Same issue as clang bug report:
https://github.com/llvm/llvm-project/issues/96859

This is a bug in the sources.

But does GCC have a walkaround similar as -fdelayed-template-parsing in Clang?

https://inbox.sourceware.org/gcc-patches/CA+=Sn1m=nJ+S3Zy4kzRE=tyGnED+XDN0ifqVKbjH49vr60h3uA@mail.gmail.com/

FWIW -fdelayed-template-parsing seems to originally have been introduced as an MSVC compatibility flag: https://clang.llvm.org/docs/MSVCCompatibility.html#template-instantiation-and-name-lookup

It can change the meaning of valid code since it causes unqualified lookup to be performed from the point of instantiation instead of from the template definition:

  int g(long) { return 0; }

  template<class T>
  int f() { return g(0); }

  int g(int) { return 1; }

  int main() {
    return f<int>(); // returns 1 with -fdelayed-template-parsing, 0 without
  }

That it also suppresses errors inside uninstantiated templates seems to be a convenient coincidence, so it doesn't seem to be an ideal workaround.

I'm going to try downgrading these name lookup errors into permerrors when inside an uninstantiated template, so that they can be worked around by passing -fpermissive (which doesn't change the meaning of valid code).

So my understanding is that the Clang teams have decided that the code in xalancbmk is just broken (one of our engineers stumbled on this a few weeks back).

Of course spec is highly reluctant to change the source.  We've been down that path multiple times.  So we're probably going to need to have some flag we can use to compile this broken code in xalancbmk.

By the way Xalan even upstream still has this bug.
https://github.com/apache/xalan-c/blob/c326619da4813acfc845c2830d904a4860f9afe1/src/xalanc/XMLSupport/XalanOtherEncodingWriter.hpp#L323

