[Bug target/117408] New: ICE on `#pragma arm "arm_mve.h" false`

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

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

Bug ID: 117408
   Summary: ICE on `#pragma arm "arm_mve.h" false`
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: azoff at gcc dot gnu.org
  Target Milestone: ---

Starting in r14-435-g00d97bf3b5a, GCC ICEs if `#pragma arm "arm_mve.h" false`
or `#pragma arm "arm_mve.h" true` is issued in a compile unit that does not
have `#pragma arm "arm_mve_types.h"` before.

Reproducer:
/* { dg-do compile } */
/* { dg-require-effective-target arm_v8_1m_mve_ok } */
/* { dg-add-options arm_v8_1m_mve } */

/* It doesn't really matter if this produces errors missing types,
  but it mustn't trigger an ICE.  */
#pragma GCC arm "arm_mve.h" false /* { dg-error "this definition requires MVE
types" } */



Example ICE:

foo.c:7:9: internal compiler error: Segmentation fault
7 | #pragma GCC arm "arm_mve.h" false /* { dg-error "this definition
requires MVE types" } */
  | ^~~
0x2ef975e internal_error(char const*, ...)
.../gcc/diagnostic-global-context.cc:518
0x17a64af crash_signal
.../gcc/toplev.cc:323
0x7f672e74908f ???
   
/build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x1c06f35 build_function_type(tree_node*, tree_node*, bool)
.../gcc/tree.cc:7534
0x1c07612 build_function_type_array_1
.../gcc/tree.cc:7661
0x1c07643 build_function_type_array(tree_node*, int, tree_node**)
.../gcc/tree.cc:7671
0x1ec81cd
arm_mve::function_builder::add_unique_function(arm_mve::function_instance
const&, tree_node*, vec&, bool, bool, bool)
.../gcc/config/arm/arm-mve-builtins.cc:980
0x1ecf983 build_one
.../gcc/config/arm/arm-mve-builtins-shapes.cc:252
0x1ecfac5 build_all
.../gcc/config/arm/arm-mve-builtins-shapes.cc:282
0x1ed00f2 arm_mve::binary_acca_int32_def::build(arm_mve::function_builder&,
arm_mve::function_group_info const&, bool) const
.../gcc/config/arm/arm-mve-builtins-shapes.cc:511
0x1ec89b8
arm_mve::function_builder::register_function_group(arm_mve::function_group_info
const&, bool)
.../gcc/config/arm/arm-mve-builtins.cc:1113
0x1ec6d1f arm_mve::handle_arm_mve_h(bool)
.../gcc/config/arm/arm-mve-builtins.cc:542
0xf5aee1 arm_pragma_arm
.../gcc/config/arm/arm-c.cc:154
0xf11057 c_invoke_pragma_handler(unsigned int)
.../gcc/c-family/c-pragma.cc:1743
0xe215f4 c_parser_pragma
.../gcc/c/c-parser.cc:15400
0xdf94d3 c_parser_external_declaration
.../gcc/c/c-parser.cc:2044
0xdf8f7e c_parser_translation_unit
.../gcc/c/c-parser.cc:1917
0xe547e2 c_parse_file()
.../gcc/c/c-parser.cc:27866
0xf094a6 c_common_parse_file()
.../gcc/c-family/c-opts.cc:1352
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 libstdc++/117406] std::ilogb should return INT_MAX when argument is infinite also for 16-bit floats

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2024-11-01

--- Comment #1 from Jakub Jelinek  ---
Created attachment 59518
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59518&action=edit
gcc15-pr117406.patch

Untested fix.  Though I still need to add some testcase coverage.

[Bug tree-optimization/117395] missed SRA opportunity with extracting subpart of type

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=14295
 Ever confirmed|0   |1
   Last reconfirmed||2024-11-01

--- Comment #1 from Andrew Pinski  ---
It is a slight regression from GCC 14 though.

Which produced:
```
foo:
ldr q31, [x0, 32]
sub sp, sp, #128
add sp, sp, 128
dup d0, v31.d[1]
add v0.4h, v0.4h, v31.4h
ret
```

But that is only because vget_low_s16/vget_high_s16 didn't expand to using
BIT_FIELD_REF before.

The bigger issue is GCC does not have a copy propagation for aggregates pass
(see PR 14295 and others).

[Bug tree-optimization/117395] missed SRA opportunity with extracting subpart of type

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> 
> The bigger issue is GCC does not have a copy propagation for aggregates pass
> (see PR 14295 and others).

Basically we depend on SRA to do most if not all of the `copy propagation for
aggregates` which might not be a good idea.

[Bug gcov-profile/117412] New: Bogus execution count for assignment with function call

[wentaoz5 at illinois dot edu via Gcc-bugs]

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

Bug ID: 117412
   Summary: Bogus execution count for assignment with function
call
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wentaoz5 at illinois dot edu
  Target Milestone: ---

How to reproduce:

$ gcc --version

gcc (GCC) 15.0.0 20240923 (experimental)
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat > test.c << 'EOF'
int foo(long a) {
return 0;
};

struct Bar { int b; };

int main(void) {
intx[100];
struct Bar y;
intz;

int   a1;
unsigned long a2;
long long a3;

*x = foo(
 a1*2);

x[1] = foo(
 a2+1);

y.b = foo(
 a3-3);

return 0;
}
EOF
$ gcc --coverage test.c -o test
$ ./test
$ gcov test
$ cat test.c.gcov
...
-:   15:
2:   16:*x = foo(
1:   17: a1*2);
-:   18:
2:   19:x[1] = foo(
1:   20: a2+1);
-:   21:
2:   22:y.b = foo(
1:   23: a3-3);
-:   24:
1:   25:return 0;
...

Line 16, 19 and 22 are reported to executed twice, which is hard to interpret.

