I ran into a peculiar bug with gfortran:
program check
open( 10, file = 'check.inp', form = 'binary' )
! Comment
end program
(the comment starts at column 132, but the problem actually occurs in
a long linje with trailing blanks too)
--- Comment #15 from bonzini at gnu dot org 2009-08-07 07:24 ---
Subject: Re: version 150336 broke bootstrap on ia64-hp-hpux11.23
After applying the most recent patch the ia64 bootstrap started working but
the
pa bootstrap (hppa2.0w-hp-hpux11.11) started failing. The
--- Comment #3 from jv244 at cam dot ac dot uk 2009-08-07 07:35 ---
still missing 4.5.0, this seems a particularly useful F03 feature ;-)
For an expert, should be 'easy' to add (ignoring the F2008 variant) ?
--
jv244 at cam dot ac dot uk changed:
What|Removed
--- Comment #7 from thomas at coware dot com 2009-08-07 07:37 ---
This is how function func looks after the if conversion (test.c.144r.ce1):
(note 4 0 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 4 3 2 test.c:3 (set (reg/v:SI 63 [ arg ])
(mem/c/i:SI (reg/f:SI 16 argp) [0 arg+0 S4
The following semi-invalid code ICEs (but compiles fine with ifort):
MODULE f03_test
USE, INTRINSIC :: ISO_C_BINDING
INTERFACE
FUNCTION build(lib, np) BIND(C)
END FUNCTION
END INTERFACE
PROCEDURE(build), POINTER :: pbuild
CONTAINS
SUBROUTINE test_asc()
END SUBROUTINE
uname -a
Linux loanamd25 2.6.16.46-0.10-smp #1 SMP Mon May 7 13:37:05 UTC 2007 x86_64
x86_64 x86_64 GNU/Linux
gfortran --version
GNU Fortran (GCC) 4.5.0 20090730 (experimental)
cat type.f90
subroutine sub(n,x)
intrinsic abs
integer n, x(abs(n))
end
gfortran -Wall -c type.f90
type.f90:2.13:
--- Comment #4 from paolo dot carlini at oracle dot com 2009-08-07 08:22
---
Nice that we have a workaround, still, the problem should not happen anyway: in
normal builds on x86_64-linux, no fenv.h is generated during the build and the
one provided by the underlying libc is of course
--- Comment #3 from rakdver at gcc dot gnu dot org 2009-08-07 08:44 ---
(In reply to comment #1)
The tree optimizers canonicalize the loop to
bb 3:
# i_5 = PHI i_3(4), 0(2)
# ivtmp.23_1 = PHI ivtmp.23_4(4), 10(2)
f2 ();
i_3 = i_5 + 1;
ivtmp.23_4 = ivtmp.23_1 - 1;
--- Comment #4 from andi-gcc at firstfloor dot org 2009-08-07 08:50 ---
The RTL loop optimizer does this optimization. I had to fix it a couple
of years ago for unsigned variables.
I think the loop optimizer still does it, just the gcc 4 frontend doesn't
give it input RTL with a
--- Comment #5 from rakdver at kam dot mff dot cuni dot cz 2009-08-07
08:54 ---
Subject: Re: [4.3/4.4/4.5 Regression] No loop counter reversal for simple
loops anymore
The RTL loop optimizer does this optimization. I had to fix it a couple
of years ago for unsigned variables.
I
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-08-07 08:32 ---
Err, that's not exactly a fix for -O2/-O3 ;)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The ALLOCATABLE attribute was only allowed for arrays in F95, but F03 also
allows allocatable scalars (which will be useful for polymorphism).
Simple example:
real, allocatable :: scalar
allocate(scalar)
scalar = exp(1.)
print *,scalar
deallocate(scalar)
end
With current trunk you get:
--- Comment #1 from jv244 at cam dot ac dot uk 2009-08-07 09:15 ---
for reference:
elete_root (t=0x1306d40) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/bbt.c:149
149 if (t-left-priority t-right-priority)
(gdb) bt
#0 delete_root (t=0x1306d40) at
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-07 09:27 ---
Before the ICE one gets the error:
SUBROUTINE test_bind_c BIND(C,name=test_bind_c)
1
Error: Missing required parentheses before BIND(C) at (1)
If this error is
--- Comment #6 from andi-gcc at firstfloor dot org 2009-08-07 09:38 ---
It worked on x86 at least
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40886
--- Comment #5 from bonzini at gnu dot org 2009-08-07 09:46 ---
No, the build system should support everything; not just host==target != build
which is not so uncommon -- for example this is how cygwin worked before it
could host GCC -- but even the admittedly crazy target==build !=
--- Comment #7 from steven at gcc dot gnu dot org 2009-08-07 09:47 ---
Re. comment #6: doloop never worked on x86 except for the AMD K6. x86 does not
have a doloop pattern.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40886
--- Comment #8 from andi-gcc at firstfloor dot org 2009-08-07 09:52 ---
At least my example in the original bug description shows that the optimization
worked on gcc 3.3. If your theory doesn't explain this then your theory is
wrong.
--
--- Comment #5 from mikpe at it dot uu dot se 2009-08-07 10:06 ---
The test case doesn't appear to be in the repository.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39987
--- Comment #3 from jv244 at cam dot ac dot uk 2009-08-07 10:11 ---
(In reply to comment #2)
Before the ICE one gets the error:
SUBROUTINE test_bind_c BIND(C,name=test_bind_c)
1
that's why I called the testcase semi-invalid. Note
--- Comment #6 from paolo dot carlini at oracle dot com 2009-08-07 10:12
---
Paolo, if you could help, it would be great. About the driver, really I have no
idea. And I have never seen that almost-empty generated fenv.h, if it's really
happening maybe the library-proper isn't at
--- Comment #7 from bonzini at gnu dot org 2009-08-07 10:45 ---
What's the content of gcc/fenv.h in the build directory? If I have to guess,
I'd suppose it's generated by fixincludes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
Linux buildhost 2.6.30.1amd64-kvm #1 SMP Tue Jul 7 10:55:30 UTC 2009 x86_64
GNU/Linux
../gcc-4.4.1/configure --disable-multilib --enable-languages=c,c++
(Also found to fail with gcc4.3.4 (64bit), gcc4.3.2 (32bit))
Test.cpp:
#include cassert
#include iostream
using std::cout;
using std::endl;
--- Comment #1 from janus at gcc dot gnu dot org 2009-08-07 11:22 ---
The following is enough to make the test case work:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 150529)
+++
--- Comment #2 from burnus at gcc dot gnu dot org 2009-08-07 11:48 ---
Of cause, you need to add a -std=f95 check - and one should do some
thinking/testing whether other items are missing.
There are some other related issues, which should be handled separately:
- Allocate on assignment
--- Comment #3 from janus at gcc dot gnu dot org 2009-08-07 11:54 ---
(In reply to comment #2)
and one should do some thinking/testing whether other items are missing.
One things which is missing is the ALLOCATED intrinsic. Working on it ...
--
--- Comment #8 from booleandomain at gmail dot com 2009-08-07 11:58 ---
Created an attachment (id=18316)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18316action=view)
x86_64-unknown-linux-gnu/libstdc++-v3/include/fenv.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #9 from booleandomain at gmail dot com 2009-08-07 12:00 ---
Created an attachment (id=18317)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18317action=view)
x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1/fenv.h
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-07 12:01 ---
What is the expected output and what is the wrong output you see?
The Intel compiler produces
bas...@0x7fffdd88
b...@0x7fffdd98
bart: 0x7fffdd88
baseIf: 0x7fffdd88
bar:0x7fffdd98
--- Comment #10 from booleandomain at gmail dot com 2009-08-07 12:03
---
Created an attachment (id=18318)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18318action=view)
build-stage1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-08-07 12:31
---
Adding this to Bart::InnerBart::getOuter():
cout BaseIf1: (BaseIf*)outer endl;
and this to Bar::InnerBar::getVal():
cout BaseIf2: (BaseIf*)bar endl;
shows different values for
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-08-07 12:42
---
Ah, [class.virtual] paragraph 5 says:
If the return type of D::f differs from the return type of B::f, the class type
in the return type of D::f shall be complete at the point of declaration of
D::f or shall be
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-07 13:07 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dodji at gcc dot gnu dot org 2009-08-07 13:13 ---
Subject: Bug 39987
Author: dodji
Date: Fri Aug 7 13:13:12 2009
New Revision: 150568
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150568
Log:
2009-08-07 Dodji Seketeli do...@redhat.com
PR c++/39987
--- Comment #7 from dodji at gcc dot gnu dot org 2009-08-07 13:16 ---
Subject: Bug 39987
Author: dodji
Date: Fri Aug 7 13:15:43 2009
New Revision: 150569
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150569
Log:
2009-08-07 Dodji Seketeli do...@redhat.com
PR c++/39987
--- Comment #8 from dodji at gcc dot gnu dot org 2009-08-07 13:16 ---
Subject: Re: [4.3/4.4/4.5 Regression] Rejects default argument
that is a template via access failure
Le 07/08/2009 12:06, mikpe at it dot uu dot se a écrit :
--- Comment #5 from mikpe at it dot uu dot se
--- Comment #4 from dodji at gcc dot gnu dot org 2009-08-07 13:20 ---
Subject: Re: New: [4.5 Regression] ICE in create_tmp_var,
at gimplify.c:504
Patch posted at http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00428.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40866
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-07 13:25 ---
(In reply to comment #1)
Janus, I think it is another side effect of your intrinsic patches.
Probably yes. But: I have a patch (regtesting right now).
--
janus at gcc dot gnu dot org changed:
What
--- Comment #3 from janus at gcc dot gnu dot org 2009-08-07 13:27 ---
Created an attachment (id=18322)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18322action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40995
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-07 13:39 ---
I guess m32c implements a widening multiplication that isn't correctly
implemented. Because (short)(40 * -1000) is exactly 25526.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-08-07 13:40 ---
EDG accepts the code in strict-ansi mode as well, without a diagnostic.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-07 13:57 ---
I think there is a general GCC 4.5 problem with debugging symbols. I opened a
PR about this (PR 40660) - which is regarding Fortran - but there was recently
also GCC complaining at #gcc about this issue when
--- Comment #4 from janus at gcc dot gnu dot org 2009-08-07 14:14 ---
The attached patch regresses on:
FAIL: gfortran.dg/gamma_2.f90 -O (test for excess errors)
FAIL: gfortran.dg/intrinsic_subroutine.f90 -O (test for errors, line 6)
FAIL: gfortran.dg/intrinsic_subroutine.f90 -O
--- Comment #2 from burnus at gcc dot gnu dot org 2009-08-07 14:23 ---
Hmm, actually your example works here:
(gdb) b 7
Breakpoint 1 at 0x4007a0: file hjff.f90, line 7.
(gdb) run
[...]
Breakpoint 1, dummy () at hjff.f90:7
7 PRINT *, 'Hello',nerr
(gdb) p nerr
$1 = 666
Hello,
Following code (written just for fun) leads to:
Program received signal SIGSEGV, Segmentation fault.
main () at main-general.cpp:95
95 printf(%d\n, x_reg);
BTW, there is warning when using ecx, eax, edx.
should there be any warning for esp?
GCC 4.4
X86
Compile flags: -g3
--- Comment #3 from burnus at gcc dot gnu dot org 2009-08-07 14:32 ---
The result of eu-readelf looks OK, however, since I read module for item 175,
I wonder whether this is a problem that gdb is too old. There was a change (I
think in the later stages of 4.4.0) which wrote the proper
--- Comment #2 from burnus at gcc dot gnu dot org 2009-08-07 14:41 ---
Using 4.5.0 20090805 with GDB 6.8.50.20090803-10.1 (includes patches of
Fedora/Jan Kratochvil which support F90 arrays/C99 VLA and module variables),
the result is now:
Breakpoint 1, test () at fhjf.f90:3
3
The function alloca (for cygwin/mingw target _alloca) is broken or not
available (for linux64), when using option -fno-builtin.
The linux and win32 targets the symbol alloca isn't present. For windows
targets there is an implementation (_alloca) in gcc/config/i386/cygwin.asm
present. But when
--- Comment #5 from janus at gcc dot gnu dot org 2009-08-07 15:37 ---
Created an attachment (id=18323)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18323action=view)
updated patch
Updating patch to take care of the two observed regressions.
--
janus at gcc dot gnu dot org
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-08-07 15:38 ---
Created an attachment (id=18324)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18324action=view)
Testcase for alloca/_alloca
to be compiled with option -fno-builtins
--
--- Comment #6 from janus at gcc dot gnu dot org 2009-08-07 15:46 ---
(In reply to comment #1)
When fixing it, one should make sure that
intrinsic abs
real abs
still prints a warning with -Wsurprising.
This is done by intrinsic.f90 and intrinsic_2.f90 in the testsuite.
--
--- Comment #4 from burnus at gcc dot gnu dot org 2009-08-07 16:00 ---
There was a change (I think in the later stages of 4.4.0) which wrote the
proper
DWARF_MODULE* to the ELF binary. However, gdb did ignore that bit.
There was a fix for the gdb trunk
See:
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2009-08-07 16:06
---
The problem is that the error locus is at the end of the line rather then the
end of the non-whitespace characters of the related statement.
--
jvdelisle at gcc dot gnu dot org changed:
What
--- Comment #4 from dj at redhat dot com 2009-08-07 16:26 ---
m32c != m32r
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41000
--- Comment #6 from eric dot weddington at atmel dot com 2009-08-07 16:38
---
The test case works for me on AVR GCC 4.3.2 using -Wall and -O[0123s]. Closing
bug.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #5 from toon at moene dot org 2009-08-07 16:58 ---
Could indeed be the version of gdb.
Mine is:
$ gdb -v
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software:
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-07 17:02 ---
Subject: Bug 40999
Author: rguenth
Date: Fri Aug 7 17:02:43 2009
New Revision: 150572
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150572
Log:
2009-08-07 Richard Guenther rguent...@suse.de
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-07 17:19 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from joseph at codesourcery dot com 2009-08-07 17:24 ---
Subject: Re: New: alloca broken for -fno-builtin
On Fri, 7 Aug 2009, ktietz at gcc dot gnu dot org wrote:
The function alloca (for cygwin/mingw target _alloca) is broken or not
available (for linux64), when
--- Comment #3 from jv244 at cam dot ac dot uk 2009-08-07 17:28 ---
Is there some meta-bug about Fortran-related debug issues? I've added PR 40823
about another debug issue. It likely requires a FE fix, so the component
'debug' is somewhat too vague.
--
Compiling following code [1] in the following way [2] with gcc 4.3.3 leads to
the diagnostics [3].
To my mind statement
test.cpp: In constructor 'testclass::testclass()':
test.cpp:4: error: class 'testclass' does not have any field named 'number'
is redundant because statements
test.cpp:15:
program bug
integer :: a(5) = (/1,2,3,4,5/)
integer, allocatable:: b(:)
b = (/ a(1:5), a(1:5) /)
print *, b
endprogram bug
integer :: a(5) = (/1,2,3,4,5/)
integer, allocatable:: b(:)
b = (/ a(1:5), a(1:5) /)
print *, b
end
The assignment to b generates a seg fault. I believe this to be
--- Comment #1 from b0ntrict0r at yandex dot ru 2009-08-07 18:11 ---
By the way using gcc instead of g++ doesn't changed things.
And I've just tested this code with Comeau online C++ compiler and it gave
exactly what I want to get:
Comeau C/C++ 4.3.10.1 (Oct 6 2008 11:28:09) for
--- Comment #7 from mahatma at eu dot by 2009-08-07 18:21 ---
(In reply to comment #6)
You can try my patch for PR 40838.
No error.
Current i386.h must be fixed by hands. Next I attach gcc-4.4.1 version of this
patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40985
--- Comment #8 from mahatma at eu dot by 2009-08-07 18:24 ---
Created an attachment (id=18325)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18325action=view)
PR 40838 for gcc 4.4.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40985
--- Comment #4 from eric dot weddington at atmel dot com 2009-08-07 18:56
---
No news on this for several years. Closing as WONTFIX.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #1 from eric dot weddington at atmel dot com 2009-08-07 19:16
---
*** This bug has been marked as a duplicate of 34734 ***
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #3 from eric dot weddington at atmel dot com 2009-08-07 19:16
---
*** Bug 40112 has been marked as a duplicate of this bug. ***
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2009-08-07
19:25 ---
Keywords: mangling, anonymous namespaces.
Adding option such as -frandom-seed=271828 to CXXFLAGS_FOR_TARGET allows to
bootstrap.
--
d dot g dot gorbachev at gmail dot com changed:
What
--- Comment #1 from kargl at gcc dot gnu dot org 2009-08-07 19:27 ---
*** This bug has been marked as a duplicate of 35810 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from kargl at gcc dot gnu dot org 2009-08-07 19:27 ---
*** Bug 41003 has been marked as a duplicate of this bug. ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-08-07 21:05 ---
(In reply to comment #2)
Subject: Re: New: alloca broken for -fno-builtin
On Fri, 7 Aug 2009, ktietz at gcc dot gnu dot org wrote:
The function alloca (for cygwin/mingw target _alloca) is broken or not
--- Comment #18 from skunk at iskunk dot org 2009-08-07 21:13 ---
Confirmed correct fixincluding of if.h in the GCC 4.4.1 build. Ding, dong, this
bug is dead!
--
skunk at iskunk dot org changed:
What|Removed |Added
--- Comment #4 from joseph at codesourcery dot com 2009-08-07 22:36 ---
Subject: Re: alloca broken for -fno-builtin
On Fri, 7 Aug 2009, ktietz at gcc dot gnu dot org wrote:
Well, if so. It makes no sense that -fno-builtins tries to call a function
which isn't present. But for other
Compile the attached source code with options -Os -march=armv5te -mthumb
Gcc generates following code snippet:
...
cmp r0, r2
bne .L5
b .L15--- A
.L9:
ldr r3, [r1]
cmp r3, #0
beq .L7
str
--- Comment #1 from carrot at google dot com 2009-08-08 00:10 ---
Created an attachment (id=18326)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18326action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41004
I was trying to build a simple app and use the std::string to build an ofstream
as allowed by C++-0X.
The source and header allows this. You can compile but not link.
I've verified this on powerpc-apple-darwin7.9.0 and on x86_64-linux-unknown.
I think symbols are getting stripped out of the
78 matches
Mail list logo
