Re: Apply function attributes (e.g., [[gnu::access()]]) to pointees too

[Alejandro Colomar via Gcc]

Hi Martin,

On Thu, Jul 11, 2024 at 06:34:04PM GMT, Alejandro Colomar wrote:
> Hi Martin, David,
> 
> On Thu, Jul 11, 2024 at 06:08:38PM GMT, David Brown wrote:
> > On 11/07/2024 11:58, Martin Uecker via Gcc wrote:
> > > > [[gnu::access(read_write, 1)]]
> > > > [[gnu::access(read_only, 2)]]
> > > > [[gnu::nonnull(1, 2)]]
> > > > [[gnu::null_terminated_string_arg(2)]]
> > > > char *
> > > > strsep(char **restrict sp, const char *delim);
> > > 
> > > The main problem from a user perspective is that
> > > these are attributes on the function declaration
> > > and not on the argument (type).
> > > 
> > > > 
> > > > I was thinking that with floating numbers, one could specify the number
> > > > of dereferences with a number after the decimal point.  It's a bit
> > > > weird, since the floating point is interpreted as two separate integer
> > > > numbers separated by a '.', but could work.  In this case:
> > > > 
> > > > [[gnu::access(read_write, 1)]]
> > > > [[gnu::access(read_write, 1.1)]]
> > > > [[gnu::access(read_only, 2)]]
> > > > [[gnu::nonnull(1, 2)]]
> > > > [[gnu::null_terminated_string_arg(1.1)]]
> > > > [[gnu::null_terminated_string_arg(2)]]
> > > > char *
> > > > strsep(char **restrict sp, const char *delim);
> > > > 
> > > > Which would mark the pointer *sp as read_write and a string.  What do
> > > > you think about it?
> > > 
> > > If the attributes could be applied to the type, then
> > > one could attach them directly at an intermediate
> > > pointer level, which would be more intuitive and
> > > less fragile.
> > > 

On the other hand, I was thinking of this not for [[gnu::access()]], but
for [[alx::restrict()]].

The idea was to be able to mark strtol(3) with it:

[[alx::restrict(1, 2.1)]]
[[alx::restrict(2)]]
[[gnu::access(read_only, 1)]]
[[gnu::access(write_only, 2)]]
[[gnu::access(none, 2.1)]]
[[gnu::nonnull(1)]]
[[gnu::null_terminated_string_arg(1)]]
[[gnu::leaf]]
[[gnu::nothrow]]
long
strtol(const char *nptr, char **endp, int base);

For marking parameters 1 and 2.1 as possibly aliasing each other
requires doing so at the function, and not at the parameter.

Have a lovely day!
Alex

> > 
> > That would be a huge improvement (IMHO).  Then you could write :
> > 
> > #define RW [[gnu::access(read_write)]]
> > #define RO [[gnu::access(read_only)]]
> > #define NONNULL [[gnu::nonnull]]
> > #define CSTRING [[gnu::null_terminated_string_arg]]
> > 
> > char * strsep(char * RW * RW NONNULL CSTRING restrict sp,
> > const char * RO NUNNULL CSTRING delim);
> 
> Yup; if that could be done, it would be interesting.  Martin, can it be
> done?  I'm worried that it might get ambiguous in some cases.  Is there
> any summary of positions where C23 attributes can go and their meanings?
> I always have a hard time finding all the possible combinations.
> 
> Should such a new attribute go to the left of the '*', or to the right?
> 
> > It would be even better if the characteristics could be tied into a typedef.
> > 
> > typedef const char * [[gnu::access(read_only)]] [[gnu::nonnull]]
> > [[gnu::null_terminated_string_arg]] const_cstring;
> 
> H.
> 
> > David
> 
> Cheers,
> Alex
> 
> -- 
> 



-- 



signature.asc
Description: PGP signature

GCC 11.5 Release Candidate available from gcc.gnu.org

[Richard Biener via Gcc]

The first release candidate for GCC 11.5 is available from

https://gcc.gnu.org/pub/gcc/snapshots/11.5.0-RC-20240712/

and shortly its mirrors.  It has been generated from git commit
r11-11573-g30ffca55041518.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.
Please test it and report any issues to bugzilla.

If all goes well, we'd like to release 11.5 on Friday, July 19th.

The GCC 11 branch will be closed after this release.

Re: Nonbootstrap build with Apple clang broken in gm2

[Gaius Mulley via Gcc]

FX Coudert  writes:

