--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-04-27
06:03 ---
Changed summary to be more precise about non-standard.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #3 from kendallc at vxitech dot com 2008-04-27 07:32 ---
The issue was the uClibc makefiles having -Wa,--bitwise-or as a default
config option. This causes binutils to not treat | as a comment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36049
--- Comment #1 from burnus at gcc dot gnu dot org 2008-04-27 08:01 ---
gfortran's rejection is in line with g95, NAG f95, ifort, openf95, sunf95 and
ifort.
I think gfortran is right and the sequence (or bind(C)) attribute is needed.
The reason is the same as for the following program:
See thread at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e9add97708681397
Full example, reported by James Van Buskirk, see
http://groups.google.com/group/comp.lang.fortran/msg/9c42edc4620a1cff
Using -frepack-arrays, the dummy array x is repacked in the function. This
--- Comment #3 from dimhen at gmail dot com 2008-04-27 10:26 ---
trunk rev.#134722 has no bug
--
dimhen at gmail dot com changed:
What|Removed |Added
On the attached testcase on powerpc64-linux (native, 64-bit cc1plus)
compiling with -O2 -g -w -m64 -mminimal-toc -fPIC results in ICE during garbage
collection. I've tracked that to excessively deep backtrace when marking
dwarf2 debug info, above 94000 calls in the backtrace, out of this
80462
Environment:
System: Linux darksky.homeunix.net 2.6.22.9-THUNDERBIRD_31-Shadowfax #3 Tue Oct
2 00:48:34 EEST 2007 i686 athlon-4 i386 GNU/Linux
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../gcc-3.4.3/configure --prefix=/usr
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #1 from jakub at gcc dot gnu dot org 2008-04-27 11:00 ---
Created an attachment (id=15534)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15534action=view)
1.ii.bz2
Preprocessed file from openvrml.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36060
--- Comment #2 from jakub at gcc dot gnu dot org 2008-04-27 11:06 ---
As most of the nested calls are due to following die_sib, out of the first
almost 46000 frames I've uped, there were:
20273 gt_ggc_m_10die_struct ((*x).die_sib);
8878 gt_ggc_m_19VEC_dw_attr_node_gc ((*x).die_attr);
--- Comment #1 from gabrielcvdj at yahoo dot com 2008-04-27 11:08 ---
Created an attachment (id=15535)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15535action=view)
The preprocessed file that triggers the bug, generated by adding -save-temps
I didn't considered necessary to add
--- Comment #2 from gabrielcvdj at yahoo dot com 2008-04-27 11:21 ---
This bug seems to be similar to:
GCC Bugzilla Bug 14452
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36061
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-04-27 12:32
---
Fixing.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-04-27 13:06 ---
3.4.6 works for me.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-04-27 13:08 ---
Similar to PR35204 shouldn't we simply lift soft stack limits at the start of
gcc?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36060
--- Comment #2 from w6ws at earthlink dot net 2008-04-27 13:24 ---
Subject: Re: Not allowing pointers to derived types in
COMMON
burnus at gcc dot gnu dot org wrote:
--- Comment #1 from burnus at gcc dot gnu dot org 2008-04-27 08:01
---
gfortran's rejection is in line
--- Comment #4 from jakub at gcc dot gnu dot org 2008-04-27 13:33 ---
You can't always do that, sometimes the stack limit is a hard limit.
Additionally, often on Linux setrlimit RLIMIT_STACK after exec is already
too late (as in topdown memory layout things are often mapped already
--- Comment #4 from gabrielcvdj at yahoo dot com 2008-04-27 14:43 ---
I inially thought this problem was solved earlier in the 3.4.x series. I've
seen this bug mentioned several times for the 3.4.x series.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36061
--- Comment #3 from burnus at gcc dot gnu dot org 2008-04-27 15:30 ---
See also:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/773de8d5b57f8e20
(In reply to comment #2)
I am only concerned with the POINTER case. I am not placing a
derived type object in the
The recently added options -mpc32, -mpc64, and -mpc80 are not documented
properly.
These are claimed to be i386 and amd64 only option. In fact, these options are
i386, amd64, and *linux only* options. These options do not work on any other
target.
--
Summary: -mpc32,-mpc64, and
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-04-27 16:27 ---
Subject: Bug 34223
Author: rguenth
Date: Sun Apr 27 16:27:08 2008
New Revision: 134730
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134730
Log:
2008-04-27 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-04-27 16:27
---
Subject: Bug 18754
Author: rguenth
Date: Sun Apr 27 16:27:08 2008
New Revision: 134730
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134730
Log:
2008-04-27 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-04-27 17:16 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #21 from rguenth at gcc dot gnu dot org 2008-04-27 17:16
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from danglin at gcc dot gnu dot org 2008-04-27 17:17 ---
The test pr35729.c also fails on hppa-unknown-linux-gnu.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-04-27 17:21 ---
Which is also the reason for early unrolling not helping. But at -O3 the
tree loop optimizer unrolls the loop after LIM/PRE fixed the size estimate.
But it's too late to clean up at this point (no strong memory
--- Comment #5 from danglin at gcc dot gnu dot org 2008-04-27 18:01 ---
I first saw this in 133010.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
--- Comment #1 from ubizjak at gmail dot com 2008-04-27 18:05 ---
No, these options are also working well on darwin. Other OSes need to update
their ENDFILE_SPEC entry and their config.gcc entry.
Sorry, I'm not able to test this on other systems than x86-*-linux, so it is up
to OS
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-04-27 18:43
---
I think compiling with -fbacktrace and calling the STOP intrinsic should emit a
backtrace. Maybe not enough, but still useful.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
The following code:
program spacing_bug
implicit none
real, parameter :: x1 = 3.14159265358979
integer, parameter :: ulps1 = 2
real, parameter :: y1 = ulps1*spacing(x1) ! Only f03
real, parameter :: y2 = rrspacing(x1) ! Only f03
real, parameter :: y3 = scale(x1,ulps1) ! Only f03
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-04-27 18:48
---
I'll start giving it a look, to see whether it's a Fortran front-end issue or a
more generic win64 issue.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
When the attached example is compiled by the
gcc version 4.4.0 20080426 (experimental) (GCC)
using
gcc -O1 -march=nocona -m32 -c vorbisfile.c.c -o vorbisfile.o
it produces the following error:
vorbisfile.c: In function 'ov_time_seek_page':
--- Comment #1 from drab at kepler dot fjfi dot cvut dot cz 2008-04-27
18:55 ---
Created an attachment (id=15536)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15536action=view)
Example that triggers the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36064
# libtool --version |head -n1
ltmain.sh (GNU libtool) 2.2.2
# make
[...]
make[5]: Entering directory
`/build-gcc-i586/BUILD/gcc-4.3.1/build/i586-ark-linux/libjava/classpath/native/fdlibm'
if /bin/sh ../../libtool --tag=CC --mode=compile
/build-gcc-i586/BUILD/gcc-4.3.1/build/./gcc/xgcc
--- Comment #2 from kargl at gcc dot gnu dot org 2008-04-27 20:39 ---
(In reply to comment #1)
No, these options are also working well on darwin. Other OSes need to update
their ENDFILE_SPEC entry and their config.gcc entry.
Then document the platforms on which these options work.
The attached example, when compiled with
gcc version 4.4.0 20080426 (experimental) (GCC)
using
-
gcc -O1 -finline-small-functions -ftree-vrp -funsafe-loop-optimizations -c
stream_encoder.c.c -o stream_encoder.o
-
produces the following ICE.
-
stream_encoder.c: In
--- Comment #1 from martin dot drab at fjfi dot cvut dot cz 2008-04-27
20:58 ---
Created an attachment (id=15537)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15537action=view)
Example that triggers the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36066
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-27 21:11 ---
Confirmed.
Program received signal SIGSEGV, Segmentation fault.
0x0829ba29 in operand_equal_p (arg0=0xb7b248f0, arg1=0xb7c6fd68, flags=0)
at /home/richard/src/trunk/gcc/fold-const.c:3037
3037 if
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-04-27 21:31 ---
Created an attachment (id=15538)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15538action=view)
somehwat reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36066
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|ICE with -O1
--- Comment #4 from martin dot drab at fjfi dot cvut dot cz 2008-04-27
21:43 ---
The test cases also fail with
-O1 -finline-small-functions -ftree-vrp -fprefetch-loop-arrays
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36066
--- Comment #16 from gnu_andrew at member dot fsf dot org 2008-04-27 22:01
---
Created an attachment (id=15539)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15539action=view)
Fix substring bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
--- Comment #2 from manu at gcc dot gnu dot org 2008-04-27 22:13 ---
*** Bug 36050 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from manu at gcc dot gnu dot org 2008-04-27 22:13 ---
*** This bug has been marked as a duplicate of 25733 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from martin dot drab at fjfi dot cvut dot cz 2008-04-27
22:54 ---
And the test cases also fail with
-O1 -finline-small-functions -ftree-vrp -m32
so if you compile it for 32-bit target, naither the -funsafe-loop-optimizations
nor the -fprefetch-loop-arrays needs to
On Linux/ia32 and Linux/Intel64, I got
Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/tls/section-2.c-ansi
-pedantic-errors -fno-show-column -S -m32 -o section-2.s(timeout =
I got
Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/vect/vect-118.c -O3
-fdump-tree-vect-details -fno-show-column -lm -m32 -o ./vect-118.exe
(timeout = 300)
PASS:
--- Comment #6 from hutchinsonandy at aim dot com 2008-04-28 00:58 ---
Created an attachment (id=15540)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15540action=view)
Partial solution using DF defs.
--
hutchinsonandy at aim dot com changed:
What|Removed
--- Comment #7 from hutchinsonandy at aim dot com 2008-04-28 00:59 ---
Attached is INCOMPLETE attempt to fix this issue.
Register saves appear to be ok. But same function is required for Argument
pointer elimination offset. It would appear DF chain info is not maintained,
when global.c
--- Comment #4 from mmitchel at gcc dot gnu dot org 2008-04-28 04:27
---
Not a primary platform.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35399
--- Comment #1 from mmitchel at gcc dot gnu dot org 2008-04-28 04:28
---
Fortran is not a primary language.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35986
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36023
--- Comment #12 from mmitchel at gcc dot gnu dot org 2008-04-28 04:37
---
I don't see that this is a bug, given that the compiler's optimization is
within the bounds set by the C standard. I agree with Kaveh's comment that it
is desirable that C libraries be able to implement external
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35813
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36013
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35987
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36060
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35985
--- Comment #11 from mmitchel at gcc dot gnu dot org 2008-04-28 04:40
---
Manuel --
Would you please open a new bug for the diagnostic.c issue and close this one
now that the library problem has been resolved?
Thanks,
-- Mark
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
--- Comment #2 from ubizjak at gmail dot com 2008-04-28 05:34 ---
Mine.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
64 matches
Mail list logo