They do have a jira but there does not look like there is much work being done on the project either.
(https://issues.apache.org/jira/issues/ ).

The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:596d1ed9d40b1081fcc6c6161a0135952829b88f

commit r15-2774-g596d1ed9d40b1081fcc6c6161a0135952829b88f
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue Aug 6 20:54:03 2024 -0400

    c++: permit errors inside uninstantiated templates [PR116064]
    
    In recent versions of GCC we've been diagnosing more and more kinds of
    errors inside a template ahead of time.  This is a largely good thing
    because it catches bugs, typos, dead code etc sooner.
    
    But if the template never gets instantiated then such errors are harmless
    and can be inconvenient to work around if say the code in question is
    third party and in maintenance mode.  So it'd be handy to be able to
    prevent these template errors from rendering the entire TU uncompilable.
    (Note that such code is "ill-formed no diagnostic required" according
    the standard.)
    
    To that end this patch turns any errors issued within a template into
    permerrors associated with a new -Wtemplate-body flag so that they can
    be downgraded via e.g. -fpermissive or -Wno-error=template-body.  If
    the template containing a downgraded error later needs to be instantiated,
    we'll issue an error then.  But if the template never gets instantiated
    then the downgraded error won't affect validity of the rest of the TU.
    
    This is implemented via a diagnostic hook that gets called for each
    diagnostic, and which adjusts an error diagnostic appropriately if we
    detect it's occurring from a template context, and additionally flags
    the template as erroneous.
    
    For example the new testcase permissive-error1a.C gives:
    
    gcc/testsuite/g++.dg/template/permissive-error1a.C: In function 'void f()':
    gcc/testsuite/g++.dg/template/permissive-error1a.C:7:5: warning: increment of read-only variable 'n' [-Wtemplate-body]
        7 |   ++n;
          |     ^
    ...
    gcc/testsuite/g++.dg/template/permissive-error1a.C: In instantiation of 'void f() [with T = int]':
    gcc/testsuite/g++.dg/template/permissive-error1a.C:26:9:   required from here
       26 |   f<int>();
          |   ~~~~~~^~
    gcc/testsuite/g++.dg/template/permissive-error1a.C:5:6: error: instantiating erroneous template
        5 | void f() {
          |      ^
    gcc/testsuite/g++.dg/template/permissive-error1a.C:7:5: note: first error appeared here
        7 |   ++n; // {
          |     ^
    ...
    
            PR c++/116064
    
    gcc/c-family/ChangeLog:
    
            * c.opt (Wtemplate-body): New warning.
    
    gcc/cp/ChangeLog:
    
            * cp-tree.h (erroneous_templates_t): Declare.
            (erroneous_templates): Declare.
            (cp_seen_error): Declare.
            (seen_error): #define to cp_seen_error.
            * error.cc (get_current_template): Define.
            (relaxed_template_errors): Define.
            (cp_adjust_diagnostic_info): Define.
            (cp_seen_error): Define.
            (cxx_initialize_diagnostics): Set
            diagnostic_context::m_adjust_diagnostic_info.
            * module.cc (finish_module_processing): Don't write the
            module if it contains an erroneous template.
            * pt.cc (maybe_diagnose_erroneous_template): Define.
            (instantiate_class_template): Call it.
            (instantiate_decl): Likewise.
    
    gcc/ChangeLog:
    
            * diagnostic.cc (diagnostic_context::initialize): Set
            m_adjust_diagnostic_info.
            (diagnostic_context::report_diagnostic): Call
            m_adjust_diagnostic_info.
            * diagnostic.h (diagnostic_context::m_adjust_diagnostic_info):
            New data member.
            * doc/invoke.texi (-Wno-template-body): Document.
            (-fpermissive): Mention -Wtemplate-body.
    
    gcc/testsuite/ChangeLog:
    
            * g++.dg/ext/typedef-init.C: Downgrade error inside template
            to warning due to -fpermissive.
            * g++.dg/pr84492.C: Likewise.
            * g++.old-deja/g++.pt/crash51.C: Remove unneeded dg-options.
            * g++.dg/template/permissive-error1.C: New test.
            * g++.dg/template/permissive-error1a.C: New test.
            * g++.dg/template/permissive-error1b.C: New test.
            * g++.dg/template/permissive-error1c.C: New test.
    
    Reviewed-by: Jason Merrill <jason@redhat.com>

One can now use -fpermissive or -Wno-error=template-body to compile TUs containing errors inside uninstantiated templates.

The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:d1fc9816df81e953308428641685d6ec6d84c9ac

commit r15-2802-gd1fc9816df81e953308428641685d6ec6d84c9ac
Author: Patrick Palka <ppalka@redhat.com>
Date:   Wed Aug 7 14:28:26 2024 -0400

    c++: erroneous partial spec vs primary tmpl [PR116064]
    
    When a partial specialization is deemed erroneous at parse time, we
    currently flag the primary template as erroneous instead.  Later
    at instantiation time we check if the primary template is erroneous
    rather than the selected partial specialization, so at least we're
    consistent.
    
    But it's better not to conflate a partial specialization with the
    primary template since they're instantiated independenty.  This avoids
    rejecting the instantiation of A<int> in the below testcase.
    
            PR c++/116064
    
    gcc/cp/ChangeLog:
    
            * error.cc (get_current_template): If the current scope is
            a partial specialization, return it instead of the primary
            template.
            * pt.cc (instantiate_class_template): Pass the partial
            specialization if any to maybe_diagnose_erroneous_template
            instead of the primary template.
    
    gcc/testsuite/ChangeLog:
    
            * g++.dg/template/permissive-error2.C: New test.
    
    Reviewed-by: Jason Merrill <jason@redhat.com>

So - fixed?

(In reply to Richard Biener from comment #10)
> So - fixed?

Yes.

Looks RISC-V backend still has this issue, can you reproduce this?

/opt/gcc-master//bin/g++ --version
g++ (GCC) 15.0.0 20241014 (experimental)

/opt/gcc-master//bin/g++ -std=c++03 -c -o XalanXMLSerializerFactory.o -DSPEC -DNDEBUG  -DAPP_NO_THREADS -DXALAN_INMEM_MSG_LOADER -I. -Ixercesc -Ixercesc/dom -Ixercesc/dom/impl -Ixercesc/sax -Ixercesc/util/MsgLoaders/InMemory -Ixercesc/util/Transcoders/Iconv -Ixalanc/i>
In file included from XalanXMLSerializerFactory.cpp:30:
xalanc/XMLSupport/XalanOtherEncodingWriter.hpp: In member function 'void xalanc_1_10::XalanOtherEncodingWriter<Predicate, ConstantsType>::writeSafe(const xalanc_1_10::XalanDOMChar*, xalanc_1_10::XalanFormatterWriter::size_type)':
xalanc/XMLSupport/XalanOtherEncodingWriter.hpp:319:30: error: 'class xalanc_1_10::XalanOtherEncodingWriter<Predicate, ConstantsType>' has no member named 'm_isPresentable' [-Wtemplate-body]
  319 |                     if(this->m_isPresentable(value))
      |                              ^~~~~~~~~~~~~~~
xalanc/XMLSupport/XalanOtherEncodingWriter.hpp:325:31: error: 'class xalanc_1_10::XalanOtherEncodingWriter<Predicate, ConstantsType>' has no member named 'writeNumberedEntityReference' [-Wtemplate-body]
  325 |                         this->writeNumberedEntityReference(value);
      |                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
specmake: *** [/root/panli/benchmarks/spec2017/benchspec/Makefile.defaults:366: XalanXMLSerializerFactory.o] Error 1
specmake: *** Waiting for unfinished jobs....

(In reply to Li Pan from comment #12)
> Looks RISC-V backend still has this issue, can you reproduce this?
> 
> /opt/gcc-master//bin/g++ --version
> g++ (GCC) 15.0.0 20241014 (experimental)
> 
> /opt/gcc-master//bin/g++ -std=c++03 -c -o XalanXMLSerializerFactory.o -DSPEC
> -DNDEBUG  -DAPP_NO_THREADS -DXALAN_INMEM_MSG_LOADER -I. -Ixercesc
> -Ixercesc/dom -Ixercesc/dom/impl -Ixercesc/sax
> -Ixercesc/util/MsgLoaders/InMemory -Ixercesc/util/Transcoders/Iconv
> -Ixalanc/i>
> In file included from XalanXMLSerializerFactory.cpp:30:
> xalanc/XMLSupport/XalanOtherEncodingWriter.hpp: In member function 'void
> xalanc_1_10::XalanOtherEncodingWriter<Predicate,
> ConstantsType>::writeSafe(const xalanc_1_10::XalanDOMChar*,
> xalanc_1_10::XalanFormatterWriter::size_type)':
> xalanc/XMLSupport/XalanOtherEncodingWriter.hpp:319:30: error: 'class
> xalanc_1_10::XalanOtherEncodingWriter<Predicate, ConstantsType>' has no
> member named 'm_isPresentable' [-Wtemplate-body]
>   319 |                     if(this->m_isPresentable(value))
>       |                              ^~~~~~~~~~~~~~~
> xalanc/XMLSupport/XalanOtherEncodingWriter.hpp:325:31: error: 'class
> xalanc_1_10::XalanOtherEncodingWriter<Predicate, ConstantsType>' has no
> member named 'writeNumberedEntityReference' [-Wtemplate-body]
>   325 |                         this->writeNumberedEntityReference(value);
>       |                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> specmake: ***
> [/root/panli/benchmarks/spec2017/benchspec/Makefile.defaults:366:
> XalanXMLSerializerFactory.o] Error 1
> specmake: *** Waiting for unfinished jobs....

your command invocation doesn't look like you passed any of the two required flags though..

> One can now use -fpermissive or -Wno-error=template-body to compile TUs
> containing errors inside uninstantiated templates.

So you have to use one of those two.

> So you have to use one of those two.

Thanks, I see, let me update the config file and have another try.

(In reply to Li Pan from comment #14)
> > So you have to use one of those two.
> 
> Thanks, I see, let me update the config file and have another try.

-Wno-error=template-body works, thanks a lot.