> Hi,
>
> I am unable to perform a nonbootstrap build when gm2 is included, with
> Apple clang 15 as compiler. The error is due to incorrect inclusion of
> headers ( and ) which are included after GCC’s
> system.h has been included, and macros like abort() are redefined or
> poisoned.
>
> I think the correct idiom in GCC is to #define INCLUDE_STRING (for
> example) before “system.h” is included, rather than #include 
> directly. The attached patch fixes the issue.
>
> Best,
> FX

Hi,

many thanks for the patch - will apply,

regards,
Gaius

Re: Nonbootstrap build with Apple clang broken in gm2

[FX Coudert via Gcc]

Another quick m2-related question: I am seeing, in a build of GCC 14.1.0 on 
Linux, that flex is called when building with the modula-2 front-end. It was 
not the case in previous builds, and the only difference is that I added m2 to 
the languages. Is that systematic? If so, the prerequisites page should be 
amended: https://gcc.gnu.org/install/prerequisites.html

Best,
FX

RE: [EXTERNAL] Re: g++12 broke my system of overloaded operator<

[Dalbey, Keith via Gcc]

I'm not going to argue about the change for CONCRETE operators, I'm going to 
argue about the loss of power/flexibility for TEMPLATED operators, because it 
defeats the whole purpose of TEMPLATED functions/operators otherwise

I've attached the header file in question... it's mostly about outputting STL 
containers (like vectors, pairs, std::shared_ptr, the file name originates when 
I was just using it for vectors but I since expanded it to other STL 
containers, not sure that std::shared_ptr technically qualifies as a 
"container")

if there could be a sort of "carve out" for TEMPLATED operator<<  (actually all 
templated operators) so that declaration of *concretions* of the templated 
operator<< get inserted at the top of any file where they're used but the 
concretized definition gets inserted at the end of the first file where it's 
used, then my templated operator<< code SHOULD just work again... and this 
change would technically affect TEMPLATED operators rather than CONCRETE 
operators

here's an example 

I generally put toStream() methods on my classes (which are scoped by 
namespaces, with a pure virtual toStream() in the base class) and AT the end of 
the class' header file (unscoped/global scope) I'll inline a CONCRETE 
operator<<  for the class which just calls the class' toStream() function.

To explain where the std::shared_ptr comes into this
My classes have heavy weight static ptrFactory methods (so they can 
throw exceptions, and the ptrFactory methods call do-nothing constructors that 
just copy stuff in) and produce a raw pointer(so they can be swigged to 
java), with an inline static PtrFactory method wrapping that to produce a 
std::shared_ptr for (memory management in) C++ side use (this makes MOVING 
instances   around easy/cheap)

In some other C++ file there will be a (usually SORTED) 
std::vector>>>  
This is basically a lighter weight map that I look up with 
std::lower_bound... one of the applications is a sort of statistical 
database/information-system where "tables" got replaced with smart  
histograms (and SomeClass="bins" of some histograms can be SomeClass=histograms 
for other variables, and the SomeKey could be a primitive, a pair or a vector, 
possibly a pair of vectors), 

the outer std::shared_ptr is to make moving entries (e.g. in std::sort 
[with a custom comparator], or when inserting a new entry into an already 
sorted vector) cheap i.e. shallow copies rather than   deep copies (the inner 
shared_ptr is for indirection through polymorphism so the current histogram 
doesn't have to know/care about what type of concrete histogram it's bins are, 
and allowing the  lookup to happen on an entry with just key and the "bin" 
being a nullptr)

and somewhere (in a .cpp file rather than a .hpp file) I'll << the vector 
(a.k.a. table/histogram) (this is a usually a dump of a "table" or part of a 
"table" in an informative error message that gets thrown in an exception, or in 
the test suite, which has roughly the same number of lines as the real code not 
counting the SWIG generated wrappers)

If the declaration of the CONCRETE operator<< 
std::vector> gets inserted at 
the top of each "file" where it gets used and the concretized definition gets 
inserted at the "bottom" of the FIRST file where its used then all CONCRETIONS 
of the TEMPLATED operator<<'s SHOULD still just work  without undoing your fix 
for CONCRETE operators

Not sure how the compiler would know whether the current file was the FIRST 
file or not, but it seems like the same problem that had to be solved for class 
declarations/definitions when there are method definitions in the class 
declaration.

-Original Message-
From: Andrew Pinski  
Sent: Thursday, July 11, 2024 6:16 PM
To: Dalbey, Keith 
Cc: gcc@gcc.gnu.org
Subject: [EXTERNAL] Re: g++12 broke my system of overloaded operator<<

