--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-19
06:10 ---
This is still a bad bug which should be fixed for 4.0.1 at least.
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From wilson at gcc dot gnu dot org 2005-04-19
06:22 ---
The reload patch seems reasonable, though not very satisfying. It is only
disabling some optimizations within reload, and hence should be somewhat safe.
Though it is still a reload patch, and all reload
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-19
06:54 ---
The problem has resurfaced on mainline:
http://gcc.gnu.org/ml/gcc/2005-04/msg01052.html
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-19
07:07 ---
Subject: Bug 21098
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-19 07:07:11
Modified files:
gcc: ChangeLog
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-19
07:10 ---
Subject: Bug 16861
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-19 07:10:06
Modified files:
gcc/fortran: ChangeLog resolve.c
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-19
07:24 ---
Like comment #5 says, this one is not fixed. The patch I committed only adress
part of the issue. Removed patch keyword accordingly.
--
What|Removed |Added
ICE on gcc 4.0.0rc2, but works on both 3.3.5 and 3.4.3.
$ /usr/local/gcc-4.0/bin/g++ -c -O -mmmx 1.cpp
1.cpp: In function 'void f()':
1.cpp:51: internal compiler error: in simplify_subreg, at simplify-rtx.c:3729
--
Summary: ICE on mmx intrinsics
Product: gcc
--- Additional Comments From jochang at gmail dot com 2005-04-19 08:05
---
Created an attachment (id=8680)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8680action=view)
the test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21099
ICE on gcc 4.0.0rc2, but both 3.3.5 and 3.4.3 work.
No ICE if change pentium-mmx to pentium2.
$ /usr/local/gcc-4.0/bin/g++ -c -march=pentium-mmx 2.cpp
2.cpp: In function 'void f()':
2.cpp:30: error: unrecognizable insn:
(insn 13 12 14 0 (set (mem/i:V2SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S8 A64])
--- Additional Comments From jochang at gmail dot com 2005-04-19 09:05
---
Created an attachment (id=8681)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8681action=view)
the test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21100
--- Additional Comments From carlos at mind dot be 2005-04-19 09:49 ---
Subject: Re: -many flag causes problems
On Tuesday 19 April 2005 01:34, amodra at bigpond dot net dot au wrote:
--- Additional Comments From amodra at bigpond dot net dot au
2005-04-18 23:34 --- Please
--- Additional Comments From giovannibajo at libero dot it 2005-04-19
09:59 ---
Will be fixed by this patch for PR 19126:
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01959.html
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-04-19
10:03 ---
Eric, if you confirm that this bug is fixed in 3.3 and 3.4, then this is a
(latent) regression on mainline and 4.0.
--
What|Removed |Added
--
What|Removed |Added
Attachment #8681|text/x-c++src |text/plain
mime type||
--- Additional Comments From giovannibajo at libero dot it 2005-04-19
10:06 ---
it might be a typo in the MMX/SSE cleanup...
--
What|Removed |Added
CC|
ICE on gcc 4.0.0rc2, but both 3.3.5 and 3.4.3 work.
$ /usr/local/gcc-4.0/bin/g++ -c -O2 -funroll-loops -march=pentium4 3.cpp
3.cpp: In function 'void f()':
3.cpp:29: error: could not find a spill register
(insn:HI 95 94 96 0 (set (reg:V4HI 29 mm0 [orig:115 D.2920 ] [115])
--- Additional Comments From jochang at gmail dot com 2005-04-19 10:15
---
Created an attachment (id=8683)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8683action=view)
the test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21101
--- Additional Comments From chris at bubblescope dot net 2005-04-19 10:19
---
Yup, just checked the standard, and it agrees with the code (not the comment).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21035
ICE on gcc 4.0.0rc2, but both 3.3.5 and 3.4.3 work.
$ /usr/local/gcc-4.0/bin/g++ -c -O -msse2 4.cpp
4.cpp: In function 'void f()':
4.cpp:10: internal compiler error: in immed_double_const, at emit-rtl.c:467
Here is the source:
#include emmintrin.h
__m128i S;
void f()
{
__m128i A;
A =
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-19
10:52 ---
Subject: Bug 21064
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-19 10:52:04
Modified files:
libjava: ChangeLog
Compiling following code:
program chk
character*8 a
a = 'a string'
end
with gfortran and the -fdump-tree-generic induces a segfault:
Program received signal SIGSEGV, Segmentation fault.
0x0857af51 in dump_function_to_file (fn=0xb7ad6438, file=0x87ce8b8, flags=512)
at
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-19
11:43 ---
Subject: Bug 21096
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-19 11:43:24
Modified files:
gcc: ChangeLog tree-ssa-copy.c
Log
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-19 11:44
---
Just checked in a patch.
--
What|Removed |Added
Status|NEW
The following reduced program causes a segmentation fault at runtime. It runs
correctly if the *x on line 11 is removed. From this, I would surmise that
something is not right with the allocation of space for the temporary. Further
simplification of the structure of the program eliminates
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-19
12:04 ---
*** Bug 21103 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-19
12:04 ---
*** This bug has been marked as a duplicate of 21049 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-19
12:21 ---
I don't think this is correct code. See PR 20960. Yes ICC does not seg fault
on it. I will note that XLC
does the same thing as gfortran.
I also think this is a dup of bug 18197.
--
--- Additional Comments From aph at gcc dot gnu dot org 2005-04-19 12:33
---
Should be fixed by
2005-04-18 Andrew Haley [EMAIL PROTECTED]
* java-except.h (struct eh_range.handler): Remove unused field.
(handle_nested_ranges): Remove function declaration.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
Compiling
void
foo ()
{
float c[20480][4];
}
fails with
t3.c: In function 'foo':
t3.c:16: internal compiler error: in tree_low_cst, at tree.c:3846
All current CVS versions (4.X fail).
At least some 3.x versions are not affected
GCC 2.96 shows an other error.
Affected Versions, which I
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-19
13:08 ---
Confirmed, this is most likely caused by the tree-ssa merge.
--
What|Removed |Added
The dwarf2 output for a type attribute for an array fails.
Eg:
$cat x.c
typedef unsigned char GROUP9_T[3];
typedef GROUP9_T EGROUP9_T __attribute ((eeprom));
$./cc1 --version
GNU C version 4.1.0 20050416 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0 20050302
--- Additional Comments From aph at gcc dot gnu dot org 2005-04-19 13:26
---
See http://gcc.gnu.org/ml/gcc/2005-04/msg01068.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21022
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-04-19
13:31 ---
Subject: Re: Segmentation fault on correct code
--- Additional Comments From pinskia at gcc dot gnu dot org
2005-04-19 12:21 ---
I don't think this is correct code. See PR 20960. Yes ICC
--- Additional Comments From bangerth at dealii dot org 2005-04-19 14:08
---
Why? This code as always wrong. It has nothing to do with gcc3.4.x.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17445
If Pmode is smaller than the HOST_BITS_PER_WIDE_INT (ie for i686 as host all
targets, which use HImode or QImode as Pmode), a stack overflow produce the
following internal compiler error:
$./cc1 t4.c
check1972
/homes/mkoegler/m68hc05/src/host-i686-pc-linux-gnu/gcc/test/t4.c: In function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-19
14:47 ---
/* If this fails, we've overflowed the stack frame. Error nicely? */
gcc_assert (offset == trunc_int_for_mode (offset, Pmode));
Hmm, I wonder if this is a regression or not.
--
What
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-19
14:53 ---
Confirmed on i386-linux.
Same thing happens without -fdefault-integer-8 on:
character(len=6_8) hed, final
data final /'foo'/
data hed /'bar'/
if (hed == final) call abort
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-19
14:53 ---
Exactly the same segfault happens without -fdefault-integer-8 on:
character(len=8_8) a
a = '12345678'
end
Using a integer(8) as length for a string is broken, and that's why
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-19
14:53 ---
I am no longer working on this.
--
What|Removed |Added
AssignedTo|pinskia at gcc
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-19
14:53 ---
*** Bug 21083 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-19
14:54 ---
I am no longer working on this.
--
What|Removed |Added
AssignedTo|pinskia at gcc
--- Additional Comments From phython at gcc dot gnu dot org 2005-04-19
14:57 ---
Yup, the dumps from the c++ front end is:
;; Function size_t f(size_t, size_t) (_Z1fjj)
size_t f(size_t, size_t) (b, c)
{
bb 0:
return (size_t) (((int) a[b] - (int) a[c]) /[ex] 4);
}
and the C
--- Additional Comments From sebor at roguewave dot com 2005-04-19 15:39
---
I discussed this with Mike Miller of EDG. His response to my query on the issue
(copied with his permission) is below.
Mike Miller wrote:
...
There were a couple of different examples in that thread,
so
--- Additional Comments From sebor at roguewave dot com 2005-04-19 15:41
---
Here's a followup email from Mike with some calarifying comments:
Mike Miller wrote:
Martin Sebor wrote:
Thanks a lot for the detailed analysis! I wonder if your reasoning
would be the same given a
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-19
15:43 ---
Subject: Bug 21022
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-19 15:43:00
Modified files:
gcc: dbxout.c ChangeLog
Log message:
--
What|Removed |Added
CC||ericw at evcohs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
--
What|Removed |Added
CC||ericw at evcohs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21078
--- Additional Comments From ericw at evcohs dot com 2005-04-19 15:49
---
Björn,
That sounds like a reasonable approach. Submit a bug report to the avr-libc
project on Savannah:
http://savannah.nongnu.org/projects/avr-libc/
Eric
--
What|Removed
--
What|Removed |Added
CC||ericw at evcohs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21107
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-19
16:15 ---
Further reduced testcase:
module perdida_m
contains
subroutine perdida (z, x)
real, dimension (:) :: x, z
z = generalized_hookes_law (x) + 1.0
end subroutine perdida
function
--- Additional Comments From rth at gcc dot gnu dot org 2005-04-19 16:21
---
When, exactly, did you think that cmpxchg was added? Use -march=i486. Duh.
--
What|Removed |Added
--- Additional Comments From hjl at lucon dot org 2005-04-19 16:28 ---
But there is no __sync_bool_compare_and_swap_4 in source code.
If it isn't available, shouldn't gcc leave __sync_bool_compare_and_swap
alone.
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--- Additional Comments From matz at suse dot de 2005-04-19 16:51 ---
I agree with most of what Jim said. Except for the part that we maybe don't
have to fix the reload issue, when we fix usage of the uninitialized register
for piecewise struct initialization. The latter will fix
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-19
17:08 ---
Subject: [PR target/16888] clear reg names of unavailable regs
We used to crash at print_operand time, because the register asm
variable named a REX register, not available in 32-bit mode.
This patch
--- Additional Comments From andreast at gcc dot gnu dot org 2005-04-19
17:53 ---
Completed a build of HEAD with awt-gtk enabled on darwin7.9.
Thanks!
I run now a build on 4.0, even if we may not get this fix in for 4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21022
--- Additional Comments From law at redhat dot com 2005-04-19 17:59 ---
An update. The jump threading changes are blocked pending resolution of
a semi-latent bug in reload which is exposed by the combination of the
jump threading changes plus the recent merges from TCB.
I'm testing a
--- Additional Comments From bangerth at dealii dot org 2005-04-19 18:25
---
Martin Mike,
I'm happy to reopen this PR. I understand your analysis, and in fact thought
about it when I wrote my comment. Independently of whether it may be strictly
mandated by the standard, I do have to
--
What|Removed |Added
Component|java|debug
Summary|ICE while compiling |[4.0 only] ICE while
--- Additional Comments From tobi at gcc dot gnu dot org 2005-04-19 18:34
---
Probably the right way to solve this is to call the code in c-ppoutput.c from
the Fortran frontend.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-19
18:51 ---
descriptor.offset (in the front end) aka descriptor-base
in the library is currently useless.
Look at this:
$ cat offset.f90
program main
real :: a(2,2)
real, allocatable :: b(:,:)
real, pointer ::
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-19
19:23 ---
(In reply to comment #3)
Further reduced testcase:
Lahey/Fujitsu Fortran 95 Source Check Output
I think everyone should read
http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html#6 which David E.
send me to
--- Additional Comments From rth at gcc dot gnu dot org 2005-04-19 19:34
---
No, because __sync_bool_compare_and_swap is overloaded.
This expansion to __sync_bool_compare_and_swap_N is documented.
--
What|Removed |Added
--- Additional Comments From tsv at solvo dot ru 2005-04-19 19:38 ---
I was able to fix the problem by applying the following patch:
--- gcc-3.4.3-20050222/boehm-gc/include/private/gcconfig.h.orig 2005-04-19
19:40:06.0 +0400
+++
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-19
19:40 ---
Then this is fixed for 3.4.4 and above by the following patch (which does the
same):
2005-04-11 Richard Henderson [EMAIL PROTECTED]
* include/private/gcconfig.h (alpha-linux): Use
--
What|Removed |Added
Keywords||wrong-debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21016
--
What|Removed |Added
Component|debug |middle-end
Keywords||ice-on-valid-code
Summary|internal
--
What|Removed |Added
Keywords||ice-on-valid-code, ssemmx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21102
--
What|Removed |Added
Keywords||ice-on-valid-code, ssemmx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21101
--
What|Removed |Added
Keywords|rejects-valid |ice-on-valid-code, ssemmx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21100
--
What|Removed |Added
Keywords||ice-on-valid-code, ssemmx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21099
--
What|Removed |Added
Summary|.note.GNU-stack emitted |[3.4/4.0 only] .note.GNU-
||stack emitted
Target
--- Additional Comments From tsv at solvo dot ru 2005-04-19 19:57 ---
(In reply to comment #4)
Then this is fixed for 3.4.4 and above by the following patch (which does the
same):
2005-04-11 Richard Henderson [EMAIL PROTECTED]
* include/private/gcconfig.h (alpha-linux):
--- Additional Comments From wanderer at rsu dot ru 2005-04-19 20:08
---
Proposed patch (in #4) work fine at FreeBSD 5.1
And fix my tescase variant:
__inline void f(int a)
{
int i;
if (a 0) {
for (i = 0, a = ~a; a; i++) {
if ((a 1) != 0) {
f(i);
}
}
--- Additional Comments From wilson at gcc dot gnu dot org 2005-04-19
20:09 ---
This is due to an internal implementation detail. The -Wl options are handled
by pretending that the argument to the -Wl option is an object file name. This
works because the only thing we do with object
Configured with: ../gcc-4.1/configure --enable-languages=c,f95
--prefix=/home/ig25
Thread model: posix
gcc version 4.1.0 20050419 (experimental)
Reshape is trickier than I thought, apparently.
--
Summary: reshape with order causes memory corruption
Product: gcc
Current mainline fails to bootstrap with this error while linking libgcj.la:
`.L_ZN4java4util7logging6Logger7getNameEv13' referenced in section `.data.rel'
of ./.libs/libgcj0_convenience.a(Logger.o): defined in discarded section
The documentation in rtl.texi for the HIGH and LO_SUM operators incorrectly say
that they should use Pmode. There is no such restriction. They can be used
with any mode. Pmode is only necessary if the operand is an address, such as a
SYMBOL_REF or a LABEL_REF. The text will need some rewording
--- Additional Comments From andreast at gcc dot gnu dot org 2005-04-19
20:26 ---
Add on, a full bootstrap on 4.0 branch with the following config completed
successfully:
/Volumes/src/gcc/gcc-4.0-branch/gcc/configure
--prefix=/Volumes/src/gcc/gcc-4.0-branch/testbin
Because of the decomposition of structures in tree-ssa, the middle end is
emitting RTL code that can read uninitialized registers. On IA-64, this can
result in a NaT consumption fault if the uninitialized register has its NaT bit
set.
Before tree-ssa, we would have had a constructor, and
--- Additional Comments From wilson at gcc dot gnu dot org 2005-04-19
20:41 ---
Created an attachment (id=8684)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8684action=view)
synthetic IA-64 testcase to generate NaT consumption fault
Compile this with -O, and it will fail with
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-19
20:47 ---
To me, the target specific code should be the one to fix this problem up and
not the middle-end or at
least have a hook for it so you don't mess around with other targets getting
the speed up. Anyways
The Xassembler and Xpreprocessor options don't work. They accidentally pass
options to the linker in addition to the assembler and preprocessor.
For example, on linux, the assembler ignores the -D option, but the linker does
not. If I try using -Xassembler to pass the -D option to the
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-19
20:54 ---
Confirmed. -Xassebler did not exist in 3.3.3 but -Xpreprocessor did and works
as expected.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-19
20:57 ---
*** This bug has been marked as a duplicate of 21070 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-19
20:57 ---
*** Bug 21109 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
Jumps into the scope of an identifier with variably modified type (with goto or
switch) are not rejected by the C++ front end. Bug 12913 describes this problem
for C, but there should be a separate bug for C++ since bug 16989 only depends
on the issue being fixed for C and not for C++. The
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bothner at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-19
21:45 ---
Subject: [PR c++/21087] don't keep builtin anticipated decl, override it with
actual declaration
When push_overloaded_decl() was passed a new declaration that matches
a builtin decl, it would verify that
In functions utilising varargs gcc generates the below prologue, which
unfortunately results in movaps operating on a non 16byte aligned memory
address. In this particular case we should either be ensuring alignment on the
stack variable, or using movups. I have reason to believe, from discussion
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-19
21:56 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
-exceptions --disable-version-specific-runtime-lib
s --disable-win32-registry
Thread model: posix
gcc version 4.1.0 20050419 (experimental)
on the other hand I have tried to compile same file by the gcc that is
distributes with cygwin, I works.
the problem I report disappears.
here is the version
This is reduced from the eclipse problem I was seeing.
Compile the following Test.java with gcj --main=Test Test.java
public abstract class Test
{
public static void main(String[] args) throws Exception
{
Class c = Class.forName(Invoke);
Object o = c.newInstance();
Test t = (Test)
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-phiopt.c.diff?r1=2.25r2=2.26only_with_tag=MAIN
- if (EDGE_COUNT (bb1-succs) 1
+ if (!single_succ_p (bb1) 1
We don't need 1.
--
Summary: tree-ssa-phiopt.c:193 has wrong translation from
EDGE_COUNT
--- Additional Comments From daney at gcc dot gnu dot org 2005-04-19 22:55
---
Replacing Test.java with this seems to work:
import java.lang.reflect.*;
public abstract class Test
{
public static void main(String[] args) throws Exception
{
Class c = Class.forName(Invoke);
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu
|dot org |
Status|UNCONFIRMED
--- Additional Comments From wilson at specifixinc dot com 2005-04-19
23:05 ---
Subject: Re: IA-64 NaT consumption faults due to uninitialized
register reads
pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-19
20:47
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-19
23:28 ---
This is a regression.
--
What|Removed |Added
CC|
1 - 100 of 304 matches
Mail list logo
