http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59420
--- Comment #4 from Alexander Holler ---
Thanks a lot for the very fast solution.
I wasn't aware that gcc does such optimizations and maybe posted the bug too
fast without really having examined the assembler.
Using -fno-tree-loop-distribute-pat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419
--- Comment #3 from Jerry DeLisle ---
I will take this one if you like.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59300
--- Comment #1 from Rafael Avila de Espindola ---
clang had an even stranger behavior
(http://llvm.org/bugs/show_bug.cgi?id=18174). I fixed that in a way that it now
agrees with gcc on the testcase in this bug.
It would still be nice to know if t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59421
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> Do you have a full testcase that is able to compile and work?
s/work/run/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59421
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59420
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Component|c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59420
--- Comment #2 from Richard Earnshaw ---
You'll get more attention paid to this if you can describe why you think the
code generated is incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59421
Bug ID: 59421
Summary: stof(), stod() wrong result
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
As
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59420
--- Comment #1 from Alexander Holler ---
Created attachment 31397
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31397&action=edit
memset.s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59420
Bug ID: 59420
Summary: arm: broken code generated (memset from newlib 2.0)
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419
Tobias Burnus changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419
Bug ID: 59419
Summary: [4.9 Regression] Failing OPEN with FILE='xxx' and
IOSTAT creates the file 'xxx' after revision 196783
Product: gcc
Version: 4.9.0
Status: UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #11 from janus at gcc dot gnu.org ---
r205785 fixes the original error (i.e. comment 1). ToDo: The ICE regression of
comment 3.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #10 from janus at gcc dot gnu.org ---
Author: janus
Date: Sat Dec 7 19:27:19 2013
New Revision: 205785
URL: http://gcc.gnu.org/viewcvs?rev=205785&root=gcc&view=rev
Log:
2013-12-07 Janus Weil
PR fortran/59414
* resolve.c (r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #14 from H.J. Lu ---
(In reply to H.J. Lu from comment #13)
> loop in Perl_pp_aassign is miscompiled:
>
> 44098a: e8 91 38 05 00 callq 494220
> 44098f: 67 89 03mov%eax,(%ebx)
> 440992:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #13 from H.J. Lu ---
loop in Perl_pp_aassign is miscompiled:
44098a: e8 91 38 05 00 callq 494220
44098f: 67 89 03mov%eax,(%ebx)
440992: 83 c3 04add$0x4,%ebx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59411
--- Comment #3 from janus at gcc dot gnu.org ---
In F03, I think the relevant quotes are:
R506 initialization is = initialization-expr
or => null-init
7.1.7 Initialization expression
An initialization expression is an expressi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Severity|blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59411
--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to janus from comment #1)
> One should check the
> Fortran standard for restrictions in the case of C_PTRs (which, strictly
> speaking, are no actual pointers in the Fortran sense).
Since
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59411
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #12 from H.J. Lu ---
This function:
SV *
sv_mortalcopy(SV *oldstr)
{
dTHR;
register SV *sv;
new_SV(sv);
SvANY(sv) = 0;
SvREFCNT(sv) = 1;
SvFLAGS(sv) = 0;
sv_setsv(sv,oldstr);
if (++PL_tmps_ix >= PL
-threads=posix --enable-symvers=gnu --enable-c99
--enable-long-long --enable-target-optspace
target_alias=arm-unknown-linux-gnueabi --enable-languages=c++ --disable-shared
--disable-libmudflap --disable-libssp --enable-checking
Thread model: posix
gcc version 4.9.0 20131207 (experimental) [trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #11 from H.J. Lu ---
latch execution count can be an expression like "if (b)" in
gcc.dg/torture/pr59058.c. Will such an expression be possible
negative at run-time?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #10 from H.J. Lu ---
(In reply to rguent...@suse.de from comment #9)
> >
> >Is that ever possible to have latch execution count < 0
> >and FIRST_NITERS == 0? It happens in x32 253.perlbmk.
>
> That should be impossible.
>
That is wh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #9 from rguenther at suse dot de ---
"hjl.tools at gmail dot com" wrote:
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
>
>--- Comment #8 from H.J. Lu ---
>(In reply to rguent...@suse.de from comment #7)
>> "hjl.tools at gmail do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58864
--- Comment #10 from Jakub Jelinek ---
Author: jakub
Date: Sat Dec 7 15:43:48 2013
New Revision: 205784
URL: http://gcc.gnu.org/viewcvs?rev=205784&root=gcc&view=rev
Log:
PR target/58864
* optabs.c (emit_conditional_move): Save and restor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59011
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Sat Dec 7 15:43:05 2013
New Revision: 205783
URL: http://gcc.gnu.org/viewcvs?rev=205783&root=gcc&view=rev
Log:
PR middle-end/59011
* gimplify.c (nonlocal_vla_vars): New variable.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59011
--- Comment #7 from Mikael Pettersson ---
It appears the test case wasn't added to 4.8 branch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #8 from janus at gcc dot gnu.org ---
The patch in comment 2 regtests cleanly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
Summar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #7 from Dominique d'Humieres ---
The issue of comment 3 appeared between revisions 187190 (2012-05-05) and
187198 (actually 187193 and I'ld bet for 187192).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59417
Markus Trippelsdorf changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: antoine.balestrat at gmail dot com
Hi !
I'm using GCC 4.9 20131207.
$ cat deter.c
int a, b, d;
short c;
void f(void)
{
if(b)
{
int *e;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to Antony Lewis from comment #5)
> The sourced allocate errors crop up in various places in the full code, and
> already seem to be known in several bug reports, e.g.
> http://gcc.gnu.org/b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #5 from Antony Lewis ---
Thanks for the quick fix!
The sourced allocate errors crop up in various places in the full code, and
already seem to be known in several bug reports, e.g.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672
Fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #4 from janus at gcc dot gnu.org ---
Btw, when using the second (commented-out) version of 'AddArray' (which
apparently crashes with ifort), the full code in comment 0 compiles cleanly
with gfortran trunk plus the patch in comment 2.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
> With the patch the reduced test case in comment 1 compiles cleanly, but the
> full code in comment 0 then gives an ICE on a different location:
>
> ObjectLists.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59416
Bug ID: 59416
Summary: A nested template reusing the template arguments of
the enclosing type in a template template argument not
working
Product: gcc
Version: 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #2 from janus at gcc dot gnu.org ---
This draft patch fixes the error (but has not been regtested yet):
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56686
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #26 from H.J. Lu ---
(In reply to Kostya Serebryany from comment #25)
> > https://bugzilla.kernel.org/show_bug.cgi?id=66721
>
> Good! Looking forward for a fix and hoping to have it in the next Ubuntu LTS.
> Any chance?
> Is there an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19970
Kai Tietz changed:
What|Removed |Added
Status|NEW |WAITING
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #8 from H.J. Lu ---
(In reply to rguent...@suse.de from comment #7)
> "hjl.tools at gmail dot com" wrote:
> >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
> >
> >--- Comment #3 from H.J. Lu ---
> >slpeel_tree_peel_loop_to_edge ha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
Statu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18649
--- Comment #10 from Kai Tietz ---
For mingw-code this bug is fixed. It was caused by a bug in SjLj catch-reason.
Issue is fixed for 32-bit and 64-bit mingw targets for all open branches.
As report was for different targets, it would be good if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52898
--- Comment #8 from Kazumoto Kojima ---
I'm OK with it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #7 from rguenther at suse dot de ---
"hjl.tools at gmail dot com" wrote:
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
>
>--- Comment #3 from H.J. Lu ---
>slpeel_tree_peel_loop_to_edge has comments:
>
> The first guard is:
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52898
--- Comment #7 from Oleg Endo ---
Kaz, I'd like to deprecate the mcbranchdi and mcmpeqdi options in 4.9 and make
the current default values fixed as follows:
mcbranchdi is usually enabled (it gets disabled in some SH5 case in
sh_option_override).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #25 from Kostya Serebryany ---
> https://bugzilla.kernel.org/show_bug.cgi?id=66721
Good! Looking forward for a fix and hoping to have it in the next Ubuntu LTS.
Any chance?
Is there anything else we could do with this tsan issue?
(gi
51 matches
Mail list logo