[You don't often get email from pins...@gmail.com. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

On Thu, Jul 11, 2024 at 5:04 PM Dalbey, Keith via Gcc  wrote:
>
> So I'm on redhat 7 and just got devtoolsset-12 and code (a system of 
> overloaded<< operators) that was working with devtoolset-10 now break 
> (because of ordering)
>
> To not bury the lead..
>
> My code relies on the version 11 or older behavior (see below), and I don't 
> see how anyone could call the new behavior an improvement or correction 
> because it neuters/cancels out  the power/flexibility of the STL.   Yes one 
> could technically work around it by forward declaring templated operator<<  
> but that makes the system not extensible,  a common package/gitlab project 
> that handles this for the STL and then gets succeed into another library that 
> overloads the operator<< for concrete classes just doesn't work any more... 
> and that was my exact use case.

So your code depends on non-standard behavior that GCC accidentally got wrong 
until GCC 12.
I feel

RE: [EXTERNAL] Re: g++12 broke my system of overloaded operator<

[Dalbey, Keith via Gcc]

Thinking about it some more,  I can probably get templated operator<< stuff to 
work again, if I make the following changes

•   I forward declare all the templated operator<< at the start of vector 
convenience, and implement the templated operator<< after the forward 
declarations 
•   vectorConvenience.hpp ONLY gets included in .cpp files AS IN NEVER 
INCLUDE vectorConvenience.hpp in a header file (the implementations of some 
concrete operate<< will probably need to get moved from .hpp files to .cpp 
files), this may mean splitting vectorConvenience.hpp into stl2ostream.hpp and 
vs everything else (which still should be able to be included in header files)
•   Concrete classes have the operator<< at least declared (if not defined) 
in their header files (so their declarations happen ahead of the next line)
•   I <#include "vectorConvenience.hpp"/ #include "stl2ostream.hpp"> as the 
LAST of the header files, and maybe after some other forward declares in the 
.cpp files.

But seriously never being able to include a header file IN/OR-BEFORE other 
header files seems like an unreasonable hoop to jump through (as in users of my 
"common" library/git project will hit compilation errors and have to read docs 
to figure it out) when templated operator<< should just work without jumping 
through a series of hoops JUST BECAUSE THEY'RE TEMPLATES.

-Original Message-
From: Dalbey, Keith 
Sent: Friday, July 12, 2024 10:58 AM
To: Andrew Pinski 
Cc: gcc@gcc.gnu.org
Subject: RE: [EXTERNAL] Re: g++12 broke my system of overloaded operator<<

I'm not going to argue about the change for CONCRETE operators, I'm going to 
argue about the loss of power/flexibility for TEMPLATED operators, because it 
defeats the whole purpose of TEMPLATED functions/operators otherwise

I've attached the header file in question... it's mostly about outputting STL 
containers (like vectors, pairs, std::shared_ptr, the file name originates when 
I was just using it for vectors but I since expanded it to other STL 
containers, not sure that std::shared_ptr technically qualifies as a 
"container")

if there could be a sort of "carve out" for TEMPLATED operator<<  (actually all 
templated operators) so that declaration of *concretions* of the templated 
operator<< get inserted at the top of any file where they're used but the 
concretized definition gets inserted at the end of the first file where it's 
used, then my templated operator<< code SHOULD just work again... and this 
change would technically affect TEMPLATED operators rather than CONCRETE 
operators

here's an example 

I generally put toStream() methods on my classes (which are scoped by 
namespaces, with a pure virtual toStream() in the base class) and AT the end of 
the class' header file (unscoped/global scope) I'll inline a CONCRETE 
operator<<  for the class which just calls the class' toStream() function.

To explain where the std::shared_ptr comes into this
My classes have heavy weight static ptrFactory methods (so they can 
throw exceptions, and the ptrFactory methods call do-nothing constructors that 
just copy stuff in) and produce a raw pointer(so they can be swigged to 
java), with an inline static PtrFactory method wrapping that to produce a 
std::shared_ptr for (memory management in) C++ side use (this makes MOVING 
instances   around easy/cheap)

In some other C++ file there will be a (usually SORTED) 
std::vector>>>  
This is basically a lighter weight map that I look up with 
std::lower_bound... one of the applications is a sort of statistical 
database/information-system where "tables" got replaced with smart  
histograms (and SomeClass="bins" of some histograms can be SomeClass=histograms 
for other variables, and the SomeKey could be a primitive, a pair or a vector, 
possibly a pair of vectors), 

the outer std::shared_ptr is to make moving entries (e.g. in std::sort 
[with a custom comparator], or when inserting a new entry into an already 
sorted vector) cheap i.e. shallow copies rather than   deep copies (the inner 
shared_ptr is for indirection through polymorphism so the current histogram 
doesn't have to know/care about what type of concrete histogram it's bins are, 
and allowing the  lookup to happen on an entry with just key and the "bin" 
being a nullptr)

