Hello Jack,
* Jack Howarth wrote on Fri, Mar 26, 2010 at 01:13:16AM CET:
While testing a patch to update the minimum version
of cloog-ppl in gcc trunk...
--- configure.ac(revision 157732)
+++ configure.ac(working copy)
@@ -1612,9 +1612,9 @@
if test x$with_cloog != xno
On Sat, Mar 27, 2010 at 07:56:14AM +0100, Ralf Wildenhues wrote:
Hello Jack,
* Jack Howarth wrote on Fri, Mar 26, 2010 at 01:13:16AM CET:
While testing a patch to update the minimum version
of cloog-ppl in gcc trunk...
--- configure.ac(revision 157732)
+++ configure.ac
On Fri, Mar 26, 2010 at 11:21:27AM -0700, Neil Vachharajani wrote:
Thanks for re-raising this issue. I'm certainly interested in
applying the patch. I figured I had missed the boat for GCC 4.5 and
was going to re-re-raise the issue for 4.6. I someone approves the
patch, I'll apply it once
On Sat, Mar 27, 2010 at 12:17, Jack Howarth howa...@bromo.med.uc.edu wrote:
On Sat, Mar 27, 2010 at 07:56:14AM +0100, Ralf Wildenhues wrote:
Hello Jack,
* Jack Howarth wrote on Fri, Mar 26, 2010 at 01:13:16AM CET:
While testing a patch to update the minimum version
of cloog-ppl in gcc
--- Comment #2 from pault at gcc dot gnu dot org 2010-03-27 07:55 ---
This is a bit odd. SIZEOF seems to be properly registered in intrinsic.c:
add_sym_1 (sizeof, GFC_ISYM_SIZEOF, NO_CLASS, ACTUAL_NO, BT_INTEGER, ii,
GFC_STD_GNU, gfc_check_sizeof, NULL, NULL,
--- Comment #3 from meissner at gcc dot gnu dot org 2010-03-27 10:27
---
Subject: Bug 43544
Author: meissner
Date: Sat Mar 27 10:27:39 2010
New Revision: 157770
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157770
Log:
PR 43544, change
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-03-27 10:41 ---
Fixed on trunk sofar.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-27 10:44 ---
Created an attachment (id=20223)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20223action=view)
preprocessed source
Downloaded and attached.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43548
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-03-27 10:45 ---
I very much doubt that the cited revision fixed anything here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43247
--- Comment #5 from hubicka at ucw dot cz 2010-03-27 10:53 ---
Subject: Re: [4.5 Regression] make_decl_rtl failure
for C++ on AIX and HPUX
Honza - ping.
There is proposed patch sent to ML
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00789.html
I've missed that Steve Ellcey
--- Comment #4 from zsojka at seznam dot cz 2010-03-27 10:57 ---
Indeed, r157766 no longer crashes
*** This bug has been marked as a duplicate of 43381 ***
--
zsojka at seznam dot cz changed:
What|Removed |Added
--- Comment #7 from zsojka at seznam dot cz 2010-03-27 10:57 ---
*** Bug 43501 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43381
--- Comment #116 from rguenth at gcc dot gnu dot org 2010-03-27 11:14
---
Given that parsing takes most of the time the compile-time indeed looks
reasonable. That DF uses 20GB of ram at -O3 is still unfortunate, but the
-O1 numbers look indeed good.
I wonder if the parsing numbers
--- Comment #8 from jsm28 at gcc dot gnu dot org 2010-03-27 11:46 ---
Subject: Bug 43381
Author: jsm28
Date: Sat Mar 27 11:46:07 2010
New Revision: 157772
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157772
Log:
PR c/43381
* c-decl.c (get_parm_info): Assert that
--- Comment #9 from jsm28 at gcc dot gnu dot org 2010-03-27 11:47 ---
Fixed for 4.4.4 and 4.5.0.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from hubicka at gcc dot gnu dot org 2010-03-27 11:56 ---
Subject: Bug 43391
Author: hubicka
Date: Sat Mar 27 11:56:30 2010
New Revision: 157773
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157773
Log:
PR middle-end/43391
* varasm.c
--- Comment #11 from developer at sandoe-acoustics dot co dot uk
2010-03-27 11:59 ---
It seems that objc_start_function is expecting a TREE in the objcpp case - so
the error marked node is indeed unexpected.
I've tried this on i686-darwin and i32-linux - but there are obviously a lot
--- Comment #15 from uros at gcc dot gnu dot org 2010-03-27 12:09 ---
Subject: Bug 42113
Author: uros
Date: Sat Mar 27 12:09:24 2010
New Revision: 157774
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157774
Log:
PR target/42113
* config/alpha/alpha.md
--- Comment #16 from uros at gcc dot gnu dot org 2010-03-27 12:16 ---
Subject: Bug 42113
Author: uros
Date: Sat Mar 27 12:15:50 2010
New Revision: 157775
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157775
Log:
PR target/42113
* config/alpha/alpha.md
--- Comment #17 from ubizjak at gmail dot com 2010-03-27 12:17 ---
Fixed in a better way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-03-27 12:45 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from ubizjak at gmail dot com 2010-03-27 12:52 ---
This patch also works:
Index: stor-layout.c
===
--- stor-layout.c (revision 157756)
+++ stor-layout.c (working copy)
@@ -1346,11 +1346,12 @@
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-27 12:53 ---
No, sseregparm should be perfectly fine with x87 math - it only needs
(obviously) SSE registers available. It's an ABI switch like regparm,
whether math is done using SSE registers or x87 math doesn't and shouldn't
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-03-27 12:54
---
(In reply to comment #9)
This patch also works:
Index: stor-layout.c
===
--- stor-layout.c (revision 157756)
+++ stor-layout.c
--- Comment #7 from developer at sandoe-acoustics dot co dot uk 2010-03-27
13:10 ---
see
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01282.html
hopefully, that's a reasonable way to fix.
--
developer at sandoe-acoustics dot co dot uk changed:
What|Removed
--- Comment #11 from uros at gcc dot gnu dot org 2010-03-27 13:40 ---
Subject: Bug 43528
Author: uros
Date: Sat Mar 27 13:40:08 2010
New Revision: 157776
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157776
Log:
PR tree-optimization/43528
* stor-layout.c
--- Comment #5 from hjl dot tools at gmail dot com 2010-03-27 14:11 ---
(In reply to comment #4)
No, sseregparm should be perfectly fine with x87 math - it only needs
(obviously) SSE registers available. It's an ABI switch like regparm,
whether math is done using SSE registers or
--- Comment #8 from hjl dot tools at gmail dot com 2010-03-27 14:24 ---
(In reply to comment #7)
I very much doubt that the cited revision fixed anything here.
If it is true, that only means that the bug is latent on trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43247
--- Comment #2 from pogonyshev at gmx dot net 2010-03-27 14:36 ---
I'm sorry, but why? Isn't the compiler the same? What is the point of not
providing good type traits if you can?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43549
--- Comment #4 from developer at sandoe-acoustics dot co dot uk 2010-03-27
14:38 ---
shouldn't this be NeXT-specific - i.e. skipped for -fgnu-runtime, rather than
XFAILED?
--
developer at sandoe-acoustics dot co dot uk changed:
What|Removed
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-03-27 15:23 ---
(In reply to comment #5)
(In reply to comment #4)
No, sseregparm should be perfectly fine with x87 math - it only needs
(obviously) SSE registers available. It's an ABI switch like regparm,
whether math is
--- Comment #7 from hjl dot tools at gmail dot com 2010-03-27 15:37 ---
(In reply to comment #6)
I don't follow. TARGET_SSEREGPARM does not mean you'll do SSE math.
It merely says that you can expect incoming arguments in SSE registers
instead of on stack. For
--- Comment #12 from danglin at gcc dot gnu dot org 2010-03-27 15:43
---
Subject: Bug 41674
Author: danglin
Date: Sat Mar 27 15:43:19 2010
New Revision: 157779
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157779
Log:
PR middle-end/41674
* cgraphunit.c
--- Comment #13 from danglin at gcc dot gnu dot org 2010-03-27 15:53
---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #117 from lucier at math dot purdue dot edu 2010-03-27 16:38
---
Subject: Re: [4.3/4.4/4.5 Regression] Inordinate compile times on large
routines
On Mar 27, 2010, at 7:14 AM, rguenth at gcc dot gnu dot org wrote:
I wonder if the parsing numbers are accurate as the
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-27 16:38 ---
Just to clarify, the issue is that
(insn 6 5 7 2 t.i:2 (set (reg:DF 21 xmm0)
(float_extend:DF (mem/u/c/i:SF (symbol_ref/u:SI (*.LC0) [flags 0x2])
[0 S4 A32]))) 99 {*extendsfdf2_i387} (expr_list:REG_EQUAL
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-03-27 16:39 ---
In fact reduce_alignment_ok is _only_ used in the assert.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43546
--- Comment #118 from lucier at math dot purdue dot edu 2010-03-27 16:44
---
Created an attachment (id=20224)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20224action=view)
time/memory report compiling all.i with -O3
These are the detailed time and memory statistics reported
--- Comment #1 from pault at gcc dot gnu dot org 2010-03-27 17:59 ---
With the function calls interchanged, the problem goes away. ie. with:
write (*,*) shape(this%myarray) /= shape(array) ! SEGFAULT
I can't see from the code yet why this is happening but can confirm the bug.
Paul
--- Comment #9 from hubicka at gcc dot gnu dot org 2010-03-27 18:30 ---
Have patch in testing. Problem is that inliner is copying the clone info
including the replacement when producing clone of clone that leads to
transformations sometimes being applied multiple times.
--
hubicka
--- Comment #26 from hubicka at gcc dot gnu dot org 2010-03-27 18:31
---
Patch queued for next stage1
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2010-03-27 18:45 ---
Replacing the gcc_assert with
if (!overriding || !overriding-n.tb)
return FAILURE;
Fixes the problem. This looks like one ICE too far :-)
It might be best, I suppose, to limit the above to overriding
--- Comment #3 from pault at gcc dot gnu dot org 2010-03-27 18:47 ---
Confirmed
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from pault at gcc dot gnu dot org 2010-03-27 18:53 ---
What is the status of this one Tobias?
I'll confirm it whilst I'm here :-)
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2010-03-27 18:55 ---
Tobias,
Can this be closed now?
Certainly, it can be confirmed!
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from ghazi at gcc dot gnu dot org 2010-03-27 18:56 ---
Subject: Bug 39254
Author: ghazi
Date: Sat Mar 27 18:56:08 2010
New Revision: 157780
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157780
Log:
Backport:
2009-06-16 Jorn Rennecke
--- Comment #26 from ghazi at gcc dot gnu dot org 2010-03-27 19:03 ---
Completed full bootstrap and testsuite on powerpc-unknown-linux-gnu with extra
-fpic/-fPIC passes. The only difference was that the testcase va-arg-trap-1.c
was fixed.
Installed on 4.4 branch.
--
ghazi at gcc
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-27 19:05 ---
I suppose I should have provided a testcase. The FE now produces control-flow
free allocation like:
D.1612 = D.1601 - D.1600;
atmp.5.dtype = 537;
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-03-27 19:06 ---
Created an attachment (id=20225)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20225action=view)
testcase from tonto
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-03-27 19:08
---
The gimplifier of course transforms the COND_EXPRs back to control flow, thus
the CFG looks like
D.1616 = D.1612 0;
D.1617 = D.1612 + 1;
if (D.1616 != 0)
goto bb 32;
else
goto bb 33;
bb 32:
--- Comment #13 from pault at gcc dot gnu dot org 2010-03-27 19:11 ---
Can we close this one, guys?
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43146
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-03-27 19:12
---
The middle-end ends up with the following optimized:
D.1776_95 = D.1775_94 - D.1591_90;
if (D.1776_95 = 0)
goto bb 34;
else
goto bb 33;
bb 33:
D.1620_204 = __builtin_malloc (D.1795_11);
--- Comment #3 from paolo dot carlini at oracle dot com 2010-03-27 19:27
---
Because maintaining more code is a burden, and TR1, now that C++1x is around
the corner is just history, from now on will be only *minimally* maintained.
--
--- Comment #4 from pogonyshev at gmx dot net 2010-03-27 19:33 ---
From info:
...some of which have been implemented in an experimental C++0x mode in GCC.
Instead of maintaining a separate piece of code you could have one just include
another so that they are the same and be done with
Quantum Espresso (http://www.quantum-espresso.org/download.php) is miscompiled,
cf. http://www.democritos.it/pipermail/pw_forum/2010-March/016356.html
Fetch code, configure with F77=gfortran F90=gfortran and compile. Run the
example02 and compare the output for ph.x si.dynG with the reference,
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-27 19:41 ---
This is very little information. What target, what set of optimization
options?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43551
--- Comment #2 from burnus at gcc dot gnu dot org 2010-03-27 19:52 ---
Working: 2009-04-05-r145558
Failing: 2009-04-06-r145580
Changelog shows a couple of I/O patches - and indeed if one uses the working
version with the current 4.4.4 libgfortran the bug is also present. Now, I need
to
--- Comment #5 from paolo dot carlini at oracle dot com 2010-03-27 20:00
---
Evidently, you never studied the actual specs: the C++1x traits are different,
in many *incompatible* ways, eg is_lvalue_reference / is_rvalue_reference vs
is_reference. Many C++1x traits don't even compile in
--- Comment #5 from redi at gcc dot gnu dot org 2010-03-27 20:14 ---
With current versions this is only a warning not an error, changing keywords
from rejects-valid to diagnostic
(In reply to comment #3)
There is no other way to make a member-variable accessible only from all
objects
--- Comment #6 from redi at gcc dot gnu dot org 2010-03-27 20:19 ---
I think the warning is reasonable, but it would be nice if it could be
disabled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29615
--- Comment #3 from burnus at gcc dot gnu dot org 2010-03-27 20:56 ---
No success so far; I will try it tomorrow. To reproduce: Fetch, as written in
comment 0, the source code and untar it.
./configure F77=gfortran F90=gfortran FFLAGS_NOOPT='-O0 -g' BLAS_LIBS=-lblas
--- Comment #14 from kargl at gcc dot gnu dot org 2010-03-27 21:22 ---
(In reply to comment #13)
Can we close this one, guys?
Paul
Sure. I think that we've demonstrated that
it is a gentoo issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43146
--- Comment #18 from jakub at gcc dot gnu dot org 2010-03-27 21:39 ---
The first patch is now in, so this isn't a -fcompare-debug failure anymore.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2010-03-27 21:43 ---
Just another data point: I have disabled the format caching (format_cache_ok =
false in io/format.c), but it did not seem to help (on the trunk).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43551
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-27 21:55 ---
Fortran. P4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43505
--- Comment #6 from burnus at gcc dot gnu dot org 2010-03-27 22:22 ---
The XML reading seems to be OK - at least I have added some write statements to
iotk_dat.spp (at the dat = lines; then make update before clean build)
and the output is the same for the 2009-04-05 and the trunk
FAIL: gcc.dg/guality/pr41353-1.c -O2 -flto line 28 i == 37
FAIL: gcc.dg/guality/pr41353-1.c -O2 -flto line 28 i1 == 2 * 37
FAIL: gcc.dg/guality/pr41353-1.c -O2 -flto line 28 i2 == 3 * 37
FAIL: gcc.dg/guality/pr41353-1.c -O2 -fwhopr line 28 i == 37
FAIL: gcc.dg/guality/pr41353-1.c -O2
While testing the proposed patch to eliminate race conditions in indirect value
profiling...
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00892.html
I found that the many profile testcases failed due unresolved symbols such
as...
__emutls_v.__gcov_indirect_call_counters and
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-03-28
02:07 ---
I based my proposed patch roughly on the orginal patch that introduced the use
of -DHAVE_CC_TLS.
Author: hjl
Date: Fri Jul 6 14:00:46 2007
New Revision: 126416
URL:
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-03-28
02:16 ---
Created an attachment (id=20226)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20226action=view)
proposed patch to pass -DUSE_EMUTLS via libgcc/config/t-emutls on darwin
--
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2010-03-28 03:02
---
I am not able to help here until probably Monday night. Turning off format
caching is very easy for debugging purposes. I will keep an eye on this until
I can get to a workstation I can use.
--
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-03-28
04:39 ---
Regression testing of t-emutls.diff patch on x86_64-apple-darwin9 and
x86_64-apple-darwin10 at...
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg02419.html
--- Comment #1 from simartin at gcc dot gnu dot org 2010-03-28 05:16
---
Confirmed. Seems to be due to:
http://gcc.gnu.org/viewcvs/trunk/gcc/toplev.c?r1=117578r2=118362diff_format=h
--
simartin at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from simartin at gcc dot gnu dot org 2010-03-28 05:17
---
Seems to be due to:
http://gcc.gnu.org/viewcvs/trunk/gcc/toplev.c?r1=117578r2=118362diff_format=h
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-03-28
05:49 ---
Created an attachment (id=20227)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20227action=view)
revised proposed patch to pass -DUSE_EMUTLS via libgcc/config/t-emutls on
darwin
--
76 matches
Mail list logo
