--- Comment #4 from joachim dot reichel at gmx dot de 2010-07-14 06:22
---
I tested your patch on gcc 4.4.4. I ran into PR 40974 and used the patch in
comment #20.
The full program (and the test case) now compiles fine. Note that I only
compiled the program. I was not able to run it be
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-07-14 04:24 ---
Fixed in trunk.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #1 from davidxl at gcc dot gnu dot org 2010-07-14 04:12 ---
This seems to be specific to powerpc.
Could you attach the dump files with options:
-O2 -Wuninitialized -fdump-tree-cddce2 -fdump-tree-uninit-details
Thanks,
David
(In reply to comment #0)
> Subject testcase f
--- Comment #15 from danglin at gcc dot gnu dot org 2010-07-14 00:18
---
We get a segv here:
Program received signal SIGSEGV, Segmentation fault.
0x0017686c in emit_block_move_hints (x=0x7afb3610, y=0x7afb36f0,
size=0x7af312d8, method=1074100336, expected_align=0, expected_size=-1
--- Comment #2 from jason at gcc dot gnu dot org 2010-07-14 00:01 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from jason at gcc dot gnu dot org 2010-07-14 00:00 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from mikpe at it dot uu dot se 2010-07-13 23:51 ---
Created an attachment (id=21195)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21195&action=view)
fix __cxa_type_match and __cxa_begin_cleanup prototypes
Looks like long-standing confusion about the return types of
--- Comment #2 from adam at consulting dot net dot nz 2010-07-13 23:19
---
This issue needs to be revisited with the advent of asm goto:
__attribute__ ((noreturn)) void noreturn_via_asm_goto() {
loop:
asm goto ("jmp %l[loop]\n" : : : : loop);
}
int main() {}
$ gcc-4.5 -std=gnu99 -
--- Comment #12 from hp at gcc dot gnu dot org 2010-07-13 23:07 ---
(In reply to comment #11)
> (In reply to comment #9)
> > the simulator supports cris-axis-linux-gnu too, but you don't want to build
> > for
> > that target, it's a slightly more complicated. :)
>
> actually, on reflec
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jyasskin at gmail dot com
|dot org
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-07-13 22:58 ---
Reopening
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|R
--- Comment #7 from jyasskin at gmail dot com 2010-07-13 22:56 ---
I'm working on a patch for this at
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01116.html. It works by emitting a
fake use of the key method any time a translation unit depends on an imported
vtable or typeinfo.
--
j
--- Comment #3 from jason at gcc dot gnu dot org 2010-07-13 22:23 ---
Subject: Bug 44540
Author: jason
Date: Tue Jul 13 22:23:38 2010
New Revision: 162158
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162158
Log:
PR c++/44540
* mangle.c (write_type): Canonicaliz
--- Comment #1 from jason at gcc dot gnu dot org 2010-07-13 22:24 ---
Subject: Bug 44909
Author: jason
Date: Tue Jul 13 22:23:49 2010
New Revision: 162159
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162159
Log:
PR c++/44909
* cp-tree.h (struct lang_type_class)
--- Comment #9 from kargl at gcc dot gnu dot org 2010-07-13 22:20 ---
I'm working on a patch, so I might as well take
ownership of the PR.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from burnus at gcc dot gnu dot org 2010-07-13 22:08 ---
(In reply to comment #6)
> (In reply to comment #1)
> > Reported by Satish at http://gcc.gnu.org/ml/fortran/2010-07/msg00152.html
>
> Is the original code invalid?
>
> C401 (R401) The derived-type-spec shall not spe
--- Comment #2 from amylaar at gcc dot gnu dot org 2010-07-13 21:56 ---
Subject: Bug 44874
Author: amylaar
Date: Tue Jul 13 21:55:57 2010
New Revision: 162156
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162156
Log:
gcc:
PR other/44874
* tree-dump.c (dump_optio
--- Comment #56 from amylaar at gcc dot gnu dot org 2010-07-13 21:56
---
Subject: Bug 44832
Author: amylaar
Date: Tue Jul 13 21:55:57 2010
New Revision: 162156
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162156
Log:
gcc:
PR other/44874
* tree-dump.c (dump_opt
--- Comment #4 from jason at gcc dot gnu dot org 2010-07-13 21:51 ---
I disagree with the analysis. In fact, QMapData::shared_null correctly gets
32-bit DECL_ALIGN once we walk the pending_statics vector in
finish_record_layout. But this is irrelevant.
The problem is that at the point
Subject testcase fails on powerpc64.
FAIL: gcc.dg/uninit-pred-9_b.c bogus warning (test for bogus messages, line 24)
Compiling standalone I see the following:
pthaugen/work> ~/install/gcc/trunk/bin/gcc -O2 -S -m32 -Wuninitialized
~/src/gcc/trunk/gcc/gcc/testsuite/gcc.dg/uninit-pred-9_b.c
/home/
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #7 from kargl at gcc dot gnu dot org 2010-07-13 21:01 ---
Created an attachment (id=21194)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21194&action=view)
patch for original problem
Patch the fixed Satish's original problem. It simply checks
for a derived type prior
The F2003 spec has the following not about the NAME= specifier:
NOTE 9.63
If this specifier appears in an INQUIRE by file statement, its value is not
necessarily the same as the name given in the FILE= specifier. However, the
value returned shall be suitable for use as the value of the fil
--- Comment #6 from kargl at gcc dot gnu dot org 2010-07-13 20:41 ---
(In reply to comment #1)
> Reported by Satish at http://gcc.gnu.org/ml/fortran/2010-07/msg00152.html
Is the original code invalid?
A type is specified in several contexts by a type specifier.
R401 type-spec is
--- Comment #5 from kargl at gcc dot gnu dot org 2010-07-13 20:35 ---
> Talking about (c): The following valid program is also rejected:
>
> real(8),allocatable :: r8
> allocate( real(8) :: r8)
> end
Hmm. Interesting.
real(8),allocatable :: r8
allocate(real(kind=8) :: r8)
end
works
--- Comment #3 from John dot Tytgat at aaug dot net 2010-07-13 20:32
---
I can confirm that it is because of the use of --enable-maintainer-mode we get
an error instead of a warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44902
--- Comment #11 from iains at gcc dot gnu dot org 2010-07-13 20:30 ---
(In reply to comment #9)
> (I could reply "yes" to your original question, however, but that's
> irrelevant;
> the simulator supports cris-axis-linux-gnu too, but you don't want to build
> for
> that target, it's
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-07-13 20:06
---
The solution here should take into account all possible "key words"
combinations as well. integer, complex, character, etc. Matching "REAL"
should give match no accept for the few cases that are acceptable "REAL
--- Comment #1 from lennox at cs dot columbia dot edu 2010-07-13 18:54
---
Adding Cc: of Ian Taylor -- this message is emitted by
warn_cxx_compat_finish_struct, written by him.
--
lennox at cs dot columbia dot edu changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2010-07-13 17:48 ---
(In reply to comment #2)
> a) TYPE(REAL) / TYPE(REAL_TYPE) is allowed, one probably can borrow the code
> from there.
Thinking of it again, the simplest seems to be to copy from decl.c's
gfc_match_decl_type_spec ever
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-13 17:42 ---
Reminder:
a) TYPE(REAL) / TYPE(REAL_TYPE) is allowed, one probably can borrow the code
from there.
b) In fixed format, spaces do not count anything, thus,
ALL O CATE( REAL _ TYPE :: t)
ALL O CATE( R E A L ::
--- Comment #14 from mikpe at it dot uu dot se 2010-07-13 17:40 ---
Also fails on sparc64-linux, with SIGBUS due to misaligned load in bar().
On armv5tel-unknown-linux-gnueabi it triggers an alignment exception, which the
Linux kernel may emulate/fixup (there's a kernel tunable for that
--- Comment #18 from burnus at gcc dot gnu dot org 2010-07-13 17:34 ---
Reminder: The function decl ("fn spec") needs to be updated for asynchronous
I/O; in particular WAIT needs to have the "X" (unused argument) removed.
Possibly, other function names should be used to keep the nonclobb
--- Comment #6 from burnus at gcc dot gnu dot org 2010-07-13 17:32 ---
Main library calls are done.
TODO:
- Intrinsic calls such as "call ctime()" which do not have a function
declaration
- Nonintrinsic functions with non-pointer INTENT(IN/OUT); handle also
(non)clobber [target/pointer
--- Comment #1 from bdsatish at gmail dot com 2010-07-13 17:30 ---
Reported by Satish at http://gcc.gnu.org/ml/fortran/2010-07/msg00152.html
Simplified testcase by Janus Weil:
type :: real_type
end type
class(real_type), allocatable :: obj
allocate(real_type :: obj)
end
This is a simp
--- Comment #1 from zsojka at seznam dot cz 2010-07-13 17:29 ---
Created an attachment (id=21193)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21193&action=view)
auto-reduced testcase (from libstdc++-v3/testsuite/20_util/function/5.cc)
--
http://gcc.gnu.org/bugzilla/show_bug.
Command line:
$ gcc -O1 -std=gnu++0x -fverbose-asm
Output:
/tmp/ccUXumsY.s: Assembler messages:
/tmp/ccUXumsY.s:52: Error: junk at end of line, first unrecognized character is
`*'
The offending line is:
movq%rax, (%rbx)# D.2519, MEM[(<<< Unknown tree: offset_type
>>>
* &)__dest_3
--
Summary: [OOP] Intrinsic type
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bdsatish at gmail
--- Comment #5 from burnus at gcc dot gnu dot org 2010-07-13 17:26 ---
Subject: Bug 43665
Author: burnus
Date: Tue Jul 13 17:26:02 2010
New Revision: 162147
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162147
Log:
2010-07-13 Tobias Burnus
Daniel Franke
--- Comment #17 from sandra at codesourcery dot com 2010-07-13 17:13
---
As a point of clarification, I am not getting paid to care about this issue
either. :-) At this time I have no plans to continue working on it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
--- Comment #6 from jakub at gcc dot gnu dot org 2010-07-13 17:08 ---
Please don't keep reopening this bug.
The symbols are weak undefs because libgfortran doesn't require (and shouldn't
require) libpthread, it is thread-safe only when libpthread is linked in.
--
jakub at gcc dot gnu
--- Comment #11 from jiez at gcc dot gnu dot org 2010-07-13 16:40 ---
Created an attachment (id=21192)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21192&action=view)
The reduced test case
--
jiez at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from uweigand at gcc dot gnu dot org 2010-07-13 16:35
---
Also fails on spu-elf.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jiez at gcc dot gnu dot org 2010-07-13 16:20 ---
Created an attachment (id=21191)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21191&action=view)
The reduced test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44921
--- Comment #14 from sandra at codesourcery dot com 2010-07-13 16:13
---
There are two patches that made the difference: r158189 (Carrot's patch for
PR42601) and r162043 (the second part of my patch for PR42505). I checked that
backporting these two changes to the 4.5 branch is suffic
--- Comment #8 from laurent at guerby dot net 2010-07-13 16:05 ---
Should be fixed now.
--
laurent at guerby dot net changed:
What|Removed |Added
Status|ASSIG
--- Comment #7 from guerby at gcc dot gnu dot org 2010-07-13 15:59 ---
Subject: Bug 44458
Author: guerby
Date: Tue Jul 13 15:59:20 2010
New Revision: 162146
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162146
Log:
2010-07-13 Laurent GUERBY
PR bootstrap/44458
--- Comment #8 from burnus at gcc dot gnu dot org 2010-07-13 15:54 ---
(In reply to comment #5)
> Here int_ptr is a pointer to an array of integers, but int_ptr(0) is an
> element
> of that array, so it doesn't have the POINTER attribute, does it?
It doesn't have the pointer attribute
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-07-13 15:53 ---
We need the full preproccessed source which is showing the issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
Hi there, the ARM compiler (we use 4.4.1 but could also verify this on
different platforms) illegally ignores the volatile statement on globals when
optimization >0 is used. Here is an example:
volatile unsigned char *glbDummyToTestVolatileBug;
...
:
for (glbDummyToTestVolatileBug=0;glbDummyToT
--- Comment #10 from iains at gcc dot gnu dot org 2010-07-13 15:32 ---
of course, there should not be different behavior with/without
--enable-build-with-cxx, so I guess that the test-suite fix is only part of the
solution.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44488
--- Comment #12 from bonzini at gnu dot org 2010-07-13 15:31 ---
Subject: Re: GCC fails to build if MPFR 3.0.0 (Release
Candidate) is used
On 07/13/2010 05:01 PM, marc dot glisse at normalesup dot org wrote:
> --- Comment #11 from marc dot glisse at normalesup dot org 2010-07-13
--- Comment #15 from manu at gcc dot gnu dot org 2010-07-13 15:22 ---
Before closing this, please check all testcases provided and add at least one
of them to the testsuite.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40146
--- Comment #9 from iains at gcc dot gnu dot org 2010-07-13 15:20 ---
Subject: Bug 44488
Author: iains
Date: Tue Jul 13 15:20:21 2010
New Revision: 162144
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162144
Log:
PR objc/44488
* lib/objc-torture.exp (objc-set-r
--- Comment #3 from uweigand at gcc dot gnu dot org 2010-07-13 15:15
---
Also fails on spu-elf.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from marc dot glisse at normalesup dot org 2010-07-13
15:01 ---
Sorry, no commit rights. I wrote the patch because it was a one-liner, but I
still don't even have a copyright assignment on file.
Can you handle the rest?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #10 from bonzini at gnu dot org 2010-07-13 14:43 ---
Great! Do you have commit rights? Patch is ok for all 4.5 and 4.6.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44455
--- Comment #14 from caolanm at redhat dot com 2010-07-13 14:37 ---
Checking with gcc 4.5, this works fine for me now, so I'm happy to call this
fixed in 4.5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40146
--- Comment #9 from marc dot glisse at normalesup dot org 2010-07-13 14:26
---
Ok, the 4 tests worked fine. I tested with gcc-4.5.0 because the snapshots
complained about the number of arguments to ggc_alloc_cleared_lang_type
(without any patch). I used --without-ppl (otherwise you get
--- Comment #3 from abel at gcc dot gnu dot org 2010-07-13 14:10 ---
Created an attachment (id=21190)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21190&action=view)
proposed patch
This exact patch is against trunk, it may apply with fuzz on 4_4 branch.
--
http://gcc.gnu.or
--- Comment #2 from abel at gcc dot gnu dot org 2010-07-13 14:07 ---
Confirmed on the 4.4 branch. The problem is latent on trunk.
When we have added support for moving insns through mutually exclusive insns,
it was made possible to move conditional jumps across block boundaries. Bu
--- Comment #6 from jakub at gcc dot gnu dot org 2010-07-13 14:04 ---
Subject: Bug 44701
Author: jakub
Date: Tue Jul 13 14:03:49 2010
New Revision: 162142
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162142
Log:
PR testsuite/44701
* recog.c (constrain_operands)
--- Comment #7 from janus at gcc dot gnu dot org 2010-07-13 13:54 ---
Ok, here goes the next try. This patch cures the bogus error from comment #0,
removes the regressions on c_loc_tests_* and rejects the test case due to the
polymorphic argument:
Index: gcc/fortran/resolve.c
==
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-07-13 13:53
---
Does
Index: expr.c
===
--- expr.c (revision 162140)
+++ expr.c (working copy)
@@ -8778,6 +8778,11 @@ expand_expr_real_1 (tree exp, rtx targ
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-13 13:34 ---
There is already testcases like this in gcc.dg/ipa/ipa-pta-*.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23134
--- Comment #14 from burnus at gcc dot gnu dot org 2010-07-13 13:32 ---
(In reply to comment #13)
> Still present.
Well, INTENT(IN), nonclobber, and something more is now supported by the middle
end through the "fn spec" attribute (space to make sure this attribute stays
internal for no
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-13 13:31 ---
Subject: Bug 36960
Author: rguenth
Date: Tue Jul 13 13:31:26 2010
New Revision: 162141
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162141
Log:
2010-07-13 Richard Guenther
PR tree-optimization/
--- Comment #20 from rguenth at gcc dot gnu dot org 2010-07-13 13:29
---
The bug is confused now and mixes -fargument-* with other missed opts (which
I think are fixed with IPA-PTA and/or proper use of restricts or are dups
of other problems).
-fargument-noalias* problems are WONTFIX,
--- Comment #4 from burnus at gcc dot gnu dot org 2010-07-13 13:21 ---
Subject: Bug 43665
Author: burnus
Date: Tue Jul 13 13:20:52 2010
New Revision: 162140
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162140
Log:
2010-07-13 Daniel Franke
Tobias Burnus
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2010-07-13
13:06 ---
(In reply to comment #17)
> Subject: Re: --enable-build-with-cxx plugin tests fail
>
> > This patch should restore the use of the previous stage compiler for
> > plugins.
>
> Indeed: with the exception
--- Comment #5 from victor dot pasko at gmail dot com 2010-07-13 12:36
---
The root cause of the problem is in using weak symbol pthread_cancel in unit.o
object from libgfortran.a library. Why it's so?
Look:
% nm unit.o
04f0 T _gfortrani_close_unit
04a0 T _gfor
--- Comment #6 from janus at gcc dot gnu dot org 2010-07-13 12:32 ---
> c_loc_tests_5.f03 has:
>
> integer(c_int), dimension(:), pointer :: int_ptr
> my_c_ptr = c_loc(int_ptr(0))
>
> Here int_ptr is a pointer to an array of integers, but int_ptr(0) is an
> element
> of that a
--- Comment #4 from jakub at gcc dot gnu dot org 2010-07-13 12:22 ---
It is not a gcc thing though, but glibc. Some Linux distributions (e.g. recent
Fedora or RHEL) ld -r all libpthread.a objects together, so this works, others
do not.
--
jakub at gcc dot gnu dot org changed:
--- Comment #5 from janus at gcc dot gnu dot org 2010-07-13 12:12 ---
(In reply to comment #3)
> For the program in comment 0, NAG prints:
> Error: aaa.f90, line 16: The argument to C_LOC must not be polymorphic
> though ifort and crayftn accept the code. Thus, at least with
> -std=f95
--- Comment #4 from burnus at gcc dot gnu dot org 2010-07-13 12:04 ---
Thus: The derived type needs to be BIND(C) - but then it cannot be extended (as
it is not extensible) - nor can the extended type be BIND(C) (per C1503). And
without BIND(C) it is not interoperable - besides that poly
--- Comment #3 from victor dot pasko at gmail dot com 2010-07-13 12:01
---
I would like that it was possible to get correct static program by using just:
gfortran -static bug.f90 -fopenmp
--
victor dot pasko at gmail dot com changed:
What|Removed
--- Comment #1 from redi at gcc dot gnu dot org 2010-07-13 11:54 ---
Oops, this should be Component=debug
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2010-07-13 11:52 ---
For the program in comment 0, NAG prints:
Error: aaa.f90, line 16: The argument to C_LOC must not be polymorphic
though ifort and crayftn accept the code. Thus, at least with
-std=f95/f2003/f2008 one should reject i
--- Comment #3 from paolo dot carlini at oracle dot com 2010-07-13 11:48
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #2 from paolo at gcc dot gnu dot org 2010-07-13 11:48 ---
Subject: Bug 44908
Author: paolo
Date: Tue Jul 13 11:47:58 2010
New Revision: 162138
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162138
Log:
cp/
2010-07-13 Paolo Carlini
PR c++/44908
* c
--- Comment #8 from jakub at gcc dot gnu dot org 2010-07-13 07:00 ---
Subject: Bug 44901
Author: jakub
Date: Tue Jul 13 06:59:56 2010
New Revision: 162126
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162126
Log:
PR debug/44901
* vec.h (VEC_block_remove): Fix co
--- Comment #8 from dennis dot wassel at googlemail dot com 2010-07-13
11:36 ---
Also fails with 4.5.0 (release version) using Daniel's reduced testcase
$ gfortran -c pr37744.f90
pr37744.f90:4.2:
XXX ! any error will do
1
Error: Unclassifiable statement at (1)
pr3
--- Comment #11 from steven at gcc dot gnu dot org 2010-07-13 11:28 ---
We have a separate bug for malloced memory. So this bug is FIXED.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from steven at gcc dot gnu dot org 2010-07-13 11:27 ---
Ehm, Richi, WONTFIX why? Is this not what you added the alias attributes for?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17064
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-13 11:23 ---
Indeed.
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-13 11:19 ---
Subject: Bug 44911
Author: rguenth
Date: Tue Jul 13 11:18:50 2010
New Revision: 162137
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162137
Log:
2010-07-13 Richard Guenther
PR middle-end/44911
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-07-13 11:12
---
(In reply to comment #9)
> Restrict has been implemented anew for GCC 4.6. Does that fix this bug?
In 4.5, see comment #7 for the status of this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2462
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-07-13 11:10
---
WONTFIX.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITI
--- Comment #2 from janus at gcc dot gnu dot org 2010-07-13 11:10 ---
(In reply to comment #1)
> However, it regresses at least on c_loc_tests_5.f03 and c_loc_tests_14.f90.
Actually I have the feeling that both of these test cases are invalid, and the
patch is right to reject them.
--
--- Comment #18 from iains at gcc dot gnu dot org 2010-07-13 11:01 ---
fixed
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from steven at gcc dot gnu dot org 2010-07-13 11:00 ---
Insofar something that doesn't exist anymore can be considered broken, this bug
is FIXED:
;; Function x (x)
x ()
{
intD.0 aD.1233;
intD.0 D.1983;
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru,exec)
--- Comment #5 from steven at gcc dot gnu dot org 2010-07-13 10:55 ---
Test case of comment #4 still fails with r162134.
Not sure what is expected for the test case of comment #0, but I'm assuming the
point is that the store of the reduction should be sunk. That doesn't happen as
of r16
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-13 10:49 ---
GCC 4.1 and GCC 4.2 are no longer maintained => WONTFIX.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from steven at gcc dot gnu dot org 2010-07-13 10:48 ---
Restrict has been implemented anew for GCC 4.6. Does that fix this bug?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from kkojima at gcc dot gnu dot org 2010-07-13 10:41 ---
Subject: Bug 44761
Author: kkojima
Date: Tue Jul 13 10:41:15 2010
New Revision: 162135
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162135
Log:
PR target/44761
* mode-switching.c (optimize_
--- Comment #13 from steven at gcc dot gnu dot org 2010-07-13 10:37 ---
Still present.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|20
--- Comment #5 from steven at gcc dot gnu dot org 2010-07-13 10:33 ---
r162134 at -O3:
;; Function h (h)
h (int * a)
{
:
*a_1(D) = 1;
return;
}
;; Function g (g)
g ()
{
int t1;
int t;
int t.0;
int D.1984;
:
t = 0;
h (&t);
t1_1 = t;
g1 (t1_1);
t.0_2 = t;
D.
--- Comment #15 from steven at gcc dot gnu dot org 2010-07-13 10:29 ---
Still not fixed with r162134:
;; Function bar (bar)
bar ()
{
int prephitmp.4;
:
prephitmp.4_1 = i;
switch (prephitmp.4_1) , case 0: >
:
foo ();
prephitmp.4_7 = i;
# prephitmp.4_8 = PHI
:
switch (p
--- Comment #17 from steven at gcc dot gnu dot org 2010-07-13 10:21 ---
>From common.opt r161963:
fargument-alias
Common
Does nothing. Preserved for backward compatibility.
fargument-noalias
Common
Does nothing. Preserved for backward compatibility.
fargument-noalias-global
Common
Doe
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-13
10:16 ---
Subject: Re: --enable-build-with-cxx plugin tests fail
> This patch should restore the use of the previous stage compiler for plugins.
Indeed: with the exception of the $(ENABLE_BUILD_WITH_CXX) handling,
1 - 100 of 127 matches
Mail list logo
