https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114688
Bug ID: 114688
Summary: repeat load argument of an inline function
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #13 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #12)
> short a;
> short c;
> short d;
> void
> foo (short b, short f)
> {
> c = b + a;
> d = f + a;
> }
>
> foo(short, short):
> addwa(%rip), %di
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #19 from Hongtao Liu ---
(In reply to Jakub Jelinek from comment #17)
> Both of the posted patches are incorrect, this needs to be fixed in
> asan_emit_stack_protection, account for the different offsets[0] which
> happens when a sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
--- Comment #12 from Richard Biener ---
I'm re-testing the patch in comment#8 and will push it. Please check the
possible issue mentioned in comment#9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114130
--- Comment #4 from GCC Commits ---
The releases/gcc-12 branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:d37be5c0413783c5459c5664b6ffb9f47acfca4e
commit r12-10319-gd37be5c0413783c5459c5664b6ffb9f47acfca4e
Author: Kito Cheng
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114687
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70569
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114684
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-04-11
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114674
--- Comment #5 from Di Zhao ---
Yes it's better to take a maximum MEM_ALIGN. I've missed that. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114681
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114682
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #12 from Hongtao Liu ---
short a;
short c;
short d;
void
foo (short b, short f)
{
c = b + a;
d = f + a;
}
foo(short, short):
addwa(%rip), %di
addwa(%rip), %si
movw%di, c(%rip)
movw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
--- Comment #13 from Uroš Bizjak ---
(In reply to Segher Boessenkool from comment #12)
> You cannot use a :CC value as argument of an unspec, as explained before.
>
> The result of a comparison is expressed as a comparison, in RTL. This patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114687
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904
--- Comment #5 from sandra at gcc dot gnu.org ---
Per TR12, these are the rules for the scoping/evaluation of these expressions:
"For the match clause of a declare variant directive, any argument of the base
function that is referenced in an exp
algorithms: zlib
gcc version 14.0.1 20240410 (experimental) (GCC)
git version: 0774240b4df9a9bc48ce33a9625788e402498f5a
***
Program:
$ cat mutant.c
int a;
int b(int);
__attribute__((pure, returns_twice)) int c() {
a = 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71760
--- Comment #3 from Andrew Pinski ---
(In reply to Eric Gallager from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Fixed in GCC 9 by r9-6544-g62de703f1990d2 .
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2019-March/518751.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71760
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80219
--- Comment #6 from Andrew Pinski ---
gcc_warning_prefix and gcc_error_prefix are still not set for the gnat
testsuite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
--- Comment #14 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:e40a3d86511efcea71e9eadde8fb9f96be52f790
commit r14-9908-ge40a3d86511efcea71e9eadde8fb9f96be52f790
Author: Pan Li
Date: Thu Apr 11 09:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89129
Bug 89129 depends on bug 54664, which changed state.
Bug 54664 Summary: expand_gimple_cond -Wtype-limits warning for predictably
small BRANCH_COST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54664
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54664
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |6.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44756
Bug 44756 depends on bug 54664, which changed state.
Bug 54664 Summary: expand_gimple_cond -Wtype-limits warning for predictably
small BRANCH_COST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54664
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105910
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69971
Andrew Pinski changed:
What|Removed |Added
CC||karine.even_mendoza at kcl dot
ac.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38077
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> This was fixed for GCC 5.5.0 by r5-10168-g26736ac3d17699 and GCC 6.1.0+ by
> r6-5413-g9dc39706b4afc3 .
I should say that was the last patch which was needed to f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38077
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Bernd Edlinger from comment #2)
> > As of current 4.9 trunk, that may have changed a bit.
> > but it still does not do what one would expect:
>
> Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38077
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38077
--- Comment #3 from Andrew Pinski ---
(In reply to Bernd Edlinger from comment #2)
> As of current 4.9 trunk, that may have changed a bit.
> but it still does not do what one would expect:
That is a different issue ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #16 from Thiago Jung Bauermann
---
(In reply to Andrew Pinski from comment #15)
> (In reply to Thiago Jung Bauermann from comment #14)
> > This came up in the context of a Linux kernel patch series providing a
> > "Unified cross-arch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71760
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114130
--- Comment #3 from GCC Commits ---
The releases/gcc-13 branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:fb6ec6df54317ed3f6e6f878b6ea29dbef6bfe2d
commit r13-8598-gfb6ec6df54317ed3f6e6f878b6ea29dbef6bfe2d
Author: Kito Cheng
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106899
Andrew Pinski changed:
What|Removed |Added
Summary|Snapshots do not contain|Snapshots maybe should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59905
Andrew Pinski changed:
What|Removed |Added
CC||rhill at gentoo dot org
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31359
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114666
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> Created attachment 57925 [details]
> Patch which I am testing
Looks like I need a small tweak as gcc.dg/torture/builtin-isinf_sign-1.c fails
due to the converts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #15 from Andrew Pinski ---
(In reply to Thiago Jung Bauermann from comment #14)
> This came up in the context of a Linux kernel patch series providing a
> "Unified cross-architecture kernel-mode FPU API" because the AMD GPU driver
> f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
Thiago Jung Bauermann changed:
What|Removed |Added
CC||thiago.bauermann at linaro dot
o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86698
Andrew Pinski changed:
What|Removed |Added
Depends on||23872
--- Comment #3 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112878
--- Comment #6 from GCC Commits ---
The master branch has been updated by Indu Bhagat :
https://gcc.gnu.org/g:5c869aa8a4538b218d9e59de6c96133971e7b965
commit r14-9906-g5c869aa8a4538b218d9e59de6c96133971e7b965
Author: Indu Bhagat
Date: Wed A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95277
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |c
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70039
Andrew Pinski changed:
What|Removed |Added
Known to work||11.1.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510
Bug 63510 depends on bug 63451, which changed state.
Bug 63451 Summary: bad location for the condition in for-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63451
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63451
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
--- Comment #12 from Segher Boessenkool ---
You cannot use a :CC value as argument of an unspec, as explained before.
The result of a comparison is expressed as a comparison, in RTL. This patch
allows malformed RTL in more places than before,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114625
Patrick Palka changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114666
--- Comment #7 from Andrew Pinski ---
Created attachment 57925
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57925&action=edit
Patch which I am testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114606
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114606
--- Comment #1 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:b8b148bc22673689fda19711b428b544462be2e4
commit r14-9903-gb8b148bc22673689fda19711b428b544462be2e4
Author: Marek Polacek
Date: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114685
--- Comment #1 from m.cencora at gmail dot com ---
Oops, the -isystem and -std options are not necessary for reproduction.
This is enough:
$ g++ -fmodules-ts lldiv_t.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
m.cencora at gmail dot com changed:
What|Removed |Added
Attachment #57921|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114472
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114686
--- Comment #1 from Andrew Pinski ---
I suspect this will happen for GCC 15. GCC 14's RVV was done to test out the
middle-end and back-end parts and not really tuned at all. Even the default
tuning is no cost model; though you can turn it on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114684
--- Comment #1 from Andrew Pinski ---
Note clang Canonicalizes it into `-([b]&1)` (though on aarch64, they don't use
sbfx while GCC does uses that).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
--- Comment #9 from m.cencora at gmail dot com ---
(In reply to Jonathan Wakely from comment #8)
> Thanks. I hope we'll end up auto-generating a file like that from
> ../gcc/cp/cxxapi-data.csv
Hmm, then that file will have to be extended because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114686
Bug ID: 114686
Summary: Feature request: Dynamic LMUL should be the default
for the RISC-V Vector extension
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114685
Bug ID: 114685
Summary: [modules] ICE when exporting a type through a
different alias then one declared in GMF
Product: gcc
Version: 14.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114684
Bug ID: 114684
Summary: `-(int)(unsigned:1)signed:1` could just be
`(int)signed:1`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114472
--- Comment #4 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:4a94551d7eaaf7a75c5195fc0bf4af94185a04c7
commit r14-9902-g4a94551d7eaaf7a75c5195fc0bf4af94185a04c7
Author: David Malcolm
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114683
Bug ID: 114683
Summary: [modules] name declared in GMF in inline namespace and
exported via using-decl from parent namespace is not
visible to importer
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106500
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114682
--- Comment #1 from Andrew Pinski ---
Note I was imspired to look into this because of
https://github.com/llvm/llvm-project/issues/88274 (note LLVM does a worse job
here and does not constant loads the string either).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114682
Bug ID: 114682
Summary: const_array[i].b where i is PHI<0,1,2> is not folded
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhan
/x86_64-pc-linux-gnu-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9885-20240410075703-g109f1b28fc9-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240410 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114680
--- Comment #2 from Jonathan Wakely ---
There's line 685 too
void
_M_set_options(__pool_base::_Tune __t)
{ __policy_type::_S_get_pool()._M_set_options(__t); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114680
--- Comment #1 from Jonathan Wakely ---
I doubt anybody uses that code anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
--- Comment #11 from Uroš Bizjak ---
(In reply to Segher Boessenkool from comment #10)
> It is still wrong. You're trying to sweep tour wrong assumptions under the
> rug,
> but they will only rear up elsewhere. Just fix the actual *target* pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114680
Bug ID: 114680
Summary: libstdc++-v3/include/ext/mt_allocator.h:142: possible
performance problem ?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #29 from g.peterh...@t-online.de ---
(In reply to Jakub Jelinek from comment #28)
> As long as the scale is a power of two or 1.0 / power of two, I don't see
> why any version wouldn't be inaccurate.
Yes, but the constant scale_up is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
--- Comment #10 from Segher Boessenkool ---
It is still wrong. You're trying to sweep tour wrong assumptions under the
rug,
but they will only rear up elsewhere. Just fix the actual *target* problem!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #60 from Sarah Julia Kriesch ---
I have to agree with Richard. This problem has been serious for a long time but
has been ignored by IBM based on distribution choices.
Anyway, we want to live within the open source community without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114665
--- Comment #3 from Patrick O'Neill ---
Created attachment 57922
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57922&action=edit
Generated assembly files
Hmm doesn't look like it from my side - maybe there's some stack related
weirdness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104585
--- Comment #4 from Bill Long ---
Any prediction for this one? (I realize you still have F2018 an F2023 to get
through.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989
--- Comment #25 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #24)
> > * testsuite/30_threads/jthread/95989.cc: New test.
>
> This testcase fails on FreeBSD 14:
Related PRs there: PR 103444 and PR 82635; it might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103496
--- Comment #3 from anlauf at gcc dot gnu.org ---
The code in comment#0 compiles at r14-9893-gded646c91d2c0f
and gives the indicated results.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106500
--- Comment #7 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:ded646c91d2c0fb908faf6fa8fe1df0d7df49d16
commit r14-9893-gded646c91d2c0fb908faf6fa8fe1df0d7df49d16
Author: Harald Anlauf
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #59 from Richard Biener ---
(In reply to Segher Boessenkool from comment #57)
> (In reply to Richard Biener from comment #56)
> > The fix was reverted but will be re-instantiated for GCC 15 by me.
>
> And I still protest.
>
> PR101
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114678
--- Comment #2 from Andrew Pinski ---
(In reply to Richard Biener from comment #1)
> I guess VRP should handle __builtin_isinf and friends.
Like was posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648303.html ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114677
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114678
Richard Biener changed:
What|Removed |Added
Blocks||85316
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #28 from Jakub Jelinek ---
As long as the scale is a power of two or 1.0 / power of two, I don't see why
any version wouldn't be inaccurate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #7 from Richard Biener ---
The question is what the intrinsic constraints are on TBAA.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114672
Richard Biener changed:
What|Removed |Added
Known to work||14.0
--- Comment #3 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114672
--- Comment #2 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:912753cc5f18d786e334dd425469fa7f93155661
commit r14-9892-g912753cc5f18d786e334dd425469fa7f93155661
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #27 from g.peterh...@t-online.de ---
Hi Matthias,
thanks for your benchmark. I still have 2 questions:
1) Accuracy
The frexp/ldexp variant seems to be the most accurate; is that correct? Then
other constants would have to be used in h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #58 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #57)
> (In reply to Richard Biener from comment #56)
> > The fix was reverted but will be re-instantiated for GCC 15 by me.
>
> And I still protest.
>
> PR1015
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #57 from Segher Boessenkool ---
(In reply to Richard Biener from comment #56)
> The fix was reverted but will be re-instantiated for GCC 15 by me.
And I still protest.
PR101523 is a very serious problem, way way way more "P1" than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114679
Bug ID: 114679
Summary: .file directive missing on MIPS ports when debug
symbols are enabled.
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
Michael Meissner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
Bug 104772 depends on bug 99708, which changed state.
Bug 99708 Summary: __SIZEOF_FLOAT128__ not defined on powerpc64le-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
--- Comment #8 from Jonathan Wakely ---
Thanks. I hope we'll end up auto-generating a file like that from
../gcc/cp/cxxapi-data.csv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #16 from Segher Boessenkool ---
Yup, GPR31 is used for the emulated frame pointer, so this is user error:
saying
a fixed-purpose register is clobbered makes no sense. You are not allowed to
use any register that the compiler uses fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114668
--- Comment #2 from Robin Dapp ---
This, again, seems to be a problem with bit extraction from masks.
For some reason I didn't add the VLS modes to the corresponding vec_extract
patterns. With those in place the problem is gone because we go th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
--- Comment #7 from m.cencora at gmail dot com ---
Created attachment 57921
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57921&action=edit
Full "std" module
FYI if you want to stress test the modules impl w.r.t. similar issues, here is
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
Peter Bergner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #14 from Richard Sandiford ---
Yeah, I think so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #13 from Peter Bergner ---
So I think the conclusion is we should close this as INVALID, correct?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114674
Alex Coplan changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #12 from Richard Sandiford ---
(In reply to Peter Bergner from comment #11)
> > > but how are users supposed to know whether
> > > -fno-omit-frame-pointer is in effect or not? I've looked and there is no
> > > pre-defined macro a us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #11 from Peter Bergner ---
(In reply to Richard Sandiford from comment #10)
> Yeah, I agree it's an error. The PR says “ICE”, but is there an internal
> error? The “cannot be used in ‘asm’ here” is a normal user-facing error,
> alb
1 - 100 of 160 matches
Mail list logo
