[Bug target/99422] New: [11 Regression] ICE in extract_constrain_insn building glibc pthread_create

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

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

Bug ID: 99422
   Summary: [11 Regression] ICE in extract_constrain_insn building
glibc pthread_create
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: vmakarov at gcc dot gnu.org
  Target Milestone: ---
Target: i686-*-linux-gnu

Created attachment 50314
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50314&action=edit
preprocessed source

Commit 9105757a59b890194ebf5b4fcbacd58db34ef332 ("[PR99378] LRA: Skip
decomposing address for asm insn operand with unknown constraint.") introduced
the following ICE building glibc for i686-linux-gnu. Tested with an x86_64
compiler; compile the attached .i file with the following options: -m32
-march=i686 -O2 -pg -S

In file included from pthread_create.c:59:
allocatestack.c: In function '__nptl_setxid':
allocatestack.c:1173:1: error: unrecognizable insn:
(insn 103 534 535 21 (parallel [
(set (mem/v:SI (plus:SI (mem/f/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int 8 [0x8])) [85 cmdp+0 S4 A32])
(const_int 16 [0x10])) [5 cmdp_52(D)->cntr+0 S4 A32])
(asm_operands/v:SI ("lock;incl %0") ("=m") 0 [
(mem/v:SI (plus:SI (reg:SI 0 ax [208])
(const_int 16 [0x10])) [5 cmdp_52(D)->cntr+0 S4
A32])
(const_int 12 [0xc])
]
 [
(asm_input:SI ("m") allocatestack.c:1036)
(asm_input:SI ("i") allocatestack.c:1036)
]
 [] allocatestack.c:1036))
(clobber (reg:CC 17 flags))
]) "allocatestack.c":1036:47 -1
 (nil))
during RTL pass: reload
allocatestack.c:1173:1: internal compiler error: in extract_constrain_insn, at
recog.c:2670
0x63ae76 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/scratch/jmyers/glibc/many11/src/gcc/gcc/rtl-error.c:108
0x63ae92 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/scratch/jmyers/glibc/many11/src/gcc/gcc/rtl-error.c:116
0xd1149d extract_constrain_insn(rtx_insn*)
/scratch/jmyers/glibc/many11/src/gcc/gcc/recog.c:2670
0xbec6a7 check_rtl
/scratch/jmyers/glibc/many11/src/gcc/gcc/lra.c:2087
0xbf14ac lra(_IO_FILE*)
/scratch/jmyers/glibc/many11/src/gcc/gcc/lra.c:2505
0xba1489 do_reload
/scratch/jmyers/glibc/many11/src/gcc/gcc/ira.c:5827
0xba1489 execute
/scratch/jmyers/glibc/many11/src/gcc/gcc/ira.c:6013
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/100184] Detect variables which are only "used" in updating themselves

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

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #1 from Joseph S. Myers  ---
See bug 44677.

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

[Bug c/44677] Warn for variables incremented but not used

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||eyalroz1 at gmx dot com

--- Comment #11 from Joseph S. Myers  ---
*** Bug 100184 has been marked as a duplicate of this bug. ***

[Bug preprocessor/97602] New: #line overflow check incomplete

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

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

Bug ID: 97602
   Summary: #line overflow check incomplete
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

Preprocessing the following test with -pedantic does not produce a diagnostic,
just silent wrapping of the line number.

#line 50

By comparison, if you instead have

#line 30

then you get a diagnostic

t.c:1:7: warning: line number out of range
1 | #line 30
  |   ^~

The code in directives.c:strtolinenum tries to check for overflow after it
occurs, with logic "if (reg < reg_prev)" that doesn't cover all cases. 
Checking before it occurs (allowing properly for the case of UINT_MAX / 10
where overflow depends on the value of the next digit) is needed instead.

[Bug preprocessor/97604] New: Bad digit separators accepted in pp-numbers

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

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

Bug ID: 97604
   Summary: Bad digit separators accepted in pp-numbers
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: emsr at gcc dot gnu.org
  Target Milestone: ---

cpplib lexes pp-numbers in lex_number.  Following bug 64626 that includes some
logic to disallow a pp-number ending with C++ digit separators.  However, that
logic is insufficient to cover all cases where the lexing includes too many
characters in the pp-number.

Compile the following with -std=c++17:

int a = 0x0'e-0xe;

This gives a bogus error:

t.cc:1:9: error: unable to find numeric literal operator 'operator""-0xe'
1 | int a = 0x0'e-0xe;
  | ^
t.cc:1:9: note: use '-fext-numeric-literals' to enable more built-in suffixes

The pp-number syntax starts a pp-number with "digit" or ". digit" and then
allows various things to follow, one of which is "' nondigit" and another one
of which is "e sign".  The longest possible preprocessing token starting with
the first 0 in the above example is 0x0'e because the text preceding "e-" ends
with "'" and so is not a pp-number.  So 0x0'e is a preprocessing token,
followed by "-", and the above is in fact a subtraction of two separate integer
literals, i.e. valid C++ input.

"'" must only be accepted in a pp-number when followed by a digit or nondigit,
and if that nondigit is e, E, p or P, it terminates the pp-number if a sign
follows.  Although I haven't given examples here, you can probably construct
rejects-valid examples (ones involving macro expansion, at least) also for the
case of wrongly accepting a digit separator followed by a UCN / UTF-8 character
(an identifier-nondigit that is not a nondigit) or '.'.  The case of
consecutive digit separators shouldn't introduce rejects-valid bugs because ''
isn't valid at the start of a preprocessing token, but bug 83873 would be fixed
by following the syntax in lex_number and rejecting them there rather than
trying to catch them later.

[Bug libgcc/97635] New: binary-to-DFP conversions incorrect

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

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

Bug ID: 97635
   Summary: binary-to-DFP conversions incorrect
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

On targets using DPD decimal floating point (tested for powerpc64le-linux-gnu,
presumably applies on s390 as well), the libgcc conversions from binary
floating point to decimal floating point, using sprintf, are not correctly
rounded.  IEEE 754 requires such conversions to be correctly rounded (using the
decimal rounding mode, not the binary rounding mode), with corresponding
exceptions (and the lowest possible decimal quantum exponent if the result is
inexact, the quantum exponent as close to 0 as possible if the result is
exact).

sprintf is used with BFP_FMT, where BFP_FMT is set to use a precision depending
on the source format.  However, that precision is the solution to a different
problem: what precision is sufficient for (to-nearest) conversion from that
binary format to decimal and back to produce the same binary value (i.e. the
precisions are the values of FLT_DECIMAL_DIG, DBL_DECIMAL_DIG, etc.).  The
problem here isn't converting to decimal and back, it's converting correctly to
a given decimal format, where exactly one value in that format is a correct
result, and other values that round back to the same binary value are
incorrect.

For example, the test below, which fails for powerpc64le-linux-gnu, does a
conversion from float to _Decimal64.  Unsurprisingly, a 9-digit decimal value
from sprintf is not sufficient for a correctly rounded 16-digit _Decimal64
value.  Using the precision of the *target* type, not the source type, would
mostly work if sprintf is correctly rounding, except that the result needs to
be rounded according to the decimal rounding mode and sprintf for a binary
input rounds according to the binary rounding mode (and the case of "to
nearest, ties away from 0" doesn't have a corresponding binary mode, even if
you restrict attention to the IEEE decimal modes and ignore the other ones
supported on Power hardware), and also there would be problems with double
rounding and missing underflow exceptions when the result is in the subnormal
range for the decimal format (there could be problems with decimal quantum
exponents as well).

extern void abort (void);
extern void exit (int);

float f = 0.1f;

_Decimal64 d = 0.100014901161DD;
_Decimal64 dd = (_Decimal64) 0.1f;

int
main (void)
{
  /* Compile-time conversion is correct.  */
  if (dd != d)
abort ();
  /* Run-time conversion is incorrect.  */
  if ((_Decimal64) f != d)
abort ();
  exit (0);
}

[Bug libgcc/97635] binary-to-DFP conversions incorrect

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

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

--- Comment #1 from Joseph S. Myers  ---
With some analysis of the worst cases (for every possible pair of source and
target exponents) using continued fractions, it would also be possible to
determine a single precision value that is always correct for any given pair of
formats, so that computing a string to that precision will produce a correct
result and exceptions regardless of the binary and decimal rounding modes,
without any special handling of subnormals being needed.  Heuristically, that
would be roughly the precision of the decimal format that's the target of the
conversion, plus log to base 10 of the number of different values in the source
format.

[Bug target/97683] New: [11 Regression] nios2 assembler branch offset errors building glibc

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

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

Bug ID: 97683
   Summary: [11 Regression] nios2 assembler branch offset errors
building glibc
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: assemble-failure
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: cltang at gcc dot gnu.org, sandra at gcc dot gnu.org
  Target Milestone: ---
Target: nios2-*-*

Created attachment 49489
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49489&action=edit
preprocessed source

Building glibc for nios2-linux-gnu produces a long series of errors of the
form:

/tmp/ccwdG18R.s: Assembler messages:
/tmp/ccwdG18R.s:4291: Error: branch offset 38052 out of range -32768 to 32767

Compile the attached preprocessed source with: -c -fpic -g -O2 (note, -g is for
some reason required for the errors to appear).

I don't know quite when this appeared because the glibc build with GCC mainline
was broken for a while with architecture-independent issues.

[Bug c/97882] [8/9/10/11 Regression] Segmentation Fault on improper redeclaration of function

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

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

Joseph S. Myers  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-17
   Target Milestone|--- |8.5
 Status|UNCONFIRMED |NEW
Summary|Segmentation Fault on   |[8/9/10/11 Regression]
   |improper redeclaration of   |Segmentation Fault on
   |function|improper redeclaration of
   ||function
 Ever confirmed|0   |1

