https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61942
--- Comment #2 from Vittorio Zecca ---
This is what I get on x86-64 with a sanitized version of gcc:
~/local/gcc-4.9.1-sanitized/bin/gcc -S gccerr12.c -funroll-loops -O3
../../gcc-4.9.1/gcc/loop-iv.c:2272:24: runtime error: signed integer overf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61900
--- Comment #2 from Vittorio Zecca ---
This happens when I build gcc itself with option -fsanitize=undefined,
at build time, in directory x86_64-unknown-linux-gnu/32/libgcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63188
--- Comment #8 from mrs at gcc dot gnu.org ---
Author: mrs
Date: Sat Sep 6 05:17:10 2014
New Revision: 214983
URL: https://gcc.gnu.org/viewcvs?rev=214983&root=gcc&view=rev
Log:
2014-09-05 Dominique Dhumieres
PR target/63188
* config
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63148
Doug Gilmore changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62255
--- Comment #8 from Jason Merrill ---
And here's a reduced testcase that GCC and EDG reject, but clang accepts.
template struct Test {
template static void check(typename X::Undefined *);
template static int &check(...);
static const in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62146
--- Comment #3 from eraman at gcc dot gnu.org ---
Author: eraman
Date: Sat Sep 6 01:49:07 2014
New Revision: 214981
URL: https://gcc.gnu.org/viewcvs?rev=214981&root=gcc&view=rev
Log:
2014-09-05 Easwaran Raman
Backport from mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63188
Mike Stump changed:
What|Removed |Added
CC||mikestump at comcast dot net
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62255
--- Comment #7 from Jason Merrill ---
The problem with this testcase is that in evaluating
arma::is_Mat_fixed_only, arma::eop_exp> >::value we
need to look up check, arma::eop_exp>>, which means
looking up arma::eOp, arma::eop_exp>::Mat_fixed_typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62146
--- Comment #2 from eraman at gcc dot gnu.org ---
Author: eraman
Date: Fri Sep 5 22:23:26 2014
New Revision: 214977
URL: https://gcc.gnu.org/viewcvs?rev=214977&root=gcc&view=rev
Log:
2014-09-05 Easwaran Raman
PR rtl-optimization/6214
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62270
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63156
--- Comment #7 from Steven Bosscher ---
(In reply to Carrot from comment #6)
> Since it is intentionally to remove flag DF_REF_READ_WRITE on use,
Ah, but I don't think that was the correct fix. The DEF and USE refs should
both have the flag set.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63186
--- Comment #1 from Jakub Jelinek ---
For the case when any of the bbs considered for being split (into
function.part.N) refers to a label which is defined in one of the basic blocks
that are not considered for split we already kind of have code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63188
--- Comment #6 from Dominique d'Humieres ---
testing finished without regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63192
Bug ID: 63192
Summary: non-mutable lambda capture by value on reference does
not apply const
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191
Bug ID: 63191
Summary: 32-bit gcc uses excessive memory during dead store
elimination with -fPIC
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63187
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63187
--- Comment #1 from Segher Boessenkool ---
Author: segher
Date: Fri Sep 5 19:17:08 2014
New Revision: 214976
URL: https://gcc.gnu.org/viewcvs?rev=214976&root=gcc&view=rev
Log:
2014-09-05 Segher Boessenkool
PR target/63187
* config/r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
--- Comment #9 from R Copley ---
Heh, sorry. I don't really know C, I assumed it had an implicit "return 0;"
like C++. Apparently C99 has this but earlier C standards do not. So, not
bizarre at all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
--- Comment #8 from R Copley ---
No, I use the mingw-builds distro too.
gcc --version
gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 4.9.1
Bizarrely, the attached program exits with a random error code unless I add a
"return 0;" statem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62659
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62659
--- Comment #4 from Jason Merrill ---
Author: jason
Date: Fri Sep 5 18:00:00 2014
New Revision: 214975
URL: https://gcc.gnu.org/viewcvs?rev=214975&root=gcc&view=rev
Log:
PR c++/62659
* semantics.c (potential_constant_expression_1): Hand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62659
--- Comment #3 from Jason Merrill ---
Author: jason
Date: Fri Sep 5 17:59:40 2014
New Revision: 214974
URL: https://gcc.gnu.org/viewcvs?rev=214974&root=gcc&view=rev
Log:
PR c++/62659
* semantics.c (potential_constant_expression_1): Hand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63188
--- Comment #5 from Dominique d'Humieres ---
Bootstrap of revision r214972 with the patch
--- ../_clean/gcc/config/darwin.h2014-06-27 18:25:13.0 +0200
+++ gcc/config/darwin.h2014-09-05 18:28:29.0 +0200
@@ -499,7 +499,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62659
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
--- Comment #9 from Manuel López-Ibáñez ---
(In reply to Manuel López-Ibáñez from comment #5)
> The C++ parser lexes (and preprocesses) before handling the pragmas, whereas
> the C parser processes the pragmas as it sees them.
>
> We must someho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20567
mrs at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20567
Mike Stump changed:
What|Removed |Added
CC||mikestump at comcast dot net
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48914
Manuel López-Ibáñez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
Manuel López-Ibáñez changed:
What|Removed |Added
CC||bero at arklinux dot org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63189
--- Comment #2 from Breton M. Saunders ---
I'm actually showing the same symptoms on Ubuntu 12.04 using virtual-box and
gcc v4.6.3.
Here are the details:
bms20@medivh-lbo-vm:~/LboPlatforms/ti37XX$ uname -a
Linux medivh-lbo-vm 3.8.0-44-generic #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63190
mshawcroft at gcc dot gnu.org changed:
What|Removed |Added
Target||aarch64
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63190
Bug ID: 63190
Summary: Assembler errors when building md5 code from fbb on
aarch64
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62262
mshawcroft at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63188
--- Comment #4 from joseph at codesourcery dot com ---
On Fri, 5 Sep 2014, dominiq at lps dot ens.fr wrote:
> > INIT_SECTION_ASM_OP is meant to be a string constant, not empty. Try
> > defining it to "". I suppose the cases in libgcc that act
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63188
--- Comment #3 from Dominique d'Humieres ---
> INIT_SECTION_ASM_OP is meant to be a string constant, not empty. Try
> defining it to "". I suppose the cases in libgcc that actually use the
> string constant value inside asm, rather than just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63188
--- Comment #2 from joseph at codesourcery dot com ---
INIT_SECTION_ASM_OP is meant to be a string constant, not empty. Try
defining it to "". I suppose the cases in libgcc that actually use the
string constant value inside asm, rather than j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62255
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63189
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63189
Bug ID: 63189
Summary: Incorrect results from trivial loop when optimized
with O3 or O2+tree vectorization
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63188
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63188
Bug ID: 63188
Summary: [5 Regression] r214954 breaks bootstrap on
x86_64-apple-darwin13
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: blocker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63187
Bug ID: 63187
Summary: Unrecognizable insn ICE due to revision 214080
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62659
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |4.9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245
--- Comment #12 from vondele at gcc dot gnu.org ---
Author: vondele
Date: Fri Sep 5 13:40:05 2014
New Revision: 214958
URL: https://gcc.gnu.org/viewcvs?rev=214958&root=gcc&view=rev
Log:
PR fortran/62245
* intrinsic.texi (INT): cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #2 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> Hm? The PHI does post-dominate the memset. I think you run into another
> check, namely we visited the call already (temp != NULL).
Oups... The original testcas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63186
Bug ID: 63186
Summary: [4.9/5 Regression] Undefined .L* symbols because of
fnsplit
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58734
--- Comment #2 from Roger Ferrer Ibanez ---
Hi,
g++ 4.9.1. does not fail anymore with this one.
I guess it was already been fixed.
Kind regards,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
--- Comment #42 from Richard Biener ---
With the proposed patch (with a tiny fix) I get:
(compute_affine_dependence
stmt_a: _23 = MEM[(real(kind=8)[0:D.2444] *)&x clique 1 base 4][_20];
stmt_b: _112 = MEM[(real(kind=8)[0:D.2444] *)&x clique
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62659
Conrad changed:
What|Removed |Added
CC||conradsand.arma at gmail dot
com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38354
--- Comment #5 from Jonathan Wakely ---
(In reply to Adam Warner from comment #4)
> Why can a compile-time array of 32-bit function pointers (compatible with
> the non-large code model) be compiled using g++ but not gcc?
The C standard is much m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57248
--- Comment #6 from Paolo Carlini ---
Sorry, I made a mistake, the original testcase with replaced by the
code in Comment #3 is still rejected. However, it's true that all the up to
date compilers I have at hand reject it with the same kind of e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35290
Marc Glisse changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
Bug ID: 63185
Summary: Improve DSE with branches
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57248
Paolo Carlini changed:
What|Removed |Added
CC||paolo.carlini at oracle dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175
Dominique d'Humieres changed:
What|Removed |Added
Target|powerpc-linux-gnu |powerpc*-*-*
Status|U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38354
--- Comment #4 from Adam Warner ---
Why can a compile-time array of 32-bit function pointers (compatible with the
non-large code model) be compiled using g++ but not gcc?
$ g++ -fpermissive computable_at_load_time.c
computable_at_load_time.c:9:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59676
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57979
Paolo Carlini changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 59676, which changed state.
Bug 59676 Summary: Non-integral glvalues accepted in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59676
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63181
--- Comment #2 from Jonathan Wakely ---
N.B. that's not a temporary, it's a named lvalue, but we should definitely
diagnose it.
Since 4.7 GCC does now diagnose similar cases with temporaries resulting from
implicit conversions:
struct Foo {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63157
--- Comment #3 from Richard Biener ---
(In reply to haynberg from comment #2)
> I recently read your old PR about placement new -
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286.
>
> Is using placement new also a means to prevent strict-ali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175
Richard Biener changed:
What|Removed |Added
Component|regression |testsuite
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63177
--- Comment #3 from Richard Biener ---
The version-for-alias code makes choices dependent on ordering of data
references
which changes from time to time. I've repeatedly tried to clean up the code
but only manage to break more testcases where th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63179
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63181
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63182
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63148
--- Comment #9 from Richard Biener ---
Fixed on trunk the "right" way, still pondering of the best way to fix it on
the branches. (aka less intrusive)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63184
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63184
Bug ID: 63184
Summary: [4.8/4.9/5 Regression] Fails to simplify comparison
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63148
--- Comment #8 from Richard Biener ---
Author: rguenth
Date: Fri Sep 5 08:23:32 2014
New Revision: 214941
URL: https://gcc.gnu.org/viewcvs?rev=214941&root=gcc&view=rev
Log:
2014-09-05 Richard Biener
PR middle-end/63148
* fold-const.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63182
Dominique d'Humieres changed:
What|Removed |Added
Target|hppa2.0w-hp-hpux11.11 |hppa2.0w-hp-hpux11.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63148
Richard Biener changed:
What|Removed |Added
CC|rguenther at suse dot de |
--- Comment #7 from Richard Bie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #6 from Dominik Vogt ---
I'll submit a fix for this problem as soon as I figure out what to do with the
patch.
74 matches
Mail list logo
