[Bug tree-optimization/110702] [12 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||aegges at web dot de

--- Comment #9 from Richard Biener  ---
*** Bug 111517 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/111517] [12/13 Regression] Optimization -O1 removes necessary loop for initialization since r12-5915-ge93809f62363ba

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
duplicate

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

[Bug target/111533] [14 Regression] ICE: RTL check: expected code 'reg', have 'const_int' in rhs_regno, at rtl.h:1934

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 Target||riscv

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

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

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

--- Comment #1 from Richard Biener  ---
Hm, but the COLLECT_GCC_OPTIONS variable is only used for communicating between
the driver and the linker, the options therein are individually passed to the
program execved?

You are maybe looking for the -f*-map options to take a file as input
containing multiple mappings?

[Bug tree-optimization/110817] [14 Regression] wrong code with vector compares and vector lowering

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

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

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

[Bug target/111534] [14 Regression] wrong code with -mgeneral-regs-only and vector compare

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
  _5 = BIT_FIELD_REF <_1, 8, 0>;
  _6 = _5 != 0;
  _7 = _5 == 0;
  _8 = (signed char) _7;
  _9 = (signed char) _5;
  _10 = _9 + -1;

It is the same.

>here only a target option impacts the behavior
Because -mgeneral-regs-only basically is -mno-sse which also shows the issue. 
Basicaly is the lowering of the vector comparison (combined with the referenced
match pattern in the other bug report) which is causing the issue.

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

[Bug target/111534] New: [14 Regression] wrong code with -mgeneral-regs-only and vector compare

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 111534
   Summary: [14 Regression] wrong code with -mgeneral-regs-only
and vector compare
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 55966
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55966=edit
reduced testcase

This might be the same as PR110817, but here only a target option impacts the
behavior, and no other optimizations are enabled.

$ x86_64-pc-linux-gnu-gcc -mgeneral-regs-only testcase.c && ./a.out
Aborted

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-4218-20230922114852-ge446ed29f6c-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-4218-20230922114852-ge446ed29f6c-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230922 (experimental) (GCC)

[Bug target/111451] RISC-V: Missed optimization of vrgather.vv into vrgatherei16.vv

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Li Xu :

https://gcc.gnu.org/g:0ed05db7cee8f92604b5d7761713b7a7161e0db0

commit r14-4219-g0ed05db7cee8f92604b5d7761713b7a7161e0db0
Author: xuli 
Date:   Fri Sep 22 01:25:39 2023 +

RISC-V: Optimization of vrgather.vv into vrgatherei16.vv[PR111451]

Consider this following case:

typedef int32_t vnx32si __attribute__ ((vector_size (128)));

  __attribute__ ((noipa)) void permute_##TYPE (TYPE values1, TYPE values2, 
   \
   TYPE *out)  
   \
  {
   \
TYPE v 
   \
  = __builtin_shufflevector (values1, values2, MASK_##NUNITS (0,
NUNITS)); \
*(TYPE *) out = v; 
   \
  }

  T (vnx32si, 32)  
   \

TEST_ALL (PERMUTE)

Before this patch:
  lia4,31
  vsetvli   a5,zero,e32,m8,ta,ma
  vl8re32.v v24,0(a0)
  vid.v v8
  vrsub.vx  v8,v8,a4
  vrgather.vv   v16,v24,v8
  vs8r.vv16,0(a2)
  ret

The index vector register "v8" occupies 8 registers.
We should optimize it into vrgatherei16.vv which is
using int16 as the index elements.

After this patch:
  vsetvli   a5,zero,e16,m4,ta,ma
  lia4,31
  vid.v v4
  vl8re32.v v16,0(a0)
  vrsub.vx  v4,v4,a4
  vsetvli   zero,zero,e32,m8,ta,ma
  vrgatherei16.vv   v8,v16,v4
  vs8r.vv8,0(a2)
  ret
With vrgatherei16.vv, the v8 will occupy 4 registers instead
of 8. Lower the register consuming and register pressure.

PR target/111451

gcc/ChangeLog:

* config/riscv/riscv-v.cc (emit_vlmax_gather_insn): Optimization of
vrgather.vv
into
vrgatherei16.vv.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/vls-vlmax/perm-4.c: Adjust case.
* gcc.target/riscv/rvv/autovec/vls/perm-4.c: Ditto.

[Bug c++/111532] tuple get accesses through base element type in constant expression

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 55965
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55965=edit
Reduced testcase

It is __no_unique_address__ and empty base class related ...

[Bug target/111533] New: [14 Regression] ICE: RTL check: expected code 'reg', have 'const_int' in rhs_regno, at rtl.h:1934

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 111533
   Summary: [14 Regression] ICE: RTL check: expected code 'reg',
have 'const_int' in rhs_regno, at rtl.h:1934
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Broken on trunk: r14-4211-g29862e21f6d

Bisected to/Caused by: r14-3508-ge030af3e6f6

rv64gcv fails to build glibc with --enable-checking=rtl
This same failure/backtrace shows up on rv32gc with testcases like
gcc.target/riscv/rvv/autovec/reduc/reduc_call-1.c with --enable-checking=rtl.

Backtrace (from run using r14-4211-g29862e21f6d):

during RTL pass: vsetvl
res_debug.c: In function '__dn_count_labels':
res_debug.c:1050:1: internal compiler error: RTL check: expected code 'reg',
have 'const_int' in rhs_regno, at rtl.h:1934
 1050 | }
  | ^
