--- Comment #10 from ubizjak at gmail dot com 2010-06-10 06:18 ---
(In reply to comment #9)
Following patch is also needed to fix conditional splitting (it does not fix
original uncovered problem where BLOCK_FOR_INSN returns null):
I am not sure this is correct. The code prior
--- Comment #4 from kargl at gcc dot gnu dot org 2010-06-10 06:31 ---
(In reply to comment #3)
The result of transfer is largest kind of decimal. Can be kind=8 or kind=16
depending on the system. Maybe we should add some documentation in the manual
on this. Thanks Steve for
--- Comment #17 from sebastian dot huber at embedded-brains dot de
2010-06-10 07:13 ---
Thank you for your investigations. A special case fix is better than nothing.
I am not a GCC expert but it seems that this kind of bug appears quite
regularly on different platforms and all use
--- Comment #17 from vapier at gentoo dot org 2010-06-10 07:22 ---
vanilla gcc-4.4.x shows the same behavior if you were to use the same configure
options as Gentoo. specifically, --disable-checking seems to cause this.
i dont have the ability to re-open this bug since i didnt file it
--- Comment #5 from burnus at gcc dot gnu dot org 2010-06-10 07:25 ---
I think there is another problem. Assuming the following program:
integer(4) :: i4
integer(8) :: i8
i4 = 1
i8 = transfer(i4, mold=i8)
end
The TRANSFER (as the one in comment 0) is partially undefined, but there is
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-10 07:33 ---
(In reply to comment #1)
This should work (untested). However, ASYNCHRONOUS is F2003. Should one
introduce standard-specific checks? The whole function seems to be agnostic in
this respect?!
Well, if you have
--- Comment #5 from paolo dot carlini at oracle dot com 2010-06-10 08:14
---
Thanks Jason. Actually, the issue seems already known, LWG 1326, Bullet 4 of
the proposed resolution (the name of the issue isn't particularly telling, I
would say). It's still [New] But I guess we had better
--- Comment #6 from paolo dot carlini at oracle dot com 2010-06-10 08:16
---
Sorry, I meant Bullet 5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44487
Based on
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/377859ecc89ea65c
For the following program, gfortran just prints:
During initialization
Error: Incompatible types in DATA statement at (1); attempted conversion of
INTEGER(16) to CHARACTER(1)
Expected: gfortran
--- Comment #76 from iains at gcc dot gnu dot org 2010-06-10 09:02 ---
committed to the 4.5 branch as r160526.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
--- Comment #44 from harry dot he at freescale dot com 2010-06-10 09:03
---
Thanks for your reminding, Mark.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-06-10 09:18 ---
I've found now that the runtime is picked up from the install location.
For default configuration, I use --prefix=/user/inria , and the file is
then picked up from
--- Comment #5 from amylaar at gcc dot gnu dot org 2010-06-10 09:28 ---
(In reply to comment #4)
I've found now that the runtime is picked up from the install location.
P.S.: That doesn't happen when I cut paste the LD_LIBRARY_PATH settings
and the compile command from the log file -
struct T { const char *p; };
struct S { T a, b, c; unsigned d; };
void bar (const T , const T );
void
foo (S s, T e)
{
const char *a = e.p;
const char *b = s.b.p;
__asm__ volatile (/* %0 %1 */ : : rm (a), rm (b));
bar (e, s.b);
}
has PRE_MODIFY and PRE_INC in MEM operands of
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-10 09:33 ---
I had saw this before and it was declared this was correct behavior but I
cannot find the bug any more.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-06-10 09:41 ---
Found the bug which I was talking about, PR 33932.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44461
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-10 09:44 ---
struct T { unsigned long p; };
struct S { T a, b, c; unsigned d; };
__attribute__((noinline))
void
bar (const T x, const T y)
{
if (x.p != 0x2348 || y.p != 0x2346)
__builtin_abort ();
}
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-06-10 09:47 ---
I think the real issue is that m is too generic from the point of the
documentation.
Reading:
http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Simple-Constraints.html#Simple-Constraints
Makes it sound like it could
On powerpc-linux and i686-linux cxg1004 fails, here is the powerpc-linux log:
BUILD cxg1004.adb
gnatmake --GCC=/home/guerby/build/gcc/xgcc -B/home/guerby/build/gcc/ -gnatws
-O2 -I/home/guerby/build/gcc/testsuite/ada/acats/support cxg1004.adb -largs
--GCC=/home/guerby/build/gcc/xgcc
--- Comment #1 from laurent at guerby dot net 2010-06-10 09:56 ---
From the ChangeLog this patch looks like a good candidate:
+2010-06-01 Jan Hubicka j...@suse.cz
+
+ * tree-cfgcleanup.c (fixup_noreturn_call): Break out from ...;
+ remove return value.
--
laurent at
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44484
--- Comment #4 from schwab at linux-m68k dot org 2010-06-10 10:12 ---
You need to use the %U and %X modifiers together with m. If the insn does
not support them (no update and/or indexed form) you cannot use m. Basically
this means you can use m only with the normal load/store insns.
--- Comment #5 from jakub at gcc dot gnu dot org 2010-06-10 10:25 ---
And ensure that it is used exactly once in an inline asm pattern? Even for g
constraint? That just can't be true.
Just look at how many of m and =m constraints e.g. glibc uses.
Only 8 occurrences of %U, but e.g.:
--- Comment #7 from paolo at gcc dot gnu dot org 2010-06-10 10:25 ---
Subject: Bug 44487
Author: paolo
Date: Thu Jun 10 10:24:46 2010
New Revision: 160528
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160528
Log:
2010-06-10 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #8 from paolo at gcc dot gnu dot org 2010-06-10 10:26 ---
Subject: Bug 44487
Author: paolo
Date: Thu Jun 10 10:26:14 2010
New Revision: 160529
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160529
Log:
2010-06-10 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #9 from paolo dot carlini at oracle dot com 2010-06-10 10:29
---
Fixed for 4.5.1.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from schwab at linux-m68k dot org 2010-06-10 10:59 ---
You can use them as many times as needed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
--- Comment #7 from schwab at linux-m68k dot org 2010-06-10 11:06 ---
A matched constraint can never have side effects, and the powerpc specific uses
are already correct (though they could take advantage of the es or Z
constraints).
--
--- Comment #3 from hp at gcc dot gnu dot org 2010-06-10 11:11 ---
*** This bug has been marked as a duplicate of 44460 ***
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from hp at gcc dot gnu dot org 2010-06-10 11:11 ---
*** Bug 44453 has been marked as a duplicate of this bug. ***
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from hp at gcc dot gnu dot org 2010-06-10 11:13 ---
Committed.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #11 from hp at gcc dot gnu dot org 2010-06-10 11:13 ---
Subject: Bug 44460
Author: hp
Date: Thu Jun 10 11:12:12 2010
New Revision: 160533
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160533
Log:
PR rtl-optimization/44460
* emit-rtl.c
--- Comment #8 from jakub at gcc dot gnu dot org 2010-06-10 11:36 ---
Don't understand the last comment.
If matched constraint can't have side-effects, then this bug is valid and
auto-inc-dec.c should just do if (asm_noperands (insn) = 0) continue;
similarly how it refuses to auto-inc
--- Comment #9 from schwab at linux-m68k dot org 2010-06-10 11:50 ---
You cannot use an m operand more than once, since it can include side
effects.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
--- Comment #10 from fche at redhat dot com 2010-06-10 12:11 ---
(In reply to comment #9)
You cannot use an m operand more than once, since it can include side
effects.
Nor less than once, apparently.
--
fche at redhat dot com changed:
What|Removed
--- Comment #1 from andi-gcc at firstfloor dot org 2010-06-10 12:22 ---
I noticed that setting -fwhole-program on both compile and link stage
makes the weak problem go away. Expected?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
--- Comment #11 from jakub at gcc dot gnu dot org 2010-06-10 12:24 ---
I believe for GCC it shouldn't be hard to at least easily detect the used zero
times case which happens very often in lost of code.
asm (... %2 ... : =m (*p) : m (*p), r (p));
is just very common, the =m and m just
--- Comment #12 from matz at gcc dot gnu dot org 2010-06-10 12:26 ---
I don't think it ever was intended that 'm' includes operands with embedded
side-effects. I don't think so because making this work reliably is
relatively difficult. In particular the tests that Jakub mentions would
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-10 12:29 ---
(In reply to comment #1)
I noticed that setting -fwhole-program on both compile and link stage
makes the weak problem go away. Expected?
No. -fwhole-program is ignored during compile stage if -flto or -fwhopr
is
--- Comment #15 from iains at gcc dot gnu dot org 2010-06-10 12:33 ---
back-ported to 4.5 release branch as r160541.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32052
--- Comment #13 from schwab at linux-m68k dot org 2010-06-10 12:39 ---
m is defined to be the most general memory constraint, and a pre/post
modified memory operand is still a memory operand.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
--- Comment #14 from schwab at linux-m68k dot org 2010-06-10 12:42 ---
asm (... %2 ... : =m (*p) : m (*p), r (p));
In this case the compiler should never use a side effect.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
--- Comment #15 from schwab at linux-m68k dot org 2010-06-10 12:46 ---
The %X modifier has nothing to do with side effects, it is used for indexed
addressing modes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2010-06-10 12:47
---
Patch submitted at: http://gcc.gnu.org/ml/fortran/2010-06/msg00091.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from andi-gcc at firstfloor dot org 2010-06-10 12:58 ---
On the link stage it's apparently not ignored and it fixes the weak
problem.
So just whatever weak magic -fwhole-program does would need to be done
when it's not enabled too.
--
--- Comment #8 from sandra at codesourcery dot com 2010-06-10 13:01 ---
I was barking up the wrong tree with my last idea -- the signed/unsigned
conversion business was a red herring. Here's what I now believe is the
problem: the costs computation is underestimating the register
--- Comment #10 from iains at gcc dot gnu dot org 2010-06-10 13:04 ---
back-ported to 4.5. release branch as r160546.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35996
--- Comment #16 from andi-gcc at firstfloor dot org 2010-06-10 13:20
---
I reduced another of my ICEs from this build and it's in the same place.
(gdb) bt
#0 var_map_base_init (map=0x10abe60) at ../../gcc/gcc/tree-ssa-live.c:87
#1 0x007248fb in coalesce_ssa_name () at
--- Comment #17 from andi-gcc at firstfloor dot org 2010-06-10 13:21
---
Created an attachment (id=20882)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20882action=view)
other test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- Comment #16 from fche at redhat dot com 2010-06-10 13:24 ---
(In reply to comment #13)
m is defined to be the most general memory constraint, and a pre/post
modified memory operand is still a memory operand.
If this is to stand, please amend the documentation to warn about this.
--- Comment #10 from paolo dot carlini at oracle dot com 2010-06-10 13:35
---
Still looking for feedback from the port maintainer... Suresh, the next issue
you are having should be reported separately, it's a compiler proper issue,
being an internal compiler error.
--
paolo dot
--- Comment #22 from paolo dot carlini at oracle dot com 2010-06-10 13:38
---
Jon, I would recommend closing this. We don't want to fiddle with auto_ptr
anyway, and the small issue with shared_ptr is fixed for 4.6.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
--- Comment #17 from matz at gcc dot gnu dot org 2010-06-10 13:34 ---
m is defined to be the most general memory constraint, and a pre/post
modified memory operand is still a memory operand.
I know that this is the case, which is why I said: If that means to slightly
change the
--- Comment #23 from redi at gcc dot gnu dot org 2010-06-10 13:54 ---
we have regressed in terms of the warning, but no diagnostic is required and
auto_ptr is deprecated in C++0x, so WONTFIX
--
redi at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from paolo dot carlini at oracle dot com 2010-06-10 14:07
---
I'm tempted to commit Suresh patch, properly tweaked for the copyright years,
in mainline and close the PR: I think it's short enough to not require a full
assignment, and we can certainly improve the
--- Comment #11 from hjl dot tools at gmail dot com 2010-06-10 14:30
---
(In reply to comment #10)
(In reply to comment #9)
Following patch is also needed to fix conditional splitting (it does not
fix
original uncovered problem where BLOCK_FOR_INSN returns null):
I am
--- Comment #4 from domob at gcc dot gnu dot org 2010-06-10 14:48 ---
Subject: Bug 38936
Author: domob
Date: Thu Jun 10 14:47:49 2010
New Revision: 160550
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160550
Log:
2010-06-10 Daniel Kraft d...@domob.eu
PR fortran/38936
--- Comment #12 from paolo at gcc dot gnu dot org 2010-06-10 14:53 ---
Subject: Bug 43918
Author: paolo
Date: Thu Jun 10 14:53:15 2010
New Revision: 160551
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160551
Log:
2010-06-10 Suresh Gumpula suresh.gump...@amd.com
PR
--- Comment #13 from paolo dot carlini at oracle dot com 2010-06-10 14:54
---
Fixed for 4.6.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #12 from ubizjak at gmail dot com 2010-06-10 14:57 ---
(In reply to comment #11)
I am not sure this is correct. The code prior to revision 160394 was
written in such a way to support X86_TUNE_OPT_AGU. We may have missed
some cases. But it is mostly correct. I'd
--- Comment #13 from ubizjak at gmail dot com 2010-06-10 14:59 ---
(In reply to comment #12)
(In reply to comment #11)
I am not sure this is correct. The code prior to revision 160394 was
written in such a way to support X86_TUNE_OPT_AGU. We may have missed
some cases.
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-06-10 15:04 ---
Testing fix.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from schwab at linux-m68k dot org 2010-06-10 15:09 ---
One option is to add a sequence point before every asm statement.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
--- Comment #14 from ubizjak at gmail dot com 2010-06-10 15:12 ---
(In reply to comment #11)
ADD is always faster than LEA for adding a register. However
there is a special case on Atom where ADD should be avoided.
It is true that LEA doesn't touch flags and we used it instead
of
--- Comment #13 from jakub at gcc dot gnu dot org 2010-06-10 15:16 ---
Subject: Bug 43838
Author: jakub
Date: Thu Jun 10 15:15:18 2010
New Revision: 160554
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160554
Log:
PR other/43838
* cp-demangle.c (struct
--- Comment #19 from schwab at linux-m68k dot org 2010-06-10 15:19 ---
Of course, there _is_ already a sequence point before every statement. Doh.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
--- Comment #20 from jakub at gcc dot gnu dot org 2010-06-10 15:22 ---
Another option is to disallow side-effects in inline asm memory operands and
let the user explicitly request that the side-effects are possible, through
some new constraint modifier (e.g. _ used as _mi or =_g would
--- Comment #14 from jakub at gcc dot gnu dot org 2010-06-10 15:24 ---
Subject: Bug 43838
Author: jakub
Date: Thu Jun 10 15:24:11 2010
New Revision: 160555
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160555
Log:
PR other/43838
* cp-demangle.c (struct
--- Comment #8 from jakub at gcc dot gnu dot org 2010-06-10 15:32 ---
Subject: Bug 10197
Author: jakub
Date: Thu Jun 10 15:31:56 2010
New Revision: 160556
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160556
Log:
PR other/43838
* cp-demangle.c (struct
--- Comment #15 from jakub at gcc dot gnu dot org 2010-06-10 15:32 ---
Subject: Bug 43838
Author: jakub
Date: Thu Jun 10 15:31:56 2010
New Revision: 160556
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160556
Log:
PR other/43838
* cp-demangle.c (struct
--- Comment #15 from hjl dot tools at gmail dot com 2010-06-10 15:43
---
(In reply to comment #14)
(In reply to comment #11)
ADD is always faster than LEA for adding a register. However
there is a special case on Atom where ADD should be avoided.
It is true that LEA doesn't
--- Comment #8 from zsojka at seznam dot cz 2010-06-10 15:45 ---
Is there a chance this will be backported to 4.5? As Jakub pointed out at
PR44178/comment #7, gcc 4.5 r160526 (with RTL checking) fails on this testcase
with:
$ gcc -fsched-pressure -fschedule-insns pr43332/testcase.c
--- Comment #16 from hjl at gcc dot gnu dot org 2010-06-10 16:01 ---
Subject: Bug 44470
Author: hjl
Date: Thu Jun 10 16:00:31 2010
New Revision: 160557
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160557
Log:
Revert the part of r160394 to fix bootstap with --with-arch=atom.
--- Comment #2 from j-etienne at users dot sourceforge dot net 2010-06-10
16:39 ---
avr/wdt.h does provide the means to stop/start/refresh the watchdog from the
main C program. But, as said in the original comment, if the bss and/or data
section is too large, the CPU spends a lot of
--- Comment #3 from j at uriah dot heep dot sax dot de 2010-06-10 16:43
---
(In reply to comment #2)
avr/wdt.h does provide the means to stop/start/refresh the watchdog from the
main C program.
No. It contains a fairly detailed description how to place the
watchdog
--- Comment #2 from marc dot mengel at gmail dot com 2010-06-10 16:43
---
This could be a disaster if floating point exceptions are enabled, as it would
trigger an exception whenever some part of the block was an invalid floating
point number.
One would at least need to save/restore
--- Comment #41 from aoliva at gcc dot gnu dot org 2010-06-10 16:44 ---
Subject: Bug 41371
Author: aoliva
Date: Thu Jun 10 16:43:46 2010
New Revision: 160559
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160559
Log:
PR debug/41371
* var-tracking.c (find_loc_in_1pdv): Remove
--- Comment #12 from jamborm at gcc dot gnu dot org 2010-06-10 16:49
---
Subject: Bug 44258
Author: jamborm
Date: Thu Jun 10 16:49:09 2010
New Revision: 160561
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160561
Log:
2010-06-10 Martin Jambor mjam...@suse.cz
PR
--- Comment #5 from domob at gcc dot gnu dot org 2010-06-10 16:50 ---
This first commit implements association to scalar expressions as a first step.
More to follow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38936
--- Comment #42 from aoliva at gcc dot gnu dot org 2010-06-10 17:01 ---
Subject: Bug 41371
Author: aoliva
Date: Thu Jun 10 17:01:32 2010
New Revision: 160563
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160563
Log:
PR debug/41371
* var-tracking.c (find_loc_in_1pdv): Remove
--- Comment #21 from jakub at gcc dot gnu dot org 2010-06-10 17:06 ---
Created an attachment (id=20883)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20883action=view)
gcc46-pr44494.patch
WIP patch that implements that. Still missing documentation, testcases and
likely also doing
--- Comment #4 from eric dot weddington at atmel dot com 2010-06-10 17:16
---
Again: setting this to INVALID.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #45 from mark dot workman at acm dot org 2010-06-10 17:43
---
(In reply to comment #40)
with my toolchain (From CodeSourcery, 4.4-78), o1test gives correct behavior
with built-in flags(-te500v2), but wrong behaviors with -fcaller-saves -O
-fno-omit-frame-pointer -fno-dce
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-06-10 17:47 ---
(In reply to comment #2)
Thus, I do not see why one should add another version check.
Fine by me.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ro at gcc dot gnu dot org 2010-06-10 17:53 ---
Jakub, perhaps you could have a look? This problem existed long before the
current round of emutls breakage.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from spop at gcc dot gnu dot org 2010-06-10 17:55 ---
Subject: Bug 44185
Author: spop
Date: Thu Jun 10 17:54:39 2010
New Revision: 160566
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160566
Log:
Fix PR44185: prefetch test failures.
2010-06-10 Changpeng Fang
Since a few days, a couple of __sync_fetch_and_* testcases fail on Solaris
2/SPARC
(Solaris 8 to 10), both 32 and 64-bit, Sun as and gas:
+FAIL: gcc.c-torture/compile/sync-3.c -O2 (test for excess errors)
+FAIL: gcc.c-torture/compile/sync-3.c -O3 -fomit-frame-pointer (test for
exces
s errors)
--- Comment #1 from ro at gcc dot gnu dot org 2010-06-10 18:18 ---
Created an attachment (id=20884)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20884action=view)
working sync-3.s from gcc 4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44494
--- Comment #2 from ro at gcc dot gnu dot org 2010-06-10 18:18 ---
Created an attachment (id=20885)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20885action=view)
broken sync-3.s from mainline
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44494
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-06-10 18:26 ---
Subject: Bug 44457
Author: dfranke
Date: Thu Jun 10 18:25:56 2010
New Revision: 160567
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160567
Log:
gcc/fortran/:
2010-06-10 Daniel Franke
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-06-10 18:26 ---
Thus fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Since some time, bootstrap on Solaris 11/SPARC fails building the 32-bit
libgcj_tools_la-tools.lo:
/bin/ksh ./libtool --tag=GCJ --mode=compile
/vol/gcc/obj/regression/trunk/11-gcc/build/./gcc/gcj -v
-B/vol/gcc/obj/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libjava/
--- Comment #7 from aoliva at gcc dot gnu dot org 2010-06-10 18:50 ---
Steve, I only see problems on ia64 at -O3, and that's because VTA is disabled
when selective scheduling is enabled.
Uros, I can't duplicate the problem with a cross compiler for alpha: the debug
info in the assembly
--- Comment #5 from spop at gcc dot gnu dot org 2010-06-10 22:59 ---
Patch http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01155.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44483
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-10 23:02 ---
I got
[...@gnu-29 testsuite]$ ../gfortran -B../ -S
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/maxlocval_2.f90
-O1
--- Comment #1 from jv244 at cam dot ac dot uk 2010-06-10 19:12 ---
Created an attachment (id=20886)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20886action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44496
--- Comment #5 from jamborm at gcc dot gnu dot org 2010-06-10 21:39 ---
Mine
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2010-06-10 19:51
---
Patch proposed at: http://gcc.gnu.org/ml/fortran/2010-06/msg00099.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
On Linux/Intel64, 160556 gave
FAIL: libgomp.fortran/lock-1.f90 -O3 -g (internal compiler error)
FAIL: libgomp.fortran/lock-1.f90 -O3 -g (test for excess errors)
FAIL: libgomp.fortran/task1.f90 -O2 (internal compiler error)
FAIL: libgomp.fortran/task1.f90 -O2 (internal compiler error)
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-06-10 19:58 ---
(In reply to comment #2)
This could be a disaster if floating point exceptions are enabled, as it would
trigger an exception whenever some part of the block was an invalid floating
point number.
One would at
1 - 100 of 136 matches
Mail list logo
