--- Comment #5 from burnus at gcc dot gnu dot org 2007-11-17 08:08 ---
Additional problems, spotted by FX:
subroutine foo(x) bind(c)
character(len=1) :: x
function bar(x) bind(c)
character(len=1) :: x, bar
These generates:
foo (x, _x)
bar (__result, .__result, x, _x)
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-11-17 08:16
---
Could you post a full backtrace?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
I search for demux_lavf.c and libmpdemux and mplayer and didn't found anything
so I hope this wasn't already repported.
Trying to compil mplayer svn with gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
With current trunk on Alpha:
(sid)353:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O1
smapi-api_sdm.c
(sid)354:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O2
smapi-api_sdm.c
smapi-api_sdm.c: In function 'SdmOpenMsg':
smapi-api_sdm.c:15: error: invalid rtl sharing found in
--- Comment #1 from tbm at cyrius dot com 2007-11-17 11:59 ---
Created an attachment (id=14571)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14571action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34132
--- Comment #5 from sparc64 at rediffmail dot com 2007-11-17 11:50 ---
(In reply to comment #3)
This is invalid as there are no computed gotos in your example so the compiler
does not know it is a target for a goto so it is able to move the label
around.
I dont understand why this
--- Comment #2 from tbm at cyrius dot com 2007-11-17 11:59 ---
/* Testcase by Martin Michlmayr [EMAIL PROTECTED] */
static char *sd_msg = %s%u.msg;
void SdmOpenMsg (short mode, char *msgname, int filemode)
{
if (mode == 0)
{
xprintf (msgname, (char *) sd_msg);
filemode = 1;
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-17 12:33 ---
IMNSHO this is not a regression.
void f (const char *)
#ifdef NORET
__attribute__ ((noreturn))
#endif
;
template class T struct A
{
int g ()
{
#ifdef TEST1
f (__FUNCTION__);
#elif defined TEST2
f ((const
--- Comment #2 from sam at rfc1149 dot net 2007-11-17 12:34 ---
Confirmed on 4.3.0 HEAD with a different (and strange) error message.
+===GNAT BUG DETECTED==+
| 4.3.0 20071114 (experimental) (i686-pc-linux-gnu) Program_Error
--- Comment #16 from rask at gcc dot gnu dot org 2007-11-17 12:19 ---
A directive which allows a test to increase the timeout to x times the normal
timeout would probably be a good idea. A few of the tests take much longer than
most and IMO their timeout should be set based on the
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-17 12:35 ---
Oops, sorry for the typo (twice -DTEST3, never -DTEST2). But with -DTEST2 the
output is always identical to -DTEST3 with all compilers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30988
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-17 13:04 ---
*** This bug has been marked as a duplicate of 34113 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-17 12:46 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-17 12:46 ---
Confirmed.
int foo(int i)
{
return -2*__builtin_abs(i-2);
}
get's folded to
return ABS_EXPR (2 - i) * 2;
doh.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-17 12:40 ---
Works for me, this is a dup of PR34113.
*** This bug has been marked as a duplicate of 34113 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-11-17 12:40 ---
*** Bug 34127 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-17 12:37 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
C1237 (R1225) A proc-language-binding-spec shall not be specified for an
internal procedure.
However, gfortran accepts the following:
subroutine foo()
contains
subroutine bar() bind (c)
end subroutine bar
end subroutine foo
program main
use iso_c_binding
implicit none
contains
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-11-17 13:04 ---
*** Bug 34131 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from fxcoudert at gcc dot gnu dot org 2007-11-17 13:49
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Using gcc 4.1, 4.2, or 4.3 I get an ICE when compiling testcase-min.i
$ gcc-4.2 testcase-min.i -O1 -c
testcase-min.i: In function main:
testcase-min.i:4: warning: return type of main is not int
testcase-min.i:21: internal compiler error: in lhd_set_decl_assembler_name, at
langhooks.c:165
--- Comment #1 from edwintorok at gmail dot com 2007-11-17 14:03 ---
Created an attachment (id=14572)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14572action=view)
reduced testcase
To reproduce bug run: gcc -O1 testcase-min.i
I used the delta tool to produce a reduced testcase.
--- Comment #6 from burnus at gcc dot gnu dot org 2007-11-17 13:49 ---
More fun with ENTRY:
a) gfortran does not match the BIND(C) suffix for ENTRY,
R1235 entry-stmt is ENTRY entry-name [ ( [ dummy-arg-list ] ) [ suffix ] ]
cf. decl.c: gfc_match_function_decl and gfc_match_entry
--- Comment #24 from fxcoudert at gcc dot gnu dot org 2007-11-17 13:47
---
Subject: Bug 30285
Author: fxcoudert
Date: Sat Nov 17 13:46:53 2007
New Revision: 130257
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130257
Log:
PR fortran/30285
* module.c (struct
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-17 14:22 ---
Subject: Bug 34130
Author: rguenth
Date: Sat Nov 17 14:22:42 2007
New Revision: 130258
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130258
Log:
2007-11-17 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #2 from edwintorok at gmail dot com 2007-11-17 14:09 ---
(In reply to comment #1)
Created an attachment (id=14572)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14572action=view) [edit]
reduced testcase
To reproduce bug run: gcc -O1 testcase-min.i
I used the delta
As reported by Jack Howarth
http://gcc.gnu.org/ml/fortran/2007-11/msg00122.html
Analysis by Walter Spector:
a) http://gcc.gnu.org/ml/fortran/2007-11/msg00131.html
Ah - the old put block data in a library, and use EXTERNAL to make sure
it gets linked in trick. Many compilers have gotten this
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-17 14:23 ---
Fixed on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
As reported by Dominique,
http://gcc.gnu.org/ml/fortran/2007-11/msg00105.html
Christopher D. Rickett replied:
(3) gfortran.dg/bind_c_coms.f90 which fails because of the warnings:
ld: warning alignment lost in merging tentative definition _f03_com2
ld: warning alignment lost in merging
--- Comment #1 from w6ws at earthlink dot net 2007-11-17 15:34 ---
First, the problem is described, and a full test case available, at:
http://www.ncl.ucar.edu/Download/build_from_src.shtml#CompilersNeeded
Second, I am not sure if part b (changing the name from BSS to TEXT) is
--- Comment #3 from tbm at cyrius dot com 2007-11-17 16:09 ---
I get this ICE too and the backtrace looks suspiciously similar. My testcase
needs -O3:
/* Testcase by Martin Michlmayr [EMAIL PROTECTED] */
struct User
{
char username[10];
};
void auth_set_username (struct User *user)
--- Comment #4 from tbm at cyrius dot com 2007-11-17 16:12 ---
Just that I have PLUS_EXPR rather than MULT_EXPR but it also points to
pointer plus.
pinskia, were you going to take a look at this?
#0 fancy_abort (file=0xb867e8 gcc/tree.c, line=3110,
function=0xb899de build2_stat)
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-11-17 16:48 ---
Apparently, I had run configure and make in the gcc source directory,
which caused this strange behavior. Interestingly, this broke
the build in the bin directory, later.
Checking out a fresh tree, configureing
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2007-11-17 16:55
---
Mine, I have posted a patch.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-11-17 17:10
---
First, a question: what are the math functions that should be used for DFmode
on sh with -m2e? For example, what function should we use for copysign(DFmode,
DFmode): is that copysignl?
After talking about it
--- Comment #8 from pault at gcc dot gnu dot org 2007-11-17 17:18 ---
(In reply to comment #7)
Ah! ubound.51 is not declared anywhere in spec_test.
This comes about because the character length for 'tricky' depends on a
characteristic of a variable, declared in tricky, that is not a
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-17 17:33 ---
LLVM got the pointer type wrong. Anyway, we shouldn't ICE on this.
Testing a fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2007-11-17 17:07 ---
(In reply to comment #2)
I do not see any alternative but to rewrite the interface routines and put
them in resolve.c.
This maybe a bit alarmist but not by much. Certainly, 33888 needs a bit of
help from
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2007-11-17 17:49
---
Subject: Bug 25252
Author: fxcoudert
Date: Sat Nov 17 17:49:45 2007
New Revision: 130259
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130259
Log:
PR fortran/25252
* interface.c
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2007-11-17 17:54
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-17 18:19 ---
Subject: Bug 34133
Author: burnus
Date: Sat Nov 17 18:19:16 2007
New Revision: 130260
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130260
Log:
2007-11-17 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-17 18:20 ---
(In reply to comment #3)
LLVM got the pointer type wrong. Anyway, we shouldn't ICE on this.
Testing a fix.
really these functions should not be exposed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34134
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-11-17 18:21 ---
*** Bug 34134 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-11-17 18:21 ---
*** This bug has been marked as a duplicate of 31128 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2007-11-17 18:21 ---
FIXED on the trunk (4.3.0). (Not part of any branch.)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-11-17 18:22
---
The problem here is that when we resolve cshift and eoshift we convert dim from
a EXPR_VARIABLE to a EXPR_FUNCTION that converts the type to match up with the
runtime function.
Later in trans-expr.c, code is not
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #10 from jakub at gcc dot gnu dot org 2007-11-17 19:25 ---
Created an attachment (id=14573)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14573action=view)
gcc43-pr34134.patch
Patch to avoid the ICE.
I don't mind the patch which disables these builtins either, but
1)
--- Comment #7 from rob dot quill at gmail dot com 2007-11-17 19:27 ---
I believe I have this done, just checking there are no regressions.
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33092
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-11-17 20:36 ---
(In reply to comment #5)
I dont understand why this bug is invalid. When I use label, I intend to
load the address where I point to in my code -- not where the compiler wants
to
move it around.
No, this
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-11-17 20:38 ---
Well this is invalid if you did a configure/make in the gcc source directory
and now trying to build in another directory without doing make distclean.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-17
21:42 ---
Subject: Re: xgcc: Internal error: Segmentation fault (program gnat1)
Could you post a full backtrace?
Program received signal SIGSEGV, Segmentation fault.
0x00ef4ce0 in linemap_lookup (set=0x7aedc000,
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-11-17 21:46
---
Program received signal SIGSEGV, Segmentation fault.
0x00ef4ce0 in linemap_lookup (set=0x7aedc000, line=2)
at ../../gcc/libcpp/line-map.c:282
282 if (line = cached-start_location)
(gdb) bt
#0
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-17 21:48 ---
Note that instead of PR31976 where this ICE probably happens because of bad
luck, this testcase is a recipie to create a VOP with N operands that will
never be partitioned (due to the PR33870 fix) and thus reliably
--- Comment #6 from danglin at gcc dot gnu dot org 2007-11-17 22:05 ---
Hardware watchpoint 6: (int) preinit_symbols
Old value = 0
New value = 2061380416
dbxout_symbol (decl=0x7adf60d0, local=0) at ../../gcc/gcc/dbxout.c:2494
2494 DBXOUT_DECR_NESTING_AND_RETURN (0);
(gdb) bt
--- Comment #7 from danglin at gcc dot gnu dot org 2007-11-17 22:07 ---
This is decl. gdb crashes when I use print_tree:
(gdb) p debug_tree (decl)
type_decl 7adf60d0 long int
type integer_type 7aded000 long int sizes-gimplified public visited
sizetype SI
size integer_cst
--- Comment #8 from danglin at gcc dot gnu dot org 2007-11-17 22:13 ---
(gdb) p *set
$3 = {maps = 0x0, allocated = 0, used = 0, cache = 0, last_listed = -1,
depth = 0, trace_includes = 0 '\0', highest_location = 0, highest_line = 0,
max_column_hint = 0,
reallocator = @0x40057d72:
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2007-11-17 22:15
---
Fixing.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bdavis at gcc dot gnu dot org 2007-11-17 22:35 ---
here is what i got on a P4, running FC8.
[EMAIL PROTECTED] gfc]$ /usr/bin/gfortran -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-11-17 22:42
---
It's 64-bit only, and it appears to be a glibc bug: with glibc on x86_64,
sinf((float) integer_variable) is slower than (float)sin((double)
integer_variable). Paul Brook looked into it a bit, and said that while
--- Comment #3 from rwgk at yahoo dot com 2007-11-18 02:54 ---
(In reply to comment #2)
Works for me, this is a dup of PR34113.
*** This bug has been marked as a duplicate of 34113 ***
This is not the case. My original bug report was based on svn revision
130232, which includes
--- Comment #8 from sparc64 at rediffmail dot com 2007-11-18 07:25 ---
Ok, Continued :
The goto statement works fine with optimization unless that goto is
needless (like goto to next C statement) in which case, usage of labels as
addresses in other places (like printf) takes a beating.
--- Comment #9 from sparc64 at rediffmail dot com 2007-11-18 07:28 ---
I must have said architectural hurdles not limitations... especially
because I have quoted harvard cache as an example.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581
63 matches
Mail list logo
