--- 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
--- 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 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 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
---
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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
(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 #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
--- 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 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
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 #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
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
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
--- 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
--- 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
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 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
--- 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
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 #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
---
--- 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 #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 #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 #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 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
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 #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
--
--- 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 #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 #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 #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 #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 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
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
$ 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
--
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
--
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
--
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=32406
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
--- 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
--- 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 #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 #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 #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 #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
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 #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 #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
58 matches
Mail list logo
