http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #20 from linzj ---
(In reply to Richard Henderson from comment #19)
> Created attachment 32311 [details]
> proposed patch
>
> Running full tests on this overnight, but it fixes the ICE.
Oh, It never comes to me that both setting the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #33 from Jerry DeLisle ---
Author: jvdelisle
Date: Sun Mar 9 05:34:34 2014
New Revision: 208439
URL: http://gcc.gnu.org/viewcvs?rev=208439&root=gcc&view=rev
Log:
2014-03-08 Jerry DeLisle
PR libfortran/38199
* io/list_read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #32 from Jerry DeLisle ---
Created attachment 32312
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32312&action=edit
New patch for case in comment 21
This is just a preliminary runtime patch.
Without:
real0m7.519s
user0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #19 from Richard Henderson ---
Created attachment 32311
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32311&action=edit
proposed patch
Running full tests on this overnight, but it fixes the ICE.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #31 from Jerry DeLisle ---
Author: jvdelisle
Date: Sun Mar 9 03:17:16 2014
New Revision: 208438
URL: http://gcc.gnu.org/viewcvs?rev=208438&root=gcc&view=rev
Log:
2014-03-08 Jerry DeLisle
PR libfortran/38199
* io/list_read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #30 from Jerry DeLisle ---
The read:
read(buffer,'(i10)') i
is an entirely different code path then the example in Comment #22 because of
the format specifier. This is handled very differently from a list directed
read. In read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #18 from linzj ---
(In reply to Richard Henderson from comment #17)
> The REG_ARGS_SIZE notes are a red-herring.
>
> The bug is that
>
> (insn:TI 66 61 31 4 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
> (reg:SI 0 a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446
David Heidelberger (okias) changed:
What|Removed |Added
CC||david.heidelberger at ixit do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55807
David Heidelberger (okias) changed:
What|Removed |Added
CC||david.heidelberger at ixit do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
Richard Henderson changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #17 from Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #29 from Manfred Schwarb ---
The regression flag was re-added by Tobias in comment 23 due to
a regression in the testcase of comment 21:
!234567
character buffer*10
integer i,j
DO j=1,
write(buffer,'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60469
Bug ID: 60469
Summary: simple cilk plus program ICEs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60468
Bug ID: 60468
Summary: ./fpu-target.h:93:3: error: unknown type name 'choke'
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45143
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60148
--- Comment #13 from Jerry DeLisle ---
Only documentation remains for this patch. Need to document gfortran extended
behavior for default behavior when writing to name lists whne no DELIM= has
been specified. gfortran defaults to DELIM="quotes"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60467
Bug ID: 60467
Summary: ICE with -fcilkplus
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60447
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60447
--- Comment #8 from Tobias Burnus ---
Author: burnus
Date: Sat Mar 8 18:53:18 2014
New Revision: 208431
URL: http://gcc.gnu.org/viewcvs?rev=208431&root=gcc&view=rev
Log:
2014-03-08 Tobias Burnus
PR fortran/60447
* f95-lang.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41757
devurandom at gmx dot net changed:
What|Removed |Added
CC||devurandom at gmx dot net
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60462
Fred Krogh changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60450
--- Comment #8 from janus at gcc dot gnu.org ---
(In reply to kargl from comment #6)
> Patch is OK with a testcase.
Thanks, committed to the 4.8 branch as r208430. Will backport to 4.7 soon.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60450
--- Comment #7 from janus at gcc dot gnu.org ---
Author: janus
Date: Sat Mar 8 13:59:00 2014
New Revision: 208430
URL: http://gcc.gnu.org/viewcvs?rev=208430&root=gcc&view=rev
Log:
2014-03-08 Janus Weil
PR fortran/60450
* simplify.c (g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60466
Bug ID: 60466
Summary: Support for HARD_REGNO_NREGS_HAS_PADDING and
HARD_REGNO_NREGS_WITH_PADDING broken
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
--- Comment #1 from devurandom at gmx dot net ---
Created attachment 32310
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32310&action=edit
emerge --info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
Bug ID: 60465
Summary: Compiling glibc-2.17,2.18 with gcc-4.8.2 and
binutils-2.23.2,2.24 results in segfaults in _start /
elf_get_dynamic_info
Product: gcc
Version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60393
Adam Butcher changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60447
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #16 from linzj ---
I have dodged this bug by the following patch:
diff --git a/gcc/cfgcleanup.c b/gcc/cfgcleanup.c
index 77196ee..d7c2b1e 100644
--- a/gcc/cfgcleanup.c
+++ b/gcc/cfgcleanup.c
@@ -1106,20 +1106,7 @@ old_insns_match_p (in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60462
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #15 from linzj ---
dir = merge_dir (dir, old_insns_match_p (0, i1, i2));
if (dir == dir_none || (!dir_p && dir != dir_both))
break;
{
print_rtl_single (stdout, i1);
print_rtl_single (stdout, i2);
p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418
--- Comment #17 from rguenther at suse dot de ---
On 3/7/14 10:57 PM, hjl.tools at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418
>
> --- Comment #14 from H.J. Lu ---
> (In reply to Richard Biener from comment #13)
>>
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60033
Adam Butcher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60393
--- Comment #1 from Adam Butcher ---
Author: abutcher
Date: Sat Mar 8 09:33:03 2014
New Revision: 208426
URL: http://gcc.gnu.org/viewcvs?rev=208426&root=gcc&view=rev
Log:
Fix PR c++/60393
PR c++/60393
* parser.c (cp_parser_parameter_dec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60033
--- Comment #8 from Adam Butcher ---
Author: abutcher
Date: Sat Mar 8 09:33:12 2014
New Revision: 208427
URL: http://gcc.gnu.org/viewcvs?rev=208427&root=gcc&view=rev
Log:
Fix PR c++/60033
PR c++/60033
* pt.c (tsubst_copy): When retrievi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58271
--- Comment #2 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Sat Mar 8 09:27:23 2014
New Revision: 208425
URL: http://gcc.gnu.org/viewcvs?rev=208425&root=gcc&view=rev
Log:
gcc/
PR target/58271
* config/mips/mips.c (mips_op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60464
--- Comment #7 from Jeremy Cooper ---
I have managed to resolve the problem by doing two things. However, one of them
is still distasteful (editing the GCC 4.8.2 source).
1. Edited gcc/config/arm/t-arm-elf, uncommenting the following lines:
MULT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #52 from Marc Glisse ---
(In reply to Harald van Dijk from comment #51)
> Note that a consequence of this is that a function declaration that uses a
> typedef may not be compatible with the typedef (I think):
>
> extern "C" { void f();
37 matches
Mail list logo