(Example reduced from
https://github.com/apache/httpd/blob/2.4.62/server/util_filter.c#L138)

These are the known conditions to trigger the behavior:

1. The argument is "somewhat complex": variable alone or constant alone
   won't trigger it
2. Function name and assignment is put in the first line; operator of the
   argument is put in the second line
3. Argument and parameter have different types
4. The return value is assigned to one of {subscript,dereference,struct member}

[Bug libbacktrace/117413] New: [15 regression] RISC-V: stage2 build failure with __builtin_prefetch

[ewlu at rivosinc dot com via Gcc-bugs]

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

Bug ID: 117413
   Summary: [15 regression] RISC-V: stage2 build failure with
__builtin_prefetch
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libbacktrace
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ewlu at rivosinc dot com
CC: ian at gcc dot gnu.org
  Target Milestone: ---

postcommit is failing to build gcc stage2 for all linux targets with the
following error:

2024-11-01T19:57:30.3588122Z In function 'elf_fetch_bits',
2024-11-01T19:57:30.3588960Z inlined from 'elf_zlib_inflate' at
../../../../gcc/libbacktrace/elf.c:2452:11:
2024-11-01T19:57:30.3590444Z ../../../../gcc/libbacktrace/elf.c:1158:3: error:
invalid second argument to '__builtin_prefetch'; using zero [-Werror]
2024-11-01T19:57:30.3591537Z  1158 |   __builtin_prefetch (pin, 0, 0);
2024-11-01T19:57:30.3592082Z   |   ^~
2024-11-01T19:57:30.3593258Z ../../../../gcc/libbacktrace/elf.c:1158:3: error:
invalid third argument to '__builtin_prefetch'; using zero [-Werror]
2024-11-01T19:57:30.3594345Z cc1: all warnings being treated as errors
2024-11-01T19:57:30.3594950Z make[4]: *** [Makefile:1538: elf.lo] Error 1
2024-11-01T19:57:30.3595566Z make[4]: *** Waiting for unfinished jobs

https://github.com/patrick-rivos/gcc-postcommit-ci/issues/2030

Likely caused by r15-4847-g79a75b1f551

[Bug libbacktrace/117413] [15 regression] RISC-V: stage2 build failure with __builtin_prefetch

[ewlu at rivosinc dot com via Gcc-bugs]

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

Edwin Lu  changed:

   What|Removed |Added

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

--- Comment #1 from Edwin Lu  ---
dup

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

[Bug bootstrap/117407] [15 regression] bootstrap fails after r15-4847-g79a75b1f551821

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #3 from Sam James  ---
This should be fixed now.

[Bug tree-optimization/117385] Move phiopt away from doing a COND_EXPR with a comparison as first operand

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

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

--- Comment #2 from Andrew Pinski  ---
Note maybe_fold_comparisons_from_match_pd is an example of generating gimple on
the stack.

[Bug web/117401] Spell that ./configure --enable-link-mutex is deprecated

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

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

--- Comment #4 from Eric Gallager  ---
(In reply to Jakub Jelinek from comment #3)
> That doesn't really matter.  Anybody who used the option in GCC 13/14 got
> that deprecation message.

They might not have seen it, though, as it is easy for warning messages to get
lost in the sea of configure output

[Bug c++/117410] New: Ambiguous overload with ellipsis

[ddvamp007 at gmail dot com via Gcc-bugs]

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

Bug ID: 117410
   Summary: Ambiguous overload with ellipsis
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ddvamp007 at gmail dot com
  Target Milestone: ---

#include 
#include 

template 
bool foo() { return false; }

template 
requires std::is_void_v
bool foo(...) { return true; }

template 
bool bar() { return false; }

template 
requires (x == 0)
bool bar(...) { return true; }

int main() {
assert(foo());
assert(bar());
}

Compilation error with gcc, ok with clang

It looks like 'true' options are more specialized than 'false' according to
[temp.func.order]

[Bug libstdc++/111055] [C++23] Implement P1206R7, Conversions from ranges to containers

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

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

--- Comment #9 from Jonathan Wakely  ---
Still to do:

-  and  (I have a patch but it needs more tests)
- 
- 
- 
- 
- 

[Bug libstdc++/117406] std::ilogb should return INT_MAX when argument is infinite also for 16-bit floats

[pkeir at outlook dot com via Gcc-bugs]

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

--- Comment #2 from Paul Keir  ---
Created attachment 59519
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59519&action=edit
Test for the proposed fix.

[Bug tree-optimization/117398] [15 Regression] ICE: in invert, at value-range.cc:2165 at -O3 with "-fno-thread-jumps"

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Last reconfirmed||2024-11-01
Summary|ICE: in invert, at  |[15 Regression] ICE: in
   |value-range.cc:2165 at -O3  |invert, at
   |with "-fno-thread-jumps"|value-range.cc:2165 at -O3
   ||with "-fno-thread-jumps"
  Known to fail||15.0
 Status|UNCONFIRMED |NEW
   Keywords||ice-checking,
   ||needs-bisection
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
  gcc_checking_assert (!undefined_p () && !varying_p ());

  switch (b_3(D))  [INV], case 0 ... 1:  [INV]>



Confirmed. This is a regression but I am not 100% sure when it was introduced;
it might have been introduced when gimple_outgoing_range::calc_switch_ranges
code was introduced but I am not sure.

Also I am not 100% sure if this is a ranger issue though; it might be a latent
bug in the way forwprop handles switch and fixing up when it comes to the full
range of the case statements.

Better testcase which avoids the warning about bool in a switch.

```
int a;
void c(void);
int d(_Bool b) {
  switch (b+0) {
  case 0:
break;
  case 1:
break;
  default:
c();
  }
  if (b)
return a;
}
```

[Bug bootstrap/117407] [15 regression] bootstrap fails after r15-4847-g79a75b1f551821

[ewlu at rivosinc dot com via Gcc-bugs]

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

Edwin Lu  changed:

   What|Removed |Added

 CC||ewlu at rivosinc dot com

--- Comment #2 from Edwin Lu  ---
*** Bug 117413 has been marked as a duplicate of this bug. ***

[Bug fortran/117381] -fmax-identifier-length= is completely ignored

[8e3g6jay6 at mozmail dot com via Gcc-bugs]

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

Jordan <8e3g6jay6 at mozmail dot com> changed:

   What|Removed |Added

 Status|RESOLVED|WAITING
 Resolution|WONTFIX |---

[Bug tree-optimization/114326] Missed optimization for A || B when !B implies A.

[adhemerval.zanella at linaro dot org via Gcc-bugs]

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

Adhemerval Zanella  changed:

   What|Removed |Added

 CC||adhemerval.zanella at linaro 
dot o
   ||rg

--- Comment #7 from Adhemerval Zanella  
---
It has triggered a regression on arm32 Linaro bots [1]:


---
Executing on host:
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-eabi-gcc
 
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.dg/tree-ssa/fold-xor-and-or.c
 -mthumb -march=armv8.1-m.main+mve.fp+fp.dp -mtune=cortex-m55 -mfloat-abi=hard
-mfpu=auto   -fdiagnostics-plain-output   -O3 -fdump-tree-optimized -S  -o
fold-xor-and-or.s
FAIL: gcc.dg/tree-ssa/fold-xor-and-or.c scan-tree-dump-not optimized
"d1_[0-9]+.D. \\^ d2_[0-9]+.D."

$ grep -e "d1_[0-9]" fold-xor-and-or.c.267t.optimized
  _1 = d1_4(D) ^ d2_5(D);
---

It can be triggered with a cross-compiler targeting arm-linux-gnueabhf with the
above flags.

[1]
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/650/artifact/artifacts/00-sumfiles/gcc.log.0.xz

[Bug tree-optimization/114326] Missed optimization for A || B when !B implies A.

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Adhemerval Zanella from comment #7)
> It has triggered a regression on arm32 Linaro bots [1]:
This is recorded as PR 116860 already.  I might take a look later but I suspect
it is a missed with optimization due to the way if combine works.

[Bug libstdc++/102445] [meta-bug] std::regex issues

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

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

Bug 117394 Summary: evil regex causes a stack overflow and a crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117394

   What|Removed |Added

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

[Bug libstdc++/117394] evil regex causes a stack overflow and a crash

[vincent.lebourlot at starqube dot com via Gcc-bugs]

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

--- Comment #2 from vincent.lebourlot at starqube dot com ---
fair enough. Any chance this might be looked at at some point? llvm doesn't
seem to have such a problem on that regex. 
Cheers

[Bug web/117401] Spell that ./configure --enable-link-mutex is deprecated

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||documentation
   Last reconfirmed||2024-11-01

[Bug web/117401] Spell that ./configure --enable-link-mutex is deprecated

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
We should just remove the option, it has been deprecated already in GCC 13.

[Bug libstdc++/117403] New: [C++26] Implement P1901R2 Enabling the Use of weak_ptr as Keys in Unordered Associative Containers

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

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

Bug ID: 117403
   Summary: [C++26] Implement P1901R2 Enabling the Use of weak_ptr
as Keys in Unordered Associative Containers
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 110339
  Target Milestone: ---

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p1901r2.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339
[Bug 110339] Implement C++26 library features

[Bug libstdc++/117402] New: [C++26] Implement P2363R5 Extending associative containers with the remaining heterogeneous overloads

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

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

Bug ID: 117402
   Summary: [C++26] Implement P2363R5 Extending associative
containers with the remaining heterogeneous overloads
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 110339
  Target Milestone: ---

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2363r5.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339
[Bug 110339] Implement C++26 library features

[Bug tree-optimization/117398] New: ICE: in invert, at value-range.cc:2165 at -O3 with "-fno-thread-jumps"

[iamanonymous.cs at gmail dot com via Gcc-bugs]

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

Bug ID: 117398
   Summary: ICE: in invert, at value-range.cc:2165 at -O3 with
"-fno-thread-jumps"
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---

***
OS and Platform:
$ uname -a:
Linux 65dac7c84719 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC
2023 x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
Using built-in specs.
COLLECT_GCC=/home/software/gcc-trunk-3aa004f/bin/gcc
COLLECT_LTO_WRAPPER=/home/software/gcc-trunk-3aa004f/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++ --prefix=/home/software/gcc-trunk-3aa004f
--enable-coverage
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240630 (experimental) (GCC) 

***
Program:
$ cat mutant.c
int a;
void c();
int d() {
  _Bool b;
  switch (b) {
  case 1:
break;
  case 0:
break;
  default:
c();
  }
  if (b)
return a;
}

***
Command Lines:
$ gcc -O3 -fno-thread-jump mutant.c
mutant.c: In function 'd':
mutant.c:5:3: warning: switch condition has boolean value [-Wswitch-bool]
5 |   switch (b) {
  |   ^~
during GIMPLE pass: evrp
mutant.c:15:1: internal compiler error: in invert, at value-range.cc:2165
   15 | }
  | ^
0x5071bcf diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x50724a1 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, int, char const*, __va_list_tag (*) [1],
diagnostic_t)
???:0
0x50924c7 internal_error(char const*, ...)
???:0
0x50729e4 fancy_abort(char const*, int, char const*)
???:0
0x26f5a11 irange::invert()
???:0
0x4b6a318 gimple_outgoing_range::calc_switch_ranges(gswitch*)
???:0
0x4b69df7 gimple_outgoing_range::switch_edge_range(irange&, gswitch*,
edge_def*)
???:0
0x4b6aa11 gimple_outgoing_range::edge_range_p(irange&, edge_def*)
???:0
0x4b819f8 gori_compute::edge_range_p(vrange&, edge_def*, tree_node*,
range_query&)
???:0
0x4b624d5 ranger_cache::edge_range(vrange&, edge_def*, tree_node*,
ranger_cache::rfd_mode)
???:0
0x4b6572c ranger_cache::resolve_dom(vrange&, tree_node*, basic_block_def*)
???:0
0x4b66316 ranger_cache::range_from_dom(vrange&, tree_node*, basic_block_def*,
ranger_cache::rfd_mode)
???:0
0x4b63e23 ranger_cache::fill_block_cache(tree_node*, basic_block_def*,
basic_block_def*)
???:0
0x4b62a70 ranger_cache::block_range(vrange&, basic_block_def*, tree_node*,
bool)
???:0
0x4b53937 gimple_ranger::range_on_entry(vrange&, basic_block_def*, tree_node*)
???:0
0x4b535e3 gimple_ranger::range_of_expr(vrange&, tree_node*, gimple*)
???:0
0x26e08cf range_query::value_of_expr(tree_node*, gimple*)
???:0
0x264999a rvrp_folder::value_of_expr(tree_node*, gimple*)
???:0
0x23533d2 substitute_and_fold_engine::replace_uses_in(gimple*)
???:0
0x2354b24 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
???:0
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.

Godbolt link: https://godbolt.org/z/Mq4WEnqYn

[Bug c++/117400] New: ICE on invalid requires clause of generic lambda in function template

[eczbek.void at gmail dot com via Gcc-bugs]

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

Bug ID: 117400
   Summary: ICE on invalid requires clause of generic lambda in
function template
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eczbek.void at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/3MG6fMaa7


```
template
void f(){
[](auto) requires {} {}; // nonsense
}

int main() {
f();
}
```


Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20241101/configure
--prefix=/opt/compiler-explorer/gcc-build/staging
--enable-libstdcxx-backtrace=yes --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,objc,obj-c++,go,d,rust,m2 --enable-ld=yes
--enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build-gcc-a287ff2697f0788856a21c99098611a5ae0a4749-binutils-2.42
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241031 (experimental)
(Compiler-Explorer-Build-gcc-a287ff2697f0788856a21c99098611a5ae0a4749-binutils-2.42)
 
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s'
'-masm=intel' '-fno-verbose-asm' '-S' '-std=c++20' '-v' '-freport-bug'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' '/app/'

/opt/compiler-explorer/gcc-trunk-20241101/bin/../libexec/gcc/x86_64-linux-gnu/15.0.0/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-trunk-20241101/bin/../lib/gcc/x86_64-linux-gnu/15.0.0/
-D_GNU_SOURCE  -quiet -dumpdir /app/ -dumpbase output.cpp -dumpbase-ext
.cpp -masm=intel -mtune=generic -march=x86-64 -g -std=c++20 -version
-fdiagnostics-color=always -fno-verbose-asm -freport-bug -o /app/output.s
GNU C++20
(Compiler-Explorer-Build-gcc-a287ff2697f0788856a21c99098611a5ae0a4749-binutils-2.42)
version 15.0.0 20241031 (experimental) (x86_64-linux-gnu)
compiled by GNU C version 11.4.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-trunk-20241101/bin/../lib/gcc/x86_64-linux-gnu/15.0.0/../../../../x86_64-linux-gnu/include"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20241101/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.0/../../../../include/c++/15.0.0"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20241101/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.0/../../../../include/c++/15.0.0/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20241101/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.0/../../../../include/c++/15.0.0/backward"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20241101/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.0/include"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20241101/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.0/include-fixed/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20241101/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.0/include-fixed"
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-trunk-20241101/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.0/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/opt/compiler-explorer/gcc-trunk-20241101/bin/../lib/gcc/x86_64-linux-gnu/15.0.0/../../../../include/c++/15.0.0

/opt/compiler-explorer/gcc-trunk-20241101/bin/../lib/gcc/x86_64-linux-gnu/15.0.0/../../../../include/c++/15.0.0/x86_64-linux-gnu

/opt/compiler-explorer/gcc-trunk-20241101/bin/../lib/gcc/x86_64-linux-gnu/15.0.0/../../../../include/c++/15.0.0/backward

/opt/compiler-explorer/gcc-trunk-20241101/bin/../lib/gcc/x86_64-linux-gnu/15.0.0/include

/opt/compiler-explorer/gcc-trunk-20241101/bin/../lib/gcc/x86_64-linux-gnu/15.0.0/include-fixed/x86_64-linux-gnu

/opt/compiler-explorer/gcc-trunk-20241101/bin/../lib/gcc/x86_64-linux-gnu/15.0.0/include-fixed
 /usr/local/include
 /opt/compiler-explorer/gcc-trunk-20241101/bin/../lib/gcc/../../include
 /usr/include/x86_64-lin

[Bug bootstrap/117399] make all-target-libgcc fails because gcc/as line 114 is "exec $original" and $original is --64

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
>I want to compile only libgcc_s.so in order to put it in a chrooted 
>environment. I call


The build is NOT designed that way.

[Bug web/117401] New: Spell that ./configure --enable-link-mutex is deprecated

[dilyan.palauzov at aegee dot org via Gcc-bugs]

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

Bug ID: 117401
   Summary: Spell that ./configure --enable-link-mutex is
deprecated
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org
  Target Milestone: ---

https://gcc.gnu.org/install/configure.html describes --enable-link-mutex ,
without stating that the option is deprecated.  But gcc/configure.ac:L7251
contains:

AC_MSG_WARN([--enable-link-mutex is deprecated and will be removed in the next
release, use --enable-link-serialization instead])

https://gcc.gnu.org/install/configure.html should state that
--enable-link-mutex is deprecated and suggest to use
--enable-link-serialization .

[Bug bootstrap/117396] gcc/configure --help should print --disable-multilib instead of --enable-multilib

[dilyan.palauzov at aegee dot org via Gcc-bugs]

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

--- Comment #2 from Дилян Палаузов  ---
I think all of them (--disable-ld, --disable-ada, …) should be changed.  This
way ./configure --help  will only suggest how to toggle the default and what is
the default.

Here a legthy discussion (by me): https://ab.bapha.be/posts/help-output/ .

[Bug bootstrap/117399] make all-target-libgcc fails because gcc/as line 114 is "exec $original" and $original is --64

[dilyan.palauzov at aegee dot org via Gcc-bugs]

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

--- Comment #2 from Дилян Палаузов  ---
This was suggested here:
https://stackoverflow.com/questions/22707265/how-to-build-libgcc-of-gcc-compiler/22707330#22707330
.

[Bug target/116887] Section type conflict on loongarch with .data.rel.ro section attribute

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

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

--- Comment #28 from GCC Commits  ---
The master branch has been updated by Xi Ruoyao :

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

commit r15-4842-gc8d35f2ecbf124bdd164dbb1c36de9d90695843b
Author: Xi Ruoyao 
Date:   Fri Oct 11 02:44:27 2024 +0800

Always set SECTION_RELRO for or .data.rel.ro{,.local} [PR116887]

At least two ports (hppa and loongarch) need to set SECTION_RELRO for
.data.rel.ro{,.local} in section_type_flags (PR52999 and PR116887), and
I cannot see a reason not to just set it in the generic code.

With this applied we can also remove the hppa-specific
pa_section_type_flags in a future patch.

gcc/ChangeLog:

PR target/116887
* varasm.cc (default_section_type_flags): Always set
SECTION_RELRO if name is .data.rel.ro{,.local}.

gcc/testsuite/ChangeLog:

PR target/116887
* gcc.dg/pr116887.c: New test.

[Bug target/116887] Section type conflict on loongarch with .data.rel.ro section attribute

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

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

Xi Ruoyao  changed:

   What|Removed |Added

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

--- Comment #29 from Xi Ruoyao  ---
Fixed for trunk.

[Bug analyzer/117373] [15 regression] -Wunused-parameter warning in analyzer/infinite-loop.cc

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:36a92c3829ba7a2683c3b095356b9ed08978420a

commit r15-4841-g36a92c3829ba7a2683c3b095356b9ed08978420a
Author: David Malcolm 
Date:   Fri Nov 1 12:22:53 2024 -0400

analyzer: fix -Wunused-parameter warning [PR117373]

gcc/analyzer/ChangeLog:
PR analyzer/117373
* infinite-loop.cc
(infinite_loop_diagnostic::describe_final_event): Fix
-Wunused-parameter warning

Signed-off-by: David Malcolm 

[Bug bootstrap/117361] [15 Regression] GCC build fails with "gcc/opts-diagnostic.cc:599: test_output_arg_parsing: FAIL: ASSERT_STREQ (pt.get_diagnostic_text ()" when using some locales

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:8e95e064ea73d46b50a68b0104c18685251d326d

commit r15-4840-g8e95e064ea73d46b50a68b0104c18685251d326d
Author: David Malcolm 
Date:   Fri Nov 1 12:22:47 2024 -0400

Use LC_ALL=C when running selftests [PR117361]

gcc/ChangeLog:
PR bootstrap/117361
* Makefile.in (GCC_FOR_SELFTESTS): New.

gcc/c/ChangeLog:
PR bootstrap/117361
* Make-lang.in (s-selftest-c): Use GCC_FOR_SELFTESTS.
(selftest-c-gdb): Likewise.
(selftest-c-valgrind): Likewise.

gcc/cp/ChangeLog:
PR bootstrap/117361
* Make-lang.in (s-selftest-c++): Use GCC_FOR_SELFTESTS.
(selftest-c++-gdb): Likewise.
(selftest-c++-valgrind): Likewise.

gcc/rust/ChangeLog:
PR bootstrap/117361
* Make-lang.in (s-selftest-rust): Use GCC_FOR_SELFTESTS.
(selftest-rust-gdb): Likewise.
(selftest-rust-valgrind): Likewise.

Signed-off-by: David Malcolm 

[Bug bootstrap/117361] [15 Regression] GCC build fails with "gcc/opts-diagnostic.cc:599: test_output_arg_parsing: FAIL: ASSERT_STREQ (pt.get_diagnostic_text ()" when using some locales

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #6 from David Malcolm  ---
Should be fixed by the above patch; marking as fixed.

[Bug analyzer/117373] [15 regression] -Wunused-parameter warning in analyzer/infinite-loop.cc

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from David Malcolm  ---
Thanks; should be fixed by the above patch.

[Bug libstdc++/112596] GCC regex error in Opentelemetry C++

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
No testcase after a year so I'm closing this.

[Bug c++/101887] [12/13/14/15 Regression] ICE with invalid declaration of 'operator delete'

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Simon Martin :

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

commit r15-4843-gfe919da3c395d2214ffc81ad4f51f8344ad5a5c1
Author: Simon Martin 
Date:   Thu Oct 31 15:41:11 2024 +0100

c++: Add testcase for now fixed issue [PR101887]

The testcase in PR101887 has been working since the fix for PR104846,
via r12-7599-gac8310dd122172.

This patch simply adds the case to the testsuite.

PR c++/101887

gcc/testsuite/ChangeLog:

* g++.dg/init/delete5.C: Add testcase from PR c++/101887.

[Bug bootstrap/117399] make all-target-libgcc fails because gcc/as line 114 is "exec $original" and $original is --64

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

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

--- Comment #4 from Sam James  ---
Note that r15-2368-g6a55ff29578e8a makes the error better.

[Bug bootstrap/117399] make all-target-libgcc fails because gcc/as line 114 is "exec $original" and $original is --64

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|WONTFIX |INVALID

--- Comment #3 from Andrew Pinski  ---
Also:
/src/chroot/gcc1420/./gcc/as: line 114: exec: --: invalid option


Means the as is not found for the target.
So invalid and not won't fix.

[Bug c/117289] gcc.dg/debug/ctf/ctf-function-pointers-2.c failure with -std=gnu23

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||david.faust at oracle dot com,
   ||ibhagat at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #1 from Joseph S. Myers  ---
I'm not sure how exactly CTF is meant to handle deduplication where there are
multiple equivalent versions of the same type (POINTER_TYPE, FUNCTION_TYPE
etc.) that are supposed to end up the same in output. Here, we have two
versions of the function pointer type void (*) (struct callback_head *head):
one for the member of the structure, and one in the subsequently defined
typedef.

DWARF debug info seems to get things right even with -std=gnu23: the debug info
for the typedef points to the same type as used for the structure member.
However, CTF outputs the pointer and function types twice, so resulting in the
failure of this test with -std=gnu23.

An actual difference between the two function type definitions is that the one
for the member has TYPE_STRUCTURAL_EQUALITY_P set, whereas that for the typedef
has TYPE_CANONICAL set. It appears, judging by the comment on
c_update_type_canonical, that it may be deliberate for a type created while the
structure was incomplete to retain TYPE_STRUCTURAL_EQUALITY_P. I don't know if
this difference is the actual cause of the problem, or if something else is
meant to ensure that types with no semantic difference as far as CTF is
concerned don't end up duplicated in the CTF output, even if there are multiple
type nodes at the tree level (as noted above, it seems that DWARF ends up
getting the output right, without duplication).

[Bug c++/101887] [12/13/14/15 Regression] ICE with invalid declaration of 'operator delete'

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

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

Simon Martin  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail|12.0|
 Resolution|--- |FIXED
   Target Milestone|12.5|12.0

--- Comment #8 from Simon Martin  ---
Fixed in GCC 12+ via the fix for PR104846.

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

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

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

--- Comment #38 from avieira at gcc dot gnu.org ---
> At least if the behavior is either perform the operation on all elements and
> then based on the 16 bits in the predicate choose result between the newly
> computed result and something else on byte by byte basis.  
Yeah this is what happens for predicated arithmetic operations.

If you want to read it up yourself, look up page 1032 in
https://developer.arm.com/documentation/ddi0553/by?lang=en

That is the section 'Operation for all encodings' in Chapter C2.4, which
describes how a vector add (VADD) works. For MVE that section describes the
operation per 'beat' which is always 32-bits, so for your mental model imagine
that section happens 4 times per vector operation.

Basically if you look at the pseudo-code, the predicate mask is only used for
'writing back the result'. In other words, it does the addition as if we are
going to use everything and its doing a regular unpredicated vector add.

Then when it comes back to write back to the result register, it ignores the
size of the elements altogether and for each 'beat' looks at the result as a
collection of 4-bytes, i.e. over the course of all 4-beats it looks at the
result Q register as 16-bytes, and for each of those bytes it looks up the
corresponding bit in the 16-bit predicate mask and if that bit is 1 it
overrides the current byte in the result Q register with the same byte as the
result of the addition and if its 0 it leaves the existing byte as is.

To give an example:
VMSR P0, r0
VPST
VADDT.i32 Q0, Q1, Q2

With
r0 = 0x8181
Q0 = {0x, 0x, 0x, 0x}
Q1 = {  0x11,   0x11,   0x11,   0x11}
Q2 = {0xaa00, 0xaa00, 0xaa00, 0xaa00}

Will lead to Q0 having the following values:
Q0 = { 0xf11, 0xaaff, 0xff11, 0xaaff}

This is because the mask 0x08181 will only overwrite the least significant byte
of the 32-bits for even elements and the most significant byte for the odd
elements in the result register with the result of Q1 + Q2 = {0xaa11,
0xaa11, 0xaa11, 0xaa11}.

[Bug c++/117392] template argument deduction problem with CNTTP

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

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

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-11-01
   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=115314
 CC||ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
Confirmed, seems we're incorrectly treating the dependent specialization
  constant_wrapper<(L::value - R::value)>
as if it were written
  constant_wrapper<(L::value - R::value), decltype(L::value - R::value)::type>
i.e. the defaulted template argument lacks the implicit CTAD cast to
fixed_value.

So a workaround would be to add a redundant cast in the default template
argument:
  template 
  struct constant_wrapper;

[Bug bootstrap/117396] gcc/configure --help should print --disable-multilib instead of --enable-multilib

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

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

--- Comment #1 from Andrew Pinski  ---
There are others which have a similar help file issue:
AC_ARG_ENABLE(ld,
[AS_HELP_STRING([[--enable-ld[=ARG]]],
[build ld @<:@ARG={default,yes,no}@:>@])],
ENABLE_LD=$enableval,
ENABLE_LD=yes)

...
AC_ARG_ENABLE(libada,
[AS_HELP_STRING([--enable-libada], [build libada directory])],
ENABLE_LIBADA=$enableval,
ENABLE_LIBADA=yes)

...
AC_ARG_ENABLE(libssp,
[AS_HELP_STRING([--enable-libssp], [build libssp directory])],
ENABLE_LIBSSP=$enableval,
ENABLE_LIBSSP=yes)


...
AC_ARG_ENABLE(lto,
[AS_HELP_STRING([--enable-lto], [enable link time optimization support])],
enable_lto=$enableval,
enable_lto=yes; default_enable_lto=yes)



So I am not sure which is correct to do.

Anyways the documentation:
https://gcc.gnu.org/install/configure.html

Documents --disable-multilib correctly. --help on configure is only a short
form of the help.

[Bug bootstrap/117396] gcc/configure --help should print --disable-multilib instead of --enable-multilib

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug modula2/117371] [14.2 Regression] type incompatibility between ‘INTEGER’ and ‘CARDINAL’

