From: Joseph S. Myers [mailto:jos...@codesourcery.com]
Sent: Tuesday, September 02, 2014 11:29 PM
Identifiers beginning with a single underscore are reserved with file
scope. This means an application cannot provide an external definition of
them, because such an external definition would
On Wed, Sep 3, 2014 at 7:35 AM, Carrot Wei car...@google.com wrote:
Hi
I have following questions about web (pseudo register renaming) pass:
1. It is well known that register renaming is a big help to register
allocation, but in gcc's backend, the web pass is far before RA, there
are about
On Mon, Sep 1, 2014 at 9:14 AM, Peng Fan van.free...@gmail.com wrote:
On 09/01/2014 08:09 AM, Matt Thomas wrote:
On Aug 31, 2014, at 11:32 AM, Joel Sherrill joel.sherr...@oarcorp.com
wrote:
Hi,
I am writing some code and found that system crashed. I found it was
unaligned access which
On 09/02/2014 11:22 PM, James Nelson wrote:
This is error-prone because even though a size parameter is given, the code
in the function has no requirement to enforce it. With a bounded array
type, the prototype looks like this:
buf *foo(char buf[sz], size_t sz);
GCC already has a syntax
On Wed, Sep 3, 2014 at 1:35 AM, Carrot Wei wrote:
1. It is well known that register renaming is a big help to register
allocation, but in gcc's backend, the web pass is far before RA, there
are about 20 passes between them. Does it mean register renaming can
also heavily benefit other
On Wed, Sep 3, 2014 at 9:17 AM, Bin.Cheng wrote:
Last time I tried, there are several passes after loop_done and before
auto-inc-dec can't handle auto-increment addressing mode, including
fweb.
It surprises me that pass_web can't handle AUTOINC. Perhaps I'm off my
rocker, but it's always been
I've noticed that
make -j -k check-fortran
results in a serialized checking, while
make -j32 -k check-fortran
goes parallel. Somehow the explicit 'N' in -jN seems to be needed for the check
target, while the other targets seem to do just fine. Is that a feature, or
should I file a PR for
On Wed, 3 Sep 2014, VandeVondele Joost wrote:
I've noticed that
make -j -k check-fortran
results in a serialized checking, while
make -j32 -k check-fortran
goes parallel. Somehow the explicit 'N' in -jN seems to be needed for the check
target, while the other targets seem to do just fine.
On Wed, Sep 03, 2014 at 09:15:51AM +, VandeVondele Joost wrote:
I've noticed that
make -j -k check-fortran
results in a serialized checking, while
make -j32 -k check-fortran
goes parallel. Somehow the explicit 'N' in -jN seems to be needed for the
check target, while the other
It is intentional. With -j it is essentially a fork bomb, just don't use it.
well, silently ignoring it for just this target did cost me a lot of time,
while an eventual fork bomb would have been dealt with much more quickly.
Somewhat related is there a rule of thumb on how is the
What did you expect for -j alone? an error?
No, as is standard in gnu make, a new process for any target that can be
processed (i.e. unlimited).
... check-fortran seems to be limited to about ~5 parallel targets ...
Running the make with -j8 gives 7 directories gfortran[1-6]? in
On Wed, Sep 03, 2014 at 09:37:19AM +, VandeVondele Joost wrote:
It is intentional. With -j it is essentially a fork bomb, just don't use
it.
well, silently ignoring it for just this target did cost me a lot of time,
while an eventual fork bomb would have been dealt with much more
Hi Joost,
VandeVondele Joost wrote:
I've noticed that
make -j -k check-fortran
results in a serialized checking, while
make -j32 -k check-fortran
goes parallel.
I have to admit that I don't know why that's the case. However, I can answer
the next question, is presumably related to this
I have to admit that I don't know why that's the case.
Actually Marc answered that one (I had the wrong mail address for gcc@ so
repeat here):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53155
See: gcc/fortran/Make-lang.in, which has:
I'll have a look and do some testing what the
expect -- /usr/share/dejagnu/runtest.exp --tool gcc lto.exp weak.exp tls.exp
ipa.exp tree-ssa.exp debug.exp dwarf2.exp fixed-point.exp vxworks.exp
cilk-plus.exp vmx.exp pch.exp simulate-thread.exp x86_64-costmodel-vect.exp
i386-costmodel-vect.exp spu-costmodel-vect.exp
On Wed, Sep 03, 2014 at 10:35:41AM +, VandeVondele Joost wrote:
expect -- /usr/share/dejagnu/runtest.exp --tool gcc lto.exp weak.exp
tls.exp ipa.exp tree-ssa.exp debug.exp dwarf2.exp fixed-point.exp
vxworks.exp cilk-plus.exp vmx.exp pch.exp simulate-thread.exp
Hi,
I found there is a performance problem with some simd intrinsics
(vld2_dup_*) on aarch64-none-elf. Now the vld2_dup_* are defined as
follows:
#define __LD2R_FUNC(rettype, structtype, ptrtype, \
regsuffix, funcsuffix, Q) \
__extension__ static __inline rettype \
__attribute__
On Wed, 3 Sep 2014, Florian Weimer wrote:
On 09/02/2014 11:22 PM, James Nelson wrote:
This is error-prone because even though a size parameter is given, the code
in the function has no requirement to enforce it. With a bounded array
type, the prototype looks like this:
buf *foo(char
On 09/03/14 02:35, Steven Bosscher wrote:
On Wed, Sep 3, 2014 at 9:17 AM, Bin.Cheng wrote:
Last time I tried, there are several passes after loop_done and before
auto-inc-dec can't handle auto-increment addressing mode, including
fweb.
It surprises me that pass_web can't handle AUTOINC.
Hi Shanyao,
On 03/09/14 16:02, shanyao chen wrote:
Hi,
I found there is a performance problem with some simd intrinsics
(vld2_dup_*) on aarch64-none-elf. Now the vld2_dup_* are defined as
follows:
#define __LD2R_FUNC(rettype, structtype, ptrtype, \
regsuffix, funcsuffix, Q) \
Trying to bootstrap m68k i hit an assert in emit_library_call_value_1
that wants to assure that the stack is aligned properly.
PUSH_ROUNDING(GET_MODE_SIZE(QImode)) for m5206 is currently 1 so
the testcase below has stack_pointer_delta = 1 + 1 + 4
but emit_library_call_value_1() has this:
/*
On 09/03/2014 05:20 PM, Joseph S. Myers wrote:
On Wed, 3 Sep 2014, Florian Weimer wrote:
On 09/02/2014 11:22 PM, James Nelson wrote:
This is error-prone because even though a size parameter is given, the code
in the function has no requirement to enforce it. With a bounded array
type, the
On Wed, 3 Sep 2014, Florian Weimer wrote:
If you declare the size as [static sz] then
that means it points to an array of at least that size, but it could be
larger.
GCC does not seem to enforce that. This compiles without errors:
[static] is about optimization (but GCC doesn't
On Wed, Sep 3, 2014 at 1:29 AM, Steven Bosscher stevenb@gmail.com wrote:
On Wed, Sep 3, 2014 at 1:35 AM, Carrot Wei wrote:
1. It is well known that register renaming is a big help to register
allocation, but in gcc's backend, the web pass is far before RA, there
are about 20 passes between
On Tue, Sep 2, 2014 at 7:32 AM, Maxim Ostapenko
m.ostape...@partner.samsung.com wrote:
Hi,
At this moment, most of GCC builtin memory functions (for example strcpy,
stpcpy, wcpcpy, strdup, etc) are not instrumented by GCC, however some of
them are rather dangerous. If GCC inlines these
On 09/03/14 09:56, Bernhard Reutner-Fischer wrote:
Trying to bootstrap m68k i hit an assert in emit_library_call_value_1
that wants to assure that the stack is aligned properly.
PUSH_ROUNDING(GET_MODE_SIZE(QImode)) for m5206 is currently 1 so
the testcase below has stack_pointer_delta = 1 + 1 +
On 9/3/2014 1:24 PM, Jeff Law wrote:
On 09/03/14 09:56, Bernhard Reutner-Fischer wrote:
Trying to bootstrap m68k i hit an assert in emit_library_call_value_1
that wants to assure that the stack is aligned properly.
PUSH_ROUNDING(GET_MODE_SIZE(QImode)) for m5206 is currently 1 so
the
On 2 September 2014 16:28, Joseph S. Myers jos...@codesourcery.com wrote:
On Tue, 2 Sep 2014, Joey Ye wrote:
Apparently newlib is not following this specification very well, as
there are symbols like _abc_r defined every where in current newlib. I
am not implying the spec should not be
On Wed, 3 Sep 2014, Joern Rennecke wrote:
On 2 September 2014 16:28, Joseph S. Myers jos...@codesourcery.com wrote:
On Tue, 2 Sep 2014, Joey Ye wrote:
Apparently newlib is not following this specification very well, as
there are symbols like _abc_r defined every where in current newlib.
On 2014-08-29 2:47 AM, Ilya Enkovich wrote:
Seems your patch doesn't cover all cases. Attached is a modified
patch (with your changes included) and a test where double constant is
wrongly rematerialized. I also see in ira dump that there is still a
copy of PIC reg created:
Initialization of
Joel Sherrill joel.sherr...@oarcorp.com writes:
On 9/3/2014 1:24 PM, Jeff Law wrote:
On 09/03/14 09:56, Bernhard Reutner-Fischer wrote:
Perhaps m5206 is not TARGET_CAS and should not compile this linux-atomic
in the first place?
No, I don't think so.
Coldfire does not have the CAS
For a 16 bit CPU the cmpelim pass is changing
(insn 33 84 85 6 (parallel [
(set (reg:HI 1 r1)
(ashift:HI (reg:HI 1 r1)
(const_int 1 [0x1])))
(clobber (reg:CC_NOOV 7 flags))
])
Snapshot gcc-4.9-20140903 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140903/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Fri, 29 Aug 2014, ConcertPass Mirrors Admin wrote:
we set up a new GCC mirror for the community.
URL: http://mirrors.concertpass.com/gcc/
Organization/Contact: ConcertPass (ad...@mirrors.concertpass.com)
Location: United States, Michigan
Please, add it to your mirror list page.
Done
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62308
Yvan Roux yroux at gcc dot gnu.org changed:
What|Removed |Added
CC||vmakarov at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
Zhenqiang Chen zhenqiang.chen at arm dot com changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409
--- Comment #7 from Freddie Chopin freddie_chopin at op dot pl ---
Great (; Do you have some timeline? I'm not trying to rush you - I'm just
working on a project in which this feature would be beneficial, so I'm
wondering whether I should wait a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848
--- Comment #8 from Andrey Ryabinin ryabinin.a.a at gmail dot com ---
Hi, may I ask what's the status of this?
Besides of section mismatches in linux kernel it also breaks kernel's modules.
Variable __this_module doesn't get into section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61881
--- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org ---
Author: burnus
Date: Wed Sep 3 06:41:37 2014
New Revision: 214843
URL: https://gcc.gnu.org/viewcvs?rev=214843root=gccview=rev
Log:
Missed that file in r213079 of 2014-07-26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61888
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org ---
Author: burnus
Date: Wed Sep 3 06:41:37 2014
New Revision: 214843
URL: https://gcc.gnu.org/viewcvs?rev=214843root=gccview=rev
Log:
Missed that file in r213079 of 2014-07-26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305
--- Comment #17 from Tobias Burnus burnus at gcc dot gnu.org ---
Author: burnus
Date: Wed Sep 3 06:41:37 2014
New Revision: 214843
URL: https://gcc.gnu.org/viewcvs?rev=214843root=gccview=rev
Log:
Missed that file in r213079 of 2014-07-26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62663
--- Comment #4 from Andreas Schwab sch...@linux-m68k.org ---
Then this is most likely a linker bug, not setting up the GOT correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63152
Bug ID: 63152
Summary: needless initialization of local pointer arrays.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63152
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62224
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63153
Bug ID: 63153
Summary: pointers are not nullified with -finit-local-zero
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61330
--- Comment #9 from Yvan Roux yroux at gcc dot gnu.org ---
Author: yroux
Date: Wed Sep 3 07:23:01 2014
New Revision: 214847
URL: https://gcc.gnu.org/viewcvs?rev=214847root=gccview=rev
Log:
gcc/
2014-09-03 Yvan Roux yvan.r...@linaro.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606
--- Comment #9 from Yvan Roux yroux at gcc dot gnu.org ---
Author: yroux
Date: Wed Sep 3 07:23:01 2014
New Revision: 214847
URL: https://gcc.gnu.org/viewcvs?rev=214847root=gccview=rev
Log:
gcc/
2014-09-03 Yvan Roux yvan.r...@linaro.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62224
--- Comment #12 from Chris Clayton chris2553 at googlemail dot com ---
Sorry, you'll have to stick with me here while a figure out what that means.
I think you are saying that prior to r214208, the symbols definedMacros() and
headerPaths() were
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62224
--- Comment #13 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(In reply to Chris Clayton from comment #12)
Sorry, you'll have to stick with me here while a figure out what that means.
I think you are saying that prior to r214208,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
--- Comment #21 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com ---
I filed this previously, maybe its duplicate
Bug 61578 - Code size increase for ARM thumb compared to 4.8.x when compiling
with -Os
BR Fredrik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62662
--- Comment #5 from Andreas Krebbel krebbel at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #4)
I agree that this is something we need to fix in the back-end. I was just
curious about when this surfaced first and keep that info for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61078
--- Comment #8 from Andreas Krebbel krebbel at gcc dot gnu.org ---
Author: krebbel
Date: Wed Sep 3 08:06:09 2014
New Revision: 214850
URL: https://gcc.gnu.org/viewcvs?rev=214850root=gccview=rev
Log:
2014-09-03 Andreas Krebbel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63152
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61078
Andreas Krebbel krebbel at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61654
Martin Jambor jamborm at gcc dot gnu.org changed:
What|Removed |Added
Known to fail|4.10.0 |5.0
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61986
--- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00209.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62015
--- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00210.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63150
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63148
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60276
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||doug.gilmore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
You might want to try -fsanitize=undefined and/or -fno-strict-overflow as it
sounds like you may be invoking undefined behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62224
--- Comment #14 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #13)
(In reply to Chris Clayton from comment #12)
Sorry, you'll have to stick with me here while a figure out what that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53155
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
--- Comment #39 from Martin Jambor jamborm at gcc dot gnu.org ---
(In reply to Vidya Praveen from comment #38)
Until we fix this issue, could we have workaround posted by Martin Jambor
(comment #29) applied again on 4.9 and trunk?
No, not on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49444
bin.cheng amker.cheng at gmail dot com changed:
What|Removed |Added
CC||amker.cheng at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
--- Comment #40 from rguenther at suse dot de rguenther at suse dot de ---
nOn Wed, 3 Sep 2014, jamborm at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
--- Comment #39 from Martin Jambor jamborm at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140
--- Comment #5 from Ralf Hoffmann gcc at boomerangsworld dot de ---
Thanks for the feedback, I am also suspecting I have some problem in my code
regarding undefined behavior.
What I do for testing is to compile my tool Worker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49444
--- Comment #9 from Richard Biener rguenth at gcc dot gnu.org ---
Thus dup of PR61320?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62024
--- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org ---
Author: mpolacek
Date: Wed Sep 3 11:16:29 2014
New Revision: 214871
URL: https://gcc.gnu.org/viewcvs?rev=214871root=gccview=rev
Log:
PR c/62024
* c-parser.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62024
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |5.0
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62026
--- Comment #8 from Martin Jambor jamborm at gcc dot gnu.org ---
I'm sorry but I cannot reproduce the problem with the attached testcase. I
will try the libxul link.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155
Bug ID: 63155
Summary: [4.9/5 Regression] memory hog
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
There is a git mirror of the svn repo.
Anyway, -fsanitize=undefined enables -fno-delete-null-pointer-checks, perhaps
you could try that option alone if it makes a difference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62259
Ulrich Weigand uweigand at gcc dot gnu.org changed:
What|Removed |Added
CC||uweigand at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49444
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
CC||pinskia at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62294
--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org ---
Author: mpolacek
Date: Wed Sep 3 12:54:06 2014
New Revision: 214874
URL: https://gcc.gnu.org/viewcvs?rev=214874root=gccview=rev
Log:
PR c/62294
* c-typeck.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62294
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140
--- Comment #7 from Ralf Hoffmann gcc at boomerangsworld dot de ---
Created attachment 33442
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33442action=edit
simplified example file 1
simple example containing the code piece which triggers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140
--- Comment #8 from Ralf Hoffmann gcc at boomerangsworld dot de ---
Created attachment 33443
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33443action=edit
aguixtest.cc
file with helper functions, not related to the problem, but required
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140
--- Comment #9 from Ralf Hoffmann gcc at boomerangsworld dot de ---
Created attachment 33444
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33444action=edit
aguixtest.hh
file with helper functions, not related to the problem, but required
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140
--- Comment #10 from Ralf Hoffmann gcc at boomerangsworld dot de ---
Created attachment 33445
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33445action=edit
build
build script used to create executable test program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140
--- Comment #11 from Ralf Hoffmann gcc at boomerangsworld dot de ---
I managed to create a standalone test program. Attachment aguix.cc contains
the stripped down critical code segments. The two other files aguixtest.cc
and aguixtest.hh are just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62259
David Edelsohn dje at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62294
--- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org ---
Author: mpolacek
Date: Wed Sep 3 13:20:43 2014
New Revision: 214876
URL: https://gcc.gnu.org/viewcvs?rev=214876root=gccview=rev
Log:
PR c/62294
* gcc.dg/pr62294.c: New
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62294
--- Comment #6 from Emmanuel Thomé Emmanuel.Thome at inria dot fr ---
Thanks.
E.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58526
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org ---
See also RFC patch at https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00232.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
I wonder why we need to explicitely represent abnormal PHIs in the dispatcher.
All incoming edges are abnormal and all SSA names have to be coalesced anyway.
Thus we could instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
--- Comment #41 from Richard Biener rguenth at gcc dot gnu.org ---
New attempt: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00232.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61986
--- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org ---
Author: jamborm
Date: Wed Sep 3 14:16:54 2014
New Revision: 214877
URL: https://gcc.gnu.org/viewcvs?rev=214877root=gccview=rev
Log:
2014-09-03 Martin Jambor mjam...@suse.cz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
So the issue is that the setjmp argument needs two temporaries:
D.2832 = Unity.CurrentAbortFrame;
D.2833 = Unity.AbortFrame[D.2832];
bb 18:
D.2834 = _setjmp (D.2833);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62015
--- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org ---
Author: jamborm
Date: Wed Sep 3 14:26:38 2014
New Revision: 214878
URL: https://gcc.gnu.org/viewcvs?rev=214878root=gccview=rev
Log:
2014-09-03 Martin Jambor mjam...@suse.cz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57335
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61986
--- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org ---
I can reproduce the bug on the 4.9 branch too and the code is the same
in 4.8 as well (although the bug does not manifest form me there), so
please keep this bug opened until I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62259
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to saugustine from comment #0)
My uneducated guess is that the template at atomic:189 should either use
_M_i in calls to __atomic_is_lock_free (instead of nullptr) or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62270
--- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org ---
Author: mpolacek
Date: Wed Sep 3 16:04:27 2014
New Revision: 214881
URL: https://gcc.gnu.org/viewcvs?rev=214881root=gccview=rev
Log:
PR fortran/62270
* interface.c
1 - 100 of 247 matches
Mail list logo
