[Bug rtl-optimization/29881] union causes inefficient code

[spd at poczta dot fm]

--- Comment #2 from spd at poczta dot fm  2006-11-18 10:25 ---
(In reply to comment #1)
> The problem here I think is unions.
> 
> Here is how I would have written this code (without using unions in fact):
> 
> void array_sample_fun(__m128 *dst, const __m128  *src, int length) {
> __m128 af = _mm_set1_ps(1.20f);
> __m128 bf = _mm_set1_ps(2.88f);
> __m128 cf = _mm_set1_ps(-2.44f);
> __m128 df = _mm_set1_ps(4.06f);
> __m128 ef = _mm_set1_ps(-12.04f);
> 
> __m128i mask = _mm_set1_epi32(0xff << 23);
> __m128i bias = _mm_set1_epi32(0x7f << 23);
> __m128i t;
> 
> while (length-- != 0) {
> __m128 vec;
> 
> vec = (*src++);
> __m128 arg =
> _mm_cvtepi32_ps(_mm_srai_epi32(_mm_sub_epi32(_mm_and_si128((__m128i)vec, 
> mask),
> bias),
> 23));
> vec = (__m128)_mm_or_si128(_mm_andnot_si128(mask,
> (__m128i)vec), bias);
> *dst++ = _mm_add_ps(arg,
> _mm_add_ps(_mm_mul_ps(_mm_add_ps(_mm_mul_ps(_mm_add_ps(_mm_mul_ps(_mm_add_ps(
> _mm_mul_ps(af, vec), bf), vec), cf), vec), df),
> vec), ef));
> }
> }
> 
> 
> --
> The above gives good results for 32bit:
> .L4:
> movaps  (%eax), %xmm0
> movdqa  %xmm4, %xmm1
> addl$1, %ecx
> addl$16, %eax
> movdqa  %xmm0, %xmm2
> pandn   %xmm0, %xmm1
> movaps  .LC0, %xmm0
> por %xmm3, %xmm1
> pand%xmm4, %xmm2
> psubd   %xmm3, %xmm2
> mulps   %xmm1, %xmm0
> psrad   $23, %xmm2
> cvtdq2ps%xmm2, %xmm2
> addps   .LC1, %xmm0
> mulps   %xmm1, %xmm0
> addps   %xmm7, %xmm0
> mulps   %xmm1, %xmm0
> addps   %xmm6, %xmm0
> mulps   %xmm1, %xmm0
> addps   %xmm5, %xmm0
> addps   %xmm0, %xmm2
> movaps  %xmm2, (%edx)
> addl$16, %edx
> cmpl%ebx, %ecx
> jne .L4
> 
> 
> While your orginal example on 32bits has a store to the stack.
> 
> So this is just a case where union cause missed optimization
> 

Thanks for the hint! Assembly looks ok right now - didn't expect that this kind
of casting would work (it doesn't in msvc compilers). Anyway it would be nice
if the compiler would detect such a optimization opportunity (union case) as a
valid one.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29881

[Bug fortran/27546] [F2003] IMPORT not implemented

[patchapp at dberlin dot org]

--- Comment #11 from patchapp at dberlin dot org  2006-11-18 10:45 ---
Subject: Bug number PR27546

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/2006-11/msg01304.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27546

[Bug c/29885] New: compiling takes very long time during -O3 compile

[marcus at jet dot franken dot de]

Compiling the attached testcase (from WINE) with -O3 takes very long
time and memory (800MB) on current TRUNK (4.3).

removing one or more lines speeds up the compiler massively.

I think this is due to bitmask and ifs.


-- 
   Summary: compiling takes very long time during -O3 compile
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marcus at jet dot franken dot de
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29885

[Bug c/29885] compiling takes very long time during -O3 compile

[marcus at jet dot franken dot de]

--- Comment #1 from marcus at jet dot franken dot de  2006-11-18 10:59 
---
Created an attachment (id=12640)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12640&action=view)
locale.i

gcc -O3 -c locale.i 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29885

[Bug target/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal
  Component|c   |target
  GCC build triplet|Linux comp.home.net 2.6.12- |i686-pc-linux-gnu
   |27mdk-i686-up-4GB #1 Tue Sep|
   |26 12:41|
   GCC host triplet|Linux comp.home.net 2.6.12- |i686-pc-linux-gnu
   |27mdk-i686-up-4GB #1 Tue Sep|
   |26 12:41|
 GCC target triplet|Linux comp.home.net 2.6.12- |i686-pc-linux-gnu
   |27mdk-i686-up-4GB #1 Tue Sep|
   |26 12:41|


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29884

[Bug target/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2006-11-18 11:07 ---
963 v_r_signal_L.v = *(vFloat *)&signal_spectrum_L[bin_number];

(gdb) p signal_spectrum_L
$1 = (AUDIO_DATA_TYPE *) 0x80491e0
(gdb) p bin_number
$2 = 1
(gdb) p &signal_spectrum_L[bin_number]
$3 = (AUDIO_DATA_TYPE *) 0x80491e4


This is not a bug, the alignment requirement for vector loads are 16byte
aligned and you just violated that.

You should use the SSE intrinsics for unaligned loads here.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29884

[Bug middle-end/29885] compiling takes very long time during -O3 compile

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-11-18 11:10 ---
This is ok with "4.3.0 20061112" on i686-linux-gnu.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29885

[Bug c++/29883] i686-pc-cygwin/3.4.4 - internal compiler error: Segmentation fault

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|trivial |normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29883

[Bug rtl-optimization/29881] union causes inefficient code

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2006-11-18 11:17 ---
(In reply to comment #2)
> Thanks for the hint! Assembly looks ok right now - didn't expect that this 
> kind
> of casting would work (it doesn't in msvc compilers). Anyway it would be nice
> if the compiler would detect such a optimization opportunity (union case) as a
> valid one.

It is a documented extension for GCC, though it is a standard feature with
altivec(VMX, powerpc) and SPU compilers which is why it is included with GCC.

http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Vector-Extensions.html

It is possible to cast from one vector type to another, provided they are of
the same size (in fact, you can also cast vectors to and from other datatypes
of the same size).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  GCC build triplet|x86_64-unknown-linux-gnu|
   GCC host triplet|x86_64-unknown-linux-gnu|
 GCC target triplet|x86_64-unknown-linux-gnu|i?86-*-* x86_64-*-*
   Keywords||missed-optimization


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29881

[Bug middle-end/29881] union causes inefficient code

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2006-11-18 11:18 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
  Component|rtl-optimization|middle-end
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-11-18 11:18:36
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29881

[Bug c++/28284] [4.1 regression] ICE with invalid static const variable

[reichelt at gcc dot gnu dot org]

--- Comment #6 from reichelt at gcc dot gnu dot org  2006-11-18 11:39 
---
Mark, your patch for PR29106 backported this bug back to the 4.1 branch.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mark at codesourcery dot com
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |
Summary|[4.2 regression] ICE with   |[4.1 regression] ICE with
   |invalid static const|invalid static const
   |variable|variable
   Target Milestone|4.2.0   |4.1.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28284

[Bug c++/29106] [4.0 Regression] sizeof(*var) in expression drops entire line of code out of compile

[reichelt at gcc dot gnu dot org]

--- Comment #12 from reichelt at gcc dot gnu dot org  2006-11-18 11:55 
---
Btw, the fix ported PR28284 back to the 4.1 branch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29106

[Bug fortran/24285] format(1000(a,$))

[fxcoudert at gcc dot gnu dot org]

--- Comment #7 from fxcoudert at gcc dot gnu dot org  2006-11-18 12:17 
---
Subject: Bug 24285

Author: fxcoudert
Date: Sat Nov 18 12:16:42 2006
New Revision: 118971

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118971
Log:
PR fortran/24285

* io.c (check_format): Allow dollars everywhere in format, and
issue a warning.

* gfortran.dg/dollar_edit_descriptor-3.f: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/dollar_edit_descriptor-3.f
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24285

[Bug fortran/24285] format(1000(a,$))

[fxcoudert at gcc dot gnu dot org]

--- Comment #8 from fxcoudert at gcc dot gnu dot org  2006-11-18 12:19 
---
Fixed on 4.3, and I'll backport it to 4.2 after some time.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||patch
  Known to fail||4.2.0
  Known to work||4.3.0
   Target Milestone|--- |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24285

[Bug c++/29886] New: [4.0/4.1/4.2/4.3 regression] C-style cast misinterpreted as variable declaration

[reichelt at gcc dot gnu dot org]

The following IMHO valid code snippet is rejected since GCC 4.0.0:


struct A
{
  static int x[1];
};

void foo(int i)
{
  if (int(A::x[i])) {}
}


bug.cc: In function 'void foo(int)':
bug.cc:8: error: array bound is not an integer constant


-- 
   Summary: [4.0/4.1/4.2/4.3 regression] C-style cast misinterpreted
as variable declaration
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: rejects-valid, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29886

[Bug c++/29886] [4.0/4.1/4.2/4.3 regression] C-style cast misinterpreted as variable declaration

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.0.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29886

[Bug c++/29886] [4.0/4.1/4.2/4.3 regression] Cast misinterpreted as variable declaration

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2006-11-18 14:47 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-11-18 14:47:40
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29886

[Bug fortran/27546] IMPORT is broken

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.3.0
Summary|[F2003] IMPORT not  |IMPORT is broken
   |implemented |
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27546

[Bug middle-end/29887] New: wrong-code for errno handling on overflow/underflow

[rguenth at gcc dot gnu dot org]

builtins.c:expand_errno_check() can only handle setting EDOM if the operation
returns NaN on error.  Most overflow/underflow conditions result in -Inf/+Inf
instead and with non-default rounding-mode (-frounding-math) the maximum or
minimum floating-point value will be returned (round to -Inf/+Inf or zero).

One testcase:

#include 
#include 
#include 

int main(int argc, char **argv)
{
  double y = atof(argv[1]);
  double x = exp (y);
  printf("%.6e %.6e\n", y, x);
  perror("errno");
  return 0;
}

which shall print "errno: Numerical result out of range" if you pass 5000
to the testcase executable but prints "errno: Success" if you build with
-funsafe-math-optimizations on i686 which will do an inline expansion for
exp ().


-- 
   Summary: wrong-code for errno handling on overflow/underflow
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29887

[Bug target/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code

[sergstesh at yahoo dot com]

--- Comment #5 from sergstesh at yahoo dot com  2006-11-18 15:17 ---
IIRC, misaligned data should cause performance penalty, not segmentation fault.

Look at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818 , at the case when
there is no segfault:

"
when the code runs fine (i.e. compiled by gcc-4.1.1), the screen output is:

"
checkpoint 1
&inp_array_1[0]=80498e0
checkpoint 2
bn=1
&inp_array_1[1]=80498e4
checkpoint 3
checkpoint 4
...
"

- as you see '&inp_array_1[1]=80498e4', and its WRT to line numbers 31..35 in:

 29   while(half_nos - bn >= NUMBER_OF_ELEMENTS_IN_VECTOR)
 30 {
 31 fprintf(stderr, "bn=%u\n", bn);
 32 fprintf(stderr, "&inp_array_1[%u]=%0lx\n", bn, (unsigned
long)&inp_array_1[bn]);
 33
 34 fprintf(stderr, "checkpoint 3\n");
 35 vtmp1.v = *(vFloat *)&inp_array_1[bn];
 36 fprintf(stderr, "checkpoint 4\n");
 37
 38 bn += NUMBER_OF_ELEMENTS_IN_VECTOR;
 39 } // while(half_nos - bn >= NUMBER_OF_ELEMENTS_IN_VECTOR)
.

In this case the address is 80498e4, i.e. no a multiple of 16, still, the
code does not segfault, even though a misaligned operation:

 35 vtmp1.v = *(vFloat *)&inp_array_1[bn];

is executed.

This is what I found in the documentation:

http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options
:

"
-mpreferred-stack-boundary=num
Attempt to keep the stack boundary aligned to a 2 raised to num byte
boundary. If -mpreferred-stack-boundary is not specified, the default is 4 (16
bytes or 128 bits), except when optimizing for code size (-Os), in which case
the default is the minimum correct alignment (4 bytes for x86, and 8 bytes for
x86-64).

On Pentium and PentiumPro, double and long double values should be aligned
to an 8 byte boundary (see -malign-double) or suffer significant run time
performance penalties. On Pentium III, the Streaming SIMD Extension (SSE) data
type __m128 suffers similar penalties if it is not 16 byte aligned.
...
"

- from the above I expected to "suffer significant run time performance
penalties", but not a segfault.

Could you please:

1) point me to the documentation which says that misaligned SSE data will
cause segfault;

2) if such a document does not exist, update the documentation, preferably
pointing also to Intel documentation stating that misaligned SSE data causes
segmentation fault;

3) explain, how/why the code in

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818

does not segfault even though it has the same misalignment as here


?

Thanks in advance.


-- 

sergstesh at yahoo dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29884

[Bug fortran/27698] subroutine _foo draws "unclassifiable statement" instead of a useful error.

[aldot at gcc dot gnu dot org]

--- Comment #11 from aldot at gcc dot gnu dot org  2006-11-18 15:23 ---

> Disallowing a dollar sign as the very first character in a name even if
> -fdollar-ok was requested by the user seems to be a simple omission to me.
> 
> Whether we want to allow for such invalid code for compatibility is beyond my
> judgement, though.

One implication would concern implicit types, AFAICS.
gfc_namespace.default_type[GFC_LETTERS] is currently limiting implicit types to
a..z

Should -fdollar-ok be made to allow for a '$' even in the first position of a
name (including implicit types for types with a name starting with '$') or are
we better off to extend the documentation to explicitely note that '$' as the
_first_ char in a name is not supported in this extension?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27698

[Bug c/29888] New: No error when "too few arguments" or "conflicting types" would be expected

[alexer at mbnet dot fi]

Compiling the following code snippet gives no errors:

int main(){
  foo();
  return 0;
}
int foo(int x){
  return 0;
}

If return type of foo is changed to void, it gives the following errors: (which
i think would be the expected in the first case, too)

wtf.c:7: error: conflicting types for 'foo'
wtf.c:3: error: previous implicit declaration of 'foo' was here

Tested on 3.4.5 and 4.1.1


-- 
   Summary: No error when "too few arguments" or "conflicting types"
would be expected
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexer at mbnet dot fi


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29888

[Bug c++/29022] [4.0/4.1/4.2/4.3 regression] ICE using operator int in invalid class hierarchy

[patchapp at dberlin dot org]

--- Comment #3 from patchapp at dberlin dot org  2006-11-18 17:30 ---
Subject: Bug number PR c++/29022

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/2006-11/msg01314.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29022

[Bug bootstrap/29889] New: jc1 segfaults while bootstrap

[falk at debian dot org]

[...]
/src/gcc-2006.11.16/build/gcc/gcj
-B/src/gcc-2006.11.16/build/alphaev68-unknown-linux-gnu/libjava/
-B/src/gcc-2006.11.16/build/gcc/ -mieee -fclasspath=
-fbootclasspath=/src/gcc-2006.11.16/build/alphaev68-unknown-linux-gnu/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -fjni
-findirect-dispatch -fno-indirect-classes -c @gnu-CORBA.list -fPIC -o
.libs/gnu-CORBA.o
gnu/CORBA/CDR/gnuRuntime.java: In class 'gnu.CORBA.CDR.gnuRuntime$Redirection':
gnu/CORBA/CDR/gnuRuntime.java: In method
'gnu.CORBA.CDR.gnuRuntime$Redirection.toString()':
gnu/CORBA/CDR/gnuRuntime.java:95: 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.
make[3]: *** [gnu-CORBA.lo] Error 1
make[3]: Leaving directory
`/src/gcc-2006.11.16/build/alphaev68-unknown-linux-gnu/libjava'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/src/gcc-2006.11.16/build/alphaev68-unknown-linux-gnu/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/src/gcc-2006.11.16/build'
make: *** [bootstrap] Error 2

[EMAIL 
PROTECTED]:/src/gcc-2006.11.16/build/alphaev68-unknown-linux-gnu/libjava% gdb
../../gcc/jc1
GNU gdb 6.5-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "alpha-linux-gnu"...Using host libthread_db library
"/lib/libthread_db.so.1".

(gdb) r /tmp/cckTVEkLjx -fhash-synchronization -fuse-divide-subroutine
-fuse-boehm-gc -fnon-call-exceptions -mieee -fkeep-inline-functions -quiet
-dumpbase ccWKKQvWjx -mieee -mcpu=ev67 -auxbase-strip .libs/gnu-CORBA.o -g -O2
-Wno-deprecated -version -ffilelist-file -fclasspath=
-fbootclasspath=/src/gcc-2006.11.16/build/alphaev68-unknown-linux-gnu/libjava/classpath/lib
-fencoding=UTF-8 -fbootstrap-classes -fjni -findirect-dispatch
-fno-indirect-classes -fPIC -o /tmp/ccQxnArK.s
Starting program: /src/gcc-2006.11.16/build/gcc/jc1 /tmp/cckTVEkLjx
-fhash-synchronization -fuse-divide-subroutine -fuse-boehm-gc
-fnon-call-exceptions -mieee -fkeep-inline-functions -quiet -dumpbase
ccWKKQvWjx -mieee -mcpu=ev67 -auxbase-strip .libs/gnu-CORBA.o -g -O2
-Wno-deprecated -version -ffilelist-file -fclasspath=
-fbootclasspath=/src/gcc-2006.11.16/build/alphaev68-unknown-linux-gnu/libjava/classpath/lib
-fencoding=UTF-8 -fbootstrap-classes -fjni -findirect-dispatch
-fno-indirect-classes -fPIC -o /tmp/ccQxnArK.s
GNU Java version 4.3.0 20061116 (experimental) (alphaev68-unknown-linux-gnu)
compiled by GNU C version 4.3.0 20061116 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Class path starts here:
./
   
/src/gcc-2006.11.16/build/alphaev68-unknown-linux-gnu/libjava/classpath/lib/
(system)

Program received signal SIGSEGV, Segmentation fault.
add_type_assertion (class=, assertion_code=, op1=0x2473a20, 
op2=) at ../../gcc/java/expr.c:477
477   **(type_assertion **)as_pp = as;
(gdb) bt
#0  add_type_assertion (class=, assertion_code=, op1=0x2473a20, 
op2=) at ../../gcc/java/expr.c:477
#1  0x0001200893ac in vfy_is_assignable_from (target=0x1, source=0x18) at
../../gcc/java/verify-glue.c:246
#2  0x00012008af50 in types_compatible (t=, k=)
at ../../gcc/java/verify-impl.c:376
#3  0x00012008b3a0 in vfy_pop_type_t (match={key = reference_type, klass =
0x1207d2f90, pc = -2})
at ../../gcc/java/verify-impl.c:1172
#4  0x00012008d1a4 in verify_instructions () at
../../gcc/java/verify-impl.c:2913
#5  0x00012008e9ec in verify_method (meth=0x11ffed210) at
../../gcc/java/verify-impl.c:3305
#6  0x000120088634 in verify_jvm_instructions_new (jcf=0x201eac8,
byte_ops=0x1206cf50c "»", length=20)
at ../../gcc/java/verify-glue.c:507
#7  0x00012007eca4 in expand_byte_code (jcf=0x201eac8, method=) at ../../gcc/java/expr.c:3094
#8  0x000120091564 in parse_class_file () at ../../gcc/java/jcf-parse.c:955
#9  0x000120095d2c in java_parse_file (set_yydebug=)
at ../../gcc/java/jcf-parse.c:1310
#10 0x00012032a030 in toplev_main (argc=, argv=) at ../../gcc/toplev.c:1033
#11 0x0001200ad228 in main (argc=8609912, argv=0xafafafafafafafaf) at
../../gcc/main.c:35
(gdb)


-- 
   Summary: jc1 segfaults while bootstrap
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
 GCC build triplet: alphaev68-unknown-linux-gnu
  GCC host triplet: alphaev68-unknown-linux-gnu
GCC target triplet: alphaev68-unknown-linux-gn

[Bug libgomp/29890] New: FAIL: libgomp.fortran/vla6.f90 -O0 execution test

[danglin at gcc dot gnu dot org]

Executing on host: /xxx/gnu/gcc/objdir/gcc/xgcc -B/xxx/gnu/gcc/objdir/gcc/
/xxx/
gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/vla6.f90 
-B/xxx/gnu/gcc/objdir/hp
pa2.0w-hp-hpux11.00/./libgomp/
-I/xxx/gnu/gcc/objdir/hppa2.0w-hp-hpux11.00/./lib
gomp -I/xxx/gnu/gcc/gcc/libgomp/testsuite/.. -fmessage-length=0 -fopenmp  -O0
  -L/xxx/gnu/gcc/objdir/hppa2.0w-hp-hpux11.00/./libgomp/.libs -lgomp
-L/xxx/gnu/
gcc/objdir/hppa2.0w-hp-hpux11.00/./libgomp/../libgfortran/.libs -lgfortranbegin
-lgfortran -lm   -o ./vla6.exe(timeout = 300)
PASS: libgomp.fortran/vla6.f90  -O0  (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/xxx/gnu/gcc/objdir/hppa2.0w-hp-hpux11.00/./libgomp
/.libs:/xxx/gnu/gcc/objdir/hppa2.0w-hp-hpux11.00/./libgomp/../libgfortran/.libs:
/xxx/gnu/gcc/objdir/gcc:.:/xxx/gnu/gcc/objdir/hppa2.0w-hp-hpux11.00/./libgomp/.l
ibs:/xxx/gnu/gcc/objdir/hppa2.0w-hp-hpux11.00/./libgomp/../libgfortran/.libs:/xx
x/gnu/gcc/objdir/gcc
FAIL: libgomp.fortran/vla6.f90  -O0  execution test

This is the backtrace from the generated core dump:

(gdb) bt
#0  0xc01f9500 in kill () from /usr/lib/libc.2
#1  0xc0195660 in raise () from /usr/lib/libc.2
#2  0xc01d6b24 in abort_C () from /usr/lib/libc.2
#3  0xc01d6b7c in abort () from /usr/lib/libc.2
#4  0xc214ac70 in _gfortran_abort ()
at ../../../gcc/libgfortran/intrinsics/abort.c:39
#5  0x3a18 in foo___925 () from ./vla6.x0
#6  0x3c14 in test___914 () from ./vla6.x0
#7  0x2f30 in MAIN__ () from ./vla6.x0
#8  0x9214 in main (argc=2063683944, argv=0x7b015168)
at ../../../gcc/libgfortran/fmain.c:18

I can't duplicate the failure running the program under gdb, or when
compiled with -g.  The FAIL only occurs at -O0.


-- 
   Summary: FAIL: libgomp.fortran/vla6.f90  -O0  execution test
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa2.0w-hp-hpux11*
  GCC host triplet: hppa2.0w-hp-hpux11*
GCC target triplet: hppa2.0w-hp-hpux11*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29890

[Bug target/29114] ICE when cross-compiling glibc for hppa on a 64bit host

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca  2006-11-18 
18:01 ---
Subject: Re:  ICE when cross-compiling glibc for hppa on a 64bit host

Untested patch.

Dave


--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca  2006-11-18 
18:01 ---
Created an attachment (id=12641)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12641&action=view)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29114

[Bug target/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2006-11-18 18:05 ---
There are two SSE instructions for loading memory, one that does unaligned
loads and one that does aligned loads.  And the default instruction used for
vectors pointers is the aligned one.  This is standard SSE way of doing it and
not a GCC specific issue.  Most likely because the data is aligned just off by
4 bytes.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29884

[Bug c/29888] No error when "too few arguments" or "conflicting types" would be expected

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-11-18 18:08 ---
implicit declarations are a bit weird really (it is one reason why it is
depercated in C99).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29888

[Bug tree-optimization/29877] out of SSA (TER) extends variable life of variable beyond original declared

[amacleod at redhat dot com]

--- Comment #4 from amacleod at redhat dot com  2006-11-18 18:20 ---
Yes, I think that is sufficient. I beleive all register variables have to be
loaded into an SSA_NAME like this before they can be used, and they all have to
have a virtual operand. So it should be good.

You beat me to it :-)

Andrew


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29877

[Bug rtl-optimization/29879] [4.3 Regression] ICE: verify_flow_info: loop_father but no loops

[danglin at gcc dot gnu dot org]

--- Comment #3 from danglin at gcc dot gnu dot org  2006-11-18 18:32 ---
This breaks bootstrap on hppa-unknown-linux-gnu:

/home/dave/gnu/gcc-4.3/objdir/./gcc/xgcc -B/home/dave/gnu/gcc-4.3/objdir/./gcc/
-B/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-
4.3.0/hppa-linux/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/inclu
de -isystem /home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/sys-include
-DHAVE_CONFI
G_H -I. -I../../../gcc/libgfortran -I. -iquote../../../gcc/libgfortran/io
-I../.
./../gcc/libgfortran/../gcc -I../../../gcc/libgfortran/../gcc/config
-I../.././g
cc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold
-style-definition -Wextra -Wwrite-strings -ftree-vectorize -funroll-loops -O2
-g
 -O2 -c ../../../gcc/libgfortran/generated/matmul_i4.c  -fPIC -DPIC -o
.libs/mat
mul_i4.o
../../../gcc/libgfortran/generated/matmul_i4.c: In function 'matmul_i4':
../../../gcc/libgfortran/generated/matmul_i4.c:337: error: verify_flow_info:
Blo
ck 137 has loop_father, but there are no loops


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29879

[Bug tree-optimization/29891] New: libgcc2.c: In function '__gcc_bcmp': ICE: Segmentation fault

[danglin at gcc dot gnu dot org]

Reported first here: .
Also, see .

(gdb) bt
#0  rewrite_use_compare (data=0x7eff0e18, use=0x4007f928, cand=0x4008f450)
at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5625
#1  0x00320390 in rewrite_uses (data=0x7eff0e18)
at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5678
#2  0x003246a0 in tree_ssa_iv_optimize_loop (data=0x7eff0e18, loop=0x7eff0ea0)
at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5868
#3  0x00324c20 in tree_ssa_iv_optimize (loops=0x40076360)
at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5905
#4  0x0030638c in tree_ssa_loop_ivopts () at ../../gcc/gcc/tree-ssa-loop.c:451
#5  0x00266b44 in execute_one_pass (pass=0x400123a0)
at ../../gcc/gcc/passes.c:871
#6  0x00266ce4 in execute_pass_list (pass=0x400123a0)
at ../../gcc/gcc/passes.c:918
#7  0x00266cf8 in execute_pass_list (pass=0x40012130)
at ../../gcc/gcc/passes.c:919
#8  0x00266cf8 in execute_pass_list (pass=0x40008608)
at ../../gcc/gcc/passes.c:919
#9  0x000c64a4 in tree_rest_of_compilation (fndecl=0x7acfbf50)
at ../../gcc/gcc/tree-optimize.c:463
#10 0x00039490 in c_expand_body (fndecl=0x7acfbf50)
at ../../gcc/gcc/c-decl.c:6847
#11 0x00293814 in cgraph_expand_function (node=0x7ad61c40)
at ../../gcc/gcc/cgraphunit.c:1241

As noted by Steve, the return value from the call to
get_use_iv_cost is null:

(gdb) disass 0x31fc6c 0x31fc8c
Dump of assembler code from 0x31fc6c to 0x31fc8c:
0x0031fc6c :copy r3,r26
0x0031fc70 :copy r5,r25
0x0031fc74 :b,l 0x315bb0 ,rp
0x0031fc78 :copy r4,r24
0x0031fc7c :ldw c(ret0),r6
0x0031fc80 :cmpib,= 0,r6,0x31fe9c

0x0031fc84 :copy r4,r25
0x0031fc88 :ldw 0(r3),r26
End of assembler dump.
(gdb) p/x $ret0
$2 = 0x0

(gdb) p *data
$10 = {current_loop = 0x4007f1c0, regs_used = 0, niters = 0x4007f430,
  version_info_size = 70, version_info = 0x400901b8, relevant = 0x400747dc,
  max_inv_id = 3, iv_uses = 0x4007f558, iv_candidates = 0x4008f540,
  important_candidates = 0x40074560, consider_all_candidates = 1 '\001'}
(gdb) p *use
$11 = {id = 0, type = USE_COMPARE, iv = 0x4007f828, stmt = 0x7aded208,
  op_p = 0x7aded224, related_cands = 0x0, n_map_members = 23,
  cost_map = 0x4008f618, selected = 0x4008f450}
(gdb) p *cand
$14 = {id = 19, important = 0 '\0', pos = IP_NORMAL, incremented_at = 0x0,
  var_before = 0x7ad712d0, var_after = 0x7ad719f0, iv = 0x4008f480, cost = 8,
  depends_on = 0x0}

(gdb) step
get_use_iv_cost (data=0x7eff0e18, use=0x4007f928, cand=0x4008f450)
at ../../gcc/gcc/tree-ssa-loop-ivopts.c:2397
2397  s = cand->id & (use->n_map_members - 1);
(gdb)
2389  ret = use->cost_map + cand->id;
(gdb)
2390  if (!ret->cand)
(gdb)
2407}
(gdb)
rewrite_use_compare (data=0x7eff0e18, use=0x4007f928, cand=0x4008f450)
at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5625
5625  bound = cp->value;


-- 
   Summary: libgcc2.c: In function '__gcc_bcmp': ICE: Segmentation
fault
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa2.0w-hp-hpux11*
  GCC host triplet: hppa2.0w-hp-hpux11*
GCC target triplet: hppa2.0w-hp-hpux11*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29891

[Bug tree-optimization/29891] [4.3 Regression] libgcc2.c: In function '__gcc_bcmp': ICE: Segmentation fault

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Severity|normal  |blocker
   Keywords||build, ice-on-valid-code
Summary|libgcc2.c: In function  |[4.3 Regression] libgcc2.c:
   |'__gcc_bcmp': ICE:  |In function '__gcc_bcmp':
   |Segmentation fault  |ICE: Segmentation fault
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29891

[Bug fortran/27885] FAIL: libgomp.fortran/vla[1-7].f90 -O0 (test for excess errors)

[danglin at gcc dot gnu dot org]

--- Comment #5 from danglin at gcc dot gnu dot org  2006-11-18 23:17 ---
Subject: Bug 27885

Author: danglin
Date: Sat Nov 18 23:17:33 2006
New Revision: 118977

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118977
Log:
PR fortran/27885
PR middle-end/28176
* stor-layout.c (set_sizetype): Limit precision of *bitsizetypes types
to MAX_FIXED_MODE_SIZE.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/stor-layout.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27885

[Bug middle-end/28176] FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE)

[danglin at gcc dot gnu dot org]

--- Comment #10 from danglin at gcc dot gnu dot org  2006-11-18 23:17 
---
Subject: Bug 28176

Author: danglin
Date: Sat Nov 18 23:17:33 2006
New Revision: 118977

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118977
Log:
PR fortran/27885
PR middle-end/28176
* stor-layout.c (set_sizetype): Limit precision of *bitsizetypes types
to MAX_FIXED_MODE_SIZE.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/stor-layout.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28176

[Bug middle-end/28176] FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE)

[danglin at gcc dot gnu dot org]

--- Comment #11 from danglin at gcc dot gnu dot org  2006-11-19 00:44 
---
Subject: Bug 28176

Author: danglin
Date: Sun Nov 19 00:44:04 2006
New Revision: 118984

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118984
Log:
PR fortran/27885
PR middle-end/28176
* stor-layout.c (set_sizetype): Limit precision of *bitsizetypes types
to MAX_FIXED_MODE_SIZE.


Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/stor-layout.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28176

[Bug fortran/27885] FAIL: libgomp.fortran/vla[1-7].f90 -O0 (test for excess errors)

[danglin at gcc dot gnu dot org]

--- Comment #6 from danglin at gcc dot gnu dot org  2006-11-19 00:44 ---
Subject: Bug 27885

Author: danglin
Date: Sun Nov 19 00:44:04 2006
New Revision: 118984

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118984
Log:
PR fortran/27885
PR middle-end/28176
* stor-layout.c (set_sizetype): Limit precision of *bitsizetypes types
to MAX_FIXED_MODE_SIZE.


Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/stor-layout.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27885

[Bug middle-end/28176] FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE)

[danglin at gcc dot gnu dot org]

--- Comment #12 from danglin at gcc dot gnu dot org  2006-11-19 00:50 
---
Fixed by patch.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28176

[Bug fortran/27885] FAIL: libgomp.fortran/vla[1-7].f90 -O0 (test for excess errors)

[danglin at gcc dot gnu dot org]

--- Comment #7 from danglin at gcc dot gnu dot org  2006-11-19 00:51 ---
Fixed by patch.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27885

[Bug libgomp/29890] FAIL: libgomp.fortran/vla6.f90 -O0 execution test

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2006-11-19 01:04 ---
Duplicate of PR 28708.  Sorry.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29890

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[pinskia at gcc dot gnu dot org]

--- Comment #14 from pinskia at gcc dot gnu dot org  2006-11-19 01:27 
---
This like the other you filed is not a GCC bug, you are accessing a SSE vector
that is not aligned so you have to use the SSE intrinsic that does unaligned
access.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[sergstesh at yahoo dot com]

--- Comment #15 from sergstesh at yahoo dot com  2006-11-19 01:59 ---
Is the alignment requirement always applicable in all the cases, or just
for gcc-3.4.6 ?

Remember, in this case gcc-4.1.1 produces code which doesn't segfault.

Is it that gcc-4.1.1 optimizes out the failing line ?
Is it that gcc-4.1.1 falsely aligns the memory location in question ?
Is it that gcc-4.1.1 uses misaligned load into SSE registers by default ?

Is there any page in gcc manual clearly saying:

"align your data properly or your program will segfault"

?

I am specifically interested in the "or your program will segfault" part ?


-- 

sergstesh at yahoo dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[pinskia at gcc dot gnu dot org]

--- Comment #16 from pinskia at gcc dot gnu dot org  2006-11-19 02:06 
---
(In reply to comment #15)
> Is the alignment requirement always applicable in all the cases, or just
> for gcc-3.4.6 ?

It segfaults for me with gcc-4.1.2.

> 
> Remember, in this case gcc-4.1.1 produces code which doesn't segfault.

That could be because malloc/stack locations just happen to be 16byte aligned

> 
> Is it that gcc-4.1.1 optimizes out the failing line ?
No.

> Is it that gcc-4.1.1 falsely aligns the memory location in question ?

Well it can be 8byte aligned and accidently also 16byte aligned (which does
happen every once in a while).

> Is it that gcc-4.1.1 uses misaligned load into SSE registers by default ?
No because I could reproduce the failure in 4.1.2

> 
> Is there any page in gcc manual clearly saying:
> 
> "align your data properly or your program will segfault"
> 
> ?
> 
> I am specifically interested in the "or your program will segfault" part ?

This is call debugging your program.  Also you really should read web pages
about SSE programming because it seems like you don't understand how to use.

Also using mode with vector mode is deprecated and you should be using
vector_size instead.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818

[Bug rtl-optimization/29879] [4.3 Regression] ICE: verify_flow_info: loop_father but no loops

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2006-11-19 02:11 ---
A very reduced testcase:
int main ()
{
  return 0;
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29879

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[sergstesh at yahoo dot com]

--- Comment #17 from sergstesh at yahoo dot com  2006-11-19 02:20 ---
Regarding

"
> Is it that gcc-4.1.1 falsely aligns the memory location in question ?

Well it can be 8byte aligned and accidently also 16byte aligned (which does
happen every once in a while).
"

The original report shows:

"
&inp_array_1[1]=80498e4
checkpoint 3
Segmentation fault
"

, i.e. the failing address is not 8 bytes aligned, it's 4 bytes aligned.

Regarding

"
> I am specifically interested in the "or your program will segfault" part ?

This is call debugging your program.  Also you really should read web pages
about SSE programming because it seems like you don't understand how to use.
"

I did read documentation on the issue, beginning from gcc manual.

You correctly point out that by default aligned loads are used, which
are faster, and Intel documentation says that misaligned address in such
a case causes general protection fault. Which can be dealt with by kernel.

The point is that I do not recall in the gcc manual mentioning of the default
aligned load.

Adding one sentence (if it's not yet there) would make life of both end users
and developers easier - the developers will have to deal with smaller amount
of bug reports like this one.

Regarding

"
Also using mode with vector mode is deprecated and you should be using
vector_size instead.
"

- sure, just gcc-3.4.6 doesn't understand this. I do not remember how
the gcc version macro is called, so I used the code which was compatible with
both gcc-3.4.6 and gcc-4.1.1, though it produces warning on gcc-4.1.1.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818

[Bug rtl-optimization/29879] [4.3 Regression] ICE: verify_flow_info: loop_father but no loops

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2006-11-19 02:25 ---
current_loops is not being set for RTL optimizers.  Why?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29879

[Bug rtl-optimization/29879] [4.3 Regression] ICE: verify_flow_info: loop_father but no loops

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2006-11-19 02:43 ---
The problem is fwprop calls flow_loops_find directly and flow_loops_free
direclty which no other pass does so this is valid ICE after all.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29879

[Bug rtl-optimization/29879] [4.3 Regression] ICE: verify_flow_info: loop_father but no loops

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2006-11-19 02:46 ---
I am testing a patch for this.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29879

[Bug rtl-optimization/29879] [4.3 Regression] ICE: verify_flow_info: loop_father but no loops

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2006-11-19 02:52 ---
Created an attachment (id=12642)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12642&action=view)
Patch which should fix it

This patch fixes it as far as I can tell.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29879

[Bug rtl-optimization/29879] [4.3 Regression] ICE: verify_flow_info: loop_father but no loops

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2006-11-19 02:59 ---
Created an attachment (id=12643)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12643&action=view)
New patch, the old one could cause a seg fault also during bootstrap

I forgot when I changed loops to current_loops to check if current_loops was
NULL.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #12642|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29879