--- Comment #1 from raeburn at raeburn dot org 2009-07-03 06:45 ---
(In reply to comment #0)
> , but it does not seem to recognize that the following is also a valid
> prototype:
>
> int count * ( demo_counter * self, int count_amt );
It isn't.
> Following the traditional "right-then-
--- Comment #9 from burnus at gcc dot gnu dot org 2009-07-03 06:40 ---
(In reply to comment #8)
> Please try with a newer version of gfortran. Literally, hundreds of
> bugs and changes have occurred since version 4.3.0 was released.
> I believe this bug is a duplicate of
> http://gcc.g
The gcc C compiler doesn't seem to be following the traditional
"right-then-left" rule when compiling function pointer prototypes.
For example, gcc properly considers this to be a valid prototype:
int (*count)( demo_counter * self, int count_amt );
, but it does not seem to recognize that the fo
--- Comment #18 from amodra at bigpond dot net dot au 2009-07-03 01:38
---
I wonder whether people reporting that this bug has not been fixed (at least
for C/C++) realize that the fix needs to be in the sources you are building.
It's not a fix that affects the installed compiler.
I've
--- Comment #7 from paolo dot carlini at oracle dot com 2009-07-03 00:38
---
I see, thanks Manuel for the feedback, I'll give it some thought.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #7 from lennart dot borgman at gmail dot com 2009-07-03 00:35
---
I think I found an answer to my last question here:
http://www.mingw.org/wiki/IncludePathHOWTO
Now I only need to understand how to parse that output...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #6 from manu at gcc dot gnu dot org 2009-07-03 00:25 ---
(In reply to comment #5)
> Manuel, pardon the naive question: are we getting closer to fixing this? I'm
> asking because I saw patches about column numbers and wondered if that really
> means that very soon we'll be abl
--- Comment #5 from paolo dot carlini at oracle dot com 2009-07-02 23:55
---
Manuel, pardon the naive question: are we getting closer to fixing this? I'm
asking because I saw patches about column numbers and wondered if that really
means that very soon we'll be able to just print a care
--- Comment #4 from manu at gcc dot gnu dot org 2009-07-02 23:49 ---
*** Bug 40228 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from manu at gcc dot gnu dot org 2009-07-02 23:49 ---
This seems the exact definition of caret diagnostics.
*** This bug has been marked as a duplicate of 24985 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from manu at gcc dot gnu dot org 2009-07-02 23:41 ---
We can add an option Wunused-result that controls the warnings.
Wno-unused-result and -Werror=unused-result will then work as expected.
Index: gcc/c-common.c
--- Comment #8 from kargl at gcc dot gnu dot org 2009-07-02 23:17 ---
(In reply to comment #7)
> Although this program compiled OK under g77 it failed under gfortran.
>
Please attach a tarball with all the files need to reproduce the failure,
or us to a URL where we can get the origina
--- Comment #7 from rogermc at iinet dot net dot au 2009-07-02 22:58
---
Although this program compiled OK under g77 it failed under gfortran.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40612
--- Comment #4 from dj at redhat dot com 2009-07-02 21:43 ---
Created an attachment (id=18132)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18132&action=view)
dump just after rnreg
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
--- Comment #3 from dj at redhat dot com 2009-07-02 21:42 ---
Created an attachment (id=18131)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18131&action=view)
dump just before rnreg
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
--- Comment #2 from dj at redhat dot com 2009-07-02 21:42 ---
Created an attachment (id=18130)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18130&action=view)
resulting .s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
--- Comment #1 from dj at redhat dot com 2009-07-02 21:41 ---
Created an attachment (id=18129)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18129&action=view)
test case for the above
Compile with:
./cc1 -quiet -mivc2 dj.c -O2 -o dj.s -frename-registers
--
http://gcc.gnu.org
When compiled with -frename-registers, the TBA test case produces invalid
code. Specifically, the cpadd4.h opcode clobbers $c1 but the cpsub2.h
assumes it still has the value "a" in it. Compiling with
-fno-rename-registers results in valid code.
--
Summary: -frename-registers causes
--- Comment #9 from paolo dot carlini at oracle dot com 2009-07-02 20:47
---
Yes, is not fixed in 4.3.3. Is already fixed for 4.3.4, etc.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
--- Comment #8 from galtgendo at o2 dot pl 2009-07-02 20:42 ---
Though perhaps I didn't need to reopen.
Just making sure: could you reproduce it with one of
the mentioned versions ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40623
--- Comment #7 from galtgendo at o2 dot pl 2009-07-02 20:37 ---
Created an attachment (id=18128)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18128&action=view)
this is the incorrect one
...with 'printf' and 'x0*y1-x1*y0'
Both with '-O2' (though -0 is enough).
--
http://gcc.
--- Comment #6 from galtgendo at o2 dot pl 2009-07-02 20:35 ---
Created an attachment (id=18127)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18127&action=view)
this is correct assembly
...when 'printf' and '(x0*(y0+dy) - (x0+dx)*y0)'
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #5 from galtgendo at o2 dot pl 2009-07-02 20:33 ---
It definitely doesn't work in 4.3.3.
I'll attach generated assembly.
--
galtgendo at o2 dot pl changed:
What|Removed |Added
--- Comment #1 from tjruwase at google dot com 2009-07-02 18:48 ---
Created an attachment (id=18126)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18126&action=view)
Proposed Patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40625
On x86_64-unknown-linux-gnu, revision 149190:
make -k check-gcc RUNTESTFLAGS="plugin.exp" results in
Running gcc-4.4.0/src/gcc/testsuite/gcc.dg/plugin/plugin.exp ...
ERROR: tcl error sourcing gcc-4.4.0/src/gcc/testsuite/gcc.dg/plugin/plugin.exp.
ERROR: can't read "ld_library_path": no such var
--- Comment #6 from lennart dot borgman at gmail dot com 2009-07-02 18:34
---
Thanks, I see. How can one then figure out the include path that a user has?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40624
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-07-02 18:32 ---
Because the FSF does not supply the binaries you are using so it is not a bug
with GCC rather than the way it was configured. when configuring with
--prefix=/mingw, it have to mean C:/mingw. Also GCC binaries are r
--- Comment #4 from lennart dot borgman at gmail dot com 2009-07-02 18:31
---
Ah, sorry, I did not see your comment. Could you advice how the MinGW team
should configure the compilation?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40624
--- Comment #3 from lennart dot borgman at gmail dot com 2009-07-02 18:29
---
pinskia, please explain why you marked this bug as invalid!
--
lennart dot borgman at gmail dot com changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-07-02 18:27 ---
Since the output of gcc -v depends on how GCC was configured, this is not a bug
with GCC and really a bug with the way mingw's gcc was configured.
--
pinskia at gcc dot gnu dot org changed:
What|R
--- Comment #4 from paolo dot carlini at oracle dot com 2009-07-02 18:26
---
Can't reproduce in any active branch, thus already fixed for 4.5.0, 4.4.1,
4.3.4 (maybe 4.3.3 too).
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #1 from lennart dot borgman at gmail dot com 2009-07-02 18:16
---
Hm, something went wrong when sending the bug report. It should have said
When doing
gcc -v
the resulting prefix for me is
--prefix=/mingw
On w32 ... (the rest is correct)
--
lennart dot borgman a
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-07-02 18:15
---
Complete.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status|N
--- Comment #5 from ghazi at gcc dot gnu dot org 2009-07-02 18:14 ---
Make sure to re-enable the commented out tests in
gfortran.dg/integer_exponentiation_4.f90. See:
http://gcc.gnu.org/ml/fortran/2009-06/msg00288.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
This is for gcc on w32 (windows). I have downloaded the MinGW installer and
installed gcc from that.
When doing
gcc -v
the resulting prefix for me is
On w32 this should include the drive letter otherwise it is totally useless. So
it should be
--prefix=c:/mingw
I also wonder if this is the
--- Comment #3 from galtgendo at o2 dot pl 2009-07-02 18:08 ---
Created an attachment (id=18125)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18125&action=view)
data for the test
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40623
--- Comment #7 from rth at gcc dot gnu dot org 2009-07-02 18:05 ---
*** Bug 40620 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40462
--- Comment #2 from rth at gcc dot gnu dot org 2009-07-02 18:05 ---
*** This bug has been marked as a duplicate of 40462 ***
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from galtgendo at o2 dot pl 2009-07-02 18:05 ---
Due to that 'printf' thing, it seems vaguely similar
to bug 39333, however here neither of the switches mentioned there
has an effect.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40623
--- Comment #1 from galtgendo at o2 dot pl 2009-07-02 18:02 ---
Created an attachment (id=18124)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18124&action=view)
a testcase for the bug
As I said in the Gentoo bug,
one version of the 'area' line produces correct result,
other does
I'm in doubt about exact compiler info,
cause I want to report a bug from Gentoo bugzilla,
where reporter was using 4.3.2, but I could reproduce it
with 4.4.0.
We're both on x86.
It's http://bugs.gentoo.org/show_bug.cgi?id=276146.
A rather simple code fragment gets miscompiled,
but after making a
--- Comment #4 from hunterggl at gmail dot com 2009-07-02 17:46 ---
(In reply to comment #3)
> For both mulscale and divscale you have ecx as an input register but nothing
> marks it as being modified so GCC does not know that. It does not read the
> template string to figure out what y
--- Comment #2 from ycollet at freesurf dot fr 2009-07-02 17:39 ---
It should be relatively easy to make configure emit an error when it can't find
flex. I have lost a couple of hours before figuring out that flex was missing.
YC
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40618
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-07-02 16:51 ---
For both mulscale and divscale you have ecx as an input register but nothing
marks it as being modified so GCC does not know that. It does not read the
template string to figure out what you had meant to say.
--
--- Comment #17 from bergner at gcc dot gnu dot org 2009-07-02 16:48
---
Alan, do you have any ideas?
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from joel at gcc dot gnu dot org 2009-07-02 16:44 ---
*** Bug 40622 has been marked as a duplicate of this bug. ***
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from joel at gcc dot gnu dot org 2009-07-02 16:44 ---
*** This bug has been marked as a duplicate of 40462 ***
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
/home/joel/test-gcc/b-gcc1-sparc/./gcc/xgcc
-B/home/joel/test-gcc/b-gcc1-sparc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/ -isystem
/home/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/targ-include -isystem
/home/joel/test-gcc/gcc-svn/newlib/libc/include
-B/home/j
--- Comment #5 from joel at gcc dot gnu dot org 2009-07-02 16:44 ---
/home/joel/test-gcc/b-gcc1-sparc/./gcc/xgcc
-B/home/joel/test-gcc/b-gcc1-sparc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/ -isystem
/home/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib
--- Comment #2 from hunterggl at gmail dot com 2009-07-02 16:39 ---
Created an attachment (id=18123)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18123&action=view)
Comparison of asm
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40621
--- Comment #1 from hunterggl at gmail dot com 2009-07-02 16:38 ---
Created an attachment (id=18122)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18122&action=view)
Test file
This a small fragment of code that causes problems
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-02 16:37
---
debug/40462?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40620
--- Comment #16 from lucier at math dot purdue dot edu 2009-07-02 16:35
---
OK, so we've had several reliable reports that this bug still exists, but I'm
not high enough in the GCC bugzilla hierarchy to reopen this bug (I just
tried), perhaps Andreas or Jakub would like to do so. (Jak
GCC doesn't produce the correct assembler code when I use optimizations.
[code]
#include
#define mulscale(a,d,c) \
({ int __a=(a), __d=(d), __c=(c); \
__asm__ __volatile__ ("imull %%edx; shrdl %%cl, %%edx, %%eax" \
: "=a" (__a), "=d" (__d) \
: "a" (__a), "d" (__d), "c"
/home/joel/test-gcc/b-gcc1-sparc/./gcc/xgcc
-B/home/joel/test-gcc/b-gcc1-sparc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/ -isystem
/home/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/targ-include -isystem
/home/joel/test-gcc/gcc-svn/newlib/libc/include
-B/home/j
--- Comment #15 from jan at codejunky dot org 2009-07-02 16:26 ---
Same problem here on powerpc-32:
powerpc-unknown-linux-gnu-gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat -Wm
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-07-02 15:50
---
Subject: Bug 40617
Author: rguenth
Date: Thu Jul 2 15:50:26 2009
New Revision: 149179
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149179
Log:
2009-07-02 Richard Guenther
PR bootstrap/40617
--- Comment #7 from rguenther at suse dot de 2009-07-02 15:46 ---
Subject: Re: Pointer does not really escape
with write
On Thu, 2 Jul 2009, steven at gcc dot gnu dot org wrote:
> --- Comment #6 from steven at gcc dot gnu dot org 2009-07-02 15:40
> ---
> Dan, you mentioned
--- Comment #6 from steven at gcc dot gnu dot org 2009-07-02 15:40 ---
Dan, you mentioned a "pointer_no_escape" attribute. What was that about? I've
never seen that mentioned before (or a patch to implement it). Sounds like a
cool attribute to have (and not just for Fortran, too).
-
--- Comment #11 from matz at gcc dot gnu dot org 2009-07-02 15:31 ---
Subject: Bug 32131
Author: matz
Date: Thu Jul 2 15:31:28 2009
New Revision: 149178
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149178
Log:
fortran/
PR fortran/32131
* trans-array.c (gfc_con
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-02 15:29 ---
flex is only required to build svn checkouts or snapshots. Release tarballs
contain the generated files.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from jsm28 at gcc dot gnu dot org 2009-07-02 15:17 ---
If you are building an i686-pc-linux-gnu compiler you should start by
building i686-pc-linux-gnu binutils (configured --enable-64-bit-bfd)
and installing them in the same prefix in which you are going to install
GCC (
--- Comment #9 from steven at gcc dot gnu dot org 2009-07-02 15:12 ---
Note I have various working patches for GVN-based hoisting. All of them are
actually too aggressive, causing failures in the vectorizer test cases
(unrecognizable data dependency patterns). But I still intend to pos
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-02 15:07 ---
Restricting can be done via casting to volatile - then it is only
*(volatile int *)&i
That needs then to be applies in all expressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30733
--- Comment #8 from aldot at gcc dot gnu dot org 2009-07-02 15:05 ---
Important reminder from steven from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33828#c13
stevenb> GCC should not hoist up further than up to the first common dominator.
i.e. "..can be Hoisted to B" from #3
and _not_
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-02 15:01 ---
Ok, i have an idea.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-02 14:59
---
Jason, can you have a look to this one? Thanks in advance!
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-07-02 14:55 ---
Hmm, building genmodes.o with -save-temps makes the segfault go away...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40617
--- Comment #7 from heydowns at borg dot com 2009-07-02 14:46 ---
Created an attachment (id=18121)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18121&action=view)
Proposed fix: Changes linking on solaris based on std=X and implements escapes
in braced specs
Attaching a fix that w
--- Comment #10 from burnus at gcc dot gnu dot org 2009-07-02 14:44 ---
Michael Matz fixed that for allocatable arrays, but the patch needs to be
extended to nonallocatable arrays, cf.
http://gcc.gnu.org/ml/fortran/2009-07/msg4.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
template struct X {};
template auto f(T t) -> X {}
template auto g(T t) -> X {}
Compiling with -std=c++0x gives
decltype_ice.cc:4:52: internal compiler error: Segmentation fault: 11
--
Summary: [c++0x] ICE on repeated decltype expression in auto
functions
--- Comment #7 from hjl dot tools at gmail dot com 2009-07-02 14:36 ---
(In reply to comment #6)
> Ok, I see it with stage3 only :(
>
> build/genmodes > tmp-modes.c
> /bin/sh: line 1: 16996 Segmentation fault build/genmodes > tmp-modes.c
> make[3]: *** [s-modes] Error 139
> make[3]
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-07-02 14:31 ---
Ok, I see it with stage3 only :(
build/genmodes > tmp-modes.c
/bin/sh: line 1: 16996 Segmentation fault build/genmodes > tmp-modes.c
make[3]: *** [s-modes] Error 139
make[3]: *** Waiting for unfinished jobs
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-02 14:24 ---
Thus, please somebody attach genmodes.i that is miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40617
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-07-02 14:16 ---
Hm, I'm into stage2 and genmodes was already built and executed fine - so,
I don't seem to be able to reproduce it right now.
How did you configure? I did
/space/rguenther/tramp3d/trunk/configure --enable-language
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-02 13:56 ---
Ok, I'm trying to reproduce and get genmodes.i.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40617
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
Version|4.4.0 |4.5.0
http://
--- Comment #9 from marek dot rouchal at infineon dot com 2009-07-02 13:52
---
(In reply to comment #8)
> For a 32-bit-default compiler that can also build 64-bit code, configure
> for i686-pc-linux-gnu with --enable-targets=all. (Set CC="gcc -m32"
> and CC_FOR_BUILD="gcc -m32" in your
--- Comment #2 from hjl dot tools at gmail dot com 2009-07-02 13:51 ---
(In reply to comment #1)
> For 4.5 you mean?
>
Yes. Only on Linux/ia32. Linux/x86-64 passed that failure
point.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-02 13:46 ---
For 4.5 you mean?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Versio
when flex is not installed, configure detects that flex is not installed but
doesn't emit an error.
Flex is required to build gcc-4.5 (to produce gengtype-lex.c).
So, if no flex, no gcc :-)
YC
--
Summary: when flex is not installed, gcc build stop because of a
non
Revision 149170:
http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00046.html
breaks bootstrap on Linux/ia32:
/export/gnu/import/svn/gcc-test/bld/./prev-gcc/xgcc
-B/export/gnu/import/svn/gcc-test/bld/./prev-gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/bin/
-B/usr/local/i686-pc-
--- Comment #5 from burnus at gcc dot gnu dot org 2009-07-02 12:36 ---
> > call output (p1, p2, p3, p4)
> > That still clobbers p1, p2, p3, and p4 as they are passed by reference so
> > is it really undefined code if output changes the values for the do loop?
> Yes.
Conf
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot
|dot org
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-02 12:17 ---
Fixed on the branches.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known t
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-07-02 12:16 ---
Subject: Bug 40585
Author: rguenth
Date: Thu Jul 2 12:16:39 2009
New Revision: 149173
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149173
Log:
2009-07-02 Richard Guenther
PR middle-end/40585
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-07-02 12:16 ---
Subject: Bug 40585
Author: rguenth
Date: Thu Jul 2 12:15:27 2009
New Revision: 149172
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149172
Log:
2009-07-02 Richard Guenther
PR middle-end/40585
--- Comment #8 from jsm28 at gcc dot gnu dot org 2009-07-02 11:57 ---
For a 32-bit-default compiler that can also build 64-bit code, configure
for i686-pc-linux-gnu with --enable-targets=all. (Set CC="gcc -m32"
and CC_FOR_BUILD="gcc -m32" in your environment and configure
--enable-targe
--- Comment #3 from paolo dot carlini at oracle dot com 2009-07-02 11:40
---
Apparently, HJ can't reproduce it either:
http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg00122.html
--
paolo dot carlini at oracle dot com changed:
What|Removed |Add
--- Comment #7 from marek dot rouchal at infineon dot com 2009-07-02 11:46
---
(In reply to comment #5)
> What you want is --with-cpu=default32 for x86_64 which does not exist yet. It
> does for powerpc64 though.
I'd like to ping this request once again - it seems that there was no pr
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-02 11:37 ---
Jakub should maybe know more ;)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-02 11:33 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40613
--- Comment #5 from jakub at gcc dot gnu dot org 2009-07-02 11:30 ---
Fix posted: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00091.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from tsyvarev at ispras dot ru 2009-07-02 11:26 ---
Ok, sorry for noise. I'll try with libunwind.
Only thing - what does it mean
> invalid testcase because you make libunwind fail by setrlimit.
Does it mean that setrlimit shouldn't be used with new operator? or with
ex
There are some new 1.5 PrintStream constructors that are in GNU Classpath but
not in the local gcj version of the same file. This causes the OpenJDK7 b62
build to fail:
/mnt/builder/icedtea/bootstrap/jdk1.6.0/bin/javac -J-XX:ThreadStackSize=1536
-J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOpt
--- Comment #13 from hubicka at ucw dot cz 2009-07-02 10:10 ---
Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852
OK, on i386 it has some effect according to our nightly tester
it is 3524421->3510754. The size used to be as low as 3431090
so it is just small im
--- Comment #10 from paolo dot carlini at oracle dot com 2009-07-02 10:08
---
Thanks Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-02 10:07
---
Today, with 149169, I can't reproduce this problem. By the way, I suspect an
ICE or something similar was happening, definitely wrong categorization.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40613
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-02 10:05 ---
I can reproduce it, the abort is from the system libunwind:
(gdb) run
Starting program: /tmp/a.out
Executing test_4_10()
#0 0xa0010721 in __kernel_syscall_via_break ()
#1 0x20422940 in *__GI_rais
1 - 100 of 107 matches
Mail list logo
