https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109920
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109920
--- Comment #4 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:493a63af6cbab094c36a76435c12b1886328dab8
commit r14-1083-g493a63af6cbab094c36a76435c12b1886328dab8
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103716
--- Comment #7 from CVS Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:842a432b02238361ecc601d301ac400a7f30f4fa
commit r14-1082-g842a432b02238361ecc601d301ac400a7f30f4fa
Author: Paul Thomas
Date: Tue M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
--- Comment #11 from CVS Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:056280dea422ba831e40dee9e6769862927998c6
commit r14-1081-g056280dea422ba831e40dee9e6769862927998c6
Author: Paul Thomas
Date: Tue M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97720
--- Comment #5 from Jason Merrill ---
Note that Foo is unneeded, this shows the same behavior:
void bad_guy() throw() {
try { throw 0; }
catch (float) { }
// Don't catch int.
}
vo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109922
--- Comment #3 from Jiang An ---
> setfill and its friends
I was wrong. Only setfill itself is so relaxed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109922
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #2 from Jian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
--- Comment #17 from Andrew Pinski ---
(In reply to Adam Wozniak from comment #13)
> (In reply to Jakub Jelinek from comment #11)
> > Bisection points to r10-3309-g7d112d6670a0e0e662
>
> that link gives me an error
https://gcc.gnu.org/git/gitw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
--- Comment #16 from Andrew Pinski ---
(In reply to Adam Wozniak from comment #12)
>
> No, i am fairly CERTAIN they are different executables.
GCC has been using an integrated preprocessor since GCC 3.0 timeframe (~2000 or
maybe even before).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83400
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
See A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
--- Comment #15 from Adam Wozniak ---
(In reply to Jonathan Wakely from comment #6)
> ≠ cannot be used in an identifier, and it's none of the other forms either.
at the risk of beating a dead horse, what you are saying here is that ≠ simply
can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #4 from Stan Johnson ---
Adding more swap space doesn't help.
The latest Gentoo update attempted to merge gcc-13.1.1_p20230520, and it failed
while compiling gimple-match.cc in stage2.
The error message is "virtual memory exhausted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
--- Comment #14 from Adam Wozniak ---
(In reply to Adam Wozniak from comment #12)
> (In reply to Jonathan Wakely from comment #9)
> > (In reply to Adam Wozniak from comment #8)
> > > i don't think of the preprocessor as part of the compiler.
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
--- Comment #13 from Adam Wozniak ---
(In reply to Jakub Jelinek from comment #11)
> Bisection points to r10-3309-g7d112d6670a0e0e662
that link gives me an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
--- Comment #12 from Adam Wozniak ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Adam Wozniak from comment #8)
> > i don't think of the preprocessor as part of the compiler.
> > it's a different step, a different executable, th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108732
Justin Chen changed:
What|Removed |Added
CC||justinpopo6 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109937
--- Comment #2 from Andrew Pinski ---
Note GCC 13 behavior is correct according to the C++ defect report: CWG1228 but
it is being raised with the C++ standards committee again.
Anyways see bug 109247 comment #5 on that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109247
Andrew Pinski changed:
What|Removed |Added
CC||enolan at alumni dot cmu.edu
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109937
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91317
S. Davis Herring changed:
What|Removed |Added
CC||herring at lanl dot gov
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109937
Bug ID: 109937
Summary: Spurious ambiguous overload error when class with
explicit template ctor is assigned to from an
braced-init-list initializing an aggregate
Product:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109913
--- Comment #10 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:b9fb093e7ccaee68be659d7d9711652c57e37aca
commit r14-1079-gb9fb093e7ccaee68be659d7d9711652c57e37aca
Author: Iain Sandoe
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101528
--- Comment #7 from Carl Love ---
I recently committed a patch to fix the counts.
commit 5d336ae49528fde3904c9e5bfc83a450429b2961
Author: Carl Love
Date: Fri Mar 10 18:16:52 2023 -0500
rs6000: Fix test int_128bit-runnable.c instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97720
Jason Merrill changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
--- Comment #10 from Andreas Schwab ---
> The standard says "Each preprocessing token that is converted to a token
> (5.6) shall have the lexical form of a keyword, an identifier, a literal, or
> an operator or punctuator."
The argument of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
--- Comment #9 from Jonathan Wakely ---
(In reply to Adam Wozniak from comment #8)
> i don't think of the preprocessor as part of the compiler.
> it's a different step, a different executable, that happens BEFORE the
> compiler.
No it isn't. Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
--- Comment #8 from Adam Wozniak ---
(In reply to Jonathan Wakely from comment #6)
> That isn't the point. The compiler has to tokenize the input in order to
> perform the preprocessing step. That means it has to be able to decide what
> the byt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109935
--- Comment #4 from Andrew Pinski ---
The same is true even with a depedent field rather than base:
```
template
struct C {
B b;
};
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109935
--- Comment #3 from Andrew Pinski ---
C{B{1}};
Does work though.
I suspect the issue is cannot figure out that {1} can be bound to B and
deudce T there and even GCC gives that as a reason:
:7:8: note: candidate: 'template C(B)-> C'
7 | str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
--- Comment #6 from Jonathan Wakely ---
(In reply to Adam Wozniak from comment #4)
> reopening. this is not at all "expected".
>
> C++ papers P1041R4 and P1139R2 cover literal constants in code.
> they do not at all cover anything about argume
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109934
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
--- Comment #5 from Jonathan Wakely ---
I think https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1949r7.html
is the most relevant paper.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
Adam Wozniak changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
--- Comment #2 from Andrew Pinski ---
See C++ papers: P1041R4 and P1139R2 on this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
--- Comment #1 from Andrew Pinski ---
clang rejects both:
:2:3: error: unexpected character
X(🤔) // emojis work
^~
:3:3: error: unexpected character
X(≠) // this "not equal" does NOT work!
^
GCC does reject both with -pedantic (in GCC 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109935
--- Comment #2 from Oleksandr Koval ---
According to cppreference, Clang has not implemented CTAD for aggregates at all
so no surprise here. I know that gcc/msvc rejects it but I don't understand
why.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109935
--- Comment #1 from Andrew Pinski ---
MSVC rejects `C{{1}}` for the same reason as GCC.
clang rejects even `B{1}` .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
Bug ID: 109936
Summary: error: extended character ≠ is not valid in an
identifier
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109935
Bug ID: 109935
Summary: CTAD for an aggregate with a dependent base class
doesn't work
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20976
Jason Merrill changed:
What|Removed |Added
Target Milestone|--- |4.6.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109934
Bug ID: 109934
Summary: Wrong code at -O3 on x86_64-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109920
--- Comment #3 from David Binderman ---
(In reply to Aldy Hernandez from comment #2)
> Created attachment 55137 [details]
> untested patch
>
> Does this fix the problem?
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66618
--- Comment #9 from Alex Henrie ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Alex Henrie from comment #6)
> > This wasn't fixed properly, or it was broken again before the release of GCC
> > 8.1: In GCC 8.1 and later no warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66618
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Alex Henrie from comment #6)
> > This wasn't fixed properly, or it was broken again before the release of GCC
> > 8.1: In GCC 8.1 and later no warnin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66618
--- Comment #7 from Andrew Pinski ---
(In reply to Alex Henrie from comment #6)
> This wasn't fixed properly, or it was broken again before the release of GCC
> 8.1: In GCC 8.1 and later no warning at all is issued for the example
> program, even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109920
--- Comment #2 from Aldy Hernandez ---
Created attachment 55137
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55137&action=edit
untested patch
Does this fix the problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109933
--- Comment #2 from Andrew Pinski ---
So it looks like it is still broken.
andia4,s0,3
sllia4,a4,3
li a2,1
andia3,s0,-4
sll a2,a2,a4
amoor.w.aqrla5,a2,0(a3)
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109933
--- Comment #1 from Andrew Pinski ---
This might be fixed on the trunk with recent patches; note those patches are
NOT backportable from what I remember.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66618
Alex Henrie changed:
What|Removed |Added
CC||alexhenrie24 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109933
Bug ID: 109933
Summary: __atomic_test_and_set is broken for BIG ENDIAN riscv
targets
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641
--- Comment #20 from CVS Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:42d6b7d58caf7858704d93ce2f7a8cdf8a071e44
commit r14-1076-g42d6b7d58caf7858704d93ce2f7a8cdf8a071e44
Author: Georg-Johann Lay
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #4 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Aldy Hernandez from comment #2)
> > If irange::supports_p (TREE_TYPE (arg)) is true, we're talking about an
> > integer/pointer, but if range_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #3 from Andrew Pinski ---
(In reply to Aldy Hernandez from comment #2)
> If irange::supports_p (TREE_TYPE (arg)) is true, we're talking about an
> integer/pointer, but if range_cast is being called on a parm_type of
> RECORD_TYPE, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #2 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #1)
> Breakpoint 6, range_cast (r=..., type=) at
> /home/apinski/src/upstream-gcc/gcc/gcc/range-op.cc:4853
> 4853 Value_Range tmp (r);
>
>
> Confirmed.
> The c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109930
--- Comment #3 from Simon Richter ---
I was looking at ARMv7 initially.
If I understood the implementation correctly, this can be a generic
optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109932
Bug ID: 109932
Summary: ICE in in extract_insn, at recog.cc:2791 on ppc64le
with -mno-vsx
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682
--- Comment #7 from Ian Lance Taylor ---
To be clear, I will at some point update libgo to newer Go releases, yes. I'm
working on adding generics support to the frontend.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682
--- Comment #6 from Ian Lance Taylor ---
libgo is running behind right now, but in any case I personally don't have
plans to add LoongARCH support. I would be happy to review any patches, which
would ideally be sent using the process described
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109930
Andrew Pinski changed:
What|Removed |Added
Target||!i*86-* & !x86_64-*
Ever confirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243
--- Comment #10 from CVS Commits ---
The releases/gcc-10 branch has been updated by Michael Meissner
:
https://gcc.gnu.org/g:c970030226341f0c7fa9f319b37786ca81703c6d
commit r10-11421-gc970030226341f0c7fa9f319b37786ca81703c6d
Author: Michael Mei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243
--- Comment #9 from CVS Commits ---
The releases/gcc-11 branch has been updated by Michael Meissner
:
https://gcc.gnu.org/g:d7d25bcfbd5ee5ef17fabeb67ad5e093cd975a36
commit r11-10807-gd7d25bcfbd5ee5ef17fabeb67ad5e093cd975a36
Author: Michael Meis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109855
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243
--- Comment #8 from CVS Commits ---
The releases/gcc-12 branch has been updated by Michael Meissner
:
https://gcc.gnu.org/g:3bb91d31a272d7fd9f02301df101e3041d5aeb5d
commit r12-9635-g3bb91d31a272d7fd9f02301df101e3041d5aeb5d
Author: Michael Meiss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109855
--- Comment #6 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #5)
> (In reply to rsand...@gcc.gnu.org from comment #4)
> > I guess the problem is that the define_subst output template has:
> >
> > (match_operand: 0)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109931
--- Comment #4 from Andrew Pinski ---
There is another bug about this.
In this case we know that bit 5 is set for the range ['a','z'] .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100764
Patrick Palka changed:
What|Removed |Added
Target Milestone|11.3|10.3
--- Comment #5 from Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100764
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641
--- Comment #19 from CVS Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:9f5065094c9632a50bea604d5896a139609e50cf
commit r14-1074-g9f5065094c9632a50bea604d5896a139609e50cf
Author: Georg-Johann Lay
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109923
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109913
--- Comment #9 from Andrew Pinski ---
(In reply to Iain Sandoe from comment #8)
> powerpc darwin bootstrap succeeded at r14-1028 with (as expected) Andrew's
> patch amended to:
>
> diff --git a/libobjc/encoding.c b/libobjc/encoding.c
> index 9b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505
--- Comment #22 from Jakub Jelinek ---
Fixed for 12.4, 13.2 and 14.1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505
--- Comment #21 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:6ef4e2e11c653f1d51f9a304a8d1cf44a53b4ad7
commit r12-9634-g6ef4e2e11c653f1d51f9a304a8d1cf44a53b4ad7
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109913
--- Comment #8 from Iain Sandoe ---
powerpc darwin bootstrap succeeded at r14-1028 with (as expected) Andrew's
patch amended to:
diff --git a/libobjc/encoding.c b/libobjc/encoding.c
index 9bd261c..f1bbd6b 100644
--- a/libobjc/encoding.c
+++ b/l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505
--- Comment #20 from CVS Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:0feece18e6993d02f24a9381ddb5420bb4509554
commit r13-7365-g0feece18e6993d02f24a9381ddb5420bb4509554
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #43 from Alejandro Colomar ---
GCC's manual also doesn't seem to document any deviation from ISO C
rules regarding mem*() functions. It would be good to document what is
the GCC interpretation of ISO C regarding those rules, and what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71990
Ivan Sorokin changed:
What|Removed |Added
CC||vanyacpp at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109922
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109855
--- Comment #5 from ktkachov at gcc dot gnu.org ---
(In reply to rsand...@gcc.gnu.org from comment #4)
> I guess the problem is that the define_subst output template has:
>
> (match_operand: 0)
>
> which creates a new operand 0 with an empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109855
--- Comment #4 from rsandifo at gcc dot gnu.org
---
I guess the problem is that the define_subst output template has:
(match_operand: 0)
which creates a new operand 0 with an empty predicate and constraint,
as opposed to a (match_dup 0), wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #42 from Alejandro Colomar ---
I'm very confused by this ticket.
The discussion seems to be settled by Martin Sebor that the presented
code has UB due to pointer provenance issues, according to the WG14
interpretation of the standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109855
--- Comment #3 from rsandifo at gcc dot gnu.org
---
Looking at the mddump file, the output predicate and constraint
seem to have gone AWOL:
;; /home/ricsan01/gnu/src/gcc/gcc/config/aarch64/aarch64-simd.md: 1554
(define_insn ("aarch64_mlav4hi_v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109931
--- Comment #3 from Antony Polukhin ---
> But that's because nothing in the function asserts this? Without fully
> specializing and unrolling on the constant "hello" argument at least.
Yes, I was hoping for that unrolling to happen
Probably a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109855
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-05-22
Ever confir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109931
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109930
--- Comment #1 from Richard Biener ---
Can you proivde a testcase that can be compiled?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109931
--- Comment #1 from Richard Biener ---
But that's because nothing in the function asserts this? Without fully
specializing and unrolling on the constant "hello" argument at least.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109931
Bug ID: 109931
Summary: Knowledge on literal not used in optimization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109930
Bug ID: 109930
Summary: transform atomic exchange to unconditional store when
old value is unused?
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109929
--- Comment #2 from Xi Ruoyao ---
(In reply to Richard Biener from comment #1)
> I think nobody paid attention to graphite the last years - I suggest to
> try simpler things like non-profiled bootstrap or just running the
> testsuite with -fgrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109926
--- Comment #8 from Jonathan Wakely ---
Comment on attachment 55135
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55135
config
configure:18893: checking fenv.h usability
configure:18893: i586-msdosdjgpp-c++ -c -g -O2 -std=c++11 -fno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109929
--- Comment #1 from Richard Biener ---
I think nobody paid attention to graphite the last years - I suggest to
try simpler things like non-profiled bootstrap or just running the
testsuite with -fgraphite-identity added.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109929
Bug ID: 109929
Summary: profiledbootstrap failure on aarch64-linux-gnu with
graphite optimization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109926
--- Comment #7 from cqwrteur ---
Created attachment 55135
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55135&action=edit
config
config
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109926
--- Comment #6 from Jonathan Wakely ---
Please provide the i586-msdosdjgpp/libstdc++-v3/config.log file, not the
top-level one from configuring gcc.
The libstdc++ fenv.h has:
#include
#if _GLIBCXX_HAVE_FENV_H
# include_next
#endif
And that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109926
--- Comment #5 from Jonathan Wakely ---
(In reply to cqwrteur from comment #4)
> libstdc++ provides a fenv.h, however, the build system cannot find it with
> canadian compilation.
The error comes from the libstdc++ fenv.h
1 - 100 of 109 matches
Mail list logo