--- Comment #1 from Joseph S. Myers  ---
Looks like a regression in GCC 7 relative to GCC 6.  Whether this code is valid
or invalid GNU C is a tricky question, but I'm inclined to say that when the
incomplete enum type extension is used, we should *not* count such enums as
compatible with unsigned int since we don't know what members the enum will
have once completed.  So, for example, I think we ought to reject

extern enum foo *x;
unsigned int *x;

and certainly ought to reject

extern enum foo *x;
unsigned int *x;
enum foo { A = -1 };

where the enum ends up compatible with int rather than unsigned int.  (But a
patch involving rejecting such code might not be such a good idea for
backporting, given the risk of breaking user programs that build OK with the
release branch compilers.)

(A C11 defect fix incorporated in C17 means a qualifier on a function return
type is ignored, so whether the code is valid is not affected by the "const" in
the original test case.)

[Bug c/95630] rejects-valid on comparison of pointers to complete vs incomplete types in C11 mode

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |11.0

--- Comment #2 from Joseph S. Myers  ---
Fixed for GCC 11.

[Bug preprocessor/97602] #line overflow check incomplete

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Joseph S. Myers  ---
Fixed for GCC 11.

[Bug preprocessor/82359] #line does not allow C++14 quotes in number

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |12.0

--- Comment #5 from Joseph S. Myers  ---
Fixed for GCC 12.

[Bug c/100353] [11/12 Regression] Accepts invalid label

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Joseph S. Myers  ---
C2x feature, not a bug.

[Bug c++/83873] adjacent digit separators are accepted in the exponent-part of floating-point literals

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |12.0
 Status|NEW |RESOLVED

--- Comment #3 from Joseph S. Myers  ---
Fixed for GCC 12.

[Bug preprocessor/97604] Bad digit separators accepted in pp-numbers

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |12.0

--- Comment #2 from Joseph S. Myers  ---
Fixed for GCC 12.

[Bug c/100792] ICE: gimplify_expr, at gimplify.c:14879

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

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

Joseph S. Myers  changed:

   What|Removed |Added

Version|tree-ssa|12.0
 Status|RESOLVED|UNCONFIRMED
 Resolution|WONTFIX |---

--- Comment #2 from Joseph S. Myers  ---
The compiler should not ICE for any input.

[Bug middle-end/101170] New: [12 Regression] ICE in df_ref_record building libgomp for ColdFire

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

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

Bug ID: 101170
   Summary: [12 Regression] ICE in df_ref_record building libgomp
for ColdFire
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---
Target: m68k-linux-gnu

Created attachment 51051
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51051&action=edit
preprocessed source

Commit 7232f7c4c2d727431096a7ecfcf4ad4db71dcf2a ("expand: empty class return
optimization [PR88529]") introduces an ICE building libgomp for m68k-linux-gnu
(configure --with-arch=cf --disable-multilib).  Compile the attached test with
-g -O2 (the -g is required):

during RTL pass: reload
/scratch/jmyers/glibc/many12/src/gcc/libgomp/ordered.c: In function
'GOMP_doacross_ull_wait':
/scratch/jmyers/glibc/many12/src/gcc/libgomp/ordered.c:827:1: internal compiler
error: in df_ref_record, at df-scan.c:2598
  827 | }
  | ^
0x851ce2 df_ref_record
/scratch/jmyers/glibc/many12/src/gcc/gcc/df-scan.c:2598
0x8524bb df_uses_record
/scratch/jmyers/glibc/many12/src/gcc/gcc/df-scan.c:2859
0x852c78 df_insn_refs_collect
/scratch/jmyers/glibc/many12/src/gcc/gcc/df-scan.c:3213
0x8560fe df_bb_refs_record(int, bool)
/scratch/jmyers/glibc/many12/src/gcc/gcc/df-scan.c:3339
0x856674 df_scan_blocks()
/scratch/jmyers/glibc/many12/src/gcc/gcc/df-scan.c:588
0xabbc1d do_reload
/scratch/jmyers/glibc/many12/src/gcc/gcc/ira.c:5886
0xabbc1d execute
/scratch/jmyers/glibc/many12/src/gcc/gcc/ira.c:6008
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

https://sourceware.org/pipermail/libc-testresults/2021q2/008114.html

[Bug c/101212] forward declaration of parameter

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

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #1 from Joseph S. Myers  ---
See the first example in bug 23144.

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

[Bug c/23144] [9/10/11/12 Regression] invalid parameter forward declarations not diagnosed

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #27 from Joseph S. Myers  ---
*** Bug 101212 has been marked as a duplicate of this bug. ***

[Bug c/108375] New: [10/11/12/13 Regression] Some variably modified types not detected as such

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

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

Bug ID: 108375
   Summary: [10/11/12/13 Regression] Some variably modified types
not detected as such
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

variably_modified_type_p fails to detect an array type as variably modified if
the array and its element type are of constant size but the element type is
variably modified. For example, the following code should be diagnosed as
invalid, but is not (similar rejects-valid or wrong-code examples could no
doubt be constructed as well).

void
f (int a)
{
  typedef int A[a];
  goto x;
  A *p[2];
  x : ;
}

This is a regression in 4.2 and later relative to older versions, I think
introduced by g:2e3b8fe7b5405a94d86bfa323c0e80e83c58d784 .

commit 2e3b8fe7b5405a94d86bfa323c0e80e83c58d784
Author: Eric Botcazou 
Date:   Wed May 17 13:11:09 2006 +

tree.c (variably_modified_type_p): Return true if the element type is
variably modified without recursing.

* tree.c (variably_modified_type_p) : Return true
if the element type is variably modified without recursing.

From-SVN: r113858

[Bug target/108484] New: [13 Regression] ICE building glibc for ia64 in cselib_subst_to_values, at cselib.cc:2148

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

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

Bug ID: 108484
   Summary: [13 Regression] ICE building glibc for ia64 in
cselib_subst_to_values, at cselib.cc:2148
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---
Target: ia64*-*-*

Created attachment 54319
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54319&action=edit
preprocessed source

Compile the attached file (from glibc) with -g -O2 for ia64-linux-gnu. This
produces the following ICE:

during RTL pass: mach
In file included from ../sysdeps/ia64/unwind-resume.c:18:
../sysdeps/generic/unwind-resume.c: In function '_Unwind_Resume':
../sysdeps/generic/unwind-resume.c:38:1: internal compiler error: in
cselib_subst_to_values, at cselib.cc:2148
0x5fd409 cselib_subst_to_values(rtx_def*, machine_mode)
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2148
0x98c873 cselib_subst_to_values(rtx_def*, machine_mode)
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2193
0x98f761 cselib_subst_to_values_from_insn(rtx_def*, machine_mode, rtx_insn*)
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2264
0x18172aa add_insn_mem_dependence
/scratch/jmyers/glibc/many13/src/gcc/gcc/sched-deps.cc:1741
0x181b230 sched_analyze_2
/scratch/jmyers/glibc/many13/src/gcc/gcc/sched-deps.cc:2688
0x181b267 sched_analyze_2
/scratch/jmyers/glibc/many13/src/gcc/gcc/sched-deps.cc:2806
0x181b9eb sched_analyze_insn
/scratch/jmyers/glibc/many13/src/gcc/gcc/sched-deps.cc:2960
0x181ddb0 deps_analyze_insn(deps_desc*, rtx_insn*)
/scratch/jmyers/glibc/many13/src/gcc/gcc/sched-deps.cc:3683
0x181e40e sched_analyze(deps_desc*, rtx_insn*, rtx_insn*)
/scratch/jmyers/glibc/many13/src/gcc/gcc/sched-deps.cc:3836
0x1821870 schedule_ebb(rtx_insn*, rtx_insn*, bool)
/scratch/jmyers/glibc/many13/src/gcc/gcc/sched-ebb.cc:505
0x1821da2 schedule_ebbs()
/scratch/jmyers/glibc/many13/src/gcc/gcc/sched-ebb.cc:655
0x11b3346 ia64_reorg
/scratch/jmyers/glibc/many13/src/gcc/gcc/config/ia64/ia64.cc:9862
0xdb527d execute
/scratch/jmyers/glibc/many13/src/gcc/gcc/reorg.cc:3927
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

Introduced by g:3c99493bf39a7fef9213e6f5af94b78bb15fcfdc

commit 3c99493bf39a7fef9213e6f5af94b78bb15fcfdc
Author: Alexandre Oliva 
Date:   Thu Jan 19 01:09:15 2023 -0300

[PR106746] drop cselib addr lookup in debug insn mem

The testcase used to get scheduled differently depending on the
presence of debug insns with MEMs.  It's not clear to me why those
MEMs affected scheduling, but the cselib pre-canonicalization of the
MEM address is not used at all when analyzing debug insns, so the
memory allocation and lookup are pure waste.  Somehow, avoiding that
waste fixes the problem, or makes it go latent.


for  gcc/ChangeLog

PR debug/106746
* sched-deps.cc (sched_analyze_2): Skip cselib address lookup
within debug insns.

for  gcc/testsuite/ChangeLog

PR debug/106746
* gcc.target/i386/pr106746.c: New.

