date:20240522

[Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space

2024-05-22 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

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

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

commit r15-765-gd3c506eff54fcbac389a529c2e98da108a410b7f
Author: Jakub Jelinek 
Date:   Wed May 22 09:12:28 2024 +0200

ubsan: Use right address space for MEM_REF created for bool/enum
sanitization [PR115172]

The following testcase is miscompiled, because -fsanitize=bool,enum
creates a MEM_REF without propagating there address space qualifiers,
so what should be normally loaded using say %gs:/%fs: segment prefix
isn't.  Together with asan it then causes that load to be sanitized.

2024-05-22  Jakub Jelinek  

PR sanitizer/115172
* ubsan.cc (instrument_bool_enum_load): If rhs is not in generic
address space, use qualified version of utype with the right
address space.  Formatting fix.

* gcc.dg/asan/pr115172.c: New test.

[Bug tree-optimization/115144] [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095

2024-05-22 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2024-05-22
 Status|UNCONFIRMED |ASSIGNED

--- Comment #8 from Richard Biener  ---
(In reply to Hans-Peter Nilsson from comment #7)
> (In reply to Richard Biener from comment #6)
[...]
> >  I do want to play with
> > sinking to the start of the else {, but without doing any lifetime analysis
> > I fear that's going to be worse in the average as the current location
> > at least ensures we're close to the first use of the DEF we sink.
> 
> Thank you in advance and for the look this far!  I haven't looked closer at
> what happens with later passes in main, but looking at the generated
> assembly code, the "sinking" of a division has the eventual effect of
> increasing register pressure; see the previously attached dumps.

Indeed, we have originally

  _38 = _36 / _37;
  _39 = _36 % _37;
  r2_78 = (signed char) _39;

where both _36 and _37 die (but _39 and _38 are live for a lot longer).  We
sink the _38 def across

   [local count: 173045540]:
  # iftmp.10_49 = PHI 
  if (_41 >= iftmp.10_49)
goto ; [0.00%]
  else
goto ; [100.00%]

   [local count: 173045540]:
  r1.13_43 = (unsigned char) _38;

which the original profile check avoided.  I'll note the above is a more
sensible case where to avoid such sinking but I'll also note that sinking
does not look at register pressure (or basically whether a sinking
increases or decreases register pressure) at all and generally GIMPLE
passes are not supposed to do this (it's also not an easy feat).

[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu since r13-455

2024-05-22 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

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

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

commit r15-766-gdbc9b45a3c2468ad134b3a9bd4961f7ae6bc1e67
Author: Jakub Jelinek 
Date:   Wed May 22 09:13:50 2024 +0200

strlen: Fix up !si->full_string_p handling in count_nonzero_bytes_addr
[PR115152]

The following testcase is miscompiled because
strlen_pass::count_nonzero_bytes_addr doesn't handle correctly
the !si->full_string_p case.
If si->full_string_p, it correctly computes minlen and maxlen as
minimum and maximum length of the '\0' terminated stgring and
clears *nulterm (ie. makes sure !full_string_p in the ultimate
caller) if minlen is equal or larger than nbytes and so
'\0' isn't guaranteed to be among those bytes.
But in the !si->full_string_p case, all we know is that there
are [minlen,maxlen] non-zero bytes followed by unknown bytes,
so effectively the maxlen is infinite (but caller cares about only
the first nbytes bytes) and furthermore, we never know if there is
any '\0' char among those, so *nulterm needs to be always cleared.

2024-05-22  Jakub Jelinek  

PR tree-optimization/115152
* tree-ssa-strlen.cc (strlen_pass::count_nonzero_bytes_addr): If
!si->full_string_p, clear *nulterm and set maxlen to nbytes.

* gcc.dg/pr115152.c: New test.

[Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space

2024-05-22 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:

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

commit r14-10230-gd224c7d8d8b49daab54a977a4f2217423d3d12a0
Author: Jakub Jelinek 
Date:   Wed May 22 09:12:28 2024 +0200

ubsan: Use right address space for MEM_REF created for bool/enum
sanitization [PR115172]

The following testcase is miscompiled, because -fsanitize=bool,enum
creates a MEM_REF without propagating there address space qualifiers,
so what should be normally loaded using say %gs:/%fs: segment prefix
isn't.  Together with asan it then causes that load to be sanitized.

2024-05-22  Jakub Jelinek  

PR sanitizer/115172
* ubsan.cc (instrument_bool_enum_load): If rhs is not in generic
address space, use qualified version of utype with the right
address space.  Formatting fix.

* gcc.dg/asan/pr115172.c: New test.

(cherry picked from commit d3c506eff54fcbac389a529c2e98da108a410b7f)

[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu since r13-455

2024-05-22 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #10 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:

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

commit r14-10231-gfc9fb69ad624fd4cc89ff31ad0a7b8d88481c1f7
Author: Jakub Jelinek 
Date:   Wed May 22 09:13:50 2024 +0200

strlen: Fix up !si->full_string_p handling in count_nonzero_bytes_addr
[PR115152]

The following testcase is miscompiled because
strlen_pass::count_nonzero_bytes_addr doesn't handle correctly
the !si->full_string_p case.
If si->full_string_p, it correctly computes minlen and maxlen as
minimum and maximum length of the '\0' terminated stgring and
clears *nulterm (ie. makes sure !full_string_p in the ultimate
caller) if minlen is equal or larger than nbytes and so
'\0' isn't guaranteed to be among those bytes.
But in the !si->full_string_p case, all we know is that there
are [minlen,maxlen] non-zero bytes followed by unknown bytes,
so effectively the maxlen is infinite (but caller cares about only
the first nbytes bytes) and furthermore, we never know if there is
any '\0' char among those, so *nulterm needs to be always cleared.

2024-05-22  Jakub Jelinek  

PR tree-optimization/115152
* tree-ssa-strlen.cc (strlen_pass::count_nonzero_bytes_addr): If
!si->full_string_p, clear *nulterm and set maxlen to nbytes.

* gcc.dg/pr115152.c: New test.

(cherry picked from commit dbc9b45a3c2468ad134b3a9bd4961f7ae6bc1e67)

[Bug target/115025] [14/15 regression] prime computation performance regression, x86, between gcc-14 and gcc-13 on skylake platform

2024-05-22 Thread haochen.jiang at intel dot com via Gcc-bugs

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

Haochen Jiang  changed:

   What|Removed |Added

 CC||jh at suse dot cz

--- Comment #6 from Haochen Jiang  ---
>From my investigation, there are two commits related to this PR. Both of them
related to copy header pass (ch2).

This is the dump before ch2 pass for that loop.

   [local count: 109475452]:
  _4 = n_1(D) % 5;
  if (_4 == 0)
goto ; [3.66%]
  else
goto ; [96.34%]

   [local count: 105468650]:
  _24 = n_1(D) % 7;
  if (_24 == 0)
goto ; [3.66%]
  else
goto ; [96.34%]


First is r14-2675. After this commit, the ch2 pass refused to duplicate bb 9
and bb 10 for the following reason, which previously will duplicate. This
caused half of the total regression.

"Not duplicating bb 9: condition based on non-IV loop variant."

The other is r14-2709. After this commit, the ch2 pass tried to duplicate both
bb 9 and bb 10, but eventually the pass did not. However, the commit
contributed the other half of the regression.

Going to dig into deeper

[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics

2024-05-22 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
(In reply to Hongtao Liu from comment #11)
> (In reply to Jakub Jelinek from comment #10)
> > Any of the floating point to integer intrinsics if they have out of range
> > value (haven't checked whether floating point to unsigned intrinsic is a
> > problem too or not).
> > No matter if it is float or double (dunno if _Float16 too, or __bf16), and
> > no matter if it is scalar intrinsic (ss/sd etc.) or vector and how many
> > vector elements.
> > But, this isn't really a regression, GCC has always behaved that way, the
> > only thing that actually changed is that perhaps we can constant fold more
> > than we used to do in the past.
> > When not using intrinsics, IMNSHO we should keep doing what we did before.
> 
> Can we restrict them under flag_trapping_math?

If we do that, we should do it on the fold-const.cc side as well.  There we
fold it but add TREE_OVERFLOW flag in the overflow cases to the resulting tree,
whether it prevents folding or not during GIMPLE passes would need to be
figured out.

C23 in F.4 says:
If the integer type is bool, 6.3.1.2 applies and the conversion raises no
floating-point exceptions if the floating-point value is not a signaling NaN.
Otherwise, if the floating value is infinite or NaN or if the integral part of
the floating value exceeds the range of the integer type, then the "invalid"
floating-point exception is raised and the resulting value is unspecified.
Otherwise, the resulting value is determined by 6.3.1.4. Conversion of an
integral floating value that does not exceed the range of the integer type
raises no floating-point exceptions; whether conversion of a non-integral
floating value raises the "inexact" floating-point exception is unspecified.

That said, this change really won't help the backend which supposedly should
have the same behavior regardless of -fno-trapping-math, because in that case
it is the value
of the result (which is unspecified by the standards) rather than whether an
exception is triggered or not.

[Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space

2024-05-22 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #10 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:35ac28b9c26debcc8ec8b247d75d4d271de72189

commit r13-8791-g35ac28b9c26debcc8ec8b247d75d4d271de72189
Author: Jakub Jelinek 
Date:   Wed May 22 09:12:28 2024 +0200

ubsan: Use right address space for MEM_REF created for bool/enum
sanitization [PR115172]

The following testcase is miscompiled, because -fsanitize=bool,enum
creates a MEM_REF without propagating there address space qualifiers,
so what should be normally loaded using say %gs:/%fs: segment prefix
isn't.  Together with asan it then causes that load to be sanitized.

2024-05-22  Jakub Jelinek  

PR sanitizer/115172
* ubsan.cc (instrument_bool_enum_load): If rhs is not in generic
address space, use qualified version of utype with the right
address space.  Formatting fix.

* gcc.dg/asan/pr115172.c: New test.

(cherry picked from commit d3c506eff54fcbac389a529c2e98da108a410b7f)

[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu since r13-455

2024-05-22 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #11 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:53bc98f5355ada17d1629a2d0e96aebd397780c6

commit r13-8792-g53bc98f5355ada17d1629a2d0e96aebd397780c6
Author: Jakub Jelinek 
Date:   Wed May 22 09:13:50 2024 +0200

strlen: Fix up !si->full_string_p handling in count_nonzero_bytes_addr
[PR115152]

The following testcase is miscompiled because
strlen_pass::count_nonzero_bytes_addr doesn't handle correctly
the !si->full_string_p case.
If si->full_string_p, it correctly computes minlen and maxlen as
minimum and maximum length of the '\0' terminated stgring and
clears *nulterm (ie. makes sure !full_string_p in the ultimate
caller) if minlen is equal or larger than nbytes and so
'\0' isn't guaranteed to be among those bytes.
But in the !si->full_string_p case, all we know is that there
are [minlen,maxlen] non-zero bytes followed by unknown bytes,
so effectively the maxlen is infinite (but caller cares about only
the first nbytes bytes) and furthermore, we never know if there is
any '\0' char among those, so *nulterm needs to be always cleared.

2024-05-22  Jakub Jelinek  

PR tree-optimization/115152
* tree-ssa-strlen.cc (strlen_pass::count_nonzero_bytes_addr): If
!si->full_string_p, clear *nulterm and set maxlen to nbytes.

* gcc.dg/pr115152.c: New test.

(cherry picked from commit dbc9b45a3c2468ad134b3a9bd4961f7ae6bc1e67)

[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics

2024-05-22 Thread slyfox at gcc dot gnu.org via Gcc-bugs

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

--- Comment #14 from Sergei Trofimovich  ---
Created attachment 58265
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58265&action=edit
shorter-bug.cc

I shrunk bug.cc slightly further into shorter-bug.cc and now it fails equally
on gcc-13 and gcc-15. I agree that gcc-15 just got more constant folds
available now, but otherwise it's behaviour did not change.

But is it correct?

[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics

2024-05-22 Thread slyfox at gcc dot gnu.org via Gcc-bugs

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

--- Comment #15 from Sergei Trofimovich  ---
> I shrunk bug.cc slightly further into shorter-bug.cc and now it fails
> equally on gcc-13 and gcc-15. I agree that gcc-15 just got more constant
> folds available now, but otherwise it's behaviour did not change.
> 
> But is it correct?

Specifically -O0 works:

  $ /tmp/gb/gcc/xg++ -Wall -B/tmp/gb/gcc bug.cc -o bug -O0 && ./bug
overflow(i): 0x 0x

And -O2 crashes:

  $ /tmp/gb/gcc/xg++ -Wall -B/tmp/gb/gcc bug.cc -o bug -O2 && ./bug
overflow(i): 0x 0x
  Illegal instruction (core dumped)

[Bug fortran/59104] Wrong result with SIZE specification expression

2024-05-22 Thread pault at gcc dot gnu.org via Gcc-bugs

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #4 from Paul Thomas  ---
The problem lies in gfc_conv_expr_descriptor, as the following demonstrates:
module m1
   implicit none
   integer, parameter :: dp = kind([double precision::])
   contains
  function f(x)
 integer, intent(in) :: x
 real(dp) f(x/2)
 integer y(size(f)+1)

 write(*,*) 'size(f) = ',size(f)
 write(*,*) 'size(y) = ',my_size(y)
 f = 0
  end function f
  integer function my_size (arg)
integer :: arg(:)
my_size = size(arg)
  end
end module m1

program bug3
   use m1
   implicit none
   real y

   y = sum(f(2))
end program bug3

In both this and the original testcase, the result depends ultimately on a
'ubound.x' that has not been set.

I am not sure that I understand why explicit shape arrays are being handled
this way in size, when all the information needed is present in the array_spec.
However, the passing of an incorrect descriptor to 'my_size' has to be fixed.

Cheers

Paul

[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics

2024-05-22 Thread liuhongt at gcc dot gnu.org via Gcc-bugs

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

--- Comment #16 from Hongtao Liu  ---

> 
> That said, this change really won't help the backend which supposedly should
> have the same behavior regardless of -fno-trapping-math, because in that
> case it is the value
> of the result (which is unspecified by the standards) rather than whether an
> exception is triggered or not.
First, I agree with you, they're 2 separate issues.
What I proposed is just trying to find a balance that makes it possible not to
refine all cvtt* instructions to UNSPEC, because that would lose a lot of
optimization opportunities.
If it can be restricted under flag_trapping_math, at least those intrinsics are
fine at O2/O3.

[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314

2024-05-22 Thread natalie.perlin at noaa dot gov via Gcc-bugs

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

--- Comment #10 from Natalie Perlin  ---
A workaround found for gnu/14.1.0 gcc that produces error instead of warnings
at times: 
 Using cflag="-Wno-implicit-function-declaration ..." helped to avoid errors in
the code location in my previous comment.

The following "cflags" was needed to build successfully a package of the
software stack that gave troubles compiling:

 cflags="Wno-deprecated-declarations -Wno-implicit-function-declaration
-Wno-incompatible-pointer-types -Wno-implicit-int"

[Bug rtl-optimization/115182] [15 Regression] gcc.target/cris/pr93372-47.c at r15-518-g99b1daae18c095

2024-05-22 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314

2024-05-22 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #11 from Jakub Jelinek  ---
You want to fix the code as described in e.g.
https://gcc.gnu.org/gcc-14/porting_to.html , not find workarounds.  The code
was apparently never valid C99+.

[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics

2024-05-22 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #17 from Jakub Jelinek  ---
I don't think the cost of using UNSPEC would be significant if the backend
tried to constant fold more target builtins.  Anyway, with the proposed changes
perhaps you could keep using FIX/UNSIGNED_FIX for flag_trapping_math case even
for the intrinsics and use UNSPECs only for !flag_trapping_math.

[Bug debug/115066] [debug, gsplit-dwarf, gdwarf-4, g3] DW_MACRO_define_strp used for debug_str_offsets index

2024-05-22 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by Rainer Orth :

https://gcc.gnu.org/g:6c97934fde7caf483ffc5079eb8ca4af04354a2c

commit r15-767-g6c97934fde7caf483ffc5079eb8ca4af04354a2c
Author: Tom de Vries 
Date:   Wed May 22 10:06:10 2024 +0200

testsuite: Allow for non-SECTION_MERGE systems in gcc.dg/pr115066.c
[PR115066]

gcc.dg/pr115066.c currently FAILs on Solaris/SPARC with the native as:

FAIL: gcc.dg/pr115066.c scan-assembler .bytet0xbt# Define macro
strx

Instead of the expected

.byte   0xb ! Define macro strx

the assembler output contains

.byte   0x1 ! Define macro

Apparently this happens because the Solaris as/ld combo doesn't support
SHF_MERGE.

While I initially meant to just skip the test on sparc*-*-solaris2* &&
!gas,
Tom suggested to allow for both forms instead, which is what his patch
does.

Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11 (as and gas
each) and x86_64-pc-linux-gnu.

2024-05-21  Tom de Vries  

gcc/testsuite:
PR debug/115066
* gcc.dg/pr115066.c (scan-assembler): Allow for alternative form
of Define macro.

[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5

2024-05-22 Thread ibuclaw at gcc dot gnu.org via Gcc-bugs

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

--- Comment #11 from ibuclaw at gcc dot gnu.org ---
(In reply to Iain Sandoe from comment #0)
> At present, still trying to figure out how to debug this further .. it's D
> so no preprocessed output - I guess will have to try tree dumps.
Dustmite would help reduce it if you have a reliable automated test.

[Bug web/115183] GCCGO appears twice at https://gcc.gnu.org/onlinedocs/14.1.0/

2024-05-22 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
I fixed the GCCGO references and the typo.

[Bug tree-optimization/113524] FAIL: gcc.dg/torture/pr113026-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for bogus messages, line 10)

2024-05-22 Thread ro at gcc dot gnu.org via Gcc-bugs

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

Rainer Orth  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Rainer Orth  ---
FWIW, I've now found that on sparc-sun-solaris2.11 (32-bit only) the warning
occurs as far back as gcc 10 with just

gcc -O3 -ftracer

Back in gcc 10, it would happen for both -m32 and -m64, while from gcc 11
onward, it's for -m32 only.

[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics

2024-05-22 Thread amonakov at gcc dot gnu.org via Gcc-bugs

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

--- Comment #18 from Alexander Monakov  ---
No, allowing value-changing transformations under -ftrapping-math is really not
appropriate. Invoking the intrinsic on a large floating-point value is not UB.

[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics

2024-05-22 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #19 from Jakub Jelinek  ---
(In reply to Alexander Monakov from comment #18)
> No, allowing value-changing transformations under -ftrapping-math is really
> not appropriate. Invoking the intrinsic on a large floating-point value is
> not UB.

If we guarantee that we never constant fold FIX/UNSIGNED_FIX with
-ftrapping-math (we shouldn't, as the exceptions should be raised), then using
FIX/UNSIGNED_FIX is ok in
flag_trapping_math guarded patterns even if the intrinsics have some specific
value they want in those cases, because they will never be folded.
While for !flag_trapping_math, we should use UNSPEC because FIX/UNSIGNED_FIX
can be folded and would be folded to whatever the generic code decides, which
might disagree to what the intrinsics need.

[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5

2024-05-22 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

--- Comment #12 from Richard Biener  ---
How do I reproduce this?  I tried, on x86_64-linux an all-language bootstrap
using gdc-13 for the first stage and that succeeded.  I'm now trying again
with gdc-12, just --enable-languages=d and an explicit
--with-built-config=bootstrap-debug

[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5

2024-05-22 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

--- Comment #13 from Richard Biener  ---
(In reply to Iain Sandoe from comment #9)
> (In reply to Richard Biener from comment #8)
> > I've pushed a fix for PR115137, it's likely this fixes also this bug.
> 
> unfortunately, not; at least, on my fastest x86 machine (AVX512) - the fail
> is the same (different CSWTCH.xxx numbers between the stage1 compiler and
> the stage2 - the numbers are unchanged with the r15-753 [.154 and .155
> respectively]).

Note stage1 and stage2 are not expected to compare equal - it's stage2 and
stage3 objects that are compared.

> I don't expect the machine to make any difference - and I saw that this was
> also reported by at least one person for Linux too (although bootstrapping
> with O3, I think).

I think that was an ICE with prange.

[Bug tree-optimization/108357] [13 Regression] Dead Code Elimination Regression at -O2 since r13-4607-g2dc5d6b1e7ec88

2024-05-22 Thread ro at gcc dot gnu.org via Gcc-bugs

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

Rainer Orth  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #22 from Rainer Orth  ---
As reported, the test still FAILs on Solaris/SPARC (and always had).  Also
happens on Linux/sparc64, btw., so nothing Solaris-specific in here.

[Bug tree-optimization/115184] New: gcc.dg/vect/vect-33.c FAILs

2024-05-22 Thread ro at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 115184
   Summary: gcc.dg/vect/vect-33.c FAILs
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-sun-solaris2.11

Since 20230801, the gcc.dg/vect/vect-33.c test FAILs on 32 and 64-bit
Solaris/SPARC:

FAIL: gcc.dg/vect/vect-33.c -flto -ffat-lto-objects  scan-tree-dump-not
optimized "Invalid sum"
FAIL: gcc.dg/vect/vect-33.c scan-tree-dump-not optimized "Invalid sum"

Obviously due to this patch:

commit 1762957384c659a2e6827939ce4b1f1d1ad40003
Author: Jan Hubicka 
Date:   Tue Aug 1 12:07:39 2023 +0200

[Bug tree-optimization/115184] gcc.dg/vect/vect-33.c FAILs

2024-05-22 Thread ro at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Rainer Orth  ---
Created attachment 58266
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58266&action=edit
32-bit sparc-sun-solaris2.11 vect-33.c.265t.optimized

[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics

2024-05-22 Thread amonakov at gcc dot gnu.org via Gcc-bugs

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

--- Comment #20 from Alexander Monakov  ---
(In reply to Jakub Jelinek from comment #19)
> If we guarantee that we never constant fold FIX/UNSIGNED_FIX with
> -ftrapping-math (we shouldn't, as the exceptions should be raised), then
> using FIX/UNSIGNED_FIX is ok in
> flag_trapping_math guarded patterns even if the intrinsics have some
> specific value they want in those cases, because they will never be folded.

No, this sounds illogical. The compiler may fold out-of-range conversions just
fine, it just needs to preserve the original operation (with its result now
dead), or use any other opportunity to ensure that exceptions are still raised.
Specifically, it is okay to transform

float f;
int i;

f = 0x0.8p+33f;
i = (int) f;

to

f = 0x0.8p+33f;
dummy = (int) f;
i = INT_MAX; // or whatever

The "known" value of 'i' may then facilitate further folding.

[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5

2024-05-22 Thread iains at gcc dot gnu.org via Gcc-bugs

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

--- Comment #14 from Iain Sandoe  ---
(In reply to Richard Biener from comment #13)
> (In reply to Iain Sandoe from comment #9)
> > (In reply to Richard Biener from comment #8)
> > > I've pushed a fix for PR115137, it's likely this fixes also this bug.

> Note stage1 and stage2 are not expected to compare equal - it's stage2 and
> stage3 objects that are compared.

Right, for the runtime objects they are built with the stage2 and stage3
compilers,
but for the language objects (like the one we see here), those are built with
the stage1 and stage2 compilers.  I did check manually that the stage3 compiler
does do the same as the stage2 (and that -fdebug-compare does not fail(.


>> I don't expect the machine to make any difference - and I saw that this was
>> also reported by at least one person for Linux too (although bootstrapping
>> with O3, I think).


>I think that was an ICE with prange.


Hmm, I thougt I saw toon report the same file with a -O3 bootstrap on Linux:

make[3]: Leaving directory '/home/toon/scratch/bld2850364'
Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/d/opover.o differs
make[2]: *** [Makefile:37306: compare] Error 1

[Bug libstdc++/115145] Help lambda in rewritten std::variant comparisons does not specify return type

2024-05-22 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

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

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

commit r15-769-gb33f44ca6ce2dae7502ce138600e1631ffc9232c
Author: Jonathan Wakely 
Date:   Tue May 21 15:13:01 2024 +0100

libstdc++: Ensure std::variant relops convert to bool [PR115145]

Ensure that the result of comparing the variant alternatives is
converted to bool immediately rather than copied.

libstdc++-v3/ChangeLog:

PR libstdc++/115145
* include/std/variant (operator==, operator!=, operator<)
(operator<=, operator>, operator>=): Add trailing-return-type to
lambda expressions to trigger conversion to bool.
* testsuite/20_util/variant/relops/115145.cc: New test.

[Bug libstdc++/115099] compilation error: format thread::id

2024-05-22 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

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

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

commit r15-770-g1a5e4dd83788ea4c049d354d83ad58a6a3d747e6
Author: Jonathan Wakely 
Date:   Fri May 17 10:55:32 2024 +0100

libstdc++: Implement std::formatter without 
[PR115099]

The std::thread::id formatter uses std::basic_ostringstream without
including , which went unnoticed because the test for it uses
a stringstream to check the output is correct.

The fix implemented here is to stop using basic_ostringstream for
formatting thread::id and just use std::format instead.

As a drive-by fix, the formatter specialization is constrained to
require that the thread::id::native_handle_type can be formatted, to
avoid making the formatter ill-formed if the pthread_t type is not a
pointer or integer. Since non-void pointers can't be formatted, ensure
that we convert pointers to const void* for formatting. Make a similar
change to the existing operator<< overload so that in the unlikely case
that pthread_t is a typedef for char* we don't treat it as a
null-terminated string when inserting into a stream.

libstdc++-v3/ChangeLog:

PR libstdc++/115099
* include/bits/std_thread.h: Declare formatter as friend of
thread::id.
* include/std/thread (operator<<): Convert non-void pointers to
void pointers for output.
(formatter): Add constraint that thread::native_handle_type is a
pointer or integer.
(formatter::format): Reimplement without basic_ostringstream.
* testsuite/30_threads/thread/id/output.cc: Check output
compiles before  has been included.

[Bug tree-optimization/114154] gcc.dg/vect/vect-alias-check-1.c XPASSes

2024-05-22 Thread ro at gcc dot gnu.org via Gcc-bugs

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

Rainer Orth  changed:

   What|Removed |Added

 CC||felix.yang at huawei dot com

--- Comment #5 from Rainer Orth  ---
Felix, can you have a look please?

[Bug tree-optimization/114072] gcc.dg/vect/vect-pr111779.c FAILs

2024-05-22 Thread ro at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Rainer Orth  ---
Richard, any suggestion on how to handle this?  There are 3 instances of
"not vectorized" in the dump:

/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-pr111779.c:29:23:
missed:   not vectorized: relevant stmt not supported: _4 = a$b4_6 >> 7;
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-pr111779.c:36:1:
missed:   not vectorized: relevant stmt not supported: _ifc__32 =
x[i_15].D.2986;
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-pr111779.c:45:17:
missed:  not vectorized: no grouped stores in basic block.

[Bug libstdc++/114940] std::generator relies on an optional overload of operator delete

2024-05-22 Thread redi at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from Jonathan Wakely  ---
We have the same problem in

[Bug tree-optimization/114072] gcc.dg/vect/vect-pr111779.c FAILs

2024-05-22 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Richard Biener  ---
Hmm, is solaris-sparc big-endian?  It seems so.  That makes the bitfield
access require a VnQImode logical right shift (but little-endian doesn't
require it - it's actually bitfield endianess that matters).

There is vect_shift_char you could use and somehow conditionalize that
on big-endianess.

[Bug libstdc++/114940] std::generator relies on an optional overload of operator delete

2024-05-22 Thread redi at gcc dot gnu.org via Gcc-bugs

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |13.4
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|NEW |ASSIGNED

[Bug c/115185] New: Missing "too long" warning when string-array size doesn't include NULL byte

2024-05-22 Thread Hi-Angel at yandex dot ru via Gcc-bugs

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

Bug ID: 115185
   Summary: Missing "too long" warning when string-array size
doesn't include NULL byte
   Product: gcc
   Version: 14.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Hi-Angel at yandex dot ru
  Target Milestone: ---

It's a common pattern to have some `enum Foo { one, two, three }`, and then
some 2-dimensinal array `FooAsString`, which allows one to get name of the
`Foo` field by passing an index, like `printf("%s",
FooAsString[my_Foo_variable])`.

Problem though is that it isn't allowed to declare multi-dimensinal array and
omit all dimensions, so one have to declare as `FooAsString[][6]` for example.
That makes programmer to rely on the compiler to detect when the `6` is not
enough to hold the string.

GCC kind of tries to warn about that, however its check is off-by-one because
it does not take into account the NULL byte that the C-string has to end with.


# Steps to reproduce (in terms of terminal commands)

λ cat test.c
#include 

int main() {
enum Foo {
hello,
} obj = hello;
static const char description[][5] = {[hello] = "hello"};

printf("%s", description[obj]);
}
λ gcc test.c -o a -Wall -Wextra


## Expected

A warning:

test.c:7:53: warning: initializer-string for array of ‘char’ is too long
7 | static const char description[][5] = {[hello] = "hello"};

## Actual

No warnings.

[Bug rtl-optimization/115186] New: Suboptimal codes generated by rtl-expand for divmod

2024-05-22 Thread dizhao at os dot amperecomputing.com via Gcc-bugs

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

Bug ID: 115186
   Summary: Suboptimal codes generated by rtl-expand for divmod
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dizhao at os dot amperecomputing.com
  Target Milestone: ---

For the code below:

typedef unsigned short int uint16_t;
typedef unsigned char uint8_t;
typedef long unsigned int size_t;

uint16_t fletcher16(const uint8_t *data, const size_t len)
{
register uint16_t sum1 = 0, sum2 = 0;
register size_t i;

for (i = 0; i < len; i++) {
sum1 = (sum1 + data[i]) % 255;
sum2 = (sum2 + sum1) % 255;
}
return ((uint16_t)(sum2 << 8)) | sum1;
}

, when compiled with "-O3 -mcpu=ampere1a", shift+add is used instead of div.
The dump file at 266r.expand shows:

   20: NOTE_INSN_BASIC_BLOCK 4
   21: debug i => r114:DI-r116:DI
   22: debug sum2 => r111:SI#0
   23: debug sum1 => r110:SI#0
   24: debug begin stmt marker
   25: r118:SI=zero_extend([r114:DI])
   26: r119:SI=r118:SI+r110:SI
   27: r120:DI=zero_extend(r119:SI)
   28: r121:DI=r120:DI
   29: r122:DI=r121:DI<<0x8
   30: r123:DI=r122:DI+r120:DI
  REG_EQUAL r120:DI*0x101
   31: r124:DI=r123:DI<<0x10
   32: r125:DI=r123:DI+r124:DI
  REG_EQUAL r120:DI*0x1010101
   33: r126:DI=r125:DI<<0x7
   34: r127:DI=r126:DI+r120:DI
  REG_EQUAL r120:DI*0x80808081
   35: r128:DI=r127:DI 0>>0x20
   36: r104:SI=r128:DI#0 0>>0x7
  REG_EQUAL udiv(r119:SI,0xff)
   ...

However, using mult instruction is better, like (the result can be produce with
"-mtune=neoverse-n1"):

   20: NOTE_INSN_BASIC_BLOCK 4
   21: debug i => r114:DI-r116:DI
   22: debug sum2 => r111:SI#0
   23: debug sum1 => r110:SI#0
   24: debug begin stmt marker
   25: r118:SI=zero_extend([r114:DI])
   26: r119:SI=r118:SI+r110:SI
   27: r121:SI=0x80808081
   28: r120:DI=zero_extend(r119:SI)*zero_extend(r121:SI)
   29: r122:DI=r120:DI 0>>0x20
   30: r104:SI=r122:DI#0 0>>0x7
  REG_EQUAL udiv(r119:SI,0xff)
   ...

The problem is, in expmed.cc:expmed_mult_highpart, when the result here is 0:
  /* See whether the specialized multiplication optabs are
 cheaper than the shift/add version.  */
  tem = expmed_mult_highpart_optab (mode, op0, narrow_op1, target,
unsignedp,

, the "tem" produced by the code that follows (shift/add version) can be more
expensive than the result of:
  return expmed_mult_highpart_optab (mode, op0, op1, target, unsignedp,
 max_cost);

For -mcpu=ampere1a, the estimated cost of the former is 36, the cost of the
latter is 28.

[Bug rtl-optimization/115186] Suboptimal codes generated by rtl-expand for divmod

2024-05-22 Thread dizhao at os dot amperecomputing.com via Gcc-bugs

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

--- Comment #1 from Di Zhao  ---
A raw fix below can fix this case (not sure if this is the right way):

diff --git a/gcc/expmed.cc b/gcc/expmed.cc
index 50d22762cae..bf42a0ff5ca 100644
--- a/gcc/expmed.cc
+++ b/gcc/expmed.cc
@@ -3976,7 +3976,10 @@ expmed_mult_highpart (scalar_int_mode mode, rtx op0, rtx
op1,
   bool sign_adjust = false;
   enum mult_variant variant;
   struct algorithm alg;
-  rtx narrow_op1, tem;
+  rtx narrow_op1, tem, tem2;
+  rtx_insn *shift_add_insns;
+  rtx_insn *mult_insns;
+  unsigned shift_add_cost, mult_cost;

   /* We can't support modes wider than HOST_BITS_PER_INT.  */
   gcc_assert (HWI_COMPUTABLE_MODE_P (mode));
@@ -4014,6 +4017,7 @@ expmed_mult_highpart (scalar_int_mode mode, rtx op0, rtx
op1,
   if (tem)
return tem;

+  start_sequence ();
   tem = convert_to_mode (wider_mode, op0, unsignedp);
   tem = expand_mult_const (wider_mode, tem, cnst1, 0, &alg, variant);
   tem = extract_high_half (mode, tem);
@@ -4021,8 +4025,29 @@ expmed_mult_highpart (scalar_int_mode mode, rtx op0, rtx
op1,
   /* Adjust result for signedness.  */
   if (sign_adjust)
tem = force_operand (gen_rtx_MINUS (mode, tem, op0), tem);
+  shift_add_insns = get_insns ();
+  end_sequence ();
+  shift_add_cost = seq_cost (shift_add_insns, speed);
+  
+  start_sequence ();
+  tem2 = expmed_mult_highpart_optab (mode, op0, op1, target, unsignedp,
+max_cost);
+  mult_insns = get_insns ();
+  end_sequence ();
+  mult_cost = seq_cost (mult_insns, speed);

-  return tem;
+  if (tem2 && mult_cost < shift_add_cost)
+   {
+ emit_insn (mult_insns);
+ return tem2;
+   }
+  else if (shift_add_cost < max_cost)
+   {
+ emit_insn (shift_add_insns);
+ return tem;
+   }
+  else
+   return 0;
 }
   return expmed_mult_highpart_optab (mode, op0, narrow_op1, target,
 unsignedp, max_cost);

[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte

2024-05-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Andrew Pinski  ---
Note in c, "abc" is valid for [3] initializer . This is different from c++.

There is a dup of this bug already filed asking to add the warning. I think it
was added but it is not included in either -Wextra nor -Wall.

[Bug c++/115187] New: ICE when deleting temporary array

2024-05-22 Thread mital at mitalashok dot co.uk via Gcc-bugs

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

Bug ID: 115187
   Summary: ICE when deleting temporary array
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mital at mitalashok dot co.uk
  Target Milestone: ---

A delete-expression where the operand comes from a temporary array causes an
internal compiler error

https://godbolt.org/z/7a9sM9KqT

void f() {
  using T = int[2];
  delete T{};
}


test.cpp: In function ‘void f()’:
test.cpp:3:10: warning: deleting array ‘T()’
3 |   delete T{};
  |  ^~~
test.cpp:1:6: internal compiler error: in verify_gimple_stmt, at
tree-cfg.cc:5169
1 | void f() {
  |  ^
0x9069f1 verify_gimple_stmt
./gcc/gcc/tree-cfg.cc:5169
0x13ed54f verify_gimple_in_seq_2
./gcc/gcc/tree-cfg.cc:5288
0x13ed518 verify_gimple_in_seq_2
./gcc/gcc/tree-cfg.cc:5257
0x13ed588 verify_gimple_in_seq_2
./gcc/gcc/tree-cfg.cc:5252
0x13ed5ed verify_gimple_in_seq(gimple*, bool)
./gcc/gcc/tree-cfg.cc:5327
0x107426b gimplify_body(tree_node*, bool)
./gcc/gcc/gimplify.cc:19237
0x10743f9 gimplify_function_tree(tree_node*)
./gcc/gcc/gimplify.cc:19355
0xe873c7 cgraph_node::analyze()
./gcc/gcc/cgraphunit.cc:687
0xe899d7 analyze_functions
./gcc/gcc/cgraphunit.cc:1251
0xe8a721 symbol_table::finalize_compilation_unit()
./gcc/gcc/cgraphunit.cc:2560
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.

This also happens when the array is a subobject of a temporary:

struct X { int x[2]; };
void f() {
  delete X{}.x;
}

This also happens if the operand is a pointer derived from that array, `delete
+T{};`, `delete (T{} + 1);`, `delete +X{}.x;`, `delete (X{}.x + 1)`

[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu since r13-455

2024-05-22 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #12 from Jakub Jelinek  ---
Fixed for 13.4+/14.2+/15.1+.

[Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space

2024-05-22 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #11 from Jakub Jelinek  ---
Fixed for 13.4+/14.2+/15.1+ so far.

[Bug target/114860] [14/15 regression] [aarch64] 511.povray regresses by ~5.5% with -O3 -flto -march=native -mcpu=neoverse-v2 since r14-10014-ga2f4be3dae04fa

2024-05-22 Thread prathamesh3492 at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from prathamesh3492 at gcc dot gnu.org ---
Hi Tamar,
Using -falign-loops=5 indeed brings back the performance.
The adrp instruction has same address (0x4ae784) by setting -falign-loops=5
(which reduces misalignment to 4) with/without a2f4be3dae0. So I guess this is
really code-alignment issue ?

(Also in our latest builds the regression has seemingly gone away without any
adjustments to code alignment)

Thanks,
Prathamesh

[Bug tree-optimization/114072] gcc.dg/vect/vect-pr111779.c FAILs

2024-05-22 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #2 from Richard Biener  ---
> Hmm, is solaris-sparc big-endian?  It seems so.  That makes the bitfield

It is indeed.

> access require a VnQImode logical right shift (but little-endian doesn't
> require it - it's actually bitfield endianess that matters).
>
> There is vect_shift_char you could use and somehow conditionalize that
> on big-endianess.

I think the best we can do then is

/* { dg-skip-if "PR tree-optimization/114072" { be && { ! vect_shift_char } } }
*/

Lets the test become UNSUPPORTED on 32 and 64-bit SPARC, but still PASS
as before on 32 and 64-bit x86.

[Bug target/114860] [14/15 regression] [aarch64] 511.povray regresses by ~5.5% with -O3 -flto -march=native -mcpu=neoverse-v2 since r14-10014-ga2f4be3dae04fa

2024-05-22 Thread tnfchris at gcc dot gnu.org via Gcc-bugs

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

--- Comment #9 from Tamar Christina  ---
(In reply to prathamesh3492 from comment #8)
> Hi Tamar,
> Using -falign-loops=5 indeed brings back the performance.
> The adrp instruction has same address (0x4ae784) by setting -falign-loops=5
> (which reduces misalignment to 4) with/without a2f4be3dae0. So I guess this
> is really code-alignment issue ?
> 

Indeed, we don't aggressively align loops if they require too much padding to
not bloat the binaries too much.  That's why sometimes you just get unlucky and
the hot loop gets misaligned.

[Bug testsuite/102954] [12/13/14/15 regression] gcc.dg/vect/pr33804.c XPASSes

2024-05-22 Thread ro at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from Rainer Orth  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> > --- Comment #1 from Richard Biener  ---
> > It was likely the vect_worthwhile_without_simd_p changes where we might now
> > vectorize this loop using (unaligned) 'int'.
> >
> > Can you confirm that?
> 
> Indeed.  I've also noticed that another regression was caused by the
> same change:
> 
> XPASS: gcc.dg/vect/slp-multitypes-3.c -flto -ffat-lto-objects 
> scan-tree-dump-times vect "vectorized 1 loops" 1
> XPASS: gcc.dg/vect/slp-multitypes-3.c -flto -ffat-lto-objects 
> scan-tree-dump-times vect "vectorizing stmts using SLP" 2
> XPASS: gcc.dg/vect/slp-multitypes-3.c scan-tree-dump-times vect "vectorized
> 1 loops" 1
> XPASS: gcc.dg/vect/slp-multitypes-3.c scan-tree-dump-times vect "vectorizing
> stmts using SLP" 2
> 
> Again 64-bit SPARC.

That test already has

/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { xfail
sparc*-*-* } } } */

so we could change the xfail to { sparc*-*-* && ilp32 } (although that might be
papering over the real issue).

[Bug libstdc++/115099] compilation error: format thread::id

2024-05-22 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

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

https://gcc.gnu.org/g:4896bb3199253dc350f8fb5ff63370310ca27ce2

commit r14-10232-g4896bb3199253dc350f8fb5ff63370310ca27ce2
Author: Jonathan Wakely 
Date:   Fri May 17 10:55:32 2024 +0100

libstdc++: Implement std::formatter without 
[PR115099]

The std::thread::id formatter uses std::basic_ostringstream without
including , which went unnoticed because the test for it uses
a stringstream to check the output is correct.

The fix implemented here is to stop using basic_ostringstream for
formatting thread::id and just use std::format instead.

As a drive-by fix, the formatter specialization is constrained to
require that the thread::id::native_handle_type can be formatted, to
avoid making the formatter ill-formed if the pthread_t type is not a
pointer or integer. Since non-void pointers can't be formatted, ensure
that we convert pointers to const void* for formatting. Make a similar
change to the existing operator<< overload so that in the unlikely case
that pthread_t is a typedef for char* we don't treat it as a
null-terminated string when inserting into a stream.

libstdc++-v3/ChangeLog:

PR libstdc++/115099
* include/bits/std_thread.h: Declare formatter as friend of
thread::id.
* include/std/thread (operator<<): Convert non-void pointers to
void pointers for output.
(formatter): Add constraint that thread::native_handle_type is a
pointer or integer.
(formatter::format): Reimplement without basic_ostringstream.
* testsuite/30_threads/thread/id/output.cc: Check output
compiles before  has been included.

(cherry picked from commit 1a5e4dd83788ea4c049d354d83ad58a6a3d747e6)

[Bug libstdc++/115099] compilation error: format thread::id

2024-05-22 Thread redi at gcc dot gnu.org via Gcc-bugs

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed for 14.2, thanks for the report.

[Bug c++/115139] [14 Regression] Enum inside variadic template class can't define one of self with usage another value from this enum

2024-05-22 Thread pavel at karpychev dot name via Gcc-bugs

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

--- Comment #5 from Pavel  ---
Thank you for the fix!

[Bug testsuite/115140] [15 regression] libgomp.oacc-c++/../libgomp.oacc-c-c++-common/acc_prof-kernels-1.c excess errors after r15-579-ga9251ab3c91c8c

2024-05-22 Thread ro at gcc dot gnu.org via Gcc-bugs

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

Rainer Orth  changed:

   What|Removed |Added

   Host|powerpc64-linux-gnu,|powerpc64-linux-gnu,
   |powerpc64le-linux-gnu   |powerpc64le-linux-gnu,
   ||*-*-solaris2.11
 CC||ro at gcc dot gnu.org
  Build|powerpc64-linux-gnu,|powerpc64-linux-gnu,
   |powerpc64le-linux-gnu   |powerpc64le-linux-gnu,
   ||*-*-solaris2.11
 Target|powerpc64-linux-gnu,|powerpc64-linux-gnu,
   |powerpc64le-linux-gnu   |powerpc64le-linux-gnu,
   ||*-*-solaris2.11

--- Comment #2 from Rainer Orth  ---
Also seen on Solaris/SPARC and x86.

[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte

2024-05-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Andrew Pinski  ---
It is included in -Wc++-compat .

[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte

2024-05-22 Thread Hi-Angel at yandex dot ru via Gcc-bugs

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

--- Comment #3 from Konstantin Kharlamov  ---
(In reply to Andrew Pinski from comment #2)
> It is included in -Wc++-compat .

Cool, thanks! I'll add the warning to the list we compile the project with,
thank you!

[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5

2024-05-22 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

--- Comment #15 from Richard Biener  ---
Indeed with boostrap-O3 I can see

Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/d/opover.o differs

since both have debug info with bootstrap-O3 the difference is only

-18: 0b0c 4 OBJECT  LOCAL  DEFAULT6 CSWTCH.154
+18: 0b0c 4 OBJECT  LOCAL  DEFAULT6 CSWTCH.155

there's already differenes in SRA and even local-fnsummary.  In fact
gimplification shows

--- ../prev-gcc/d/opover.d.006t.gimple  2024-05-22 13:50:13.437438763 +0200
+++ d/opover.d.006t.gimple  2024-05-22 13:51:08.710863322 +0200
@@ -5158,57 +5158,58 @@
 overflow = 0;
 newLength.100_2 = newLength;
 newLength.101_3 = newLength.100_2;
+newLength.102_4 = newLength.101_3;
 D.12117 = .ADD_OVERFLOW (typeInfoSize, 1);

as first difference (but the .original dumps are the same).  That's in
the __setArrayAllocLength function.

Note the opover.d compile doesn't even use -O3, so this is all extremely
odd.  It would somehow point at a miscompile of the stage2 compiler by
the stage1 compiler manifesting itself only in this change ...

So the logical next step would be to bisect stage1/stage2 object files
of d21 and see which stage2 object is miscompiled.

[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte

2024-05-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Andrew Pinski  ---
: In function 'main':
:8:57: warning: initializer-string for array of 'char' is too long for
C++ [-Wc++-compat]
8 | static const char description[][5] = {[hello] = "hello"};
  | ^~~


There is a patch floating around to add it as a different option besides just
C++-compat too:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651664.html

[Bug tree-optimization/114072] gcc.dg/vect/vect-pr111779.c FAILs

2024-05-22 Thread rguenther at suse dot de via Gcc-bugs

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

--- Comment #4 from rguenther at suse dot de  ---
On Wed, 22 May 2024, ro at CeBiTec dot Uni-Bielefeld.DE wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114072
> 
> --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
> > --- Comment #2 from Richard Biener  ---
> > Hmm, is solaris-sparc big-endian?  It seems so.  That makes the bitfield
> 
> It is indeed.
> 
> > access require a VnQImode logical right shift (but little-endian doesn't
> > require it - it's actually bitfield endianess that matters).
> >
> > There is vect_shift_char you could use and somehow conditionalize that
> > on big-endianess.
> 
> I think the best we can do then is
> 
> /* { dg-skip-if "PR tree-optimization/114072" { be && { ! vect_shift_char } } 
> }
> */
> 
> Lets the test become UNSUPPORTED on 32 and 64-bit SPARC, but still PASS
> as before on 32 and 64-bit x86.

Can we instead guard the scan-tree-dump?  This way the correctness
execute part still is exercised?

[Bug tree-optimization/114072] gcc.dg/vect/vect-pr111779.c FAILs

2024-05-22 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #4 from rguenther at suse dot de  ---
[...]
>> I think the best we can do then is
>> 
>> /* { dg-skip-if "PR tree-optimization/114072" { be && { ! vect_shift_char } 
>> } }
>> */
>> 
>> Lets the test become UNSUPPORTED on 32 and 64-bit SPARC, but still PASS
>> as before on 32 and 64-bit x86.
>
> Can we instead guard the scan-tree-dump?  This way the correctness
> execute part still is exercised?

Sure, even if the result is somewhat hard to read with all those levels
of braces:

/* { dg-final { scan-tree-dump "LOOP VECTORIZED" "vect" { target { vect_int &&
{ le || { be && vect_shift_char } } } } } } */

This way, all of compile, execute, and scan are run on x86, while on
sparc it's only compile, execute.

[Bug tree-optimization/114072] gcc.dg/vect/vect-pr111779.c FAILs

2024-05-22 Thread rguenther at suse dot de via Gcc-bugs

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

--- Comment #6 from rguenther at suse dot de  ---
On Wed, 22 May 2024, ro at CeBiTec dot Uni-Bielefeld.DE wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114072
> 
> --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
> > --- Comment #4 from rguenther at suse dot de  ---
> [...]
> >> I think the best we can do then is
> >> 
> >> /* { dg-skip-if "PR tree-optimization/114072" { be && { ! vect_shift_char 
> >> } } }
> >> */
> >> 
> >> Lets the test become UNSUPPORTED on 32 and 64-bit SPARC, but still PASS
> >> as before on 32 and 64-bit x86.
> >
> > Can we instead guard the scan-tree-dump?  This way the correctness
> > execute part still is exercised?
> 
> Sure, even if the result is somewhat hard to read with all those levels
> of braces:
> 
> /* { dg-final { scan-tree-dump "LOOP VECTORIZED" "vect" { target { vect_int &&
> { le || { be && vect_shift_char } } } } } } */
> 
> This way, all of compile, execute, and scan are run on x86, while on
> sparc it's only compile, execute.

Looks good, pre-approved.

[Bug libstdc++/115122] Incorrect detection of C99 support when cross back builds

2024-05-22 Thread tomas.kalibera at gmail dot com via Gcc-bugs

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

--- Comment #2 from Tomas Kalibera  ---
(In reply to Andrew Pinski from comment #1)
> When I do cross back builds, I normally don't rebuild the target libraries
> and just use the already built target libraries from the cross builds. Since
> you are now building the target libraries twice and you really don't need to
> though.

Thanks, but it is still a bug, right? I've got a report from a user who ran
into this in gcc built via MXE (specifically via Rtools which are a fork of MXE
for building R and packages), plugins/examples/host-toolchain/gcc-host. I
assume MXE builds libstdc++ twice to simplify maintenance of the build scripts
which would otherwise have to somehow copy some of the files from the previous
build (and ccache is used). The docker file attached is a simplified version of
the build but retains the same problem.

[Bug c++/115187] ICE when deleting temporary array

2024-05-22 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-05-22
   Keywords||accepts-invalid,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Confirmed.  Missed gimplification:

#1  0x01c12d7e in verify_gimple_stmt (
stmt=)
at /space/rguenther/src/gcc/gcc/tree-cfg.cc:5169

try
  {
<<< Unknown GIMPLE statement: gimple_with_cleanup_expr >>>

D.2795 = {};
D.2796 = &D.2795;
MEM[(int *)D.2796] = {CLOBBER(eob)};
  }
finally
  {
operator delete (D.2796, 4);
  }


clang complains:

t.ii:3:7: error: cannot delete expression of type 'T' (aka 'int[2]')
3 |   delete T{};
  |   ^  ~~~

[Bug c++/115187] [14/15 Regression] ICE when deleting temporary array

2024-05-22 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

Summary|ICE when deleting temporary |[14/15 Regression] ICE when
   |array   |deleting temporary array
   Target Milestone|--- |14.2
   Priority|P3  |P2
  Known to work||13.2.0

--- Comment #2 from Richard Biener  ---
And GCC 13 complains:

t.ii: In function ‘void f()’:
t.ii:3:14: warning: deleting array ‘T()’
3 |   delete T{};
  |  ^~~
t.ii:3:14: error: taking address of temporary array
t.ii:3:14: error: type ‘using T = int [2]’ {aka ‘int [2]’} argument given to
‘delete’, expected pointer

[Bug target/115188] New: [14/15 regression] invalid Thumb assembly for atomic store in loop on ARMv6

2024-05-22 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 115188
   Summary: [14/15 regression] invalid Thumb assembly for atomic
store in loop on ARMv6
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ebotcazou at gcc dot gnu.org
  Target Milestone: ---

This apparently comes from the fix for PR target/111235: the following code:

int data[4];

void init (unsigned int lb, unsigned int hb)
{
  for (unsigned int i = lb; i < hb; i++)
__atomic_store_4 (&data[i], 0, __ATOMIC_RELAXED);
}

yields invalid assembly when compiled with -mthumb -mcpu=cortex-m0 -O2:

t.s: Assembler messages:
t.s:35: Warning: missing operand; zero assumed
t.s:35: Error: cannot use register index with PC-relative addressing -- `str
r1,r0!'

[Bug target/115188] [14/15 regression] invalid Thumb assembly for atomic store in loop on ARMv6

2024-05-22 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

 Target||arm
   Keywords||wrong-code
   Target Milestone|--- |14.2

[Bug other/115189] New: libiberty introduces UNC paths waking up binutils bug

2024-05-22 Thread tomas.kalibera at gmail dot com via Gcc-bugs

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

Bug ID: 115189
   Summary: libiberty introduces UNC paths waking up binutils bug
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tomas.kalibera at gmail dot com
  Target Milestone: ---

With gcc 13.2 (and binutils 2.42) located on a mapped network drive on Windows,
it is not possible to build a trivial example below. It worked with gcc 12.3
(and binutils 2.40).

The problem is that a UNC path (\\host\share) is passed to the linker (ld.exe)
instead of the traditional drive letter (D:\directory) via which gcc is
invoked, and the linker cannot deal with it. Reverting

commit e2bb55ec3b70cf45088bb73ba9ca990129328d60
Author: niXman 
Date:   Sat Feb 11 06:18:10 2023 +

libiberty: fix lrealpath on Windows NTFS symlinks

gcc computes the wrong prefix if invoked through an NTFS
symlink. Try to resolve it if possible.

PR/108350

libiberty/ChangeLog:

* lrealpath.c (lrealpath): try to resolve symlink and
use UNC paths where applicable.

restores the previous behavior (and I am using it as a work-around).

My understanding is (but I've not tested) that this has been fixed in binutils:

https://sourceware.org/bugzilla/show_bug.cgi?id=29533
https://sourceware.org/bugzilla/show_bug.cgi?id=31527

However, binutils with that fix haven't been released, yet. It is not
impossible that UNC paths newly produced by gcc would confuse some other tools
coming from the Unix world (though I've not seen it happen, yet).

In principle, I would tend to think that people on Windows use mapped network
drives primarily to avoid UNC paths, as their applications may not work with
them, so, ideally one should respect that and preserve the mapped network
drives in paths. I wonder if it would be possible to defensively amend
libiberty following this principle and hence reduce the amount of bugs it wakes
up in other software.

--


# example output from a trivial example
# using Msys2 shell, gcc is on p: mapped from //tsclient/share

env PATH=/p/x86_64-w64-mingw32.static.posix/bin:$PATH g++ -o hw hw.c
P:\x86_64-w64-mingw32.static.posix\bin/ld.exe: cannot find
//tsclient/share/x86_64-w64-mingw32.static.posix/bin/../lib/gcc/x86_64-w64-mingw32.static.posix/13.2.0/../../../../lib/crt2.o:
Invalid argument
P:\x86_64-w64-mingw32.static.posix\bin/ld.exe: cannot find
//tsclient/share/x86_64-w64-mingw32.static.posix/bin/../lib/gcc/x86_64-w64-mingw32.static.posix/13.2.0/crtbegin.o:
Invalid argument
P:\x86_64-w64-mingw32.static.posix\bin/ld.exe: cannot find -lstdc++: No such
file or directory
P:\x86_64-w64-mingw32.static.posix\bin/ld.exe: cannot find -lmingw32: No such
file or directory
...

[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test

2024-05-22 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #4 from Jonathan Wakely  ---

> It's possible that all the lambda frames are inlined, or skip+2 in
> stacktrace.cc causes us to skip real frames that we should keep, or maybe
> libbacktrace just doesn't work on this target.

In the Solaris case, the libbacktrace tests all PASS on all of 32 and
64-bit SPARC and x86.

The stacktrace failures only happen on 32-bit x86; 64-bit x86 is fine.

I'm now trying a debug build and plan to compare i386 and amd64 side by
side to find differences.

[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2

2024-05-22 Thread syq at gcc dot gnu.org via Gcc-bugs

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

YunQiang Su  changed:

   What|Removed |Added

   Last reconfirmed||2024-05-22
 CC||syq at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #5 from YunQiang Su  ---
Assign it to me.

[Bug c++/115190] New: -fmodule-mapper does not accept CRLF files

2024-05-22 Thread huangqinjin at gmail dot com via Gcc-bugs

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

Bug ID: 115190
   Summary: -fmodule-mapper does not accept CRLF files
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: huangqinjin at gmail dot com
  Target Milestone: ---

In MSYS2/UCRT64 shell,install gcc (version 14.1.0),

$ printf '$root .\r\n' > a.modmap
$ g++ -std=c++20 -fmodules-ts -fmodule-mapper=a.modmap -E -o /dev/null -x c++
/dev/null
nul: error: failed reading mapper 'a.modmap'


CMake related issue: https://gitlab.kitware.com/cmake/cmake/-/issues/25974

[Bug tree-optimization/115191] New: [15 regression] ICE when building stklos (in verify_range, at value-range.cc:1526)

2024-05-22 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 115191
   Summary: [15 regression] ICE when building stklos (in
verify_range, at value-range.cc:1526)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: aldyh at gcc dot gnu.org
  Target Milestone: ---

```
$ x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.   -DPCRE2POSIX_SHARED 
-I/usr/lib64/libffi/include-O2 -c -o socket.o socket.c
during GIMPLE pass: phiopt
In file included from socket.c:34:
socket.c: In function ‘STk_socket_accept’:
stklos.h:282:18: internal compiler error: in verify_range, at
value-range.cc:1526
  282 |   SCM CPP_CONCAT(STk_, _cname) _params
  |  ^~~~
stklos.h:92:33: note: in definition of macro ‘CPP_CONCAT’
   92 | #define CPP_CONCAT(x, y)x##y
  | ^
socket.c:434:1: note: in expansion of macro ‘DEFINE_PRIMITIVE’
  434 | DEFINE_PRIMITIVE("socket-accept", socket_accept, subr12,
  | ^~~~
0x55d4f104ac8b irange::verify_range()
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/value-range.cc:1526
0x55d4f23b0da2 global_range_query::range_of_expr(vrange&, tree_node*, gimple*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/value-query.cc:436
0x55d4f21f9e12 value_replacement
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-ssa-phiopt.cc:1330
0x55d4f21fb64a execute
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-ssa-phiopt.cc:4265
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
```

```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/15/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/15/python
--enable-languages=c,c++,fortran,rust --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened
15.0. p, commit bc7d81fe2f725b4043ce8b9ffb11d80032ce3f75'
--with-gcc-major-version-only --enable-libstdcxx-time --enable-lto
--disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --disable-cet
--disable-systemtap --enable-valgrind-annotations --disable-vtable-verify
--disable-libvtv --with-zstd --with-isl --disable-isl-version-check
--enable-default-pie --enable-host-pie --enable-host-bind-now
--enable-default-ssp --disable-fixincludes --with-build-config=bootstrap-O3
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240522 (experimental)
73a167cfa225d5ee7092d41596b9fea1719898ff (Gentoo Hardened 15.0. p, commit
bc7d81fe2f725b4043ce8b9ffb11d80032ce3f75)
```

[Bug tree-optimization/115191] [15 regression] ICE when building stklos (in verify_range, at value-range.cc:1526)

2024-05-22 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Sam James  ---
Created attachment 58267
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58267&action=edit
socket.i

I'm reducing.

[Bug c++/77465] [DR909] rejected C-style cast involving casting away constness from result of conversion operator

2024-05-22 Thread egallager at gcc dot gnu.org via Gcc-bugs

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
Maybe at least special-case the -Wold-style-cast warning to say something
special about it?

[Bug tree-optimization/115191] [15 regression] ICE when building stklos (in verify_range, at value-range.cc:1526)

2024-05-22 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Sam James  ---
Just -O1 is enough.

[Bug rtl-optimization/115038] [14/15 regression] internal error in seh_cfa_offset with -O2 -fno-omit-frame-pointer

2024-05-22 Thread law at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from Jeffrey A. Law  ---
Yea, I would think we want to avoid anything marked as frame related. 
Otherwise we have to go back and fixup the CFI nodes and such.

Eric, do you want to handle the final bootstrap+regression test?  Or do you
want me to take it from here?

[Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars)

2024-05-22 Thread jukka.suomela at aalto dot fi via Gcc-bugs

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

Bug ID: 115192
   Summary: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with
vectors and scalars)
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jukka.suomela at aalto dot fi
  Target Milestone: ---

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

It seems that GCC 14.1.0 with -O3 mis-compiles the attached code on x86-64. The
key element seems to be loops that involve both arrays of vector types and
arrays of scalar types.

This is the expected output:

$ g++-14 -Wall -Wextra -O2 test.cc -o test && ./test
0.00 0.00
3.00 3.00
9.00 9.00

This is the unexpected output that we got with -O3:

$ g++-14 -Wall -Wextra -O3 test.cc -o test && ./test
0.00 0.00
3.00 3.00
6.00 6.00

I have attached the preprocessed source code produced by the following command,
and I will attach also the full compiler output that I got:

g++-14 -v -save-temps -Wall -Wextra -O3 test.cc -o test

Compiler: GNU C++17 (Homebrew GCC 14.1.0) version 14.1.0
(x86_64-apple-darwin21), compiled by GNU C version 14.1.0, GMP version 6.3.0,
MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP, Target:
x86_64-apple-darwin21.6.0.

This is GCC on Intel-macOS from Homebrew, but we originally noticed the problem
in Intel-Linux, so it doesn't seem to be specific to macOS or Homebrew.
However, I wasn't able to reproduce the bug on Apple M3, so it might be
specific to x86-64.

[Bug c++/115192] GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars)

2024-05-22 Thread jukka.suomela at aalto dot fi via Gcc-bugs

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

--- Comment #1 from Jukka Suomela  ---
Created attachment 58269
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58269&action=edit
Compiler output

[Bug c++/57025] Solaris g++ defines __STDC_VERSION__=199901L

2024-05-22 Thread alan.coopersmith at oracle dot com via Gcc-bugs

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

Alan Coopersmith  changed:

   What|Removed |Added

 CC||alan.coopersmith at oracle dot 
com

--- Comment #11 from Alan Coopersmith  ---
While Solaris 11.3 support has been dropped from gcc now, Jonathan Perkins
from pkgsrc found that just removing the definition of __STDC_VERSION__
didn't work with some of the illumos headers:
https://github.com/jperkin/notes/blob/main/gcc-cpp-stdc/README.md

[Bug tree-optimization/115191] [15 regression] ICE when building stklos (in verify_range, at value-range.cc:1526)

2024-05-22 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Sam James  ---
```
typedef void *SCM;
void set_socket_io_ports();
void STk_socket_accept(SCM line_buffered) {
  if (!line_buffered)
line_buffered = (SCM)3;
  set_socket_io_ports(line_buffered != 1);
}
```

[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314

2024-05-22 Thread natalie.perlin at noaa dot gov via Gcc-bugs

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

--- Comment #12 from Natalie Perlin  ---
Jakub Jelinek - thanks for your note. At this point we may not do anything
during the build, as these packages are retrieved from official spack
repository. And yes, they may often carry a lot of legacy code...

[Bug c++/57025] Solaris g++ defines __STDC_VERSION__=199901L

2024-05-22 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs

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

--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #11 from Alan Coopersmith  ---
> While Solaris 11.3 support has been dropped from gcc now, Jonathan Perkins
> from pkgsrc found that just removing the definition of __STDC_VERSION__
> didn't work with some of the illumos headers:
> https://github.com/jperkin/notes/blob/main/gcc-cpp-stdc/README.md

Unfortunately, the Illumos guys have refused to cooperate with upstream
GCC and LLVM for years, never tried to upstream patches, perform
testing, report results or anything.  Unless they suddenly start
testing, analysis, and provide patches, I'm not willing to do their work
for them.  I simply don't have the time.

[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314

2024-05-22 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #13 from Jakub Jelinek  ---
So provide fixes upstream and hope they apply them soon.

[Bug c++/115192] [14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars)

2024-05-22 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Sam James  ---
Created attachment 58270
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58270&action=edit
bisect-me.cxx

I'll bisect with attached.

[Bug c++/115192] [14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r14-2117

2024-05-22 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-05-22
   Target Milestone|--- |14.2
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
Summary|[14/15 regression] -O3  |[14/15 regression] -O3
   |miscompilation on x86-64|miscompilation on x86-64
   |(loops with vectors and |(loops with vectors and
   |scalars)|scalars) since r14-2117

--- Comment #3 from Jakub Jelinek  ---
Since r14-2117-gdd86a5a69cbda40cf76388a65d3317c91cb2b501

[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5

2024-05-22 Thread ibuclaw at gcc dot gnu.org via Gcc-bugs

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

--- Comment #16 from Iain Buclaw  ---
(In reply to Richard Biener from comment #15)
> Note the opover.d compile doesn't even use -O3, so this is all extremely
> odd.  It would somehow point at a miscompile of the stage2 compiler by
> the stage1 compiler manifesting itself only in this change ...
> 
> So the logical next step would be to bisect stage1/stage2 object files
> of d21 and see which stage2 object is miscompiled.
After removing `--enable-multilib` I've managed to replicate this too.

Confirmed that GDCFLAGS ignores whatever's in
`--with-build-config=bootstrap-O3` when compared next to 


Stage1 (`-g -O2` vs `-g`)
```
gdc -c  -g -O2 -fversion=IN_GCC  -fno-PIE  -fno-exceptions
-fasynchronous-unwind-tables  -Wall -Wdeprecated -fno-common -o d/opover.o -MT
d/opover.o -MMD -MP -MF d/.deps/opover.TPo -I../../gcc/d -J../../gcc/d/dmd
-J../../gcc/d/dmd/res ../../gcc/d/dmd/opover.d

g++ -std=c++11  -fno-PIE -c  -DIN_GCC_FRONTEND -g -DIN_GCC-fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -fno-PIE -I. -Id
-I../../gcc -I../../gcc/d -I../../gcc/../include  -I../../gcc/../libcpp/include
-I../../gcc/../libcody  -I../../gcc/../libdecnumber
-I../../gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace  
-o d/d-attribs.o -MT d/d-attribs.o -MMD -MP -MF d/.deps/d-attribs.TPo
../../gcc/d/d-attribs.cc
```

Stage2 (`-O2 -g` vs `-O3 -g -fno-checking`)
```
/repos/gcc/build.O3/./prev-gcc/gdc -B/repos/gcc/build.O3/./prev-gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -O2 -g
-B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libphobos/libdruntime/gcc
-B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libphobos/src
-B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libphobos/src/.libs
-I/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libphobos/libdruntime
-I/repos/gcc/libphobos/libdruntime
-L/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libphobos/src/.libs
-B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -c  -g
-O2 -fversion=IN_GCC  -fno-PIE  -fno-exceptions -fasynchronous-unwind-tables 
-Wall -Wdeprecated -fno-common -o d/opover.o -MT d/opover.o -MMD -MP -MF
d/.deps/opover.TPo -I../../gcc/d -J../../gcc/d/dmd -J../../gcc/d/dmd/res
../../gcc/d/dmd/opover.d

/repos/gcc/build.O3/./prev-gcc/xg++ -B/repos/gcc/build.O3/./prev-gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
 -I/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/include 
-I/repos/gcc/libstdc++-v3/libsupc++
-L/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs 
-fno-PIE -c  -DIN_GCC_FRONTEND -O3 -g -fno-checking -DIN_GCC-fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -fno-PIE -I. -Id
-I../../gcc -I../../gcc/d -I../../gcc/../include  -I../../gcc/../libcpp/include
-I../../gcc/../libcody  -I../../gcc/../libdecnumber
-I../../gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace  
-o d/d-attribs.o -MT d/d-attribs.o -MMD -MP -MF d/.deps/d-attribs.TPo
../../gcc/d/d-attribs.cc
```

Stage3: (`-O2 -g` vs `-O3 -g -fchecking=1`)
```
/repos/gcc/build.O3/./prev-gcc/gdc -B/repos/gcc/build.O3/./prev-gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -O2 -g
-B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libphobos/libdruntime/gcc
-B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libphobos/src
-B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libphobos/src/.libs
-I/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libphobos/libdruntime
-I/repos/gcc/libphobos/libdruntime
-L/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libphobos/src/.libs
-B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -c  -g
-O2 -fversion=IN_GCC  -fno-PIE  -fno-exceptions -fasynchronous-unwind-tables 
-Wall -Wdeprecated -fno-common -o d/opover.o -MT d/opover.o -MMD -MP -MF
d/.deps/opover.TPo -I../../gcc/d -J../../gcc/d/dmd -J../../gcc/d/dmd/res
../../gcc/d/dmd/opover.d

/repos/gcc/build.O3/./prev-gcc/xg++ -B/repos/gcc/build.O3/./prev-gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3

[Bug c++/107500] [12 Regression] Useless atexit entry for ~constant_init in eh_globals.cc

2024-05-22 Thread redi at gcc dot gnu.org via Gcc-bugs

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #29 from Jonathan Wakely  ---
Fixed for 12.4 and up.

[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5

2024-05-22 Thread iains at gcc dot gnu.org via Gcc-bugs

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

--- Comment #17 from Iain Sandoe  ---
however, the opover.o mismatch is a symptom - rather than the cause.

If all the objects for the D FE are built by D, then that would tend to point
to miscompilation of something in common code (that is built with C++ and
therefore can be affected by O3).

[Bug rtl-optimization/115038] [14/15 regression] internal error in seh_cfa_offset with -O2 -fno-omit-frame-pointer

2024-05-22 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs

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

--- Comment #9 from Eric Botcazou  ---
> Eric, do you want to handle the final bootstrap+regression test?  Or do you
> want me to take it from here?

I can do it right now.

[Bug rtl-optimization/115038] [14/15 regression] internal error in seh_cfa_offset with -O2 -fno-omit-frame-pointer

2024-05-22 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Eric Botcazou :

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

commit r15-776-gf14ef5cfd4c1ba1d34afda9174935e40d3c0a3ce
Author: Eric Botcazou 
Date:   Wed May 22 18:10:39 2024 +0200

Fix internal error in seh_cfa_offset with -O2 -fno-omit-frame-pointer

The problem directly comes from the -ffold-mem-offsets pass messing up with
the prologue and the frame-related instructions, which is a no-no with SEH,
so the fix simply disconnects the pass in these circumstances.

gcc/
PR rtl-optimization/115038
* fold-mem-offsets.cc (fold_offsets): Return 0 if the defining
instruction of the register is frame related.

gcc/testsuite/
* g++.dg/opt/fmo1.C: New test.

[Bug c++/115190] -fmodule-mapper does not accept CRLF files

2024-05-22 Thread bugzilla.gcc at me dot benboeckel.net via Gcc-bugs

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

--- Comment #1 from Ben Boeckel  ---
My analysis points to the change needing to happen in
1module_resolver::read_tuple_file` in `c++tools/resolver.cc`.

[Bug c++/115192] [14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r14-2117

2024-05-22 Thread jukka.suomela at aalto dot fi via Gcc-bugs

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

--- Comment #4 from Jukka Suomela  ---
Created attachment 58271
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58271&action=edit
Another example, miscompiles with GCC 11 (-O3 -march=skylake)

Here is a minor variant of the theme. This variant seems to fail already on GCC
11 if I compile with -O3 -march=skylake.

Expected:

$ g++-11 -Wall -Wextra test.cc -O2 -march=skylake -o test && ./test
0.00 0.00
11.00 22.00
22.00 44.00

Unexpected:

$ g++-11 -Wall -Wextra test.cc -O3 -march=skylake -o test && ./test
0.00 0.00
11.00 22.00
11.00 22.00

This was with g++-11 (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 on x86_64-linux-gnu.
In godbolt.org GCC 11.1 seemed to be the first version where this behavior
started.

(Apologies if this should be a separate bug report. I posted this here, as I
suspect the bugs might be related.)

[Bug c++/115190] -fmodule-mapper does not accept CRLF files

2024-05-22 Thread peter0x44 at disroot dot org via Gcc-bugs

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

Peter Damianov  changed:

   What|Removed |Added

 CC||peter0x44 at disroot dot org

--- Comment #2 from Peter Damianov  ---
I could only reproduce this on MSYS2's gcc packages. On w64devkit, I couldn't
reproduce it. Nor with a gcc 15 I built myself.

I suspect perhaps it has something to do with whether gcc uses mmap or not? But
I'm not certain of this.

[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314

2024-05-22 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

--- Comment #14 from anlauf at gcc dot gnu.org ---
(In reply to Natalie Perlin from comment #9)
>  All rebuilt, gnu/14.1.0 with openmpi/4.1.6, revised configuration of the
> software stack (spack-stack). Still the same error with
> [-Wimplicit-function-declaration]. 
> 
> Verified a build of the same stack with gnu/13.2.0 and openmpi/4.1.6. The
> same location in the code gives warning, instead of the error, during the
> build. Same package, different version of gcc. Please see below snippets of
> the builds:
> 
> 1. Build with gnu/13.2.0 gives the following: 
> ---
> ...
>  /scratch2/NCEPDEV/stmp1/role.epic/spack-stack/spack-stack-1.6.0/spack/lib/
> spack/env/gcc/gcc -DHAVE_CONFIG_H -I. -I.
> -I../../../src/libjasper/include/jasper -I../../../src/libjasper/include -g
> -O2 -MT jas_getopt.lo -MD -MP -MF .deps/jas_getopt.Tpo -c jas_getopt.c -o
> jas_getopt.o
> jas_getopt.c: In function 'jas_getopt':
> jas_getopt.c:129:49: warning: implicit declaration of function
> 'jas_eprintf'; did you mean 'vsnprintf'? [-Wimplicit-function-declaration]
>   129 | jas_eprintf("unknown
> long option %s\n", s);
>   | ^~~
>   | vsnprintf
> ...
> ---
> 
> 2. Build with gnu/14.1.0 gives the following:
> ---
> ...
>  /scratch2/NCEPDEV/stmp1/role.epic/spack-stack/spack-stack-1.6.0_gnu14/spack/
> lib/spack/env/gcc/gcc -DHAVE_CONFIG_H -I. -I.
> -I../../../src/libjasper/include/jasper -I../../../src/libjasper/include -g
> -O2 -MT jas_getopt.lo -MD -MP -MF .deps/jas_getopt.Tpo -c jas_getopt.c -o
> jas_getopt.o
> jas_getopt.c: In function 'jas_getopt':
> jas_getopt.c:129:49: error: implicit declaration of function 'jas_eprintf';
> did you mean 'vsnprintf'? [-Wimplicit-function-declaration]
>   129 | jas_eprintf("unknown
> long option %s\n", s);
>   | ^~~
>   | vsnprintf
> make[4]: *** [Makefile:349: jas_getopt.lo] Error 1
> ...
> ---
> 
> Any suggestions?..

The original jasper files look fine to me:

https://github.com/jasper-software/jasper/blob/master/src/libjasper/base/jas_getopt.c

which includes

https://github.com/jasper-software/jasper/blob/master/src/libjasper/include/jasper/jas_debug.h

Looks like spack either does not generate proper include paths, or a
bad include file is found.

> Has a version of gnu/13.3.0 become available that might have the ICE fix?..

See https://gcc.gnu.org/gcc-13/ .

[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5

2024-05-22 Thread ibuclaw at gcc dot gnu.org via Gcc-bugs

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

--- Comment #18 from Iain Buclaw  ---
Reduction of opover.d
```
bool __setArrayAllocLength(size_t newLength)
{
import core.checkedint;
bool overflow;
addu(newLength,
 addu(0, 0, overflow),
 overflow);

return true;
}

enum EXP
{
greaterOrEqual,
greaterThan,
lessOrEqual,
lessThan,
}

EXP reverseRelation(EXP op)
{
switch (op)
{
case EXP.greaterOrEqual:  op = EXP.lessOrEqual;break;
case EXP.greaterThan: op = EXP.lessThan;   break;
case EXP.lessOrEqual: op = EXP.greaterOrEqual; break;
default:  break;
}
return op;
}
```


Running (from the build directory)
```
./stage1-gcc/gdc -B ./stage1-gcc/ -c -O2 -g -fversion=IN_GCC \
   -I ./stage1-x86_64-pc-linux-gnu/libphobos/libdruntime \
   -I ../../libphobos/libdruntime -I ../../gcc/d/ \
   -J ../../gcc/d/dmd -J ../../gcc/d/dmd/res opover.d -o opover-1.o

../stage2-gcc/gdc -B ../stage2-gcc/ -c -O2 -g -fversion=IN_GCC \
   -I ../stage2-x86_64-pc-linux-gnu/libphobos/libdruntime \
   -I ../../libphobos/libdruntime -I ../../gcc/d/ \
   -J ../../gcc/d/dmd -J ../../gcc/d/dmd/res opover.d -o opover-2.o

cmp --ignore-initial=16 opover-1.o opover-2.o
```


Also observed from assembly output
```
--- opover-1.s  2024-05-22 19:10:36.315939819 +0200
+++ opover-2.s  2024-05-22 19:10:28.763819758 +0200
@@ -29,7 +29,7 @@ _D6opover15reverseRelationFEQBa3EXPZQj:
movl%edi, %eax
cmpl$2, %eax
ja  .L5
-   leaqCSWTCH.8(%rip), %rdx
+   leaqCSWTCH.9(%rip), %rdx
movl(%rdx,%rax,4), %eax
 .L5:
 .LVL2:
@@ -123,9 +123,9 @@ gdc.dso_dtor:
.quad   gdc.dso_dtor
.section.rodata
.align 8
-   .type   CSWTCH.8, @object
-   .size   CSWTCH.8, 12
-CSWTCH.8:
+   .type   CSWTCH.9, @object
+   .size   CSWTCH.9, 12
+CSWTCH.9:
.long   2
.long   3
.long   0
```

[Bug c++/115192] [14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r14-2117

2024-05-22 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
The #c4 testcase changed behavior with
r11-6380-g9fa5b473b5b8e289b6542adfd5cfaddfb3036048

[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.

2024-05-22 Thread kargls at comcast dot net via Gcc-bugs

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

--- Comment #7 from kargls at comcast dot net ---
Bummer.  Seems I lost my WIP on this bug.

'import, none' would be handy for block host association in contained
subprograms in my current development.

[Bug fortran/115193] New: using indices with character type within a select type causes ICE

2024-05-22 Thread ryan.mulhall at noaa dot gov via Gcc-bugs

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

Bug ID: 115193
   Summary: using indices with character type within a select type
causes ICE
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.mulhall at noaa dot gov
CC: thomas.robinson at noaa dot gov, unassigned at gcc dot 
gnu.org
  Target Milestone: ---

This bug seems to be a regression from past versions, gfortran 10-13 worked
without error.

Bug #100860 describes a similar issue, but gfortran 14.1.0 generates an ICE
while the original issue had a seg fault.

I believe the error is coming from the usage of indices to get a substring from
a class(*) type.

I've simplified the test program from the original report to be more compact:


program test

  implicit none

  character (len=:), allocatable :: str

  str = "examplestring"
  call foo(str,13)

  contains

  subroutine foo(bar, strlen)
class(*), intent (in)  :: bar
integer,  intent (in)  :: strlen

select type (bar)
type is (character(*))
  print *, 'String is "', bar(1:strlen), '"' ! fails here 
class default
  print *, "Not the right type"
end select
  end subroutine

end program test

[Bug fortran/115193] using indices with character type within a select type causes ICE

2024-05-22 Thread ryan.mulhall at noaa dot gov via Gcc-bugs

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

--- Comment #1 from Ryan Mulhall  ---
Error output:


test2.F90:18:43:

   18 |   print *, 'String is "', bar(1:strlen), '"' ! fails here
  |   1
internal compiler error: Segmentation fault
0xe5329f crash_signal
../.././gcc/toplev.cc:319
0x8ced67 gfc_conv_scalarized_array_ref
../.././gcc/fortran/trans-array.cc:3938
0x8cfc46 gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*)
../.././gcc/fortran/trans-array.cc:4094
0x90a946 gfc_conv_variable
../.././gcc/fortran/trans-expr.cc:3189
0x90d6c2 gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../.././gcc/fortran/trans-expr.cc:9943
0x9336f2 gfc_trans_transfer(gfc_code*)
../.././gcc/fortran/trans-io.cc:2609
0x8c48c7 trans_code
../.././gcc/fortran/trans.cc:2583
0x9312d9 build_dt
../.././gcc/fortran/trans-io.cc:2053
0x8c4827 trans_code
../.././gcc/fortran/trans.cc:2555
0x950234 gfc_trans_block_construct(gfc_code*)
../.././gcc/fortran/trans-stmt.cc:2377
0x8c4aa7 trans_code
../.././gcc/fortran/trans.cc:2459
0x9472dc gfc_trans_select_type_cases
../.././gcc/fortran/trans-stmt.cc:3020
0x9519a9 gfc_trans_select_type(gfc_code*)
../.././gcc/fortran/trans-stmt.cc:3729
0x8c4a07 trans_code
../.././gcc/fortran/trans.cc:2479
0x950234 gfc_trans_block_construct(gfc_code*)
../.././gcc/fortran/trans-stmt.cc:2377
0x8c4aa7 trans_code
../.././gcc/fortran/trans.cc:2459
0x8f4b24 gfc_generate_function_code(gfc_namespace*)
../.././gcc/fortran/trans-decl.cc:7880
0x8f4914 gfc_generate_contained_functions
../.././gcc/fortran/trans-decl.cc:5995
0x8f4914 gfc_generate_function_code(gfc_namespace*)
../.././gcc/fortran/trans-decl.cc:7812
0x866986 translate_all_program_units
../.././gcc/fortran/parse.cc:7099
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++/115192] [11/12/13/14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380

2024-05-22 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

Summary|[14/15 regression] -O3  |[11/12/13/14/15 regression]
   |miscompilation on x86-64|-O3 miscompilation on
   |(loops with vectors and |x86-64 (loops with vectors
   |scalars) since r14-2117 |and scalars) since r11-6380

--- Comment #6 from Sam James  ---
Retitling then so it doesn't get lost. Can always split if needed.

[Bug c++/115194] New: [modules] "reference to is ambiguous" when multiple paths to same symbol exist through module

2024-05-22 Thread nickbegg at gmail dot com via Gcc-bugs

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

Bug ID: 115194
   Summary: [modules] "reference to  is ambiguous" when
multiple paths to same symbol exist through module
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nickbegg at gmail dot com
  Target Milestone: ---

This code example was reduced from Boost's multi_index_container.

When referencing symbols via modules and using statements, gcc gets tripped up
with different routes to the same symbol. 

When #including clean.hpp directly into main.cpp, this compiles ok.:

/// clean.hpp :

namespace NS1 { namespace NS2 {
class Thing {};
} // NS2
using NS2::Thing;
} // NS1

/// modA.mpp:
module;

#include "clean.hpp"

export module modA;

export namespace NS1 {
using ::NS1::Thing;
namespace NS2 {
} }

/// main.cpp:

#if 0
#include "clean.hpp"
#else
import modA;
#endif

using NS1::Thing;
using namespace NS1::NS2;
Thing thing;

///

Tested with gcc trunk / 15.0.0 20240522 (revid
1a5e4dd83788ea4c049d354d83ad58a6a3d747e6)

/home/nick/inst/gcc-trunk-debug/bin/g++   -fdiagnostics-color=always -g
-std=gnu++23 -MD -MT CMakeFiles/moduleMin.dir/main.cpp.o -MF
CMakeFiles/moduleMin.dir/main.cpp.o.d -fmodules-ts
-fmodule-mapper=CMakeFiles/moduleMin.dir/main.cpp.o.modmap -MD
-fdeps-format=p1689r5 -x c++ -o CMakeFiles/moduleMin.dir/main.cpp.o -c
/home/nick/src/moduleMin/main.cpp
/home/nick/src/moduleMin/main.cpp:9:1: error: reference to ‘Thing’ is ambiguous
9 | Thing thing;
  | ^
In file included from /home/nick/src/moduleMin/modA.mpp:3,
of module modA, imported at /home/nick/src/moduleMin/main.cpp:4:
/home/nick/src/moduleMin/clean.hpp:5:7: note: candidates are: ‘class
NS1::NS2::Thing@modA’
5 | class Thing {};
  |   ^
/home/nick/src/moduleMin/clean.hpp:5:7: note: ‘class
NS1::NS2::Thing@modA’

[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5

2024-05-22 Thread ibuclaw at gcc dot gnu.org via Gcc-bugs

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

--- Comment #19 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #18)
> Reduction of opover.d
> ```
> bool __setArrayAllocLength(size_t newLength)
> {
> import core.checkedint;
> bool overflow;
> addu(newLength,
>  addu(0, 0, overflow),
>  overflow);
> 

This is likely not translatable into C/C++. The D FE emits ADD_OVERFLOW()
directly, and swapping this with __builtin_uaddll_overflow is not equivalent -
pulling out the second `addu` to its own local variable means the comparison
failure is not triggered.

[Bug fortran/115193] using indices with character type within a select type causes ICE

2024-05-22 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED
   Keywords|wrong-code  |ice-on-valid-code

--- Comment #2 from anlauf at gcc dot gnu.org ---
This bug has already been reported as pr114874 and just been fixed last week.

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

1 2 >

1 - 100 of 184 matches

Mail list logo