and somewhere (in a .cpp file rather than a .hpp file) I'll << the vector 
(a.k.a. table/histogram) (this is a usually a dump of a "table" or part of a 
"table" in an informative error message that gets thrown in an exception, or in 
the test suite, which has roughly the same number of lines as the real code not 
counting the SWIG generated wrappers)

If the declaration of the CONCRETE operator<< 
std::vector> gets inserted at 
the top of each "file" where it gets used and the concretized definition gets 
inserted at the "bottom" of the FIRST file where its used then all CONCRETIONS 
of the TEMPLATED operator<<'s SHOULD still ju

Re: g++12 broke my system of overloaded operator<

[Jonathan Wakely via Gcc]

On Fri, 12 Jul 2024 at 01:03, Dalbey, Keith via Gcc  wrote:
>
> So I'm on redhat 7 and just got devtoolsset-12 and code (a system of 
> overloaded<< operators) that was working with devtoolset-10 now break 
> (because of ordering)
>
> To not bury the lead..
>
> My code relies on the version 11 or older behavior (see below), and I don't 
> see how anyone could call the new behavior an improvement or correction 
> because it neuters/cancels out  the power/flexibility of the STL.   Yes one 
> could technically work around it by forward declaring templated operator<<  
> but that makes the system not extensible,  a common package/gitlab project 
> that handles this for the STL and then gets succeed into another library that 
> overloads the operator<< for concrete classes just doesn't work any more... 
> and that was my exact use case.
>
> Please reverse this change in future editions of gcc, it is absolutely awful.

Why would you want the example below to behave differently for
operator+(t, 0) and t+0 when they're two different ways to spell the
same function call?

The old behaviour was clearly a bug, and thankfully has been fixed.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577 for the bug
report I made about it years ago, which has a large number of
duplicates because other people also reported the old behaviour as a
bug. Because it was a bug, and people wanted GCC to follow the C++
standard.

I'm sorry you've written code that depends on a bug, but we're not
going to break GCC again to restore the bug.


>
> From this link
> https://developers.redhat.com/articles/2022/04/25/new-c-features-gcc-12#corrections_and_internal_improvements
> Corrections and internal improvements
> The changes described in this section bring GCC more in line with recent 
> changes to the standard, and permit behavior that previously did not work 
> correctly.
> Dependent operator lookup changes
> GCC 12 corrected a problem where the compiler performed an unqualified lookup 
> for a dependent operator expression at template definition time instead of at 
> instantiation time. The fix matches the existing behavior for dependent call 
> expressions. Consider the following test case demonstrating this change:
> #include 
>
> namespace N {
>   struct A { };
> }
>
> void operator+(N::A, double) {
>   std::cout << "#1 ";
> }
>
> template
> void f(T t) {
>   operator+(t, 0);
>   t + 0;
> }
>
> // Since it's not visible from the template definition, this later-declared
> // operator overload should not be considered when instantiating 
> f(N::A),
> // for either the call or operator expression.
> void operator+(N::A, int) {
>   std::cout << "#2 ";
> }
>
> int main() {
>   N::A a;
>   f(a);
>   std::cout << std::endl;
> }
> Copy snippet
> This program will print #1 #2 when compiled with versions 11 or older of GCC, 
> but GCC 12 correctly prints #1 #1. That's because previously only the call 
> expression resolved to the #1 overload, but with GCC 12 the operator 
> expression does too.

RE: [EXTERNAL] Re: g++12 broke my system of overloaded operator<

[Dalbey, Keith via Gcc]

The means by which this FIX was implemented caused OTHER problems

template 
std::ostream& operator<<(std::ostream& os, const std::pair& pr)
{
os << "(" << pr.first << ", " << pr.second << ")";
return os;
}

Will only work for CONCRETE classes that take the place of "F" and "S" IFF each 
of their concrete operator<< 's is FORWARD DECLARED ahead of the above 
template, so primitives like int and double should still work,  but if you 
include this file in a header file that contains a concrete class that you 
define an operator<< for, and then use in another file, you're SOL.

If you mix that with templated operator<< for vectors and std::shared_ptr  then 
there's a chicken and the egg problem for which STL templated operator<< gets 
declared first/ but you can work around this by FORWARD declaring all of your 
operator<< (including the concrete and templated ones) before **Defining** the 
STL templated operator<< 's, but that means the header file containing the STL 
templated operator<< 's can never be included in another header file and it can 
only be included as *the absolute last header file* in a .cpp file (so that all 
the concrete operator<< get declared before them, and you may still need to 
forward declare some of the contents of the .cpp file ahead of including this 
header file)

