--- Comment #8 from janus at gcc dot gnu dot org 2010-06-11 02:56 ---
(In reply to comment #7)
> At r160588 of gfortran 4.6 trunk, the patch in comment #3 fixes the codes in
> comment #1 and #6, but comment #0 seems to get stuck in some kind of infinite
> loop.
Btw, it also fixes the te
--- Comment #7 from janus at gcc dot gnu dot org 2010-06-11 02:50 ---
At r160588 of gfortran 4.6 trunk, the patch in comment #3 fixes the codes in
comment #1 and #6, but comment #0 seems to get stuck in some kind of infinite
loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
--- Comment #37 from phmagic at mail dot ru 2010-06-11 01:43 ---
Thank you, Ed. I missed that. I wrongly (obviously wrongly, because this would
negatively affect performance) thought that ABI is such that stack is aligned
after the call, not before.
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #5 from janus at gcc dot gnu dot org 2010-06-11 01:42 ---
Subject: Bug 44207
Author: janus
Date: Fri Jun 11 01:42:38 2010
New Revision: 160589
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160589
Log:
2010-06-10 Janus Weil
PR fortran/44207
* reso
--- Comment #3 from manu at gcc dot gnu dot org 2010-06-11 01:13 ---
Testing this patch:
Index: gcc/testsuite/g++.dg/pr44486.C
===
--- gcc/testsuite/g++.dg/pr44486.C (revision 0)
+++ gcc/testsuite/g++.dg/pr44486.C
--- Comment #46 from harry dot he at freescale dot com 2010-06-11 01:09
---
Mark, I have reported the issue to CodeSourcery and waiting them to confirm, I
guess our toolchain may need different patches for it, or there is something
wrong in my validation.
--
harry dot he at freescal
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-10 22:42 ---
The error looks like:
/export/gnu/import/rrs/160549/src/libgomp/testsuite/libgomp.fortran/task1.f90:
In function 'MAIN__._omp_fn.1':^M
/export/gnu/import/rrs/160549/src/libgomp/testsuite/libgomp.fortran/task1.f90:11
--- Comment #36 from ed at catmur dot co dot uk 2010-06-10 21:28 ---
Alexander, you're omitting to consider that call pushes EIP + 4 onto the stack.
Thus on entry the stack is already misaligned by -4, so gcc is correct.
--
ed at catmur dot co dot uk changed:
What|Re
--- Comment #11 from hp at gcc dot gnu dot org 2010-06-10 21:02 ---
(In reply to comment #10)
> Now (with r160560) appearing for cris-elf too!
Forgot to mention that it last worked for cris-elf with r160547.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
On Linux/ia32, revision 160551 gave
FAIL: gfortran.dg/maxlocval_2.f90 -O1 (internal compiler error)
FAIL: gfortran.dg/maxlocval_2.f90 -O1 (test for excess errors)
Revision 160538 is OK
--
Summary: [4.6 Regression] gfortran.dg/maxlocval_2.f90
Product: gcc
Ve
--- Comment #7 from hjl dot tools at gmail dot com 2010-06-10 22:02 ---
The testcase failed on Linux/ia64 at -O:
[...@gnu-12 gcc]$ ./xgcc -B./ -O
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/pr42461.c
/tmp/ccmdb99H.o: In function `main':
pr42461.c:(.text+0x22): undef
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-06-10 19:54 ---
This gives a proper locus:
Index: expr.c
===
--- expr.c (revision 160567)
+++ expr.c (working copy)
@@ -3203,7 +3203,7 @@ gfc_check_assign (g
--- Comment #17 from hjl dot tools at gmail dot com 2010-06-10 19:16
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #8 from paolo dot carlini at oracle dot com 2010-06-10 23:23
---
Thanks Janis. I think that Jason reviewed your C++ contributions regarding
decimal floating point, thus, once more, I'm adding him in CC hoping for help
on this issue.
In a nutshell, it seems that something is
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-06-10 19:43 ---
With '-Wall' one also gets:
$ gfortran-svn -Wall pr44491.f90
pr44491.f90:1.31:
character*2 escape /'1B'x/
1
Warning: BOZ literal at (1) is bitwise transferred non-integer symbol
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2010-06-10 20:36
---
Patch proposed at: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01143.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #35 from phmagic at mail dot ru 2010-06-10 19:08 ---
Hello,
I just upgraded to gcc-4.4.3 (from Gentoo distribution) and recompiled the
whole system (on x86). Then I had to discover the (as it turned to be,
infamous) mozilla-firefox + zlib bug. I reported it to the distributi
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2010-06-10 20:03
---
Subject: Bug 36234
Author: fxcoudert
Date: Thu Jun 10 20:02:39 2010
New Revision: 160569
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160569
Log:
PR fortran/38273
* gfortran.texi: Docume
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-10 22:54 ---
mesa in SPEC CPU 2000 failed to compile:
/export/gnu/import/rrs/160549/usr/bin/gcc -S -DSPEC_CPU2000_LP64 -O2
-ffast-math -O3 -ffast-math -funroll-loops vbfill.c
gnu-32:pts/5[189]> /export/gnu/import/rr
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-10 22:40 ---
It is caused by revision 160549:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00464.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from kargl at gcc dot gnu dot org 2010-06-10 22:37 ---
This is a context free PR. Please provide details.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from hp at gcc dot gnu dot org 2010-06-10 21:00 ---
Now (with r160560) appearing for cris-elf too!
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-10 23:20 ---
From:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01081.html
if (!df_live_scratch)
-df_live_scratch = BITMAP_ALLOC (NULL);
+df_live_scratch = BITMAP_ALLOC (&problem_data->live_bitmaps);
...
+ bitma
--- Comment #8 from sje at cup dot hp dot com 2010-06-10 19:27 ---
I see pr41353-1.c failures with -O2 -flto and -O2 -fwhopr as well as with -O3.
I also see other guality tests fail with non -O3 flags.
See http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00991.html
--
http://gcc.gn
--- Comment #7 from janis at gcc dot gnu dot org 2010-06-10 21:58 ---
The new decimal* classes are sometimes treated as classes, sometimes as
scalars. From a first look, something might be going wrong with the use of
__are_same in bits/std_iterator.h so that it needs special casing for
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2010-06-10 20:03
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2010-06-10 20:03
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Known to work||4.5.1
Summary|ICE: segfault: |[4.6 Regression] IC
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2010-06-10 19:15
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2010-06-10 19:14
---
Subject: Bug 43032
Author: fxcoudert
Date: Thu Jun 10 19:14:12 2010
New Revision: 160568
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160568
Log:
PR fortran/43032
* intrinsic.texi (FLUSH
del: posix
gcc version 4.6.0 20100610 (experimental) [trunk revision 160564] (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-O1' '-fbounds-check' '-mtune=generic'
'-march=x86-64'
/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-06-10 19:09 ---
The same ICE is triggered by
subroutine s
contains
SUBROUTINE s
END SUBROUTINE
end subroutine
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2010-06-10 19:35
---
Patch proposed at: http://gcc.gnu.org/ml/fortran/2010-06/msg00098.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-06-10 20:08 ---
(In reply to comment #2)
> This gives a proper locus:
And fails the regression test on gfortran.dg/data_array_5.f90 - this turns out
to be another variation of PR35849.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2010-06-10 20:03
---
Subject: Bug 38273
Author: fxcoudert
Date: Thu Jun 10 20:02:39 2010
New Revision: 160569
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160569
Log:
PR fortran/38273
* gfortran.texi: Docume
--- 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
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)
FAIL:
--- 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
-
--- 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
AssignedTo|unassigned
--- 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=20886&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44496
--- 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
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/maxlocv
--- 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 #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
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/
-B/vol/gcc/obj/regre
--- 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
--- 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=gcc&view=rev&rev=160567
Log:
gcc/fortran/:
2010-06-10 Daniel Franke
PR fortran
--- 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=20885&action=view)
broken sync-3.s from mainline
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44494
--- 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=20884&action=view)
working sync-3.s from gcc 4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44494
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 #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=gcc&view=rev&rev=160566
Log:
Fix PR44185: prefetch test failures.
2010-06-10 Changpeng Fang
--- 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 #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 #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-
--- 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 #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=20883&action=view)
gcc46-pr44494.patch
WIP patch that implements that. Still missing documentation, testcases and
likely also doin
--- 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=gcc&view=rev&rev=160563
Log:
PR debug/41371
* var-tracking.c (find_loc_in_1pdv): Remove rec
--- 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 #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=gcc&view=rev&rev=160561
Log:
2010-06-10 Martin Jambor
PR tree-optimization/4
--- 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=gcc&view=rev&rev=160559
Log:
PR debug/41371
* var-tracking.c (find_loc_in_1pdv): Remove rec
--- 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 the
--- Comment #3 from j at uriah dot heep dot sax dot de 2010-06-10 16:43
---
(In reply to comment #2)
> 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 reset/initialization int
--- Comment #2 from j-etienne at users dot sourceforge dot net 2010-06-10
16:39 ---
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 time initial
--- 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=gcc&view=rev&rev=160557
Log:
Revert the part of r160394 to fix bootstap with --with-arch=atom.
2
--- 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
pr43
--- 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 doe
--- 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=gcc&view=rev&rev=160556
Log:
PR other/43838
* cp-demangle.c (struct d_print_i
--- 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=gcc&view=rev&rev=160556
Log:
PR other/43838
* cp-demangle.c (struct d_print_in
--- 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=gcc&view=rev&rev=160555
Log:
PR other/43838
* cp-demangle.c (struct d_print_i
--- 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" woul
--- 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 #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=gcc&view=rev&rev=160554
Log:
PR other/43838
* cp-demangle.c (struct d_print_i
--- 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
> o
--- 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 #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
AssignedTo|una
--- 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
> > > >
--- 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
--- 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 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=gcc&view=rev&rev=160551
Log:
2010-06-10 Suresh Gumpula
PR libstdc++/43918
--- 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=gcc&view=rev&rev=160550
Log:
2010-06-10 Daniel Kraft
PR fortran/38936
* gf
--- 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):
--- 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 msdosdjg
--- 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 |Add
--- 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 d
--- 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 #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 carl
--- 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 thi
--- 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=20882&action=view)
other test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- 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
../../g
--- 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 #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 pressur
--- 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.
--
http://gcc.gnu.org/bugzilla/show
--- 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 #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 #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 #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 #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 #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
i
--- 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 #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" an
1 - 100 of 134 matches
Mail list logo
