--- Comment #14 from ebotcazou at gcc dot gnu dot org 2008-11-25 08:41
---
Subject: Bug 37319
Author: ebotcazou
Date: Tue Nov 25 08:39:39 2008
New Revision: 142188
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142188
Log:
PR fortran/37319
* parse.c
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2008-11-25 08:44
---
Patch installed.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from ubizjak at gmail dot com 2008-11-25 09:15 ---
Should we fix __sync_synchronize in 4.3 too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793
--- Comment #5 from ktietz at gcc dot gnu dot org 2008-11-25 10:22 ---
Created an attachment (id=16766)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16766action=view)
improved patch file
this fixes the callabi issues from sysv_abi-ms_abi.
As Lankhorst told me, that there seems to
--- Comment #28 from rguenth at gcc dot gnu dot org 2008-11-25 10:34
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from j dot s dot wijnhout at lumc dot nl 2008-11-25 11:00
---
The problem is of course during linking, which fails. But why should I expect
the following?:
* Using TemplatedClass works just fine stand-alone.
* Adding DependentTemplatedClass to the equation hides
--- Comment #5 from dennis dot wassel at googlemail dot com 2008-11-25
11:26 ---
gfortran also produces ICEs in this context:
gfortran -O1 -fdump-tree-vect-details -ftree-vectorize
-ftree-parallelize-loops=2 -c ma57.f
ma57.f: In function 'ma57id':
ma57.f:131: internal compiler error:
--- Comment #29 from rguenth at gcc dot gnu dot org 2008-11-25 10:35
---
Subject: Bug 38151
Author: rguenth
Date: Tue Nov 25 10:34:11 2008
New Revision: 142189
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142189
Log:
2008-11-25 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-11-25 10:35 ---
Subject: Bug 38236
Author: rguenth
Date: Tue Nov 25 10:34:11 2008
New Revision: 142189
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142189
Log:
2008-11-25 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-25 11:58 ---
Simpler testcase at -O
void
foo (unsigned long *start, unsigned long *end)
{
unsigned long *temp = end - 1;
while (end start)
*end-- = *temp--;
}
blocks alias-improvements branch (causes the store and
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-25 10:34 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-25 12:22 ---
On the branch I am installing the following as a stop-gap measure:
Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c (revision 142149)
--- Comment #11 from tehila at il dot ibm dot com 2008-11-25 12:17 ---
(In reply to comment #10)
If you only get slow compilation at -O2 and above then your problem is
probably
due to PR 37790. The original problem affected -O1 compiles as well as -O2.
PR 37790 doesn't solve the
--- Comment #4 from burnus at gcc dot gnu dot org 2008-11-25 12:53 ---
Subject: Bug 38248
Author: burnus
Date: Tue Nov 25 12:51:44 2008
New Revision: 142190
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142190
Log:
2008-11-25 Jan Kratochvil [EMAIL PROTECTED]
PR
Currently, there are only strange parenthesis-related error messages given if
an old, incompatible .mod file is used with a newer compiler, e.g.
Fatal Error: Reading module mmm at line 16 column 65: Expected left parenthesis
(cf. also PR 38248). The solution is to add a version number which is
--- Comment #18 from mikael at gcc dot gnu dot org 2008-11-25 13:28 ---
Subject: Bug 36463
Author: mikael
Date: Tue Nov 25 13:27:26 2008
New Revision: 142191
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142191
Log:
2008-11-25 Mikael Morin [EMAIL PROTECTED]
PR
--- Comment #12 from abel at gcc dot gnu dot org 2008-11-25 14:28 ---
I have somewhat cut the testcase, having the call with two ARG3's instead of
ten coming from ARG4. With this smaller testcase, I see that the most time is
taken by register renaming (cross to spu-elf, compiled with
--- Comment #6 from zhiyin at maths dot tcd dot ie 2008-11-25 14:51 ---
Fix in 4.3 much appreciated. Thank you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36410
Take:
#define vf4 __attribute__((vector_size(16) )) float
template class T inline T Abs( const T A )
{
return (A=(T)0) ? A : -A;
}
template inline vf4 Abs( const vf4 A) { }
-- CUT ---
If we change vf4 to be a typedef it works.
--
Summary: vector_size attribute vs
--- Comment #8 from hjl at gcc dot gnu dot org 2008-11-25 15:34 ---
Subject: Bug 37843
Author: hjl
Date: Tue Nov 25 15:33:27 2008
New Revision: 142193
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142193
Log:
gcc/
2008-11-25 H.J. Lu [EMAIL PROTECTED]
Joey Ye
The testcases gcc.dg/torture/ipa-pta-1.c and gcc.dg/tree-ssa/alias-2.c used to
work with -fpic/-fPIC on the trunk, but now fail. The alias-2.c testcase
worked in 4.2, 4.3 with -fpic/-fPIC also, and the testcase doesn't appear to
have changed. I think ipa-pta-1.c was added only on the trunk a few
As noted here:
http://gcc.gnu.org/ml/gcc/2008-11/msg00234.html
various components of GCC (xgcc, gcov, etc) are linking unnecessarily with
gmp/mpfr. I believe we only need to do that for executables linked against
libbackend.a (like cc1). The result is exposed when gmp/mpfr are shared
libraries
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
The testcase gcc.dg/ipa/ipacost-2.c fails with -fpic/-fPIC, and has been doing
so since it was added to the testsuite back in August.
August results:
http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg02784.html
Current results:
http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg02234.html
Is this
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-11-25 16:31 ---
IMHO a backport is not needed for error-recovery bugs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36410
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.4 regression]|[4.4 Regression]
|gcc.dg/torture/ipa-pta-1.c
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.4.0
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||missed-optimization
Target Milestone|---
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.4.0
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-11-25 16:34
---
So, this is fixed now?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-25 16:37 ---
Can you use ./contrib/gcc_update to update your gcc source tree
so that we can tell which revisions you are using? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38261
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org
|dot org
--- Comment #12 from ro at gcc dot gnu dot org 2008-11-25 17:08 ---
Fixed for 4.4.0. (Sorry for not updating the PR.)
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jason at redhat dot com 2008-11-25 17:35 ---
Subject: Re: [4.2/4.3 Regression] ICE with transparent union
rguenth at gcc dot gnu dot org wrote:
IMHO a backport is not needed for error-recovery bugs.
This is not an error-recovery bug, the patch makes us accept it.
tree_forwarder_block_p has
if (find_edge (ENTRY_BLOCK_PTR, bb))
return false;
without explanation. This test was added by you, Jeff - do you remember why?
Removing this check triggers some ICEs in the testsuite because remove_bb
(called from remove_forwarder_block) unconditionally moves
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-25 19:11 ---
Created an attachment (id=16767)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16767action=view)
patch
Patch that miscompares.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38264
When some STL containers are created, explicit constructors for contained
objects are treated as converting constructors. The keyword explicit is
ignored, and no error message is issued; see the code.
#include vector
#include deque
class X {
public:
explicit X(int) {}
};
When I try to compile code that include curses.h on IRIX, g++ chokes on the
fixed curses.h, producing errors like:
/appl/local_sde_dev/IRIX64-6.5/gcc-4.3.2/bin/../lib/gcc/mips-sgi-irix6.5/4.3.2/include-fixed/curses.h:1294:
error: declaration of C function 'int mvwprintw(WINDOW*, int, int, ...)'
--- Comment #1 from Jay dot St dot Pierre at Colorado dot EDU 2008-11-25
19:31 ---
Created an attachment (id=16768)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16768action=view)
Test file that includes curses.h
I compile this with g++ z.c -o z
--
The rtl epilogues are inserted after the USE which indicates where
the return value is. As a result, an instruction that calculates the
return value cannot be placed in the delay slot of the return
instruction. That is something that we did get right when we
had non-rtl epilogues - the
--- Comment #2 from Jay dot St dot Pierre at Colorado dot EDU 2008-11-25
19:34 ---
Created an attachment (id=16769)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16769action=view)
The fixed curses.h produced by the build of gcc-4.3.2
--
--- Comment #1 from cfairles at gcc dot gnu dot org 2008-11-25 19:34
---
GCC 4.4.0 also accepts this code as does Comeau 4.3.10.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
--- Comment #2 from paolo dot carlini at oracle dot com 2008-11-25 19:48
---
Unless I'm badly mistaken, this behaviour, dating back to the original HP/SGI
STL and as such very difficult to change now, is a small extension due to the
use in the containers of _Construct instead of
--- Comment #2 from law at redhat dot com 2008-11-25 20:04 ---
Subject: Re: New: tree_forwarder_block_p says no to
first basic block
rguenth at gcc dot gnu dot org wrote:
tree_forwarder_block_p has
if (find_edge (ENTRY_BLOCK_PTR, bb))
return false;
without explanation.
--- Comment #3 from alexandre dot nunes at gmail dot com 2008-11-25 20:01
---
Still fails as of gcc 4.3.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26850
Here is a patch from Dwarak for fixing this.
He will send this to review on gcc-patches@ list.
Sebastian Pop
--
AMD - GNU Tools
--- Makefile.in 2008-10-23 10:33:51.274495000 -0500
+++ Makefile.in.fix 2008-11-19 16:11:55.80298 -0600
@@ -903,8 +903,9 @@ BUILD_LIBDEPS=3D $(BUILD_LIBIBERTY)
--- Comment #1 from sebpop at gmail dot com 2008-11-25 20:25 ---
Subject: Re: New: [4.4 regression] GCC components unnecessarily link with
shared gmp/mpfr
Here is a patch from Dwarak for fixing this.
He will send this to review on gcc-patches@ list.
Sebastian Pop
--
AMD - GNU Tools
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-25 20:29 ---
Subject: Bug 37869
Author: rguenth
Date: Tue Nov 25 20:27:44 2008
New Revision: 142202
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142202
Log:
2008-11-25 Richard Guenther [EMAIL PROTECTED]
*
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-11-25 21:23 ---
Testcase from comment #1 has wrong points-to sets on the trunk as well (-O).
end = NONLOCAL
temp_4 = end
end_7 = end_1
temp_8 = temp_2
end_1 = end
end_1 = end_7
temp_2 = temp_4
temp_2 = temp_8
...
end_7 is a
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-11-25 21:45 ---
Simpler testcase:
void
foo (unsigned long *end)
{
unsigned long *temp = end - 1;
while (1)
*end-- = *temp;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37869
tchaikovski:[/usr/shared-apps/lib/gcc] gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../configure --prefix=/usr/shared-apps
--enable-languages=c,c++,fortran --enable-shared --enable-threads=solaris
--enable-nls --enable-checking=release --with-mpfr=/usr/shared-apps/
Save the attachments (pin.c and ntoskrnl.h) to the same directory. Then run the
following commands:
gcc -o ntoskrnl.h.gch -I. -fno-unit-at-a-time -Os ntoskrnl.h
gcc -v -o pin.o -I. -fno-unit-at-a-time -Os -c pin.c
The latter will print the following:
Using built-in specs.
Target: mingw32
--- Comment #1 from hackbunny at reactos dot com 2008-11-25 21:56 ---
Created an attachment (id=16770)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16770action=view)
test case (1 of 2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38269
--- Comment #2 from hackbunny at reactos dot com 2008-11-25 21:56 ---
Created an attachment (id=16771)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16771action=view)
test case (2 of 2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38269
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-11-25 22:04 ---
4.1.3 is old and no longer being maintained. So can you try 4.2.3 or better
yet 4.3.2?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from hackbunny at reactos dot com 2008-11-25 22:12 ---
Yes and no, we are resisting upgrading due to PR 31707 (which we are attempting
to workaround, and the workaround led to this bug...). I will try ASAP anyway
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38269
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-11-25 22:38 ---
Then do not use PCH. Seriously, this is not going to be fixed unless you
provide a patch ;) Rather I hope we will end up removing the current PCH
implementation.
--
--- Comment #7 from olsner at gmail dot com 2008-11-25 23:02 ---
Original test case and test case from comment #1 both give this result (i.e. no
ICE) for me:
(Comment #1)
stdin: In function void foo():
stdin:4: error: can't find class$ in __java_boolean
(Original test case)
--- Comment #2 from ghazi at gcc dot gnu dot org 2008-11-25 23:08 ---
(In reply to comment #1)
Subject: Re: New: [4.4 regression] GCC components unnecessarily link with
shared gmp/mpfr
Here is a patch from Dwarak for fixing this.
He will send this to review on gcc-patches@ list.
--- Comment #8 from olsner at gmail dot com 2008-11-25 23:24 ---
So, all issues mentioned in this bug are fixed, and related issues all have
their own bugs? I think we should just close this one and ping/reconfirm/close
bug 18244...
--
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-11-25 23:40 ---
This only ICEs now with checking turned on:
t.cc: In function 'void foo()':
t.cc:28: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have integer_type in
Libgomp test libgomp.c/atomic-3.c started failing with wrong answers on power5
and power6 systems for -m32, and tests nqueens-1.c and sort-1.c started hanging
intermittently for both -m32 and -m64 on those systems, with the addition of
r139969, which removes the memory barrier from
--- Comment #6 from d dot g dot gorbachev at gmail dot com 2008-11-26
00:00 ---
GCC 4.3.2 failed to compile the testcase with internal compiler error: in
copy_phis_for_bb, at tree-inline.c:1227 or internal compiler error: in
gimplify_expr, at gimplify.c:6146 message.
GCC 4.4.0 works.
--- Comment #8 from kkojima at gcc dot gnu dot org 2008-11-26 00:03 ---
Vlad, thanks for taking the time to look into this! Your comments
in #7 and http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01323.html
give a very clear picture of the problem.
--
--- Comment #9 from d dot g dot gorbachev at gmail dot com 2008-11-26
00:14 ---
GCC 4.3.2 and 4.4.0 compile the above testcase without warnings.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
gcc -S -O1 -Wuninitialized uninitialized.c
GCC 4.4.0 20081121:
warning: 's' is used uninitialized in this function
GCC 4.3.2:
warning: âiâ may be used uninitialized in this function
--
Summary: Spurious / missing ... used uninitialized in this
function
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2008-11-26
02:48 ---
Created an attachment (id=16772)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16772action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38271
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-11-26 02:54 ---
What the *#$^*(#^$*(:
SR.3_5 = p_1(D)-c;
SR.4_6 = VIEW_CONVERT_EXPRlong long unsigned int(*p_1(D));
SR.4_7 = SR.4_6 4294967295;
SR.5_8 = (unsigned int) SR.4_7;
s.0.c ={v} SR.3_5;
SR.6_10 =
--- Comment #17 from jason at gcc dot gnu dot org 2008-11-26 03:53 ---
Subject: Bug 28743
Author: jason
Date: Wed Nov 26 03:51:40 2008
New Revision: 142212
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142212
Log:
PR c++/28743
* decl2.c (check_classfn): Error
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-11-26 03:53
---
I have been given access to a mchine with this architecture and have not, after
several evenings at it, been able to complete a single build of gfortran. I
notice some instructions on the gcc web page about some
On Linux/ia32, revision 142207 caused
FAIL: libgomp.fortran/threadprivate2.f90 -O1 execution test
--
Summary: [4.4 Regression] Revision 142207 caused
libgomp.fortran/threadprivate2.f90
Product: gcc
Version: 4.4.0
Status:
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-11-26 03:59
---
Un assigning myself since I think Janne is working on this and I would hate to
duplicate effort. If I need to pick back up on this, let me know.
--
jvdelisle at gcc dot gnu dot org changed:
What
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2008-11-26 04:05
---
Not a gfortran frontend issue, so closing.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2008-11-26
04:25 ---
On i686-apple-darwin9, we are failing...
FAIL: gcc.target/i386/pr37843-1.c scan-assembler call[\\t ]*foo
FAIL: gcc.target/i386/pr37843-2.c scan-assembler jmp[\\t ]*foo
at revision 142207.
--
/fink.build/gcc44-4.3.999-20081125/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.3.999-20081125/darwin_objdir/gcc/
/sw/src/fink.build/gcc44-4.3.999-20081125/gcc-4.4-20081125/gcc/testsuite/gcc.target/i386/pr37843-1.c
-O2 -mpreferred-stack-boundary=6 -mincoming-stack-boundary=5 -S -m32 -o
pr37843-1.s
/fink.build/gcc44-4.3.999-20081125/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.3.999-20081125/darwin_objdir/gcc/
/sw/src/fink.build/gcc44-4.3.999-20081125/gcc-4.4-20081125/gcc/testsuite/gcc.target/i386/pr37843-2.c
-O2 -mpreferred-stack-boundary=6 -mincoming-stack-boundary=6 -S -m32 -o
pr37843-2.s
--- Comment #12 from hjl dot tools at gmail dot com 2008-11-26 05:38
---
I don't think sibcall work on Darwin. Can you skip them on Darwin?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37843
--- Comment #2 from mt1 at systella dot fr 2008-11-26 07:17 ---
(In reply to comment #1)
I have been given access to a mchine with this architecture and have not,
after
several evenings at it, been able to complete a single build of gfortran. I
notice some instructions on the gcc
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-11-26 07:48
---
I have been given access to a mchine with this architecture and have not,
after several evenings at it, been able to complete a single build of
gfortran.
Weird, folks generally can build it flawlessly, see
79 matches
Mail list logo