[ludovic--- via Gcc-bugs]

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

--- Comment #2 from Ludovic Brenta  ---
The trigger for the bug is the "BY k" in the third loop at line 20.

Removing these words removes the error reported (but obviously 
makes the program less efficient).

-- 
Ludovic Brenta.

[Bug bootstrap/117399] New: make all-target-libgcc fails because gcc/as line 114 is "exec $original" and $original is --64

[dilyan.palauzov at aegee dot org via Gcc-bugs]

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

Bug ID: 117399
   Summary: make all-target-libgcc fails because gcc/as line 114
is "exec $original" and $original is --64
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org
  Target Milestone: ---

I want to compile only libgcc_s.so in order to put it in a chrooted
environment. I call

/src/gcc-14.2.0/configure --disable-multilib --enable-languages=c
--target=x86_64-unknown-linux-gnu && make all-target-libgcc

Eventually it creates x86_64-unknown-linux-gnu/libgcc, executes there

/src/gcc-14.2.0/libgcc/configure --srcdir=/src/gcc-14.2.0/libgcc
--cache-file=./config.cache --with-cross-host=x86_64-pc-linux-gnu
--disable-multilib --enable-languages=c,lto
--program-transform-name=s&^&x86_64-unknown-linux-gnu-&
--disable-option-checking --disable-year2038
--with-target-subdir=x86_64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu

