[Bug middle-end/114700] Front-end optimization generates wrong code with -ftrapv.

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

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

--- Comment #9 from Richard Biener  ---
That that GCC doesn't promise that -ftrapv preserves all overflows and traps,
it merely guarantees that all overflows that actually happen trap.  So GCC is
fine to contract some expressions where the overall number of overflows can
only
decrease.

That's not a bug with -ftrapv.

It is considered a bug with -fsanitize=undefined though.

[Bug middle-end/114700] Front-end optimization generates wrong code with -ftrapv.

[lin1.hu at intel dot com via Gcc-bugs]

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

--- Comment #8 from lin1.hu at intel dot com ---
(In reply to Andrew Pinski from comment #6)
> Note `c  - y  - c` to become `-y` reduces the possible of an overflow and is
> well defined for wrapping so this might be still on purpose as there will
> never be an overflow that causes difference if assuming wrapping ...

Indeed, so for -fsanitize=undefined, `c  - y  - c` become `-y` is right. It's
just missing the optimization to turn `z = c  - y  - c + a  + y - b` into `z =
a - b`.

[Bug middle-end/114700] Front-end optimization generates wrong code with -ftrapv.

[lin1.hu at intel dot com via Gcc-bugs]

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

--- Comment #7 from lin1.hu at intel dot com ---
(In reply to Andrew Pinski from comment #5)
> From match.pd:
>   /* Match patterns that allow contracting a plus-minus pair
>  irrespective of overflow issues.  */
>   /* (A +- B) - A   ->  +- B */
>   /* (A +- B) -+ B  ->  A */
>   /* A - (A +- B)   -> -+ B */
>   /* A +- (B -+ A)  ->  +- B */
>   (simplify
>(minus (nop_convert1? (plus:c (nop_convert2? @0) @1)) @0)
>(view_convert @1))
>   (simplify
>(minus (nop_convert1? (minus (nop_convert2? @0) @1)) @0)
>(if (!ANY_INTEGRAL_TYPE_P (type)
> || TYPE_OVERFLOW_WRAPS (type))
>(negate (view_convert @1))
>(view_convert (negate @1
> 
> Looks like missing a TYPE_OVERFLOW_SANITIZED check.

OK, this looks like the same reason why z = c - y + a - c is not optimized.

[Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point

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

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

--- Comment #17 from Kewen Lin  ---
(In reply to Michael Matz from comment #16)
> (In reply to Kewen Lin from comment #15)
> > I agree, thanks for the comments! btw, I'm not fighting for the current
> > implementation, just want to know more details why users are unable to make
> > use of the current implementation, is it just due to its inefficiency (like
> > the above sequence) or un-usability (unused at all). As your comments, I
> > think it's due to the former (inefficiency)?!
> 
> Okay.  So, yeah, I _think_ that other way (with NOPs between GEP and LEP,
> plus a jump around them) could be made to work with userspace live patching.
> It would just be inefficient.  But do note that that jump around was _not_
> part of the original way of -fpatchable-function-entry, so a change to
> codegen
> would have to have happened anyway to make that other way usable.  And it
> has the
> (perhaps theoretical, who knows :) ) problem of not using the normal 8-byte
> difference between GEP and LEP.
> 

Thanks again for confirming this understanding!

> I think your current proposal from comment #10 is the better from all
> perspectives.

Yeah, I agree. When reworking this support previously, comment #10 like
implementation was considered as a better one but it's not finally made due to
the concern that can break the assumption NOPs should be consecutive, based on
all the inputs here I think it's time to "fix" it by just underscoring this
special not-consecutive NOPs in documentation.

[Bug middle-end/114700] Front-end optimization generates wrong code with -ftrapv.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Note `c  - y  - c` to become `-y` reduces the possible of an overflow and is
well defined for wrapping so this might be still on purpose as there will never
be an overflow that causes difference if assuming wrapping ...

[Bug middle-end/114700] Front-end optimization generates wrong code with -ftrapv.

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

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

--- Comment #5 from Andrew Pinski  ---
>From match.pd:
  /* Match patterns that allow contracting a plus-minus pair
 irrespective of overflow issues.  */
  /* (A +- B) - A   ->  +- B */
  /* (A +- B) -+ B  ->  A */
  /* A - (A +- B)   -> -+ B */
  /* A +- (B -+ A)  ->  +- B */
  (simplify
   (minus (nop_convert1? (plus:c (nop_convert2? @0) @1)) @0)
   (view_convert @1))
  (simplify
   (minus (nop_convert1? (minus (nop_convert2? @0) @1)) @0)
   (if (!ANY_INTEGRAL_TYPE_P (type)
|| TYPE_OVERFLOW_WRAPS (type))
   (negate (view_convert @1))
   (view_convert (negate @1

Looks like missing a TYPE_OVERFLOW_SANITIZED check.

[Bug middle-end/114700] Front-end optimization generates wrong code with -ftrapv.

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

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

--- Comment #4 from Andrew Pinski  ---
int z;
void func(int a, int b, int c, int y){
z = c  - y  - c + a  + y - b;
}

[Bug middle-end/113904] [OpenMP][5.0][5.1] Dynamic context selector 'user={condition(expr)}' not handled

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

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

--- Comment #6 from sandra at gcc dot gnu.org ---
On further investigation, it appears that both the C and C++ front ends are at 
least attempting to parse the context selectors in the correct scope, although
C++ trips over a "use of parameter outside function body" error.  If that's
fixed, a code walk would find these things easily enough.  I guess we'd only
want to do the function wrapper around the expression if it actually references
parameters?  Certainly not for constants, at least.

I'd need help figuring out what to do for Fortran as I'm less familiar both
with the language semantics and the front end implementation.  I guess there
are additional complications due to supporting nested functions/modules.

[Bug middle-end/114700] Front-end optimization generates wrong code with -ftrapv.

[lin1.hu at intel dot com via Gcc-bugs]

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

--- Comment #3 from lin1.hu at intel dot com ---
(In reply to lin1.hu from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Gcc's trapv is known not always to work correctly.
> > 
> > Try -fsanitize=undefined instead.

Thanks, it solves the problem to some extent. But c is eliminated, I think c
- y may cause signed overflow.

https://godbolt.org/z/Wbzx5Edsj

[Bug middle-end/114700] Front-end optimization generates wrong code with -ftrapv.

[lin1.hu at intel dot com via Gcc-bugs]

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

--- Comment #2 from lin1.hu at intel dot com ---
(In reply to Andrew Pinski from comment #1)
> Gcc's trapv is known not always to work correctly.
> 
> Try -fsanitize=undefined instead.

Thanks, it solves the problem to some extent. But c is eliminated, I think c -
y may cause signed overflow, c

https://godbolt.org/z/Wbzx5Edsj

[Bug middle-end/114700] Front-end optimization generates wrong code with -ftrapv.

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

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

--- Comment #1 from Andrew Pinski  ---
Gcc's trapv is known not always to work correctly.

Try -fsanitize=undefined instead.

[Bug c/114700] New: Front-end optimization generates wrong code with -ftrapv.

[lin1.hu at intel dot com via Gcc-bugs]

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

Bug ID: 114700
   Summary: Front-end optimization generates wrong code with
-ftrapv.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lin1.hu at intel dot com
  Target Milestone: ---

We test GCC vs Clang with -ftrapv, and test is 
z = c  - y  - c + a  + y - b;
https://godbolt.org/z/EW1xTsazG

We think the clang is right, the overflow judgment should be performed after
each operation. But the front-end generates a - b directly, looks like there's
a bug in the front-end's handling of -ftrapv.

-ftrapv
This option generates traps for signed overflow on addition, subtraction,
multiplication operations. The options -ftrapv and -fwrapv override each other,
so using -ftrapv -fwrapv on the command-line results in -fwrapv being
effective. Note that only active options override, so using -ftrapv -fwrapv
-fno-wrapv on the command-line results in -ftrapv being effective.


We have another question, we found the front-end won't optimize z = c - y + a -
c, while z = c - y - c + a will, is this for any particular reason or is it a
bug?

[Bug c++/18635] [DR 504] use of uninitialised reference accepted (without -Wuninitialized) in C++ front end

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #22 from Marek Polacek  ---
Now closed as NAD: https://cplusplus.github.io/CWG/issues/504.html

[Bug c++/112842] Constrained parameter pack with trailing param gives no matching function.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Similar to PR 106211 .

[Bug c++/106211] Rejects valid with function template with non-deduced parameters from deduced parameters of another function template

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||c++-lambda
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-04-11
 Ever confirmed|0   |1

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

[Bug c++/114695] Template argument deduction and defaulted template template parameters

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

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

--- Comment #2 from Andrew Pinski  ---
Note you don't need the extra template int argument either to reproduce the
failure:
```

template  struct Bar {
void accept(X value) { }
};

template  struct Foo;

template 
struct Foo...> : Bar... {
template  class B = ::Bar>
constexpr static Bar* slice_by_type(B* self) {
return self;
}

template 
void accept(Us... values) {
(slice_by_type(this)->accept(values), ...);
}
};

int main() {
Foo, Bar> foo;
foo.accept(3.14f, 10);
}
```

[Bug c++/114695] Template argument deduction and defaulted template template parameters

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed; EDG accepts it also in C++17 (and C++20) modes. 

Also note If I change slice_by_type to take Bar instead of the template
argument, it works which makes it feel like for some reason GCC is not able to
deduce the arguments properly.

[Bug c++/114697] [DR 233] references in user defined conversions

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug target/94630] General bug for changes needed to switch the powerpc64le-linux long double default

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

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #11 from Michael Meissner  ---
All of the changes needed for making long double use the IEEE 128-bit encoding
have been fixed in GCC.  The Fedora distribution now uses long doubles with
IEEE 128-bit encodings as the default.

[Bug target/101019] GCC should consider using PLI/SLDI/PADDI to load up 64-bit constants on power10

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

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #2 from Michael Meissner  ---
The changes for this were checked into the master branch on December 12th, 2023
by Jiufu Guo  .

[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8

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

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

Peter Bergner  changed:

   What|Removed |Added

URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
   |il/gcc-patches/2022-Septemb |il/gcc-patches/2024-April/6
   |er/601825.html  |49329.html

--- Comment #19 from Peter Bergner  ---
New patch submitted as an update to Will's patch.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

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

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

--- Comment #22 from Tamar Christina  ---
note that due to the secondary exit the actual full vector iteration count is 8
scalar elements at VF=4 == 2.

And it's this boundary condition where we fail, since ceil (8/4) == 2. any
other value would have done the partial vector iteration.

Basically final_iter_may_be_partial ends up being ignored.

[Bug go/114699] gcc-go -buildmode=c-shared doesn't use -Wl,-z,nodelete so libraries crash when dlclosed

[rjones at redhat dot com via Gcc-bugs]

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

--- Comment #3 from Richard W.M. Jones  ---
(Edit comment 2: To be clear, that wasn't the thread where the
segfault occurred, which was some golang thread, that was the
thread that was unmapping the memory at the same time.  Using
nodelete avoids this by not actually unmapping the code.)

[Bug go/114699] gcc-go -buildmode=c-shared doesn't use -Wl,-z,nodelete so libraries crash when dlclosed

[rjones at redhat dot com via Gcc-bugs]

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

--- Comment #2 from Richard W.M. Jones  ---
This was the stack trace of the crashing thread with gcc-go:

Thread 7 (Thread 0x7ff5c1af3a40 (LWP 2819340)):
#0  0x7ff5c24d67cb in __GI_munmap () at
../sysdeps/unix/syscall-template.S:117
#1  0x7ff5c24c916a in _dl_unmap_segments (l=0x563fc0eba080) at
./dl-unmap-segments.h:32
#2  _dl_unmap (map=map@entry=0x563fc0eba080) at ../sysdeps/x86_64/tlsdesc.c:31
#3  0x7ff5c24b5ff5 in _dl_close_worker (map=,
map@entry=0x563fc0eb9a90, force=force@entry=false) at dl-close.c:628
#4  0x7ff5c24b663b in _dl_close (_map=0x563fc0eb9a90) at dl-close.c:793
#5  0x7ff5c24b5523 in __GI__dl_catch_exception
(exception=exception@entry=0x7fffe1bbd500, operate=0x7ff5c24b6600 <_dl_close>,
args=0x563fc0eb9a90) at dl-catch.c:237
#6  0x7ff5c24b5679 in _dl_catch_error (objname=0x7fffe1bbd568,
errstring=0x7fffe1bbd570, mallocedp=0x7fffe1bbd567, operate=,
args=) at dl-catch.c:256
#7  0x7ff5c20a4913 in _dlerror_run (operate=,
args=) at dlerror.c:138
#8  0x7ff5c20a4656 in __dlclose (handle=) at dlclose.c:31
#9  0x563fb3951239 in backend_unload (b=b@entry=0x563fc0ebbf60,
unload=0x7ff5c1ae43b0) at /home/rjones/d/nbdkit/server/backend.c:154
#10 0x563fb39512bc in plugin_free (b=0x563fc0ebbf60) at
/home/rjones/d/nbdkit/server/plugins.c:64
#11 0x563fb394ed51 in main (argc=, argv=) at
/home/rjones/d/nbdkit/server/main.c:838

[Bug go/114699] gcc-go -buildmode=c-shared doesn't use -Wl,-z,nodelete so libraries crash when dlclosed

[rjones at redhat dot com via Gcc-bugs]

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

--- Comment #1 from Richard W.M. Jones  ---
gcc 14.0.1-0.13.fc40 => crashes
golang-bin-1.22.2-1.fc40.x86_64 => works

I also checked this by stracing the linking process and
seeing -Wl,-z,nodelete is being used by golang, but not by
gcc-go.

[Bug go/114699] New: gcc-go -buildmode=c-shared doesn't use -Wl,-z,nodelete so libraries crash when dlclosed

[rjones at redhat dot com via Gcc-bugs]

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

Bug ID: 114699
   Summary: gcc-go -buildmode=c-shared doesn't use -Wl,-z,nodelete
so libraries crash when dlclosed
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: rjones at redhat dot com
  Target Milestone: ---

I was chasing a crash in nbdkit-golang-plugin
(https://gitlab.com/nbdkit/nbdkit/-/tree/master/plugins/golang?ref_type=heads).

This crash only happens with gcc-go (and quite reproducibly), but doesn't
happen with golang.  The crash happened when the plugin was being unloaded
with dlclose(3).

Long story short, this is a bug that has already been reported and "fixed"
(or more accurately, worked around) in golang:

https://github.com/golang/go/issues/11100

Because goroutines, the garbage collector, etc is basically running all
the time in golang programs, you cannot safely remove them from memory.
Any attempt to actually dlclose a golang plugin will crash most of the
time when a goroutine/the GC executes some code after dlclose.

golang works around this by linking shared libraries it creates with
-Wl,-z,nodelete:

https://github.com/golang/go/blob/1843464f014c946c1663de76249267486887626f/src/cmd/link/internal/ld/lib.go#L1587

Because gcc-go doesn't do this, the same shared libraries crash when
compiled with it.

Fix (or workaround) is probably to copy what golang does.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

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

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

--- Comment #21 from Tamar Christina  ---
Created attachment 57932
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57932=edit
loop.c

attached reduced testcase that reproduces the issue and also checks the buffer
position and copied values.

As discussed on IRC when peeling for gaps we need to either adjust the upper
bounds of the vector loop or force the vector loop to get to the scalar loop. 
However we already go to the scalar loop, just with the wrong induction value
because we were never supposed to take the main exit.

whether go to the scalar loop depends on
x = (((ptr2 - ptr1) - 16) / 16) + 1
x == (((x - 1) >> 2) << 2)

in this case x == 26, so we do go to the scalar code already, but through the
main exit.

exiting through the main exit assumes you've done all vector iterations, in
this case 6 iterations based on the main exit condition which is first != last.

In this case the inductions values will be set on niters_vector_mult.

so in this case first += 24

But that's wrong since the secondary exit has a known iteration count of 9, due
to (buffer_ptr + store_size) <= buffer_end.

Statement (exit)if (ivtmp_21 != 0)
 is executed at most 8 (bounded by 8) + 1 times in loop 1.

So we will always exit through it as 9 < 24.

that means that when we calculate the upper bounds of the vector loop, we must
add a bias so that in this boundary condition that we do an extra partial
vector iteration.

I think the discussion on IRC went off track for a bit and hopefully this
testcase and the explanation above shows that for all early break and all
epilogue peeling reasons, we must bias up for the upper bound to give the
secondary exits a chance to trigger.

So really do think the correct patch is:

diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 4375ebdcb49..0973b952c70 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -12144,6 +12144,9 @@ vect_transform_loop (loop_vec_info loop_vinfo, gimple
*loop_vectorized_call)
  -min_epilogue_iters to remove iterations that cannot be performed
by the vector code.  */
   int bias_for_lowest = 1 - min_epilogue_iters;
+  if (LOOP_VINFO_EARLY_BREAKS (loop_vinfo))
+bias_for_lowest = 1;
+
   int bias_for_assumed = bias_for_lowest;
   int alignment_npeels = LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo);
   if (alignment_npeels && LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo))

for the reasons described above.  There's no way for us to take the main exit,
which signifies (we've reached the end of all iterations we can possibly do as
vector) and get the correct induction values in this case.

[Bug tree-optimization/114678] FAIL: gcc.dg/tree-ssa/range-sincos.c scan-tree-dump-not evrp "link_error" on s390

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Confirmed then. Maybe you should xfail it for s390 for GCC 14 at least and then
unxfail when the patch is committed?

[Bug c++/114694] dependent-name alias type accepted in elaborated type specifier within a template

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug driver/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |driver

--- Comment #16 from Andrew Pinski  ---
(In reply to Thomas Koenig from comment #15)
> > I am suspect we might be able to remove this and it will work but there
> > needs to be a lot of testing on many different targets and such.
> 
> A configure test, maybe?

Considering it is all new (modern) ld that do this and I don't think it would
hurt all others, removing that code might be the best thing really. Plus it is
code that dates from the early 90s so I think it is way out of date really.

[Bug c++/114694] dependent-name alias type accepted in elaborated type specifier within a template

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
PR 21498 is another one in this area.

[Bug fortran/113793] malloc abort on character allocate with source argument

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #57354|0   |1
is obsolete||

--- Comment #3 from anlauf at gcc dot gnu.org ---
Created attachment 57931
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57931=edit
Improved patch

This patch fixes both the scalar and the array variants.
Needs regtesting.

[Bug c++/114694] dependent-name alias type accepted in elaborated type specifier within a template

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> There might be a dup somewhere ...

PR 93816 is definitely related but it is not a dup since that has no dependent
types but it does have templates being involved.

[Bug c++/114694] dependent-name alias type accepted in elaborated type specifier within a template

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #1 from Andrew Pinski  ---
There might be a dup somewhere ...

[Bug ipa/114698] [12/13/14 regression] dcfldd produces wrong sha256 sum on ppc64le and -O3 since r12-5244-g64f3e71c302b4a

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #9 from Peter Bergner  ---
(In reply to Andrew Pinski from comment #6)
> Note this implementation of sha2.c is shared all over the place it seems and
> has this known issue ...

Confirmed that the patch fixes the error.  It's too bad the "fix" hasn't been
as widely shared. :-(

Closing this as INVALID.

[Bug ipa/114698] [12/13/14 regression] dcfldd produces wrong sha256 sum on ppc64le and -O3 since r12-5244-g64f3e71c302b4a

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

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

--- Comment #8 from Peter Bergner  ---
(In reply to Andrew Pinski from comment #6)
> Note this implementation of sha2.c is shared all over the place it seems and
> has this known issue ...

(In reply to Andrew Pinski from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > uint8_t buffer[SHA256_BLOCK_LENGTH];
> > 
> > W256 = (sha2_word32*)context->buffer;
> > 
> > This is starting to smell like the code is violating strict aliasing rules
> > ...
> 
> The patch in  https://github.com/NetBSD/pkgsrc/issues/122  applies directly
> here too.

Thanks for the pointer, I'll try the patch and report back.  Jan's commit does
seem to make a change in the alias handling, so it very well could have exposed
that type of problem in the sha2 routine.

[Bug ipa/114698] [12/13/14 regression] dcfldd produces wrong sha256 sum on ppc64le and -O3 since r12-5244-g64f3e71c302b4a

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

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

--- Comment #7 from Andrew Pinski  ---
See https://github.com/archiecobbs/libnbcompat/issues/4 for the full analysis
of the issue with sha2.c and even mentions it is shared with many projects.

[Bug ipa/114698] [12/13/14 regression] dcfldd produces wrong sha256 sum on ppc64le and -O3 since r12-5244-g64f3e71c302b4a

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

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

--- Comment #6 from Andrew Pinski  ---
Note this implementation of sha2.c is shared all over the place it seems and
has this known issue ...

[Bug ipa/114698] [12/13/14 regression] dcfldd produces wrong sha256 sum on ppc64le and -O3 since r12-5244-g64f3e71c302b4a

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

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

--- Comment #5 from Andrew Pinski  ---
Specifically
https://github.com/archiecobbs/libnbcompat/commit/864c1cf42c2c605636008626f171caf6410421cb
.

[Bug ipa/114698] [12/13/14 regression] dcfldd produces wrong sha256 sum on ppc64le and -O3 since r12-5244-g64f3e71c302b4a

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> uint8_t buffer[SHA256_BLOCK_LENGTH];
> 
> W256 = (sha2_word32*)context->buffer;
> 
> This is starting to smell like the code is violating strict aliasing rules
> ...

The patch in  https://github.com/NetBSD/pkgsrc/issues/122  applies directly
here too.

[Bug ipa/114698] [12/13/14 regression] dcfldd produces wrong sha256 sum on ppc64le and -O3 since r12-5244-g64f3e71c302b4a

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

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

--- Comment #3 from Andrew Pinski  ---
uint8_t buffer[SHA256_BLOCK_LENGTH];

W256 = (sha2_word32*)context->buffer;

This is starting to smell like the code is violating strict aliasing rules ...

[Bug ipa/114698] dcfldd produces wrong sha256 sum on ppc64le and -O3

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

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

Peter Bergner  changed:

   What|Removed |Added

  Component|target  |ipa
 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Peter Bergner  ---
I've confirmed that the function being miscompiled is
src/sha2.c:SHA256_Transform() on line 440.  I can add configure dcfldd with a
normal -O2 and add a __attribute__((optimize (3))) to this function and I see
bad output.  I can also configure dcfldd with -O3 and add a
__attribute__((optimize (2))) to this function and I see good output.


Doing a git bisect, it identified the following GCC commit as causing the bug:

64f3e71c302b4a13e61656ee509e7050b9bce978 is the first bad commit
commit 64f3e71c302b4a13e61656ee509e7050b9bce978
Author: Jan Hubicka 
Date:   Sun Nov 14 18:49:15 2021 +0100

Extend modref to track kills

This patch adds kill tracking to ipa-modref.  This is representd by array
of accesses to memory locations that are known to be overwritten by the
function.

gcc/ChangeLog:

2021-11-14  Jan Hubicka  

* ipa-modref-tree.c (modref_access_node::update_for_kills): New
member function.
(modref_access_node::merge_for_kills): Likewise.
(modref_access_node::insert_kill): Likewise.
* ipa-modref-tree.h (modref_access_node::update_for_kills,
modref_access_node::merge_for_kills,
modref_access_node::insert_kill):
Declare.
(modref_access_node::useful_for_kill): New member function.
* ipa-modref.c (modref_summary::useful_p): Release useless kills.
(lto_modref_summary): Add kills.
(modref_summary::dump): Dump kills.
(record_access): Add mdoref_access_node parameter.
(record_access_lto): Likewise.
(merge_call_side_effects): Merge kills.
(analyze_call): Add ALWAYS_EXECUTED param and pass it around.
(struct summary_ptrs): Add always_executed filed.
(analyze_load): Update.
(analyze_store): Update; record kills.
(analyze_stmt): Add always_executed; record kills in clobbers.
(analyze_function): Track always_executed.
(modref_summaries::duplicate): Duplicate kills.
(update_signature): Release kills.
* ipa-modref.h (struct modref_summary): Add kills.
* tree-ssa-alias.c (alias_stats): Add kill stats.
(dump_alias_stats): Dump kill stats.
(store_kills_ref_p): Break out from ...
(stmt_kills_ref_p): Use it; handle modref info based kills.

gcc/testsuite/ChangeLog:

2021-11-14  Jan Hubicka  

* gcc.dg/tree-ssa/modref-dse-3.c: New test.

 gcc/ipa-modref-tree.c| 179 +++
 gcc/ipa-modref-tree.h|  15 ++
 gcc/ipa-modref.c | 126 +---
 gcc/ipa-modref.h |   1 +
 gcc/testsuite/gcc.dg/tree-ssa/modref-dse-3.c |  22 +++
 gcc/tree-ssa-alias.c | 207 +++
 6 files changed, 471 insertions(+), 79 deletions(-)

[Bug c++/94404] [meta-bug] C++ core issues

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

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

Bug 110216 Summary: tuple_size requirements for structured binding has not been 
updated after DR 2386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110216

   What|Removed |Added

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

[Bug c++/110216] tuple_size requirements for structured binding has not been updated after DR 2386

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Seems to be fixed; I'm updating cxx-dr-status.html.

[Bug target/114698] dcfldd produces wrong sha256 sum on ppc64le and -O3

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

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

Peter Bergner  changed:

   What|Removed |Added

  Known to work||11.0
 CC||dje at gcc dot gnu.org,
   ||linkw at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
 Target||powerpc64le-linux
   Last reconfirmed||2024-04-11
  Known to fail||12.0, 13.0, 14.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||wrong-code

--- Comment #1 from Peter Bergner  ---
Confirmed.

[Bug target/114698] New: dcfldd produces wrong sha256 sum on ppc64le and -O3

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

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

Bug ID: 114698
   Summary: dcfldd produces wrong sha256 sum on ppc64le and -O3
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

Building the dcfldd v1.9.1 package on powerpc64le-linux when configured to use
-O3 produces an incorrect sha256 sum for GCC trunk, 13 and 12.  GCC 11 and
earlier produces correct output.  For example (-O3 trunk build):

bergner@ltcden2-lp1:dcfldd [v1.9.1]$ echo TestInput | ./src/dcfldd hash=sha256
TestInput

Total (sha256):
d627605bdee37e388a5c232dc407cb5cd287d27187d6787999ad3bb59d383e9a

0+1 records in
0+1 records out

...versus expected output from an -O2 trunk build:

bergner@ltcden2-lp1:dcfldd [v1.9.1]$ echo TestInput | ./src/dcfldd hash=sha256
TestInput

Total (sha256):
8021973df8498a650e444fd84c705d9168639a246bc6024066e4091b2b450da6

0+1 records in
0+1 records out

...and from sha256sum:

bergner@ltcden2-lp1:dcfldd-git [v1.9.1]$ echo TestInput | /usr/bin/sha256sum 
8021973df8498a650e444fd84c705d9168639a246bc6024066e4091b2b450da6  -


Current steps to recreate:

git clone https://github.com/resurrecting-open-source-projects/dcfldd.git
cd dcfldd/
git checkout v1.9.1 -b v1.9.1
./autogen.sh
./configure CFLAGS="-O3"
make
echo TestInput | ./src/dcfldd hash=sha256

[Bug c++/114697] New: [DR 233] references in user defined conversions

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

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

Bug ID: 114697
   Summary: [DR 233] references in user defined conversions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This should compile:

```
  struct Z {};

  struct A {
operator Z&();  // #1
operator const Z&();
  };

  struct B {
operator Z();   // #2
operator const Z&&();
  };

  const Z& r1 = A();  // OK, uses #1
  const Z&& r2 = B(); // OK, uses #2
```

but we reject it with:

cwg233.C:13:15: error: conversion from ‘A’ to ‘const Z&’ is ambiguous
   13 | const Z& r1 = A();  // OK, uses #1
  |   ^~~
cwg233.C:4:3: note: candidate: ‘A::operator Z&()’
4 |   operator Z&();  // #1
  |   ^~~~
cwg233.C:5:3: note: candidate: ‘A::operator const Z&()’
5 |   operator const Z&();
  |   ^~~~

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

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

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

--- Comment #24 from Andrew Pinski  ---
(In reply to Richard Earnshaw from comment #21)
> With my new testcase, compiled on an arm-none-eabi cross with 
> 
> cc1plus ../hwy-pr111231-cpp.cc -mfpu=neon-vfpv4 -mfloat-abi=hard
> -mfp16-format=ieee -marm -mlibarch=armv7-a+neon-vfpv4
> -march=armv7-a+neon-vfpv4 -O2 -fPIE -fvisibility=hidden
> -fvisibility-inlines-hidden -fmerge-all-constants -fmath-errno
> -fno-exceptions
> 
> The critical sequence, at the end of gimple optimization is:
> 
>   v = b;
>   MEM  [(char * {ref-all})] = MEM  char[16]> [(char * {ref-all})];
>   v ={v} {CLOBBER(eol)};
>   v = D.33805;
>   vect__239.652_700 = MEM  [(short int *)];
>   vect__240.653_702 = vect__239.652_700 << 8;
> 
> This generates the following (pseudo) rtl:
> 
> ; D.33805 = _179
>   113: r215:SI=r109:SI-0x10
>   114: {r0:SI..r3:SI} = [r215:SI (0 MEM  [(char *
> {ref-all})_179]+0 S4 A64)]
>   112: r214:SI=r109:SI-0x60
>   115: [r214:SI (0 MEM  [(char * {ref-all})]+0 S4
> A64)] = {r0:SI..r3:SI}
> ; _179 = D.33805
>   117: r217:SI=r109:SI-0x60
>   118: {r0:SI..r3:SI} = [r217:SI (2 D.33805+0 S4 A64)]
>   116: r216:SI=r109:SI-0x10
> * 119: [r216:SI (2 MEM[(struct Vec128 *)_179]+0 S4 A64)] =
> {r0:SI..r3:SI}
> ; r218 = _179
> * 120: r218:V8HI=[r109:SI-0x10 (3 MEM  [(short int
> *)_179]+0 S16 A64)]
>   121: r178:V8HI=unspec[r218:V8HI,const_vector] 451
> 
> The two key instructions have been starred. 
> 
> Things proceed OK until sched2, at which point, when building the
> dependencies, we fail to create a link between i119 and i120.  I've tracked
> this as far as ptr_deref_may_alias_decl_p (), where the call to
> may_be_aliased () decides that D.33805 cannot be aliased and thus there's no
> dependency.  But it's not clear to me why we've tracked back to the copy
> before the load of interest, nor why, at this point, we're looking at tree
> addressability to decide whether or not there are memory dependencies here.

This making it sound like one of the -fstack-reuse= issues (see the linked bug
reports from PR 111843). Does -fstack-reuse=none help?

[Bug target/114696] New: ICE: in extract_constrain_insn_cached, at recog.cc:2725 insn does not satisfy its constraints: {*anddi_1} with -mapxf -mx32

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114696
   Summary: ICE: in extract_constrain_insn_cached, at
recog.cc:2725 insn does not satisfy its constraints:
{*anddi_1} with -mapxf -mx32
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -mapxf -mx32 testcase.c 
testcase.c: In function 'foo':
testcase.c:8:1: error: insn does not satisfy its constraints:
8 | }
  | ^
(insn 43 42 44 2 (parallel [
(set (reg:DI 1 dx [+8 ])
(and:DI (mem/c:DI (plus:SI (reg:SI 4 si [110])
(const_int 8 [0x8])) [1 a+8 S8 A64 AS1])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) "testcase.c":7:7 613 {*anddi_1}
 (nil))
during RTL pass: shorten
testcase.c:8:1: internal compiler error: in extract_constrain_insn_cached, at
recog.cc:2725
0x808789 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x808810 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:118
0x7f8fbf extract_constrain_insn_cached(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2725
0x1dce737 get_attr_modrm(rtx_insn*)
/repo/gcc-trunk/gcc/config/i386/i386.md:759
0x1dd2bb7 insn_default_length(rtx_insn*)
/repo/gcc-trunk/gcc/config/i386/i386.md:785
0x10e00ee shorten_branches(rtx_insn*)
/repo/gcc-trunk/gcc/final.cc:1089
0x10e022f rest_of_handle_shorten_branches
/repo/gcc-trunk/gcc/final.cc:4335
0x10e022f execute
/repo/gcc-trunk/gcc/final.cc:4364
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


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

[Bug fortran/103471] [11/12/13/14 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114

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

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #6 from Paul Thomas  ---
The current mainline and 13-branches now power through to the fatal error at
trans-decl.cc:1800.

Paul

[Bug target/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc

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

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

--- Comment #15 from Thomas Koenig  ---
(In reply to Andrew Pinski from comment #14)
> (In reply to Jonathan Wakely from comment #10)
> > If --with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld is required then
> > it needs to be documented at
> > https://gcc.gnu.org/install/specific.html#x-x-freebsd
> 
> So what I think is happening is the ld (LLVM's lld) does not include
> /usr/lib by default in the library search path and gcc's driver does not
> pass -L/usr/lib -L/lib on to ld because it assumes all ld normally search
> there by default (which most unix ld did before lld and mold come around).
>

[...]

> I am suspect we might be able to remove this and it will work but there
> needs to be a lot of testing on many different targets and such.

A configure test, maybe?

[Bug c++/114695] New: Template argument deduction and defaulted template template parameters

[vin.piquet at gmail dot com via Gcc-bugs]

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

Bug ID: 114695
   Summary: Template argument deduction and defaulted template
template parameters
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vin.piquet at gmail dot com
  Target Milestone: ---

 test.cpp 
template  struct Bar {
void accept(X value) { }
};

template  struct Foo;

template 
struct Foo...> : Bar... {
template  typename B = Bar>
constexpr static B* slice_by_type(B* self) {
return self;
}

template 
void accept(Us... values) {
(slice_by_type(this)->accept(values), ...);
}
};

int main() {
Foo, Bar<1, int>> foo;
foo.accept(3.14f, 10);
}
 test.cpp 

GCC rejects this code with the following error

 console output for GCC 13.2 
test.cpp: In instantiation of 'void Foo...>::accept(Us ...) [with
Us = {float, int}; int ...Is = {0, 1}; Ts = {float, int}]':
test.cpp:22:15:   required from here
test.cpp:16:27: error: no matching function for call to 'Foo,
Bar<1, int> >::slice_by_type(Foo, Bar<1, int> >*)'
   16 | (slice_by_type(this)->accept(values), ...);
  |  ~^~
test.cpp:10:31: note: candidate: 'template, class> class B> static constexpr B* Foo...>::slice_by_type(B*) [with int I = T; B = I; int ...Is = {0, 1}; Ts
= {float, int}]'
   10 | constexpr static B* slice_by_type(B* self) {
  |   ^
test.cpp:10:31: note:   template argument deduction/substitution failed:
test.cpp:16:27: note:   'B' is an ambiguous base class of 'Foo, Bar<1, int> >'
   16 | (slice_by_type(this)->accept(values), ...);
  |  ~^~

This appears to be a consequence of GCC matching T to I somehow and getting
confused. I can't really tell what's going on here, except that the fact GCC
seems to not deduce I = 0 supposedly because B is not deduced to Bar<0,
float>.

Interestingly, GCC 6.3 also rejects this code, with a somewhat more clear
error:

 Console output for GCC 6.3 
test.cpp: In instantiation of 'void Foo...>::accept(Us ...) [with
Us = {float, int}; int ...Is = {0, 1}; Ts = {float, int}]':
:22:25:   required from here
:16:27: error: no matching function for call to 'Foo,
Bar<1, int> >::slice_by_type(Foo, Bar<1, int> >*)'
 (slice_by_type(this)->accept(values), ...);
  ~^~
test.cpp:10:31: note: candidate: template, class> class B> static constexpr B* Foo...>::slice_by_type(B*) [with T = T; int I = I; B = B; int ...Is = {0,
1}; Ts = {float, int}]
 constexpr static B* slice_by_type(B* self) {
   ^
test.cpp:10:31: note:   template argument deduction/substitution failed:
test.cpp:16:27: error: type/value mismatch at argument 1 in template parameter
list for 'template, class> class B'
 (slice_by_type(this)->accept(values), ...);
  ~^~
test.cpp:16:27: note:   expected a constant of type 'int', got 'Bar<0, float>'
 Console output for GCC 6.3 

MSVC accepts this code in C++20 but rejects it in C++17 with a similar error;
Clang accepts this code on both versions since Clang 5.0.0

Relevant godbolt link: https:~~godbolt.org~z~48zs7KnTo (replace tildes)

 Compiler version 
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-linux-gnu/13/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 13.2.0-4ubuntu3'
--with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release
--build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (Ubuntu 13.2.0-4ubuntu3)
 Compiler version ===

Thank you :)

[Bug c++/90390] [CWG1996] incorrect list initialization behavior for references

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

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

Jason Merrill  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
Summary|incorrect list  |[CWG1996] incorrect list
   |initialization behavior for |initialization behavior for
   |references  |references
 CC||jason at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #3 from Jason Merrill  ---
This is https://wg21.link/cwg1996 ; I think this is a defect in the standard.

[Bug target/114676] [12/13/14 Regression] DSE removes assignment that is used later

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

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

--- Comment #11 from Andreas Krebbel  ---
The documentation of vec_xl and vec_xst doesn't seem to mention anything
special with regard to that. So I understand the memory is only accessed
through pointers which are compatible to the ones used when invoking the
builtin.

That particular usage within pytorch looks ok to me.

I'm already testing a patch which matches what you are proposing. I hope to be
able to reduce the testcase somewhat.

Thanks for your help!

[Bug sanitizer/114687] [13/14 Regression] ICE: in edge_before_returns_twice_call, at gimple-iterator.cc:981

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 57929
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57929=edit
gcc14-pr114687.patch

Untested fix.  The tree-cfg.cc verification that ECF_RETURNS_TWICE call is
the first in bb appart from labels/debug stmts is keyed on it appearing in a bb
which has abnormal predecessor, this patch guards the code that attempts to
maintain that invariant on the same condition.

[Bug fortran/105168] [11/12/13/14 Regression] ICE in gfc_maybe_dereference_var, at fortran/trans-expr.cc:2870 since r9-3522-gd0477233215e37de

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

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #6 from Paul Thomas  ---
(In reply to Martin Liška from comment #2)
> Started with r9-3522-gd0477233215e37de.

Hi Martin,

Reverting this patch has no effect on the ICE.

Regards

Paul

[Bug c++/114625] requires { T{}; } wrongly returns false when T{} is ill-formed while in concept

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Thanks.  Probably GCC 15 work.

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

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

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

--- Comment #23 from Richard Earnshaw  ---
#0  ptr_deref_may_alias_decl_p (ptr=0x75e0c678, decl=0x75dff000)
at /home/rearnsha/gnusrc/gcc-cross/gcc-13/gcc/tree-ssa-alias.cc:295
#1  0x01768173 in indirect_ref_may_alias_decl_p (ref1=0x75e9ad98, 
base1=0x75e9ad98, offset1=..., max_size1=..., size1=..., 
ref1_alias_set=3, base1_alias_set=3, ref2=0x75deae60, 
base2=0x75dff000, offset2=..., max_size2=..., size2=..., 
ref2_alias_set=0, base2_alias_set=0, tbaa_p=false)
at /home/rearnsha/gnusrc/gcc-cross/gcc-13/gcc/tree-ssa-alias.cc:2102
#2  0x01769541 in refs_may_alias_p_2 (ref1=0x7fffceb0, 
ref2=0x7fffce70, tbaa_p=false)
at /home/rearnsha/gnusrc/gcc-cross/gcc-13/gcc/tree-ssa-alias.cc:2505
#3  0x0176968a in refs_may_alias_p_1 (ref1=0x7fffce70, 
ref2=0x7fffceb0, tbaa_p=false)
at /home/rearnsha/gnusrc/gcc-cross/gcc-13/gcc/tree-ssa-alias.cc:2534
#4  0x00f7bf7d in rtx_refs_may_alias_p (x=0x75ed3b40, 
mem=0x75e9c9d8, tbaa_p=true)
at /home/rearnsha/gnusrc/gcc-cross/gcc-13/gcc/alias.cc:366
#5  0x00f8243b in true_dependence_1 (mem=0x75e9c9d8, 
mem_mode=E_SImode, mem_addr=0x75e9c9c0, x=0x75ed3b40, 
x_addr=0x75ed3b28, mem_canonicalized=false)

Where (in true_dependence_1):
p mem
$96 = (const_rtx) 0x75e9c9d8
(gdb) pr
(mem/c:SI (plus:SI (reg/f:SI 14 lr [214])
(const_int 4 [0x4])) [0 MEM  [(char *
{ref-all})]+4 S4 A32])

p x
$97 = (const_rtx) 0x75ed3b40
(gdb) pr
(mem/c:V8HI (plus:SI (reg/f:SI 13 sp)
(const_int 256 [0x100])) [3 MEM  [(short int
*)_179]+0 S16 A64])

in refs_may_alias_p_1:
p *ref1
$99 = {ref = 0x75e9ad98, base = 0x75e9ad98, 
  offset = {> = {coeffs = {0}}, }, 
  size = {> = {coeffs = {128}}, }, 
  max_size = {> = {coeffs = {128}}, }, 
  ref_alias_set = 3, base_alias_set = 3, volatile_p = false}
p *ref2
$100 = {ref = 0x75deae60, base = 0x75dff000, 
  offset = {> = {coeffs = {32}}, }, 
  size = {> = {coeffs = {32}}, }, 
  max_size = {> = {coeffs = {128}}, }, 
  ref_alias_set = 0, base_alias_set = 0, volatile_p = false}

p ref1->ref
$101 = (tree) 0x75e9ad98
(gdb) pt
 
unit-size 
align:16 warn_if_not_align:0 symtab:0 alias-set 3 canonical-type
0x77405498 precision:16 min  max

pointer_to_this  reference_to_this
>
V8HI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set 3 canonical-type
0x7752d7e0 nunits:8
pointer_to_this >

arg:0 
sizes-gimplified public unsigned type_6 SI
size 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set 12 canonical-type
0x7740c150
pointer_to_this  reference_to_this
>
var 
def_stmt 
version:179
ptr-info 0x75e71468>
arg:1 
constant 0>>

p ref1->base
$102 = (tree) 0x75e9ad98
(gdb) pt
 
unit-size 
align:16 warn_if_not_align:0 symtab:0 alias-set 3 canonical-type
0x77405498 precision:16 min  max

pointer_to_this  reference_to_this
>
V8HI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set 3 canonical-type
0x7752d7e0 nunits:8
pointer_to_this >

arg:0 
sizes-gimplified public unsigned type_6 SI
size 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set 12 canonical-type
0x7740c150
pointer_to_this  reference_to_this
>
var 
def_stmt 
version:179
ptr-info 0x75e71468>
arg:1 
constant 0>>

p ref2->ref
$103 = (tree) 0x75deae60
(gdb) pt
 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x77405348 precision:8 min  max >
BLK
size 
unit-size 
user align:16 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76322d20
domain 
sizes-gimplified public type_6 SI
size 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76b33d20 precision:32 min  max >
pointer_to_this >

arg:0 
public unsigned SI size  unit-size

align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x766db5e8>

arg:0 
used ignored BLK ../hwy-pr111231-cpp.cc:4461:27 size  unit-size 
align:64 warn_if_not_align:0 context  abstract_origin 
(mem/c:BLK (plus:SI (reg/f:SI 109 virtual-stack-vars)
(const_int -96 [0xffa0])) [2 D.33805+0 S16 A64])>
../hwy-pr111231-cpp.cc:4346:16 start: ../hwy-pr111231-cpp.cc:4346:3
finish: ../hwy-pr111231-cpp.cc:4346:24>
arg:1 
constant 0>>
p ref2->base
$104 = (tree) 0x75dff000
(gdb) pt
 
unit-size 
align:16 

[Bug target/114059] ICE in extract_insn, at recog.cc:2812 | sme2 vs -fsanitize=address -mtrack-speculation -fharden-control-flow-redundancy

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

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

Filip Kastl  changed:

   What|Removed |Added

 CC||pheeck at gcc dot gnu.org

--- Comment #2 from Filip Kastl  ---
I've just seen this ICE triggered also with -mtrack-speculation
-fharden-control-flow-redundancy -fnon-call-exceptions (also on sibcall_9.c).

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

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

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

--- Comment #22 from Richard Earnshaw  ---
(Previous analysis is based on gcc-13 branch)

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

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

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

Richard Earnshaw  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #21 from Richard Earnshaw  ---
With my new testcase, compiled on an arm-none-eabi cross with 

cc1plus ../hwy-pr111231-cpp.cc -mfpu=neon-vfpv4 -mfloat-abi=hard
-mfp16-format=ieee -marm -mlibarch=armv7-a+neon-vfpv4 -march=armv7-a+neon-vfpv4
-O2 -fPIE -fvisibility=hidden -fvisibility-inlines-hidden -fmerge-all-constants
-fmath-errno -fno-exceptions

The critical sequence, at the end of gimple optimization is:

  v = b;
  MEM  [(char * {ref-all})] = MEM  [(char * {ref-all})];
  v ={v} {CLOBBER(eol)};
  v = D.33805;
  vect__239.652_700 = MEM  [(short int *)];
  vect__240.653_702 = vect__239.652_700 << 8;

This generates the following (pseudo) rtl:

; D.33805 = _179
  113: r215:SI=r109:SI-0x10
  114: {r0:SI..r3:SI} = [r215:SI (0 MEM  [(char *
{ref-all})_179]+0 S4 A64)]
  112: r214:SI=r109:SI-0x60
  115: [r214:SI (0 MEM  [(char * {ref-all})]+0 S4
A64)] = {r0:SI..r3:SI}
; _179 = D.33805
  117: r217:SI=r109:SI-0x60
  118: {r0:SI..r3:SI} = [r217:SI (2 D.33805+0 S4 A64)]
  116: r216:SI=r109:SI-0x10
* 119: [r216:SI (2 MEM[(struct Vec128 *)_179]+0 S4 A64)] =
{r0:SI..r3:SI}
; r218 = _179
* 120: r218:V8HI=[r109:SI-0x10 (3 MEM  [(short int
*)_179]+0 S16 A64)]
  121: r178:V8HI=unspec[r218:V8HI,const_vector] 451

The two key instructions have been starred. 

Things proceed OK until sched2, at which point, when building the dependencies,
we fail to create a link between i119 and i120.  I've tracked this as far as
ptr_deref_may_alias_decl_p (), where the call to may_be_aliased () decides that
D.33805 cannot be aliased and thus there's no dependency.  But it's not clear
to me why we've tracked back to the copy before the load of interest, nor why,
at this point, we're looking at tree addressability to decide whether or not
there are memory dependencies here.

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #11 from Jonathan Wakely  ---
Fixed

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

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

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

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

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

commit r14-9917-g1defe743aeb19532f6d6f4cab37e10f11467abd8
Author: Jonathan Wakely 
Date:   Thu Apr 11 12:28:25 2024 +0100

libstdc++: Export std::__basic_file::native_handle as GLIBCXX_3.4.33
[PR114692]

I added this new symbol in the wrong version. GLIBCXX_3.4.32 was
already used for the GCC 13.2.0 release, so the new symbol should have
been in a new GLIBCXX_3.4.33 version.

Additionally, the pattern doesn't need to use [cw] because we only ever
use __basic_file, even for std::basic_filebuf.

libstdc++-v3/ChangeLog:

PR libstdc++/114692
* config/abi/pre/gnu.ver (GLIBCXX_3.4.32): Move new exports for
__basic_file::native_handle to ...
(GLIBCXX_3.4.33): ... here. Adjust to not match wchar_t
specialization, which isn't used.
* testsuite/util/testsuite_abi.cc: Add GLIBCXX_3.4.33 and update
latest version check.

[Bug c++/114694] New: dependent-name alias type accepted in elaborated type specifier within a template

[ing.russomauro at gmail dot com via Gcc-bugs]

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

Bug ID: 114694
   Summary: dependent-name alias type accepted in elaborated type
specifier within a template
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ing.russomauro at gmail dot com
  Target Milestone: ---

Here below you may find an example with a class named D, defining a nested
alias type which, in turn, is referred by an elaborated type specifier within a
function template f() instantiated with template type parameter equal to D.
The same with a class E where 'using' syntax is used.
In both cases, the alias-id is accepted.
The non-dependent alias-id ('Alias') is correctly refused.

The standard reads "If a typedef-name is used to identify the subject of an
elaborated-type-specifier ..., the program is ill-formed."

I see old tickets about elaborated-type-specifiers, as 11036, and 87781, and a
single open ticket 55809, but none of them seem related to the context of a
dependent-name alias within a template.


class C{public: void f(){};};

using Alias = C;

struct D
{
typedef C Alias2;
};

struct E
{
using Alias2 = C;
};

template
void f()
{
//struct Alias x; -> error, as 'Alias' is an alias type
struct T::Alias2 y; // WEIRDLY, no error here, despite 'Alias2' is
 // an alias type when instantiated with either T=D or
T=E.
y.f(); // avoids warning for unused variable
typename T::Alias2 z; // ok no error with typename
z.f(); // avoids warning for unused variable
}

void foo()
{
//struct Alias a; -> error, as 'Alias' is an alias type
//struct D::Alias2 a2; -> error, as 'D::Alias2' is an alias type

f();
f();
}

int main(){
foo();
}

[Bug c++/114303] [11/12/13/14 Regression] ICE with constexpr if and accessing captures across nested generic lambdas

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r14-9916-gb262b17636e47ae969a74f16e86ccb00678d5e88
Author: Patrick Palka 
Date:   Thu Apr 11 10:16:41 2024 -0400

c++: build_extra_args recapturing local specs [PR114303]

r13-6452-g341e6cd8d603a3 made build_extra_args walk evaluated contexts
first so that we prefer processing a local specialization in an evaluated
context even if its first use is in an unevaluated context.  But this
means we need to avoid walking a tree that already has extra args/specs
saved because the list of saved specs appears to be an evaluated
context which we'll now walk first.  It seems then that we should be
calculating the saved specs from scratch each time, rather than
potentially walking the saved specs list from an earlier partial
instantiation when calling build_extra_args a second time around.

PR c++/114303

gcc/cp/ChangeLog:

* constraint.cc (tsubst_requires_expr): Clear
REQUIRES_EXPR_EXTRA_ARGS before calling build_extra_args.
* pt.cc (tree_extra_args): Define.
(extract_locals_r): Assert *_EXTRA_ARGS is empty.
(tsubst_stmt) : Clear IF_SCOPE on the new
IF_STMT.  Call build_extra_args on the new IF_STMT instead
of t which might already have IF_STMT_EXTRA_ARGS.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/constexpr-if-lambda6.C: New test.

Reviewed-by: Jason Merrill 

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

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

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

--- Comment #20 from Richard Earnshaw  ---
Created attachment 57928
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57928=edit
fully preprocessed testcase

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

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

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

--- Comment #9 from Jonathan Wakely  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649260.html

[Bug c++/114685] [modules] ICE when exporting a type through a different alias then one declared in GMF

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

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

Nathaniel Shead  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=114683
 Status|UNCONFIRMED |NEW
 CC||nshead at gcc dot gnu.org
   Last reconfirmed||2024-04-11
 Ever confirmed|0   |1

--- Comment #2 from Nathaniel Shead  ---
This fails on

  if (data->hash->add_namespace_entities (decl, data->partitions))
{
  /* It contains an exported thing, so it is exported.  */
  gcc_checking_assert (DECL_MODULE_PURVIEW_P (decl));
  DECL_MODULE_EXPORT_P (decl) = true;
}

ultimately for a very similar reason to PR114683: non-functions brought in by
using-decls currently just bind the value directly which means that there's
nothing to indicate that they should be exported from this scope (and not their
original one).

I've been playing around with making use of the existing STAT_HACK machinery to
try to get this working, but it looks like we'll probably need to overhaul a
fair chunk of the name lookup code to handle this correctly.

[Bug tree-optimization/114678] FAIL: gcc.dg/tree-ssa/range-sincos.c scan-tree-dump-not evrp "link_error" on s390

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

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

--- Comment #3 from Stefan Schulze Frielinghaus  
---
Thanks for the pointer.  I can confirm that the patch fixes this PR and also
fixes

FAIL: gcc.dg/tree-ssa/vrp-float-abs-1.c scan-tree-dump-not evrp "link_error"

[Bug sanitizer/114687] [13/14 Regression] ICE: in edge_before_returns_twice_call, at gimple-iterator.cc:981

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

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

--- Comment #2 from Jakub Jelinek  ---
Saying a function is valid code in this case is difficult, claiming that a
noreturn function is pure or returns_twice is wrong, it isn't pure, nor
returns_twice, as it never returns.

[Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point

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

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

--- Comment #16 from Michael Matz  ---
(In reply to Kewen Lin from comment #15)
> I agree, thanks for the comments! btw, I'm not fighting for the current
> implementation, just want to know more details why users are unable to make
> use of the current implementation, is it just due to its inefficiency (like
> the above sequence) or un-usability (unused at all). As your comments, I
> think it's due to the former (inefficiency)?!

Okay.  So, yeah, I _think_ that other way (with NOPs between GEP and LEP,
plus a jump around them) could be made to work with userspace live patching.
It would just be inefficient.  But do note that that jump around was _not_
part of the original way of -fpatchable-function-entry, so a change to codegen
would have to have happened anyway to make that other way usable.  And it has
the
(perhaps theoretical, who knows :) ) problem of not using the normal 8-byte
difference between GEP and LEP.

I think your current proposal from comment #10 is the better from all
perspectives.

[Bug target/114676] [12/13/14 Regression] DSE removes assignment that is used later

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

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

--- Comment #10 from Jakub Jelinek  ---
I admit I haven't studied what exactly pytorch does there.

[Bug target/114676] [12/13/14 Regression] DSE removes assignment that is used later

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

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

--- Comment #9 from Jakub Jelinek  ---
It depends on what the vec_xl*/vec_xst* documentation requires/user expect.
If the expectation is that the loads/stores should alias the scalar pointee of
the pointer type passed to those intrinsics, then
--- gcc/config/s390/s390-c.cc.jj2024-01-03 11:51:54.847407588 +0100
+++ gcc/config/s390/s390-c.cc   2024-04-10 16:30:31.896197832 +0200
@@ -498,8 +498,8 @@ s390_expand_overloaded_builtin (location
/* Build a vector type with the alignment of the source
   location in order to enable correct alignment hints to be
   generated for vl.  */
-   tree mem_type = build_aligned_type (return_type,
-   TYPE_ALIGN (TREE_TYPE (TREE_TYPE
((*arglist)[1];
+   unsigned align = TYPE_ALIGN (TREE_TYPE (TREE_TYPE ((*arglist)[1])));
+   tree mem_type = build_aligned_type (return_type, align);
return build2 (MEM_REF, mem_type,
   fold_build_pointer_plus ((*arglist)[1], (*arglist)[0]),
   build_int_cst (TREE_TYPE ((*arglist)[1]), 0));
@@ -511,11 +511,13 @@ s390_expand_overloaded_builtin (location
/* Build a vector type with the alignment of the target
   location in order to enable correct alignment hints to be
   generated for vst.  */
-   tree mem_type = build_aligned_type (TREE_TYPE((*arglist)[0]),
-   TYPE_ALIGN (TREE_TYPE (TREE_TYPE
((*arglist)[2];
+   unsigned align = TYPE_ALIGN (TREE_TYPE (TREE_TYPE ((*arglist)[2])));
+   tree mem_type = build_aligned_type (TREE_TYPE ((*arglist)[0]), align);
return build2 (MODIFY_EXPR, mem_type,
-  build1 (INDIRECT_REF, mem_type,
-  fold_build_pointer_plus ((*arglist)[2],
(*arglist)[1])),
+  build2 (MEM_REF, mem_type,
+  fold_build_pointer_plus ((*arglist)[2],
+   (*arglist)[1]),
+  build_int_cst (TREE_TYPE ((*arglist)[2]), 0)),
   (*arglist)[0]);
   }
 case S390_OVERLOADED_BUILTIN_s390_vec_load_pair:
might be all that is needed (if it is needed at all).
If the expectation is that one can read what has been written by those
intrinsics or write
what will be read by those intrinsics though unrelated effective pointers, then
it should alias everything,
which could be say just using ptr_type_node instead of the current types in
both of the build_int_cst (..., 0) calls above.

[Bug target/114676] [12/13/14 Regression] DSE removes assignment that is used later

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

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

--- Comment #8 from Andreas Krebbel  ---
Apparently, I decided to go with a MEM_REF already for the load variant of the
builtin - vec_xl. I've to check whether there was any reason not to do this
also for vec_xst.

Making it a pointer which aliases everything might be too big of a hammer I
guess?!

[Bug target/114693] `expand` introduce redundant store facing logic expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 Resolution|--- |FIXED
   Keywords||missed-optimization
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Andrew Pinski  ---
Actually this is fixed on the trunk.

This is what we got in GCC 13 and before:
  g.0_1 = g;
  _2 = (_Bool) g.0_1;
  _3 = (char) _2;
  s.f0 = _3;


But in GCC 14+ we get:
  g.0_1 = g;
  _2 = g.0_1 & 1;
  _3 = (char) _2;
  s.f0 = _3;


This was fixed by r14-6420-g85c5efcffed19c .

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

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

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to Jonathan Wakely from comment #4)
> > This were added by r13-7320-g0d5a359140503d which is in 13.2 :-(
> 
> Oops, guess too late then for those.  We'll need to consider 13.2 as a fuzzy
> snapshot in between 13.1 and 13.3 then

GCC 13.1 was April 26th and didn't contain any GLIBCXX_3.4.32 I think;
then I've committed r13-7287 on April 28th, which added
_ZSt21ios_base_library_initv,
that was intentionally in a symver shared both by 13.2 and 14.1
then you've committed r13-7320 backport which added those 2 _S_allocate symbols
(with 3 size_t variants); and then 13.2 released on July 27th
So, the only bug is the _ZNKSt12__basic_fileI[cw]E13native_handleEv;
Though, surprisingly, the gnu.ver side says both Ic and Iw, while the
baseline_symbols.txt updates clearly indicate that only the Ic version is
exported.

[Bug target/114693] `expand` introduce redundant store facing logic expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64
  Component|rtl-optimization|target

--- Comment #1 from Andrew Pinski  ---
This is a target specific issue on how x86_64 backend patterns are done IIRC.

[Bug rtl-optimization/114693] New: `expand` introduce redundant store facing logic expression

[absoler at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 114693
   Summary: `expand` introduce redundant store facing logic
expression
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: absoler at smail dot nju.edu.cn
  Target Milestone: ---

A simple case, regression from gcc-5
```
struct S{
char  f0;
int  f3;
} s;
int g, f;

void func_1() {
  int a = 0;
  s.f0 = 1 && ((3 > a) & g);
}
```
compiled with -O2 :

```
func_1():
  401340:   mov0x10846(%rip),%eax# 411b8c 
  401346:   mov%al,0x10844(%rip)# 411b90 
  40134c:   andb   $0x1,0x1083d(%rip)# 411b90 
  401353:   retq  
```

it seems "1 && " interfere the compiler, after removing it the compiler
generates:
```
func_1():
  401340:   movzbl 0x10845(%rip),%eax# 411b8c 
  401347:   and$0x1,%eax
  40134a:   mov%al,0x10840(%rip)# 411b90 
  401350:   retq   
```

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

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

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Jonathan Wakely from comment #4)
> This were added by r13-7320-g0d5a359140503d which is in 13.2 :-(

Oops, guess too late then for those.  We'll need to consider 13.2 as a fuzzy
snapshot in between 13.1 and 13.3 then

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

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

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

--- Comment #6 from Jonathan Wakely  ---
r14-739-gc62e945492afbb incorrectly added them to GLIBCXX_3.4.32 which should
have been frozen after 13.1 but it looks like I thought it was a new version
for 13.2/14.0

Then I must have thought 13.2 and 14.0 were both using that new version, they
should both have those new symbols.

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

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

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

--- Comment #5 from Jonathan Wakely  ---
The *shouldn't* have been added there though.

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

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

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

--- Comment #4 from Jonathan Wakely  ---
This were added by r13-7320-g0d5a359140503d which is in 13.2 :-(

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

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

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to Jonathan Wakely from comment #1)
> --- a/libstdc++-v3/config/abi/pre/gnu.ver
> +++ b/libstdc++-v3/config/abi/pre/gnu.ver
> @@ -2521,9 +2521,12 @@ GLIBCXX_3.4.31 {
>  GLIBCXX_3.4.32 {
>  _ZSt21ios_base_library_initv;
> 
> _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE11_S_allocateER
> S3_[jmy];
> +} GLIBCXX_3.4.31;
> +
> +GLIBCXX_3.4.33 {
>  # std::basic_file<>::native_handle()
>  _ZNKSt12__basic_fileI[cw]E13native_handleEv;
> -} GLIBCXX_3.4.31;
> +} GLIBCXX_3.4.32;
>  
>  # Symbols in the support library (libsupc++) have their own tag.
>  CXXABI_1.3 {

_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE11_S_allocateERS3_[jmy];
wasn't in GCC 13.2 either, just _ZSt21ios_base_library_initv;

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

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

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 57927
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57927=edit
gcc14-libstdc++-baseline-updates.patch

This was what I've been preparing before noticing this issue.  If we change
libstdc++, that will need to be regenerated obviously (plus
libstdc++-v3/testsuite/util/testsuite_abi.cc updated of course).

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

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

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

--- Comment #1 from Jonathan Wakely  ---
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -2521,9 +2521,12 @@ GLIBCXX_3.4.31 {
 GLIBCXX_3.4.32 {
 _ZSt21ios_base_library_initv;

_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE11_S_allocateERS3_[jmy];
+} GLIBCXX_3.4.31;
+
+GLIBCXX_3.4.33 {
 # std::basic_file<>::native_handle()
 _ZNKSt12__basic_fileI[cw]E13native_handleEv;
-} GLIBCXX_3.4.31;
+} GLIBCXX_3.4.32;

 # Symbols in the support library (libsupc++) have their own tag.
 CXXABI_1.3 {

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 CC||redi at gcc dot gnu.org
   Priority|P3  |P1
   Keywords||ABI

[Bug libstdc++/114692] New: [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

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

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

Bug ID: 114692
   Summary: [14 Regression] Symbol versioning problem in GCC 14
libstdc++.so.6
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

I was just updating libstdc++ baseline_symbols.txt files from latest Fedora,
but seems we have a major issue.
While the CXXABI_1.3.15 symver is really new in GCC 14 and got one symbol,
I think GCC 13.1 shipped with GLIBCXX_3.4.31 as latest symver, but then we
applied
PR108969 fix for 13.2 and added one symbol to GLIBCXX_3.4.32 -
_ZSt21ios_base_library_initv.
But new symbols for GCC 14 should have been therefore added to GLIBCXX_3.4.33,
but they were actually added to GLIBCXX_3.4.32 which already shipped in GCC
13.2:
_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.32
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_S_allocateERS3_m@@GLIBCXX_3.4.32
_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_S_allocateERS3_m@@GLIBCXX_3.4.32
(or s/m@/j@/ or s/m@/y@/).

[Bug libstdc++/89624] HLE acquire/release bits in std::memory_order don't work with -fshort-enums or -fstrict-enums

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

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

--- Comment #6 from Jonathan Wakely  ---
It's also a mostly-harmless ABI change for C++17 down, because the underlying
type without -fshort-enums changes from implicitly being chosen as unsigned
int, to explicitly being specified as int.

[Bug libstdc++/89624] HLE acquire/release bits in std::memory_order don't work with -fshort-enums or -fstrict-enums

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

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

--- Comment #5 from Jonathan Wakely  ---
I think we should just do this:

--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -77,7 +77,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   inline constexpr memory_order memory_order_acq_rel = memory_order::acq_rel;
   inline constexpr memory_order memory_order_seq_cst = memory_order::seq_cst;
 #else
-  typedef enum memory_order
+  enum memory_order : int
 {
   memory_order_relaxed,
   memory_order_consume,
@@ -85,7 +85,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   memory_order_release,
   memory_order_acq_rel,
   memory_order_seq_cst
-} memory_order;
+};
 #endif

   /// @cond undocumented


That ensures a consistent underlying type for C++17 down and C++20 up (and gets
rid of the redundant typedef). This will mean the type isn't affected by the
-fshort-enums flag at all, which also happens to solve the static_assert
failure in comment 0.

This is an ABI change for the underlying type when using -fshort-enums, but
that flag is already explicitly ABI-changing and not the default, so I care
less about a change there.

[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

[nicolas at debian dot org via Gcc-bugs]

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

Nicolas Boulenguez  changed:

   What|Removed |Added

  Attachment #57890|0   |1
is obsolete||
  Attachment #57897|0   |1
is obsolete||

--- Comment #19 from Nicolas Boulenguez  ---
Created attachment 57926
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57926=edit
eight commits isolating the definition of C time types

This version 5 fixes typos in commit 3 that were breaking the build with 1-3
applied only on x86_64-linux-gnu.
Commit 8 is adapted so that the overall effect of 1-8 is unchanged.

[Bug libgcc/114689] [14 Regression] libgcc/config/m68k/fpgnulib.c:305: Suspicious coding ?

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||m68k
   Target Milestone|--- |14.0

[Bug c++/114691] [11/12/13/14 Regression] Bogus ignoring loop annotation warning

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

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

Bug 114409 Summary: [14 Regression] ICE after adding novector pragmas (internal 
compiler error: in tsubst_expr, at cp/pt.cc:21794) since 
r14-4229-g9c62af101e11e1cce573c2b3d2e18b403412dbc8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409

   What|Removed |Added

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

[Bug c++/114409] [14 Regression] ICE after adding novector pragmas (internal compiler error: in tsubst_expr, at cp/pt.cc:21794) since r14-4229-g9c62af101e11e1cce573c2b3d2e18b403412dbc8

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #19 from Jakub Jelinek  ---
.

[Bug c++/114409] [14 Regression] ICE after adding novector pragmas (internal compiler error: in tsubst_expr, at cp/pt.cc:21794) since r14-4229-g9c62af101e11e1cce573c2b3d2e18b403412dbc8

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

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

--- Comment #18 from Jakub Jelinek  ---
The P1 bug has been fixed, I've moved the rest to PR114691.

[Bug c++/114691] [11/12/13/14 Regression] Bogus ignoring loop annotation warning

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Priority|P3  |P2
 Ever confirmed|0   |1
   Last reconfirmed||2024-04-11
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |11.5

--- Comment #1 from Jakub Jelinek  ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409#c11
contains the fix which has been posted to gcc-patches but not reviewed yet.

[Bug c++/114691] New: [11/12/13/14 Regression] Bogus ignoring loop annotation warning

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

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

Bug ID: 114691
   Summary: [11/12/13/14 Regression] Bogus ignoring loop
annotation warning
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jason at gcc dot gnu.org,
pinskia at gcc dot gnu.org, ppalka at gcc dot gnu.org,
sjames at gcc dot gnu.org, webrown.cpp at gmail dot com
Depends on: 114409
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #114409 +++

As the PR114409 initially reported P1 bug is now fixed, I'm cloning it for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409#c10 regression.

int foo (int);

void
qux (int x)
{
  #pragma GCC ivdep
  while (int y = foo (x))
++y;
}

With no options this didn't emit any warnings e.g. in r20 (i.e. in GCC
4.9), while
it emits
pr114409-2.C:7:24: warning: ignoring loop annotation
warning in r22 (i.e. in GCC 5+).
Can't bisect easily, because in various revisions in between it ICEs on
ANNOTATE_EXPR.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
[Bug 114409] [14 Regression] ICE after adding novector pragmas (internal
compiler error: in tsubst_expr, at cp/pt.cc:21794) since
r14-4229-g9c62af101e11e1cce573c2b3d2e18b403412dbc8

[Bug libgomp/114690] OpenMP 'indirect' clause: dynamic image loading/unloading

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

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

--- Comment #1 from Thomas Schwinge  ---
I suggest that in the short term, we at least add a safeguard in the
'GOMP_OFFLOAD_load_image's to error out if 'GOMP_INDIRECT_ADDR_MAP' has already
been set (that should address (a), right?), and in the
'GOMP_OFFLOAD_unload_image's error out if 'GOMP_INDIRECT_ADDR_MAP' has been set
(that should address (b) -- right?).  (I'm assuming that stale mappings being
present may potentially be problematic?)

Those should be no-ops for the presumably common case that either dynamic
loading/unloading of images isn't used at all, or if it is, that no 'indirect'
clauses are actually present.

[Bug libgomp/114690] New: OpenMP 'indirect' clause: dynamic image loading/unloading

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

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

Bug ID: 114690
   Summary: OpenMP 'indirect' clause: dynamic image
loading/unloading
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org,
kcy at codesourcery dot com
  Target Milestone: ---

The OpenMP 'indirect' clause mapping table is not populated at image load time
(host-side), but upon the first device kernel invocation (device-side:
'build_indirect_map'), and is then immutable.

This is sufficient for a lot of cases, but breaks if additional images are
loaded after the first device kernel invocation (new mappings not added), or if
images get unloaded (stale mappings not retired).

Reference:

"[PATCH] openmp: Add support for the 'indirect' clause in C/C++", "Also, for my
understanding: [...]" ff.

[Bug middle-end/110027] [11/12/13 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
Summary|[11/12/13/14 regression]|[11/12/13 regression] Stack
   |Stack objects with extended |objects with extended
   |alignments (vectors etc)|alignments (vectors etc)
   |misaligned on   |misaligned on
   |detect_stack_use_after_retu |detect_stack_use_after_retu
   |rn  |rn

--- Comment #22 from Jakub Jelinek  ---
Fixed on the trunk so far.