0x90a441 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
../../../gcc/gcc/rtl.cc:770
0x941ad7 rhs_regno(rtx_def const*)
../../../gcc/gcc/rtl.h:1934
0x942458 rhs_regno(rtx_def const*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:314
0x942458 anticipatable_occurrence_p
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:348
0x942458 pass_vsetvl::compute_local_properties()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3215
0x1680d25 pass_vsetvl::vsetvl_fusion()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3438
0x1683590 pass_vsetvl::lazy_vsetvl()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:4373
0x16837a7 pass_vsetvl::execute(function*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:4413
0x16837a7 pass_vsetvl::execute(function*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:4394
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/111531] Bound member function with multiple inheritance documentation should be clearer

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Bound member function   |Bound member function with
   |(-Wno-pmf-conversions) with |multiple inheritance
   |multiple inheritance|documentation should be
   ||clearer
 Ever confirmed|0   |1
   Severity|normal  |enhancement
   Last reconfirmed||2023-09-22
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
"the PMF needs to store information about how to adjust the ‘this’ pointer,"

And then it says:
"you can extract the pointer to the function that would be called for a given
object/PMF pair and call it directly inside the inner loop, to save a bit of
time."

Meaning the specifically a Bound member function loses the information on how
to adjust the this pointer and just contains a pointer to the function rather
than anything else.

That is why I said this is just a documentation issue of explaining this in
more clearer langauge.

[Bug c++/111531] Bound member function (-Wno-pmf-conversions) with multiple inheritance

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||documentation

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Bound-member-functions.html


Reading this gives the impression that this situation could be better explained
and such that this is expected behavior.

[Bug c++/111532] New: tuple get accesses through base element type in constant expression

[oliverzlee at gmail dot com via Gcc-bugs]

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

Bug ID: 111532
   Summary: tuple get accesses through base element type in
constant expression
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oliverzlee at gmail dot com
  Target Milestone: ---

The following does not compile with GCC trunk/13.2/13.1/12.2/12.1 and
-std=c++14:

#include 

class A
{};

class B : A
{
public:
  constexpr auto base() const -> A
  {
return static_cast(*this);
  }
};

auto main() -> int
{
  constexpr auto x =
std::get<0>(std::tuple{}).base();
  (void)x;
}

with the following error:
: In function 'int main()':
:18:38:   in 'constexpr' expansion of '(& std::get<0,
B>(std::tuple()))->B::base()'
:18:39: error: accessing value of '.std::_Head_base<0, B,
true>::_M_head_impl' through a 'const A' glvalue in a constant expression
   18 | std::get<0>(std::tuple{}).base();
  |   ^
Compiler returned: 1

This compiles with -std=c++17 and -std=c++20, outside of constant expressions,
and with GCC 11.4.

Here is a godbolt link:
https://godbolt.org/z/x9dvherM6

[Bug c++/111531] New: Bound member function (-Wno-pmf-conversions) with multiple inheritance

[paulhaile3 at gmail dot com via Gcc-bugs]

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

Bug ID: 111531
   Summary: Bound member function (-Wno-pmf-conversions) with
multiple inheritance
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paulhaile3 at gmail dot com
  Target Milestone: ---

I noticed a bug with bound pointer to member functions that I would like to
report. When using multiple inheritance, the this pointer is incorrect and
results in undefined behavior. See the example below, which is modified from
https://github.com/llvm/llvm-project/issues/22495. The last set of addresses
are incorrect - e.g. this resolves to the address of struct B, instead of A,
which means accessing the data member this->x is undefined.

"""
#include 

struct A {
int x;
void f() { 
printf("A-in-B [A::f]: %p\n", this);
printf("address of x: %p, value of x: %d\n", >x, this->x);
}
};
struct X { char y; };
struct B : X, A {};

typedef void (B::*b_mp)();
typedef void (*b_fptr)(B *);

int main() {

B b;
b.x = 100;
b_mp mp = ::f;
printf("B: [main]: %p\n", );
printf("address of x: %p, value of x: %d\n", , b.x);
printf("A-in-B [main]: %p\n", (A *));
(b.*mp)();
b_fptr fp = (b_fptr)(::f);
fp();
}
"""

Output:
B: [main]: 0x7fff4772e958
address of x: 0x7fff4772e95c, value of x: 100
A-in-B [main]: 0x7fff4772e95c
A-in-B [A::f]: 0x7fff4772e95c
address of x: 0x7fff4772e95c, value of x: 100
A-in-B [A::f]: 0x7fff4772e958
address of x: 0x7fff4772e958, value of x: 0
Compiled with x86-64 gcc 13.2 with flags "-O3 --std=c++20 -Wno-pmf-conversions"

[Bug modula2/111530] New: Unable to build GM2 standard library on BSD due to a `getopt_long_only' GNU extension dependency

[macro at orcam dot me.uk via Gcc-bugs]

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

Bug ID: 111530
   Summary: Unable to build GM2 standard library on BSD due to a
`getopt_long_only' GNU extension dependency
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: macro at orcam dot me.uk
  Target Milestone: ---
Target: *-*-netbsd*

As in the summary the GM2 frontend fails to build for a BSD system, here
the `vax-dec-netbsdelf' target specifically, due to an unguarded
requirement for the presence of a GNU extension, `getopt_long_only'
specifically, in the system C library.  This is not a standard ISO C or
POSIX function and is not therefore provided by NetBSD (version 9.0
here):

.../gcc/libgm2/libm2pim/cgetopt.cc: In function 'int
m2pim_cgetopt_getopt_long_only(int, char**, char*, const option*, int*)':
.../gcc/libgm2/libm2pim/cgetopt.cc:74:11: error: 'getopt_long_only' was not
declared in this scope; did you mean 'getopt_long'?
   74 |   int r = getopt_long_only (argc, argv, optstring, longopts,
longindex);
  |   ^~~~
  |   getopt_long
make[5]: *** [Makefile:888: cgetopt.lo] Error 1

It is not clear to me from GM2 documentation if `getopt_long_only' is
provided as a part of the standard Modula 2 language API (in which case
it should be substituted, possibly from our in-tree libiberty) or just
as a convenience pass-through to the system facility (in which case it
should be disabled).  Either way it has to be autoconf'd for and handled
accordingly.

NB NetBSD does implement `getopt_long' as an own extension (as indicated
by the error message above) using an almost identical prototype, however
documentation indicates the semantics is slightly different from GNU
`getopt_long' for corner cases.  I'm unsure if that matters for GM2, but
thought it would be worth mentioning since I noticed that.

[Bug c/108964] Attribute (multi-) target should be implemented for C front-end (not only c++)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|Attribute target should be  |Attribute (multi-) target
   |implemented for C backend   |should be implemented for C
   |(not only c++)  |front-end (not only c++)
   Last reconfirmed||2023-09-21

--- Comment #2 from Andrew Pinski  ---
Confirmed.

[Bug c++/111529] [11/12/13/14 Regression] ICE on bool conversion in an unrolled loop condition inside template lambda nested in another template scope

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||8.3.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=89576
  Known to fail||8.4.0

--- Comment #4 from Andrew Pinski  ---
So it might be the patch which fixed PR 89576 .

[Bug c++/111529] [11/12/13/14 Regression] ICE on bool conversion in an unrolled loop condition inside template lambda nested in another template scope

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work|10.1.0  |

--- Comment #3 from Andrew Pinski  ---
(In reply to Maxim Plyushkin from comment #2)
> It appears that this regression happened between 8.3 and 8.4, not between
> 10.1 and 11.1.

Oh the default C++ version changed between 10 and 11 ...

[Bug c++/111529] [11/12/13/14 Regression] ICE on bool conversion in an unrolled loop condition inside template lambda nested in another template scope

[bugreport0 at proton dot me via Gcc-bugs]

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

--- Comment #2 from Maxim Plyushkin  ---
It appears that this regression happened between 8.3 and 8.4, not between 10.1
and 11.1.

[Bug c++/111529] [11/12/13/14 Regression] ICE on bool conversion in an unrolled loop condition inside template lambda nested in another template scope

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to fail||11.1.0
  Known to work||10.1.0
   Last reconfirmed||2023-09-21
 Ever confirmed|0   |1
   Target Milestone|--- |11.5
Summary|ICE on bool conversion in   |[11/12/13/14 Regression]
   |an unrolled loop condition  |ICE on bool conversion in
   |inside template lambda  |an unrolled loop condition
   |nested in another template  |inside template lambda
   |scope   |nested in another template
   ||scope

--- Comment #1 from Andrew Pinski  ---
Slightly more reduced:
```
template 
void f() {
  []() {
#pragma GCC unroll 9
for (int i = 1; i; --i) {
}
  };
}

int main() {
  f<0>();
}
```

[Bug c++/111529] New: ICE on bool conversion in an unrolled loop condition inside template lambda nested in another template scope

[bugreport0 at proton dot me via Gcc-bugs]

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

Bug ID: 111529
   Summary: ICE on bool conversion in an unrolled loop condition
inside template lambda nested in another template
scope
   Product: gcc
   Version: 13.2.0
   URL: https://godbolt.org/z/q64oM6bre
Status: UNCONFIRMED
  Keywords: c++-lambda, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugreport0 at proton dot me
  Target Milestone: ---

template 
void f() {
  [](auto c) {
#pragma GCC unroll 9
for (int i = c; i; --i) {
}
  };
}

int main() {
  f<0>();
}


compiles with -std=c++14 but with -std=c++17 generates


: In instantiation of 'void f() [with int x = 0]':
:11:7:   required from here
:5:19: internal compiler error: unexpected expression '(bool)i' of kind
implicit_conv_expr
5 | for (int i = c; i; --i) {
  |   ^
0x1ce7bde internal_error(char const*, ...)
???:0
0x8f1d4c finish_for_cond(tree_node*, tree_node*, bool, unsigned short)
???:0
0x8d0054 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x8beb17 instantiate_decl(tree_node*, bool, bool)
???:0
0x8d993b instantiate_pending_templates(int)
???:0
0x7d9f35 c_parse_final_cleanups()
???:0
0x98c608 c_common_parse_file()
???:0


Making any explicit conversion on the counter inside the condition breaks
compilation with -std=c++14 too.

[Bug target/111528] aarch64: Test gfortran.dg/pr80494.f90 fails with -fstack-protector-strong with gcc-13

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

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

--- Comment #2 from Marek Polacek  ---
I see the ICE even with r13-7827-g4bb1ae3c13ce4f in the tree.

[Bug target/111528] aarch64: Test gfortran.dg/pr80494.f90 fails with -fstack-protector-strong with gcc-13

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

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

--- Comment #1 from Andrew Pinski  ---
Should have been fixed with:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4bb1ae3c13ce4fb72129229de66f5ffbcd45fe4c

[Bug target/111528] New: aarch64: Test gfortran.dg/pr80494.f90 fails with -fstack-protector-strong with gcc-13

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

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

Bug ID: 111528
   Summary: aarch64: Test gfortran.dg/pr80494.f90 fails with
-fstack-protector-strong with gcc-13
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Started with r13-7813-gb96e66fd4ef3e3.

$ ./f951 -quiet -Iinclude /tmp/pr80494.f90 -std=gnu -O2
-fstack-protector-strong
/tmp/pr80494.f90:32:22:

   32 | end subroutine CalcCgr
  |  ^
Error: unrecognizable insn:
(insn 382 381 189 19 (parallel [
(set (reg:DF 34 v2 [orig:117 _46 ] [117])
(mem:DF (plus:DI (reg/f:DI 31 sp)
(const_int -8 [0xfff8])) [8 zadj[_142]+0 S8
A64]))
(set (reg:DF 32 v0 [orig:127 _76 ] [127])
(mem:DF (plus:DI (reg/f:DI 31 sp)
(const_int 0 [0])) [8 zadj[_142]+8 S8 A64]))
]) -1
 (nil))
during RTL pass: cprop_hardreg
/tmp/pr80494.f90:32:22: internal compiler error: in extract_insn, at
recog.cc:2791
0x7869e0 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/mpolacek/src/gcc13/gcc/rtl-error.cc:108
0x7869fc _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/mpolacek/src/gcc13/gcc/rtl-error.cc:116
0x78535f extract_insn(rtx_insn*)
/home/mpolacek/src/gcc13/gcc/recog.cc:2791
0xef3cab extract_constrain_insn(rtx_insn*)
/home/mpolacek/src/gcc13/gcc/recog.cc:2690
0xef7cf7 copyprop_hardreg_forward_1
/home/mpolacek/src/gcc13/gcc/regcprop.cc:826
0xef8f34 execute
/home/mpolacek/src/gcc13/gcc/regcprop.cc:1408

[Bug driver/111527] New: COLLECT_GCC_OPTIONS option hits single-variable limits too early

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

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

Bug ID: 111527
   Summary: COLLECT_GCC_OPTIONS option hits single-variable limits
too early
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Tl;DR:

  linux allows you to pass up to 2MB of command line arguments to the tools
limiting each individual option to 128KB. Unfortunately `gcc` collects all the
options into a single `COLLECT_GCC_OPTIONS` variable and hits the smaller 128KB
limit.

  This causes periodic problems for distributions that install each individual
package into a separate directory. One of them is `NixOS`.

  Could `gcc` be amended not to use single limiting `COLLECT_GCC_OPTIONS`
variable and use, say, direct arguments to pass options around? Or even use
response file if it hits `-E2BIG`?

  Fake reproducer: 2 huge variables that programs normally accept, but not
`gcc`:

  $ big_100k_var=$(printf "%0*d" 10 0)

  # this works: 200KB of options for `printf` external command
  $ $(which printf) "%s %s" $big_100k_var $big_100k_var >/dev/null; echo $?
  0

  # this fails: 200KB of options for `gcc`, fails in `cc1`
  $ touch a.c; gcc -c a.c -DA=$big_100k_var -DB=$big_100k_var
  gcc: fatal error: cannot execute 'cc1': execv: Argument list too long
  compilation terminated.

  Thanks!

MOre words

In `nixpkgs` repository each package gets installed into it's own unique
directory:

/nix/store/hash1-foo/include/foo.h
/nix/store/hash2-bar/include/bar.h
...

If any of those encounter `__FILE__` macros in static inline functions they
usually embed full path to header files into final binaries as is.

I wanted to remap all those paths into form that does not contain hashes:

   
-fmacro-prefix-map=/nix/store/hash1-foo/include/foo.h=/nix/store/-foo/include/foo.h
   
-fmacro-prefix-map=/nix/store/hash2-bar/include/bar.h=/nix/store/-bar/include/bar.h
...

When I got to packages that use about ~100 include directories I started
getting  errors from `cc1`:

```
Command line: `gcc -m64 -mcx16 $remap_options
/build/qemu-8.1.0/build/meson-private/tmpbyikv8nc/testfile.c \
  -o /build/qemu-8.1.0/build/meson-private/tmpbyikv8nc/output.exe
-D_FILE_OFFSET_BITS=64 \
  -O0 -Wl,--start-group -laio -Wl,--end-group -Wl,--allow-shlib-undefined` -> 1