But really a header file that can't be included in other header files and can 
only be included as the absolute last header file in a .cpp file is a 
unreasonable set of hoops to jump through to get TEMPLATED operator<< 's to 
work, which should just work BECAUSE THEY'RE TEMPLATES

-Original Message-
From: Jonathan Wakely 
Sent: Friday, July 12, 2024 12:37 PM
To: Dalbey, Keith 
Cc: gcc@gcc.gnu.org
Subject: [EXTERNAL] Re: g++12 broke my system of overloaded operator<<

[You don't often get email from jwakely@gmail.com. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

On Fri, 12 Jul 2024 at 01:03, Dalbey, Keith via Gcc  wrote:
>
> So I'm on redhat 7 and just got devtoolsset-12 and code (a system of
> overloaded<< operators) that was working with devtoolset-10 now break
> (because of ordering)
>
> To not bury the lead..
>
> My code relies on the version 11 or older behavior (see below), and I don't 
> see how anyone could call the new behavior an improvement or correction 
> because it neuters/cancels out  the power/flexibility of the STL.   Yes one 
> could technically work around it by forward declaring templated operator<<  
> but that makes the system not extensible,  a common package/gitlab project 
> that handles this for the STL and then gets succeed into another library that 
> overloads the operator<< for concrete classes just doesn't work any more... 
> and that was my exact use case.
>
> Please reverse this change in future editions of gcc, it is absolutely awful.

Why would you want the example below to behave differently for
operator+(t, 0) and t+0 when they're two different ways to spell the
same function call?

The old behaviour was clearly a bug, and thankfully has been fixed.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577 for the bug report I 
made about it years ago, which has a large number of duplicates because other 
people also reported the old behaviour as a bug. Because it was a bug, and 
people wanted GCC to follow the C++ standard.

I'm sorry you've written code that depends on a bug, but we're not going to 
break GCC again to restore the bug.


