[Bug modula2/108294] New: soname bump for modula2 runtime libraries

[doko at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108294

Bug ID: 108294
   Summary: soname bump for modula2 runtime libraries
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

The soname for the Modula-2 runtime libraries for the compiler based on GCC 12
is 17, and didn't change for GCC 13.  Please bump the version to 18, or reset
it to 1, so that these can co-exist.  Assuming that there a slight differences
in the ABIs for these versions.

[Bug c/108295] New: Free label positions shouldn't be available outside -std=c2x

[daniel.lundin.mail at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

Bug ID: 108295
   Summary: Free label positions shouldn't be available outside
-std=c2x
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.lundin.mail at gmail dot com
  Target Milestone: ---

The new C23 features introduced in gcc 11.0.0 appears to be inconsistently
deactivated when picking some other version than -std=c2x.

The new C23 feature "Free positioning of labels inside compound statements"
appears to be active even with -std=c17 or the default gnu17 is picked. Unlike
other C23 features introduced in the same version 11 release, which are
correctly activated when using -std=c2x or otherwise inactivated.

For example gcc treats true/false as bool when activating -std=c2x but treats
them as int when older C versions are used. Free positioning of labels should
behave just in the same manner.

See attached example.

[Bug c/108296] New: __builtin_memcpy generating wrong code in some cases

[nyh at math dot technion.ac.il via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108296

Bug ID: 108296
   Summary: __builtin_memcpy generating wrong code in some cases
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nyh at math dot technion.ac.il
  Target Milestone: ---

The following trivial code, copying a string over itself moved by one byte,
shows wrong results for __builtin_memcpy() on gcc 12.2.1:

#include 
int main(){
char bufa[128] = "0123456789abcdefghijklmnopqrstuvwxyz";
char bufb[128] = "0123456789abcdefghijklmnopqrstuvwxyz";
memcpy(bufa, bufa+1, 27);
printf("  memcpy: %s\n", bufa);
__builtin_memcpy(bufb, bufb+1, 27);
printf("__builtin_memcpy: %s\n", bufb);
}

As you can see running it, memcpy() returned the right result,
123456789abcdefghijklmnopqrrstuvwxyz (the first 27 characters shifted back, so
"r" is double in the response), but __builtin_memcpy() returned the *wrong*
result - 123456789abdefgghijklmnopqrrstuvwxyz (the "c" character disappeared
and the "g" is  also doubled).


This bug was discovered in the OSv project
https://github.com/cloudius-systems/osv/issues/1212 with code that doesn't
(obviously) call __builtin_memcpy() directly, but rather had a 27-character
type being copied and the compiler implemented this copy with a call to
__builtin_memcpy(). The original miscompiling code in OSv  was something like
the following:

#include 
int main(){
char buf[128] = "0123456789abcdefghijklmnopqrstuvwxyz";
struct [[gnu::packed]] data {
char x[27];
};
void *p0 = buf;
void *p1 = &buf[1];
*static_cast(p0) = *static_cast(p1);
printf("%s", buf);
}

This appears to be a regression - this code did not miscompile in earlier gcc
releases.

[Bug c/108295] Free label positions shouldn't be available outside -std=c2x

[daniel.lundin.mail at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

--- Comment #1 from Daniel Lundin  ---
Created attachment 54193
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54193&action=edit
Correctly working true/false vs incorrectly free position of label

[Bug middle-end/108278] [13 Regression] runtime error with -O1 -Wall

[dcb314 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278

--- Comment #14 from David Binderman  ---
(In reply to Florian Weimer from comment #8)
> I believe the revert in 455acc43518744b89d6a795bbba5045bd228060b should have
> fixed this?

It looks to me like it does.

> I also brought up the initialization issue on the gcc list:
> 
> Default initialization of poly-ints
> 

This is the second time I have noticed this issue has occurred with a 
data type in gcc. It would be safer if there was a default initialisation
to zero for all gcc data types.

[Bug c/108295] Free label positions shouldn't be available outside -std=c2x

[schwab--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

--- Comment #2 from Andreas Schwab  ---
Free positioning of labels inside compound statements doesn't affect correctly
written programs.

[Bug c/108296] __builtin_memcpy generating wrong code in some cases

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108296

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
Dup of bug 32667.

The bug is not memcpy does not work for overlapping memory locations but rather
using memcpy instead of memmove for struct/block copies.

*** This bug has been marked as a duplicate of bug 32667 ***

[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667

Andrew Pinski  changed:

   What|Removed |Added

 CC||nyh at math dot technion.ac.il

--- Comment #20 from Andrew Pinski  ---
*** Bug 108296 has been marked as a duplicate of this bug. ***

[Bug c/108295] Free label positions shouldn't be available outside -std=c2x

[daniel.lundin.mail at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

--- Comment #3 from Daniel Lundin  ---
(In reply to Andreas Schwab from comment #2)
> Free positioning of labels inside compound statements doesn't affect
> correctly written programs.

No but until C23, the compiler should report an error for incorrect syntax when
they aren't. For example when declaring a variable inside a case statement
without using {} compound statements.

[Bug libbacktrace/108297] New: libtool link b2test fails: Unrecognized argument: --build-id

[danglin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297

Bug ID: 108297
   Summary: libtool link b2test fails: Unrecognized argument:
--build-id
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libbacktrace
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: ian at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

libtool: link: /home/dave/gnu/gcc/objdir64/./prev-gcc/xgcc
-B/home/dave/gnu/gcc/
objdir64/./prev-gcc/ -B/opt/gnu64/gcc/gcc-13/hppa64-hp-hpux11.11/bin/
-B/opt/gnu
64/gcc/gcc-13/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-13/hppa64-hp-hpux11.
11/lib/ -isystem /opt/gnu64/gcc/gcc-13/hppa64-hp-hpux11.11/include -isystem
/opt
/gnu64/gcc/gcc-13/hppa64-hp-hpux11.11/sys-include -funwind-tables
-frandom-seed=
b2test -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-s
tyle-definition -Wmissing-format-attribute -Wcast-qual -g -O2 -g -Wl,--build-id
-s -o b2test b2test-btest.o b2test-testlib.o 
./.libs/libbacktrace_elf_for_test.
a
ld: Unrecognized argument: --build-id
Fatal error.
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:1324: b2test] Error 1

[Bug c/108295] Free label positions shouldn't be available outside -std=c2x

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-01-05
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #4 from Andrew Pinski  ---
Try -pedantic-errors.

[Bug c/108296] __builtin_memcpy generating wrong code in some cases

[nyh at math dot technion.ac.il via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108296

--- Comment #2 from Nadav Har'El  ---
Thanks. Interesting. So __builtin_memcpy() is simply not supposed to work
correctly for overlapping areas? I now realize that according to memcpy(3)
documentation, memcpy() is also not guaranteed to work correctly in this case
(and you should use memmove() in this case), but in practice it does work
correctly when copying a higher address to a lower address.

[Bug c/108298] New: Wrong optimization of volatile access from gcc 11 and beyond

[daniel.lundin.mail at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298

Bug ID: 108298
   Summary: Wrong optimization of volatile access from gcc 11 and
beyond
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.lundin.mail at gmail dot com
  Target Milestone: ---

Created attachment 54194
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54194&action=edit
Example to reproduce incorrect optimizations

Before gcc 11.0.0, the attached example compiled under -O3 would result in the
whole function getting optimized into a single load instruction when volatile
was not used. Adding a volatile access would lead to instructions for fetching
the value from the stack getting generated.

This appears to be conforming behavior, references ISO/IEC 9899:2018 5.1.2.3,
particularly §2, §4 and §6. I believe gcc 10.4 or older behaves correctly.

After gcc 11.0.0, the function is optimized regardless of if volatile is used
or not. See attached example. With FREE_TO_OPTIMIZE defined, I would expect the
compiler to optimize the code under -O3. Without it, I would expect the
compiler to generate a read instruction since this is a "side effect".

For convenience, here is also an online compiler example for x86-64 Linux
https://godbolt.org/z/4qez1P746

[Bug c/108298] Wrong optimization of volatile access from gcc 11 and beyond

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
Dup of bug 33053.
C2x changes things which might be the reason for change in gcc 12.

*** This bug has been marked as a duplicate of bug 33053 ***

[Bug c/108295] Free label positions shouldn't be available outside -std=c2x

[daniel.lundin.mail at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

--- Comment #5 from Daniel Lundin  ---
(In reply to Andrew Pinski from comment #4)
> Try -pedantic-errors.

Yes I already did and then the error appears. But that would imply that this is
a non-standard GNU extension and not an upcoming standard C23 feature, which
still doesn't seem correct. 

If the intention was to add this as a GNU extension until formal release of
C23, then the use of such GNU extensions will behave inconsistently between gcc
<10.4 and gcc >11.0 when using the same compiler options. And I don't think
that's documented anywhere either.

[Bug c/33053] adopt accesses through a volatile-casted pointer as a GNU C extension

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33053

Andrew Pinski  changed:

   What|Removed |Added

 CC||daniel.lundin.mail at gmail 
dot co
   ||m

--- Comment #4 from Andrew Pinski  ---
*** Bug 108298 has been marked as a duplicate of this bug. ***

[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy

[nyh at math dot technion.ac.il via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667

--- Comment #21 from Nadav Har'El  ---
This old problem has become a real problem in gcc 12 with a real effect on
incorrect code generation, where code that copies an object was incorrectly
"optimized" to use __builtin_memcpy() instead of __builtin_memmove() even
though the source and destination objects may overlap - and it turns out that
__builtin_memcpy() may produce incorrect results for overlapping addresses.

This bug was discovered in the OSv project
https://github.com/cloudius-systems/osv/issues/1212 with code that doesn't
(obviously) call __builtin_memcpy() directly, but rather had a 27-character
type being copied and the compiler implemented this copy with a call to
__builtin_memcpy(). Here is an example of code which generates the wrong
results (note the missing "c" in the result and unexpectedly doubled "g"):

#include 
int main(){
char buf[128] = "0123456789abcdefghijklmnopqrstuvwxyz";
struct [[gnu::packed]] data {
char x[27];
};
void *p0 = buf;
void *p1 = &buf[1];
*static_cast(p0) = *static_cast(p1);
printf("%s", buf);
}

[Bug c/108295] Free label positions shouldn't be available outside -std=c2x

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Andrew Pinski  ---
(In reply to Daniel Lundin from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > Try -pedantic-errors.
> 
> Yes I already did and then the error appears. But that would imply that this
> is a non-standard GNU extension and not an upcoming standard C23 feature,
> which still doesn't seem correct. 
> 
> If the intention was to add this as a GNU extension until formal release of
> C23, then the use of such GNU extensions will behave inconsistently between
> gcc <10.4 and gcc >11.0 when using the same compiler options. And I don't
> think that's documented anywhere either.

https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Mixed-Labels-and-Declarations.html#Mixed-Labels-and-Declarations

Compared to
https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gcc/Mixed-Declarations.html#Mixed-Declarations

Is definitely documented.

[Bug c/108295] Free label positions shouldn't be available outside -std=c2x

[daniel.lundin.mail at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

--- Comment #7 from Daniel Lundin  ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Daniel Lundin from comment #5)
> > (In reply to Andrew Pinski from comment #4)
> > > Try -pedantic-errors.
> > 
> > Yes I already did and then the error appears. But that would imply that this
> > is a non-standard GNU extension and not an upcoming standard C23 feature,
> > which still doesn't seem correct. 
> > 
> > If the intention was to add this as a GNU extension until formal release of
> > C23, then the use of such GNU extensions will behave inconsistently between
> > gcc <10.4 and gcc >11.0 when using the same compiler options. And I don't
> > think that's documented anywhere either.
> 
> https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Mixed-Labels-and-Declarations.
> html#Mixed-Labels-and-Declarations
> 
> Compared to
> https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gcc/Mixed-Declarations.html#Mixed-
> Declarations
> 
> Is definitely documented.

Fair enough but GNU C mode is -std=gnu17 (the default setting), not -std=c17.

[Bug c/108295] Free label positions shouldn't be available outside -std=c2x

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

--- Comment #8 from Andrew Pinski  ---
"When a base standard is specified, the compiler accepts all programs following
that standard plus those using GNU extensions that do not contradict it."

Wrong again.
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/C-Dialect-Options.html#index-std-1

[Bug c/108295] Free label positions shouldn't be available outside -std=c2x

[daniel.lundin.mail at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

--- Comment #9 from Daniel Lundin  ---
(In reply to Andrew Pinski from comment #8)
> "When a base standard is specified, the compiler accepts all programs
> following that standard plus those using GNU extensions that do not
> contradict it."
> 
> Wrong again.
> https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/C-Dialect-Options.html#index-
> std-1

In this case the GNU extension does contradict the ISO 9899:2018 standard. A
conforming compiler is required to issue a diagnostic (as per 5.1.1.3) upon
spotting a violation of the syntax in 6.8.1.

[Bug c/108295] Free label positions shouldn't be available outside -std=c2x

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

--- Comment #10 from Andrew Pinski  ---
By conflicting means rejection of correct code. Like for an example the use of
the ident non reserved unix, etc.

[Bug c/108295] Free label positions shouldn't be available outside -std=c2x

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

--- Comment #11 from Jakub Jelinek  ---
(In reply to Daniel Lundin from comment #9)
> In this case the GNU extension does contradict the ISO 9899:2018 standard. A
> conforming compiler is required to issue a diagnostic (as per 5.1.1.3) upon
> spotting a violation of the syntax in 6.8.1.

In such understanding all extensions would contradict the standard, extensions
are when some otherwise invalid source is given a meaning, which is this case
too.
Even in C++ we often enable features of a newer standard in older ones as long
as they don't conflict with valid syntax, just with pedantic warnings/errors. 
It is possible
if the new feature has a new syntax which is invalid in the old standard, so
e.g. structured bindings can be accepted in older standards with pedantic
warnings/errors just fine because in older standards it was always invalid
syntax.  Compare that to features where say the behavior of some construct
changes with a newer standard version, that one obviously can't be treated that
way.
And -pedantic/-pedantic-errors are the options to request pedantic warnings or
errors.

[Bug c/108295] Free label positions shouldn't be available outside -std=c2x

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

--- Comment #12 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #10)
> By conflicting means rejection of correct code. Like for an example the use
> of the ident non reserved unix, etc.

The documentation even mentions that. You only read the snippet of what I
copied rather than reading the whole thing.

[Bug c/33053] adopt accesses through a volatile-casted pointer as a GNU C extension

[daniel.lundin.mail at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33053

--- Comment #5 from Daniel Lundin  ---
The intention of DR 476 (Sebor)
https://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_476 was a
clarification leading to a volatile lvalue access being a side effect, as
opposed to an access of volatile objects. Changes from the DR were included in
C23.

The C23 n3054 draft now says "An access to an object through the use of an
lvalue of volatile-qualified type is a volatile access. A volatile access to an
object, modifying an object, modifying a file, or calling a function that does
any of those operations are all side effects-..."

This ought to result in stricter optimizing behavior from gcc, not the other
way around. As reported in bug 108298
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298), gcc 11 and beyond rather
seems to optimize more aggressively, which it didn't up to version 10.4.

[Bug c++/108299] New: toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced

[agriff at tin dot it via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299

Bug ID: 108299
   Summary: toplevel thread_local variables are not initialized if
not referenced and initialized at wrong moment when
referenced
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: agriff at tin dot it
  Target Milestone: ---

The standard mandates that thread_local variables at top level must be
initialized in case anything in the compilation unit is referred to. There is a
specific note on the fact that they must be initialized even if they're not
used in the program.
Also they must be initialized at thread start or before anything from the
compilation unit is accessed by the thread.

This code however shows that g++ doesn't follow this rule

#include 

thread_local int flag = ([](){
printf("HERE!\n");
return 1;
})();

int main() {
printf("Hello, world.\n");
return 0;
}

In this version the thread local initialization is skipped.
Mover if after the printf the statement

flag;

is added then the initialization is performed, but AFTER the "Hello, world"
message (another violation of the standard).

Trying on godbolt I saw the problem is present even in trunk and in clang
(works as expected in MSVC).

The problems are present both on the main implicit thread and with threads
started explicitly with std::thread.

[Bug c++/108286] [GCC 12/13] OpenMP Target directive causes internal compiler error

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108286

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:29c3218618ef6177dc33871b26c8fbd9b21eabe1

commit r13-5006-g29c3218618ef6177dc33871b26c8fbd9b21eabe1
Author: Jakub Jelinek 
Date:   Thu Jan 5 11:57:30 2023 +0100

openmp: Fix up finish_omp_target_clauses [PR108286]

The comment in the loop says that we shouldn't add a map clause if such
a clause exists already, but the loop was actually using OMP_CLAUSE_DECL
on any clause.  Target construct can have various clauses which don't
have OMP_CLAUSE_DECL at all (e.g. nowait, device or if) or clause
where it means something different (e.g. privatization clauses, allocate,
depend).

So, only check OMP_CLAUSE_DECL on OMP_CLAUSE_MAP clauses.

2023-01-05  Jakub Jelinek  

PR c++/108286
* semantics.cc (finish_omp_target_clauses): Ignore clauses other
than
OMP_CLAUSE_MAP.

* testsuite/libgomp.c++/pr108286.C: New test.

[Bug c++/108286] [12 Regression] OpenMP Target directive causes internal compiler error

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108286

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[GCC 12/13] OpenMP Target   |[12 Regression] OpenMP
   |directive causes internal   |Target directive causes
   |compiler error  |internal compiler error

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/104921] aarch64: Assembler failure with vbfmlalbq_lane_f32 intrinsic

[acoplan at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104921

Alex Coplan  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |acoplan at gcc dot 
gnu.org

--- Comment #4 from Alex Coplan  ---
I'll take a look at this

[Bug target/104921] aarch64: Assembler failure with vbfmlalbq_lane_f32 intrinsic

[acoplan at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104921

Alex Coplan  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug bootstrap/108300] New: `abort()` macro cause bootstrap failure on *-w64-mingw32

[lh_mouse at 126 dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300

Bug ID: 108300
   Summary: `abort()` macro cause bootstrap failure on
*-w64-mingw32
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

Recently, mingw-w64 has got updated  from Wine. GCC then ceases to
build:

```
../../gcc/gcc/system.h:791:30: error: expected identifier before string
constant
  791 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
  |  ^~~~
```

The reason is elaborated in this piece of log of #gcc on OFTC:

```
[16:51:28]  on Windows hosts,  now involves ,
which brings a struct that has `abort()` as a member function, so if the macro
above is expanded there it will become nonsense.
[16:52:34]  if GCC does not use that struct (and a plenty more) the
standard way to prevent them from being included is to define
`WIN32_LEAN_AND_MEAN` before inclusion of .  unfortunately, not all
GCC source files do so.
[16:53:31]  there are about thirty to forty files that include
 without defining `WIN32_LEAN_AND_MEAN`.  do you think it is a good
idea to patch them all?
[16:54:11]  this can be generated by an sed command, but it's gonna
be a large patch, touching files that I am not familiar with.
[16:55:03]  or, we can patch mingw-w64 msxml.h to `#undef abort`.
[16:57:22]  can you fixincludes windows.h to add a wrapperr that defines
WIN32_LEAN_AND_MEAN and then include_next windows.h?
[16:58:11]  (that means you do not have to patch the original file ..
you could also use fixincludes to do that too - but it seems maybe more
complicated than the wrapper)
[17:06:14]  .. of course, that does not help if the files are sources
that need to be built by the bootstrap compiler - it’s only going to succeed if
they are all target-libs related.
[17:23:52]  .. hmm but if they are sources in the gcc tree, I’d suppose
that windows.h should not be included directly - but via system.h where you
could place the #define before the inclusion.
[17:34:14]  ugh, the wonders of macros
[17:34:25]  maybe that can be a static inline fn instead?
[17:34:41]  (or even just regular ol inline)
[18:08:19]  yeah, GCC should not #define abort like that, it's
disgusting
[18:08:40]  "but we've always done it like that" - time to stop
```

I create this PR for the record. In my opinion, including  without
`WIN32_LEAN_AND_MEAN` pulls in tons of unnecessary stuff and is almost never
desired. This can be fixed by

```
sed -Ei 's,^( *)#( *)include ,\1#\2define WIN32_LEAN_AND_MEAN
1\n&,'  \
  $(grep --inc "*.[hc]" --inc "*.cc" -Flr "")
```

(Some source files already have it.)

[Bug c/108296] __builtin_memcpy generating wrong code in some cases

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108296

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
The restrictions on __builtin_memcpy are exactly the same as on memcpy, and ISO
C is very clear on: "If copying takes place between objects that overlap, the
behavior
is undefined."

[Bug c/108296] __builtin_memcpy generating wrong code in some cases

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108296

--- Comment #4 from Jakub Jelinek  ---
I think all of the above snippets have UB, whether using memcpy,
__builtin_memcpy or
overlapping structure assignment.  It is all user error.
If you need overlapping copies, always use memmove/__builtin_memmove.

[Bug bootstrap/108300] `abort()` macro cause bootstrap failure on *-w64-mingw32

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-01-05

--- Comment #1 from Jonathan Wakely  ---
(In reply to LIU Hao from comment #0)
>   791 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)

The C++ standard says this is undefined.

We should do something like:

#ifdef __has_builtin
# define HAS_BUILTIN(X) __has_builtin(X)
#else
# define HAS_BUILTIN(X) 0
#endif

namespace gcc {
#if HAS_BUILTIN(__builtin_FILE) && HAS_BUILTIN(__builtin_LINE) \
  && HAS_BUILTIN(__builtin_FUNCTION)
__attribute__((noreturn))
inline void
abort(const char* file = __builtin_FILE(),
  long line = __builtin_LINE(),
  const char* func = __builtin_FUNCTION())
{ fancy_abort(file, line, func); }
#else
__attribute__((noreturn))
inline void
abort()
{ fancy_abort("", 0, ""); }
#endif
}

[Bug c/33053] adopt accesses through a volatile-casted pointer as a GNU C extension

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33053

--- Comment #6 from Segher Boessenkool  ---
(In reply to Daniel Lundin from comment #5)
> This ought to result in stricter optimizing behavior from gcc, not the other
> way around.

Well, GCC did implement this already.  My request was that we should document
this, so that users can depend on this.

> As reported in bug 108298
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298), gcc 11 and beyond
> rather seems to optimize more aggressively, which it didn't up to version
> 10.4.

And that is a bug.  I'll reopen that PR.

[Bug c/108298] Wrong optimization of volatile access from gcc 11 and beyond

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298

Segher Boessenkool  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |---
   Last reconfirmed||2023-01-05
 Status|RESOLVED|NEW
 Ever confirmed|0   |1
 CC||segher at gcc dot gnu.org

--- Comment #2 from Segher Boessenkool  ---
This is not a dup of 33053 (see PR33053#c5 and PR33053#c6).  Reopening, and
confirmed.  There should be a read from memory: that is a side effect, it has
to be executed in the real machine as in the abstract machine.

[Bug c/108298] Wrong optimization of volatile access from gcc 11 and beyond

[daniel.lundin.mail at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298

--- Comment #3 from Daniel Lundin  ---
(In reply to Segher Boessenkool from comment #2)
> This is not a dup of 33053 (see PR33053#c5 and PR33053#c6).  Reopening, and
> confirmed.  There should be a read from memory: that is a side effect, it has
> to be executed in the real machine as in the abstract machine.

This is however very much related to DR476 which is now implemented as per C23.
So conformance to DR476 should be on the C23 TODO-list.

[Bug libstdc++/107784] QOI: sizeof( bind_front( Member-Function ) ) too big

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107784

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Jonathan Wakely  ---
This was fixed in r13-4214-gcbd05ca5ab1231 but I forgot to mention the PR in
the commit.

There's no ABI concern because std::bind_front is a C++20 feature and we
haven't stabilised our C++20 ABI yet. So fixed for GCC 13, but not suitable to
backport because we don't change the ABI within a single release series, even
for unstable C++20 features.

[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Jakub Jelinek  ---
I don't think your claims are based on anything in the standard.
The standard clearly says that it is implementation defined if non-block
thread_local vars are dynamically initialized right away or deferred and
initialized on first non-initialization odr-use.  The latter is what GCC
implements.

[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299

--- Comment #2 from Jakub Jelinek  ---
See https://eel.is/c++draft/basic.start.dynamic#7 for details.

[Bug libstdc++/108265] chrono::hh_mm_ss can't be constructed from unsigned durations

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108265

--- Comment #3 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:

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

commit r12-9030-gebb1f6d14c2fef2e4e4aab30525279524c8f9145
Author: Jonathan Wakely 
Date:   Wed Jan 4 16:43:51 2023 +

libstdc++: Fix std::chrono::hh_mm_ss with unsigned rep [PR108265]

libstdc++-v3/ChangeLog:

PR libstdc++/108265
* include/std/chrono (hh_mm_ss): Do not use chrono::abs if
duration rep is unsigned. Remove incorrect noexcept-specifier.
* testsuite/std/time/hh_mm_ss/1.cc: Check unsigned rep. Check
floating-point representations. Check default construction.

(cherry picked from commit e36e57b032b2d70eaa1294d5921e4fd8ce12a74d)

[Bug libstdc++/108265] chrono::hh_mm_ss can't be constructed from unsigned durations

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108265

--- Comment #4 from Jonathan Wakely  ---
and for 12.3

[Bug libstdc++/108221] Building cross compiler for H8 family fails at libstdc++-v3/src/c++20/tzdb.cc

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221

--- Comment #2 from Jonathan Wakely  ---
This is a pre-existing problem that std::to_chars for floating-point types
doesn't work on these targets. Until I started to use std::format in
std/c++20/tzdb.cc the library wasn't using that, so the missing feature only
caused testsuite failures.

[Bug target/108293] Incorrect assembly emitted for float for BPF target

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108293

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The bug is in bpf_print_operand:
case CONST_DOUBLE:
  if (CONST_DOUBLE_HIGH (op))
fprintf (file, HOST_WIDE_INT_PRINT_DOUBLE_HEX,
 CONST_DOUBLE_HIGH (op), CONST_DOUBLE_LOW (op));
  else if (CONST_DOUBLE_LOW (op) < 0)
fprintf (file, HOST_WIDE_INT_PRINT_HEX, CONST_DOUBLE_LOW (op));
  else
fprintf (file, HOST_WIDE_INT_PRINT_DEC, CONST_DOUBLE_LOW (op));
  break;
Obviously, the above handling is fine only for integral CONST_DOUBLEs, so for
floating point modes one needs to do something that other targets do, like:
  else if (CONST_DOUBLE_P (x) && GET_MODE (x) == SFmode)
{
  long l;

  REAL_VALUE_TO_TARGET_SINGLE (*CONST_DOUBLE_REAL_VALUE (x), l);
  fprintf (file, "0x%08x", (unsigned int) l);
}
for SFmode, or

  else if (CONST_DOUBLE_P (x) && GET_MODE (x) == DFmode)
{
  long l[2];

  REAL_VALUE_TO_TARGET_DOUBLE (*CONST_DOUBLE_REAL_VALUE (x), l);
  fprintf (file, "0x%lx%08lx", l[1] & 0x, l[0] & 0x);
}
for DFmode.

[Bug bootstrap/108300] `abort()` macro cause bootstrap failure on *-w64-mingw32

[lh_mouse at 126 dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300

--- Comment #2 from LIU Hao  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to LIU Hao from comment #0)
> >   791 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
> 
> The C++ standard says this is undefined.
> 
> We should do something like:
> 

I was almost going to submit a patch for mingw-w64 headers. If you think this
can be fixed for GCC 13, that's very kind of you, and please consider
backporting.

[Bug target/108293] Incorrect assembly emitted for float for BPF target

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108293

--- Comment #2 from Jakub Jelinek  ---
Another thing is that at least for all SFmode constant one could use mov
instead of lddw.

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |13.0

--- Comment #1 from Jakub Jelinek  ---
Started with r13-4977-gd0558f420b2a5692fd38ac76ffa97ae6c1726ed9

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-01-05
 Ever confirmed|0   |1

[Bug c/108301] New: GCC Static Analyzer evaluates "__analyzer_eval((!(((0 != b[0]) == p_9) && p_9)))" to be TRUE in the true branch of "if ((((0 != b[0]) == p_9) && p_9))"

[geoffreydgr at icloud dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108301

Bug ID: 108301
   Summary: GCC Static Analyzer evaluates "__analyzer_eval((!(((0
!= b[0]) == p_9) && p_9)))" to be TRUE in the true
branch of "if 0 != b[0]) == p_9) && p_9))"
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: geoffreydgr at icloud dot com
  Target Milestone: ---

Hi, I found a problem that GCC Static Analyzer evaluates two contradictory
expressions to be true at the same time.  

The  two contradictory expressions are "__analyzer_eval(  0 != b[0]) ==
p_9))) && (p_9) );" and "__analyzer_eval(! 0 != b[0]) == p_9))) && (p_9)
);".

https://godbolt.org/z/GYj1oaxqr

Input:
```c
#include 
#include "stdint.h"
void __analyzer_eval(int a) {}

int foo(const int p_9)
{ 
  int a = 8;
  int b[2] ={1,1};

  for (int i = 0; i < 2; i++)
  {
b[i] = 1;
  }

lbl_1710:
  if 0 != b[0]) == p_9) && p_9))
  { 
__analyzer_eval(  0 != b[0]) == p_9))) && (p_9) );
__analyzer_eval(! 0 != b[0]) == p_9))) && (p_9) );

for (a = (1); (a != 2); ++a)
{ 
  if (-1)
  {
goto lbl_1710;
  }
}
  }

  return p_9;
}

int main(){}
```

Output:
```bash
: In function 'foo':
:18:5: warning: TRUE
   18 | __analyzer_eval(  0 != b[0]) == p_9))) && (p_9) );
  | ^
:19:5: warning: TRUE
   19 | __analyzer_eval(! 0 != b[0]) == p_9))) && (p_9) );
  | ^
:18:5: warning: UNKNOWN
   18 | __analyzer_eval(  0 != b[0]) == p_9))) && (p_9) );
  | ^