stderr:
gcc: fatal error: cannot execute 'cc1': execv: Argument list too long
compilation terminated.
```

The limit felt too low and I found the `COLLECT_GCC_OPTIONS` variable.

[Bug tree-optimization/111517] [12/13 Regression] Optimization -O1 removes necessary loop for initialization since r12-5915-ge93809f62363ba

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

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

--- Comment #4 from Andrew Pinski  ---
r0-126272-g8fdc414d439bc7148e079d27220e59 adds check_loadstore but IVOPTS can
sometimes produce these TARGET_MEM_REF with 0 as first operand ...

[Bug tree-optimization/111517] [12/13 Regression] Optimization -O1 removes necessary loop for initialization since r12-5915-ge93809f62363ba

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|11.5|12.4

[Bug c/111526] inconsistent handling of declaration after label

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Actually wait:
# 3997 "./lib/config.h"
#pragma GCC diagnostic ignored "-Wpedantic"

coreutils's config.h explictly disables -Wpedantic ...

So not a bug.

[Bug c/111526] inconsistent handling of declaration after label

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug c/111526] inconsistent handling of declaration after label

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

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

--- Comment #5 from Andrew Pinski  ---
Hmm, somehow the value of warn_c11_c2x_compat is being changed from -1 to 0 ...
and not being changed back, maybe a __extension__ is happening incorrectly.

[Bug tree-optimization/111517] [12/13 Regression] Optimization -O1 removes necessary loop for initialization

[theodort at inf dot ethz.ch via Gcc-bugs]

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

Theodoros Theodoridis  changed:

   What|Removed |Added

 CC||theodort at inf dot ethz.ch

--- Comment #3 from Theodoros Theodoridis  ---
It bisects to r12-5915-ge93809f6236

[Bug c/111526] inconsistent handling of declaration after label

[P at draigBrady dot com via Gcc-bugs]

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

--- Comment #4 from Pádraig Brady  ---
Interestingly, gcc 13 _does_ warn with -Wc11-c2x-compat,
but does not warn with -Wpedantic

[Bug c/111526] inconsistent handling of declaration after label

[P at draigBrady dot com via Gcc-bugs]

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

--- Comment #3 from Pádraig Brady  ---
Created attachment 55964
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55964=edit
coreutils tail.c compilation unit

This should warn with -Wpedantic, but doesn't on gcc 13

[Bug c/111526] inconsistent handling of declaration after label

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

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

--- Comment #2 from Andrew Pinski  ---
Can you attach the original preprocessed source where you get no warning and
you think you should. Others can reduce it.

[Bug c/111526] inconsistent handling of declaration after label

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-09-21
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
This is expected behavior.

 -Wc11-c2x-compat warns also ...


>(which I haven't fully reduced but can easily reproduce),


We need a testcase where you think it should warn but does not ...

[Bug c/111526] New: inconsistent handling of declaration after label

[P at draigBrady dot com via Gcc-bugs]

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

Bug ID: 111526
   Summary: inconsistent handling of declaration after label
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: P at draigBrady dot com
  Target Milestone: ---

Created attachment 55963
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55963=edit
coreutils fix for non gcc >= 11

Ever since https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8b7a9a24
declarations after labels are allowed by default,
and only disabled with -pedantic etc.

I.e. the following simple code compiles on gcc >= 11,
but will fail when tried to be compiled with gcc <= 10, or clang for e.g.
This is exacerbated by the fact there is no compiler option
to avoid the issue on gcc <= 10 or clang,
as that code is explicitly disallowed by C11 and earlier.

int f(int x) { switch (x) { case 1: int i=f(x); } return 0; }


There is also a more subtle related issue
(which I haven't fully reduced but can easily reproduce),
where the warning will NOT fire even with -Wpedantic on gcc 13 at least.
If one compiles GNU coreutils with the attached commit reverted,
and with -Wpedantic on newer gcc, it will _NOT_ issue a warning.

[Bug c++/111525] Inconsistent Wsign-compare in c++ with ubsan

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

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

--- Comment #2 from Andrew Pinski  ---
>-Wno-error=array-bounds and -Wno-error=format-overflow are necessary as these 
>warnings have known issues under ubsan.

Actually all warnings have issues with sanitizers enabled. The manual is clear
there too:
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Instrumentation-Options.html#index-fsanitize_003daddress
```
Note that sanitizers tend to increase the rate of false positive warnings, most
notably those around -Wmaybe-uninitialized. We recommend against combining
-Werror and [the use of] sanitizers.

```


So I think --disable-werror should be used for configure option instead ...

[Bug c++/111525] Inconsistent Wsign-compare in c++ with ubsan

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2023-09-21

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/111525] New: Inconsistent Wsign-compare in c++ with ubsan

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

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

Bug ID: 111525
   Summary: Inconsistent Wsign-compare in c++ with ubsan
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhroma at gcc dot gnu.org
  Target Milestone: ---

$ cat test.cc 
extern long global;

int foo (unsigned x) {
  return x == ((global ? 64 : 32) - 1) / 8;
}
$ gcc -x c -c -Werror=sign-compare test.cc
$ gcc -x c -c -Werror=sign-compare test.cc -fsanitize=undefined
$ gcc -x c++ -c -Werror=sign-compare test.cc
$ gcc -x c++ -c -Werror=sign-compare test.cc -fsanitize=undefined
test.cc: In function ‘int foo(unsigned int)’:
test.cc:4:12: error: comparison of integer expressions of different signedness:
‘unsigned int’ and ‘int’ [-Werror=sign-compare]
4 |   return x == ((global ? 64 : 32) - 1) / 8;
  |  ~~^~~
cc1plus: some warnings being treated as errors


Warning appears only for C++ with ubsan enabled.  It seems that both sanitizer
and warning are implemented in front-end part, and C++ somehow issues warning
after instrumentation.

This actually breaks ubsan-bootstrap with -Werror enabled, from what I know all
versions since gcc-8 are affected.

configure --enable-languages=c,c++ --disable-multilib
--with-build-config=bootstrap-ubsan --enable-werror=yes && make
BOOT_CFLAGS="-Wno-error=array-bounds -Wno-error=format-overflow"

-Wno-error=array-bounds and -Wno-error=format-overflow are necessary as these
warnings have known issues under ubsan.

[Bug c++/111524] Missing support for inline namespace in spellcheck

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-09-21
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed reduced testcase:
```
namespace t
{
  inline namespace tt
  {
int abc;
  }
}

namespace t1
{
 int xyz;
}