and this fails, printing

checking whether ln -s works... yes
checking for x86_64-unknown-linux-gnu-gcc...  /src/chroot/gcc1420/./gcc/xgcc
-B/src/chroot/gcc1420/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include   
checking for suffix of object files... configure: error: in
`/src/chroot/gcc1420/x86_64-unknown-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details
make: *** [Makefile:13464: configure-target-libgcc] Error 1


and putting in config.log:

configure:3575:  /src/chroot/gcc1420/./gcc/xgcc -B/src/chroot/gcc1420/./gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include -o conftest -g -O2   conftest.c
 >&5
conftest.c:9:10: fatal error: stdio.h: No such file or directory
9 | #include 
  |  ^
compilation terminated.
configure:3578: $? = 1
configure:3791: checking for suffix of object files
configure:3813:  /src/chroot/gcc1420/./gcc/xgcc -B/src/chroot/gcc1420/./gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86
_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include
-isystem /usr/local/x86_64-unknown-linux-gnu/sys-include
-c -g -O2  conftest.c >&5
/src/chroot/gcc1420/./gcc/as: line 114: exec: --: invalid option
exec: usage: exec [-cl] [-a name] [command [argument ...]] [redirection ...]
configure:3817: $? = 1

/src/chroot/gcc1420/./gcc/as: line 114 is:

exec $original ${1+"$@"} 

and there the parameters to exec expand to 

 --64 -o conftest.o /tmp/ccg2hmj2.s

[Bug bootstrap/117396] New: gcc/configure --help should print --disable-multilib instead of --enable-multilib

[dilyan.palauzov at aegee dot org via Gcc-bugs]

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

Bug ID: 117396
   Summary: gcc/configure --help should print --disable-multilib
instead of --enable-multilib
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org
  Target Milestone: ---

gcc-14.2.0/gcc/configure.ac contains:

AC_ARG_ENABLE(multilib,
[AS_HELP_STRING([--enable-multilib],
[enable library support for multiple ABIs])],
[], [enable_multilib=yes])

That is, if --enable-multilib , --disable-multilib , --enable-multilib=yes or
--enable-multilib=no are not passed, multilib is enabled.

Adjust the output of gcc/configure --help from

  --enable-multilib   enable library support for multiple ABIs

to

  --disable-multilib  disable library support for multiple ABIs

to indicate, that by default this option is enabled.

[Bug c++/117397] New: [modules] ICE in binding_cmp with imported deduction guide

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

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

Bug ID: 117397
   Summary: [modules] ICE in binding_cmp with imported deduction
guide
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nshead at gcc dot gnu.org
  Target Milestone: ---

Consider the following:


  // a.h
  template  struct S;
  template  S(T) -> S;

  // b.h
  import "a.h";
  template  struct S;

  // m.cpp
  module;
  template  struct S;
  export module M;
  import "b.h";
  S foo();


Doing "g++ -fmodules-ts -Wno-global-module -S a.h b.h m.cpp" results in:

m.cpp:3:8: internal compiler error: in binding_cmp, at cp/module.cc:13838
3 | export module M;
  |^~
0x3bd6ca0 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:518
0x3ba363c fancy_abort(char const*, int, char const*)
../../gcc/gcc/diagnostic.cc:1580
0x10bcd9f binding_cmp
../../gcc/gcc/cp/module.cc:13838
0x3c2ee06 cmp1
../../gcc/gcc/sort.cc:151
0x3c2e73e netsort
../../gcc/gcc/sort.cc:168
0x3c2df7d mergesort
../../gcc/gcc/sort.cc:205
0x3c2dc4a gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
../../gcc/gcc/sort.cc:268
0x10bd468 depset::hash::finalize_dependencies()
../../gcc/gcc/cp/module.cc:13922
0x10cb34f module_state::write_begin(elf_out*, cpp_reader*,
module_state_config&, unsigned int&)
../../gcc/gcc/cp/module.cc:18447
0x10d2e53 finish_module_processing(cpp_reader*)
../../gcc/gcc/cp/module.cc:20918
0xff49ff c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.cc:5543
0x13c8de2 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.cc:1370
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.


This appears to be caused by duplicate deduction guides being found by name
lookup when exporting.  The following patch fixes the ICE, but might just be
hiding a more general issue, since I would think that name lookup should have
deduplicated these entries:

diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 297ef85bb1e..7133e754271 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -13684,19 +13684,26 @@ depset::hash::add_deduction_guides (tree decl)
   if (guides == error_mark_node)
 return;

-  /* We have bindings to add.  */
+  /* We have bindings to add.  Note there could be duplicates in
+ the list of entities found by name lookup.  */
   depset *binding = make_binding (ns, name);
   add_namespace_context (binding, ns);

   depset **slot = binding_slot (ns, name, /*insert=*/true);
   *slot = binding;

-  for (lkp_iterator it (guides); it; ++it)
+  hash_table seen_deps (10);
+  for (tree t : lkp_range (guides))
 {
-  gcc_checking_assert (!TREE_VISITED (*it));
-  depset *dep = make_dependency (*it, EK_FOR_BINDING);
-  binding->deps.safe_push (dep);
-  dep->deps.safe_push (binding);
+  tree *slot = seen_deps.find_slot (t, INSERT);
+  if (!*slot)
+{
+  gcc_checking_assert (!TREE_VISITED (t));
+  depset *dep = make_dependency (t, EK_FOR_BINDING);
+  binding->deps.safe_push (dep);
+  dep->deps.safe_push (binding);
+  *slot = t;
+}
 }
 }

[Bug c++/117392] template argument deduction problem with CNTTP

[hanicka at hanicka dot net via Gcc-bugs]

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

--- Comment #3 from Hana Dusíková  ---
Thanks for the workaround!

[Bug libstdc++/117394] evil regex causes a stack overflow and a crash

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
 Blocks||102445

--- Comment #1 from Jonathan Wakely  ---
There are lots of existing bugs about this.

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445
[Bug 102445] [meta-bug] std::regex issues

[Bug libstdc++/61601] C++11 regex resource exhaustion

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||vincent.lebourlot@starqube.
   ||com

--- Comment #12 from Jonathan Wakely  ---
*** Bug 117394 has been marked as a duplicate of this bug. ***

[Bug lto/117388] Mangled name in 'In function' note before warning with LTO

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
How could it?  The LTO FE doesn't know what came from C, what came from C++,
what from various other FEs, and doesn't have a union of all those
manglers/demanglers in it.
Sure, the language is stored in the debug info, but we aren't producing debug
info always...

[Bug libstdc++/117405] New: std::type_info::before() fails the asymmetry requirement

[miki at keeperrl dot com via Gcc-bugs]

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

Bug ID: 117405
   Summary: std::type_info::before() fails the asymmetry
requirement
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: miki at keeperrl dot com
  Target Milestone: ---

Created attachment 59517
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59517&action=edit
Example program that can potentially produce wrong results.

I encountered this bug when compiling using x86_64-w64-mingw32.shared-g++ in
the mxe environment, while using std::set. Looking closely at
the code in libstdc++-v3/ libsupc++/tinfo2.cc, it's obvious that before() is
not symmetric and can potentially give conflicting results for types where one
type's mangled name starts with a '*', and the other one's doesn't, depending
on the order of arguments.

I've attached an example program showing the issue. Note that it requires
specific circumstances to crash, i.e. both __GXX_TYPEINFO_EQUALITY_INLINE and
__GXX_MERGED_TYPEINFO_NAMES set to 0. Even then, I observed one computer
compiling it into an executable that doesn't crash, and another into one that
crashes, presumably depending on how the mangled names are ordered in memory.

I noticed that this implementation of type_info::before() was already discussed
under another bug report, so if this wasn't fixed then maybe I'm missing
something and perhaps my toolchain is misconfigured, in that case I'd
appreciate  any hints on that. This has major impact for me since my software
will only work correctly when cross-compiled on an older machine that I don't
use anymore.

[Bug bootstrap/117407] [15 regression] bootstrap fails after r15-4847-g79a75b1f551821

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

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||build, diagnostic
 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=44209

--- Comment #4 from Eric Gallager  ---
Also, the warning involved here not having its own flag is an example of bug
44209

[Bug bootstrap/109310] --enable-link-mutex is quite duplicate to --enable-link-serialization

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to GCC Commits from comment #3)
> The master branch has been updated by Martin Liska :
> 
> https://gcc.gnu.org/g:8b2766e87dbf0d20808bc92d8e6ee7f876d19ab2
> 
> commit r13-6929-g8b2766e87dbf0d20808bc92d8e6ee7f876d19ab2
> Author: Martin Liska 
> Date:   Wed Mar 29 14:52:42 2023 +0200
> 
> configure: deprecate --enable-link-mutex option
> 
> PR bootstrap/109310
> 
> gcc/ChangeLog:
> 
> * configure.ac: Emit a warning for deprecated option
> --enable-link-mutex.
> * configure: Regenerate.

IMO this should also get a mention in the GCC 13 release notes:
https://gcc.gnu.org/gcc-13/changes.html

[Bug tree-optimization/110361] [13/14/15 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-2020-g16b013c9d9b

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to work||13.1.0

--- Comment #4 from Andrew Pinski  ---
Looks like this was fixed sometime after r13-2020-g16b013c9d9b but before the
release of GCC 13.

[Bug tree-optimization/110361] [13/14/15 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-2020-g16b013c9d9b

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

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

--- Comment #5 from Sam James  ---
(In reply to Andrew Pinski from comment #4)
> Looks like this was fixed sometime after r13-2020-g16b013c9d9b but before
> the release of GCC 13.

I'll bisect when I'm done with another.

[Bug bootstrap/117396] gcc/configure --help should print --disable-multilib instead of --enable-multilib

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

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||build, documentation
 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
If this had been fixed previously, I probably wouldn't have gotten in the habit
of making my configure lines as long as I currently do!

[Bug c++/114461] [C++26] P3034R1 - Disallow module declarations to be macros

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:1ae24f7e0bdbdeaef9265a053a737af11f8393d2

commit r15-4848-g1ae24f7e0bdbdeaef9265a053a737af11f8393d2
Author: Jakub Jelinek 
Date:   Fri Nov 1 19:42:28 2024 +0100

c++: Attempt to implement C++26 P3034R1 - Module Declarations Shouldn't be
Macros [PR114461]

This is an attempt to implement the https://wg21.link/p3034r1 paper,
but I'm afraid the wording in the paper is bad for multiple reasons.
I think I understand the intent, that the module name and partition
if any shouldn't come from macros so that they can be scanned for
without preprocessing, but on the other side doesn't want to disable
macro expansion in pp-module altogether, because e.g. the optional
attribute in module-declaration would be nice to come from macros
as which exact attribute is needed might need to be decided based on
preprocessor checks.
The paper added https://eel.is/c++draft/cpp.module#2
which uses partly the wording from https://eel.is/c++draft/cpp.module#1

The first issue I see is that using that "defined as an object-like macro"
from there means IMHO something very different in those 2 paragraphs.
As per https://eel.is/c++draft/cpp.pre#7.sentence-1 preprocessing tokens
in preprocessing directives aren't subject to macro expansion unless
otherwise stated, and so the export and module tokens aren't expanded
and so the requirement that they aren't defined as an object-like macro
makes perfect sense.  The problem with the new paragraph is that
https://eel.is/c++draft/cpp.module#3.sentence-1 says that the rest of
the tokens are macro expanded and after macro expansion none of the
tokens can be defined as an object-like macro, if they would be, they'd
be expanded to that.  So, I think either the wording needs to change
such that not all preprocessing tokens after module are macro expanded,
only those which are after the pp-module-name and if any
pp-module-partition
tokens, or all tokens after module are macro expanded but none of the
tokens in
pp-module-name and pp-module-partition if any must come from macro
expansion.  The patch below implements it as if the former would be
specified (but see later), so essentially scans the preprocessing tokens
after module without expansion, if the first one is an identifier, it
disables expansion for it and then if followed by . or : expects another
such identifier (again with disabled expansion), but stops after second
: is seen.

Second issue is that while the global-module-fragment start is fine,
matches
the syntax of the new paragraph where the pp-tokens[opt] aren't present,
there is also private-module-fragment in the syntax where module is
followed by : private ; and in that case the colon doesn't match the
pp-module-name grammar and appears now to be invalid.  I think the
https://eel.is/c++draft/cpp.module#2
paragraph needs to change so that it allows also that pp-tokens of
a pp-module may also be : pp-tokens[opt] (and in that case, I think
the colon shouldn't come from a macro and private and/or ; can).

Third issue is that there are too many pp-tokens in
https://eel.is/c++draft/cpp.module , one is all the tokens between
module keyword and the semicolon and one is the optional extra tokens
after pp-module-partition (if any, if missing, after pp-module).
Perhaps introducing some other non-terminal would help talking about it?
So in "where the pp-tokens (if any) shall not begin with a ( preprocessing
token" it isn't obvious which pp-tokens it is talking about (my assumption
is the latter) and also whether ( can't appear there just before macro
expansion or also after expansion.  The patch expects only before
expansion,
so
 #define F ();
 export module foo F
would be valid during preprocessing but obviously invalid during
compilation, but
 #define foo(n) n;
 export module foo (3)
would be invalid already during preprocessing.

The last issue applies only if the first issue is resolved to allow
expansion of tokens after : if first token, or after pp-module-partition
if present or after pp-module-name if present.  When non-preprocessing
scanner sees
 export module foo.bar:baz.qux;
it knows nothing can come from preprocessing macros and is ok, but if it
sees
 export module foo.bar:baz qux
then it can't know whether it will be
 export module foo.bar:baz;
or
 export module foo.bar:baz [[]];
or
 export module foo.bar:baz.freddy.garply;
because qux could be validly a macro, which expands to ; or [[]];
or .freddy.garply; etc.  So, either the non-preprocessing scanner would
need to note it as possible export of foo.bar:baz* module partitio

[Bug web/117401] Spell that ./configure --enable-link-mutex is deprecated

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to Jakub Jelinek from comment #1)
> We should just remove the option, it has been deprecated already in GCC 13.

I don't see that mentioned in its release notes:
https://gcc.gnu.org/gcc-13/changes.html

[Bug web/117401] Spell that ./configure --enable-link-mutex is deprecated

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

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

--- Comment #3 from Jakub Jelinek  ---
That doesn't really matter.  Anybody who used the option in GCC 13/14 got that
deprecation message.

[Bug libstdc++/117406] std::ilogb should return INT_MAX when argument is infinite also for 16-bit floats

[pkeir at outlook dot com via Gcc-bugs]

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

--- Comment #3 from Paul Keir  ---
At least for ilogb.

[Bug c++/117410] Ambiguous overload with ellipsis

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-01
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Reduced with no headers:
```

