[Bug d/110516] core.volatile.volatileLoad discarded if result is unused

[witold.baryluk+gcc at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Witold Baryluk  ---
Thank you for a quick fix Iain!

[Bug d/110516] core.volatile.volatileLoad discarded if result is unused

[witold.baryluk+gcc at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Witold Baryluk  ---
I see.

Point 1 is definitively incorrect. I interpreted asembler wrong:

void example.actualRun(ubyte*):
pushrbp
mov rbp, rsp
mov QWORD PTR [rbp-8], rdi
nop
pop rbp
ret


The move there, is just some stack manipulation, it has nothing to do with
volatileLoad.



You are right about the side effect visibility and volatileStore.

Still, there should be a way to express real memory read, with result not
stored anywhere in program (just written to register, then discarded).

This has some (not very common) uses in memmory-mapped IO, i.e. in drivers for
devices where the read itself could indicate something (this of course usually
also require setting proper page table attributes to disable caching or other
optimizations, etc, not just volatile load in machine code). I do not have
specific examples at hand, but afaik I saw some examples in the past (mostly on
older architectures), as well some watchdog chips that reset timer on read.

Another use is for doing memory and cache read benchmarks and profiling. We
want to invoke read (to register) from some memory location, but we do not need
the value for anything else.

And more esoteric use might be memory probing. On some level systems, kernel or
bootloader, might not know the memory layout, and resort to just doing reads,
and relaying on CPU fault handlers to report invalid reads.

And some people might use load without destination, as a prefetch hint, or to
prefault some memory pages.

[Bug d/110516] core.volatile.volatileLoad discarded if result is unused

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

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

ibuclaw at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from ibuclaw at gcc dot gnu.org ---
Fix committed and backported.

[Bug d/110516] core.volatile.volatileLoad discarded if result is unused

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Iain Buclaw
:

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

commit r11-10890-gda7a10ea9245d7461253495698873891ffc20666
Author: Iain Buclaw 
Date:   Sun Jul 2 03:24:53 2023 +0200

d: Fix core.volatile.volatileLoad discarded if result is unused

The first pass of code generation in the D front-end splits up all
compound expressions and discards expressions that have no side effects.
This included calls to the `volatileLoad' intrinsic if its result was
not used, causing such calls to be eliminated from the program.

We already set TREE_THIS_VOLATILE on the expression, however the
tree documentation says if this bit is set in an expression, so is
TREE_SIDE_EFFECTS.  So set TREE_SIDE_EFFECTS on the expression too.
This prevents any early discarding from occuring.

PR d/110516

gcc/d/ChangeLog:

* intrinsics.cc (expand_volatile_load): Set TREE_SIDE_EFFECTS on
the
expanded expression.
(expand_volatile_store): Likewise.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/pr110516a.d: New test.
* gdc.dg/torture/pr110516b.d: New test.

(cherry picked from commit 80ae426a195a0d035640a6301da833564deade52)

[Bug d/110516] core.volatile.volatileLoad discarded if result is unused

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Iain Buclaw
:

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

commit r12-9749-gb224692084e40aabcba1e73166eedf55dfd7f563
Author: Iain Buclaw 
Date:   Sun Jul 2 03:24:53 2023 +0200

d: Fix core.volatile.volatileLoad discarded if result is unused

The first pass of code generation in the D front-end splits up all
compound expressions and discards expressions that have no side effects.
This included calls to the `volatileLoad' intrinsic if its result was
not used, causing such calls to be eliminated from the program.

We already set TREE_THIS_VOLATILE on the expression, however the
tree documentation says if this bit is set in an expression, so is
TREE_SIDE_EFFECTS.  So set TREE_SIDE_EFFECTS on the expression too.
This prevents any early discarding from occuring.

PR d/110516

gcc/d/ChangeLog:

* intrinsics.cc (expand_volatile_load): Set TREE_SIDE_EFFECTS on
the
expanded expression.
(expand_volatile_store): Likewise.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/pr110516a.d: New test.
* gdc.dg/torture/pr110516b.d: New test.

(cherry picked from commit 80ae426a195a0d035640a6301da833564deade52)

[Bug d/110516] core.volatile.volatileLoad discarded if result is unused

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:78e9bd776d559b4a2193d61dd074ee0880d43ec5

commit r13-7521-g78e9bd776d559b4a2193d61dd074ee0880d43ec5
Author: Iain Buclaw 
Date:   Sun Jul 2 03:24:53 2023 +0200

d: Fix core.volatile.volatileLoad discarded if result is unused

The first pass of code generation in the D front-end splits up all
compound expressions and discards expressions that have no side effects.
This included calls to the `volatileLoad' intrinsic if its result was
not used, causing such calls to be eliminated from the program.

We already set TREE_THIS_VOLATILE on the expression, however the
tree documentation says if this bit is set in an expression, so is
TREE_SIDE_EFFECTS.  So set TREE_SIDE_EFFECTS on the expression too.
This prevents any early discarding from occuring.

PR d/110516

gcc/d/ChangeLog:

* intrinsics.cc (expand_volatile_load): Set TREE_SIDE_EFFECTS on
the
expanded expression.
(expand_volatile_store): Likewise.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/pr110516a.d: New test.
* gdc.dg/torture/pr110516b.d: New test.

(cherry picked from commit 80ae426a195a0d035640a6301da833564deade52)

[Bug d/110516] core.volatile.volatileLoad discarded if result is unused

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

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

commit r14-2236-g80ae426a195a0d035640a6301da833564deade52
Author: Iain Buclaw 
Date:   Sun Jul 2 03:24:53 2023 +0200

d: Fix core.volatile.volatileLoad discarded if result is unused

The first pass of code generation in the D front-end splits up all
compound expressions and discards expressions that have no side effects.
This included calls to the `volatileLoad' intrinsic if its result was
not used, causing such calls to be eliminated from the program.

We already set TREE_THIS_VOLATILE on the expression, however the
tree documentation says if this bit is set in an expression, so is
TREE_SIDE_EFFECTS.  So set TREE_SIDE_EFFECTS on the expression too.
This prevents any early discarding from occuring.

PR d/110516

gcc/d/ChangeLog:

* intrinsics.cc (expand_volatile_load): Set TREE_SIDE_EFFECTS on
the
expanded expression.
(expand_volatile_store): Likewise.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/pr110516a.d: New test.
* gdc.dg/torture/pr110516b.d: New test.

[Bug d/110516] core.volatile.volatileLoad is broken

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

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

--- Comment #2 from ibuclaw at gcc dot gnu.org ---
(In reply to Witold Baryluk from comment #0)
> I did not test volatileStore, but I would not be surprised it is also broken.
volatileStore is fine, because that expands to an assignment, which is assumed
to have a side effect.

[Bug c++/51066] [C++0x] warning about binding an rvalue-reference to an implicit conversion result

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

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

--- Comment #5 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #3)
> This warning would also help with this horror:
> https://twitter.com/zygoloid/status/1367301323838812160

(In reply to Jonathan Wakely from comment #4)
> And this one https://twitter.com/wakomeup/status/1274778577087627267

Archive links for these: 

http://web.archive.org/web/20220327011407/https://twitter.com/zygoloid/status/1367301323838812160
http://web.archive.org/web/20200621190630/https://twitter.com/wakomeup/status/1274778577087627267

[Bug tree-optimization/109945] Escape analysis hates copy elision: different result with -O1 vs -O2

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

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

--- Comment #20 from Andrew Pinski  ---
Isn't this just a dup of bug 84414 ?

[Bug middle-end/110515] [12/13/14 Regression] llvm-15.0.7 possibly invalid code on -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||alias

--- Comment #5 from Andrew Pinski  ---
I am not 100% sure but I think the problem is related to this code (note I
added that asm comment there):
```
V *P = u.i;
V *E = P + InlineSlots;
for (; P != E; ++P) {
if (P->v != EmptyKey) {
TmpEnd->v = P->v;
++TmpEnd;
}
}

Small = false;
//asm("":"+m"(*this)::"memory");
u.o = LargeRep{new V[128], 128};
```

The problem is most likely the read from u.i is happening after the store to
u.o.

[Bug d/110514] d: accesses of immutable arrays using constant index still bounds checked

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

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

ibuclaw at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from ibuclaw at gcc dot gnu.org ---
Fix committed and backported.

[Bug d/110514] d: accesses of immutable arrays using constant index still bounds checked

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

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

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

https://gcc.gnu.org/g:750526ee180ae2af66ee07db95c9787e8d86ed4b

commit r12-9747-g750526ee180ae2af66ee07db95c9787e8d86ed4b
Author: Iain Buclaw 
Date:   Sat Jul 1 23:32:53 2023 +0200

d: Fix accesses of immutable arrays using constant index still bounds
checked

Starts setting TREE_READONLY against specific kinds of VAR_DECLs, so
that the middle-end/optimization passes can more aggressively constant
fold D code that makes use of `immutable' or `const'.

PR d/110514

gcc/d/ChangeLog:

* decl.cc (get_symbol_decl): Set TREE_READONLY on certain kinds of
const and immutable variables.
* expr.cc (ExprVisitor::visit (ArrayLiteralExp *)): Set
TREE_READONLY
on immutable dynamic array literals.

gcc/testsuite/ChangeLog:

* gdc.dg/pr110514a.d: New test.
* gdc.dg/pr110514b.d: New test.
* gdc.dg/pr110514c.d: New test.
* gdc.dg/pr110514d.d: New test.

(cherry picked from commit 61b1c562f8c703bff045e91257120e42b7fae523)

[Bug d/110514] d: accesses of immutable arrays using constant index still bounds checked

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

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:3f43c19d0d40b82ecfd10f277322c1f786bcd76d

commit r13-7519-g3f43c19d0d40b82ecfd10f277322c1f786bcd76d
Author: Iain Buclaw 
Date:   Sat Jul 1 23:32:53 2023 +0200

d: Fix accesses of immutable arrays using constant index still bounds
checked

Starts setting TREE_READONLY against specific kinds of VAR_DECLs, so
that the middle-end/optimization passes can more aggressively constant
fold D code that makes use of `immutable' or `const'.

PR d/110514

gcc/d/ChangeLog:

* decl.cc (get_symbol_decl): Set TREE_READONLY on certain kinds of
const and immutable variables.
* expr.cc (ExprVisitor::visit (ArrayLiteralExp *)): Set
TREE_READONLY
on immutable dynamic array literals.

gcc/testsuite/ChangeLog:

* gdc.dg/pr110514a.d: New test.
* gdc.dg/pr110514b.d: New test.
* gdc.dg/pr110514c.d: New test.
* gdc.dg/pr110514d.d: New test.

(cherry picked from commit 61b1c562f8c703bff045e91257120e42b7fae523)

[Bug d/110514] d: accesses of immutable arrays using constant index still bounds checked

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:61b1c562f8c703bff045e91257120e42b7fae523

commit r14-2234-g61b1c562f8c703bff045e91257120e42b7fae523
Author: Iain Buclaw 
Date:   Sat Jul 1 23:32:53 2023 +0200

d: Fix accesses of immutable arrays using constant index still bounds
checked

Starts setting TREE_READONLY against specific kinds of VAR_DECLs, so
that the middle-end/optimization passes can more aggressively constant
fold D code that makes use of `immutable' or `const'.

PR d/110514

gcc/d/ChangeLog:

* decl.cc (get_symbol_decl): Set TREE_READONLY on certain kinds of
const and immutable variables.
* expr.cc (ExprVisitor::visit (ArrayLiteralExp *)): Set
TREE_READONLY
on immutable dynamic array literals.

gcc/testsuite/ChangeLog:

* gdc.dg/pr110514a.d: New test.
* gdc.dg/pr110514b.d: New test.
* gdc.dg/pr110514c.d: New test.
* gdc.dg/pr110514d.d: New test.

[Bug d/110516] core.volatile.volatileLoad is broken

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

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

ibuclaw at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ibuclaw at gcc dot gnu.org

--- Comment #1 from ibuclaw at gcc dot gnu.org ---
(In reply to Witold Baryluk from comment #0)
> gcc 12.2.0 (from Debian stable) and gcc trunk 14.0.0 (in godbolt) tested.
> 
> core.volatile.volatileLoad simply does not work.
> 
> 1) It merges loads.
> 2) It removes unused loads at -O1 and higher.
> 
> Example:
> 
> void actualRun(ubyte* ptr1) {
>   import core.volatile : volatileLoad;
>   volatileLoad(ptr1);
>   volatileLoad(ptr1);
>   volatileLoad(ptr1);
>   volatileLoad(ptr1);
> }
Actually, doesn't seem to be doing either 1 or 2, it looks like the statement
is just dropped altogether as no obvious side-effect was picked up from the
expression to which the intrinsic was expanded into.

https://d.godbolt.org/z/361x4vKfn

[Bug d/110516] New: core.volatile.volatileLoad is broken

[witold.baryluk+gcc at gmail dot com via Gcc-bugs]

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

Bug ID: 110516
   Summary: core.volatile.volatileLoad is broken
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: witold.baryluk+gcc at gmail dot com
  Target Milestone: ---

gcc 12.2.0 (from Debian stable) and gcc trunk 14.0.0 (in godbolt) tested.

core.volatile.volatileLoad simply does not work.

1) It merges loads.
2) It removes unused loads at -O1 and higher.

Example:

void actualRun(ubyte* ptr1) {
  import core.volatile : volatileLoad;
  volatileLoad(ptr1);
  volatileLoad(ptr1);
  volatileLoad(ptr1);
  volatileLoad(ptr1);
}


Without optimisations:

void example.actualRun(ubyte*):
pushrbp
mov rbp, rsp
mov QWORD PTR [rbp-8], rdi
nop
pop rbp
ret


Incorrect.



With optimisations:

void example.actualRun(ubyte*):
ret

Incorrect.


Expected:

void example.actualRun(ubyte*):
movzx   eax, byte ptr [rdi]
movzx   eax, byte ptr [rdi]
movzx   eax, byte ptr [rdi]
movzx   eax, byte ptr [rdi]
ret



dmd and ldc behave properly.


It looks like it never worked properly.

Would be good to have a test case for this, so it does not become a regression
later.


I did not test volatileStore, but I would not be surprised it is also broken.

[Bug middle-end/110515] [12/13/14 Regression] llvm-15.0.7 possibly invalid code on -O3

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

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

--- Comment #4 from Andrew Pinski  ---
Right away I can say it is not phiopt that is causing the issue:
That is:
doing `__attribute__((optimize(3, "no-ssa-phiopt")))` (instead of just 3) still
fails.

Turning off SRA allows it to work but I suspect SRA is just exposing it.

[Bug middle-end/110515] llvm-15.0.7 possibly invalid code on -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[14 Regression] llvm-15.0.7 |llvm-15.0.7 possibly
   |possibly invalid code on|invalid code on -O3
   |-O3 |

--- Comment #3 from Andrew Pinski  ---
And GCC 12.

[Bug middle-end/110004] large increase in profile mismatches on tramp3d

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

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

--- Comment #2 from Jan Hubicka  ---
Linkes the statistics for outedges (that probabilities sums to 100).
Here are statistic for inedges.

We track mismatches after alignments RTL pass since it is last one, so it
cummulates all the mismatches through the pipeline. Martin was objecting agains
tracing all the passes independently.

https://lnt.opensuse.org/db_default/v4/CPP/graph?highlight_run=42409=353.964.7

[Bug middle-end/110515] [12/13/14 Regression] llvm-15.0.7 possibly invalid code on -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|llvm-15.0.7 possibly|[12/13/14 Regression]
   |invalid code on -O3 |llvm-15.0.7 possibly
   ||invalid code on -O3
   Target Milestone|--- |12.4
   Keywords||wrong-code

[Bug middle-end/110515] [14 Regression] llvm-15.0.7 possibly invalid code on -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||13.1.0

--- Comment #2 from Andrew Pinski  ---
It also fails in GCC 13.

[Bug middle-end/110515] [14 Regression] llvm-15.0.7 possibly invalid code on -O3

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

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

--- Comment #1 from Sergei Trofimovich  ---
I tried reverting r14-1597-g64d90d06d2db43 in hopes to sidestep PR110228. It
did not help.

[Bug middle-end/110515] New: [14 Regression] llvm-15.0.7 possibly invalid code on -O3

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

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

Bug ID: 110515
   Summary: [14 Regression] llvm-15.0.7 possibly invalid code on
-O3
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55447
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55447=edit
DwarfCompileUnit.cpp

Initially the failure is observed on r14-2233-gfca6d9c12f5bf0 where llvm-15.0.7
test suite fails a single test:

  Failed Tests (1):
LLVM :: DebugInfo/X86/vla-multi.ll

I think I shrunk it down to DwarfCompileUnit.cpp:

$ g++ -std=c++14 DwarfCompileUnit.cpp -O2 $cxxflags -o bug-O2 && ./bug-O2
Illegal instruction (core dumped)
$ g++ -std=c++14 DwarfCompileUnit.cpp -O1 $cxxflags -o bug-O1 && ./bug-O1


It's a very fragile test:
- any inlines I try seem to repair the test
- -fno-strict-aliasing unbreaks it (I believe the code is strict-aliasing
clean)
- optimization option changes repair the test

$ g++ -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-14.0.0/bin/g++
COLLECT_LTO_WRAPPER=/<>/gcc-14.0.0/libexec/gcc/x86_64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0  (experimental) (GCC)

[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable

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

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

--- Comment #23 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #22)
> (In reply to Zhendong Su from comment #21)
> > Another very likely related reproducer.
> Yes:
>[local count: 82077551]:
>   a.0_1 = a;
>   _27 = a.0_1 == 0;
>   _5 = (int) _27;
>   _28 = _5 | i_14;
>   pretmp_45 = b;
> ...
>[local count: 200189151]:
>   # i_14 = PHI 

I wonder if ccp1 in this case could cause the 1 to proped out of the loop. and
maybe we need some more isolation going on when it comes to using uninitialized
variables ...

[Bug driver/77576] gcc-ar doesn't work if all options are read from file

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Costas Argyris  ---
Implemented what Andrew said:

"I suspect we should expand the @file and then put it in a temp file and do the
correct thing."

Attached patch here but also sending to gcc-patches ML.

[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable

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

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

--- Comment #22 from Andrew Pinski  ---
(In reply to Zhendong Su from comment #21)
> Another very likely related reproducer.
Yes:
   [local count: 82077551]:
  a.0_1 = a;
  _27 = a.0_1 == 0;
  _5 = (int) _27;
  _28 = _5 | i_14;
  pretmp_45 = b;
...
   [local count: 200189151]:
  # i_14 = PHI 

[Bug driver/77576] gcc-ar doesn't work if all options are read from file

[costas.argyris at gmail dot com via Gcc-bugs]

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

Costas Argyris  changed:

   What|Removed |Added

 CC||costas.argyris at gmail dot com

--- Comment #6 from Costas Argyris  ---
Created attachment 55446
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55446=edit
Expand at-file and use temporary response file.

[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable

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

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

--- Comment #21 from Zhendong Su  ---
Another very likely related reproducer.

[628] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230701 (experimental) [master r14-924-gd709841ae0f] (GCC)
[629] %
[629] % gcctk -O3 small.c
[630] % for i in $(seq 1 10); do
> echo $i
> ./a.out
> done
1
Floating point exception
2
Floating point exception
3
Floating point exception
4
Floating point exception
5
Floating point exception
6
Floating point exception
7
Floating point exception
8
Floating point exception
9
10
[631] % cat small.c
int a, b, c, d, e, f = 1, g, h;
int main () {
  int i;
  for (; g < 1; g++) {
  if (!a)
i = 1;
  for (; b < 1; b++)
  L:
;
}
  int k = -1 / f;
  while (d)
i = 0;
  c = k;
  e = ~i;
  if (e > h) {
  f = 0;
  goto L;
}
  return 0;
}

[Bug tree-optimization/110499] malloc branch predictor is broken

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-07-01
   Keywords||missed-optimization

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

[Bug middle-end/101926] [meta-bug] struct/complex/other argument passing and return should be improved

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/110450] [14 Regression] Dead Code Elimination Regression at -O2 since r14-261-g0ef3756adf0

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
In VRP:
trunk:
```
Folding statement: _11 = _9 % 11;
Matching expression match.pd:2480, gimple-match-4.cc:35
Matching expression match.pd:2483, gimple-match-3.cc:66
Matching expression match.pd:2490, gimple-match-2.cc:58
Matching expression match.pd:1991, gimple-match-5.cc:23
Matching expression match.pd:2480, gimple-match-4.cc:35
Matching expression match.pd:2483, gimple-match-3.cc:66
Matching expression match.pd:2490, gimple-match-2.cc:58
Matching expression match.pd:1948, gimple-match-7.cc:20
Matching expression match.pd:2480, gimple-match-4.cc:35
Matching expression match.pd:2483, gimple-match-3.cc:66
Matching expression match.pd:2490, gimple-match-2.cc:58
Applying pattern match.pd:5319, gimple-match-8.cc:2688
Applying pattern match.pd:6000, gimple-match-10.cc:587
Applying pattern match.pd:2102, gimple-match-1.cc:6289
Applying pattern match.pd:6000, gimple-match-10.cc:587
Applying pattern match.pd:5284, gimple-match-4.cc:1099
Applying pattern match.pd:1378, gimple-match-3.cc:7680
Applying pattern match.pd:4720, gimple-match-1.cc:16033
gimple_simplified to _14 = a.1_2 <= 0;
_15 = (int) _14;
_11 = _15 << 3;
Global Exported: _11 = [irange] int [0, 0][8, 8] NONZERO 0x8
Folded into: _11 = _15 << 3;
```

And the relationship between _5 and _11 is completely lost.


while in GCC 13:
```
Folding statement: _11 = _9 % 11;
Global Exported: _11 = [irange] int [0, 0][8, 8] NONZERO 0x8
Folded into: _11 = _9;
```

And then we remove the __builtin_unreachable even though we infer that _5 would
be 0 and therefore _11 would never be 8 .

[Bug libstdc++/110512] C++20 random access iterators run sequentially with PSTL

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
See PR 100070. This is basically the same issue, but for PSTL.

[Bug libstdc++/110512] C++20 random access iterators run sequentially with PSTL

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

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

--- Comment #1 from Jonathan Wakely  ---
I think this is the correct behaviour according to the standard. We have other
bug reports about C++20 iterators used with STL algos and containers, which
again, are working as required by the standard.

[Bug d/110514] New: d: accesses immutable arrays using constant index still bounds checked

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

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

Bug ID: 110514
   Summary: d: accesses immutable arrays using constant index
still bounds checked
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gcc dot gnu.org
  Target Milestone: ---

For example:
---
immutable uint[] arr = [1,2,3];

void test()
{
immutable uint* p = arr.ptr;
if (arr[0]== p[0] && arr[1] == p[1] && arr[2] == p[2])
return;
assert(0);
}
---

Although the size and value of `arr` is known at compile-time, and is
guaranteed to never change at run-time, there are still three calls to
`_d_arrayboundsp` inserted into the program.

[Bug c++/110513] Invalid use of incomplete type std::bool_constant inside requires expression

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

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

--- Comment #3 from Andrew Pinski  ---
The underlaying problem here is most likely the same issue as the one in PR
94332 .

[Bug c++/110513] Invalid use of incomplete type std::bool_constant inside requires expression

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

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

--- Comment #2 from Andrew Pinski  ---
Reduced slightly more:
```
template
struct bool_const1 {};

struct B {
bool b = true;
};

// error in GCC
static_assert( requires() { bool_const1{}; } );
```

[Bug c++/110513] Invalid use of incomplete type std::bool_constant inside requires expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-07-01
 Ever confirmed|0   |1
   Keywords||rejects-valid

--- Comment #1 from Andrew Pinski  ---
Reduced testcase:
```
template
struct bool_const1 
{
  typedef bool T;
  static constexpr T value = a;
  constexpr T operator()(){return value;}
};

struct B {
bool b = true;
};

// ok everywhere
static_assert( bool_const1{}() );

// error in GCC
static_assert( requires() { bool_const1{}(); } );
```

[Bug c++/110513] New: Invalid use of incomplete type std::bool_constant inside requires expression

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 110513
   Summary: Invalid use of incomplete type std::bool_constant
inside requires expression
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

The following program


#include 

struct B {
bool b = true;
};

// ok everywhere
static_assert( std::bool_constant{}() );

// error in GCC
static_assert( requires() { std::bool_constant{}(); } );


is accepted in Clang and MSVC, but GCC complains


:11:56: error: invalid use of incomplete type
'std::bool_constant'
   11 | static_assert( requires() { std::bool_constant{}(); } );
  | ~~~^~
In file included from :1:
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/type_traits:62:12: note:
declaration of 'std::bool_constant'
   62 | struct integral_constant
  |^


Online demo: https://gcc.godbolt.org/z/csKanbM88

[Bug c++/110463] [13/14 Regression] Mutable subobject is usable in a constant expression

[fchelnokov at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Fedor Chelnokov  ---
Thanks a lot for a very quick fix!

[Bug middle-end/110510] ggc infinite recursion

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-07-01
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

--- Comment #3 from Andrew Pinski  ---
Created attachment 55445
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55445=edit
Patch to try

Can you try this patch? I am doing a full bootstrap/test right now.

[Bug libstdc++/110512] New: C++20 random access iterators run sequentially with PSTL

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

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

Bug ID: 110512
   Summary: C++20 random access iterators run sequentially with
PSTL
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gonzalo.gadeschi at gmail dot com
  Target Milestone: ---

See https://github.com/llvm/llvm-project/issues/63447

The problem is the following:

std::vector x(n), y(n);
auto ids = std::views::iota((int)0, (int)x.size());
std::for_each(std::execution::par_unseq, ids.begin(), ids.end(), [x = x.data(),
y = y.data()](int i) {
x[i] = y[i];
});

Iterators from C++20 ranges model the C++20 random_access_iterator concept, but
do not necessarily have a random access iterator tag. They are not recognized
by the PSTL as random access iterators (but forward iterators), causing the
parallel algorithms to fall back to sequential execution.

This is significantly impacting the performance a couple of large HPC
applications.

A quick and dirty workaround is to modify pstl/executors_impls.hpp by changing
the random_access_iterator to:

template 
struct __is_random_access_iterator<_IteratorType> {
static constexpr bool value = (
(bool)std::is_same_v::iterator_category,
std::random_access_iterator_tag>
|| (bool)::std::random_access_iterator<_IteratorType>
);
typedef std::integral_constant type;
};

Since llvm-project/pstl has been forked by libc++, it does no longer make sense
to try to patch pstl upstream to fix this issue.

[Bug middle-end/110510] ggc infinite recursion

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

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

--- Comment #2 from Andrew Pinski  ---
>+struct GTY((chain_next(%h.next_lp))) eh_landing_pad_d

Should have been:
+struct GTY((chain_next("%h.next_lp"))) eh_landing_pad_d

[Bug middle-end/110510] ggc infinite recursion

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

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

--- Comment #1 from Andrew Pinski  ---
It does not look like an infinite recursion but rather the chain of
eh_landing_pad_d is not mentioned to the GC so it does not do an inline-tail
call. 

This might fix the issue:
diff --git a/gcc/except.h b/gcc/except.h
index 378a9e4cb77..087d0004c6d 100644
--- a/gcc/except.h
+++ b/gcc/except.h
@@ -66,7 +66,7 @@ enum eh_region_type
 /* A landing pad for a given exception region.  Any transfer of control
from the EH runtime to the function happens at a landing pad.  */

-struct GTY(()) eh_landing_pad_d
+struct GTY((chain_next(%h.next_lp))) eh_landing_pad_d
 {
   /* The linked list of all landing pads associated with the region.  */
   struct eh_landing_pad_d *next_lp;

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

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

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

--- Comment #47 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #46)
> Note this came up on twitter the other day:
> https://twitter.com/rep_stosq_void/status/1461635511009828864

Wayback Machine link, since the original has been deleted:
http://web.archive.org/web/20220319120336/https://twitter.com/rep_stosq_void/status/1461635511009828864

[Bug d/103944] [12/13/14 Regression] Testsuite hang due to libphobos/testsuite/libphobos.gc/forkgc2.d

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

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

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

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

commit r14-2233-gfca6d9c12f5bf06469cf9f7db8c42f66ef792fd2
Author: Iain Sandoe 
Date:   Sun Feb 26 13:53:52 2023 +

libphobos, testsuite: Disable forkgc2 on Darwin [PR103944]

It hangs the testsuite (requiring manual intervention to kill the
spawned processes) which breaks CI.  The reason for the hang id not
clear.  This skips the test for now (xfail does not work).

Signed-off-by: Iain Sandoe 

PR d/103944

libphobos/ChangeLog:

* testsuite/libphobos.gc/forkgc2.d: Skip for Darwin.

[Bug d/110471] d: Don't generate code that throws exceptions when compiling with `-fno-exceptions'

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

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

ibuclaw at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from ibuclaw at gcc dot gnu.org ---
Fix committed and backported to gcc-13.

[Bug d/110471] d: Don't generate code that throws exceptions when compiling with `-fno-exceptions'

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

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Iain Buclaw
:

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

commit r13-7518-g6e7909191ada316a426739eab88139d63194e05a
Author: Iain Buclaw 
Date:   Sat Jul 1 17:01:30 2023 +0200

d: Don't generate code that throws exceptions when compiling with
`-fno-exceptions'

The version flags for RTMI, RTTI, and exceptions was unconditionally
predefined.  These are now only predefined if the feature flag is
enabled.  It was noticed that there was no `-fexceptions' definition
inside d/lang.opt, so the detection of the exceptions option flag was
only partially working.  Once that was fixed, a few places in the
front-end implementation were found to fall fowl of `nothrow' rules,
these have been fixed upstream and backported here as well.

Reviewed-on: https://github.com/dlang/dmd/pull/15357
 https://github.com/dlang/dmd/pull/15360

PR d/110471

gcc/d/ChangeLog:

* d-builtins.cc (d_init_versions): Predefine D_ModuleInfo,
D_Exceptions, and D_TypeInfo only if feature is enabled.
* lang.opt: Add -fexceptions.

gcc/testsuite/ChangeLog:

* gdc.dg/pr110471a.d: New test.
* gdc.dg/pr110471b.d: New test.
* gdc.dg/pr110471c.d: New test.

(cherry picked from commit da108c75ad386b3f1f47abb2265296e4b61d578a)

[Bug d/110471] d: Don't generate code that throws exceptions when compiling with `-fno-exceptions'

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

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

commit r14-2232-gda108c75ad386b3f1f47abb2265296e4b61d578a
Author: Iain Buclaw 
Date:   Sat Jul 1 17:01:30 2023 +0200

d: Don't generate code that throws exceptions when compiling with
`-fno-exceptions'

The version flags for RTMI, RTTI, and exceptions was unconditionally
predefined.  These are now only predefined if the feature flag is
enabled.  It was noticed that there was no `-fexceptions' definition
inside d/lang.opt, so the detection of the exceptions option flag was
only partially working.  Once that was fixed, a few places in the
front-end implementation were found to fall fowl of `nothrow' rules,
these have been fixed upstream and backported here as well.

Reviewed-on: https://github.com/dlang/dmd/pull/15357
 https://github.com/dlang/dmd/pull/15360

PR d/110471

gcc/d/ChangeLog:

* d-builtins.cc (d_init_versions): Predefine D_ModuleInfo,
D_Exceptions, and D_TypeInfo only if feature is enabled.
* lang.opt: Add -fexceptions.

gcc/testsuite/ChangeLog:

* gdc.dg/pr110471a.d: New test.
* gdc.dg/pr110471b.d: New test.
* gdc.dg/pr110471c.d: New test.

[Bug bootstrap/110467] Bootstrap with Ada enabled fails with --enable-host-pie

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

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

--- Comment #5 from Marek Polacek  ---
(In reply to Eric Botcazou from comment #4)
> > You were CC'd here:
> > , FWIW.
> 
> I totally missed it, sorry about that. :-(

No problem, sorry for not pinging you about it.  I'll make sure to CC you when
I post a fix for this PR.

[Bug d/110511] d: internal compiler error: in setValue, at d/dmd/dinterpret.c:7013

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

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

ibuclaw at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from ibuclaw at gcc dot gnu.org ---
Upstream PR backported.

[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16

[sascha.scandella at dentsplysirona dot com via Gcc-bugs]

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

--- Comment #15 from Sascha Scandella  ---
For Darwin and GCC 13.1 I've openend a PR with the band-aid fix as proposed by
Jonathan.

https://github.com/Homebrew/homebrew-core/pull/135530

[Bug d/110511] d: internal compiler error: in setValue, at d/dmd/dinterpret.c:7013

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Iain Buclaw
:

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

commit r10-11485-ga44fb702058974cc7592e8f8a81260f6ab35bece
Author: Iain Buclaw 
Date:   Sat Jul 1 15:04:25 2023 +0200

d: Fix ICE in setValue, at d/dmd/dinterpret.c:7013

Backports ICE fix from upstream.  When casting null to integer or real,
instead of painting the type on the NullExp, we emplace an
IntegerExp/RealExp with the value zero.  Same as when casting from
NullExp to bool.

Reviewed-on: https://github.com/dlang/dmd/pull/13172

PR d/110511

gcc/d/ChangeLog:

* dmd/dinterpret.c (Interpreter::visit (CastExp *)): Handle casting
null to int or float.

gcc/testsuite/ChangeLog:

* gdc.test/compilable/test21794.d: New test.

(cherry picked from commit 066385c918485d4cef5c243d3b0691193df382de)

[Bug d/110511] d: internal compiler error: in setValue, at d/dmd/dinterpret.c:7013

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

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:066385c918485d4cef5c243d3b0691193df382de

commit r11-10888-g066385c918485d4cef5c243d3b0691193df382de
Author: Iain Buclaw 
Date:   Sat Jul 1 15:04:25 2023 +0200

d: Fix ICE in setValue, at d/dmd/dinterpret.c:7013

Backports ICE fix from upstream.  When casting null to integer or real,
instead of painting the type on the NullExp, we emplace an
IntegerExp/RealExp with the value zero.  Same as when casting from
NullExp to bool.

Reviewed-on: https://github.com/dlang/dmd/pull/13172

PR d/110511

gcc/d/ChangeLog:

* dmd/dinterpret.c (Interpreter::visit (CastExp *)): Handle casting
null to int or float.

gcc/testsuite/ChangeLog:

* gdc.test/compilable/test21794.d: New test.

[Bug d/110511] d: internal compiler error: in setValue, at d/dmd/dinterpret.c:7013

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

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

ibuclaw at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-07-01
 Ever confirmed|0   |1

--- Comment #1 from ibuclaw at gcc dot gnu.org ---
Fixed by https://github.com/dlang/dmd/pull/13172

Will only backport that commit to gcc-10 and gcc-11 then.

[Bug d/110511] New: d: internal compiler error: in setValue, at d/dmd/dinterpret.c:7013

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

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

Bug ID: 110511
   Summary: d: internal compiler error: in setValue, at
d/dmd/dinterpret.c:7013
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gcc dot gnu.org
  Target Milestone: ---

Only affects gdc-11 and earlier.

---
void formattedRead()
{
cast(void)checkFormatException!();
}

const checkFormatException() =
{
const pnum = { ubyte* p; return cast(ulong) p; }();
return null;
}();

---

[Bug tree-optimization/25623] jump threading/cfg cleanup messes up "incoming counts" for some BBs

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

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

commit r14-2231-gee4d85b3a8b76328df6bccc1026d62dff5f827ce
Author: Jan Hubicka 
Date:   Sat Jul 1 13:44:46 2023 +0200

Add testcase from PR25623

gcc/testsuite/ChangeLog:

PR tree-optimization/25623
* gfortran.dg/pr25623.f90: New test.

[Bug middle-end/110510] New: ggc infinite recursion

[franckbehaghel_gcc at protonmail dot com via Gcc-bugs]

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

Bug ID: 110510
   Summary: ggc infinite recursion
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: franckbehaghel_gcc at protonmail dot com
  Target Milestone: ---

Created attachment 55444
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55444=edit
source

Hello,

The attached ada source file fails to build. I got the following result:

$ gcc -c  failed_ggc.adb
failed_ggc.adb:3:11: warning: file name does not match unit name, should be
"main.adb" [enabled by default]

raised STORAGE_ERROR : stack overflow or erroneous memory access


Looking into this with gdb, it gaves me more detailed information :


$ gcc -c  -wrapper gdb,--args failed_ggc.adb

[...]
Program received signal SIGSEGV, Segmentation fault.
0x010592c3 in gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e0410) at
gtype-desc.cc:3582
3582  gt_ggc_m_7rtx_def ((*x).landing_pad);
[...]


backtrace output looks like a infinite recursion :

(gdb) bt
#0  0x010592c3 in gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e0410) at
gtype-desc.cc:3582
#1  gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e0438) at gtype-desc.cc:3579
#2  0x010592d4 in gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e0438) at
gtype-desc.cc:3582
#3  gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e0460) at gtype-desc.cc:3579
#4  0x010592d4 in gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e0460) at
gtype-desc.cc:3582
#5  gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e0488) at gtype-desc.cc:3579
#6  0x010592d4 in gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e0488) at
gtype-desc.cc:3582
#7  gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e04b0) at gtype-desc.cc:3579
#8  0x010592d4 in gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e04b0) at
gtype-desc.cc:3582
#9  gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e04d8) at gtype-desc.cc:3579
#10 0x010592d4 in gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e04d8) at
gtype-desc.cc:3582
#11 gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e0500) at gtype-desc.cc:3579
#12 0x010592d4 in gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e0500) at
gtype-desc.cc:3582
#13 gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e0528) at gtype-desc.cc:3579
#14 0x010592d4 in gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e0528) at
gtype-desc.cc:3582
#15 gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e0550) at gtype-desc.cc:3579
#16 0x010592d4 in gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e0550) at
gtype-desc.cc:3582
#17 gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e0578) at gtype-desc.cc:3579
#18 0x010592d4 in gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e0578) at
gtype-desc.cc:3582
#19 gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e05a0) at gtype-desc.cc:3579
#20 0x010592d4 in gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e05a0) at
gtype-desc.cc:3582
#21 gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffd26e05c8) at gtype-desc.cc:3579


(gdb) bt -50
#4193802 0x010592d4 in gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffca638c80)
at gtype-desc.cc:3582
#4193803 gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffca638ca8) at gtype-desc.cc:3579
#4193804 0x010592d4 in gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffca638ca8)
at gtype-desc.cc:3582
#4193805 gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffca638cd0) at gtype-desc.cc:3579
#4193806 0x010592d4 in gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffca638cd0)
at gtype-desc.cc:3582
#4193807 gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffca638cf8) at gtype-desc.cc:3579
#4193808 0x0105939c in gt_ggc_mx_eh_landing_pad_d (x_p=0x7fffca638cf8)
at gtype-desc.cc:3577
#4193809 gt_ggc_mx_eh_region_d (x_p=0x7fffd9141738) at gtype-desc.cc:3567
#4193810 0x010593f0 in gt_ggc_mx_eh_region_d (x_p=0x7fffd9141738) at
gtype-desc.cc:3562
#4193811 gt_ggc_mx_eh_region_d (x_p=0x7fffd91416e0) at gtype-desc.cc:3549
#4193812 0x0105a0d0 in gt_ggc_mx_eh_region_d (x_p=0x7fffd91416e0) at
gtype-desc.cc:3614
#4193813 gt_ggc_mx_eh_status (x_p=0x7fffea7522d0) at gtype-desc.cc:2259
#4193814 0x0105cefe in gt_ggc_mx_function (x_p=0x7fffe94610b8) at
gtype-desc.cc:1720
#4193815 gt_ggc_mx_function (x_p=0x7fffe94610b8) at gtype-desc.cc:1715
#4193816 0x00a1fc2a in gt_ggc_mx_lang_tree_node (x_p=)
at ./gtype-ada.h:288
#4193817 0x00a1fb87 in gt_ggc_mx_lang_tree_node (x_p=)
at ./gtype-ada.h:277
#4193818 0x00a1f158 in gt_ggc_mx_lang_tree_node (x_p=)
at ./gtype-ada.h:191
#4193819 0x00a1f5be in gt_ggc_mx_lang_tree_node (x_p=)
at ./gtype-ada.h:420
#4193820 0x01059cdf in gt_ggc_mx_gimple (x_p=) at
gtype-desc.cc:1254
#4193821 0x0105afba in gt_ggc_mx_cgraph_edge (x_p=) at
gtype-desc.cc:1422
#4193822 0x0105af9e in gt_ggc_mx_cgraph_edge (x_p=) at
gtype-desc.cc:1420
#4193823 0x0105af9e in gt_ggc_mx_cgraph_edge (x_p=) at
gtype-desc.cc:1420
#4193824 0x0105af9e in 

[Bug tree-optimization/25623] jump threading/cfg cleanup messes up "incoming counts" for some BBs

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

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

--- Comment #10 from Jan Hubicka  ---
testcase from Comment #1 is wontfix (there is really not much to do at the
threading time since profile was not estimated realistically).
Original fortran testcase now works 
(after fix g:7e904d6c7f252ee947c237ed32dd43b2c248384d).
We do one threading in thread2 pass:

 Registering killing_def (path_oracle) _1
 Registering killing_def (path_oracle) ubound.4_14
Checking profitability of path (backwards):  
  [1] Registering jump thread: (2, 3) incoming edge;  (3, 6) nocopy;
path: 2->3->6 SUCCESS
Checking profitability of path (backwards):  bb:4 (6 insns) bb:10 (latch)
  Control statement insns: 2
  Overall: 4 insns


and give up on two because they crosses loop boundary.

Checking profitability of path (backwards):  bb:3 (2 insns) bb:4 (latch)
  Control statement insns: 2
  Overall: 0 insns

 Registering killing_def (path_oracle) S.6_56
path: 4->3->xx REJECTED
Checking profitability of path (backwards):  bb:6 (2 insns) bb:7 (latch)
  Control statement insns: 2
  Overall: 0 insns

 Registering killing_def (path_oracle) i_68
path: 7->6->xx REJECTED
 headers pass.

One path is the usual entry condition of loop known to be true (which I think
early opts should handle) and is eventually dealt with copy header pass.
Other path gets eventually a reason for the failure dumped:

Checking profitability of path (backwards):  bb:4 (16 insns) bb:6 (latch)
  Control statement insns: 2
  Overall: 14 insns
  FAIL: Did not thread around loop and would copy too many statements.
__attribute__((fn spec (". w w w w ")))

This is fact that loop is known to iterate at least once (there is explicit
+1). It may be interesting to peel for this.

With -O3 we vectorize the loop and while unroll the epilogue. However we get:

;;   basic block 14, loop depth 1, count 668941153 (estimated locally), maybe
hot
;;prev block 16, next block 15, flags: (NEW, REACHABLE, VISITED)
;;pred:   15 [always]  count:595357627 (estimated locally)
(FALLTHRU,DFS_BACK,EXECUTABLE)
;;16 [always]  count:73583526 (estimated locally) (FALLTHRU)
  # i_34 = PHI 
  _2 = i_34 + -1;
  _17 = (integer(kind=8)) _2;
  _18 = (*a_19(D))[_17];
  tmp_45 = __builtin_pow (_18,
3.33314829616256247390992939472198486328125e-1);
  tmp2_44 = tmp_45 * tmp_45;
  tmp4_43 = tmp2_44 * tmp2_44;
  _42 = (*b_24(D))[_17];
  _41 = _42 + tmp4_43;
  (*b_24(D))[_17] = _41;
  _39 = (*c_16(D))[_17];
  _38 = _39 + tmp2_44;
  (*c_16(D))[_17] = _38;
  i_31 = i_34 + 1;
  if (_1 < i_31)
goto ; [11.00%]
  else
goto ; [89.00%]

Cunrolli unloops it without fixing the profile resulting in inconsistent
profile:

;;   basic block 16, loop depth 0, count 668941153 (estimated locally), maybe
hot
;;   Invalid sum of incoming counts 73583527 (estimated locally), should be
668941153 (estimated locally)
;;prev block 13, next block 17, flags: (NEW, REACHABLE, VISITED)
;;pred:   13 [66.7% (guessed)]  count:63071594 (estimated locally)
(FALSE_VALUE)
;;7 [10.0% (guessed)]  count:10511933 (estimated locally)
(TRUE_VALUE)
  # i_29 = PHI 
  _2 = i_29 + -1;
  _17 = (integer(kind=8)) _2;
  _18 = (*a_19(D))[_17];
  tmp_45 = __builtin_pow (_18,
3.33314829616256247390992939472198486328125e-1);
  tmp2_44 = tmp_45 * tmp_45;
  tmp4_43 = tmp2_44 * tmp2_44;
  _42 = (*b_24(D))[_17];
  _41 = _42 + tmp4_43;
  (*b_24(D))[_17] = _41;
  _39 = (*c_16(D))[_17];
  _38 = _39 + tmp2_44;
  (*c_16(D))[_17] = _38;
  i_31 = i_29 + 1;
;;succ:   17 [always (guessed)]  count:668941153 (estimated locally)
(FALLTHRU)

;;   basic block 17, loop depth 0, count 105119324 (estimated locally), maybe
hot
;;   Invalid sum of incoming counts 700476950 (estimated locally), should be
105119324 (estimated locally)
;;prev block 16, next block 5, flags: (NEW, VISITED)
;;pred:   16 [always (guessed)]  count:668941153 (estimated locally)
(FALLTHRU)
;;13 [33.3% (guessed)]  count:31535797 (estimated locally)
(TRUE_VALUE)
;;succ:   5 [always]  count:105119324 (estimated locally)
(FALLTHRU,EXECUTABLE)

So I guess unlooping should fix the profile after itself, but does vect really
need to produce loops iterating precisely once?

[Bug middle-end/52070] missing integer comparison optimization

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com
 Resolution|--- |FIXED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=96674
   Target Milestone|--- |13.0
 Status|NEW |RESOLVED

--- Comment #3 from Roger Sayle  ---
This has been fixed (optimally) since GCC 13, by Eugene Rozenfeld's fix for PR
tree-optimization/96674.  The conditional jump was eliminated back in GCC 4.9,
but the combination of the two tests into a subtraction and a single comparison
was implemented (at the tree level) by Eugene.

[Bug tree-optimization/110506] [14 Regression] Ice: tree check: expected none of vector_type, have vector_type in get_value_for_expr, at tree-ssa-ccp.cc:686

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
This C code might be related:

typedef unsigned uint32_t;
typedef uint32_t uint32x4 __attribute__((vector_size(16)));
typedef struct {
  uint32x4 b, d
} prng_t;
prng_t prng_rand_128_r_x;
main_flags;
main() {
  uint32_t ref_crc[] = {7, 3};
  uint32x4 e = (prng_rand_128_r_x.b << 27) + (prng_rand_128_r_x.b >> 32 - 27);
  prng_rand_128_r_x.d = e;
  if (ref_crc[main_flags])
__assert_fail();
}

$ ~/gcc/results/bin/gcc -c -w -O2 bug936B.c
during GIMPLE pass: slp
bug936B.c: In function ‘main’:
bug936B.c:8:1: internal compiler error: tree check: expected none of
vector_type
, have vector_type in vect_recog_rotate_pattern, at tree-vect-patterns.cc:3729
8 | main() {
  | ^~~~
0x1166129 tree_not_check_failed(tree_node const*, char const*, int, char
const*,
 ...)
../../trunk.year/gcc/tree.cc:8936
0x1cc8da3 vect_recog_rotate_pattern(vec_info*, _stmt_vec_info*, tree_node**)
../../trunk.year/gcc/tree-vect-patterns.cc:0

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #44 from Jürgen Reuter  ---
(In reply to anlauf from comment #43)
> Mabye the fprem issue was a red herring from the beginning, pointing to a
> problem in a different place.
> 
> I recompiled each module in a loop with -O0 until the FPE went away.
> 
> instances_sub.f90 seems the file someone wants to look at.
> 
> Works at -O0, -O1, -Os, -O2 -fno-tree-vectorize
> Fails at -O2, -O3
> 
> on x86_64-pc-linux-gnu.
> 
> Jürgen: can you reduce this even more with this information?

Thanks, this info is helpful. So it is the setting up of the full process via
the instances module, which is in agreement with the fact that the simple test
with only the RNG did not fail. I will be busy for several days, but hopefully
in a week from now, I'll know more.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

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

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

--- Comment #43 from anlauf at gcc dot gnu.org ---
Mabye the fprem issue was a red herring from the beginning, pointing to a
problem in a different place.

I recompiled each module in a loop with -O0 until the FPE went away.

instances_sub.f90 seems the file someone wants to look at.

Works at -O0, -O1, -Os, -O2 -fno-tree-vectorize
Fails at -O2, -O3

on x86_64-pc-linux-gnu.

Jürgen: can you reduce this even more with this information?

[Bug tree-optimization/103680] Jump threading and switch corrupts profile

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

https://gcc.gnu.org/g:02460c0b8c9000359a09440f9532664a7835f158

commit r14-2228-g02460c0b8c9000359a09440f9532664a7835f158
Author: Jan Hubicka 
Date:   Sat Jul 1 09:09:39 2023 +0200

Fix update_bb_profile_for_threading

Fix profile some of profile mismatched caused by profile updating.
It seems that I misupdated update_bb_profile_for_threading in 2017 which
results in invalid updates from rtl threading and threadbackwards.
update_bb_profile_for_threading knows that some paths to BB are being
redirected elsehwere and those paths will exit from BB with E.  So it needs
to
determine probability of the duplicated path and redistribute probablities.
For some reaosn however the conditonal probability of redirected path is
computed after its counts is subtracted which is wrong and often results in
probability greater than 100%.

I also fixed error mesage.  Compilling tramp3d I now get following passes
producing mismpatches:
Pass dump id and name|static mismatcdynamic mismatch
 |in count |in count
113t fre |  2+2|0
114t mergephi|  2  |0
115t threadfull  |  2  |0
116t vrp |  2  |0
127t ch  |307  +305|347194302   +347194302
130t thread  |313+6|347221478   +27176
131t dom |321+8|346841121  -380357
134t reassoc |323+2|346841121
136t forwprop|327+4|347026371  +185250
144t pre |326-1|347040926   +14555
172t ifcvt   |338+2|347218249  +156280
173t vect|409   +71|356357418 +9139169
176t cunroll |377   -32|126071925   -230285493
183t loopdone|376-1|126015489   -56436
194t tracer  |379+3|127258199 +1242710
197t dom |375-4|128352165 +1093966
199t threadfull  |379+4|128526112  +173947
200t vrp |381+2|128724673  +198561
204t dce |374-7|128632495   -92178
206t sink|370-4|128618043   -14452
211t cddce   |372+2|128632495   +14452
248t ehcleanup   |370-2|128618755   -13740
255t optimized   |362-8|128576810   -41945
256r expand  |356-6|128899768  +322958
258r into_cfglayout  |353-3|129051765  +151997
259r jump|354+1|129051765
262r cse1|353-1|129051765
275r loop2_unroll|355+2|132182110 +3130345
277r loop2_done  |354-1|132182109   -1
312r pro_and_epilogue|371   +17|13324   +40215
323r bbro|375+4|132095926  -126398

Without the patch at jump2 time we get over 432 mismatches, so 15%
improvement. Some of the mismathces are unavoidable.

I think ch mismatches are mostly due to loop header copying where the
header
condition constant propagates.  Most common case should be threadable in
early
optimizations and we also could do better on profile updating here.

Bootstrapped/regtested x6_64-linux, comitted.

gcc/ChangeLog:

PR tree-optimization/103680
* cfg.cc (update_bb_profile_for_threading): Fix profile update;
make message clearer.

gcc/testsuite/ChangeLog:

PR tree-optimization/103680
* gcc.dg/tree-ssa/pr103680.c: New test.
* gcc.dg/tree-prof/cmpsf-1.c: Un-xfail.

[Bug target/109435] overaligned structs are not passed correctly for mips64

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

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

YunQiang Su  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||syq at gcc dot gnu.org

--- Comment #5 from YunQiang Su  ---
Fixed by commit:

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