>
> From this link
> https://deve/
> lopers.redhat.com%2Farticles%2F2022%2F04%2F25%2Fnew-c-features-gcc-12%
> 23corrections_and_internal_improvements&data=05%7C02%7Ckdalbey%40sandi
> a.gov%7Cc1e76e1166844e639bc208dca2a1aa33%7C7ccb5a20a303498cb0c12900738
> 1b574%7C1%7C0%7C638564062475549377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&s
> data=KxNgv9u%2BDq8toLCNArhF1xjc1tHoP2Dy%2BYEv5P2gMXo%3D&reserved=0
> Corrections and internal improvements
> The changes described in this section bring GCC more in line with recent 
> changes to the standard, and permit behavior that previously did not work 
> correctly.
> Dependent operator lookup changes
> GCC 12 corrected a problem where the compiler performed an unqualified lookup 
> for a dependent operator expression at template definition time instead of at 
> instantiation time. The fix matches the existing behavior for dependent call 
> expressions. Consider the following test case demonstrating this change:
> #include 
>
> namespace N {
>   struct A { };
> }
>
> void operator+(N::A, double) {
>   std::cout << "#1 ";
> }
>
> template
> void f(T t) {
>   operator+(t, 0);
>   t + 0;
> }
>
> // Since it's not visible from the template definition, this
> later-declared // operator overload should not be considered when
> instantiating f(N::A), // for either the call or operator expression.
> void operator+(N::A, int) {
>   std::cout << "#2 ";
> }
>
> int main() {
>   N::A a;
>   f(a);
>  

Re: [EXTERNAL] Re: g++12 broke my system of overloaded operator<

[Jonathan Wakely via Gcc]

On Fri, 12 Jul 2024 at 17:58, Dalbey, Keith via Gcc  wrote:
>
> I'm not going to argue about the change for CONCRETE operators, I'm going to 
> argue about the loss of power/flexibility for TEMPLATED operators, because it 
> defeats the whole purpose of TEMPLATED functions/operators otherwise

This is quite silly hyperbole. There are many, many good uses of
function templates that are not affected by when lookup is done, and
finding invalid declarations in the wrong scope is not "the whole
purpose" of function templates.

It's hard to take the rest of your email seriously after that.


>
> I've attached the header file in question... it's mostly about outputting STL 
> containers (like vectors, pairs, std::shared_ptr, the file name originates 
> when I was just using it for vectors but I since expanded it to other STL 
> containers, not sure that std::shared_ptr technically qualifies as a 
> "container")

The header isn't very helpful, can you show a minimal example of what
you're doing that no longer works? Maybe we can suggest how to do it
properly.

>From the header:
//put all the operator<< in the global namespace so they won't be
hidden by other custom operator<< in local namespaces

That's not how to do operator overloading, so no wonder it doesn't
work now. Lookup for operators uses Argument Dependent Lookup, which
depends on the correct use of namespaces so that the appropriate
overloads are found in associated namespaces of the argument types.

template 
inline std::ostream& operator<<(std::ostream& os, const std::pair& pr)

You should not add overloads like this for types you don't control. If
you're going to add this to the global namespace, where is typically
not going to be an associated namespace of its arguments, so ADL won't
work, then you need to make sure that the overload has been declared
prior to its use. That's really not unreasonable. Either use
namespaces properly so things can be found by ADL, or declare them
before use.

It's not reasonable to expect lookup to magically find later
declarations just because you used templates and you think that means
"find later declarations but only using infix operator syntax".

Re: [EXTERNAL] Re: g++12 broke my system of overloaded operator<

[Jonathan Wakely via Gcc]

On Fri, 12 Jul 2024 at 20:08, Dalbey, Keith  wrote:
>
> The means by which this FIX was implemented caused OTHER problems
>
> template 
> std::ostream& operator<<(std::ostream& os, const std::pair& pr)
> {
> os << "(" << pr.first << ", " << pr.second << ")";
> return os;
> }
>
> Will only work for CONCRETE classes that take the place of "F" and "S" IFF 
> each of their concrete operator<< 's is FORWARD DECLARED ahead of the above 
> template, so primitives like int and double should still work,  but if you 
> include this file in a header file that contains a concrete class that you 
> define an operator<< for, and then use in another file, you're SOL.
>
> If you mix that with templated operator<< for vectors and std::shared_ptr  
> then there's a chicken and the egg problem for which STL templated operator<< 
> gets declared first/ but you can work around this by FORWARD declaring all of 
> your operator<< (including the concrete and templated ones) before 
> **Defining** the STL templated operator<< 's, but that means the header file 
> containing the STL templated operator<< 's can never be included in another 
> header file and it can only be included as *the absolute last header file* in 
> a .cpp file (so that all the concrete operator<< get declared before them, 
> and you may still need to forward declare some of the contents of the .cpp 
> file ahead of including this header file)
>
> But really a header file that can't be included in other header files and can 
> only be included as the absolute last header file in a .cpp file is a 
> unreasonable set of hoops to jump through to get TEMPLATED operator<< 's to 
> work, which should just work BECAUSE THEY'RE TEMPLATES

You keep insisting that templates should mean something that isn't
what they mean in C++, and isn't how they work in other compilers.

Maybe you should try writing correct C++ instead?

Re: [EXTERNAL] Re: g++12 broke my system of overloaded operator<

[Andrew Pinski via Gcc]

On Fri, Jul 12, 2024 at 12:10 PM Dalbey, Keith via Gcc  wrote:
>
> The means by which this FIX was implemented caused OTHER problems
>
> template 
> std::ostream& operator<<(std::ostream& os, const std::pair& pr)
> {
> os << "(" << pr.first << ", " << pr.second << ")";
> return os;
> }


You could just do:
```
template 
std::ostream& operator<<(std::ostream& os, const std::pair& pr);

//include all other headers
template 
std::ostream& operator<<(std::ostream& os, const std::pair& pr)
{
 os << "(" << pr.first << ", " << pr.second << ")";
 return os;
}
```
And then it will work correctly.
But now this is getting into C++ help rather than GCC help really.

Thanks,
Andrew

>
> Will only work for CONCRETE classes that take the place of "F" and "S" IFF 
> each of their concrete operator<< 's is FORWARD DECLARED ahead of the above 
> template, so primitives like int and double should still work,  but if you 
> include this file in a header file that contains a concrete class that you 
> define an operator<< for, and then use in another file, you're SOL.
>
> If you mix that with templated operator<< for vectors and std::shared_ptr  
> then there's a chicken and the egg problem for which STL templated operator<< 
> gets declared first/ but you can work around this by FORWARD declaring all of 
> your operator<< (including the concrete and templated ones) before 
> **Defining** the STL templated operator<< 's, but that means the header file 
> containing the STL templated operator<< 's can never be included in another 
> header file and it can only be included as *the absolute last header file* in 
> a .cpp file (so that all the concrete operator<< get declared before them, 
> and you may still need to forward declare some of the contents of the .cpp 
> file ahead of including this header file)
>
> But really a header file that can't be included in other header files and can 
> only be included as the absolute last header file in a .cpp file is a 
> unreasonable set of hoops to jump through to get TEMPLATED operator<< 's to 
> work, which should just work BECAUSE THEY'RE TEMPLATES
>
> -Original Message-
> From: Jonathan Wakely 
> Sent: Friday, July 12, 2024 12:37 PM
> To: Dalbey, Keith 
> Cc: gcc@gcc.gnu.org
> Subject: [EXTERNAL] Re: g++12 broke my system of overloaded operator<<
>
> [You don't often get email from jwakely@gmail.com. Learn why this is 
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On Fri, 12 Jul 2024 at 01:03, Dalbey, Keith via Gcc  wrote:
> >
> > So I'm on redhat 7 and just got devtoolsset-12 and code (a system of
> > overloaded<< operators) that was working with devtoolset-10 now break
> > (because of ordering)
> >
> > To not bury the lead..
> >
> > My code relies on the version 11 or older behavior (see below), and I don't 
> > see how anyone could call the new behavior an improvement or correction 
> > because it neuters/cancels out  the power/flexibility of the STL.   Yes one 
> > could technically work around it by forward declaring templated operator<<  
> > but that makes the system not extensible,  a common package/gitlab project 
> > that handles this for the STL and then gets succeed into another library 
> > that overloads the operator<< for concrete classes just doesn't work any 
> > more... and that was my exact use case.
> >
> > Please reverse this change in future editions of gcc, it is absolutely 
> > awful.
>
> Why would you want the example below to behave differently for
> operator+(t, 0) and t+0 when they're two different ways to spell the
> same function call?
>
> The old behaviour was clearly a bug, and thankfully has been fixed.
> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577 for the bug report I 
> made about it years ago, which has a large number of duplicates because other 
> people also reported the old behaviour as a bug. Because it was a bug, and 
> people wanted GCC to follow the C++ standard.
>
> I'm sorry you've written code that depends on a bug, but we're not going to 
> break GCC again to restore the bug.
>
>
> >
> > From this link
> > https://deve/
> > lopers.redhat.com%2Farticles%2F2022%2F04%2F25%2Fnew-c-features-gcc-12%
> > 23corrections_and_internal_improvements&data=05%7C02%7Ckdalbey%40sandi
> > a.gov%7Cc1e76e1166844e639bc208dca2a1aa33%7C7ccb5a20a303498cb0c12900738
> > 1b574%7C1%7C0%7C638564062475549377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&s
> > data=KxNgv9u%2BDq8toLCNArhF1xjc1tHoP2Dy%2BYEv5P2gMXo%3D&reserved=0
> > Corrections and internal improvements
> > The changes described in this section bring GCC more in line with recent 
> > changes to the standard, and permit behavior that previously did not work 
> > correctly.
> > Dependent operator lookup changes
> > GCC 12 corrected a problem where the compiler performed an unqualified 
> > lookup for a dependent operator expression at template definition time 
> > 

Re: [EXTERNAL] Re: g++12 broke my system of overloaded operator<

[Jonathan Wakely via Gcc]

On Fri, 12 Jul 2024 at 20:08, Dalbey, Keith  wrote:
>
> The means by which this FIX was implemented caused OTHER problems
>
> template 
> std::ostream& operator<<(std::ostream& os, const std::pair& pr)
> {
> os << "(" << pr.first << ", " << pr.second << ")";
> return os;
> }
>
> Will only work for CONCRETE classes that take the place of "F" and "S" IFF 
> each of their concrete operator<< 's is FORWARD DECLARED ahead of the above 
> template, so primitives like int and double should still work,  but if you 
> include this file in a header file that contains a concrete class that you 
> define an operator<< for, and then use in another file, you're SOL.

This is simply not true.

#include 
#include 

template 
std::ostream& operator<<(std::ostream& os, const std::pair& pr)
{
os << "(" << pr.first << ", " << pr.second << ")";
return os;
}

namespace ns {

  struct A { };

  inline std::ostream& operator<<(std::ostream& out, const A& a)
  {
return out << "A\n";
  }
}

#include 

int main()
{
  std::pair p{};
  std::cout << p;
}

This program works via ADL, because it uses namespaces correctly.

If you dump all your operator overloads in the global namespace, then
it doesn't work. So don't do that then.

RE: [EXTERNAL] Re: g++12 broke my system of overloaded operator<

[Dalbey, Keith via Gcc]

-Original Message-
From: Andrew Pinski 
Sent: Friday, July 12, 2024 1:20 PM
To: Dalbey, Keith 
Cc: Jonathan Wakely ; gcc@gcc.gnu.org
Subject: Re: [EXTERNAL] Re: g++12 broke my system of overloaded operator<<

On Fri, Jul 12, 2024 at 12:10 PM Dalbey, Keith via Gcc  wrote:
>
> The means by which this FIX was implemented caused OTHER problems
>
> template 
> std::ostream& operator<<(std::ostream& os, const std::pair& pr) {
> os << "(" << pr.first << ", " << pr.second << ")";
> return os;
> }


You could just do:
```
template 
std::ostream& operator<<(std::ostream& os, const std::pair& pr); 
//include all other headers
template 
std::ostream& operator<<(std::ostream& os, const std::pair& pr) {
 os << "(" << pr.first << ", " << pr.second << ")";
 return os;
}
```
And then it will work correctly.
But now this is getting into C++ help rather than GCC help really.

Thanks,
Andrew

From Keith: that's effectively what I worked out in the paragraph below from my 
previous email (although I likely said it less clearly) but the issue with the 
solution as you wrote it means not putting all the STL template operator<< in a 
common package/library that gets used by multiple projects, UNLESS you're VERY 
VERY careful to never include the templated operator<< DEFINITIONS header file 
in *OR BEFORE* other headers.   Yes it's workable, but users will encounter 
headaches/confusion when they invariably include the file with the templated 
operator<< definitions IN *OR BEFORE* other header files.  I am not an expert 
on compilers and my practical knowledge of what templates "are" is **how** they 
have **behaved** in the past. I have 3 decades experience programming, almost 
2.5 decades of that in C++ and I've almost exclusively using gcc (so that 
different compilers behaving differently wasn't ever observed) and before 
yesterday I'd never seen or even heard anyone mention using forward 
declarations of templated functions, I honestly didn't know it was a thing.  
Admittedly my PhD is in mechanical engineering and I've using been using gcc to 
solve math/physics problems such as computational fluid dynamics, orbital 
problems, geolocation, statistics, etc. rather than "pure CS problems" like 
databases.  I don't have a CS degree but I do know that programming is/was 
taught very differently to engineering vs CS majors (back when I was first 
learning C++, engineers weren't taught about maps or sets, etc. and shared_ptrs 
weren't a thing yet, I worked out how the STL behaved by using it).  A typical 
engineers perspective on C++ vs C was (and probably still is) new & delete vs 
calloc/malloc/free, vectors instead of arrays; cin, cout, instead of fprintf 
and fscanf; using inline functions instead of macros; and classes are just 
non-public structs with methods and inheritance/polymorphism.  We were told 
that this thing called template meta programming existed and was code that 
executed in the compiler rather than runtime but we didn't actually touch 
templates in college and we weren't really taught about namespaces other than 
std either.   The point I'm making is: most g++ users' mental model of HOW 
templates are SUPPOSED to work probably doesn't match that of the developers of 
the compiler and the reason for that is how it's SUPPOSED to behave is VERY 
POORLY documented particularly on the internet (there's probably some very good 
book on it that CS majors learn C++ from).  That link I found and shared in my 
original email was the **ONLY** thing *relevant* I found in 2 hours of 
googling, but at least I immediately realized it explained **WHY** my code that 
had been working for years without error suddenly stopped working with the 
compiler switch (even though the link didn't directly speak templated 
operators). Thank you, Andrew for showing some understanding for how I reacted 
to having a (mandated) compiler change suddenly pull the rug out from under my 
code (which is being used in multiple projects).  I know a lot of other people 
in my department, most of us are either engineers or CS majors who are now 
responsible for maintaining inherited code written by engineers decades ago.  
And most of us are a bit stressed about needing to update code that broke with 
gcc 12, we don't have a lot of time to do it, and we don't have an option not 
to upgrade to gcc 12.  I'm lucky in that at least I'm maintaining my own code.


> Will only work for CONCRETE classes that take the place of "F" and "S" IFF 
> each of their concrete operator<< 's is FORWARD DECLARED ahead of the above 
> template, so primitives like int and double should still work,  but if you 
> include this file in a header file that contains a concrete class that you 
> define an operator<< for, and then use in another file, you're SOL.
>
> If you mix that with templated operator<< for vectors and
> std::shared_ptr  then there's a chicken and the egg problem for which
> STL templated operator<< gets declared 

gcc-13-20240712 is now available

[GCC Administrator via Gcc]

Snapshot gcc-13-20240712 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/13-20240712/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-13 revision 08463348c5cce84dc3c64ac4fbb20e2795ee104f

You'll find:

 gcc-13-20240712.tar.xz   Complete GCC

  SHA256=dea9c37e9280e77d1d6a0586238a2b7a418ecfa7ceffdd8a02168c0821314168
  SHA1=a93c3717042f80a04201046338385324572f546e

Diffs from 13-20240705 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-13
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.