template 
concept is_void_t = true;

template 
bool foo() { return false; }

template 
requires is_void_t
bool foo(...) { return true; }

template 
bool bar() { return false; }

template 
requires (x == 0)
bool bar(...) { return true; }

int main() {
(foo());
(bar());
}
```

MSVC, clang and EDG all accepts this so it does look like maybe a GCC bug.

Without variadic arguments, GCC accepts it.

[Bug modula2/117411] New: Request for documentation to include exception example

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

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

Bug ID: 117411
   Summary: Request for documentation to include exception example
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

Forwarding a request from the gm2 mailing list:

> Where I can find more information about exceptions handling in GM2? I
> mean documentation, examples etc.

[Bug gcov-profile/117415] Bogus execution count for assignment to *func()

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=117412

--- Comment #1 from Andrew Pinski  ---
I think this is the same underlying issue as PR 117412.

[Bug gcov-profile/117415] New: Bogus execution count for assignment to *func()

[wentaoz5 at illinois dot edu via Gcc-bugs]

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

Bug ID: 117415
   Summary: Bogus execution count for assignment to *func()
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wentaoz5 at illinois dot edu
  Target Milestone: ---

I hit the issue when dealing with
https://github.com/apache/httpd/blob/2.4.62/server/mpm_unix.c#L901. After
reduction, I ended up with two variants with slightly different triggering
conditions. See comments in code for details.

How to reproduce:

$ gcc --version

gcc (GCC) 15.0.0 20240923 (experimental)
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat > test.c << 'EOF'
int arr[10];

int *foo() {
return arr;
}

int bar() {
return 0;
}

int main(void) {
int *a = arr;
int zero = 0;

if (zero) {} else {
// Variant 1 triggering conditions:
//
// 1. RHS of assignment is a function call
// 2. The first function name and assignment are put in one line;
//the second function name is put in the other line
// 3. Inside if(){...}, else{...}, for(){...} etc
*foo()=
bar();
}

// Variant 2 triggering conditions:
//
// 1. RHS of assignment is a dereference
// 2. The function name and assignment are put in one line; the second
//dereference is put in the other line
// 3. The operand of dereference is referenced elsewhere
*foo()=
*a;
&a;

return 0;
}
EOF
$ gcc --coverage test.c -o test
$ ./test
$ gcov test
$ cat test.c.gcov
...
2:   22:*foo()=
1:   23:bar();
...
2:   32:*foo()=
1:   33:*a;
...

Line 22 and 32 are reported to executed twice, which is hard to interpret.

[Bug gcov-profile/92259] ICE with lto and auto-profile cp/mangle.c:1641 write_closure_type_name

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

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

--- Comment #3 from Sam James  ---
I wonder if this is the same issue as Andi was looking at, actually.

BTW: I note that you were using Gentoo -- were you working on any sort of
integration of autofdo with Portage? I'm open to looking into this if I can
package autofdo without too much hackery.

[Bug ipa/117350] [15 Regression] ICE with autoprofiledbootstrap and bootstrap-lto after r15-4610-gbf43fe6aa966ea

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

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

Sam James  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #22 from Sam James  ---
https://inbox.sourceware.org/gcc-patches/20241031204043.3231740-1...@linux.intel.com/T/#u

[Bug gcov-profile/92259] ICE with lto and auto-profile cp/mangle.c:1641 write_closure_type_name

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Sam James from comment #3)
> I wonder if this is the same issue as Andi was looking at, actually.

Most likely very the same issue overall. Considering need_assembler_name_p has
been around for a long time now.

[Bug tree-optimization/117287] [13/14/15 Regression] assume attribute related miscompilation

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Andrew Macleod :

https://gcc.gnu.org/g:62420dbd105bbc4fe732881875c5c85aa55b6069

commit r15-4851-g62420dbd105bbc4fe732881875c5c85aa55b6069
Author: Andrew MacLeod 
Date:   Mon Oct 28 10:19:27 2024 -0400

Reimplement 'assume' processing pass.

Rework the assume pass to work properly and fail conservatively when it
does.  Also move it to its own file.

PR tree-optimization/117287
gcc/
* Makefile.in (IBJS): Add tree-assume.o
* gimple-range.cc (assume_query::assume_range_p): Remove.
(assume_query::range_of_expr): Remove.
(assume_query::assume_query): Move to tree-assume.cc.
(assume_query::~assume_query): Remove.
(assume_query::calculate_op): Move to tree-assume.cc.
(assume_query::calculate_phi): Likewise.
(assume_query::check_taken_edge): Remove.
(assume_query::calculate_stmt): Move to tree-assume.cc.
(assume_query::dump): Remove.
* gimple-range.h (class assume_query): Move to tree-assume.cc
* tree-assume.cc: New
* tree-vrp.cc (struct pass_data_assumptions): Move to
tree-assume.cc.
(class pass_assumptions): Likewise.
(make_pass_assumptions): Likewise.

gcc/testsuite/
* g++.dg/cpp23/pr117287-attr.C: New.

[Bug bootstrap/117407] New: [15 regression] bootstrap fails after r15-4847-g79a75b1f551821

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

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

Bug ID: 117407
   Summary: [15 regression] bootstrap fails after
r15-4847-g79a75b1f551821
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:79a75b1f551821687e1ce27a82ee39b802ace2b4, r15-4847-g79a75b1f551821

/bin/sh ../libtool  --tag=CC   --mode=compile
/home/seurer/gcc/git/build/gcc-test/./gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/./gcc/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
   -DHAVE_CONFIG_H -I.
-I/home/seurer/gcc/git/gcc-test/libsanitizer/libbacktrace -I..  -I
/home/seurer/gcc/git/gcc-test/libsanitizer/../include -I
/home/seurer/gcc/git/gcc-test/libsanitizer/../libgcc -I ../../libgcc -I .. -I
/home/seurer/gcc/git/gcc-test/libsanitizer -I
/home/seurer/gcc/git/gcc-test/libsanitizer/../libbacktrace  -Wextra -Wall
-Wwrite-strings -Wmissing-format-attribute -Wcast-qual -Werror
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -g -O2 -MT
elf.lo -MD -MP -MF .deps/elf.Tpo -c -o elf.lo `test -f
'../../libbacktrace/elf.c' || echo
'/home/seurer/gcc/git/gcc-test/libsanitizer/libbacktrace/'`../../libbacktrace/elf.c
libtool: compile:  /home/seurer/gcc/git/build/gcc-test/./gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/./gcc/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
-DHAVE_CONFIG_H -I. -I/home/seurer/gcc/git/gcc-test/libsanitizer/libbacktrace
-I.. -I /home/seurer/gcc/git/gcc-test/libsanitizer/../include -I
/home/seurer/gcc/git/gcc-test/libsanitizer/../libgcc -I ../../libgcc -I .. -I
/home/seurer/gcc/git/gcc-test/libsanitizer -I
/home/seurer/gcc/git/gcc-test/libsanitizer/../libbacktrace -Wextra -Wall
-Wwrite-strings -Wmissing-format-attribute -Wcast-qual -Werror
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -g -O2 -MT
elf.lo -MD -MP -MF .deps/elf.Tpo -c
/home/seurer/gcc/git/gcc-test/libsanitizer/libbacktrace/../../libbacktrace/elf.c
 -fPIC -DPIC -o .libs/elf.o
In function 'elf_fetch_bits',
inlined from 'elf_zstd_read_fse' at
/home/seurer/gcc/git/gcc-test/libsanitizer/libbacktrace/../../libbacktrace/elf.c:2752:8:
/home/seurer/gcc/git/gcc-test/libsanitizer/libbacktrace/../../libbacktrace/elf.c:1158:3:
error: invalid second argument to '__builtin_prefetch'; using zero [-Werror]
 1158 |   __builtin_prefetch (pin, 0, 0);
  |   ^~
/home/seurer/gcc/git/gcc-test/libsanitizer/libbacktrace/../../libbacktrace/elf.c:1158:3:
error: invalid third argument to '__builtin_prefetch'; using zero [-Werror]
In function 'elf_fetch_bits',
inlined from 'elf_zstd_read_fse' at
/home/seurer/gcc/git/gcc-test/libsanitizer/libbacktrace/../../libbacktrace/elf.c:2789:12:
/home/seurer/gcc/git/gcc-test/libsanitizer/libbacktrace/../../libbacktrace/elf.c:1158:3:
error: invalid second argument to '__builtin_prefetch'; using zero [-Werror]
 1158 |   __builtin_prefetch (pin, 0, 0);
  |   ^~
/home/seurer/gcc/git/gcc-test/libsanitizer/libbacktrace/../../libbacktrace/elf.c:1158:3:
error: invalid third argument to '__builtin_prefetch'; using zero [-Werror]
In function 'elf_fetch_bits',
inlined from 'elf_zstd_read_fse' at
/home/seurer/gcc/git/gcc-test/libsanitizer/libbacktrace/../../libbacktrace/elf.c:2805:14:
/home/seurer/gcc/git/gcc-test/libsanitizer/libbacktrace/../../libbacktrace/elf.c:1158:3:
error: invalid second argument to '__builtin_prefetch'; using zero [-Werror]
 1158 |   __builtin_prefetch (pin, 0, 0);
  |   ^~
/home/seurer/gcc/git/gcc-test/libsanitizer/libbacktrace/../../libbacktrace/elf.c:1158:3:
error: invalid third argument to '__builtin_prefetch'; using zero [-Werror]
In function 'elf_fetch_bits',
inlined from 'elf_zstd_read_fse' at
/home/seurer/gcc/git/gcc-test/libsanitizer/libbacktrace/../../libbacktrace/elf.c:2813:13:
/home/seurer/gcc/git/gcc-test/libsanitizer/libbacktrace/../../libbacktrace/elf.c:1158:3:
error: invalid second argument to '__builtin_prefetch'; using zero [-Werror]
 1158 |   __builtin_prefetch (pin, 0, 0);
  |   ^~
/home/seurer/gcc/git/gcc-test/libsanitizer/libbacktrace/../../libbacktrace/elf.c:1158:3:
error: invalid third argument to '__builtin_prefetch'; using zero [

[Bug bootstrap/117401] Spell that ./configure --enable-link-mutex is deprecated

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
So just a dup of bug 109310.

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

[Bug bootstrap/109310] --enable-link-mutex is quite duplicate to --enable-link-serialization

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||dilyan.palauzov at aegee dot 
org

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

[Bug c++/55189] enable -Wreturn-type by default

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #14 from Sam James  ---
Note that we also now have -Wreturn-mismatch for C and it's an error by default
too.

[Bug target/113946] Switch ft32 to LRA

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #3 from Sam James  ---
r15-4859-g4a5a63596dd82d

[Bug ipa/117350] [15 Regression] ICE with autoprofiledbootstrap and bootstrap-lto after r15-4610-gbf43fe6aa966ea

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

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

--- Comment #23 from Andrew Pinski  ---
See reading https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64346#c4 seems like
this has basically been a known issue with autofdo and constructors due to
thunks and clones from the front-end.

[Bug gcov-profile/117415] Bogus execution count for assignment to *func()

[wentaoz5 at illinois dot edu via Gcc-bugs]

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

--- Comment #2 from Wentao Zhang  ---
(In reply to Andrew Pinski from comment #1)
> I think this is the same underlying issue as PR 117412.

Hi Andrew, thanks for your reply!

In practice we've seen many such cases caused by multi-line expressions.
Internally we have been triaging based on the minimal language constructs
needed to reproduce the behavior (triggering conditions). That's why I filed
two different bug reports. Do you have suggestions for triaging or debugging in
general?

Thanks!

[Bug target/113932] [meta-bug] Targets which should be ported to LRA

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

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

Bug 113946 Summary: Switch ft32 to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113946

   What|Removed |Added

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

[Bug bootstrap/117407] [15 regression] bootstrap fails after r15-4847-g79a75b1f551821

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-01
   Priority|P3  |P1
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-Novembe
   ||r/667236.html
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Target Milestone|--- |15.0
 CC||jakub at gcc dot gnu.org

[Bug libstdc++/111055] [C++23] Implement P1206R7, Conversions from ranges to containers

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:7a4fced2b122bde47fed2d99fb8e3cf197f9c46f

commit r15-4853-g7a4fced2b122bde47fed2d99fb8e3cf197f9c46f
Author: Jonathan Wakely 
Date:   Tue Oct 8 21:15:18 2024 +0100

libstdc++: Add P1206R7 from_range members to std::list and
std::forward_list [PR111055]

This is another piece of P1206R7, adding new members to std::list and
std::forward_list.

libstdc++-v3/ChangeLog:

PR libstdc++/111055
* include/bits/forward_list.h
(forward_list(from_range, R&&, const Alloc&), assign_range)
(prepend_range, insert_range_after): Define.
* include/bits/stl_list.h (list(from_range, R&&, const Alloc&))
(assign_range, prepend_range, append_range, insert_range):
Define.
* include/debug/forward_list
(forward_list(from_range, R&&, const Alloc&), assign_range)
(prepend_range, insert_range_after): Define.
* include/debug/list (list(from_range, R&&, const Alloc&))
(assign_range, prepend_range, append_range, insert_range):
Define.
* testsuite/23_containers/forward_list/cons/from_range.cc: New
test.
* testsuite/23_containers/forward_list/modifiers/assign_range.cc:
New test.
*
testsuite/23_containers/forward_list/modifiers/insert_range_after.cc:
New test.
* testsuite/23_containers/forward_list/modifiers/prepend_range.cc:
New test.
* testsuite/23_containers/list/cons/from_range.cc: New test.
* testsuite/23_containers/list/modifiers/append_range.cc: New
test.
* testsuite/23_containers/list/modifiers/assign/assign_range.cc:
New test.
* testsuite/23_containers/list/modifiers/insert/insert_range.cc:
New test.
* testsuite/23_containers/list/modifiers/prepend_range.cc: New
test.

Reviewed-by: Patrick Palka 

[Bug other/117409] New: ASAN issues compiling gfortran.dg/diagnostic-format-sarif-pr105916.f90

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

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

Bug ID: 117409
   Summary: ASAN issues compiling
gfortran.dg/diagnostic-format-sarif-pr105916.f90
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
Blocks: 86656
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu

With ASAN instrumented gfortran configured as:

  src/configure --prefix=/home/mjambor/gcc/mine/inst
--enable-languages=c,c++,fortran --enable-checking=release --enable-host-shared
--disable-multilib --with-build-config=bootstrap-asan

ASAN reports a heap-use-after-free problem when building our test
gcc/testsuite/gfortran.dg/diagnostic-format-sarif-pr105916.f90:

spawn -ignore SIGHUP
/home/mjambor/gcc/mine/b-obj/gcc/testsuite/gfortran/../../gfortran
-B/home/mjambor/gcc/mine/b-obj/gcc/testsuite/gfortran/../../
-B/home/mjambor/gcc/mine/b-obj/x86_64-pc-linux-gnu/./libgfortran/
/home/mjambor/gcc/mine/src/gcc/testsuite/gfortran.dg/diagnostic-format-sarif-pr105916.f90
-fdiagnostics-plain-output -fdiagnostics-plain-output -O
-fdiagnostics-format=sarif-file -fmax-errors=1 -Wfatal-errors -S -o
diagnostic-format-sarif-pr105916.s
=
==459442==ERROR: AddressSanitizer: heap-use-after-free on address
0x5080b820 at pc 0x008b0639 bp 0x7ffcd5925440 sp 0x7ffcd5924c00
READ of size 1 at 0x5080b820 thread T0
#0 0x8b0638 in strcmp
/home/mjambor/gcc/mine/src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:470
#1 0x61b7794 in file_cache::lookup_file(char const*)
/home/mjambor/gcc/mine/src/gcc/input.cc:324
#2 0x61baa11 in file_cache::lookup_or_add_file(char const*)
/home/mjambor/gcc/mine/src/gcc/input.cc:538
#3 0x61baae9 in file_cache::get_source_file_content(char const*)
/home/mjambor/gcc/mine/src/gcc/input.cc:1050
#4 0x6155bbe in sarif_builder::maybe_make_artifact_content_object(char
const*) const /home/mjambor/gcc/mine/src/gcc/diagnostic-format-sarif.cc:3189
#5 0x615623a in sarif_artifact::populate_contents(sarif_builder&)
/home/mjambor/gcc/mine/src/gcc/diagnostic-format-sarif.cc:1023
#6 0x6167c4c in
sarif_builder::make_run_object(std::unique_ptr >, std::unique_ptr >)
/home/mjambor/gcc/mine/src/gcc/diagnostic-format-sarif.cc:2960
#7 0x6168df8 in
sarif_builder::make_top_level_object(std::unique_ptr >, std::unique_ptr >)
/home/mjambor/gcc/mine/src/gcc/diagnostic-format-sarif.cc:2914
#8 0x616946e in sarif_builder::flush_to_object()
/home/mjambor/gcc/mine/src/gcc/diagnostic-format-sarif.cc:1794
#9 0x6169656 in sarif_builder::flush_to_file(_IO_FILE*)
/home/mjambor/gcc/mine/src/gcc/diagnostic-format-sarif.cc:1806
#10 0x61767a6 in sarif_file_output_format::~sarif_file_output_format()
/home/mjambor/gcc/mine/src/gcc/diagnostic-format-sarif.cc:3510
#11 0x61767a6 in sarif_file_output_format::~sarif_file_output_format()
/home/mjambor/gcc/mine/src/gcc/diagnostic-format-sarif.cc:3511
#12 0x613d834 in diagnostic_context::finish()
/home/mjambor/gcc/mine/src/gcc/diagnostic.cc:386
#13 0x7fb744 in diagnostic_finish(diagnostic_context*)
/home/mjambor/gcc/mine/src/gcc/diagnostic.h:1029
#14 0x7fb744 in toplev::main(int, char**)
/home/mjambor/gcc/mine/src/gcc/toplev.cc:2395
#15 0x808add in main /home/mjambor/gcc/mine/src/gcc/main.cc:39
#16 0x7f12c762a2ad in __libc_start_call_main (/lib64/libc.so.6+0x2a2ad)
(BuildId: 03f1631dc9760d3e30311fe62e15cc4baaa89db7)
#17 0x7f12c762a378 in __libc_start_main@@GLIBC_2.34
(/lib64/libc.so.6+0x2a378) (BuildId: 03f1631dc9760d3e30311fe62e15cc4baaa89db7)
#18 0x80a4a4 in _start ../sysdeps/x86_64/start.S:115

0x5080b820 is located 0 bytes inside of 90-byte region
[0x5080b820,0x5080b87a)
freed by thread T0 here:
#0 0x8f179b in free
/home/mjambor/gcc/mine/src/libsanitizer/asan/asan_malloc_linux.cpp:52
#1 0xc29742 in gfc_scanner_done_1()
/home/mjambor/gcc/mine/src/gcc/fortran/scanner.cc:296

previously allocated by thread T0 here:
#0 0x8f2c23 in malloc
/home/mjambor/gcc/mine/src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x6355e2b in xmalloc /home/mjambor/gcc/mine/src/libiberty/xmalloc.c:149

SUMMARY: AddressSanitizer: heap-use-after-free
/home/mjambor/gcc/mine/src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:470
in strcmp
Shadow bytes around the buggy address:
  0x5080b580: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 fa
  0x5080b600: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 02
  0x5080b680: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 fa
  0x5080b700: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 fa
  0x5080b780: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 fa
=>0x5080b800: f

[Bug c++/117309] [Docs] C++23 is not mentioned on the "supported standards" doc page

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug c++/117345] internal compiler error: Segmentation fault at maybe_begin_member_template_processing(tree_node*)

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||3.4.6
   Keywords|error-recovery  |

--- Comment #2 from Andrew Pinski  ---
Reduced down to (making it more C++98 like, removing the `decltype(auto)`):
```
struct X {
  template static void g0(T x);
};
template class A {
  friend void X::g0 >(A = 0);
};
```

we started to rejecting default arguments for friends (without -fpermissive) in
GCC 9. But the ICE has been there since at least GCC 3.4.6, I can't test any
older though.

[Bug c++/117400] ICE on invalid requires clause of generic lambda

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-01
Summary|ICE on invalid requires |ICE on invalid requires
   |clause of generic lambda in |clause of generic lambda
   |function template   |
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Reduced:
```
auto t = [](auto) requires {} {};
```

Does not need to be inside a template to get the ICE.

[Bug c++/117410] Ambiguous overload with variadic arguments

[ddvamp007 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Artyom Kolpakov  ---
(In reply to Jonathan Wakely from comment #2)
> But without the variadic arguments, the functions have equivalent function
> parameter lists, so the constraints are checked. With the ellipsis, they do
> not have equivalent function parameter lists, so the constraints are ignored.

I could not find any mention in the standard of how exactly length of function
parameter list is determined. It is unclear whether and how an ellipsis or a
function parameter pack are included in this length ([dcl.fct#4]). It is also
unclear which parameter list is mentioned in [temp.func.order#6.1].

Is this a new core Issue?

[Bug c++/117410] Ambiguous overload with variadic arguments

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> I think the reason GCC rejects the original one is because it's the only
> compiler that correctly implements P2113.

Clang apparently supports P2113 since version 16.

[Bug middle-end/117376] Spammy -Wstringop-overflow output with memcpy

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

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

--- Comment #1 from Andrew Pinski  ---
I think there is a missing check to see if the warning was emitted before the
inform.

I have seen the "note: destination object" diagnostic without a warning before
too.

[Bug middle-end/117376] Spammy -Wstringop-overflow output with memcpy

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

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

--- Comment #2 from Andrew Pinski  ---
I suspect there are some missing auto_diagnostic_group usage in 
gimple-array-bounds.cc
gimple-ssa-warn-access.cc
pointer-query.cc
tree-ssa-strlen.cc

[Bug rtl-optimization/20242] Pessimizing effects of defining EXTRA_MEMORY_CONSTRAINT

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #7 from Hans-Peter Nilsson  ---
(In reply to Andrew Pinski from comment #6)
> I am not sure if this specific issue applies any more since the move to IRA
> and LRA. And even more EXTRA_MEMORY_CONSTRAINT support was removed in
> r5-1241-g777e635f1a6cab and memory constraints are handled in the .md file
> now.

Wow, this is *old*.  Right; this is now a WONTFIX.

[Bug tree-optimization/117279] std::string bounds check from -D_GLIBCXX_ASSERTIONS not optimised out

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

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

Sam James  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #5 from Sam James  ---
I don't get why modref can't do it given it's very similar to the example in
r12-5439-g0f5afb626381d1?

[Bug target/80881] Implement Windows native TLS

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Julian Waters  changed:

   What|Removed |Added

  Attachment #59322|0   |1
is obsolete||

--- Comment #71 from Julian Waters  ---
Created attachment 59516
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59516&action=edit
Latest TLS

[Bug middle-end/117376] Spammy -Wstringop-overflow output with memcpy

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

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

--- Comment #3 from Sam James  ---
(In reply to Andrew Pinski from comment #2)
> I suspect there are some missing auto_diagnostic_group usage in 
> gimple-array-bounds.cc
> gimple-ssa-warn-access.cc
> pointer-query.cc
> tree-ssa-strlen.cc

Let me try.

[Bug tree-optimization/117414] missing predicated VN due to combining if statements

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This seems easy to add.

[Bug c++/117410] Ambiguous overload with variadic arguments

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

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

--- Comment #2 from Jonathan Wakely  ---
But without the variadic arguments, the functions have equivalent function
parameter lists, so the constraints are checked. With the ellipsis, they do not
have equivalent function parameter lists, so the constraints are ignored.

That was specified by https://wg21.link/P2113 and implemented by
r11-1571-g57b4daf8dc4ed7

Since the constraints are not checked, we can remove them without changing the
meaning of the program:


template 
bool foo() { return false; }

template 
bool foo(...) { return true; }

template 
bool bar() { return false; }

template 
bool bar(...) { return true; }

int main() {
(foo());
(bar());
}


All compilers agree that this is ambiguous.

I think the reason GCC rejects the original one is because it's the only
compiler that correctly implements P2113.

[Bug target/117408] ICE on `#pragma arm "arm_mve.h" false`

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

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