[Bug debug/106746] [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks since r13-2041-g6624ad73064de241

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

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

--- Comment #22 from Joseph S. Myers  ---
The fix introduced a regression building glibc for ia64-linux-gnu, see bug
108484.

[Bug target/103370] [12/13 Regression] Assembler error building glibc for ColdFire soft-float

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

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

--- Comment #9 from Joseph S. Myers  ---
The glibc build failure has done away and come back at least once since my
previous comment. It came back (I think the most recent time) with

commit 4fa25a7eb322f0a003c1eb15680c71ece345e01e
Author: Martin Liska 
AuthorDate: Mon Jan 24 15:45:38 2022 +0100
Commit: Martin Liska 
CommitDate: Wed Nov 30 14:03:43 2022 +0100

Improve profile handling in switch lowering.

PR tree-optimization/101301
PR tree-optimization/103680

though that's almost surely just exposing a back-end bug. However, the reduced
test here gave a different assembler error

/tmp/cc40cNSh.s: Assembler messages:
/tmp/cc40cNSh.s:320: Error: syntax error -- statement `lea
(.LC0@GOT+3,%a5),%a0' ignored
/tmp/cc40cNSh.s:328: Error: syntax error -- statement `lea
(.LC1@GOT+3,%a5),%a2' ignored

both before and after that commit (different register numbers and .s line
numbers before versus after). Despite the different error messages from the
reduced test and building glibc, they are still likely to be the same bug in
the m68k back end.

[Bug target/106282] [10/11/12/13 Regression] m68k: Problem with thread-local storage and -mcpu=5206 since r9-2326-gede9446c26a929

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

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

Joseph S. Myers  changed:

   What|Removed |Added

   Target Milestone|--- |10.5
Summary|m68k: Problem with  |[10/11/12/13 Regression]
   |thread-local storage and|m68k: Problem with
   |-mcpu=5206 since|thread-local storage and
   |r9-2326-gede9446c26a929 |-mcpu=5206 since
   ||r9-2326-gede9446c26a929
 CC||jsm28 at gcc dot gnu.org

--- Comment #2 from Joseph S. Myers  ---
My glibc bot has been failing for ColdFire since some time between commits
79d38dd46e6b07e5a90ab25df1438eb0918eb475 and
f56d48b2471c388401174029324e1f4c4b84fcdb, with an assembler error building
libgomp (affinity-fmt.c) that looks just like the one in this bug.

affinity-fmt.s: Assembler messages:
affinity-fmt.s:4062: Error: syntax error -- statement `lea
(gomp_tls_data@TLSLE+8,%a0),%a0' ignored

https://sourceware.org/pipermail/libc-testresults/2022q4/010394.html

Although that's from October 2022, I expect it's the same underlying issue, and
just was latent building libgomp until some other change exposed it there.

Note: soft-float ColdFire now fails earlier in my bot, failing to build glibc
with bug 103370 (also an assembler error, also probably latent for some time
before being exposed by an unrelated change).

[Bug target/104829] [12 Regression] Pure 32-bit PowerPC build broken

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

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

--- Comment #8 from Joseph S. Myers  ---
Created attachment 52597
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52597&action=edit
preprocessed source

Preprocessed source attached.

[Bug target/104829] [12 Regression] Pure 32-bit PowerPC build broken

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

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

--- Comment #9 from Joseph S. Myers  ---
Created attachment 52598
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52598&action=edit
generated assembly

Assembly output attached.

[Bug c/105180] [9/10/11/12 Regression] K&R style definition does not evaluate array size

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

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

Joseph S. Myers  changed:

   What|Removed |Added

Summary|K&R style definition does   |[9/10/11/12 Regression] K&R
   |not evaluate array size |style definition does not
   ||evaluate array size
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |9.5
 Ever confirmed|0   |1
   Last reconfirmed||2022-04-21

[Bug preprocessor/105412] New: [10/11/12 Regression] Missing phony target with -MP for first include when compiling from stdin

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

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

Bug ID: 105412
   Summary: [10/11/12 Regression] Missing phony target with -MP
for first include when compiling from stdin
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

When generating dependencies with -M -MP, the phony target for the first
included header (typically stdc-predef.h) is missing if compiling from stdin,
with GCC 10 and later but not with GCC 9.  For example:

$ echo "#include " |
./many9/install/compilers/x86_64-linux-gnu/bin/x86_64-glibc-linux-gnu-g++ -M
-MP -x c++ - | grep stdc-predef

/scratch/jmyers/glibc/many9/install/compilers/x86_64-linux-gnu/sysroot/usr/include/stdc-predef.h
\
/scratch/jmyers/glibc/many9/install/compilers/x86_64-linux-gnu/sysroot/usr/include/stdc-predef.h:

shows the expected phony target (the second line of output) with a GCC 9
compiler, but

$ echo "#include " |
./many10/install/compilers/x86_64-linux-gnu/bin/x86_64-glibc-linux-gnu-g++ -M
-MP -x c++ - | grep stdc-predef

/scratch/jmyers/glibc/many10/install/compilers/x86_64-linux-gnu/sysroot/usr/include/stdc-predef.h
\

shows that line of output is missing with GCC 10 and later.

(This example is adapted from code in glibc's configure script, but the bug
only actually causes problems with glibc when the compiler is used with an old
sysroot lacking stdc-predef.h and so the missing phony target is that for
 itself.)

[Bug c++/106646] [C++23] P2437R1 - Support for #warning

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

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

--- Comment #1 from Joseph S. Myers  ---
Enabled for C2x (i.e. stopped -pedantic diagnosing it) with commit
d7c3000147c1d8090f66a2baf4623d2c0dfe8eb6 - C++ will presumably want to adjust
the diagnostics as well as enabling for relevant C++ versions and adding
associated tests.

[Bug target/103370] [12/13 Regression] Assembler error building glibc for ColdFire soft-float

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

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

--- Comment #8 from Joseph S. Myers  ---
This build failure has come back on GCC mainline, some time between commit
3cab897a67af120aa18efa7ddd7ee49b9a29e5dd and
7f5ec900e53f6c7f7c06c641b4fb303ebdc83785.

[Bug c/21343] [10/11/12/13 Regression] incompatible internal linkage declarations in different scopes not diagnosed

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||pavel.morozkin at gmail dot com

--- Comment #25 from Joseph S. Myers  ---
*** Bug 106797 has been marked as a duplicate of this bug. ***

[Bug c/106797] Improvement: diagnose undefined behavior: not all declarations that refer to the same object or function have compatible type

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

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #1 from Joseph S. Myers  ---
See bug 21343.

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

[Bug c++/107080] New: ICE in verify_symtab_nodes using _Float64x with long double

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

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

Bug ID: 107080
   Summary: ICE in verify_symtab_nodes using _Float64x with long
double
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-* i?86-* ia64-*

Compiling the following C++ test for x86_64 (or i686 or ia64) produces an ICE,
no optimization or other options required (presumably introduced by the _FloatN
/ _FloatNx support for C++).


template struct S;

template<> struct S
{
  static int call (long double x, long double y) throw ()
  {
return 3;
  }
};

template<> struct S<_Float64x>
{
  static int call (_Float64x x, _Float64x y) throw ()
  {
return 3;
  }
};

template
inline int
g (T1 x, T2 y) throw ()
{
  typedef decltype (x + y) T3;
  return S::call (x, y);
}

int
f ()
{
  return g (0.0f64x, 0.0f64x) + g (0.0f64x, 0.0L);
}



t.cc:31:1: error: Two symbols with same comdat_group are not linked by the
same_comdat_group list.
   31 | }
  | ^
_Z1gIeeEiT_T0_/4 (int g(T1, T2) [with T1 = _Float64x; T2 = long double])
  Type: function definition analyzed
  Visibility: semantic_interposition no_reorder public weak comdat
comdat_group:_Z1gIeeEiT_T0_ one_only
  previous sharing asm name: 3
  References: __gxx_personality_v0/5 (addr) 
  Referring: 
  Function flags: body
  Called by: _Z1fv/2 
  Calls: _ZN1SIeE4callEee/1 
_Z1gIeeEiT_T0_/3 (int g(T1, T2) [with T1 = _Float64x; T2 = _Float64x])
  Type: function definition analyzed
  Visibility: semantic_interposition no_reorder public weak comdat
comdat_group:_Z1gIeeEiT_T0_ one_only
  next sharing asm name: 4
  References: __gxx_personality_v0/5 (addr) 
  Referring: 
  Function flags: body
  Called by: _Z1fv/2 
  Calls: _ZN1SIeE4callEee/1 
t.cc:31:1: internal compiler error: symtab_node::verify failed
0xc9ba69 symtab_node::verify_symtab_nodes()
/scratch/jmyers/glibc/many13/src/gcc/gcc/symtab.cc:1410
0xcb4ab3 symtab_node::checking_verify_symtab_nodes()
/scratch/jmyers/glibc/many13/src/gcc/gcc/cgraph.h:682
0xcb4ab3 symbol_table::compile()
/scratch/jmyers/glibc/many13/src/gcc/gcc/cgraphunit.cc:2264
0xcb80cd symbol_table::compile()
/scratch/jmyers/glibc/many13/src/gcc/gcc/cgraphunit.cc:2261
0xcb80cd symbol_table::finalize_compilation_unit()
/scratch/jmyers/glibc/many13/src/gcc/gcc/cgraphunit.cc:2529
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/107088] New: [13 Regression] cselib ICE building __trunctfxf2 on ia64

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

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

Bug ID: 107088
   Summary: [13 Regression] cselib ICE building __trunctfxf2 on
ia64
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: stefansf at linux dot ibm.com
  Target Milestone: ---
Target: ia64-*-*

Created attachment 53641
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53641&action=edit
preprocessed source

commit d0b00b63a39108311f2e6f9cbe9072579f57df7c, "cselib: Keep track of further
subvalue relations", introduced an ICE building libgcc for ia64-linux-gnu.
Compile with attached testcase with -O2.

/scratch/jmyers/glibc/many13/src/gcc/libgcc/soft-fp/trunctfxf2.c: In function
'__trunctfxf2':
/scratch/jmyers/glibc/many13/src/gcc/libgcc/soft-fp/trunctfxf2.c:52:1: internal
compiler error: in require, at machmode.h:297
   52 | }
  | ^
0x876576 opt_mode::require() const
/scratch/jmyers/glibc/many13/src/gcc/gcc/machmode.h:297
0x876576 void mode_iterator::get_known_wider(scalar_int_mode*)
/scratch/jmyers/glibc/many13/src/gcc/gcc/machmode.h:1124
0x876576 new_cselib_val
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:1579
0x873e4e cselib_lookup_1
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2315
0x873e4e cselib_lookup(rtx_def*, machine_mode, int, machine_mode)
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2431
0x876aff cselib_hash_rtx
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:1308
0x876e69 cselib_hash_rtx
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:1505
0x873c5f cselib_lookup_1
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2375
0x873c5f cselib_lookup(rtx_def*, machine_mode, int, machine_mode)
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2431
0x877a6a cselib_record_sets
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2932
0x87867d cselib_process_insn(rtx_insn*)
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:3159
0x1661d1c dse_step1
/scratch/jmyers/glibc/many13/src/gcc/gcc/dse.cc:2771
0x1661d1c rest_of_handle_dse
/scratch/jmyers/glibc/many13/src/gcc/gcc/dse.cc:3687
0x1661d1c execute
/scratch/jmyers/glibc/many13/src/gcc/gcc/dse.cc:3803
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/36113] fix C enumerators

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

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

Joseph S. Myers  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #8 from Joseph S. Myers  ---
Fixed for GCC 13.  (Where unsigned long is 64-bit, GCC may choose that instead
of unsigned long long for the underlying type of the enum, so you'll get a
format checking warning in that case, but all the enum constants now have the
enum type if any of them don't fit in int, in accordance with C2X.)

[Bug c/107164] No pedantic warning for declaration just referring to a previously-declared enum type

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

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

Joseph S. Myers  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Joseph S. Myers  ---
Fixed for GCC 13.

[Bug c/107314] [13 Regression] New -Wsign-compare since r13-3360-g3b3083a598ca3f4b

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Joseph S. Myers  ---
Closing this bug, since the new behavior is as intended.

[Bug preprocessor/104147] [9/10/11/12 Regression] C preprocessor may remove the standard required whitespace between the preprocessing tokens

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

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

Joseph S. Myers  changed:

   What|Removed |Added

  Known to fail||3.2.3
  Known to work||3.0.4
   Target Milestone|--- |9.5
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-01-20
 Ever confirmed|0   |1
Summary|C preprocessor may remove   |[9/10/11/12 Regression] C
   |the standard required   |preprocessor may remove the
   |whitespace between the  |standard required
   |preprocessing tokens|whitespace between the
   ||preprocessing tokens

--- Comment #1 from Joseph S. Myers  ---
This appears to be a regression between GCC 3.0 and 3.2.

[Bug c/103031] [12 Regression] Missing static initializer folding with -frounding-math

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

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #4 from Joseph S. Myers  ---
Fixed for GCC 12.

[Bug target/103370] New: [12 Regression] Assembler error building glibc for ColdFire soft-float

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

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

Bug ID: 103370
   Summary: [12 Regression] Assembler error building glibc for
ColdFire soft-float
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: assemble-failure
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: m68k*-*-*

Created attachment 51849
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51849&action=edit
preprocessed source

Compile and assemble the attached preprocessed source (from glibc) with -O2
-fPIC -c, using a compiler configured for m68k-linux-gnu --with-arch=cf
--with-cpu=54455 --disable-multilib (this is m68k-linux-gnu-coldfire-soft in
build-many-glibcs.py).  This produces an assembler error:

/tmp/cctaeK7A.s: Assembler messages:
/tmp/cctaeK7A.s: Fatal error: Tried to convert PC relative branch to absolute
jump

This appeared with

commit 045206450386bcd774db3bde0c696828402361c6
Author: Richard Biener 
Date:   Fri Nov 12 10:21:22 2021 +0100

tree-optimization/102880 - improve CD-DCE

though I'm guessing it was most likely to have been latent before then.

[Bug target/103370] [12 Regression] Assembler error building glibc for ColdFire soft-float

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

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

--- Comment #4 from Joseph S. Myers  ---
It seems this glibc build failure disappeared between commit
b880d1514c1e3dd75a6ea311a5cc956742bd713c and commit
8e836af61b7027c0819da62c12a8d18b7c46f3fc.  (Not verified that the GCC change
was what's relevant - my bot updated other components as well - but it looks
plausible.)

[Bug c++/19992] -fhosted/-ffreestanding for C++

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

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

Joseph S. Myers  changed:

   What|Removed |Added

  Known to fail||4.2.0
   Target Milestone|--- |4.3.0
  Known to work||4.3.0
 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Joseph S. Myers  ---
Fixed for GCC 4.3 by:

Author: Dirk Mueller 
Date:   Fri May 4 00:46:02 2007 +

c.opt (Wmain,ffreestanding): Enable for C++,ObjC++.

2007-05-04  Dirk Mueller  

* c.opt(Wmain,ffreestanding): Enable for C++,ObjC++.

* cp-tree.h (DECL_MAIN_P): only if -ffreestanding is
not in effect.

From-SVN: r124404

[Bug target/103722] New: [12 Regression] ICE in extract_constrain_insn building glibc for SH4

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

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

Bug ID: 103722
   Summary: [12 Regression] ICE in extract_constrain_insn building
glibc for SH4
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: vmakarov at gcc dot gnu.org
  Target Milestone: ---
Target: sh4*-*-*

Created attachment 52003
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52003&action=edit
preprocessed source

Build the attached code (from glibc) with -O2 for sh4-linux-gnu.  This produces
an ICE:

malloc-debug.c: In function '__debug_realloc':
malloc-debug.c:267:1: error: insn does not satisfy its constraints:
(insn 955 1863 2 2 (set (reg:SI 76 fr12 [314])
(reg:SI 146 pr)) 189 {movsi_ie}
 (nil))
during RTL pass: postreload
malloc-debug.c:267:1: internal compiler error: in extract_constrain_insn, at
recog.c:2670
0x5eec04 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/scratch/jmyers/glibc/many12/src/gcc/gcc/rtl-error.c:108
0x5eec2a _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/scratch/jmyers/glibc/many12/src/gcc/gcc/rtl-error.c:119
0xcab367 extract_constrain_insn(rtx_insn*)
/scratch/jmyers/glibc/many12/src/gcc/gcc/recog.c:2670
0xc71acd reload_cse_simplify_operands
/scratch/jmyers/glibc/many12/src/gcc/gcc/postreload.c:407
0xc732bc reload_cse_simplify
/scratch/jmyers/glibc/many12/src/gcc/gcc/postreload.c:190
0xc732bc reload_cse_regs_1
/scratch/jmyers/glibc/many12/src/gcc/gcc/postreload.c:238
0xc7584b reload_cse_regs
/scratch/jmyers/glibc/many12/src/gcc/gcc/postreload.c:66
0xc7584b execute
/scratch/jmyers/glibc/many12/src/gcc/gcc/postreload.c:2355
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

This was introduced (exposed?) by:

commit a7acb6dca941db2b1c135107dac3a34a20650d5c
Author: Vladimir N. Makarov 
Date:   Mon Dec 13 13:48:12 2021 -0500

[PR99531] Modify pseudo class cost calculation when processing move
involving the pseudo and a hard register

[Bug middle-end/102133] New: [12 Regression] ICE in set_rtl building libgcc __muldc3 for 32-bit SPARC

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

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

Bug ID: 102133
   Summary: [12 Regression] ICE in set_rtl building libgcc
__muldc3 for 32-bit SPARC
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: liuhongt at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-*-*

Created attachment 51380
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51380&action=edit
preprocessed source

commit 7218c2ec365ce95f5a1012a6eb425b0a36aec6bf, "Make sure we're playing with
integral modes before call extract_integral_bit_field.", introduces the
following ICE building libgcc for 32-bit SPARC (32-bit multilib for
sparc64-linux-gnu). Compile the attached test with -m32 -O2.

during RTL pass: expand
/scratch/jmyers/glibc/many12/src/gcc/libgcc/libgcc2.c: In function '__muldc3':
/scratch/jmyers/glibc/many12/src/gcc/libgcc/libgcc2.c:1947:1: internal compiler
error: in set_rtl, at cfgexpand.c:200
 1947 | CONCAT3(__mul,MODE,3) (MTYPE a, MTYPE b, MTYPE c, MTYPE d)
  | ^~~~
0x7ccbe9 set_rtl
/scratch/jmyers/glibc/many12/src/gcc/gcc/cfgexpand.c:179
0x7cf028 set_parm_rtl(tree_node*, rtx_def*)
/scratch/jmyers/glibc/many12/src/gcc/gcc/cfgexpand.c:1401
0x98a451 assign_parm_setup_reg
/scratch/jmyers/glibc/many12/src/gcc/gcc/function.c:3401
0x98a451 assign_parms
/scratch/jmyers/glibc/many12/src/gcc/gcc/function.c:3707
0x98de2c expand_function_start(tree_node*)
/scratch/jmyers/glibc/many12/src/gcc/gcc/function.c:5163
0x7e11b9 execute
/scratch/jmyers/glibc/many12/src/gcc/gcc/cfgexpand.c:6692
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/102127] [12 Regression] ICE when compiling (m32) powerpc/440-mulchw-1.c since g:ff6bb9dde10ab665a35bb75527313cd9f7d52f8e

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #8 from Joseph S. Myers  ---
This is probably the bug causing an ICE building GCC for soft-float powerpc
that showed up in my glibc bot.

https://sourceware.org/pipermail/libc-testresults/2021q3/008465.html

[Bug middle-end/102630] New: [12 Regression] Spurious -Warray-bounds with named address space

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

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

Bug ID: 102630
   Summary: [12 Regression] Spurious -Warray-bounds with named
address space
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*

Created attachment 51560
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51560&action=edit
preprocessed source

This is the issue breaking building glibc for x86_64 with current mainline GCC
(since July), as previously discussed in threads starting at
https://gcc.gnu.org/pipermail/gcc/2021-July/236922.html and
https://gcc.gnu.org/pipermail/gcc/2021-July/236933.html (discussion continues
into August).

Compile the attached file with -O2 -Wall -Werror and get the errors:

loadmsgcat.c: In function '_nl_load_domain':
loadmsgcat.c:770:22: error: array subscript 0 is outside array bounds of
'__seg_fs struct pthread * __seg_fs[0]' [-Werror=array-bounds]

As discussed in the previous discussions, the code generating this
-Warray-bounds warning needs to check targetm.addr_space.zero_address_valid to
determine whether zero or small constant addresses are valid in the given
address space (there's already a suitable definition of that hook for x86, but
the warning is failing to check it).

[Bug c/102821] Tentative definition of variable with internal linkage has incomplete non-array type: missing diagnostics

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #3 from Joseph S. Myers  ---
This is in a Semantics section of the standard, not Constraints, so no
diagnostic is required, but as a quality-of-implementation matter we should
diagnose it.

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

[Bug c/88727] Diagnostics improvement: Detection of undefined behaviour. Incomplete type in tenative definition with internal linkage. [-Wtentative-definition-incomplete-type]

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||pavel.morozkin at gmail dot com

--- Comment #3 from Joseph S. Myers  ---
*** Bug 102821 has been marked as a duplicate of this bug. ***

[Bug middle-end/103031] New: [12 Regression] Missing static initializer folding with -frounding-math

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

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

Bug ID: 103031
   Summary: [12 Regression] Missing static initializer folding
with -frounding-math
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

One of the recent fixes to avoid inappropriate constant folding with
-frounding-math caused the following test to produce an error when building
with -frounding-math.  Static initializers in C are evaluated at translation
time, in the default rounding mode and with exceptions discarded;
-frounding-math should not affect this.  Indeed, fold-const.c has
START_FOLD_INIT and END_FOLD_INIT that are supposed to be used for static
initializer folding to implement this, but apparently aren't being effective in
this case.

Test case:

double x = -1ULL;

Errors:

t.c:1:12: error: initializer element is not computable at load time
1 | double x = -1ULL;
  |^

Note: if the initializer is cast to double, things work fine; it's only the
case of implicit conversion that has the problem, so maybe something is handled
differently for folding an implicit conversion of a static initializer.

This breaks building glibc tests for some platforms:
https://sourceware.org/pipermail/libc-alpha/2021-October/132475.html

[Bug c/61469] language feature: Support for enum underlying type

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

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #10 from Joseph S. Myers  ---
I'm working on implementing this C2x feature for GCC 13.

[Bug c/61469] language feature: Support for enum underlying type

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |13.0

--- Comment #12 from Joseph S. Myers  ---
Implemented for GCC 13.

[Bug c++/107148] [10/11/12/13 Regression] ICE in bot_manip, at cp/tree.cc:3252

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #2 from Joseph S. Myers  ---
The following test produces the same ICE without any prior errors. I'm not sure
if a statement expression should be considered valid in this context, or if
that indicates that an earlier error is needed. Compile this test with
-fimplicit-constexpr (thus, needs GCC 12 or later, so this test does not show a
regression, unlike the ICE-on-invalid regression in the original bug report).

int f(int);
class A {
public:
  A(int);
};
class C {
  C() : m(f(({ int x = 1; x; }))) {}
  A m;
};

Alternatively, not needing -fimplicit-constexpr (rejected by GCC 10 and before;
GCC 11 and later ICE; so again not showing a regression):

int f(int);
class A {
public:
  A(int);
};
class C {
  constexpr C() : m(f(({ int x = 1; x; }))) {}
  A m;
};

The failing assertion is

  gcc_assert (VAR_P (*p) && DECL_ARTIFICIAL (*p) && !TREE_STATIC (*p));

where *p is the variable x in the statement expression, so fails
DECL_ARTIFICIAL. If this test is valid, I don't know if it should reach the
code with this assertion (or what additional issues might arise if the variable
in the statement expression were declared static).

[Bug libgcc/105669] DFP to HF (_Float16) conversions use incorrect rounding

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

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

Joseph S. Myers  changed:

   What|Removed |Added

   Last reconfirmed||2022-05-20
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Joseph S. Myers  ---
Example test illustrating this bug, at least on x86_64 (the DFP input is very
close to half way between two consecutive _Float16 values):

extern void exit (int);
extern void abort (void);
#define DCONST 7.340312e-5DF
static const _Float16 f1 = DCONST;
volatile _Decimal32 d = DCONST;
int
main (void)
{
  volatile _Float16 f2;
  f2 = d;
  if (f1 == f2)
exit (0);
  else
abort ();
}

[Bug libstdc++/105671] [11/12/13 Regression] Unexplained "undefined reference" error

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

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

Joseph S. Myers  changed:

   What|Removed |Added

Summary|Unexplained "undefined  |[11/12/13 Regression]
   |reference" error|Unexplained "undefined
   ||reference" error
 CC||jsm28 at gcc dot gnu.org
  Component|c++ |libstdc++
   Target Milestone|--- |11.4

--- Comment #2 from Joseph S. Myers  ---
I'm seeing the same undefined reference on a customer test case. I haven't
reduced it to a self-contained test case either, but as far as I can see this
is a libstdc++ issue (rather than a front-end or LTO bug). _M_high_mark (which
is new in libstdc++ in GCC 11) isn't exported from libstdc++.so (it's present
in libstdc++.a), presumably because the symbol version maps don't include it,
so if the compiler decides to inline one of the functions from the header that
calls _M_high_mark, without inlining _M_high_mark itself, there is an undefined
reference to _M_high_mark. (This selective inlining is what I haven't
reproduced in a self-contained test, even when adjusting various inlining
parameters, but it would explain the undefined reference.)

[Bug middle-end/105866] New: [13 Regression] ICE in emit_move_insn building glibc for MIPS

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

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

Bug ID: 105866
   Summary: [13 Regression] ICE in emit_move_insn building glibc
for MIPS
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: roger at nextmovesoftware dot com
  Target Milestone: ---
Target: mips*-*-*

Created attachment 53093
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53093&action=edit
preprocessed source

Commit ed6fd2aed58f2cca99f15331bf68999c0e6df370, "PR middle-end/95126: Expand
small const structs as immediate constants.", introduces an ICE for the
attached test case (from glibc) on mips64-linux-gnu. Compile with: -mabi=n32
-O2

during RTL pass: expand
key_call.c: In function 'key_gendes':
key_call.c:224:12: internal compiler error: in emit_move_insn, at expr.cc:4012
0x95754f emit_move_insn(rtx_def*, rtx_def*)
/scratch/jmyers/glibc/many13/src/gcc/gcc/expr.cc:4011
0x7eb57e load_register_parameters
/scratch/jmyers/glibc/many13/src/gcc/gcc/calls.cc:2192
0x7f31ad expand_call(tree_node*, rtx_def*, int)
/scratch/jmyers/glibc/many13/src/gcc/gcc/calls.cc:3594
0x951d45 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/scratch/jmyers/glibc/many13/src/gcc/gcc/expr.cc:11621
0x95ee95 store_expr(tree_node*, rtx_def*, int, bool, bool)
/scratch/jmyers/glibc/many13/src/gcc/gcc/expr.cc:6106
0x960a47 expand_assignment(tree_node*, tree_node*, bool)
/scratch/jmyers/glibc/many13/src/gcc/gcc/expr.cc:5835
0x80e7ae expand_call_stmt
/scratch/jmyers/glibc/many13/src/gcc/gcc/cfgexpand.cc:2829
0x80e7ae expand_gimple_stmt_1
/scratch/jmyers/glibc/many13/src/gcc/gcc/cfgexpand.cc:3869
0x80e7ae expand_gimple_stmt
/scratch/jmyers/glibc/many13/src/gcc/gcc/cfgexpand.cc:4033
0x815a22 expand_gimple_basic_block
/scratch/jmyers/glibc/many13/src/gcc/gcc/cfgexpand.cc:6085
0x8180d2 execute
/scratch/jmyers/glibc/many13/src/gcc/gcc/cfgexpand.cc:6811
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/105866] [13 Regression] ICE in emit_move_insn building glibc for MIPS

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

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

Joseph S. Myers  changed:

   What|Removed |Added

Version|12.0|13.0
   Target Milestone|--- |13.0

[Bug middle-end/105866] [13 Regression] ICE in emit_move_insn building glibc for MIPS

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

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #3 from Joseph S. Myers  ---
Yes, it's now working again.

https://sourceware.org/pipermail/libc-testresults/2022q2/009793.html

[Bug lto/106129] New: [12/13 Regression] LTO option merging broken

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

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

Bug ID: 106129
   Summary: [12/13 Regression] LTO option merging broken
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

The LTO merging of options from different input files was broken by:

commit 227a2ecf663d69972b851f51f1934d18927b62cd
Author: Martin Liska 
Date:   Fri Mar 12 11:53:47 2021 +0100

lto-wrapper: Use vec data type.

Previously, find_and_merge_options would merge options it read into those in
*opts. After this commit, options in *opts on entry to find_and_merge_options
are ignored; the only merging that takes place is between multiple sets of
options in the same input file that are read in the same call to this function
(not sure how that case can occur at all). The effects include, for example,
that if some objects are built with PIC enabled and others with it disabled,
and the last LTO object processed has PIC enabled, the choice of PIC for the
last object will result in the whole program being built as PIC, when the
merging logic is intended to ensure that a mixture of PIC and non-PIC objects
results in the whole program being built as non-PIC.

I'm testing a patch for this bug.

[Bug lto/106129] [12 Regression] LTO option merging broken

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

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

Joseph S. Myers  changed:

   What|Removed |Added

   Last reconfirmed||2022-06-30
 Ever confirmed|0   |1
Summary|[12/13 Regression] LTO  |[12 Regression] LTO option
   |option merging broken   |merging broken
 Status|UNCONFIRMED |NEW

--- Comment #2 from Joseph S. Myers  ---
Fixed so far for GCC 13.

[Bug target/103722] [12 Regression] ICE in extract_constrain_insn building glibc for SH4

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

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #8 from Joseph S. Myers  ---
Now also applied to GCC 12 branch, so fixed for GCC 12.2.

[Bug c/113455] ROUNDING: IEEE Standard: Missing decimal rounding mode 'nearest, ties away from zero' for decimalxxx datatypes.

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

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

--- Comment #6 from Joseph S. Myers  ---
-frounding-math is only relevant for arithmetic that occurs as-if at runtime in
the abstract machine. Conversion of constants to their type (or a type with
excess range and precision as indicated by DEC_EVAL_METHOD, but (a) that
doesn't apply here and (b) none of the excess precision support in GCC is
hooked up for decimal floating point, I think) occurs at translation time, not
at runtime, so is never affected by -frounding-math or fe_dec_setround (and GCC
doesn't implement the FENV_DEC_ROUND pragma to set a constant rounding mode in
a particular scope).

[Bug c/113776] [14 regression] postgresql-16.1 build failure with -Werror=vla in configure test since r14-8641

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jsm28 at gcc dot gnu.org
   Last reconfirmed||2024-02-07
 Ever confirmed|0   |1

--- Comment #3 from Joseph S. Myers  ---
Testing a patch.

[Bug c/113776] [14 regression] postgresql-16.1 build failure with -Werror=vla in configure test since r14-8641

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

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #5 from Joseph S. Myers  ---
Fixed for GCC 14.

[Bug c/113825] missing warning for omitted parameter names in function definitions (c23 extension)

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Joseph S. Myers  ---
This is diagnosed as expected with -pedantic (given a standard older than C23)
or -Wc11-c23-compat (even in C23 mode); I see no reason for this to be
different from any other extension that doesn't affect the semantics of code
valid in an older standard version.

[Bug c/113887] no support for %w128 length modifiers

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

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

--- Comment #2 from Joseph S. Myers  ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643237.html has my notes
on things that need supporting, in ,  and by implication
in printf and scanf, to support __int128 as an extended integer type for C23
and thus support int128_t, uint128_t, int_least128_t and uint_least128_t in
.

I think we *should* add such support in GCC (thus, including GCC's 
for the freestanding case - header changes appropriately conditional on C23
mode) and glibc. Not of course in GCC 14 at the current development stage, as
it's clearly a new feature.

I think it should be done with an integer constant suffix (say i128 / I128 -
potentially confusing if used together with 'i' for complex integers, but not
ambiguous), rather than using wb/uwb together with the hack of making macros
expand to e.g. ((__int128) +123wb) to get the right type (the '+' together with
the cast, to a type name that's interpreted as 0 in the preprocessor, allows
such an expression to work in #if expressions as long as the value is within
the range of intmax_t which is all that's allowed there).

When adding such a feature to glibc we'd need to consider what user-visible
features are appropriate beyond the header changes and printf/scanf support.
That probably includes functions such as strotoi128 / wcstoi128 and the
unsigned and _l versions thereof (using C23 semantics unconditionally for 0b, I
suppose), maybe also i128abs, i128div. The type-generic macros in stdbit.h mean
we don't need extra type-specific functions there.

The default printf/scanf format checking in GCC is effectively for things that
are either standard or in glibc - and w128 is only standard when you have
support for int128_t and all the pieces that go along with that, at least on
the compiler side. (I'm supposing you don't want separate musl_printf format
checking support - although such a thing is possible, we do have separate
ms_printf support for Windows target.)

[Bug c/113887] no support for %w128 length modifiers

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

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

--- Comment #5 from Joseph S. Myers  ---
Compiler and library are not in practice independent for this issue. GCC
typically provides  for freestanding compilations and forwards to a
libc version for hosted compilations, and in both cases it needs to know what
the types are for correct format checking (for example, whether int64_t is long
or long long) - and it needs to know that even in files that didn't include
, and preferably the types should be the same for hosted and
freestanding. In fact it needs to know the types even when not compiling C or
C++ - Fortran ISO_C_BINDING supports those types (though the Fortran standard
has a specific list, not mentioning int128_t or general intN_t). And to
properly support  implementation - whether in GCC's  or one
provided by libc - any int128_t support should come with all the associated
predefined macros - including __INT128_C and __UINT128_C defined to use an
appropriate constant suffix.

[Bug c/113887] no support for %w128 length modifiers

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

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

--- Comment #11 from Joseph S. Myers  ---
As I said in comment#2, I prefer a constant suffix for __int128 to the wb/uwb
hack - I think it's cleaner, as well as allowing int128_t to work properly on
all the targets that support __int128 but have not so far had an ABI for
_BitInt defined, or not had such an ABI implemented in GCC.

(I also think it's time to chase up target maintainers for all the
architectures that don't yet have _BitInt support, which is almost all of them,
inviting them to sort out an ABI definition either locally in GCC, in
conjunction with other implementations or in an actual ABI document, as
appropriate depending on the extent to which GCC for that target tries to
interoperate with other implementations or externally defined ABIs, and then
add the support, but that's a separate matter.)

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

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

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

--- Comment #4 from Joseph S. Myers  ---
I don't know what's expected for C++, but for C, TS 18661-3 and C23 don't have
versions of nexttoward for _FloatN or _FloatNx (recall that the second argument
of nexttoward has type long double independent of the first argument, which is
using long double as a common superset type for all the standard floating types
- but no such common superset type is guaranteed to exist for all the _FloatN
and _FloatNx types, and long double certainly need not be such a type, so
nexttoward doesn't make sense for _FloatN or _FloatNx). Instead, those types
have nextafter, nextup and nextdown functions.

[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs

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

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

--- Comment #17 from Joseph S. Myers  ---
The tests that GCC's internal notion of the types agrees with the headers are
in gcc.dg/c99-stdint-5.c and gcc.dg/c99-stdint-6.c.

[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)

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

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

--- Comment #16 from Joseph S. Myers  ---
I think it's clear that __has_c_attribute(gnu::unused) should only return 1 if
the [[gnu::unused]] syntax is actually parsed. (An unavoidable limitation if it
might return 1 in pre-C23 modes is that if it's used with -pedantic /
-pedantic-errors, such a usage of [[gnu::unused]] would then be diagnosed -
since another principle is that -pedantic / -pedantic-errors should not affect
semantics, in particular not change the return value of __has_c_attribute.)

I also think that __has_c_attribute(gnu::unused) should always parse
successfully in #if, even if it returns 0 in some cases.

It's probably reasonable to accept :: in [[]] attributes in pre-C23 standard
modes where those are two consecutive : tokens (the use of the [[]] syntax at
all would result in a pedwarn-if-pedantic).

Ideally there might be a marker on the tokens as suggested to indicate whether
two such tokens would have been :: if in C23 mode, to avoid accepting other
variants where the two tokens are separated in the sources. (The only reason
it's not valid to produce a single preprocessing token in pre-C23 mode is to
deal with corner cases such as ##-concatenating < :: > where the concatenations
are valid in pre-C23 mode, producing digraphs equivalent to [], but invalid in
C23 mode. Once the preprocessing tokens are converted to tokens, pre-C23
doesn't have any valid cases of two consecutive : tokens.)

[Bug tree-optimization/111770] predicated loads inactive lane values not modelled

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

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

--- Comment #6 from Joseph S. Myers  ---
X + 0. -> X is invalid for FP with signed zero or signaling NaN, and also gets
the wrong quantum exponent for decimal FP unless the zero has the maximum
possible quantum exponent (which is not what you get from all bits of the
representation zero, which is a zero with the minimum possible quantum
exponent, or from converting integer 0 to DFP, which has quantum exponent 0).

(If you add -0. (with maximum quantum exponent, in the DFP case) instead of
+0., that does produce X for X not a signaling NaN - except in FE_DOWNWARD
mode. Whereas adding +0. is only correct in FE_DOWNWARD mode, since 0. - 0. has
positive sign in all other modes.)

[Bug libquadmath/114140] quadmath fminq/fmaxq with signaling_NaN not work

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

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

--- Comment #2 from Joseph S. Myers  ---
Returning a quiet NaN when either argument is a signaling NaN is correct at
least for C (fmin/fmax correspond to IEEE 754-2008 operations, *not* the new
IEEE 754-2019 operations which are
fminimum/fmaximum/fminimum_num/fmaximum_num).

This is not a self-contained bug report ("not work" doesn't say what was
expected or why).  But the output reported from the godbolt link is

std::float128_t
inf
inf
inf
inf

__float128
inf
inf
nan
nan

which looks correct for __float128 and incorrect for float128_t (suggesting
that, in the float128_t case, something might have wrongly converted the
signaling NaN to a quiet NaN before calling the underlying function).

[Bug middle-end/94083] inefficient soft-float x!=Inf code

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

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

--- Comment #6 from Joseph S. Myers  ---
Contrary to what was claimed in bug 66462, I don't think there ever was a fixed
patch. Note that in bug 66462 comment 19, "June" is June 2017 but "November" is
November 2016 - the "November" one is the *older* one.

[Bug c/114266] No -pedantic diagnostic for zero-sized array in compound literals

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-03-07

--- Comment #2 from Joseph S. Myers  ---
The relevant constraint here is "An array of unknown size shall not be
initialized by an empty initializer.".

[Bug middle-end/114347] wrong constant folding when casting __bf16 to int

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

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

--- Comment #4 from Joseph S. Myers  ---
I think it's correct that conversions (explicit or implicit) from a value with
excess precision convert only once; they don't first remove excess range and
precision and then convert to the target type.

This is not an assertion about whether we should implement __bf16 with excess
precision, though it probably makes sense to do so in general for formats for
which processors don't provide direct arithmetic support.

[Bug tree-optimization/114465] "x % const1 % const2" should be optimized if const1 % const2 == 0

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

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

--- Comment #1 from Joseph S. Myers  ---
Note that transforming x % 1 % -1 to x % -1 wouldn't strictly be valid (because
of undefined behavior from INT_MIN % -1), though hopefully cases with constant
1 or -1 get optimized to 0 anyway and the undefined behavior is only a problem
with a -1 that's not a constant.

[Bug tree-optimization/114469] gcc.dg/torture/bitint-64.c failure with -O2 -flto -std=c23 -fwrapv

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

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

--- Comment #1 from Joseph S. Myers  ---
I'd expect _Atomic _BitInt(5) to follow the same ABI (regarding upper bits
being defined or not) as plain _BitInt(5), and any simplification needs to deal
with that.

(In principle for atomics with _BitInt with padding bits there are the same
concerns as for any types with padding bits - any compare-and-exchange loop
needs to succeed eventually when the underlying memory isn't being modified,
rather than failing in comparison of padding bits that might not have been
consistently loaded / preserved. My guess is this is unlikely to be a concern
in practice for _BitInt the way it is e.g. for x86 long double where the
padding bits only exist in memory and not in registers.)

[Bug c/112571] [13 Regression] ICE with nested redefinition of enum

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

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #7 from Joseph S. Myers  ---
Fix now backported to GCC 13 branch, so fixed in 13.3 as well.

[Bug c/114526] ISO C does not prohibit extensions: fix misconception.

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

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

--- Comment #5 from Joseph S. Myers  ---
The -pedantic documentation was updated to reflect reality - that the option is
about more than just when diagnostics are required by ISO C ("forbidden
extensions" can be taken, in the C case, as meaning those that involve
constraint violations or are outside the standard C syntax) but covers some
other programs doing things not defined in ISO C as well - in commit
074e95e34275d72664f997ed949d9c91e37cd6ee (July 2000). I don't think any
possible narrower intent there may have been long before then is particularly
relevant now.

It may well be the case that for certain diagnostics for things that do not
violate constraints or syntax rules, "ISO C does not define" or "is a GNU
extension" or similar would be better wording.

[Bug c/114526] ISO C does not prohibit extensions: fix misconception.

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

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

--- Comment #8 from Joseph S. Myers  ---
"rejects", in the ISO C sense, only applies to errors and pedwarns in GCC; not
to warnings conditional on -pedantic (of which there are also some, but which
don't turn into errors with -pedantic).

If you have cases where something that is only *undefined as a property of a
particular execution of the program* (as opposed to undefined as a property of
a translation unit or of the collection of translation units making up a
program, or violating a Constraint or syntax rule) but that are errors or
pedwarns, those should be reported as separate bugs. There are various cases
where we make sure to only warn at compilation time and generate code that
aborts at precisely the point in execution where undefined behavior would
occur, precisely because the undefined behavior in those cases is a property of
a program execution.

I believe conversions between function and object pointers are undefined as a
property of the translation unit - not of a particular execution. Whereas e.g.
calling a function pointer converted to an incompatible type is undefined as a
property of a particular execution (the undefinedness only occurring when the
call itself is executed, after all side effects from the function designator
and arguments have taken place).

[Bug libquadmath/114533] libquadmath: printf: fix misaligned access on args

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

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

--- Comment #7 from Joseph S. Myers  ---
Note also that in glibc, _Float128 support in printf code can only be used in
limited circumstances: either on powerpc64le, as one of the multiple supported
long double formats there, or through the sharing of the printf code with the
implementation of strfromf128.

In particular, there are no glibc printf formats corresponding directly to
_FloatN / _FloatNx types. There was support in principle at the WG14 meeting in
Strasbourg in January for having some form of printf/scanf support for such
types in C2y, but major work is still needed on the wording that was proposed
in N3184.

[Bug c/114526] ISO C does not prohibit extensions: fix misconception.

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

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

--- Comment #11 from Joseph S. Myers  ---
I think that simply failing to say whether a value of type X may be converted
to type Y is clearly enough for it at least to be unspecified whether or when
such conversions are possible in a cast at all (which is enough for rejecting
the translation unit). And since no requirements are imposed relating to such
conversions at either translation time or runtime, the definition of undefined
behavior is met.

If you try to cast from a struct to a union (for example), you violate a
constraint. If you try to do a conversion between a pointer and another scalar
type that's not one of the "may be converted" cases listed as allowing such a
conversion, you have undefined behavior through the lack of definition (if it's
an implicit conversion rather than a cast, doing it as an implicit conversion
violates a constraint unless it follows the requirements for assignment
expressions.)

[Bug c/114526] ISO C does not prohibit extensions: fix misconception.

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

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

--- Comment #15 from Joseph S. Myers  ---
There are several statements such as "Any pointer type may be converted to an
integer type." and "A pointer to an object type may be converted to a pointer
to a different object type.", that allow certain conversions to occur in a
translation unit and are associated with some properties of those conversions
if they are executed. There are also statements disallowing certain conversions
from occurring in a translation unit (for example, conversions between pointer
and floating types are constraint violations). In the cases where there is no
statement either way, the behavior is undefined as a property of the
translation unit (not just of the execution): it is not defined whether such a
conversion may occur in a translation unit, and not defined what the semantics
would be on execution if an implementation permits the translation of such a
conversion. Being undefined through omission of definition has, as per clause
4, not difference in meaning or emphasis from being explicitly undefined.

I'd suggest working with the Undefined Behavior Study Group on making it more
explicit for each instance of undefined behavior whether it is a property of
the program or of an execution thereof, but if any case seems particularly
unclear, filing an issue once the new C standard issue tracker is up and
running would probably be reasonable (but it seems likely that such issues
would be referred to the UB study group to recommend a resolution just as
floating-point issues would likely be referred to the CFP group).

It's *not* the case that the same rules apply everywhere, because there are two
different kinds of UB depending on whether what's undefined is a property of
the program or an execution thereof. Division by zero is obviously UB as a
property of an execution, because whether a value is zero is a property of the
execution. Different types for the same identifier with external linkage in
different translation units is obviously UB as a property of the program (and
not widely diagnosed without LTO), as the whole concept of an identifier
corresponding to an object with a particular value depends on a globally
consistent notion of its type and the UB is about presence of declarations
rather than a particular path of execution. In some cases, as here, it may be
less obvious how to read the wording as referring to properties of an execution
or of a program.

[Bug c/65213] Extend -Wmissing-declarations to variables [i.e. add -Wmissing-variable-declarations]

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |14.0

--- Comment #5 from Joseph S. Myers  ---
Implemented for GCC 14.

[Bug middle-end/87403] [Meta-bug] Issues that suggest a new warning

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
Bug 87403 depends on bug 65213, which changed state.

Bug 65213 Summary: Extend -Wmissing-declarations to variables [i.e. add 
-Wmissing-variable-declarations]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65213

   What|Removed |Added

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

[Bug c/110664] -std=c2x -pedantic-errors pedwarns on _Float128

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

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

Joseph S. Myers  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #3 from Joseph S. Myers  ---
Fixed by

commit r14-3731-g80acabb6dd05090db67805cdd358fe974b45e2ed
Author: Jakub Jelinek 
Date:   Wed Sep 6 08:51:00 2023 +0200

c: Don't pedwarn on _FloatN{,x} or {f,F}N{,x} suffixes for C2X

[Bug c/116130] Implement C23 N2956 paper - [[unsequenced]] and [[reproducible]] function type arguments

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

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

--- Comment #12 from Joseph S. Myers  ---
N3096 is a very old draft with lots of mistakes. Use N3220 instead (it has no
technical changes relative to C23, though it's also missing many late editorial
fixes required by ISO).

Composite types for conditional expressions are as intended.  [[noreturn]] is
not a type attribute but a declaration attribute (and GNU noreturn on types
merges differently).  Accordingly, C23 deliberately does not add the new type
attributes to any existing functions that were in previous C standard versions,
precisely because that would invalidate existing code that used conditional
expressions and was valid with previous standard versions.  It *does* put
[[unsequenced]] on the  functions, as they are new in C23, and it
would be appropriate for glibc to do likewise (when building with a compiler
supporting [[__unsequenced__]]) - though as the out-of-line functions won't
normally be used, and already use __attribute_const__, the effects of doing so
would be small (and it's always OK not to have the attribute in the header,
since any program valid with it there is also valid without it).

[Bug rtl-optimization/116199] New: [15 Regression] reload ICE building glibc for m68k

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

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

Bug ID: 116199
   Summary: [15 Regression] reload ICE building glibc for m68k
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: law at gcc dot gnu.org
  Target Milestone: ---
Target: m68k-*-*

Created attachment 58807
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58807&action=edit
preprocessed source

The following ICE building glibc for m68k-linux-gnu was introduced by:

commit 88d16194d0c8a6bdc2896c8944bfbf3e6038c9d2
Author: Jeff Law 
Date:   Mon Jul 22 08:45:10 2024 -0600

[NFC][PR rtl-optimization/115877] Avoid setting irrelevant bit groups as
live in ext-dce

and is still present as of 7ecd6610528a301e349df273b624513ef3827321. Build the
attached testcase with -O2 (not reduced, but pretty short anyway).

during RTL pass: reload
makedev.c: In function '__gnu_dev_makedev':
makedev.c:34:316: internal compiler error: Segmentation fault
0x1b413ce internal_error(char const*, ...)
   
/notnfs/josmyers/glibc-manual/src/gcc/gcc/diagnostic-global-context.cc:491
0xf02c3f crash_signal
/notnfs/josmyers/glibc-manual/src/gcc/gcc/toplev.cc:321
0xe7990a operands_match_p(rtx_def*, rtx_def*)
/notnfs/josmyers/glibc-manual/src/gcc/gcc/reload.cc:2252
0xe809b0 find_reloads(rtx_insn*, int, int, int, short*)
/notnfs/josmyers/glibc-manual/src/gcc/gcc/reload.cc:2782
0xe9162d calculate_needs_all_insns
/notnfs/josmyers/glibc-manual/src/gcc/gcc/reload1.cc:1469
0xe9162d reload(rtx_insn*, int)
/notnfs/josmyers/glibc-manual/src/gcc/gcc/reload1.cc:983
0xcd577f do_reload
/notnfs/josmyers/glibc-manual/src/gcc/gcc/ira.cc:5985
0xcd577f execute
/notnfs/josmyers/glibc-manual/src/gcc/gcc/ira.cc:6161
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/116244] New: [15 Regression] reload ICE building libstdc++ for coldfire

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

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

Bug ID: 116244
   Summary: [15 Regression] reload ICE building libstdc++ for
coldfire
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: law at gcc dot gnu.org
  Target Milestone: ---
Target: m68k-*-*

Created attachment 58843
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58843&action=edit
preprocessed source (gzipped)

The following ICE building libstdc++ for coldfire (m68k-linux-gnu
--with-arch=cf --disable-multilib) was introduced by:

commit 88d16194d0c8a6bdc2896c8944bfbf3e6038c9d2
Author: Jeff Law 
Date:   Mon Jul 22 08:45:10 2024 -0600

[NFC][PR rtl-optimization/115877] Avoid setting irrelevant bit groups as
live in ext-dce

and is still present as of 86512292270860bbe1dd33cef1ebe041d597462c. Thus, in
particular, it is *not* the same as the ICE building glibc for classic m68k
(bug 116199) that was introduced by the same commit (though when doing the
initial triage of the failures from build-many-glibcs.py I assumed them to be
the same issue), as that's been fixed while this ICE remains.

Build the attached preprocessed source with -std=gnu++20 -O2.

/notnfs/josmyers/glibc-manual/build/compilers/m68k-linux-gnu-coldfire/gcc/./gcc/xgcc
-B/notnfs/josmyers/glibc-manual/build/compilers/m68k-linux-gnu-coldfire/gcc/./gcc
-std=gnu++20 -O2 -fPIC -S -o /dev/null tzdb.ii 
during RTL pass: reload
/notnfs/josmyers/glibc-manual/src/gcc/libstdc++-v3/src/c++20/tzdb.cc: In member
function 'std::chrono::year_month_day
std::chrono::{anonymous}::on_day::pin(std::chrono::year) const':
/notnfs/josmyers/glibc-manual/src/gcc/libstdc++-v3/src/c++20/tzdb.cc:340:7:
internal compiler error: Segmentation fault
  340 |   }
  |   ^
0x1e4aace internal_error(char const*, ...)
   
/notnfs/josmyers/glibc-manual/src/gcc/gcc/diagnostic-global-context.cc:491
0x120254f crash_signal
/notnfs/josmyers/glibc-manual/src/gcc/gcc/toplev.cc:321
0xd530bc df_install_refs
/notnfs/josmyers/glibc-manual/src/gcc/gcc/df-scan.cc:2376
0xd530bc df_install_refs
/notnfs/josmyers/glibc-manual/src/gcc/gcc/df-scan.cc:2335
0xd53306 df_refs_add_to_chains
/notnfs/josmyers/glibc-manual/src/gcc/gcc/df-scan.cc:2430
0xd5a116 df_bb_refs_record(int, bool)
/notnfs/josmyers/glibc-manual/src/gcc/gcc/df-scan.cc:3356
0xd5a25c df_scan_blocks()
/notnfs/josmyers/glibc-manual/src/gcc/gcc/df-scan.cc:587
0xfdc7f4 do_reload
/notnfs/josmyers/glibc-manual/src/gcc/gcc/ira.cc:6040
0xfdc7f4 execute
/notnfs/josmyers/glibc-manual/src/gcc/gcc/ira.cc:6164
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

I don't know if there's any connection to the different ICE building the same
file for classic m68k with LRA enabled (bug 116236).

[Bug c/108796] Can't intermix C2x and GNU style attributes

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

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

--- Comment #13 from Joseph S. Myers  ---
Everything available with __attribute__ is also available with [[]];
__attribute__((foo)) is [[gnu::foo]]. You *do* need to ensure that the
[[gnu::foo]] is placed in the right syntactic position for the entity
appertained to, because laxity in positioning only ever applies with
__attribute__ syntax, not with [[]] syntax.

[Bug c/108796] Can't intermix C2x and GNU style attributes

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

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

--- Comment #15 from Joseph S. Myers  ---
The [[]] syntax is supported in C from GCC 10 onwards (in C++ in older versions
as well). What's new in GCC 14 is that you can use it with :: in pre-C23 modes
(with previous versions you needed -std=gnu2x / -std=c2x, otherwise the ::
wasn't parsed as it's two separate : tokens in older versions and only a single
:: token in C23).

If you're writing extern "C" in C++ and your code also supports being used from
C, you already have some language conditionals.

[Bug tree-optimization/112358] [14/15 Regression] glibc -Wstringop-overflow= build failure on hppa since r14-4089-gd45ddc2c04e471

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

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

--- Comment #8 from Joseph S. Myers  ---
If it's a false positive, it's reasonable to work around in glibc using the
libc-diag.h macros (DIAG_PUSH_NEEDS_COMMENT / DIAG_IGNORE_NEEDS_COMMENT /
DIAG_POP_NEEDS_COMMENT) - but that would need an appropriately detailed comment
explaining why it's a false positive and the code path implied by the warning
isn't actually possible.

[Bug c/116631] [gcc] c23 - 'auto' struggles with comma expression type inference.

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

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

--- Comment #2 from Joseph S. Myers  ---
The specification for underspecified declarations (auto and constexpr) says "if
anywhere within the sequence of tokens making up the declaration identifiers
that are not ordinary are declared, the behavior is implementation-defined." -
so the auto initializer can't contain a struct definition (struct members
aren't ordinary identifiers), for example. (We could reasonably remove those
errors anyway; they were added when a diagnostic was required, before it was
made implementation-defined instead. The idea of the previous requirement to
diagnose such cases was to ensure auto uses were equivalent to something that
could be expressed using typeof without enlarging scopes of tags.)

[Bug c/46073] __builtin_choose_expr outputs warnings for unused expression

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

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

--- Comment #5 from Joseph S. Myers  ---
It's doubtful that this is a bug. You could define __builtin_choose_expr so the
unselected operand only needs to be a balanced token sequence (with no commas
unless nested inside () [] {}), but it's less clear that you should; there are
disadvantages to not checking unselected operands as well as advantages. (Cf.
how it's often better to use if () rather than #if for conditionals on
compile-time constants so that more of the syntax gets checked in all build
configurations.)

(Technically, some valid code could change its semantics if you start treating
one half as only a balanced token sequence - struct / union / enum types
defined inside the unselected expression would no longer get declared for the
rest of the scope - but I think that could safely be ignored, just included in
the tests added, if we decide to make such a change.)

[Bug c/114657] Invalid type conversion from some _BitInt bit-fields

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

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

--- Comment #3 from Joseph S. Myers  ---
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2958.htm has my analysis of
the various notions of "type" used in relation to bit-fields and the questions
of what expressions are considered to have special properties associated with
referring to a bit-field.

[Bug c/114730] should enum types be vector types?

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

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

--- Comment #3 from Joseph S. Myers  ---
When implementing C23 enums with fixed underlying types I tried to ensure that
enums with underlying type bool were handled consistently with bool (cf. bug
96496 where they're not always handled consistently for C++) but it seems I
missed this vector_size check.

[Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants and floating-point constant expressions

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

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

--- Comment #3 from Joseph S. Myers  ---
The actual effect of -fexcess-precision=fast is more like "outside the back
end, pretend excess precision doesn't exist, but the back end might use it
anyway" (complicated a bit by having genuine excess precision logic for
_Float16 still in operation when otherwise pretending excess precision doesn't
exist). Pretending excess precision doesn't exist includes not having its
effects on constants. Maybe that's confusing, but the effects of excess
precision on constants also confuse people, as do all forms of excess precision
for operations, so it's not clear that an alternative would be any better.

[Bug c/114808] Qualified void return type is not diagnosed

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

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

--- Comment #7 from Joseph S. Myers  ---
Yes, this is deliberate following the resolution of DR#423 which means
qualifiers are ignored on function return types (it's still diagnosed in
pre-C11 modes).

[Bug c/114816] Non-standard behavior with void arguments

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

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

--- Comment #1 from Joseph S. Myers  ---
Note that it's not possible to define a function with such parameters ("After
adjustment, the parameters in a parameter type list in a function declarator
that is part of a definition of that function shall not have incomplete
type.").

"register void" and "const void" (single unnamed parameter) are in the list of
undefined behavior in Annex J ("A storage-class specifier or type qualifier
modifies the keyword void as a function parameter type list") - presumably
implicitly undefined for lack of definition. As for named void parameters (or
more than one void parameter, etc.), the response to C99 DR#295 says "The
Committee agrees that there do not appear to be any constraints forbidding
constructions like void func(void parm); nor are any semantics provided for
this construction." (which would also be implicitly undefined behavior).

Given the desire to reduce undefined behavior in C2y it would be reasonable to
submit a paper tightening this up by making all the problem cases (any case of
a void parameter except for the special case of a single unnamed parameter of
type void, no storage class specifier, no ellipsis following) into constraint
violations for function declarators - or indeed to raise this through the issue
tracking process once we have the new issue tracker set up, with a view to
inviting WG14 to consider this a defect applicable to older standard versions.

[Bug c/114869] GCC says nullptr_t is a C built in but it should be in

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

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

Joseph S. Myers  changed:

   What|Removed |Added

   Last reconfirmed||2024-04-29
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Joseph S. Myers  ---
I suspect

  /* C-specific nullptr initialization.  */
  record_builtin_type (RID_MAX, "nullptr_t", nullptr_type_node);

in c-decl.cc, from the original nullptr support for C.