int f = t::ab;
int f1 = t1::xy;
```

[Bug c++/111524] New: Missing support for inline namespace in spellcheck

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

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

Bug ID: 111524
   Summary: Missing support for inline namespace in spellcheck
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fdumont at gcc dot gnu.org
  Target Milestone: ---

When spellcheck is trying to find out what mistake the dev made inline
namespace are not considered.

To reproduce you just need to build g++/libstdc++ with:
--enable-languages=c++ --enable-symvers=gnu-versioned-namespace

so that you have the std::__8:: inline namespace for mostly all libstdc++
symbols.

Then running 'make check-c++' several spellcheck tests will start to fail like:

/home/fdumont/dev/gcc/git/gcc/testsuite/g++.dg/spellcheck-pr78656.C: In
function 'void* allocate(std::size_t)':
/home/fdumont/dev/gcc/git/gcc/testsuite/g++.dg/spellcheck-pr78656.C:7:15:
error: 'allocate' is not a member of 'std'; did you mean 'allocate'?
   return std::allocate().allocate(n); // { dg-error ".allocate. is not a
member of .std.; did you mean 'allocator'\\?" }
   ^~~~
/home/fdumont/dev/gcc/git/gcc/testsuite/g++.dg/spellcheck-pr78656.C:5:7: note:
'allocate' declared here
 void* allocate(std::size_t n)
   ^~~~

It's not proposing std::allocator anymore as it is in fact std::__8::allocator.

[Bug middle-end/111523] Unexpected performance regression with -ftrivial-auto-var-init=zero for e.g. systemctl unmask

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

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

Sam James  changed:

   What|Removed |Added

 CC||siddhesh at gcc dot gnu.org

--- Comment #1 from Sam James  ---
(I'll cc sid too as he might be interested, but he's also dealt with some
unexpected hardening fallout in systemd before; no worries if this isn't your
ballpark though)

[Bug middle-end/111523] New: Unexpected performance regression with -ftrivial-auto-var-init=zero for e.g. systemctl unmask

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

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

Bug ID: 111523
   Summary: Unexpected performance regression with
-ftrivial-auto-var-init=zero for e.g. systemctl unmask
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: arm-linux-eabi

This issue is opened on request from the author of -ftrivial-auto-var-init
(https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630894.html) when I
mentioned an local observation, that systemd's use of
-ftrivial-auto-var-init=zero caused a slowdown of at least 35% observable with
a mostly harmless command such as "systemctl unmask x". The
performance-regression was identified as corresponding to
https://github.com/systemd/systemd.git commit 1a4e392760 (which adds
-ftrivial-auto-var-init=zero to build flags).

My own belief is that this kind of slowdown is totally expected with
-ftrivial-auto-var-init=zero, but there was disagreement, and bugzilla might
help with fixing any issues.  Please note that I'm sorry but I'm not going to
analyze the problem myself to the level yielding a self-contained test-case.

The build environment is Poky (OpenEmbedded) mickledore-4.2 or 4.2.1 (the exact
version for the observation was probably mickledore-4.2.1, could have been 4.2;
there appears to be no related change in-between). From that version, all other
version numbers are deducible; specifically gcc-12.2.0.

Regarding systemd, matters are somewhat complicated by Poky pulling
https://github.com/systemd/systemd-stable.git (note the "-stable" difference to
the first quoted repo) with the version seemingly v253.1 (actually, git hash
6c327d74aa0). The commit-hash introducing 
-ftrivial-auto-var-init=zero is the same, 1a4e392760cb5, so it seems -stable is
just some kind of subset repo.

According to the target gcc -v option, it was configured as follows.  While the
quoted version below is 12.3 (per Poky 4.2.3), from the gcc "recipes", it
appears the gcc configuration options were the same in mickledore-4.2:
Configured with:
../../../../../../work-shared/gcc-12.3.0-r0/gcc-12.3.0/configure
--build=x86_64-linux --host=x86_64-linux --target=arm-poky-linux-gnueabi
--prefix=/host-native/usr --exec_prefix=/host-native/usr
--bindir=/host-native/usr/bin/arm-poky-linux-gnueabi
--sbindir=/host-native/usr/bin/arm-poky-linux-gnueabi
--libexecdir=/host-native/usr/libexec/arm-poky-linux-gnueabi
--datadir=/host-native/usr/share --sysconfdir=/host-native/etc
--sharedstatedir=/host-native/com --localstatedir=/host-native/var
--libdir=/host-native/usr/lib/arm-poky-linux-gnueabi
--includedir=/host-native/usr/include --oldincludedir=/host-native/usr/include
--infodir=/host-native/usr/share/info --mandir=/host-native/usr/share/man
--disable-silent-rules --disable-dependency-tracking
--with-libtool-sysroot=/host-native --enable-clocale=generic --with-gnu-ld
--enable-shared --enable-languages=c,c++ --enable-threads=posix
--disable-multilib --enable-default-pie --enable-c99 --enable-long-long
--enable-symvers=gnu --enable-libstdcxx-pch
--program-prefix=arm-poky-linux-gnueabi- --without-local-prefix
--disable-install-libiberty --disable-libssp --enable-libitm --enable-lto
--disable-bootstrap --with-system-zlib --with-linker-hash-style=sysv
--enable-linker-build-id --with-ppl=no --with-cloog=no
--enable-checking=release --enable-cheaders=c_global --without-isl
--with-gxx-include-dir=/not/exist/usr/include/c++/12.3.0
--with-sysroot=/not/exist --with-build-sysroot=/host
--enable-poison-system-directories=error --with-system-zlib --disable-static
--disable-nls --with-glibc-version=2.28 --enable-initfini-array

I'm washing my hands; these configure options are a Poky invention.

The build options besides -ftrivial-auto-var-init=zero are (quoting from the
log for a random command-line building a file in systemd/systemctl):

arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9
-fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
-Werror=format-security
--sysroot=/home/hp/cfp/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/systemd/1_253.4+git999-r0/recipe-sysroot
-Isystemctl.p -I. -I../../../../../../workspace/sources/systemd -Isrc/basic
-I../../../../../../workspace/sources/systemd/src/basic -Isrc/fundamental
-I../../../../../../workspace/sources/systemd/src/fundamental -Isrc/systemd
-I../../../../../../workspace/sources/systemd/src/systemd
-I../../../../../../workspace/sources/systemd/src/libsystemd/sd-bus
-I../../../../../../workspace/sources/systemd/src/libsystemd/sd-device
-I../../../../../../workspace/sources/systemd/src/libsystemd/sd-event
-I../../../../../../workspace/sources/systemd/src/libsystemd/sd-hwdb

[Bug tree-optimization/111517] [12/13 Regression] Optimization -O1 removes necessary loop for initialization

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-09-21
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
On the subject of:
  _1 = MEM[(unsigned int *)0B + -320B + ivtmp.27_36 + ivtmp.16_4 * 4];

during the local-pure-const2 pass:

Indirect ref write is not const/pure
vs:
  NULL memory access; terminating BB


But that MEM is not exactly an NULL Pointer access ...


  _39 = (sizetype) this_9(D);
  ivtmp.27_38 = _39 * 18446744073709551613;
  ivtmp.28_42 = _39 + 100;


This is also definitely IV-OPTs messing up ...

Though before GCC 12 it had that too but the local-pure-const2 pass it thought
something different about it:

  scanning: _1 = MEM[(unsigned int *)0B + -320B + ivtmp.27_34 + ivtmp.16_3 *
4];
Indirect ref to local or readonly memory is OK

[Bug c++/111517] [12/13 Regression] Optimization -O1 removes necessary loop for initialization

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Optimization -O1 removes|[12/13 Regression]
   |necessary loop for  |Optimization -O1 removes
   |initialization  |necessary loop for
   ||initialization
  Known to work|14.0|
   Target Milestone|--- |11.5

--- Comment #1 from Andrew Pinski  ---
-fno-ivopts allows the code to pass.

The difference between GCC 13 and the trunk is:
trunk:
  _30 = [(unsigned int *)0B + -320B + ivtmp.27_37 + ivtmp.16_4 * 4];
  _1 = *_30;

vs:
GCC 13:
  _1 = MEM[(unsigned int *)0B + -320B + ivtmp.27_36 + ivtmp.16_4 * 4];


And the call 

  TestClass::init ();

is still there in _GLOBAL__sub_I__ZN9TestClass4initEv ...

[Bug target/111518] relro protection not working in riscv

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #3 from Andrew Pinski  ---
GCC is not involed in the relazation part of the linker which seems like is
causing this issue ...

[Bug tree-optimization/111520] [14 Regression] ICE: verify_flow_info failed (error: probability of edge 3->8 not initialized) with -O -fsignaling-nans -fharden-compares -fnon-call-exceptions

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Keywords||ice-checking
 CC||hubicka at gcc dot gnu.org

[Bug tree-optimization/111519] [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu since r13-455-g1fe04c497d

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Priority|P3  |P2

[Bug tree-optimization/111515] [14 Regression] Missed Dead Code Elimination since r14-4089-gd45ddc2c04e

[theodort at inf dot ethz.ch via Gcc-bugs]

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

--- Comment #3 from Theodoros Theodoridis  ---
I'm re-reducing the case so that the missed optimization does not depend on
inlining to main (the bisection will stay the same). I'll post the updated code
soon.

[Bug target/111522] Different code path for static initialization with flto

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2023-09-21

--- Comment #1 from Andrew Pinski  ---
I think this is just broken code.

It does:
#define HWY_BEFORE_NAMESPACE()
\
  HWY_PUSH_ATTRIBUTES("altivec,vsx,power8-vector" 
\
  ",cpu=power10")

But does not do a pop before the main function.

And then you are testing on power8 which obvious does not have all of the
instructions as power10 ...
Why it works without -flto is just pure accident not using the instructions
that are not in power8.

Anyways I suspect this is too much reduced testcase. So you might need to
provide the original one.

[Bug tree-optimization/111519] [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu since r13-455-g1fe04c497d

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-09-21

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug tree-optimization/111519] [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu since r13-455-g1fe04c497d

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.3
   Keywords||wrong-code

[Bug tree-optimization/111515] [14 Regression] Missed Dead Code Elimination since r14-4089-gd45ddc2c04e

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

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

--- Comment #2 from Andrew Pinski  ---
Looks like an early jump threading happens in n and then the size differences
causes inlining heurstics not to chose the function for inlining because it is
inlining into `main`. If we change main to `f` or `main1`, then n is inlined
and there is no missed optimization ...

[Bug tree-optimization/111515] [14 Regression] Missed Dead Code Elimination since r14-4089-gd45ddc2c04e

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2023-09-21
   Target Milestone|--- |14.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
Version|unknown |14.0
 Ever confirmed|0   |1
   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
I will have a look.

[Bug fortran/111521] Polymorphic variable loses information about the actual type assigned when passed as function result

[dcesari69 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Davide Cesari  ---
An update:

By replacing the line

list_getcurr => this%curr%getval()

with

CLASS(*),POINTER :: l_p
l_p => this%curr%getval()
list_getcurr => l_p

i.e. assigning the upper function result to a temporary local pointer and
setting the current function result to that pointer gives the correct result.

[Bug target/111522] New: Different code path for static initialization with flto

[malat at debian dot org via Gcc-bugs]

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

Bug ID: 111522
   Summary: Different code path for static initialization with
flto
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: malat at debian dot org
  Target Milestone: ---

Created attachment 55962
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55962=edit
c++ code

I am seeing a difference in behavior when using -flto. Consider the following:

% c++ -std=c++11  -g -O2  -o works lto.cc
% c++ -std=c++11  -g -O2 -flto -o fails lto.cc
% ./works&& echo "success"
success
% ./fails
zsh: illegal hardware instruction  ./fails

This a POWER8 system.

[Bug c++/111516] parameter passing note is not actionable

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Jonathan Wakely  ---
That's definitely not what it's suggesting. It's telling you that the ABI for
c++17 code in gcc 10 does not match the ABI for c++17 code in gcc 9. It's a
statement of fact, it's not suggesting that you do anything. I agree that it
isn't necessarily useful, because you might not care about the ABI of c++17
code in gcc 9.

Have you tried -Wno-psabi ?

[Bug fortran/111521] New: Polymorphic variable loses information about the actual type assigned when passed as function result

[dcesari69 at gmail dot com via Gcc-bugs]

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

Bug ID: 111521
   Summary: Polymorphic variable loses information about the
actual type assigned when passed as function result
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcesari69 at gmail dot com
  Target Milestone: ---

Created attachment 55961
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55961=edit
Program showing the described behavior

Hello, the attached program shows an anomalous behavior since gcc-gfortran
version 13, in the previous gfortran versions it worked as expected.

gcc version:
GNU Fortran (GCC) 13.2.1 20230728 (Red Hat 13.2.1-1)
Copyright (C) 2023 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.

OS (Fedora 38):
Linux trentotto 6.3.8-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jun 15
02:15:40 UTC 2023 x86_64 GNU/Linux

Build command line:
gfortran -g -fcheck=all -o testpoli testpoli.f90

Actual program stdout:
 1.integer
 1.integer
 2.unknown type
 3.unknown type
   8  -1

Expected program stdout (e.g. when compiled with gfortran 12.2.1):
 1.integer
 2.integer
 3.integer
   8   8

Description:
The unlimited polymorphic derived type member %val is initialised with an
integer, but when passed back as a result of a chain of functions, it loses its
type. Additionally, the debugging print show that the function link_getval is
apparently executed twice, while it is called only once.

By executing the commented line `v => this%curr%getval()` instead of `v =>
this%getcurr()` the program gives the expected result with version 13, however
the original code was obviously more complex and this chained function call was
necessary.

The bug could be somehow related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110415 also appearing in version
13.

[Bug tree-optimization/111520] New: [14 Regression] ICE: verify_flow_info failed (error: probability of edge 3->8 not initialized) with -O -fsignaling-nans -fharden-compares -fnon-call-exceptions

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 111520
   Summary: [14 Regression] ICE: verify_flow_info failed (error:
probability of edge 3->8 not initialized) with -O
-fsignaling-nans -fharden-compares
-fnon-call-exceptions
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 55960
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55960=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -fsignaling-nans -fharden-compares
-fnon-call-exceptions testcase.C 
testcase.C: In function 'void foo()':
testcase.C:10:1: error: probability of edge 3->8 not initialized
   10 | foo ()
  | ^~~
during GIMPLE pass: hardcmp
testcase.C:10:1: internal compiler error: verify_flow_info failed
0x124a81e verify_flow_info()
/repo/gcc-trunk/gcc/cfghooks.cc:287
0x17ebd0c checking_verify_flow_info()
/repo/gcc-trunk/gcc/cfghooks.h:214
0x17ebd0c cleanup_tree_cfg_noloop
/repo/gcc-trunk/gcc/tree-cfgcleanup.cc:1154
0x17ebd0c cleanup_tree_cfg(unsigned int)
/repo/gcc-trunk/gcc/tree-cfgcleanup.cc:1205
0x1664e6c execute_function_todo
/repo/gcc-trunk/gcc/passes.cc:2057
0x166531e execute_todo
/repo/gcc-trunk/gcc/passes.cc:2142
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-4208-2023092504-g7439f40dc17-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-4208-2023092504-g7439f40dc17-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230921 (experimental) (GCC)

[Bug target/110622] x87: Miscompilation at O2 level (O1 is working)

[malat at debian dot org via Gcc-bugs]

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

--- Comment #16 from Mathieu Malaterre  ---
(In reply to Xi Ruoyao from comment #15)
> (In reply to Mathieu Malaterre from comment #14)
> > (In reply to Andrew Pinski from comment #13)
> > > (In reply to Mathieu Malaterre from comment #12)
> > > > I am seeing a difference in result (log1p computation) in the range:
> > > > 
> > > > 4318952042648305665 - 0x1.1p-64
> > > > 4368493837572636672 - 0x1.002p-53
> > > > 
> > > > the other values seems to match expectation of log1p computation.
> > > 
> > > But you used excess-precision=fast
> > > 
> > > *** This bug has been marked as a duplicate of bug 323 ***
> > 
> > AFAIK bug #323 does not mention my trick:
> > 
> >   asm volatile("" : "+r"(y.raw[0]) : : "memory");
> > 
> > That simple line totally changed the optimizer code generation.
> 
> Because in x87 the excessive precision only exists in x87 stack-like
> registers.  The "memory" clobber forces a store and reload for all
> non-register variables, thus the value is truncated into a normal double
> value and the excessive precision is lost.
> 
> There are infinite ways to work around an issue, but it does not mean PR 323
> must mention all of them.

Oh, I see. Basically my trick is convoluted `-ffloat-store`.

I finally took myself by the hand and convinced me with a simple code:

```
// gcc -m32 -fexcess-precision=fast -O2 t.c
#include 
#include 
#include 
#include 