Torbjorn SVENSSON  changed:

   What|Removed |Added

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

--- Comment #1 from Torbjorn SVENSSON  ---
Possible fix:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/667254.html

[Bug c++/115560] ICE: in type_dependent_expression_p, at cp/pt.cc:28576

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection,
   ||needs-testcase
 Ever confirmed|0   |1
  Known to work||15.0
   Last reconfirmed||2024-11-01
 Status|UNCONFIRMED |NEW
  Known to fail||14.2.0

--- Comment #1 from Andrew Pinski  ---
Looks like this one has been fixed.

[Bug bootstrap/117407] [15 regression] bootstrap fails after r15-4847-g79a75b1f551821

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:115ab8d7ad33a7f500460dc5af28f6912ddfb91c

commit r15-4856-g115ab8d7ad33a7f500460dc5af28f6912ddfb91c
Author: Jakub Jelinek 
Date:   Fri Nov 1 23:03:48 2024 +0100

builtins: Fix expand_builtin_prefetch [PR117407]

On Fri, Nov 01, 2024 at 04:47:35PM +0800, Haochen Jiang wrote:
> * builtins.cc (expand_builtin_prefetch): Use IN_RANGE to
>   avoid second usage of INTVAL.

I doubt this has been actually tested.

> --- a/gcc/builtins.cc
> +++ b/gcc/builtins.cc
> @@ -1297,7 +1297,7 @@ expand_builtin_prefetch (tree exp)
>else
>  op1 = expand_normal (arg1);
>/* Argument 1 must be 0, 1 or 2.  */
> -  if (INTVAL (op1) < 0 || INTVAL (op1) > 2)
> +  if (IN_RANGE (INTVAL (op1), 0, 2))
>  {
>warning (0, "invalid second argument to %<__builtin_prefetch%>;"
>  " using zero");
> @@ -1315,7 +1315,7 @@ expand_builtin_prefetch (tree exp)
>else
>  op2 = expand_normal (arg2);
>/* Argument 2 must be 0, 1, 2, or 3.  */
> -  if (INTVAL (op2) < 0 || INTVAL (op2) > 3)
> +  if (IN_RANGE (INTVAL (op2), 0, 3))
>  {
>warning (0, "invalid third argument to %<__builtin_prefetch%>;
using zero");
>op2 = const0_rtx;

because it inverts the tests, previously it was warning when op1 wasn't
0, 1, 2, now it warns when it is 0, 1 or 2, previously it was warning
when op2 wasn't 0, 1, 2 or 3, now it warns when it is 0, 1, 2, or 3.

Fixed thusly.

2024-11-01  Jakub Jelinek  

PR bootstrap/117407
* builtins.cc (expand_builtin_prefetch): Use !IN_RANGE rather
than IN_RANGE.

[Bug c++/117309] [Docs] C++23 is not mentioned on the "supported standards" doc page

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Andrew Pinski  ---
Fixed by:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=d949b94ea0c4206c5188a38aa045729cfc149386