https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114043
Bug ID: 114043
Summary: ICE: in write_symbol, at lto-streamer-out.cc:3015 with
-O -fstrict-enums -fprofile-generate -flto
--param=max-early-inliner-iterations=0
Product: gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #20 from Jakub Jelinek ---
(In reply to rguent...@suse.de from comment #19)
> I think the usual BLKmode check would be better here? Apart from
> that this looks correct, we shouldn't use a regular convert on
> a non-register type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111770
--- Comment #3 from Richard Biener ---
As said X + 0. -> X is an invalid transform with FP unless there are no signed
zeros (maybe also problematic with sign-dependent rounding).
I think we agree to define .MASK_LOAD to zero masked elements. W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114042
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114042
--- Comment #3 from Jakub Jelinek ---
Sure, we could repeat some of the checks we do for __builtin_clzg etc. before
we lower __builtin_stdc_*, but wouldn't that be a maintainance nightmare?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #21 from rguenther at suse dot de ---
On Thu, 22 Feb 2024, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
>
> --- Comment #20 from Jakub Jelinek ---
> (In reply to rguent...@suse.de from comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #22 from Jakub Jelinek ---
Yeah, I was worried about partial ints. Or it could be punt if TYPE_MODEs are
different and at least one of them is BLKmode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114045
Bug ID: 114045
Summary: large _BitInt * _Bool (or having known boolean range)
should be inlined instead of calling __mulbitint3
Product: gcc
Version: 14.0
Status: UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114046
Bug ID: 114046
Summary: Aarch64: Os,O1,02,O3 optimisations generates unaligned
access in short members of structure
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Jakub Jelinek ---
> Created attachment 57483
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57483&action=edit
> gcc14-pr114007.patch
>
> So far very ligh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114047
Bug ID: 114047
Summary: `(cast)(cast)a != a` for large unsigned _BitInt should
be produce better code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Joseph S. Myers ---
> The tests that GCC's internal notion of the types agrees with the headers are
> in gcc.dg/c99-stdint-5.c and gcc.dg/c99-stdint-6.c.
Ah, no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #23 from rguenther at suse dot de ---
On Thu, 22 Feb 2024, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
>
> --- Comment #22 from Jakub Jelinek ---
> Yeah, I was worried about partial ints.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114045
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114045
--- Comment #2 from Jakub Jelinek ---
And, as for loops, we pattern recognize loops doing memcpy, memset, memmove
etc. later on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114046
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027
Robin Dapp changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Last reconfir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027
--- Comment #7 from Sam James ---
(In reply to Robin Dapp from comment #6)
> Btw this fails on x86 and aarch64 for me with -fno-vect-cost-model. So it
> definitely looks generic.
What args did you use? I can't get it to fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027
--- Comment #8 from Andrew Pinski ---
(In reply to Robin Dapp from comment #6)
> Btw this fails on x86 and aarch64 for me with -fno-vect-cost-model. So it
> definitely looks generic.
I still can't reproduce it on x86 with `-O3 -fno-vect-cost-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027
--- Comment #9 from Robin Dapp ---
Argh, I actually just did a gcc -O3 -march=native pr114027.c
-fno-vect-cost-model on cfarm188 with a recent-ish GCC but realized that I used
my slightly modified version and not the original test case.
long a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114048
Bug ID: 114048
Summary: [14 regression] ICE when building libowfat-0.33 on x86
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114048
--- Comment #1 from Sam James ---
Reducing...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114038
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:853cbcb7a74ecd95efcba25279b270f0a868d584
commit r14-9131-g853cbcb7a74ecd95efcba25279b270f0a868d584
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114038
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113993
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:7ed800c9c94b57077ba5911974a63bc06a5e1c35
commit r14-9132-g7ed800c9c94b57077ba5911974a63bc06a5e1c35
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113993
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027
--- Comment #11 from Andrew Pinski ---
For x86_64, this seems to have broke between GCC 9 and GCC 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Sam James changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114047
--- Comment #1 from Andrew Pinski ---
Note there is a generic (non _BitInt) issue with __builtin_sub_overflow vs the
other comparison too; on some targets using a bit mask is better while on
others using the `<=` test is better.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114048
--- Comment #2 from Sam James ---
Reduced:
```
typedef struct {
void *child[2];
char otherbits;
} critbit0_node;
int allprefixed_traverse(char *top) {
if (top) {
critbit0_node *q = (void *)top - 1;
int direction = 0;
for (;; +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114048
Sam James changed:
What|Removed |Added
Summary|[14 regression] ICE when|[14 regression] ICE when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027
--- Comment #13 from Richard Biener ---
We're detecting a COND_REDUCTION with a chain. It seems to work (and
vectorize) with -march=znver4 using AVX sized vectors (but AVX512 style
masking).
I think what goes wrong is treating the COND_REDUCTI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027
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=114027
Richard Biener changed:
What|Removed |Added
Target Milestone|14.0|11.5
Keywords|needs-bisectio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114048
Jakub Jelinek changed:
What|Removed |Added
Summary|[14 regression] ICE when|[14 Regression] ICE when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #19 from fxcoudert at gmail dot com ---
Hi Rainer,
> Thanks a lot for the patch. I've now re-bootstrapped trunk on macOS 14
> with it applied instead of the local (incomplete)
> workaround.
I haven’t yet tested Xcode 13.3 myself,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #19 from fxcoudert at gmail dot com ---
Hi Rainer,
> Thanks a lot for the patch. I've now re-bootstrapped trunk on macOS 14
> with it applied instead of the local (incomplete)
> workaround.
I haven’t yet tested Xcode 13.3 myself,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027
--- Comment #14 from Richard Biener ---
int __attribute__((noipa))
foo (int *f, int n)
{
int res = 0;
for (int i = 0; i < n; ++i)
{
if (f[2*i])
res = 2;
if (f[2*i+1])
res = -2;
}
return res;
}
int f[] =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #19 from fxcoudert at gmail dot com
> ---
> Hi Rainer,
>
>> Thanks a lot for the patch. I've now re-bootstrapped trunk on macOS 14
>> with it applied instead of the loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #22 from Iain Sandoe ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #21)
> > --- Comment #19 from fxcoudert at gmail dot com > com> ---
> The only issue left (the gcc.dg/framework-1.c failure) so far seems to
> be an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
Bug ID: 114049
Summary: gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #22 from Iain Sandoe ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #21)
>> > --- Comment #19 from fxcoudert at gmail dot com > com> ---
>
>
>> The only is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
Bug ID: 114050
Summary: Inconsistency in double/float constant evaluation
between 32 and 64 bit
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #1 from Søren Jæger Hansen ---
Created attachment 57492
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57492&action=edit
Preprocessed output (gzipped to fit)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #3 from Andrew Pinski ---
See PR 323 and other related bug reports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #5 from Andrew Pinski ---
`0.0003 - 0.0001*3.0` with -std=c++23 is done all in long double and then
casted to double. Which is why b is 0 there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114051
Bug ID: 114051
Summary: Incorrect out-of-bounds warning in loop that never
executes, due to failure to eliminate a dead branch
Product: gcc
Version: 13.2.0
Status: UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114009
Richard Biener changed:
What|Removed |Added
Blocks||85316
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #24 from Jakub Jelinek ---
(In reply to fxcoud...@gmail.com from comment #19)
> I haven’t yet tested Xcode 13.3 myself, and have only followed the PRs from
> far away. Are there any issues (SDK, linker, or otherwise) that we need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #8 from Richard Biener ---
It's expected that SSA naming can affect code generation, there's no
"declaration order" as for VAR_DECLs we could ultimatively fall back to.
Ideally algorithms should not depend on particular ordering so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #24 from Jakub Jelinek ---
> (In reply to fxcoud...@gmail.com from comment #19)
>> I haven’t yet tested Xcode 13.3 myself, and have only followed the PRs from
>> far away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #26 from Iain Sandoe ---
but from your initial post it's also guarded by:
#ifndef __has_cpp_attribute
#define __has_cpp_attribute(x) 0
#endif
so it will always be 0 for clang in C mode, since that does not define
__has_cpp_attribut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
--- Comment #1 from Iain Sandoe ---
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers
should be a symlink to
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kerne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114030
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |middle-end
--- Comment #2 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
Bug ID: 114052
Summary: Wrong code at -O2 for well-defined infinite loop
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114032
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-02-22
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114053
Bug ID: 114053
Summary: GCC accepts initialization of array with another
static data member array in member initializer list
Product: gcc
Version: 14.0
Status: UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114053
--- Comment #1 from Jason Liam ---
Demo https://godbolt.org/z/GWr5dn9Kr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Miles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114041
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114053
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59465
Andrew Pinski changed:
What|Removed |Added
CC||jlame646 at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59465
Andrew Pinski changed:
What|Removed |Added
Summary|g++ allows |[11/12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114032
--- Comment #3 from Jakub Jelinek ---
In GCC 13 and earlier, .CLZ(0) was UB depending on CLZ_VALUE_DEFINED_AT_ZERO
(...) != 2.
In GCC 14, it is always UB, and well defined is only .CLZ(0, 32) (but with the
current
requirement that the second arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114041
--- Comment #3 from Jakub Jelinek ---
I thought graphite is done only after bitint lowering.
At that point, there should be just <= MAX_FIXED_MODE_SIZE BITINT_TYPEs around
in the IL, with the exception of loading SSA_NAMEs from memory in order t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111770
--- Comment #4 from Alex Coplan ---
(In reply to Richard Biener from comment #3)
> As said X + 0. -> X is an invalid transform with FP unless there are no
> signed zeros (maybe also problematic with sign-dependent rounding).
Yeah, I was thinkin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
--- Comment #2 from Sam James ---
Created attachment 57494
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57494&action=edit
test.c
Attaching godbolt testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114054
Bug ID: 114054
Summary: ICE: in reduce_to_bit_field_precision, at
expr.cc:12658 with -Og -fwhole-program -fno-tree-ccp
-fprofile-use -fno-tree-copy-prop and _BitInt()
Produ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114055
Bug ID: 114055
Summary: poor error message generated during when checking the
BY constant expression type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114056
Bug ID: 114056
Summary: ifcvt may introduce use of uninitialized variables
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114055
Gaius Mulley changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114040
--- Comment #3 from Zdenek Sojka ---
Created attachment 57496
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57496&action=edit
probaly related testcase
$ x86_64-pc-linux-gnu-gcc -O2 testcase2.c
$ ./a.out
Aborted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114043
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Sandoe ---
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers
> should be a symlink to
> /Library/Develo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114044
--- Comment #2 from Richard Biener ---
Only DCE removes these kind of stmts. RTL expansion needs to be forgiving here
but I guess it's bitint lowering failing to catch this call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114048
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960
--- Comment #11 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a0782531b8270f0fdb3f3e09b4ce544d5d1eef14
commit r14-9133-ga0782531b8270f0fdb3f3e09b4ce544d5d1eef14
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114056
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027
--- Comment #15 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:549f251f055e3a0b0084189a3012c4f15d635e75
commit r14-9134-g549f251f055e3a0b0084189a3012c4f15d635e75
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
Richard Biener changed:
What|Removed |Added
Component|c |tree-optimization
Status|N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #7 from Jonathan Wakely ---
And the first item at https://gcc.gnu.org/bugs/#nonbugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #8 from Søren Jæger Hansen ---
I get all this, and thanks for quick processing. Still I think it's a bit odd
that -std=c++* and -std?=gnu++* gives different results, but I assume there's a
good reason for that.
We'll be using -std=g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #9 from Jonathan Wakely ---
See the first item at https://gcc.gnu.org/gcc-13/changes.html#cxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #10 from Søren Jæger Hansen ---
-fexcess-precision=fast it is for now then, thanks again for fast feedback.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114028
--- Comment #2 from Robin Dapp ---
This is a target issue. It looks like we try to construct a "superword"
sequence when the element size is already == Pmode. Testing a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114040
--- Comment #4 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #2)
> ` -fdisable-tree-evrp -fdisable-tree-vrp1` also fixes it.
>
> EVRP and VRP1 changes:
> _3 = IMAGPART_EXPR <_8>;
> _4 = (_Bool) _3;
> _5 = (unsigned _BitIn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #126 from John Paul Adrian Glaubitz ---
I'm retesting a native build with LRA enabled by default now and report back.
If that works, I will try to build and boot a kernel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960
--- Comment #13 from Jan Hubicka ---
> Should be fixed now.
Thanks! I was testing with stage3 compiler, so that is the reason.
Indeed dropping the buffer is a good idea.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114040
--- Comment #5 from Jakub Jelinek ---
Ah, there is one difference, for the
unsigned
foo (unsigned _BitInt(8671) x, unsigned y, unsigned _BitInt(512) z)
{
unsigned _BitInt (8671) r
= x * __builtin_sub_overflow_p (y * z, 0, (unsigned _BitInt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
--- Comment #3 from Iain Sandoe ---
so .. if i follow your discussion correctly - neither clang nor gcc finds it
because it's incorrectly quoted (is that an SDK issue?).. or?
We do have control, IIRC, about adding the frameworks search path to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111770
--- Comment #5 from Richard Biener ---
(In reply to Alex Coplan from comment #4)
> (In reply to Richard Biener from comment #3)
> > Now, if-conversion could indeed elide the .COND_ADD for integers. It's
> > problematic there only because of sig
1 - 100 of 205 matches
Mail list logo