[[gnu::noipa]] void test(uint64_t v, double x, double y) {
  const double y2 = x + 1.0;
  if (y != y2)
printf("error %" PRIu64 " %.17g %a\n", v, x, x);
  else
printf("ok %" PRIu64 " %.17g %a\n", v, x, x);
}

void main() {

  uint64_t kSamplesPerRange = 4000, start = 0, stop = 9218868437227405311;
  uint64_t step = (stop / kSamplesPerRange);
  for (uint64_t value_bits = start; value_bits <= stop; value_bits += step) {
double value;
memcpy(, _bits, sizeof value);
double x = value;
double y = x + 1.0;

test(value_bits, x, y);
  }
}
```

please accept my apologies for the noise.

[Bug target/110622] x87: Miscompilation at O2 level (O1 is working)

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

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

--- Comment #15 from Xi Ruoyao  ---
(In reply to Mathieu Malaterre from comment #14)
> (In reply to Andrew Pinski from comment #13)
> > (In reply to Mathieu Malaterre from comment #12)
> > > I am seeing a difference in result (log1p computation) in the range:
> > > 
> > > 4318952042648305665 - 0x1.1p-64
> > > 4368493837572636672 - 0x1.002p-53
> > > 
> > > the other values seems to match expectation of log1p computation.
> > 
> > But you used excess-precision=fast
> > 
> > *** This bug has been marked as a duplicate of bug 323 ***
> 
> AFAIK bug #323 does not mention my trick:
> 
>   asm volatile("" : "+r"(y.raw[0]) : : "memory");
> 
> That simple line totally changed the optimizer code generation.

Because in x87 the excessive precision only exists in x87 stack-like registers.
 The "memory" clobber forces a store and reload for all non-register variables,
thus the value is truncated into a normal double value and the excessive
precision is lost.

There are infinite ways to work around an issue, but it does not mean PR 323
must mention all of them.

[Bug target/110622] x87: Miscompilation at O2 level (O1 is working)

[malat at debian dot org via Gcc-bugs]

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

--- Comment #14 from Mathieu Malaterre  ---
(In reply to Andrew Pinski from comment #13)
> (In reply to Mathieu Malaterre from comment #12)
> > I am seeing a difference in result (log1p computation) in the range:
> > 
> > 4318952042648305665 - 0x1.1p-64
> > 4368493837572636672 - 0x1.002p-53
> > 
> > the other values seems to match expectation of log1p computation.
> 
> But you used excess-precision=fast
> 
> *** This bug has been marked as a duplicate of bug 323 ***

AFAIK bug #323 does not mention my trick:

  asm volatile("" : "+r"(y.raw[0]) : : "memory");

That simple line totally changed the optimizer code generation.

[Bug middle-end/323] optimized code gives strange floating point results

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

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

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

[Bug target/110622] x87: Miscompilation at O2 level (O1 is working)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #13 from Andrew Pinski  ---
(In reply to Mathieu Malaterre from comment #12)
> I am seeing a difference in result (log1p computation) in the range:
> 
> 4318952042648305665 - 0x1.1p-64
> 4368493837572636672 - 0x1.002p-53
> 
> the other values seems to match expectation of log1p computation.

But you used excess-precision=fast

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

[Bug c/111518] relro protection not working in riscv

[schwab--- via Gcc-bugs]

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

--- Comment #2 from Andreas Schwab  ---
That's a linker bug, please report to https://sourceware.org/bugzilla/.

[Bug tree-optimization/111519] New: [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu since r13-455-g1fe04c497d

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 111519
   Summary: [13/14 Regression] Wrong code at -O3 on
x86_64-linux-gnu since r13-455-g1fe04c497d
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: roger at nextmovesoftware dot com
  Target Milestone: ---

gcc at -O3 produced the wrong code.

Bisected to r13-455-g1fe04c497d

Compiler explorer: https://godbolt.org/z/ozEaKa1rY

$ cat a.c
int printf(const char *, ...);
int a, o;
char b, f, i;
long c;
static signed char d;
static char g;
unsigned *h;
signed char *e = 
static signed char **j = 
static long k[2];
unsigned **l = 
short m;
int main(int q, char *r[]) {
  int p = 0;
  if (q == 0)
p = 1;
  signed char *n = 
  *n = 0;
  for (; c;)
for (; i; i--)
  ;
  g = 0;
  for (; g <= 1; g++) {
*n = **j;
k[g] = 0 != 
*e = l && k[0];
  }
  if (p)
printf();
  for (; o < 4; o++) {
a = d;
if (p)
  printf();
  }
  printf("%d\n", a);
}
$
$ gcc -O2 a.c && ./a.out
1
$ gcc -O3 a.c && ./a.out
0
$

[Bug c/111518] relro protection not working in riscv

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

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

palmer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||palmer at gcc dot gnu.org

--- Comment #1 from palmer at gcc dot gnu.org ---
(In reply to sattdeepan from comment #0)
> 1. Compile with -z,relro,-z,now flag:
> gcc -g -Wl,-z,norelro -O0  -o test_partial test_relro.c

Those don't match: the comment says relro+now, but the command line says
norelro.  I'm just double checking to make sure the run is from a relro+now
build, as opposed to a norelro build.

Also, I get a warning building the code.  I don't think it'll result in bad
behavior here, though.

$ riscv64-unknown-linux-gnu-gcc test.c -o test
test.c: In function ‘main’:
test.c:7:35: warning: passing argument 1 of ‘strtol’ from incompatible pointer
type [-Wincompatible-pointer-types]
7 | size_t *p = (size_t *) strtol(argv[1], NULL, 16);
  |   ^~~
  |   |
  |   int *
In file included from test.c:2:
/usr/riscv64-unknown-linux-gnu/usr/include/stdlib.h:177:48: note: expected
‘const char * restrict’ but argument is of type ‘int *’
  177 | extern long int strtol (const char *__restrict __nptr,
  | ~~~^~

[Bug c/111518] New: relro protection not working in riscv

[sattdeepan.d at samsung dot com via Gcc-bugs]

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

Bug ID: 111518
   Summary: relro protection not working in riscv
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sattdeepan.d at samsung dot com
  Target Milestone: ---

-z,relro and/or -z,now flag not working on riscv arch.


Address of printf overwritten to custom address passed as argument, but it
expected to be readonly when full relro protection is enabled

Test code to reproduce(test_relro.c):
---

#include 
#include 


int main(int argc, int *argv[])
{
size_t *p = (size_t *) strtol(argv[1], NULL, 16);

p[0] = 0xdeadbeef;

printf("RELRO: %p\n", p);

return 0;
}
---

Steps to reproduce:

1. Turn off ASLR:
  echo 0 > /proc/sys/kernel/randomise_va_space

1. Compile with -z,relro,-z,now flag:
gcc -g -Wl,-z,norelro -O0  -o test_partial test_relro.c

2. Check printf address in GOT:
sattdeepan@sri-9052:~$ objdump -R test_partial | grep printf
00012020 R_RISCV_JUMP_SLOT  printf@GLIBC_2.27

3. Running with gdb:
gdb -q test_partial

4. Get load address of printf function:
 -  + 
0x10586 - 0x10586 +  0x12020 ==> 0x12020

5. Pass load address of main as argument

gdb-peda$ r 0x12020
Starting program: /home/user/test_full_riscv 0x12020
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/riscv64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
Warning: 'set logging off', an alias for the command 'set logging enabled', is
deprecated.
Use 'set logging enabled off'.

Warning: 'set logging on', an alias for the command 'set logging enabled', is
deprecated.
Use 'set logging enabled on'.
0xdeadbeee in ?? () > address of printf overwritten to custom
address passed as argument, but it expected to be readonly
gdb-peda$

[Bug libstdc++/111327] std::bind_front (and std::not_fn) doesn't always perfectly forward according to value category of the call wrapper object

[de34 at live dot cn via Gcc-bugs]

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

Jiang An  changed:

   What|Removed |Added

 CC||de34 at live dot cn

--- Comment #5 from Jiang An  ---
The current fix doesn't seem sufficient (https://godbolt.org/z/rs5oYxjTc):

#include 
#include 

struct Weird {
void operator()() {}
bool operator()() const { return true; }
};

int main()
{
auto nf = std::not_fn(Weird{});
nf(); // should be rejected, but calls the const overload
std::as_const(nf)();
}

[Bug libstdc++/111511] Incorrect ADL in std::to_array in GCC 11/12/13

[de34 at live dot cn via Gcc-bugs]

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

--- Comment #5 from Jiang An  ---
(In reply to m.cencora from comment #2)
> (In reply to Jonathan Wakely from comment #1)
> > (In reply to Jiang An from comment #0)
> > > Not sure whether this should be WONTFIX since the implementation is
> > > fundamentally changed in GCC 14 (PR 110167).
> > 
> > There's no reason we can't fix the old version in the release branches.
> > 
> > I did notice this when rewriting it, but I didn't think to change the
> > branches to avoid ADL there, because I plan to backport the new
> > implementation eventually anyway.
> 
> On a semi-related topic:
> Can't we use __builtin_bit_cast as even simpler implementation of to_array
> for trivial types?

__builtin_bit_cast results in constant evaluation failure when the element type
is or contains a pointer or a union, which heavily restricts its usability in
to_array.

[Bug c++/111517] New: Optimization -O1 removes necessary loop for initialization

[aegges at web dot de via Gcc-bugs]

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

Bug ID: 111517
   Summary: Optimization -O1 removes necessary loop for
initialization
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aegges at web dot de
  Target Milestone: ---

We have found a regression in gcc 12 (and later) in comparison to gcc 11 (and
clang) which occurs if optimization (at least -O1) is enabled.
In the following C++ code the member variables a1 and e1 are initialized in a
loop in a init() method which is called in the constructor.  

#include 
#include 

class TestClass
{
public:
   TestClass()
   { 
   for(int i=0; i<20; i++)
   {
  a1[i] = i;
   }

   init();
}

void init();
unsigned int a1[20];
unsigned char e1[20][20];
};

void TestClass::init()
{
for (int b1 = 0; b1 < 20; b1++)
{
for (int b2 = 0; b2 < 20; b2++)
{
e1[b1][b2] = a1[b2];
}
}
}

TestClass tmp;

int main()
{
for(int i=0; i < 20 ; i++)
std::cout << std::to_string(tmp.e1[i][i]) << " ";
}
expected output: (gcc <= 11 or gcc >=12 w/o optimization)
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

actual output: 8gcc >=12 with optimization)
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 


I have used godbolt to verify the different behavior (see
https://godbolt.org/z/MnoPE8Yfr )

[Bug target/111425] ia64: ICE in net/ipv4/fib_semantics.c:1621:1: internal compiler error: Segmentation fault

[frank.scheiner at web dot de via Gcc-bugs]

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

--- Comment #6 from Frank Scheiner  ---
Dear Richard,

would it be helpful to bisect this problem or is it already known where and
when the problem was introduced?

I anyhow wanted to look into how those cross-compilers over at [1] are built
and a bisecting run could be the right excuse to actually do that.

Cheers,
Frank

[1]: https://mirrors.edge.kernel.org/pub/tools/crosstool/

[Bug libstdc++/111511] Incorrect ADL in std::to_array in GCC 11/12/13

[m.cencora at gmail dot com via Gcc-bugs]

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

--- Comment #4 from m.cencora at gmail dot com ---
Ack

[Bug libstdc++/111511] Incorrect ADL in std::to_array in GCC 11/12/13

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

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

--- Comment #3 from Jonathan Wakely  ---
Until all supported compilers implement it, that won't be simpler. We'll still
need the memcpy version as a fallback.

And it probably generated exactly the same code, although I haven't checked.

[Bug libstdc++/111511] Incorrect ADL in std::to_array in GCC 11/12/13

[m.cencora at gmail dot com via Gcc-bugs]

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

m.cencora at gmail dot com changed:

   What|Removed |Added

 CC||m.cencora at gmail dot com

--- Comment #2 from m.cencora at gmail dot com ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Jiang An from comment #0)
> > Not sure whether this should be WONTFIX since the implementation is
> > fundamentally changed in GCC 14 (PR 110167).
> 
> There's no reason we can't fix the old version in the release branches.
> 
> I did notice this when rewriting it, but I didn't think to change the
> branches to avoid ADL there, because I plan to backport the new
> implementation eventually anyway.

On a semi-related topic:
Can't we use __builtin_bit_cast as even simpler implementation of to_array for
trivial types?

[Bug c++/111516] New: parameter passing note is not actionable

[gonzalo.gadeschi at gmail dot com via Gcc-bugs]

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

Bug ID: 111516
   Summary: parameter passing note is not actionable
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gonzalo.gadeschi at gmail dot com
  Target Milestone: ---

I'm getting the following note (no reproducer yet), which as far as I can tell,
does not really tell me anything actionable and does not mention how to silence
it: 

```
/usr/include/c++/12/bits/stl_pair.h:741:5: note: parameter passing for argument
of type 'std::pair' when C++17 is enabled changed to match
C++14 in GCC 10.1
  741 | make_pair(_T1&& __x, _T2&& __y)
  | ^