:19:5: warning: UNKNOWN
   19 | __analyzer_eval(! 0 != b[0]) == p_9))) && (p_9) );
  | ^
Compiler returned: 0

```

[Bug demangler/107884] H8/300: cp-demangle.c fix warning related demangle.h

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107884

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2023-01-05
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug libstdc++/108221] Building cross compiler for H8 family fails at libstdc++-v3/src/c++20/tzdb.cc

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221

--- Comment #3 from Jonathan Wakely  ---
I have a workaround for this, but bootstrap still fails for me at:

/tmp/ccC7KXoL.s: Assembler messages:
/tmp/ccC7KXoL.s:82719: Error: value of 0001254e too large for field of 2 bytes
at 0002
make[6]: *** [Makefile:970: cp-demangle.lo] Error 1

[Bug target/105010] [12/13 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask

[pkubaj at anongoth dot pl via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010

--- Comment #21 from Piotr Kubaj  ---
I'm not sure whether it will help, but the issue only affects building 32-bit
multilib libraries on powerpc64. That is, building a full 32-bit gcc for
powerpc works just fine.

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292

--- Comment #2 from Jakub Jelinek  ---
The assembly difference is
-   movl$1, x+20(%rip)
+   movl$-6, x+20(%rip)
Now, that is the correct value to be stored into x[5] by the
__builtin_sub_overflow (0, 6, &x[5]);
statement, but each element is then shifted right by (element != 0) ? 31 : 0,
so in this case -6U >> 31 aka 1.

[Bug libstdc++/108290] QoI: bind_front captureless lambda is too big

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108290

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Status|NEW |ASSIGNED

[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2023-01-05
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288

--- Comment #1 from Jonathan Wakely  ---
I've tried to reproduce this, but it depends on the addresses of the
_Safe_iterator objects that get created, because they'll use different mutexes
unless their addresses collide in the hash function.

Would you be able to test this patch?

--- a/libstdc++-v3/include/debug/safe_iterator.h
+++ b/libstdc++-v3/include/debug/safe_iterator.h
@@ -761,12 +761,9 @@ namespace __gnu_debug
   _Safe_iterator
   operator++(int) _GLIBCXX_NOEXCEPT
   {
-   _GLIBCXX_DEBUG_VERIFY(this->_M_incrementable(),
- _M_message(__msg_bad_inc)
- ._M_iterator(*this, "this"));
-   __gnu_cxx::__scoped_lock __l(this->_M_get_mutex());
-   return _Safe_iterator(this->base()++, this->_M_sequence,
- _Attach_single());
+   _Safe_iterator __ret = *this;
+   ++*this;
+   return __ret;
   }

   // -- Bidirectional iterator requirements --
@@ -788,12 +785,9 @@ namespace __gnu_debug
   _Safe_iterator
   operator--(int) _GLIBCXX_NOEXCEPT
   {
-   _GLIBCXX_DEBUG_VERIFY(this->_M_decrementable(),
- _M_message(__msg_bad_dec)
- ._M_iterator(*this, "this"));
-   __gnu_cxx::__scoped_lock __l(this->_M_get_mutex());
-   return _Safe_iterator(this->base()--, this->_M_sequence,
- _Attach_single());
+   _Safe_iterator __ret = *this;
+   --*this;
+   return __ret;
   }

   // -- Random access iterator requirements --

[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced

[agriff at tin dot it via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299

--- Comment #3 from Andrea Griffini  ---
Thread storage duration is different from static storage duration.

The text I found on the topic is different from the one you are linking,
but even in this version (that is indeed more permissive) it's explicitly
stated that a thread_local variable must be initialized before any other
thread_local variable is accessed in the same compilation unit.

> it is implementation-defined whether the dynamic initialization of a
> non-block non-inline variable with thread storage duration is sequenced
> before the first statement of the initial function of a thread or is deferred.

> 
> If it is deferred, the initialization associated with the entity for thread
> t is sequenced before the first non-initialization odr-use by t of any
> non-inline variable with thread storage duration defined in the same
> translation unit as the variable to be initialized.
> 

> It is implementation-defined in which threads and at which points in
> the program such deferred dynamic initialization occurs.

g++ doesn't seem to follow the rule


#include 

thread_local int flag = ([](){
printf("HERE!\n"); // This initialization never happens
return 1;
})();

thread_local int flag2;

int main() {
printf("Hello, world.\n");
flag2 = 0; // accesses another thread_local variable in same compilation
unit
return 0;
}

[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
I reproduced it by reducing the size of the mutex pool to one, so they always
collide. And the patch above seems to fix it. I'll test it properly and push.

[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288

--- Comment #3 from Jonathan Wakely  ---
This was my reproducer, although it doesn't deadlock without the hack to use a
single mutex for all objects.

#define _GLIBCXX_DEBUG 1
#include 

int main()
{
  std::vector v{1,2,3};
  auto i = v.begin();
  return *i++;
}

[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299

--- Comment #4 from Jakub Jelinek  ---
flag2 doesn't have dynamic initialization, if you add dynamic initialization to
it, you'll see that flag is constructed before flag2 and that happens before it
is referenced in the current thread (after the printf in main).

[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced

[agriff at tin dot it via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299

--- Comment #5 from Andrea Griffini  ---
So you are saying that the standard forgot to add "that requires dynamic
initialization" and that this is the intention?

[Bug c/108298] Wrong optimization of volatile access from gcc 11 and beyond

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298

--- Comment #4 from Segher Boessenkool  ---
But please use PR33053 for that, or open a new PR?  Let's keep this one
for just this actual bug :-)

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292

Jakub Jelinek  changed:

   What|Removed |Added

 CC||sayle at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
So, we have ix86_expand_int_movcc called with operands:
(reg:SI 170)
(ne (reg:SI 86 [ _14 ])
(const_int 0 [0]))
(const_int 31 [0x1f])
(const_int 0 [0])
and the function emits:
(insn 42 0 43 (set (reg:CC 17 flags)
(compare:CC (reg:SI 86 [ _14 ])
(const_int 1 [0x1]))) "pr108292.c":9:5 -1
 (nil))

(insn 43 42 44 (parallel [
(set (reg:SI 171)
(if_then_else:SI (ltu:SI (reg:CC 17 flags)
(const_int 0 [0]))
(const_int -1 [0x])
(const_int 0 [0])))
(clobber (reg:CC 17 flags))
]) "pr108292.c":9:5 -1
 (expr_list:REG_EQUAL (neg:SI (ne:SI (reg:SI 86 [ _14 ])
(const_int 0 [0])))
(nil)))

(insn 44 43 45 (set (reg:SI 172)
(not:SI (reg:SI 171))) "pr108292.c":9:5 -1
 (nil))

(insn 45 44 46 (parallel [
(set (reg:SI 173)
(and:SI (reg:SI 172)
(const_int 31 [0x1f])))
(clobber (reg:CC 17 flags))
]) "pr108292.c":9:5 -1
 (nil))

(insn 46 45 0 (set (reg:SI 170)
(reg:SI 173)) "pr108292.c":9:5 -1
 (nil))
I believe the REG_EQUAL note is incorrect, it would be correct on insn 44,
pseudo 172 is r86 != 0 ? -1 : 0, while pseudo 171 is r86 == 0 ? -1 : 0.

[Bug target/105010] [12/13 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010

Segher Boessenkool  changed:

   What|Removed |Added

   Last reconfirmed||2023-01-05
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #22 from Segher Boessenkool  ---
(In reply to Piotr Kubaj from comment #21)
> I'm not sure whether it will help, but the issue only affects building
> 32-bit multilib libraries on powerpc64. That is, building a full 32-bit gcc
> for powerpc works just fine.

I can reproduce it with a simple testcase always.  It needs a powerpc64-freebsd
compiler, built with all default options.  With -m32 it still uses the 64-bit
processor, so equivalent to -mcpu=power4.  If you manually use -mcpu=7450 all
works fine.

[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||redi at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
CCing C++ committee members.
Requiring that any odr-uses of thread_local vars which have static
initialization (which strongly happens before any dynamic initialization) would
dynamically initialize all thread_local variables in the same TU declared
before such vars would have serious ABI and performance effects for no useful
gains.

[Bug c++/108302] New: void fn (uint8_t auto... args); leads to internal compiler error: Segmentation fault

[lyubomir.filipov at amusnet dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108302

Bug ID: 108302
   Summary: void fn (uint8_t auto... args);  leads to internal
compiler error: Segmentation fault
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lyubomir.filipov at amusnet dot com
  Target Milestone: ---

Hi
Trying to compile the following code:

#include 

void fn (uint8_t auto... args); 

Leads to internal compiler error:

In file included from /usr/include/stdint.h:37,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/stdint.h:9,
 from /usr/include/c++/12.2.0/cstdint:41,
 from source.cpp:1:
/usr/include/bits/stdint-uintn.h:24:19: internal compiler error: Segmentation
fault
   24 | typedef __uint8_t uint8_t;
  |   ^~~
0x7f1cf4949fcf ???
   
/packages/base/glibc-2.36/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7f1cf49351c9 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f1cf4935284 __libc_start_main_impl
../csu/libc-start.c:381
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.

Yes, I know that uint8_t auto is not supported by the C++ standard, but the
internal compiler error is a bit strange.

I am using Ubuntu 22.04 on 12th Gen Intel(R) Core(TM) i3-12100E

It happens with gcc 12.0, gcc 11.3. It also happens in compiler explorer with
the trunk version of gcc:

https://godbolt.org/z/41fxs18To

As it does happen with compiler explorer too, it looks like it is not related
to my OS or Hardware issue, as the gcc error log suggests.

[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299

--- Comment #7 from Jonathan Wakely  ---
Comment 0 seems wrong to me, there is no requirement that flag is initialized
if not odr-used, and if it is initialized, it doesn't have to happen before the
printf statement.

I agree that the standard says comment 3 should initialized both thread local
variables.

[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299

--- Comment #8 from Jonathan Wakely  ---
FWIW the current wording in the standard was introduced by
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0250r3.html

[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced

[agriff at tin dot it via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299

--- Comment #9 from Andrea Griffini  ---
I agree that comment 0 is wrong and was based on a text that I thought was
taken from the standard but apparently was not (cppreference.com). Sorry for
the noise.

I think that if the dynamic initialization should be tied only to uses of other
thread locals requiring dynamic initialization this should be stated more
precisely in the standard text.

[Bug ipa/108130] [13 Regression] LTO compile time hog seen on bootstrap-lto config since r13-4684-g7450b25566b7a7

[jamborm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108130

Martin Jambor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Martin Jambor  ---
This has been fixed by Honza's r13-4998-gedc038863d88ef

posted in https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609406.html

If the undefined reference problem persists, it is a different issue.

[Bug libstdc++/108212] [13 Regression] pretty printers don't work with Python 2 due to imports for chrono

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108212

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:80ff207da6d8784e227eb93f75c4ac5a300c8420

commit r13-5034-g80ff207da6d8784e227eb93f75c4ac5a300c8420
Author: Jonathan Wakely 
Date:   Thu Jan 5 13:41:21 2023 +

libstdc++: Fix  printers for Python 2 [PR108212]

The datetime.timezone.utc singleton doesn't exist in Python 2, but we
can create it ourselves by deriving from datetime.tzinfo.

libstdc++-v3/ChangeLog:

PR libstdc++/108212
* python/libstdcxx/v6/printers.py (_utc_timezone): New global
variable.
(StdChronoTimePointPrinter::to_string): Use it.

[Bug libstdc++/108290] QoI: bind_front captureless lambda is too big

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108290

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r13-5033-ge2eab3c4edb6aa9a93f982c4554cd756000934ca
Author: Jonathan Wakely 
Date:   Thu Jan 5 11:35:35 2023 +

libstdc++: Reduce size of std::bind_front(empty_type) result [PR108290]

libstdc++-v3/ChangeLog:

PR libstdc++/108290
* include/std/functional (_Bind_front): Add no_unique_address
attribute to data members.
* testsuite/20_util/function_objects/bind_front/107784.cc: Check
size of call wrappers with empty types for targets and bound
arguments.

[Bug libstdc++/108290] QoI: bind_front captureless lambda is too big

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108290

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jonathan Wakely  ---
Done for GCC 13. Not suitable for backports.

Thanks for the report.

[Bug libstdc++/108212] [13 Regression] pretty printers don't work with Python 2 due to imports for chrono

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108212

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #2 from Jonathan Wakely  ---
Fixed.

[Bug target/103784] suboptimal code for returning bool value on target ppc

[jskumari at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784

--- Comment #8 from Surya Kumari Jangala  ---
Using -O3 with gcc13, I got (with the test in comment 2):

For P8:
cmpwi 0,3,2
bgt 0,.L3
subfic 4,4,9
srdi 3,4,63
xori 3,3,0x1
rldicl 3,3,0,63
blr
.p2align 4,,15
.L3:
li 3,0
rldicl 3,3,0,63
blr


For P10:
cmpwi 0,3,2
bgt 0,.L3
cmpwi 0,4,9
setbcr 3,1
rldicl 3,3,0,63
blr
.p2align 4,,15
.L3:
li 3,0
rldicl 3,3,0,63
blr

[Bug target/108293] Incorrect assembly emitted for float for BPF target

[jemarch at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108293

--- Comment #3 from Jose E. Marchesi  ---
(In reply to Jakub Jelinek from comment #2)
> Another thing is that at least for all SFmode constant one could use mov
> instead of lddw.

For this I guess we could expand the "I" constraint to cover const_double that
fits in the 32-bit range.  But then we would need something like IN_RANGE that
works with const_double.

[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=znver3 since r13-4685-g4834e9360f7bf4

[jamborm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110

--- Comment #16 from Martin Jambor  ---
I have posted the sorting patch to the mailing list:

https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609459.html

[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11

[simon.marchi at polymtl dot ca via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288

--- Comment #4 from Simon Marchi  ---
Thanks for looking into this so quickly.  I'll try to test the patch against my
use case, but I might need some guidance.  I know how to build gcc and install
it in some non-default prefix.  But then, do I need to do something special
when building my program, to ensure that this libstdc++.so will be used,
instead of the system one?  Just set LD_LIBRARY_PATH appropriately, like for
any other lib?

[Bug modula2/107631] many tests don't link on Mac OS X 10.7

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107631

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:4413365616e8c6024d1ff4e23309e5012ee33b9f

commit r13-5035-g4413365616e8c6024d1ff4e23309e5012ee33b9f
Author: Iain Sandoe 
Date:   Wed Jan 4 21:03:24 2023 +

modula-2: Remove uses of scalb*() and significand*() [PR107631]

The scalb*() functions are obsolete in Posix from 2004 and removed in
2008.

The significand*() functions are glibc-only and considered there to be
obsolescent (not supported for types such as _Float128).

We can remove them from Modula-2 since they are not required for ISO
support, but we need to provide an implementation of significand* for
the "fraction()" functions.

PR modula2/107631

gcc/m2/ChangeLog:

* gm2-gcc/m2builtins.cc: Remove scalb, scalbf, scalbl,
significand, significandf, significandl.
* gm2-libs/Builtins.def (significand): Likewise.
* gm2-libs/Builtins.mod: Likewise.
* target-independent/Builtins.texi: Likewise.
* gm2-libs-iso/LowLong.mod: Implement fraction with scalbn*() and
ilogb*().
* gm2-libs-iso/LowReal.mod: Likewise.
* gm2-libs-iso/LowShort.mod: Likewise.

[Bug modula2/107631] many tests don't link on Mac OS X 10.7

[iains at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107631

Iain Sandoe  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #5 from Iain Sandoe  ---
now that we have resolved the visibility of the module registration CTORs and
eliminated uses of scalb*() and significand*() this is fixed.

[Bug modula2/108182] gm2 driver mishandles target and multilib options

[iains at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182

--- Comment #5 from Iain Sandoe  ---
(In reply to Gaius Mulley from comment #4)
> Created attachment 54184 [details]
> Potential fix for target multilib_dir handling -m and -f.
> 
> Work in progress.

1. (I think) the string you need is "multilib_os_dir" not "multilib_dir" (but
ICBW about that .. there are many twisty passages in the determination of these
things).

2. The concern remains that the language spec handler is run pretty much first
in the stack and there are several other claims on the command line that could
have specs that alter (or add) flags to the command line, giving a different
outcome to the computation of mulilib_{,os_}dir.

perhaps it would be a good idea to post this and ask the opinion of someone
like Joseph on the direction.

[Bug c/108298] Wrong optimization of volatile access from gcc 11 and beyond

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298

--- Comment #5 from Segher Boessenkool  ---
This is not x86-specific.  Like on powerpc64 we get

addi 3,3,3   # 11   [c=4 l=4]  *addsi3/1
extsw 3,3# 17   [c=4 l=4]  extendsidi2/1
blr  # 25   [c=4 l=4]  simple_return

Before RTL all is fine still:

int foo (int a, int b, int c)
{
  int _1;
  int _2;

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  _1 = a_3(D) + 1;
  b = _1;
  _2 ={v} MEM[(volatile int *)&b];
  a_6 = _2 + 2;
  return a_6;
;;succ:   EXIT

}

But it is expanded to something that is not going through memory:

;; _2 ={v} MEM[(volatile int *)&b];

(insn 10 9 0 (set (reg:SI 118 [ _2 ])
(subreg/s/u:SI (reg/v:DI 121 [ b+-4 ]) 4)) "108298.c":10:9 -1
 (nil))

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[roger at nextmovesoftware dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292

Roger Sayle  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com
 CC||roger at nextmovesoftware dot 
com
 Status|NEW |ASSIGNED

--- Comment #4 from Roger Sayle  ---
Doh! Apologies for the inconvenience.  I'll have a fix soon.

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292

--- Comment #5 from Jakub Jelinek  ---
Though, it seems the REG_EQUAL note is also wrong on the cmov10.c testcase
which went with the commit (again, exact opposite).

Seems we have multiple cases where this REG_EQUAL note is newly added.
One is x != 0 ? -1 : y, negate_cc_compare_p is true and code overridden to EQ
and ct/cf swapped.
So, the note is then (neg (eq x const0_rtx)).
Another one is x == 0 ? y : -1, negate_cc_compare_p is true, code, ct and cf
unchanged.
The note is then (neg (eq x const0_rtx)) too.
The sequence emitted for both of these cases is neg{l,q} x; sbb{l,q} tmp, tmp,
which sets tmp to 0 if x == 0 and to -1 if x != 0.  So the right note would be
IMNSHO
(neg (ne x const0_rtx)) for both of the above cases.
Another case is the sign_bit_compare_p case, which happens for (signed)
x >= 0 ? y : z
x < 0 ? y : z
x > -1 ? y : z
x <= -1 ? y : z
The code handling those cases is:
  if (code == GT || code == GE)
code = reverse_condition (code);
  else
{
  std::swap (ct, cf);
  diff = ct - cf;
}
  tmp = emit_store_flag (tmp, code, op0, op1, VOIDmode, 0, -1);
In that case emit_store_flag sets tmp to (code op0 op1) ? -1 : 0 so I think
(neg (code op0 op1)) is the right REG_EQUAL note for it.
The last case is when ix86_expand_carry_flag_compare returns true.
This is when LTU/GEU comparisons are used or something which can be turned into
one,
e.g. x == 0 or x != 0 turned into x < 1U or x >= 1U.

Now, the code below the addition of the new REG_EQUAL note assumes that the
comparison
set tmp to 0 if true and to -1 if false (which can be seen e.g. from diff == 1
&& ct == 0 case not adding any further instructions).  So the REG_EQUAL note
should be IMHO
gen_rtx_NEG (mode, gen_rtx_fmt_ee (reverse_condition (code), mode, op0, op1))
rather than gen_rtx_NEG (mode, gen_rtx_fmt_ee (code, mode, op0, op1))
for the cases where std::swap (ct, cf); has not been done (with the original
code, not the adjusted one).  For the sign_bit_compare_p case that matches the
above analysis that
it is handled correctly, as we reverse_condition iff swap isn't done.
For the negate_cc_compare_p case I think it matches the analysis too that it is
always wrong and should be always NE.

[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288

--- Comment #5 from Jonathan Wakely  ---
The patch doesn't change libstdc++.so, it only changes the headers.

You don't even need to rebuild GCC. You could just put a patched copy of
safe_iterator.h in /tmp/x/debug and then compile with -I/tmp/x so it finds the
patched header.

[Bug c++/108303] New: lookup failes with requires clause on non-template friend function of a class template

[ted at lyncon dot se via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108303

Bug ID: 108303
   Summary: lookup failes with requires clause on non-template
friend function of a class template
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ted at lyncon dot se
  Target Milestone: ---

This works up to 12.2 (inclusive) on godbolt but fails on trunk:
```
template 
struct base {
friend void foo(const Derived& d)
requires requires { bar(d); } // removing this makes it work
{
bar(d);
}
};

