--- Comment #20 from uros at kss-loka dot si 2006-06-26 06:31 ---
(In reply to comment #15)
Can someone tell me if anyone is looking into this problem with the hopes of
fixing it? I just noticed that despite the posted code demonstrating the
problem, and verification on: Pentium
Here's another ICE, probably related to temporary character arrays:
gfcbug34.f90: In function 'MAIN__':
gfcbug34.f90:1: internal compiler error: in fold_binary, at fold-const.c:8239
It dies on:
call foo ( (/ (' ',i=1,m) /) )
Testcase attached.
Cheers,
-ha
--
Summary: ICE: in
--- Comment #1 from anlauf at gmx dot de 2006-06-26 07:53 ---
Created an attachment (id=11755)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11755action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28167
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-06-26 08:24 ---
Confirmed. We end up in gfc_trans_create_temp_array
size = fold_build2 (MULT_EXPR, gfc_array_index_type, size,
TYPE_SIZE_UNIT (gfc_get_element_type (type)));
with type being a
--- Comment #2 from aph at gcc dot gnu dot org 2006-06-26 09:45 ---
Thank you for this patch.
It seems to be a patch for the core constant folding code. Would it not be
more
appropriate to do this in the Java front end's function convert() (in
java/typeck.c) ?
--
--- Comment #3 from joern dot rennecke at st dot com 2006-06-26 11:19
---
Subject: Re: floating point constant - byte/char/short conversion is wrong
for java
aph at gcc dot gnu dot org wrote:
--- Comment #2 from aph at gcc dot gnu dot org 2006-06-26 09:45 ---
Thank you for
This is totally unexpected (for me atleastÂ…) behaviour I encountered in C++. I
was using g++ version 3.4.2 (DevC++)
class Base{
public:
Base() { cout Base ctor... endl; }
virtual ~Base() { cout ~Base called... endl; }
virtual void Show() const
{
cout
--- Comment #7 from danglin at gcc dot gnu dot org 2006-06-26 13:45 ---
This test is still failing on hppa64-hp-hpux11.11.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-26
13:47 ---
Subject: Re: [4.1 Regression] inliner introduces unnecessary type conversions
Attached dump.
Dave
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-26
13:47 ---
Created an
--- Comment #2 from corsepiu at gcc dot gnu dot org 2006-06-26 14:34
---
# m68k-rtems4.7-gcc --target-help
Target specific options:
cc1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #21 from whaley at cs dot utsa dot edu 2006-06-26 15:03 ---
Uros,
Thanks for the reply; I think some confusion has set in (see below) :)
And the results are a bit suprising (this is the exact output of your test):
Note that you are running the opposite of my test case:
--- Comment #10 from pinskia at gmail dot com 2006-06-26 16:02 ---
Subject: Re: [4.1 Regression] inliner introduces unnecessary type conversions
On Jun 26, 2006, at 6:45 AM, danglin at gcc dot gnu dot org wrote:
--- Comment #7 from danglin at gcc dot gnu dot org 2006-06-26
--- Comment #3 from corsepiu at gcc dot gnu dot org 2006-06-26 16:41
---
Traceback:
Program received signal SIGSEGV, Segmentation fault.
print_filtered_help (flag=4194304) at ../../gcc-4.1.1/gcc/opts.c:1301
(gdb) where
#0 print_filtered_help (flag=4194304) at
On Jun 26, 2006, at 9:41 AM, corsepiu at gcc dot gnu dot org wrote:
--- Comment #3 from corsepiu at gcc dot gnu dot org 2006-06-26
16:41 ---
Traceback:
= the SEGFAULT occurs in memset.
Could it be, static char* printed should be initialized = 0?
Looks like reload is storing
--- Comment #4 from pinskia at physics dot uc dot edu 2006-06-26 16:46
---
Subject: Re: Target Help Seg Fault.
On Jun 26, 2006, at 9:41 AM, corsepiu at gcc dot gnu dot org wrote:
--- Comment #3 from corsepiu at gcc dot gnu dot org 2006-06-26
16:41 ---
Traceback:
=
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
GCC target
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-26 16:48 ---
PR 25636 was the 4.2.0 bug and the patch there should fix it if someone
backports it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from corsepiu at gcc dot gnu dot org 2006-06-26 17:01
---
(In reply to comment #5)
PR 25636 was the 4.2.0 bug and the patch there should fix it if someone
backports it.
For the record, the compiler exposing this is FC5's gcc-4.1.1-1.fc5
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-06-26 17:06 ---
(In reply to comment #6)
For the record, the compiler exposing this is FC5's gcc-4.1.1-1.fc5
For the record, that is not a FSF release so it should be reported directly to
Redhat.
--
--- Comment #1 from tromey at gcc dot gnu dot org 2006-06-26 17:22 ---
Does the JDK's javah put that _ into the generated header?
I suspect that you are seeing a problem with the C compiler, not a problem
with JNI header generation.
In particular I think that _, most likely, should be
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-26 18:16 ---
Here is what is happening currently with GCC:
Base ctor...
Derived ctor...
Base copy ctor...
~Derived called...
~Base called...
Base show called...
~Base called...
So you missed the copy constructor, now I don't
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-26 18:18 ---
Note ICC produces:
Base ctor...
Derived ctor...
~Derived called...
~Base called...
Base show called...
which might be just as bad.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28169
A simple byte swap routine gets the wrong result when compiled with -m64 and
either -O1, -O2, -O3 or -Os.
[EMAIL PROTECTED]:~ /opt/biarch/gcc41-base/bin/gcc -O1 -m64 badswap.c
[EMAIL PROTECTED]:~ ./a.out
Before: 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88
Result: 0x88 0x77 0x66 0x55
--- Comment #1 from bergner at vnet dot ibm dot com 2006-06-26 18:42
---
Created an attachment (id=11758)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11758action=view)
Simple test case to show the problem.
The bad code generation is in change_byte_order().
--
--- Comment #2 from bergner at vnet dot ibm dot com 2006-06-26 18:44
---
Forgot to mention this fails on both the 4.1 branch and mainline. It does work
with 3.4 and earlier versions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
RUN cd5003h
/home/dave/gcc-4.2/objdir/gcc/xgcc -c -B/home/dave/gcc-4.2/objdir/gcc/ -gnatws
-
O2 -I/home/dave/gcc-4.2/objdir/gcc/testsuite/ada/acats/support cd5003h.adb
/home/dave/gcc-4.2/objdir/gcc/xgcc -c -B/home/dave/gcc-4.2/objdir/gcc/ -gnatws
-
O2
--- Comment #3 from bergner at vnet dot ibm dot com 2006-06-26 18:49
---
Janis performed a regression hunt on mainline and identified this patch as the
start of the test failure:
r83568 | dje | 2004-06-23 21:19:00 + (Wed, 23 Jun 2004) | 7 lines
* config/rs6000/rs6000.c
--- Comment #4 from dje at gcc dot gnu dot org 2006-06-26 18:51 ---
This appears to be a problem in the insvdi_internal2 and insvdi_internal3
combiner patterns.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-06-26 18:54 ---
One thing we have is some extra virtual operands from CCP:
before:
bb 2:
mask_5 = old;
v_7 = mask_6;
# SFT.2_33 = V_MAY_DEF SFT.2_32;
*mask_5 = *v_7;
mask_8 = mask_6;
v_10 = v_9;
i_11 = 0;
goto bb 4 (L4);
--- Comment #5 from ramana dot radhakrishnan at codito dot com 2006-06-26
19:13 ---
This should be reopened. A related testcase shows a regression from 3.4.6 to
4.1.1 for m68k-elf shows a regression . combine used to take care of this in
3.4.6 . A backport of the patch is ready with
[EMAIL PROTECTED]:~ cat t.f90
program blubb
call otherini(*998)
stop
998 stop
contains
subroutine init
call otherini(*999)
return
999 stop
end subroutine init
end program blubb
[EMAIL PROTECTED]:~ ~/src/gcc/build/stage3-gcc/f951 t.f90
MAIN__ init
t.f90:6: internal compiler error:
A performance regression from 3.4.6 to 4.1.1 for m68k-elf.
combine used to take care of this in 3.4.6 .
A backport of the patch for Bug #24427 works . If its allowed, I'll put it up
.
This is the test case .
#include stdio.h
int i;
int main (void)
{
if ( ((i ~1) | 1) != ( i |
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-26 20:10 ---
As an aside, I think we should produce two lwbrx instead and then combine them
for the double word (or ldbrx which only exists on Cell as far as I know) But
that is not here or there for this problem right now.
--
--- Comment #1 from seongbae dot park at gmail dot com 2006-06-26 20:46
---
I belive this is a bug in stor-layout.c:place_field() around line 10503
bitpos is calculated as bit_offset of rli-prev_field + type size.
However, the prev_field is not really the immediately previous field but
--- Comment #2 from seongbae dot park at gmail dot com 2006-06-26 20:47
---
Oops. Mu previous comment is misplaced. It should have been on PR28161.
Please ignore it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28160
--- Comment #1 from seongbae dot park at gmail dot com 2006-06-26 20:47
---
I belive this is a bug in stor-layout.c:place_field() around line 10503
bitpos is calculated as bit_offset of rli-prev_field + type size.
However, the prev_field is not really the immediately previous field but
Here's a very strange example of data corruption when passing
a character array section in the form
call foo (a(:)(7:11))
to a subroutine even if the parameter is declared as INTENT(IN).
Furthermore, even another array gets corrupted which is intended
to hold a copy.
See testcase for details.
--- Comment #1 from anlauf at gmx dot de 2006-06-26 20:58 ---
Created an attachment (id=11759)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11759action=view)
Testcase
Output of testcase:
Before foo:
a(1)=abc def ghij
a(2)=klm nop qrst
b(1)=abc def ghij
b(2)=klm nop qrst
--- Comment #2 from bcmpinc at hotmail dot com 2006-06-26 21:01 ---
(In reply to comment #1)
Does the JDK's javah put that _ into the generated header?
No, JDK's javah creates a header equivalent to the header created by 'gcjh
-jni'.
I suspect that you are seeing a problem with the C
--- Comment #3 from seongbae dot park at gmail dot com 2006-06-26 21:08
---
The immediate cause of the problem is in stor-layout.c:place_field():
1118 if (DECL_SIZE (field) != NULL
1119host_integerp (TYPE_SIZE (TREE_TYPE (field)), 0)
1120
--- Comment #2 from seongbae dot park at gmail dot com 2006-06-26 21:10
---
More specifically:
1048 if (rli-remaining_in_alignment bitsize)
1049 {
1050 /* out of bits; bump up to next 'word'. */
1051
--- Comment #3 from dannysmith at users dot sourceforge dot net 2006-06-26
21:21 ---
I think you may be running into a compiler (MSVC vs GNUC) difference between
handling of __stdcall (==JNICALL) symbols.
For a function void __stdcall foo (int),
both MSVC and GNUC generate an
--- Comment #4 from sje at gcc dot gnu dot org 2006-06-26 21:25 ---
Subject: Bug 28114
Author: sje
Date: Mon Jun 26 21:25:23 2006
New Revision: 115025
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115025
Log:
PR c++/28114
* g++.dg/other/pr28114.C: New.
Added:
--- Comment #10 from jason at gcc dot gnu dot org 2006-06-26 21:50 ---
The bug is that handle_externally_visible adds the second decl to cgraph_nodes
and then duplicate_decls discards it without removing it from cgraph_nodes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27369
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #9 from jason at gcc dot gnu dot org 2006-06-26 22:21 ---
Is this still broken? I can't reproduce it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27578
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-06-26 22:24
---
Fixed by the patch which fixed PR 27648.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #4 from dannysmith at users dot sourceforge dot net 2006-06-26
22:26 ---
(In reply to comment #3)
I think you may be running into a compiler (MSVC vs GNUC) difference between
handling of __stdcall (==JNICALL) symbols.
Um, and this should all be taken care of by the
--- Comment #4 from kkojima at gcc dot gnu dot org 2006-06-26 22:42 ---
Thanks for your comment. Perhaps one solution would be to handle
such bit fields with excessive sizes as the case of no remaining
bits in alignment. I'm testing the appended patch which changes
lines you've pointed
--- Comment #3 from kkojima at gcc dot gnu dot org 2006-06-26 23:10 ---
GDB says that TREE_TYPE of a.d is the 32-bit integer and its
DECL_BIT_FIELD_TYPE is 64-bit when place_field processes a.e.
place_field uses the size of TREE_TYPE of the previous bit filed
when deciding whether a bit
--- Comment #1 from laurent at guerby dot net 2006-06-26 23:28 ---
Yep, that's what I got on Linux on various tests from time to time. No other
explanation than process/file OS races.
Do you run make check on a SMP box?
--
laurent at guerby dot net changed:
What
--- Comment #19 from laurent at guerby dot net 2006-06-26 23:33 ---
Richard Kenner:
Looks like the same bug that Gigi doesn't currently use VIEW_CONVERT_EXPR
for this type of Unchecked_Conversion. So already on my plate.
Was a patch written for that at AdaCore?
--
--- Comment #4 from seongbae dot park at gmail dot com 2006-06-26 23:41
---
You're correct -I've overlooked the type mismatch.
One question though is the local variable type of place_field() is
TREE_TYPE (field), not DECL_BIT_FIELD_TYPE (field).
I'm not familiar with gcc type system
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-26
23:45 ---
Subject: Re: ACATS: cd5003h intermitent fail
--- Comment #1 from laurent at guerby dot net 2006-06-26 23:28 ---
Yep, that's what I got on Linux on various tests from time to time. No other
Ideally, libgcj's install tree would be relocatable. Currently though, there
are places where we hard-code full paths, such as the -rpath values in gij. It
would be nice if someone went through all such references and turned them into
relative paths. On Linux-based systems one could use
--- Comment #5 from kkojima at gcc dot gnu dot org 2006-06-27 00:28 ---
Although I'm also not familiar with these materials, when
place_field is called for a.d, gdb says that
(gdb) call debug_tree (field)
field_decl 0xb7f494ac d
type integer_type 0xb7ea63f4 long long int DI
--- Comment #6 from dje at gcc dot gnu dot org 2006-06-27 01:34 ---
rs6000.c:insvdi_rshift_rlwimi_p() is wrong, specifically the lines checking the
shift count.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
--- Comment #7 from dje at gcc dot gnu dot org 2006-06-27 01:40 ---
I think the correct test is something like
Index: rs6000.c
===
--- rs6000.c(revision 115003)
+++ rs6000.c(working copy)
@@ -9794,8 +9794,8 @@
--- Comment #8 from amodra at bigpond dot net dot au 2006-06-27 01:41
---
I think insvdi_rshift_rlwimi_p is totally broken. It should look something
like the following to match the capabilities of rlwimi according to my reading
of the powerpc architecture specification.
/* Return 1
program: /mnt/gnu/gcc/objdir/gcc/f951 `cat xx.sh`
Detaching after fork from child process 1902.
GNU F95 version 4.2.0 20060626 (experimental) (hppa64-hp-hpux11.00)
compiled by GNU C version 4.2.0 20060626 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
--- Comment #9 from amodra at bigpond dot net dot au 2006-06-27 01:47
---
Uh, that should be INTVAL (sizeop) = 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
--- Comment #1 from danglin at gcc dot gnu dot org 2006-06-27 01:53 ---
FAIL: gfortran.dg/actual_array_substr_1.f90 -O0 (internal compiler error)
FAIL: gfortran.dg/actual_array_substr_1.f90 -O0 (test for excess errors)
WARNING: gfortran.dg/actual_array_substr_1.f90 -O0 compilation
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26211
This metabug is used to track all the patches which have been written during
Stage 3 of GCC 4.2 but do not qualify for that stage, and are waiting for Stage
1 of GCC 4.3 to be applied.
Please, do not attacch the patches to this bug. Open a new bug report, and mark
it as blocking this metabug
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-27 02:47 ---
I know there are some C inlining changes and dwarf2/3 speeds up waiting for
stage1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28177
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-27 02:48 ---
We are now in stage3 which means all of the features have been applied so this
can be closed. I filed a 4.3 meta-bug as PR 28177.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28177
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-27 02:51 ---
This has been fixed on the LTO branch by Kazu and IIRC they are preapproved for
stage1 of 4.3 so marking this as blocking PR 28177, the meta-bug for 4.3
patches.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #4 from wilson at gcc dot gnu dot org 2006-06-27 03:02 ---
This only fails for --enable-checking builds, which is the default for
mainline, but not release branches. I was able to reproduce this with gcc-4.0,
but not gcc-3.4. The difference between the two is that gcc-4.0
--- Comment #20 from kenner at vlsi1 dot ultra dot nyu dot edu 2006-06-27
03:03 ---
Subject: Re: [4.2 Regression] ACATS c35507m cd2a23e cxh1001 fail
Looks like the same bug that Gigi doesn't currently use VIEW_CONVERT_EXPR
for this type of Unchecked_Conversion. So already on
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-checking
Known to fail||4.0.0
--- Comment #5 from tromey at gcc dot gnu dot org 2006-06-27 03:20 ---
Yeah, jni.cc handles the lookup side of things.
The declaration side of things in user JNI code should be
handled by jni_md.h. It has a bunch of win32-specific code
which boils down to:
#define JNIIMPORT
--- Comment #3 from joseph dot rajesh at gmail dot com 2006-06-27 04:09
---
No I haven't missed the copy constructor... I checked the working with copy
constructor also...
I know g++ is doing a conversion and making a copy of type Base (Using Base
copy constructor)... that's why the
--- Comment #22 from uros at kss-loka dot si 2006-06-27 05:49 ---
(In reply to comment #21)
Note that you are running the opposite of my test case: SSE vs SSE rather than
x87 vs x87. This whole bug report is about x87 performance. You can get more
detail on why I want x87 in my
77 matches
Mail list logo