```


This note should at least be silenceable. 

It would be nice if the note message were to say something actionable, e.g.,
explain why this is a problem and what to do about it.

My interpretation of the note is that it is suggesting the developer to stop
using C++17 and to use C++14 instead. If this is not the intent, then it would
be great if the note could be clarified.

[Bug modula2/111510] Modula-2 runtime ICE on arm-linux-gnueabihf: iso/RTentity.mod:245:in findChildAndParent has caused internal runtime error, RTentity is either corrupt or the module storage has no

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

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

Gaius Mulley  changed:

   What|Removed |Added

   Last reconfirmed||2023-09-21
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Gaius Mulley  ---
Thanks for the bug report - I'm rebuilding gcc-13 for arm-linux-gnueabihf - but
the build will complete after I leave for the cauldron.

[Bug target/111428] RISC-V vector: Flaky segfault in {min|max}val_char_{1|2}.f90

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

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

--- Comment #2 from Robin Dapp  ---
Reproduced locally.  The identical binary sometimes works and sometimes doesn't
so it must be a race...

[Bug target/110622] x87: Miscompilation at O2 level (O1 is working)

[malat at debian dot org via Gcc-bugs]

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

--- Comment #12 from Mathieu Malaterre  ---
I am seeing a difference in result (log1p computation) in the range:

4318952042648305665 - 0x1.1p-64
4368493837572636672 - 0x1.002p-53

the other values seems to match expectation of log1p computation.

[Bug target/110622] x87: Miscompilation at O2 level (O1 is working)

[malat at debian dot org via Gcc-bugs]

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

--- Comment #11 from Mathieu Malaterre  ---
Typical setup:

g++ -fno-asynchronous-unwind-tables -fno-exceptions -fno-rtti -DHIDESYMPTOM
-std=c++11 -g -m32 -fexcess-precision=fast -O2 -o works math_test.cc
-Wfatal-errors -Wall -Wextra -Wpedantic -Wconversion -Werror

and:

g++ -fno-asynchronous-unwind-tables -fno-exceptions -fno-rtti -std=c++11 -g
-m32 -fexcess-precision=fast -O2 -o fails math_test.cc -Wfatal-errors -Wall
-Wextra -Wpedantic -Wconversion -Werror

You can observe that the only difference is that I am preventing an elision :

```
% grep -A2 HIDE math_test.cc
#ifdef HIDESYMPTOM
  asm volatile("" : "+r"(y.raw[0]) : : "memory");
