https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116357
--- Comment #2 from Andrew Pinski ---
The linked PRs kinda of point out this is invalid code and should be rejected
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116357
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |tree-optimization
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527
--- Comment #15 from Deepthi H ---
We fixed the testcase that linaro complained about the previous patch.
We tested thoroughly the updated patch in-house and sent the patch to gcc
mailing list. Please find the link below:
https://gcc.gnu.org/pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116353
--- Comment #3 from Sergei Trofimovich ---
Adding a tiny bit of debugging code it looks like it's a missing optab for
vec_select:
```diff
--- a/gcc/optabs.cc
+++ b/gcc/optabs.cc
@@ -1260,6 +1260,7 @@ expand_simple_binop (machine_mode mode, enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116357
Bug ID: 116357
Summary: The item's address of the array is not correct if
aligned is used
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103660
--- Comment #8 from Andrew Pinski ---
Patch posted for the original testcases:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660221.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116356
--- Comment #3 from Andrew Pinski ---
There is no location information being passed to the warning. So we get the
location at the end of the function instead.
Wstrict-overflow is one of the worst option designed really.
Which is why it is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116356
--- Comment #2 from Andrew Pinski ---
#0 warning (opt=opt@entry=823, gmsgid=gmsgid@entry=0x2abc5d8 "assuming signed
overflow does not occur when changing X +- C1 cmp C2 to X cmp C2 -+ C1") at
/home/apinski/src/upstream-gcc-isel/gcc/gcc/diagnost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #167 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #165)
> (In reply to Oleg Endo from comment #163)
> > (In reply to Kazumoto Kojima from comment #130)
> > > Created attachment 58831 [details]
> > > a trial patch for c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116356
--- Comment #1 from Andrew Pinski ---
Created attachment 58921
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58921&action=edit
full testcase
Next time please attach the full testcase (https://gcc.gnu.org/bugs/#dontwant):
```
What we do n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #166 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #164)
>
> R0 specific pass would be "the Right Thing". It is hard to do right away,
> though.
I know. It's not a quick-fix, needs more time to implement.
> I've se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116356
Bug ID: 116356
Summary: signed overflow warning has misplaced line number
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #165 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #163)
> (In reply to Kazumoto Kojima from comment #130)
> > Created attachment 58831 [details]
> > a trial patch for c#129
> >
> > A quick fix may be:
> >
> > * confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #164 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #162)
> (In reply to Kazumoto Kojima from comment #153)
> > Created attachment 58886 [details]
> > a revised patch for c#135 and c#139
> >
> > (In reply to Oleg Endo f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116327
--- Comment #4 from John Eivind Helset ---
if compiling my project with 14.2.1 in release mode (cmake / -O3) i got another
ICE from `internal compiler error: in set_parm_rtl, at cfgexpand.cc:1436`.
0x21a7bea internal_error(char const*, ...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116342
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #3 from Jian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #163 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #130)
> Created attachment 58831 [details]
> a trial patch for c#129
>
> A quick fix may be:
>
> * config/sh/sh.md
> (call_pcrel, call_value_pcrel, sibcall_pcrel): Us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #162 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #153)
> Created attachment 58886 [details]
> a revised patch for c#135 and c#139
>
> (In reply to Oleg Endo from comment #139)
>
> If we try to keep the old behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116355
--- Comment #2 from Andrew Pinski ---
gen_pow2p is where the issue is.
So there is a few ways of fixing this I think.
One is to convert to an unsigned type if not already.
But there is another way is to use __builtin_popcount{,l,ll} always and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116355
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116355
Andrew Pinski changed:
What|Removed |Added
Summary|switchconv introduces new |[15 Regression] switchconv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116355
Bug ID: 116355
Summary: switchconv introduces new signed overflow UB
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116349
--- Comment #5 from Sam James ---
(In reply to Sam James from comment #3)
> ```
I tried to kill the dependence on syscall.* but I clearly don't know enough Go,
as replacing it with a typedef for Errno+const for ENOENT didn't do it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116349
Andrew Pinski changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116354
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116354
Bug ID: 116354
Summary: [15 regression] ICE during bootstrap stage 2 after
r15-2891-gb219cbeda72d23
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #161 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #159)
It looks the issue described in c#148. Could you confirm that patch 58883 in
c#149 has been applied? The testcase in c#160 is compiled successf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116349
--- Comment #3 from Sam James ---
Created attachment 58920
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58920&action=edit
zoneinfo_read.go
```
$ /var/tmp/portage/sys-devel/gcc-15.0./work/build/./gcc/gccgo
-B/var/tmp/portage/sys-deve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116353
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116349
Sam James changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116353
--- Comment #2 from ptomsich at gcc dot gnu.org ---
Thanks for providing an isolated case, this is very helpful.
Note that despite this being reported as 'ce2', it is the same underlying pass
as 'ce1'... just the second time the ce (conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89213
Michael Meissner changed:
What|Removed |Added
Attachment #58918|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116349
--- Comment #2 from Sam James ---
I'm working on reducing it to a self-contained set of Go sources as much as I
can, but PR116353 will be easier to work with.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527
--- Comment #14 from Randy MacLeod ---
There is a revised patch that has finally been tested after someone's vacation.
Deepthi, please share the link to the patch on this list once it's sent.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89213
Michael Meissner changed:
What|Removed |Added
Attachment #45612|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116353
--- Comment #1 from Sergei Trofimovich ---
Bisected down to r15-2890-g72c9b5f438f22c "ifcvt: Allow more operations in
multiple set if conversion".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107757
--- Comment #3 from Michael Meissner ---
As Segher says, the test is not quite correct. I would write it as:
vector long long lsb64_opt()
{
vector long long a = vec_splats(~0LL);
__asm__("vsrd %0,%1,%2":"=v"(a):"v"(a),"v"(a));
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116353
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116351
Andrew Pinski changed:
What|Removed |Added
Target Milestone|15.0|---
Summary|[15 regression]
-libsanitizer --enable-languages=c CFLAGS='-O1 -g0'
CXXFLAGS='-O1 -g0' LDFLAGS='-O1 -g0'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240812 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116351
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116352
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
Keywords|
hms: zlib zstd
gcc version 15.0.0 20240812 (experimental)
7a970bd03f1d8eed7703db8a8db3c753ea68899f (Gentoo 15.0. p, commit
743578d0de067c87f590c9886f14961bb429c1f4)
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116351
Bug ID: 116351
Summary: [15 only] RISC-V ICE: in get_len_load_store_mode, at
optabs-tree.cc:664
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116349
Andrew Pinski changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116350
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103660
--- Comment #7 from Andrew Pinski ---
Created attachment 58916
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58916&action=edit
vector testcases
Note f2 is handled for all OP because of:
```
/* Sink binary operation to branches, but only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116350
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116350
Bug ID: 116350
Summary: [15 regression] ICE in expand_fix, at optabs.cc:5948
etc.
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116349
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Component|tr
bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240812 (experimental)
7bf4cd48d4494ba65680578e9c7ae9a1b809aeaf (Gentoo Hardened 15.0. p, commit
743578d0de067c87f590c9886f14961bb429c1f4)
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116343
--- Comment #4 from Richard Sandiford ---
(In reply to Andrew Pinski from comment #3)
> Note I think late_combine 1 depends on DCE later on to delete the
> noop_move_p instructions but since -fno-dce was passed on the command line,
> it is not d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103660
--- Comment #6 from Andrew Pinski ---
Created attachment 58915
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58915&action=edit
scalar gimple testcases
Note f2 is not optimized either.
It should be simple as:
(simplify
(op:c
(cnd @0 @
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115769
Jakub Jelinek changed:
What|Removed |Added
Attachment #58912|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116343
--- Comment #3 from Andrew Pinski ---
Note I think late_combine 1 depends on DCE later on to delete the noop_move_p
instructions but since -fno-dce was passed on the command line, it is not
deleted and that causes the ICE.
Note also I think thi
Hello,
When trying to build gfortran make ends with the following error message:
*** Configuration aarch64-apple-darwin23.6.0 not supported
Details
* Computer: MacBook Air M3
* OS: Sonoma 14.6.1
* xcode-select -v
xcode-select version 2408
* Xcode 15.4
* Downloaded gcc-14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115824
--- Comment #13 from Jonathan Wakely ---
Definitely not, because 12.4 was already released two months ago.
The patch would suppress *all* warnings from that line, including valid
warnings for code with real bugs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116343
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116348
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116348
--- Comment #1 from Sam James ---
Reduced:
```
int *a;
int b;
long c, d;
void(e)(int f) {
for (; f; f++) {
d += (long)a[f] * b;
c += (long)a[f] * 3;
}
}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116348
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116342
--- Comment #2 from Andrew Pinski ---
Note libc++ also fails the same way ...
ify --disable-libvtv --with-zstd --with-isl
--disable-isl-version-check --enable-default-pie --enable-host-pie
--enable-host-bind-now --enable-default-ssp --disable-fixincludes
--with-build-config='bootstrap-O3 bootstrap-lto'
Thread model: posix
Supported LTO compression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116342
--- Comment #1 from Andrew Pinski ---
I am not sure this is valid thing to do. That is floating point is a
fundamental types so there is no ADL involved ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116347
Bug ID: 116347
Summary: [13/14/15 only] RISC-V: Duplicate entries for -mtune
in --target-help
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116346
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116312
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308
--- Comment #9 from kargls at comcast dot net ---
(In reply to anlauf from comment #8)
> (In reply to kargls from comment #7)
> > I can no longer edit meta data for a PR. The keyword: field is wrong. This
> > is an ice-on-invalid-code. Please
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759
--- Comment #20 from GCC Commits ---
The master branch has been updated by Peter Bergner :
https://gcc.gnu.org/g:0451bc503da9c858e9f1ddfb8faec367c2e032c8
commit r15-2896-g0451bc503da9c858e9f1ddfb8faec367c2e032c8
Author: Peter Bergner
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114394
--- Comment #5 from Romain Geissler ---
Hi,
Shall this be backported to release branches ?
Cheers,
Romain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116282
--- Comment #3 from Jeffrey A. Law ---
So yes, this is a problem with the const costing giving two different answers
at different times. That in turn causes the relevant pattern to match at one
point and fail to match at another.
It's a bit of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86476
--- Comment #6 from Marek Polacek ---
(In reply to frankhb1989 from comment #5)
> Since the resolution of CWG 1330 is enabled here (plus PR 109761),
> https://gcc.gnu.org/projects/cxx-dr-status.html should be updated.
Updated, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116346
Bug ID: 116346
Summary: Bad __cxa_atexit location for extended init ref
temporaries
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115769
Jakub Jelinek changed:
What|Removed |Added
Attachment #58908|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71672
Andi Kleen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116341
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Xi Ruoyao changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308
--- Comment #7 from kargls at comcast dot net ---
I can no longer edit meta data for a PR. The keyword: field is wrong. This is
an ice-on-invalid-code. Please change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308
--- Comment #6 from kargls at comcast dot net ---
Created attachment 58911
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58911&action=edit
Fix the ICE by detecting invalid code
The attached patch catches F2023:C7125. It does not address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115731
--- Comment #3 from Arsen Arsenović ---
ah, no, never mind - it does. per [expr.prim.lambda]#6,
... Otherwise, it is a non-static member function or member function
template, ...
so, yeah, we need to complete that type, likely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #160 from John Paul Adrian Glaubitz ---
Created attachment 58910
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58910&action=edit
Preprocessed source from from comment #159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29349
John Paul Adrian Glaubitz changed:
What|Removed |Added
Attachment #58909|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29349
John Paul Adrian Glaubitz changed:
What|Removed |Added
CC||glaubitz at physik dot
fu-be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #159 from John Paul Adrian Glaubitz ---
(In reply to Kazumoto Kojima from comment #157)
> Created attachment 58905 [details]
> a revised patch for c#135, c#139 and c#154
This now fails when compiling libstdc++-v3 with:
libtool: comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116327
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2024-08-12
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115731
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876
--- Comment #15 from Jeffrey A. Law ---
It's on my list, just higher priority items to deal with right now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876
--- Comment #14 from Martin Jambor ---
This issue is still present and unfortunately it is the kind of bug that either
creates manual periodic work because people need to go over logs to verify that
no new other UBSAN failure has appeared or it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116244
--- Comment #5 from Sam James ---
The hook didn't fire for some reason but r15-2894-ge9738e77674e23 was the fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116327
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Target Mile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116244
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116331
--- Comment #6 from Carl Dehlin ---
Thanks Jakub for your explanation.
Indeed, the following program runs fine and confirms what you just said.
Inspecting the assembly shows can both std::cos and __builtin_cos are
substituted to a library call w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116331
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116331
--- Comment #4 from Carl Dehlin ---
Found answer or 3) here:
https://sourceware.org/glibc/manual/latest/html_mono/libc.html#Known-Maximum-Errors-in-Math-Functions
.
For x86_64 cos is accurate up to 1 ulp from the correctly rounded value. As I
un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115769
--- Comment #4 from Jakub Jelinek ---
The above patch is on top of the PR107637 patch (just to avoid patch
conflicts).
Anyway, on #c2 previously the IL had a CLEANUP_POINT_EXPR around the e
reference initializer as well as the A temporary create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
--- Comment #12 from Michael Matz ---
But please note that Georg-Johanns question and its ensuing subthread is not
related to this specific m68k problem. It rather deals with the situation of
what to do in the non-strict variant.
_Here_ we hav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85624
Georg-Johann Lay changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|
1 - 100 of 146 matches
Mail list logo
