We recently upgraded to 4.2.1 and noticed an immediate issue. After compiling
gcc for sparcv9 and specifically setting --with-ld=/usr/local/gnu/bin/ld,
whenever gcc actually runs it internally calls the Sun linker and therefore
dies with unknown options. A simple "hello world" refuses to build beca
--- Comment #6 from jason at gcc dot gnu dot org 2007-09-30 02:41 ---
Subject: Bug 33094
Author: jason
Date: Sun Sep 30 02:41:39 2007
New Revision: 128890
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128890
Log:
PR c++/33094
* decl.c (make_rtl_for_nonlocal_decl
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-09-30 01:58
---
It turns out that the original patch for this bug is probably what we want.
Unfortunately it uncovers a nasty latent bug where an extraneous namelist read
is attempted. It only seems to occur with multiple leve
--- Comment #4 from amruth dot laxman at nsn dot com 2007-09-29 23:58
---
You're right - I can use aligned, but I will have to search through 100,000+
lines of code to find all the places that character arrays are used and then
add the aligned directive. A lot of this code is open-sourc
--- Comment #25 from fxcoudert at gcc dot gnu dot org 2007-09-29 23:20
---
I should have posted my reduced testcase, so that I don't lose it:
real(16) :: y
y=huge(y)
write(*,"(G60.50E4)") y
write(*,"(G60.50E4)") nearest(y,1.)
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3284
--- Comment #24 from fxcoudert at gcc dot gnu dot org 2007-09-29 23:15
---
First, I should note that this doesn't affect real kinds 4 and 8, due to
Jerry's per-kind I/O change; this bug now only shows up for real(kind=16).
Second, this is a problem with huge(0._16) not being equal to LD
--- Comment #3 from ismail at pardus dot org dot tr 2007-09-29 23:03
---
Created an attachment (id=14270)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14270&action=view)
Corresponding *.i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33597
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-29 22:59 ---
The .i file is important and not the .s file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33597
--- Comment #1 from ismail at pardus dot org dot tr 2007-09-29 22:58
---
Created an attachment (id=14269)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14269&action=view)
rgb2rgb.s produced with -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33597
Specs:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/usr/lib/gcc-snapshot --disable-libgcj
--disable-libssp --disable-nls --disable-werror --disable-checking
--enable-clocale=gnu --enable-__cxa_atexit
--enable-languages=c,c++,fortran,objc --enable-libstdcx
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32406
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28313
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
$ cat o1.f90
print *, isnan (0.)
end
$ gfortran o1.f90
o1.f90: In function 'MAIN__':
o1.f90:1: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6830
The backtrace is:
#0 fancy_abort (file=0x81818c "../../trunk/gcc/expr.c", line=6830,
function=0x818638 "expand_expr_addr_expr_1") a
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/nint_2.f90 -O0 -pedantic-errors
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/h
--- Comment #3 from danglin at gcc dot gnu dot org 2007-09-29 20:42 ---
Also occurs on hppa64-hp-hpux11.11.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-29 20:42 ---
if you want aligned arrays use attribute aligned. Now GCC should automatically
doing it for non -Os/stack saving mode for optimization reasons but other than
that, you cannot depend on the alignment.
--
http://
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-09-29 20:40 ---
You should able to use the attribute aligned to get what you want.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33594
--- Comment #2 from danglin at gcc dot gnu dot org 2007-09-29 20:18 ---
realloc is called with a NULL pointer and 0 size.
realloc (0, 0) returns NULL. This causes _gfortran_os_error
to get called and the above error to get printed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=335
--- Comment #2 from amruth dot laxman at nsn dot com 2007-09-29 20:12
---
Two questions:
- why change the behavior of gcc from 3.x to 4.x?
- is there any harm in adding alignment for arrays? If not, can we make this an
enhancement request?
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-29 20:06 ---
As of comment #2 this is a possible enhancement for non -Os (or stack saving
mode) on STRICT_ALIGNMENT targets.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-29 20:03 ---
As you say, you cannot rely on alignment > 1 for an array of char.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
gcc version: 4.2.1 (also occurs with versions as early as 4.0.2)
configured with: ../gcc-4.2.1/configure --enable-languages=c,c++
With gcc 4.x, local variable arrays declared on the stack are no longer aligned
at word boundaries. For example:
void somefunc()
{
...
char buf[100];
...
}
In gcc 3
--- Comment #3 from dancecile at gmail dot com 2007-09-29 19:33 ---
wow, thanks :) dmesg was full of low memory stuff, and it turns out my swap
wasn't mounted so thanks for pointing this out quick.
i ran the compile again and it worked ok. looking at my memory consumption, i
saw that cc
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-29 19:08 ---
I think 1/0 should not be marked as throwing though as it is target dependent
if it actually will trap or not. In fact as I mentioned on PPC, it does not
trap.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=335
--- Comment #3 from dnovillo at google dot com 2007-09-29 19:08 ---
Subject: Re: tree-outof-ssa moves sources of non-call exceptions past sequence
points
On 29 Sep 2007 19:05:20 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> 1 / 0;
>
> that does not aways trap. on
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-29 19:05 ---
1 / 0;
that does not aways trap. on ppc an undefined value is returned.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33593
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-29 19:05 ---
Confirmed. Happens after final_cleanup of the following function:
;; Function void somefunction() (_Z12somefunctionv)
void somefunction() ()
{
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru,exec)
som
--- Comment #1 from rsandifo at gcc dot gnu dot org 2007-09-29 19:05
---
Assigning to Diego as he already has a patch (thanks!)
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
---
tree-outof-ssa can move potentially-trapping operations across what were
sequence points, even when compiled with -fnon-call-exceptions. E.g.,
consider the following C++ code, compiled with -fnon-call-exceptions:
#include
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-29 19:01 ---
c++: Internal error: Killed (program cc1plus)
something killed g++, likely your system ran out of memory. Consult output
of 'dmesg'.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-29 19:00 ---
Operating system error: Not a typewriter
Out of memory
uhm, this doesn't make too much sense. Can you debug this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33592
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B
/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
/test/gnu/gcc/gcc/gcc/testsui
te/gfortran.dg/array_constructor_11.f90 -O0 -pedantic-errors
-L/test/gnu/gc
c/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs
-L/test
--- Comment #1 from dancecile at gmail dot com 2007-09-29 18:35 ---
Created an attachment (id=14268)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14268&action=view)
"the preprocessed file (*.i*) that triggers the bug"
Here's the .ii file that was generated (uncompressed 1.8 MB, t
--- Comment #1 from edwintorok at gmail dot com 2007-09-29 18:10 ---
Created an attachment (id=14267)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14267&action=view)
preprocessed C program to reproduce bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33591
When reading entries of a directory with readdir() on a directory
containing many files, mudflap gives warning about out-of-bound writes.
mudflap.c: MF_VALIDATE_EXTENT (p, sizeof (*p), __MF_CHECK_WRITE, "readdir
result");
mudflap checks that the entire struct dirent is writable, however the size
Running c++ on Kubuntu Fiesty Fawn, with gcc version 4.1.2 (Ubuntu
4.1.2-0ubuntu4).
c++ crashes while processes the file, saying "c++: Internal error: Killed
(program cc1plus)"
The command is:
/usr/bin/c++ -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align
-Wchar-subscripts -Wall -W -Wp
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-29 18:04 ---
va_list on the target you are using just happens to be a char* and not a
seperate type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33588
g++43 -v output:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --program-suffix=43 --disable-multilib
--enable-languages=c,c++
Thread model: posix
gcc version 4.3.0 20070929 (experimental) (GCC)
Built from svn trunk, revision 128885
Compiling this
--- Comment #1 from oliver dot kellogg at eads dot com 2007-09-29 17:10
---
No longer crashes for me using r128881 (4.3.0 20070929)
--
oliver dot kellogg at eads dot com changed:
What|Removed |Added
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-29
16:47 ---
Subject: Re: FAIL: gfortran.dg/gamma_1.f90
> Subject: Re: FAIL: gfortran.dg/gamma_1.f90
>
> > libgfortran in general assumes that a full C99 runtime is available.
It was the fortran frontend that genera
--- Comment #1 from stephan at s11n dot net 2007-09-29 16:31 ---
Created an attachment (id=14266)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14266&action=view)
Demonstrates the problem.
Demonstrates this seeming bug, including the discrepancy between client-defined
varargs func
(i submitted this via gccbugs, but the script gave me no feedback about whether
the report was actually sent or not, so i'm re-posting here.)
gcc 4.2.1 appears to incorrectly(?) give a warning when a client-written
varargs func is passed a string literal (e.g. __FILE__) as one of the
arguments. e.
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-29
16:15 ---
Subject: Re: FAIL: gfortran.dg/gamma_1.f90
> libgfortran in general assumes that a full C99 runtime is available.
lgamma and lgamma_r are available, so it should be possible to fudge
a f version. This is
--- Comment #6 from tkoenig at gcc dot gnu dot org 2007-09-29 13:12 ---
(In reply to comment #5)
> I added a testcase for this.
Thanks!
> Can this bug be closed or does anyone feel
> strongly enough about it to fix it in 4.2?
If we can identify which patch fixed this, I'd be in favor
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-29 12:48 ---
GNU MP: Cannot reallocate memory (old_size=4 new_size=268435472)
this looks like a GMP bug, not a GCC bug [GCC doesn't even use GMP, only
MPFR which is used does].
What's your GMP version? Try updating to the late
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-29 12:45 ---
libgfortran in general assumes that a full C99 runtime is available.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33583
--- Comment #4 from patchapp at dberlin dot org 2007-09-29 09:40 ---
Subject: Bug number PR33566
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg02054.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from pault at gcc dot gnu dot org 2007-09-29 09:21 ---
(In reply to comment #2)
I take that back - I had to copy the patch by hand and, inevitably, got it
wrong.
I'll regtest over again and then submit it.
Je te remercie, Mikael!
Paul
--
http://gcc.gnu.org/bugzill
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-09-29 08:50 ---
(In reply to comment #5)
> I didn't think that -static was causing the problem since the application
> seems
> to execute correctly with the -m32 option removed, and with the -static
> remaining.
glibc is slightly
--- Comment #2 from pault at gcc dot gnu dot org 2007-09-29 08:48 ---
(In reply to comment #1)
This causes one regression - data_components_1.f90. I either have to check if
the reference is not constant or to try to simplify the expression and see if
the result is constant.
Paul
--
--- Comment #1 from kai-gcc-bugs at khms dot westfalen dot de 2007-09-29
08:35 ---
Forgot to mention, this is revision 127595.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33587
Line 6399:
@defmac INIT_SECTION_ASM_OP
If defined, a C expression whose value is a string, including spacing,
containing the assembler operation to identify the following data as
initialization code. If not defined, GCC will assume such a section does
not exist. This section has no corresponding
--- Comment #5 from tobi at gcc dot gnu dot org 2007-09-29 08:00 ---
I added a testcase for this. Can this bug be closed or does anyone feel
strongly enough about it to fix it in 4.2?
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from tobi at gcc dot gnu dot org 2007-09-29 07:57 ---
Subject: Bug 33354
Author: tobi
Date: Sat Sep 29 07:57:37 2007
New Revision: 128882
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128882
Log:
PR fortran/33354
* gfortran.dg/minmaxloc_4.f90: New.
Added:
tr
--- Comment #5 from spollmann at gmail dot com 2007-09-29 07:10 ---
(In reply to comment #4)
> (In reply to comment #3)
> > What happens if you don't use -static?
> if static is not used (and the LD_LIBRARY_PATH points to the correct location
> ;)
> the program seems to execute correctly
--- Comment #4 from spollmann at gmail dot com 2007-09-29 07:04 ---
(In reply to comment #3)
> What happens if you don't use -static?
if static is not used (and the LD_LIBRARY_PATH points to the correct location
;)
the program seems to execute correctly.
--
http://gcc.gnu.org/bugzi
58 matches
Mail list logo