#endif
```

[Bug target/110622] x87: Miscompilation at O2 level (O1 is working)

[malat at debian dot org via Gcc-bugs]

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

--- Comment #10 from Mathieu Malaterre  ---
Created attachment 55959
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55959=edit
cvise reduced test case

[Bug target/110622] x86: Miscompilation at O1 level (O0 is working)

[malat at debian dot org via Gcc-bugs]

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

Mathieu Malaterre  changed:

   What|Removed |Added

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

--- Comment #9 from Mathieu Malaterre  ---
(In reply to Mathieu Malaterre from comment #7)
> Either `-fexcess-precision=standard` or `-ffloat-store` makes the symptoms
> go away (tested at -O2).

The above statement is 100% accurate. However I still believe the optimizer is
doing a little too much on a limited range of values. Let me provide a reduce
test case.

[Bug tree-optimization/111515] New: [14 Regression] Missed Dead Code Elimination since r14-4089-gd45ddc2c04e

[theodort at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 111515
   Summary: [14 Regression] Missed Dead Code Elimination since
r14-4089-gd45ddc2c04e
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

https://godbolt.org/z/K9bbM4fc9

Given the following code:

void foo(void);
static struct a {
short b;
int c;
char d;
int e;
unsigned f;
} h, j, k = {0, 4274716299}, l, *aa = 
static char g;
static short i;
static int m, ah;
static int *ac = 
static void n(struct a o) {
int aj = o.c;
int *ak = 
*ak = g && aj;
if (!(((aj) >= 0) && ((aj) <= 4274716299))) {
__builtin_unreachable();
}
i = ah;
}
int main() {
n(l);
*aa = h;
m = *ac;
if (m < 10)
;
else
foo();
;
n(k);
}

gcc-trunk -O2 does not eliminate the call to foo:

main:
subq$8, %rsp
xorl%edi, %edi
calln.isra.0
movdqa  h(%rip), %xmm0
movlh+16(%rip), %eax
movaps  %xmm0, j(%rip)
cmpl$9, j+12(%rip)
movl%eax, j+16(%rip)
jg  .L6
.L4:
movl$-20250997, %edi
xorl%eax, %eax
calln.isra.0
addq$8, %rsp
ret
.L6:
callfoo
jmp .L4

gcc-13.2.0 -O2 eliminates the call to foo:

main:
movl$0, h+12(%rip)
movlh+16(%rip), %eax
movdqa  h(%rip), %xmm0
movl%eax, j+16(%rip)
movaps  %xmm0, j(%rip)

Bisects to r14-4089-gd45ddc2c04e

[Bug target/110751] RISC-V: Suport undefined value that allows VSETVL PASS use TA/MA

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #44 from JuzheZhong  ---
Fixed on the trunk.

Hi, LiXu. Could you verify it with trunk GCC and close this PR?

Thanks

[Bug target/110751] RISC-V: Suport undefined value that allows VSETVL PASS use TA/MA

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

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

--- Comment #43 from CVS Commits  ---
The trunk branch has been updated by Lehua Ding :

https://gcc.gnu.org/g:9b5b2c9f95056f97cf95f0e8d970015aa586497b

commit r14-4194-g9b5b2c9f95056f97cf95f0e8d970015aa586497b
Author: Juzhe-Zhong 
Date:   Thu Sep 21 15:19:29 2023 +0800

RISC-V: Enable undefined support for RVV auto-vectorization[PR110751]

Now GCC middle-end can support undefined value which is traslated into
(scratch:mode).

This patch is to enable RISC-V backend undefine value in ELSE value of
COND_LEN_xxx/COND_xxx.

Consider this following case:

  __attribute__((noipa))
  void vrem_int8_t (int8_t * __restrict dst, int8_t * __restrict a, int8_t
* __restrict b, int n)
  {
for (int i = 0; i < n; i++)
  dst[i] = a[i] % b[i];
  }

Before this patch:

vrem_int8_t:
ble a3,zero,.L5
vsetvli a5,zero,e8,m1,ta,ma
vmv.v.i v4,0  ---> redundant.
.L3:
vsetvli a5,a3,e8,m1,tu,ma ---> should be TA.
vmv1r.v v1,v4 ---> redudant.
vle8.v  v3,0(a1)
vle8.v  v2,0(a2)
sub a3,a3,a5
vrem.vv v1,v3,v2
vse8.v  v1,0(a0)
add a1,a1,a5
add a2,a2,a5
add a0,a0,a5
bne a3,zero,.L3
.L5:
ret

After this patch:

vrem_int8_t:
ble a3,zero,.L5
.L3:
vsetvli a5,a3,e8,m1,ta,ma
vle8.v  v1,0(a1)
vle8.v  v2,0(a2)
sub a3,a3,a5
vrem.vv v1,v1,v2
vse8.v  v1,0(a0)
add a1,a1,a5
add a2,a2,a5
add a0,a0,a5
bne a3,zero,.L3
.L5:
ret

PR target/110751

gcc/ChangeLog:

* config/riscv/autovec.md: Enable scratch rtx in ELSE operand.
* config/riscv/predicates.md (autovec_else_operand): New predicate.
* config/riscv/riscv-v.cc (get_else_operand): New function.
(expand_cond_len_unop): Adapt ELSE value.
(expand_cond_len_binop): Ditto.
(expand_cond_len_ternop): Ditto.
* config/riscv/riscv.cc (riscv_preferred_else_value): New function.
(TARGET_PREFERRED_ELSE_VALUE): New targethook.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/binop/vdiv-rv32gcv-nofm.c: Adapt
test.
* gcc.target/riscv/rvv/autovec/binop/vdiv-rv32gcv.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vdiv-rv64gcv-nofm.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vdiv-rv64gcv.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vrem-rv32gcv.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vrem-rv64gcv.c: Ditto.
* gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-10.c: Ditto.
* gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-11.c: Ditto.
* gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-12.c: Ditto.
* gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-4.c: Ditto.
* gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-5.c: Ditto.
* gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-6.c: Ditto.
* gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-7.c: Ditto.
* gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-8.c: Ditto.
* gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-9.c: Ditto.

[Bug target/111451] RISC-V: Missed optimization of vrgather.vv into vrgatherei16.vv

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

JuzheZhong  changed:

   What|Removed |Added

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

--- Comment #2 from JuzheZhong  ---
Reopen it since I closed by mistake.

[Bug target/111450] RISC-V: Missed optimized for strided load/store with stride = element width

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

JuzheZhong  changed:

   What|Removed |Added

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

--- Comment #2 from JuzheZhong  ---
Fixed on trunk.

[Bug target/111486] [14 Regression] ICE: in require, at machmode.h:313 with -O2 -march=rv64iv

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

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

--- Comment #1 from CVS Commits  ---
The trunk branch has been updated by Lehua Ding :

https://gcc.gnu.org/g:38048fc501b3d53fc38c701ae4625024cd93bd1d

commit r14-4193-g38048fc501b3d53fc38c701ae4625024cd93bd1d
Author: Juzhe-Zhong 
Date:   Thu Sep 21 14:54:33 2023 +0800

RISC-V: Fix SUBREG move of VLS mode[PR111486]

This patch fixes this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111486

Before this patch, we can only handle (subreg:DI (reg:V8QI))

The PR ICE:

during RTL pass: reload
testcase.c: In function 'foo':
testcase.c:8:1: internal compiler error: in require, at machmode.h:313
8 | }
  | ^
0xa40cd2 opt_mode::require() const
/repo/gcc-trunk/gcc/machmode.h:313
0xa47091 opt_mode::require() const
/repo/gcc-trunk/gcc/config/riscv/riscv.cc:2546
0xa47091 riscv_legitimize_move(machine_mode, rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/config/riscv/riscv.cc:2543
0x1f1df10 gen_movdi(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/config/riscv/riscv.md:2024
0x10f1423 rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
/repo/gcc-trunk/gcc/recog.h:411
0x10f1423 emit_move_insn_1(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/expr.cc:4164
0x10f183d emit_move_insn(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/expr.cc:4334
0x13070ec lra_emit_move(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/lra.cc:509
0x132295b curr_insn_transform
/repo/gcc-trunk/gcc/lra-constraints.cc:4748
0x1324335 lra_constraints(bool)
/repo/gcc-trunk/gcc/lra-constraints.cc:5488
0x130a3d4 lra(_IO_FILE*)
/repo/gcc-trunk/gcc/lra.cc:2419
0x12bb629 do_reload
/repo/gcc-trunk/gcc/ira.cc:5970
0x12bb629 execute
/repo/gcc-trunk/gcc/ira.cc:6156

Because of (subreg:DI (reg:V2QI))

PR target/111486

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_legitimize_move): Fix bug.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr111486.c: New test.

[Bug target/111451] RISC-V: Missed optimization of vrgather.vv into vrgatherei16.vv

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

JuzheZhong  changed:

   What|Removed |Added

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

--- Comment #1 from JuzheZhong  ---
Fixed on the trunk.

[Bug tree-optimization/111514] [14 Regression] ICE: in lower_bound, at value-range.h:1078 since r14-3644-g1aceceb1e2

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

--- Comment #2 from Shaohua Li  ---
(In reply to Andrew Pinski from comment #1)
> I suspect r14-4192-g4d80863d7f93c0a839d1fe5 fixed this ...

I checked the commit r14-4192-g4d80863d7f93c0a839d1fe5, and it indeed fixed the
issue.

[Bug c++/111512] GCC's __builtin_memcpy can trigger ADL

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2023-09-21
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Yes, that seems undesirable.

Reduced:

template
void to_array(T& from)
{
  T to;
  __builtin_memcpy(, , sizeof(T));
}

struct incomplete;

template
struct holder {
T t;
};

using validator = holder*;

int main()
{
validator a[1]{};
::to_array(a);
}

Casting the arguments to void avoids the problem:

  __builtin_memcpy((void*), (void*), sizeof(T));

[Bug tree-optimization/111469] [14 Regression] Wrong code at -Os on x86_64-linux-gnu since r14-573-g69f1a8af45

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-Septemb
   ||er/631099.html
   Keywords||patch

--- Comment #6 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631099.html

[Bug libstdc++/111511] Incorrect ADL in std::to_array in GCC 11/12/13

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-09-21
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jiang An from comment #0)
> Not sure whether this should be WONTFIX since the implementation is
> fundamentally changed in GCC 14 (PR 110167).

There's no reason we can't fix the old version in the release branches.

I did notice this when rewriting it, but I didn't think to change the branches
to avoid ADL there, because I plan to backport the new implementation
eventually anyway.

[Bug tree-optimization/111495] [14 regression] ICE in lower_bound, at value-range.h:1078 when building LLVM 17.0.1 since r14-3644-g1aceceb1e2d6e8

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #6 from Sam James  ---
Yeah, all fine now. Thanks!

[Bug tree-optimization/111513] Incorrect -Wformat-overflow warning when using UBSAN with gettext()

[gcc--- via Gcc-bugs]

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

--- Comment #4 from Thomas Weißschuh  ---
Thanks for the quick response Andrew!

I'll probably disable -Werror then.


FYI:

If I drop the `#include ` and instead declare `dcgettext` on my own,
adding `__attribute__((returns_nonnull)), the issue persists.

Maybe the special handling for gettext() in GCC with regards to format_arg
conflicts here.

/* test.c
 *
 * compile with:
 *   gcc -Wall -fsanitize=undefined -O2 test.c
 */
#include 

__attribute__((format_arg(2), returns_nonnull))
extern char *dcgettext (const char *__domainname, const char *__msgid, int
__category);

int main(void)
{
FILE *out = stdout;

fputs("\n", out);
printf(dcgettext(NULL, "foo\n", 0));
fputs("\n", out);
}

$ gcc   -Wall -fsanitize=undefined -O2   test.c  -Wextra
test.c: In function ‘main’:
test.c:16:9: warning: null format string [-Wformat-overflow=]
   16 | printf(dcgettext(NULL, "foo\n", 0));
  | ^~~
test.c:16:9: warning: null format string [-Wformat-overflow=]

[Bug tree-optimization/111495] [14 regression] ICE in lower_bound, at value-range.h:1078 when building LLVM 17.0.1 since r14-3644-g1aceceb1e2d6e8

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

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

--- Comment #5 from Jiu Fu Guo  ---
(In reply to Andrew Pinski from comment #3)
> I suspect r14-4192-g4d80863d7f93c0a839d1fe5 fixed this ...

Yes, I reproduced this issue on ppc64le, and the fix r14-4192 seems to work
fine.

[Bug tree-optimization/111482] [14 Regression] ice in lower_bound with -O3

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

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

Jiu Fu Guo  changed:

   What|Removed |Added

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

--- Comment #8 from Jiu Fu Guo  ---
Fix via r14-4192-g4d80863d7f93c0a839d1fe5dc59be83153e89110.

[Bug tree-optimization/111495] [14 regression] ICE in lower_bound, at value-range.h:1078 when building LLVM 17.0.1 since r14-3644-g1aceceb1e2d6e8

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

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

--- Comment #4 from Sam James  ---
trying..

[Bug tree-optimization/111495] [14 regression] ICE in lower_bound, at value-range.h:1078 when building LLVM 17.0.1 since r14-3644-g1aceceb1e2d6e8

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

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

--- Comment #3 from Andrew Pinski  ---
I suspect r14-4192-g4d80863d7f93c0a839d1fe5 fixed this ...

[Bug tree-optimization/111514] [14 Regression] ICE: in lower_bound, at value-range.h:1078 since r14-3644-g1aceceb1e2

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Keywords||ice-on-valid-code

--- Comment #1 from Andrew Pinski  ---
I suspect r14-4192-g4d80863d7f93c0a839d1fe5 fixed this ...