namespace adl {
struct S : base {
friend void bar(const S&) {}
};
}  // namespace adl

void test(adl::S const& s) {
foo(s);  // error: 'foo' was not declared in this scope
}
```

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292

--- Comment #6 from Jakub Jelinek  ---
So I wonder about:
--- gcc/config/i386/i386-expand.cc.jj   2023-01-04 10:45:49.978883731 +0100
+++ gcc/config/i386/i386-expand.cc  2023-01-05 18:22:40.228518935 +0100
@@ -3271,10 +3271,12 @@ ix86_expand_int_movcc (rtx operands[])
{
  negate_cc_compare_p = true;
  std::swap (ct, cf);
- code = EQ;
}
  else if (code == EQ && op1 == const0_rtx && cf == -1)
-   negate_cc_compare_p = true;
+   {
+ negate_cc_compare_p = true;
+ code = NE;
+   }
}

   diff = ct - cf;
@@ -3319,11 +3321,7 @@ ix86_expand_int_movcc (rtx operands[])

  /* To simplify rest of code, restrict to the GEU case.  */
  if (compare_code == LTU)
-   {
- std::swap (ct, cf);
- compare_code = reverse_condition (compare_code);
- code = reverse_condition (code);
-   }
+   std::swap (ct, cf);
  else
{
  if (fpcmp)
@@ -,6 +3331,10 @@ ix86_expand_int_movcc (rtx operands[])
  else
PUT_CODE (compare_op,
  reverse_condition (GET_CODE (compare_op)));
+ if (SCALAR_FLOAT_MODE_P (GET_MODE (op0)))
+   code = reverse_condition_maybe_unordered (code);
+ else
+   code = reverse_condition (code);
}
  diff = ct - cf;

but am not very sure about that, especially the floating point stuff, e.g.
whether
for -ffast-math it shouldn't actually be reverse_condition (and not add any
REG_EQUAL note if code is UNKNOWN?).

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292

--- Comment #7 from Jakub Jelinek  ---
Or for now don't add any REG_EQUAL note if op0 has scalar floating point
mode...

[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11

[simon.marchi at polymtl dot ca via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288

--- Comment #6 from Simon Marchi  ---
Because some code trying to acquire the lock (see frame #7 in my backtrace) is
in debug.cc, I thought it would maybe need to be changed too?  But I don't
really understand any of this.

[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288

--- Comment #7 from Jonathan Wakely  ---
__gnu_debug::_Safe_iterator_base::_M_detach in debug.cc isn't affected by the
patch though.

The fix is to the post-inc and post-dec members, so only the code that calls
those needs to be recompiled.

[Bug c++/108303] lookup failes with requires clause on non-template friend function of a class template

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108303

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
Started to be rejected with r13-4035

c++: only declare satisfied friends

A friend declaration can only have constraints if it is defined.  If
multiple instantiations of a class template define the same friend function
signature, it's an error, but that shouldn't happen if it's constrained to
only be declared in one instantiation.

Currently we don't mangle requirements, so the foos all mangle the same and
actually instantiating #1 will break, but for now we can test that they're
considered distinct.

[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11

[simon.marchi at polymtl dot ca via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288

--- Comment #8 from Simon Marchi  ---
I tested with just patching my /usr/include, and it looks like it works fine,
I'm able to run a program under my GDB.  Removing the fix, I get back the hang.

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[roger at nextmovesoftware dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292

--- Comment #8 from Roger Sayle  ---
Created attachment 54195
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54195&action=edit
Roger's proposed patch

Here's my proposed patch (or something close to it, it's still bootstrapping
and regression testing).  The goal is to capture the original comparison (at
the top of the BB), and avoid/ignore the actual comparison that we may have
converted to.
Sorry again to the inconvenience.  Please let me know what you think.

[Bug libstdc++/108304] New: FAIL: 20_util/from_chars/4.cc execution test

[danglin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108304

Bug ID: 108304
   Summary: FAIL: 20_util/from_chars/4.cc execution test
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/./gcc/xg++ -shared-libgcc
-B/ho
me/dave/gnu/gcc/objdir64/./gcc -nostdinc++
-L/home/dave/gnu/gcc/objdir64/hppa64-
hp-hpux11.11/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/
libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc
++-v3/libsupc++/.libs -B/opt/gnu64/gcc/gcc-13/hppa64-hp-hpux11.11/bin/
-B/opt/gn
u64/gcc/gcc-13/hppa64-hp-hpux11.11/lib/ -isystem
/opt/gnu64/gcc/gcc-13/hppa64-hp
-hpux11.11/include -isystem
/opt/gnu64/gcc/gcc-13/hppa64-hp-hpux11.11/sys-includ
e -fchecking=1
-B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/
src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections
-fdata-section
s -O2 -g -DLOCALEDIR="." -nostdinc++
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpu
x11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/hp
pa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/lib
supc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/g
cc/gcc/libstdc++-v3/testsuite/util
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite
/20_util/from_chars/4.cc -include bits/stdc++.h -fdiagnostics-plain-output
./lib
testc++.a -lm -o ./4.exe
PASS: 20_util/from_chars/4.cc (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/dave/gnu/gcc/objdir64/gcc:/home/dave/gnu/gcc/o
bjdir64/hppa64-hp-hpux11.11/./libstdc++-v3/../libatomic/.libs:/home/dave/gnu/gcc
/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/../libgomp/.libs:/home/dave/gnu/gcc
/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs::/home/dave/gnu/gcc/objdi
r64/gcc:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/../libato
mic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/../libg
omp/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.li
bs::/home/dave/gnu/gcc/objdir64/gcc:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11
.11/./libstdc++-v3/../libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux
11.11/./libstdc++-v3/../libgomp/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux
11.11/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/.
/libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs::/home/dave/gnu/gcc/objdir64/gcc:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/../libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/../libgomp/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs
Execution timeout is: 300
spawn [open ...]
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/from_chars/4.cc:325: void
test_max_mantissa() [with FloatT = long double; UIntT = __int128 unsigned]:
Assertion 'flt == val' failed.
FAIL: 20_util/from_chars/4.cc execution test

Similar fails:

/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/from_chars/8.cc:311: void
test_max_mantissa() [with FloatT = _Float128; UIntT = __int128 unsigned]:
Assert
ion 'flt == val' failed.
FAIL: 20_util/from_chars/8.cc execution test

/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
:79: void test(std::chars_format): Assertion 'ec4 == std::errc() && ptr4 ==
ptr1
' failed.
FAIL: 20_util/to_chars/float128_c++23.cc execution test

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[roger at nextmovesoftware dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292

--- Comment #9 from Roger Sayle  ---
Another way to avoid the SCALAR_FLOAT_MODE_P problem is:
  /* Add a REG_EQUAL note to allow condition to be shared.  */
  rtx note = gen_rtx_fmt_ee (orig_code, mode, op0, op1);
  /* TMP is (orig_code op0 op1) ? 0 : -1, or swapped.  */
  note = orig_swapped ? gen_rtx_NEG (mode, node)
  : gen_rtx_PLUS (mode, note, constm1_rtx);
  set_unique_reg_note (get_last_insn (), REG_EQUAL, note);

i.e. don't attempt to modify the initial comparison; instead tweak the note.

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292

--- Comment #10 from Jakub Jelinek  ---
(In reply to Roger Sayle from comment #8)
> Created attachment 54195 [details]
> Roger's proposed patch
> 
> Here's my proposed patch (or something close to it, it's still bootstrapping
> and regression testing).  The goal is to capture the original comparison (at
> the top of the BB), and avoid/ignore the actual comparison that we may have
> converted to.
> Sorry again to the inconvenience.  Please let me know what you think.

I don't like that much (of course, Uros is the maintainer so his call).
But, I think we should avoid bundling the code generation changes (the dropping
of ct or cf checks for negate_cc_compare_p; if that is a win, it should be
proven separately but it isn't clear if it is) and the patch just causes
further dead variables which the current code already has many.
What is the point of orig_code when code is already dead except for this newly
added REG_EQUAL note?  Why can't just code contain it?
As for the floating point stuff, yes, the - 1 would be an option, but perhaps
should be used only if we need to reverse floating point comparison?
If we introduce a bool for swap_ct_cf, then it seems pointless to also actually
swap ct/cf and recompute diff in all the spots, just set swap_ct_cf and
swap/recompute diff only if the bool is set and we need to look at ct/cf/diff.

[Bug c++/108275] pointer to member field is not checked for accessibility inside a template argument

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108275

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:12b0d35ec52375da5652d2b8da74083ab700b9d7

commit r13-5037-g12b0d35ec52375da5652d2b8da74083ab700b9d7
Author: Patrick Palka 
Date:   Thu Jan 5 14:21:34 2023 -0500

c++: class-head parsing and CPP_TEMPLATE_ID access [PR108275]

When tentatively parsing what is really an elaborated-type-specifier
containing a template-id first as a class-specifier, we may form a
CPP_TEMPLATE_ID token that later gets reused by the fallback parse if
the tentative parse fails.  These special tokens also capture the access
checks that have been deferred while parsing the template-id.  But here
we form such a token when the access check state is dk_no_check, and so
the token captures no access checks.  This effectively bypasses access
checking for the template-id during the subsequent parse as an
elaborated-type-specifier.

This patch fixes this by using dk_deferred instead of dk_no_check when
parsing the class name of a class-head.

PR c++/108275

gcc/cp/ChangeLog:

* parser.cc (cp_parser_class_head): Use dk_deferred instead of
dk_no_check when parsing the class name.

gcc/testsuite/ChangeLog:

* g++.dg/parse/access14.C: New test.

[Bug libbacktrace/108297] libtool link b2test fails: Unrecognized argument: --build-id

[ian at airs dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #1 from Ian Lance Taylor  ---
Does HP/UX 11.11 use ELF?  If so, I guess we need a configure test to see
whether the linker supports the --build-id option.  If it doesn't, I guess we
need to skip the debuginfo tests.

[Bug c++/108275] pointer to member field is not checked for accessibility inside a template argument

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108275

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Target Milestone|--- |13.0
 Resolution|--- |FIXED
 CC||ppalka at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 13

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[ubizjak at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292

--- Comment #11 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to Roger Sayle from comment #8)
> > Here's my proposed patch (or something close to it, it's still bootstrapping
> > and regression testing).  The goal is to capture the original comparison (at
> > the top of the BB), and avoid/ignore the actual comparison that we may have
> > converted to.
> > Sorry again to the inconvenience.  Please let me know what you think.

The fix is not a simple patch, and it looks to me that the original patch has
several rough edges. I propose to revert the original patch at this stage of
development and retry with it at the next stage 1.