https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102920
--- Comment #3 from Richard Biener ---
So the "logic" is that
# var_120_lsm.9_7 = PHI <_42(6), _29(D)(5)>
# var_123_lsm.11_13 = PHI <_26(D)(6), _1(5)>
can be considered equal since _42 and _26(D) are optimistically equal and
_29(D) and _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102921
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102921
--- Comment #3 from Jakub Jelinek ---
--- gcc/cp/call.c.jj2021-10-21 16:06:42.231940456 +0200
+++ gcc/cp/call.c 2021-10-25 10:20:00.970635564 +0200
@@ -12735,7 +12735,9 @@ set_up_extended_ref_temp (tree decl, tre
/* If the initiali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102920
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:aa15952d646fd5dd569fce287b719a737ae66e4f
commit r12-4650-gaa15952d646fd5dd569fce287b719a737ae66e4f
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102920
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102916
--- Comment #7 from Jonathan Wakely ---
C++23 is making these constexpr anyway so I'm not very inclined to change this
now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102916
--- Comment #8 from Jonathan Wakely ---
And we already have a bug report about the presence of constexpr being
non-conforming. IIRC the conclusion has been "yes, but it's more useful to
support this than to strictly conform".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102922
Bug ID: 102922
Summary: [12 Regression] Wrong code at -O3 caused by
r12-4625-gfe8475c500939011
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: wrong-c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102922
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102922
Martin Liška changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102902
--- Comment #2 from Martin Liška ---
*** Bug 102922 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
Bug ID: 102923
Summary: [12 Regression] powerpc64 (BE) linux all languages
bootstrap broken after libffi 3.4.2 import.
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102902
--- Comment #3 from Martin Liška ---
I guess fixed with:
commit aa15952d646fd5dd569fce287b719a737ae66e4f (HEAD -> master, origin/trunk,
origin/master, origin/HEAD)
Author: Richard Biener
Date: Mon Oct 25 09:33:15 2021 +0200
tree-optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102918
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
Richard Biener changed:
What|Removed |Added
Target||powerpc64-linux
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102464
--- Comment #9 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:1a07bc9cda77b1211e95ae295b30e46c0d9ee222
commit r12-4651-g1a07bc9cda77b1211e95ae295b30e46c0d9ee222
Author: liuhongt
Date: Mon Oct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102902
--- Comment #4 from Martin Liška ---
(In reply to Martin Liška from comment #3)
> I guess fixed with:
>
> commit aa15952d646fd5dd569fce287b719a737ae66e4f (HEAD -> master,
> origin/trunk, origin/master, origin/HEAD)
> Author: Richard Biener
> D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102902
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Depends on|100810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102920
Richard Biener changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102039
qingzhe huang changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24666
Bug 24666 depends on bug 102039, which changed state.
Bug 102039 Summary: another case of template function signature incorrectly
dropping top-level cv-qualifier with function parameter dependent on template
argument
https://gcc.gnu.org/bugzilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102044
qingzhe huang changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24666
Bug 24666 depends on bug 102044, which changed state.
Bug 102044 Summary: another case of template function signature incorrectly
dropping top-level cv-qualifier with function parameter of array of template
function pointer
https://gcc.gnu.org/b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102033
qingzhe huang changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24666
Bug 24666 depends on bug 102033, which changed state.
Bug 102033 Summary: template function signature incorrectly drops top-level
cv-qualifiers causing template specialization failing to match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102897
--- Comment #3 from Kewen Lin ---
The culprit assertion is based on one assumption, for one given VEC_PERM_EXPR
expression, if the type of permutation control vector and the type of
permutation operand is the same, and it's foldable, then it's d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102900
Martin Liška changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
--- Comment #2 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #1)
> But not sure about linux64.S if it doesn't suffer from the same problem.
my bad .. incomplete report:
../../../src-patched/libffi/src/powerpc/linux64.S:173: Er
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102924
Bug ID: 102924
Summary: incorrect output for error "cannot mix operands of
decimal floating and other floating types"
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102916
--- Comment #9 from Jonathan Wakely ---
See pr 49813. Jakub suggests we should remove 'constexpr' for strict modes at
least.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102905
--- Comment #2 from Richard Biener ---
Hmm, so with a cc1 cross to powerpc64-linux and -mcpu=power7 I do see the
correct things in the dump files (but not without -mcpu=power7). Similar
behavior
is for -mvsx vs. -mno-vsx (where it also reproduc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102916
--- Comment #10 from Jonathan Wakely ---
(In reply to Darrell Wright from comment #6)
> Right, mostly it can fall under as-if(if it wasn't explicitly disallowed)
Adding constexpr *is* explicitly disallowed though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102912
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102900
--- Comment #4 from anlauf at gcc dot gnu.org ---
The ICE is resolved by Jose's patch to PR100136, which was just accepted.
It would also need to get backported to 11-branch.
However, a runtime error will remain:
At line 91 of file gcc/testsuit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102910
--- Comment #8 from Tobias Burnus ---
I wonder whether something likewise (using __builtin_alloca) should also be
done in libgomp/testsuite/libgomp.oacc-c-c++-common/loop-gwv-2.c, which
currently uses
"#include " + "alloca".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102925
Bug ID: 102925
Summary: [11.2]ICE with concept of std::convertible_to with
lambda in unevaluated-context
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102905
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:0b028fb4989c2bdfaf474b4493c5926fb40da3c3
commit r12-4660-g0b028fb4989c2bdfaf474b4493c5926fb40da3c3
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102905
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50909
Evan Miller changed:
What|Removed |Added
CC||emmiller at gmail dot com
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102837
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Andrew Pinski ---
> (In reply to Andrew Pinski from comment #1)
>> It is one of the following:
>> g:8088a33df5f62fd6416fb8cb158b791e639aa707
>
> Most likely this o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102926
Bug ID: 102926
Summary: TLS register value is spilled to the stack instead of
reloaded from the system register
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101391
--- Comment #5 from Rainer Orth ---
It would be good if the additional patch could be applied, otherwise 2000+
tests
fail to link.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102927
Bug ID: 102927
Summary: Failure to optimize series of if-else to use array
when possible
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102883
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056
Iain Sandoe changed:
What|Removed |Added
CC||brad.nemanich at amd dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102342
--- Comment #1 from Rainer Orth ---
Created attachment 51660
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51660&action=edit
proposed patch
While testing a recent version of the modula-2 branch
(386e7057d75043439f313085c4cbde8109459915),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102926
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102927
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-10-25
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102927
--- Comment #2 from Martin Liška ---
(In reply to Gabriel Ravier from comment #0)
> int foo(int i) {
> if (i == 0)
> return 52;
> else if (i == 1)
> return 77;
> else if (i == 2)
> return 91;
> else if (i == 3)
> return 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102926
--- Comment #2 from Richard Biener ---
I would also guess that load_tp_hard is slower and the large mnemonic suggests
a larger instruction (ok, but we're risc and thus fixed size instructions?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102926
--- Comment #3 from Ard Biesheuvel ---
(In reply to Andrew Pinski from comment #1)
> I don't think it is a security risk really because all spills then can be
> considered security risks.
I would argue that there is no consensus on that. In fac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102927
--- Comment #3 from Martin Liška ---
> As Richi said, we do the transformation to switch only if we can expand it
> by jump table, bit test or array access.
>
> You can expand this example with:
> --param case-values-threshold=4
and we end up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102927
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100382
--- Comment #6 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:7518e4c2f0758daac5d650d400565cf49ac3c8c5
commit r12-4661-g7518e4c2f0758daac5d650d400565cf49ac3c8c5
Author: Andrew Pinski
Date: Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102908
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:7518e4c2f0758daac5d650d400565cf49ac3c8c5
commit r12-4661-g7518e4c2f0758daac5d650d400565cf49ac3c8c5
Author: Andrew Pinski
Date: Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102908
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102926
--- Comment #4 from Andrew Pinski ---
If anything it is a cost model issue in the back-end.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102927
--- Comment #5 from Gabriel Ravier ---
Um, what ? How is this invalid, exactly ? Are you saying foo is faster than baz
(in which case it seems the opposite optimization should be implemented for baz
and bar), or that this optimization just won't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102927
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102927
--- Comment #7 from Martin Liška ---
(In reply to Gabriel Ravier from comment #5)
> Um, what ? How is this invalid, exactly ? Are you saying foo is faster than
> baz (in which case it seems the opposite optimization should be implemented
> for b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102927
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40748
Andrew Pinski changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102928
Bug ID: 102928
Summary: Template argument deduction when mixing variadic
template with C-style variadic function
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40748
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102925
Andrew Pinski changed:
What|Removed |Added
Depends on||102728
--- Comment #1 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40748
--- Comment #7 from Martin Liška ---
> {
> if (i == 0) return 0;
> if (i == 1) return 1;
> if (i == 2) return 2;
> if (i == 3) return 3;
> if (i == 4) return 4;
> if (i == 5) return 4;
> if (i == 6) retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102929
Bug ID: 102929
Summary: [missed optimization] two ways to
rounddown-to-next-multiple
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
--- Comment #3 from H.J. Lu ---
powerpc64-unknown-linux-gnu works with libffi upstream on
gcc110.fsffrance.org.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102886
--- Comment #3 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:f217e87972a2a207e793101fc05cfc9dd095c678
commit r12-4662-gf217e87972a2a207e793101fc05cfc9dd095c678
Author: Martin Jambor
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102505
--- Comment #7 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:f217e87972a2a207e793101fc05cfc9dd095c678
commit r12-4662-gf217e87972a2a207e793101fc05cfc9dd095c678
Author: Martin Jambor
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102886
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102916
--- Comment #11 from Darrell Wright ---
(In reply to Jonathan Wakely from comment #7)
> C++23 is making these constexpr anyway so I'm not very inclined to change
> this now.
That is good to hear, I thought I had read/heard that there was a lot o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102930
Bug ID: 102930
Summary: equal values appear to be different due to missing
correct rounding in libc
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102836
Rainer Orth changed:
What|Removed |Added
Last reconfirmed||2021-10-25
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102930
--- Comment #1 from Vincent Lefèvre ---
I forgot some information: Debian unstable currently has libc6 2.32-4, where
IBM's code for correct rounding was disabled some time ago. This bug might be
unreproducible with other glibc versions (or other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102835
Rainer Orth changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102930
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102930
--- Comment #3 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #2)
> I think there is nothing that can be done about this, and something like
> this has been there since forever. While perhaps some double routines in
> glibc us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102834
Rainer Orth changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org
Ever con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102907
--- Comment #2 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:2cbfaba60661ebbdfcffe725ab55fbb323e2a187
commit r12-4663-g2cbfaba60661ebbdfcffe725ab55fbb323e2a187
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102907
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102851
--- Comment #2 from hasse.christoph at cern dot ch ---
Created attachment 51661
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51661&action=edit
Preprocessed source
Compile with g++ -O3 -DNDEBUG -g -o tmp.o -c preprocessed.cpp
objdump -d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102926
--- Comment #5 from Ard Biesheuvel ---
Actually, I can reproduce the same behavior without the TLS register, where the
result of a MOVW/MOVT immediate assignment is also spilled to the stack.
int ll[2];
int foo(int);
int bar(void)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #16 from qinzhao at gcc dot gnu.org ---
Created attachment 51662
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51662&action=edit
proposed patch to gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102440
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=102925
--- Comment #2 from qingzhe huang ---
I suspect this is related to template-specialization-related issue because if I
use original implementation of "std::convertible_to" to declare my concept
(https://en.cppreference.com/w/cpp/concepts/converti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102926
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
--- Comment #4 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #1)
> The stvx stuff is guarded by #ifdef __VEC__, so perhaps the lvx stuff should
> be too, or there should be .machine push; .machine power7; ... .machine pop;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
--- Comment #5 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #4)
> > At least in linux64_closure.S, perhaps guarding it with #ifdef __VEC__ might
> > be ok, because the C code will not use that code if __VEC__ isn't defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102931
Bug ID: 102931
Summary: ICE explicit lambda call operator without template
keyword
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102932
Bug ID: 102932
Summary: Wrong implementation of abs with O3
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102932
Tee KOBAYASHI changed:
What|Removed |Added
CC||xtkoba at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102932
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102932
--- Comment #3 from Rajpal Singh ---
(In reply to Tee KOBAYASHI from comment #1)
> Signed integer overflow. You can use -fwrapv.
Thanks ! Yes, it's signed integer overflow, is there any way to catch it
statically at compile time ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|marxin at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102657
--- Comment #4 from Eric Gallager ---
The GNU Coding Standards has a list of targets all Makefiles should have:
https://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18907
Eric Gallager changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720
--- Comment #7 from Eric Gallager ---
The GNU Coding Standards contain an example of a simple way to do this:
https://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets
1 - 100 of 158 matches
Mail list logo
