https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103066
--- Comment #1 from Hongyu Wang ---
__sync_val_compare_and_swap will be expanded to atomic_compare_exchange_strong
by default, should we restrict the check and return under
atomic_compare_exchange_weak which is allowed to fail spuriously?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102991
--- Comment #7 from luoxhu at gcc dot gnu.org ---
Fixed, will backport to gcc-11 in a week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102991
--- Comment #6 from CVS Commits ---
The master branch has been updated by Xiong Hu Luo :
https://gcc.gnu.org/g:614b39757b8b61f70ac1c666edb7a01a5fc19cd4
commit r12-4930-g614b39757b8b61f70ac1c666edb7a01a5fc19cd4
Author: Xionghu Luo
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101337
sandra at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102714
--- Comment #10 from Bo Duan ---
(In reply to Richard Biener from comment #7)
> (In reply to Bo Duan from comment #6)
> > Hello, should we backport this patch to gcc-10?
>
> It's scheduled for a backport to GCC 11, I'm not aware that GCC 10 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103090
--- Comment #1 from Thiago Macieira ---
One more:
bool tsign3(std::atomic )
{
// any two or more bits, so long as the sign bit is one of them
// (or the compiler doesn't know what's in the variable)
int bits = 1 | signbit;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967
--- Comment #7 from Martin Sebor ---
Both for the purposes of the warning (which can be more restrictive than what
the language considers valid), and in the C language, the semantics of the ->
expression depend on the first operand designating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55227
--- Comment #11 from Will Wray ---
Created attachment 51737
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51737=edit
Proposed patch Nov 4
Sent to gcc-patches for review
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583379.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086
--- Comment #3 from Jonathan Wakely ---
Fixed on trunk so far.
The fix needs to be backported to gcc-11 because std::tuple uses
[[no_unique_address]] there, so the bug is present.
I think it's also present on older branches, but would only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:a634928f5c8a281442ac8f5fb1636aed048ed72c
commit r12-4928-ga634928f5c8a281442ac8f5fb1636aed048ed72c
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086
--- Comment #1 from Jonathan Wakely ---
This affects the filesystem::path printer too:
impl = self.val['_M_cmpts']['_M_impl']['_M_t']['_M_t']['_M_head_impl']
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103069
--- Comment #2 from Thiago Macieira ---
See also bug 103090 for a few more (restricted) possibilities to replace a
cmpxchg loop with a LOCK RMW operation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #29 from Thiago Macieira ---
New suggestion in bug 103090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103090
Bug ID: 103090
Summary: [i386] GCC should use the SF and ZF flags in some
atomic_fetch_op sequences
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103089
xantares09 at hotmail dot com changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103089
--- Comment #2 from xantares09 at hotmail dot com ---
indeed, I assumed both were positive, I guess there's no bug then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103089
--- Comment #1 from Andrew Pinski ---
If I add:
if (n <= 0 || m <= 0) __builtin_unreachable();
before the malloc, I get no warning.
I think the warning is correct if either n or m is negative.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97121
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103089
Bug ID: 103089
Summary: -Wmaybe-uninitialized -O2 false positive
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
Bug ID: 103088
Summary: [12 regression] 500.perlbench from spec 2017 fails
since r12-4698
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
seurer at gcc dot gnu.org changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103073
--- Comment #6 from Martin Liška ---
> BTW, should I add new bugs to the meta-bug before or after they were
> confirmed?
Right after you create it I would say.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103082
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103085
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103058
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #6)
> Looking at the particular ICE, this looks like a fortran frond-end issue -
> this is during compilation and not during link and I do not see why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102869
Patrick Palka changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #8 from Aaron Ballman ---
(In reply to M Welinder from comment #6)
> elaborated-enum-specifier can be a elaborated-type-specifier. It is in the
> "enum Hog H;" case.
>
> But elaborated-enum-specifier is NOT an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #7 from M Welinder ---
Maybe kick it up to the C++ people?
Note, that if the code is not allowed then a type alias is no longer as
powerful as the original type. I really doubt that was intended.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102981
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #4 from Jeffrey A. Law
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #6 from M Welinder ---
elaborated-enum-specifier can be a elaborated-type-specifier. It is in the
"enum Hog H;" case.
But elaborated-enum-specifier is NOT an elaborated-type-specifier in the "using
enum Hog;" case,
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #5 from Aaron Ballman ---
(In reply to Marek Polacek from comment #4)
> But elaborated-enum-specifier is an elaborated-type-specifier, so
> [dcl.type.elab]#6 should still apply, right?
That is my understanding. Otherwise p6 doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #4 from Marek Polacek ---
But elaborated-enum-specifier is an elaborated-type-specifier, so
[dcl.type.elab]#6 should still apply, right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028
--- Comment #3 from Andreas Krebbel ---
So I think what is needed is something like this:
diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index 017944f4f79a..1f5b9476ac2e 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -4341,7 +4341,8 @@ find_if_header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #3 from M Welinder ---
I actually think gcc is right there.
http://eel.is/c++draft/dcl.type.elab#nt:elaborated-enum-specifier
There are requirements for elaborated-type-specifier, but none for
elaborated-enum-specifier. It's a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103073
Jan Hubicka changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103070
Jan Hubicka changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
Marek Polacek changed:
What|Removed |Added
CC||terra at gnome dot org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103087
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103087
Bug ID: 103087
Summary: "using enum" possibly incorrectly accepted
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086
Jonathan Wakely changed:
What|Removed |Added
Known to fail||11.2.1, 12.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086
Bug ID: 103086
Summary: [11/12 Regression] std::unique_ptr printer gets
confused by [[no_unique_address]] in tuple
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
--- Comment #11 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:004afb984beb6efbe25f44a5857b1c27ebc2ec82
commit r12-4921-g004afb984beb6efbe25f44a5857b1c27ebc2ec82
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103085
Bug ID: 103085
Summary: [12 Regression] -fPIC and -fstack-protector-strong
broken AArch64
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #48 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:1ece90ffa9ce63b416296bd662b8117d9b538913
commit r12-4920-g1ece90ffa9ce63b416296bd662b8117d9b538913
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
Bug ID: 103084
Summary: Accepts invalid using enum declaration with an invalid
elaborated-type-specifier
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103073
--- Comment #4 from Vsevolod Livinskiy ---
(In reply to Martin Liška from comment #2)
> Started with r12-4401-gfecd145359fc981b.
>
> @Vsevolod: Is it a yarpgen test-case?
Yes. I've added stencil support recently, but it was a surprise to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103058
Jan Hubicka changed:
What|Removed |Added
Component|ipa |fortran
--- Comment #6 from Jan Hubicka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #19 from hubicka at kam dot mff.cuni.cz ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
>
> Aldy Hernandez changed:
>
>What|Removed |Added
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
>
> Aldy Hernandez changed:
>
>What|Removed |Added
>
> Depends on||103058
>
> --- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103082
Jan Hubicka changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967
--- Comment #6 from Andreas Schwab ---
&*E is allowed for E == NULL, but I don't think this can be generalized to
>m.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102961
--- Comment #3 from John Parke ---
I think the problem is caused by:
>> 0711-738 ERROR: Input file /usr/gcc-11.2.0-build/./gcc/ppc64/crtcxa_s.o:
See below:
XCOFF32 object files are not allowed in 64-bit mode.
# @multilib_flags@ is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103058
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:d3f7a2fa64f8777cb7eae1b99ff80fbe717095ac
commit r12-4914-gd3f7a2fa64f8777cb7eae1b99ff80fbe717095ac
Author: Jan Hubicka
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967
--- Comment #5 from jbeulich at suse dot com ---
(In reply to Martin Sebor from comment #4)
> The expression pa->c is only valid if pa points to a valid object.
Well, yes, you may not deref pa if it's NULL, i.e. I agree for pa->c. But is
>c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967
--- Comment #4 from Martin Sebor ---
The expression pa->c is only valid if pa points to a valid object.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103058
--- Comment #4 from hubicka at kam dot mff.cuni.cz ---
Hi,
I am testing the following to unbreak fortran.
However the real bug is that binds_to_current_def should work on whole
WPA and be independent of partitioning. I remember I had patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103083
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103083
Martin Liška changed:
What|Removed |Added
Summary|Wrong code due to ipa-cp's |[10/11/12 Regression] Wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
Aldy Hernandez changed:
What|Removed |Added
Depends on||103058
--- Comment #18 from Aldy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103083
Bug ID: 103083
Summary: Wrong code due to ipa-cp's value range propagation
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081
--- Comment #4 from M Welinder ---
That version of clang does not do "using enum" at all. clang 13 accepts this
code, but it has other issues with "using enum".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103080
--- Comment #3 from Iain Sandoe ---
(In reply to hubicka from comment #1)
> The cdtor merging code is predating LTO - it is also used for collect2
> path on targets w/o cdtor sections.
Even so, I do not see how it can work there either*** -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101715
--- Comment #12 from Marek Polacek ---
OK, I'd totally forgotten about this PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103082
Martin Liška changed:
What|Removed |Added
Known to fail||12.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103082
Bug ID: 103082
Summary: [12 Regression] gcc/poly-int.h:1162:5: runtime error:
left shift of negative value -40
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081
--- Comment #3 from Richard Biener ---
Confirmed on the GCC 11 branch head and trunk. clang complains:
> clang++-11 -S t.C -std=c++20
t.C:4:9: error: expected unqualified-id
using enum Pig;
^
t.C:10:18: error: no member named 'OINK'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081
--- Comment #2 from Marek Polacek ---
Started with r11-5003.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103080
--- Comment #2 from Richard Biener ---
IIRC there is also an older bug about CTOR/DTOR order across multiple TUs where
with -flto be behave differently than without where I said it might be nice to
preserve linker command line order (we have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103072
--- Comment #3 from Jeremy R. ---
(In reply to Jakub Jelinek from comment #1)
> So maybe the switchconv pass could be
> improved not to do just the linear etc. expression handling, but also
> consider code sequences that are the same except for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #17 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:6a9678f0b30d36ae13259ad635e175a1e24917a1
commit r12-4905-g6a9678f0b30d36ae13259ad635e175a1e24917a1
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #16 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:e4411622690654cdc530c6262c7115a9e15dc359
commit r12-4904-ge4411622690654cdc530c6262c7115a9e15dc359
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #15 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:5ea1ce43b6070aaa94882e8b15f3340344aaa6b2
commit r12-4903-g5ea1ce43b6070aaa94882e8b15f3340344aaa6b2
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081
Bug ID: 103081
Summary: [ICE] with "using enum"
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103080
--- Comment #1 from hubicka at kam dot mff.cuni.cz ---
The cdtor merging code is predating LTO - it is also used for collect2
path on targets w/o cdtor sections.
I guess the DECL_UID compare is not very safe things to do since it
depends on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103042
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103080
Bug ID: 103080
Summary: LTO alters the ordering of static
constructors/destructors in pass_ipa_cdtor_merge.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103042
--- Comment #3 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:5914a7b5c637c9007283226f200dcab8b745abc8
commit r12-4900-g5914a7b5c637c9007283226f200dcab8b745abc8
Author: Tamar Christina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
--- Comment #10 from Andrew Macleod ---
That patch wont generally work until rangeops op1_range routines are adjusted
to deal with undefined being passed in.. I think it assumes until now that its
been trimmed out.
(In reply to Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
--- Comment #9 from Andrew Macleod ---
Created attachment 51735
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51735=edit
patch for the undefined bit
(In reply to Richard Biener from comment #7)
> === BB 2
> Imports:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103042
Tamar Christina changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101981
Martin Liška changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103072
--- Comment #2 from Martin Liška ---
Or we can alternatively merge all the case blocks into one..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103075
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103075
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:d13603501680fcdbb933cb086cd01fcc39be1908
commit r12-4898-gd13603501680fcdbb933cb086cd01fcc39be1908
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
--- Comment #8 from Richard Biener ---
Btw, I find the vrp-details dump not really useful with all the ranger
"debug" appearing _after_ the folding of stmts. Can we instead have
this somehow interleaved?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
--- Comment #7 from Richard Biener ---
=== BB 2
Imports: b.0_1 t_4(D)
Exports: b.0_1 t_4(D) _6
_6 : b.0_1(I) t_4(D)(I)
t_4(D) UNDEFINED
[local count: 176285970]:
b.0_1 = b;
_6 = b.0_1 | t_4(D);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967
jbeulich at suse dot com changed:
What|Removed |Added
CC||jbeulich at suse dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103062
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103062
--- Comment #2 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:bb27f5e9ec3c7ab0f5c859d90c59dd4573b53d97
commit r12-4891-gbb27f5e9ec3c7ab0f5c859d90c59dd4573b53d97
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103051
--- Comment #4 from Martin Liška ---
All right, so I would ideally use:
/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target {
has_arch_pwr7 } } } } */
but I see the following problem with detection of the target:
78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103011
--- Comment #8 from Pekka S ---
Created attachment 51734
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51734=edit
For CPP_FOR_BUILD use $(CC_FOR_BUILD) -E instead of $(CPP).
The problem is that when $(CPP) is not defined it is set to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103073
Jan Hubicka 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=103079
--- Comment #6 from Andrew Pinski ---
VRP2:
Predicate evaluates to: DON'T KNOW
Matching expression match.pd:1972, gimple-match.c:819
Matching expression match.pd:1975, gimple-match.c:892
Matching expression match.pd:1982, gimple-match.c:952
Not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102460
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
--- Comment #5 from Martin Liška ---
> static int c() {
> if (b)
> return b;
> }
Yes, one can use the return value as long as the function returns a value.
This means, c() can be used iff b != 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> The problem is latent though. The issue is reassociatation introduces an
> unconditional use of an uninitilized vairable:
Whoops that is not the issue here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
--- Comment #3 from Andrew Pinski ---
The problem is latent though. The issue is reassociatation introduces an
unconditional use of an uninitilized vairable:
Before
if (b.1_3 != 0)
goto ; [34.00%]
else
goto ; [66.00%]
[local
1 - 100 of 131 matches
Mail list logo
