--- Comment #7 from ubizjak at gmail dot com 2007-04-04 08:05 ---
This is the minimal test case for this bug:
--cut here--
extern void foo(void);
double *data;
double test()
{
double sum = 123.321;
int i;
for (i=0; i<4; i++)
sum += data[i];
foo();
foo();
return sum;
--- Comment #6 from pault at gcc dot gnu dot org 2007-04-04 08:19 ---
1
> Internal Error at (1):
> check_init_expr(): Unknown expression type
> I don't know if it exposes another bug or exposes something missing in your
> patch.
FX,
I have just r
--- Comment #8 from ubizjak at gmail dot com 2007-04-04 09:21 ---
The difference is in CALLER_SAVE_PROFITALBLE condition. The pseudo that holds
sum is referenced 6 times. When only one foo() is called, default
CALLER_SAVE_PROFITABLE condition causes RA to allocate call-clobbered registe
--- Comment #1 from pault at gcc dot gnu dot org 2007-04-04 09:44 ---
This fixes the immediate problem. I have to check with the standard if the
parameter is meant to take all of its characteristics from the value or if it
is just KIND.
Index: gcc/fortran/decl.c
===
Hello,
I suspect that I have found a bug in GCC. In this message you find
all information you request at http://gcc.gnu.org/bugs.html.
Best regards, Nils Holm
-- description --
An member of an array A is assigned the value of a function P.
As a side effect, the function P reallo
internal compiler error: in gfc_conv_expr, at fortran/trans-expr.c:2827
--
Summary: internal compiler error when compiling with gfortran
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
Nils M Holm <[EMAIL PROTECTED]> writes:
> -- description --
> An member of an array A is assigned the value of a function P.
> As a side effect, the function P realloc()s the array A.
>
> When including the array A in a multiple assignment, the
> old address of A is used instead of
--- Comment #1 from valerie dot vallet at univ-lille1 dot fr 2007-04-04
11:08 ---
Created an attachment (id=13326)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13326&action=view)
source file, preprocessor file, verbose output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31
Hi Eric, Hi Richard,
I need your brains...
The mips64vrel-elf toolchain is showing a lot of unexpected failures
in the gcc testsuite (and g++ testsuite) for multilibs which use
-mlong64 and -mgp32 together. For example the first one I came
across is this:
% ... mips64vrel-elf/gcc/
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-04-04 12:06 ---
Your file lacks the USEd modules "kindvar" and "caps".
Which compiler version(s) did you use?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from steven at gcc dot gnu dot org 2007-04-04 12:12 ---
I want to understand this better, so I'll investigate this.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from steven at gcc dot gnu dot org 2007-04-04 12:17 ---
Richi, Honza, is anyone looking at this problem?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from steven at gcc dot gnu dot org 2007-04-04 12:19 ---
Still see this.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-04-04 12:35 ---
No.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27869
Nick Clifton <[EMAIL PROTECTED]> writes:
> Hi Eric, Hi Richard,
>
> I need your brains...
>
> The mips64vrel-elf toolchain is showing a lot of unexpected failures
> in the gcc testsuite (and g++ testsuite) for multilibs which use
> -mlong64 and -mgp32 together. For example the first one I
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-04-04 12:46 ---
Fixed on the mainline by
Author: hubicka
Date: Fri Mar 30 09:03:55 2007
New Revision: 123358
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123358
Log:
PR middle-end/PR30700
* dwarf2out.c (re
--- Comment #5 from steven at gcc dot gnu dot org 2007-04-04 12:47 ---
Investigating...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
--- Comment #3 from eweddington at cso dot atmel dot com 2007-04-04 13:41
---
Created an attachment (id=13327)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13327&action=view)
Patch by Anatoly Sokolov
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29932
--- Comment #20 from gcc at futurenotfound dot com 2007-04-04 14:34 ---
I've been getting this issue on a Playstation 3 with Gentoo, it's an issue
particular to the 64-bit userland as opposed to the 32-bit userland if that's
of any particular help.
--
gcc at futurenotfound dot com ch
Try these commands:
$ echo 'int main(void) { return 0;}' > xx.c
$ gcc -o '' xx.c
And if you have permission to remove /path/to/crtX.o, it will be removed,
because gcc uses that as the output file.
Although it is illegal to call gcc with an empty output filename,
it really should not break any fur
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-04 15:47 ---
Note: NAG f95 has the error:
Error: foo.f90, line 7: IMPLICIT setting for letter C changed after use in
TEST
Errors in declarations, no further processing for TEST
I think strictly speaking, NAG f95 is right.
With
The function move_by_pieces in expr.c enters to endless loop when the backend
defines the sizes of all data types to be the same size (aka CHAR_TYPE_SIZE
= SHORT_TYPE_SIZE = INT_TYPE_SIZE = anyvalue
).
The loop itself occurs in this code section -
while (max_size > 1)
{
fo
--- Comment #7 from pault at gcc dot gnu dot org 2007-04-04 16:15 ---
Created an attachment (id=13328)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13328&action=view)
A better fix for the PR
This version of the patch has been moved to expr.c. It seems that PR29507,
PR31211 and P
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |middle-end
h
A program with an empty CONTAINS block is illegal, but gfortran accepts it:
PROGRAM test197
CONTAINS
END PROGRAM test197
--
Summary: A program with an empty CONTAINS block is illegal, but
gfortran accepts it
Product: gcc
Version: unknown
Hello,
I think there is a little problem under gcc ! It seems that gcc thinks
that a code block will never be reach and so do not generate its code,
but it's wrong :
-- test.c START --
void foo_printf(char *str)
{
}
int foo()
{
//assembly for sys_clone()
asm volatile (
"xor %ebx,
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-04 17:35 ---
> A program with an empty CONTAINS block is illegal
Well, this is a matter of arguments. It is invalid in Fortran 90, 95 and 2003.
But it is allowed in the current draft for Fortran 2008.
Therefore, we decided to al
In the following program FORALL is labeled and END FORALL is unlabeled, but
gfortran accepts it:
PROGRAM test200
DIMENSION j(2)
label:FORALL (i = 1:2)
j(i) = 0
END FORALL
END PROGRAM test200
--
Summary: gfortran does not detect a labeled FORALL with an
unlabeled
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-04 17:39 ---
Confirm. If one uses DO or uses a wrong label, gfortran works correctly.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #12 from patchapp at dberlin dot org 2007-04-04 17:40 ---
Subject: Bug number PR 29365
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-04/msg00140.html
--
http://gcc.gnu.org/bugzilla/
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-04 17:41 ---
C732 (R758) If the forall-construct-stmt has a forall-construct-name, the
end-forall-stmt shall have the same forall-construct-name. If the
end-forall-stmt has a forall-construct-name, the forall-construct-stmt shall
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-04 17:48 ---
>From the standard:
"5.2.9 PARAMETER statement
[...]
The named constant shall have its type, type parameters, and shape specified in
a prior specification of the specification-part or declared implicitly (5.3).
If the
gfortran does not detect the illegal use of an access specification in a
program, subroutine, or function:
PROGRAM test211
PRIVATE i
END
--
Summary: gfortran does not detect the illegal use of an access
specification in a program, subroutine, or function
gfortran does not detect duplicate EXTERNAL or INTRINSIC declarations:
SUBROUTINE test217
EXTERNAL test217a
EXTERNAL test217a
END
SUBROUTINE test218
INTRINSIC abs
INTRINSIC abs
END
--
Summary: gfortran does not detect duplicate EXTERNAL or INTRINSIC
declarations
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-04 18:47 ---
Accepted. Thanks for the report.
We do check for this but only for the PRIVATE/PUBLIC attribute and not for the
PUBLIC/PRIVATE statement.
Patch:
Index: gcc/fortran/decl.c
===
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-04 18:57 ---
Confirmed. Thanks for the report.
gfc_add_external and gfc_add_intrinsic do actually the right thing. However,
they are not used in decl.c's gfc_match_external:
gfc_clear_attr (¤t_attr);
current_attr.external =
--- Comment #5 from brooks at gcc dot gnu dot org 2007-04-04 19:10 ---
Subject: Bug 31353
Author: brooks
Date: Wed Apr 4 19:10:17 2007
New Revision: 123498
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123498
Log:
PR other/31353
* gcc.c (main): Do not run the linker if
print_s
--- Comment #3 from brooks at gcc dot gnu dot org 2007-04-04 19:17 ---
Subject: Bug 31356
Author: brooks
Date: Wed Apr 4 19:17:30 2007
New Revision: 123499
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123499
Log:
PR other/31356
* gcc.c (print_specific_help): Fix --help=
heade
--- Comment #6 from brooks at gcc dot gnu dot org 2007-04-04 19:24 ---
Fixed, as per the above commit.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from brooks at gcc dot gnu dot org 2007-04-04 19:24 ---
Fixed, as per the above commit.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from brooks at gcc dot gnu dot org 2007-04-04 19:32 ---
Fixed in svn 123497:
(http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123497)
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from stuart at gcc dot gnu dot org 2007-04-04 19:37 ---
Subject: Bug 31281
Author: stuart
Date: Wed Apr 4 19:37:14 2007
New Revision: 123501
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123501
Log:
PR 31281
* objc/objc-act.c (next_sjlj_build_cat
When I compile the module listed below, gfortran produces the message:
c1.f90:14.18:
ENTRY cx_radc(r, z)
1
Internal Error at (1):
insert_bbt(): Duplicate key found!
MODULE complex
TYPE cx
REAL :: real, imag
END TYPE cx
INTERFACE OPERATOR (+)
[EMAIL PROTECTED] test]$ g++ vCard-all.c
In file included from vCard-all.cpp:37:
AgentParam.cpp: In member function ‘virtual void
VCARD::AgentParam::_parse()’:
AgentParam.cpp:90: internal compiler error: in convert_memory_address, at
explow.c:319
Please submit a full bug report,
with preprocessed s
--- Comment #1 from arekm at pld-linux dot org 2007-04-04 20:11 ---
Created an attachment (id=13329)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13329&action=view)
problematic source (kdelibs 3.5.x)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31475
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c++ |middle-end
h
--- Comment #3 from valerie dot vallet at univ-lille1 dot fr 2007-04-04
20:39 ---
The problem occured with gcc-4.2.0 but it is solved with gcc-4.3.0. The bug can
be closed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31467
--- Comment #4 from valerie dot vallet at univ-lille1 dot fr 2007-04-04
20:40 ---
The problem occurred with gcc-4.2.0 but it is solved with installation of
gcc-4.3.0. The bug can be closed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31467
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-04 20:47 ---
The problem seems to occur with procedure pointers to ENTRY points
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
---
the following do not work when compiling using gcc
char b = 0010b;
changing it to
char b = 0b0010;
still don't work I get instead
invalid suffix "b" on integer constant
Sometime it is trivial to just use a binary representation of constant rather
than an hexadecimal or octal representa
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-04 22:51 ---
The reason why GCC does not have this feature is because it is a non standard
feature and GCC just has not implemented it yet.
Anyways this is the same as PR 23479.
*** This bug has been marked as a duplicate of 23
--- Comment #23 from pinskia at gcc dot gnu dot org 2007-04-04 22:51
---
*** Bug 31476 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from rth at gcc dot gnu dot org 2007-04-04 23:11 ---
Subject: Bug 31361
Author: rth
Date: Wed Apr 4 23:11:30 2007
New Revision: 123504
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123504
Log:
PR target/31361
* config/i386/i386.c (ix86_init_mmx_s
--- Comment #8 from rth at gcc dot gnu dot org 2007-04-04 23:13 ---
Subject: Bug 31361
Author: rth
Date: Wed Apr 4 23:13:13 2007
New Revision: 123505
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123505
Log:
PR target/31361
* config/i386/i386.c (ix86_init_mmx_s
At least some of the trapping arithmetic routines (__absvsi2, etc), are
being compiled *without* the abort that would, in general, be required.
These routines are falling foul of the signed-arithmetic-doesn't-overflow
coding trap. We need to either compile them with -fwrapv, or rewrite
them to us
--- Comment #1 from eweddington at cso dot atmel dot com 2007-04-04 23:46
---
Confirmed on 4.1.1.
Please add wrong-code to Keyword list.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30289
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-05 00:08 ---
An even better idea is to have them being called with simple programs :).
See PR 19020 for that issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31477
--- Comment #1 from danglin at gcc dot gnu dot org 2007-04-05 00:25 ---
It appears to me that there is extraneous whitespace in LD_LIBRARY_PATH.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31369
--- Comment #2 from danglin at gcc dot gnu dot org 2007-04-05 01:15 ---
I think the fails were introduced by the following change:
2007-03-18 Uros Bizjak <[EMAIL PROTECTED]>
* testsuite/config/default.exp: New file.
...
--
danglin at gcc dot gnu dot org changed:
There are
(define_insn "sse2_umulv2siv2di3"
[(set (match_operand:V2DI 0 "register_operand" "=x")
(mult:V2DI
(zero_extend:V2DI
(vec_select:V2SI
(match_operand:V4SI 1 "nonimmediate_operand" "%0")
(parallel [(const_int 0) (const_int 2)])))
--- Comment #16 from mrs at apple dot com 2007-04-05 02:52 ---
I think this patch breaks:
FAIL: g++.old-deja/g++.mike/p4736b.C (internal compiler error)
FAIL: g++.old-deja/g++.mike/p4736b.C (test for excess errors)
on powerpc-apple-darwin:
/Volumes/mrs3/net/gcc-4.2-fsf/gcc/gcc/tes
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
CC|doug dot gregor at gmail dot|
|com |
AssignedTo
GCC 4.2.0 is unable to compile STLport due to a header conflict.
When compiling any C++ program that includes :
In file included from
c:/aaronwl/gcc/root/bin/../lib/gcc/i686-pc-mingw32/4.2.0/../../../../include/c++/4.2.0/../4.2.0/cmath:52,
from /aaronwl/stlport/STLport-5.1.3/stlp
An sh-linux targeted gcc generates:
mm.i: In function mmtree_RB_REMOVE_COLOR:
mm.i:36: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
when compiling with:
sh-l
--- Comment #1 from aaronavay62 at aaronwl dot com 2007-04-05 05:34 ---
OK, mainline just uses an 'int' here instead of 'streamsize.' Also, N1822 just
has 'int.' Why is 'streamsize' here?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31481
--- Comment #2 from fang at csl dot cornell dot edu 2007-04-05 06:11
---
PR 2708 dup?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30734
--- Comment #3 from ubizjak at gmail dot com 2007-04-05 06:38 ---
Perhaps hppa64 needs the same change to libgomp.exp as in
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01497.html ?
These tests all fail because shared libgcc library is not found.
--
ubizjak at gmail dot com changed:
--- Comment #2 from fang at csl dot cornell dot edu 2007-04-05 06:46
---
same as recent c++ issue PR 31453 tripped in testsuite?
--
fang at csl dot cornell dot edu changed:
What|Removed |Added
--
M32C C-compiler 4.2.0 stop with this error:
ctest.c: In function 'Modbus_Frekvens_Init':
ctest.c:44: error: could not split insn
(insn 50 49 59 (set (mem/c:QI (plus:PSI (reg/f:PSI 7 fb)
(const_int -2 [0xfffe])) [0 card+0 S1 A8])
(if_then_else:QI (ne:QI (reg:HI 0 r0 [27]
--- Comment #1 from ubizjak at gmail dot com 2007-04-05 07:15 ---
(In reply to comment #0)
> 1. Is ix86_binary_operator_ok needed here?
Yes, it prevents expander and combiner to create two mem operands (please note
that reload can also resolve this case by itself, but some CSE opportun
--- Comment #2 from hjl at lucon dot org 2007-04-05 07:35 ---
(In reply to comment #1)
> (In reply to comment #0)
>
> > 1. Is ix86_binary_operator_ok needed here?
>
> Yes, it prevents expander and combiner to create two mem operands (please note
> that reload can also resolve this case
72 matches
Mail list logo