[Bug c/36004] New: gcc bug on alpha

[oliver at linux-kernel dot at]

Testcase:
#include 
#include 

struct Tst { unsigned char data[1]; };

int main(void)
{
struct Tst *tst = malloc(sizeof(struct Tst) + 10);
unsigned char *tmp = tst->data;

tst->data[0] = 0;
tmp[0] = 1;
tmp[1] = 2;

printf("%x %x\n", tmp[0], tmp[1]);
printf("%x %x\n", tst->data[0], tst->data[1]);
printf("%p %p\n", &tmp[0], &tmp[1]);
printf("%p %p\n", &tst->data[0], &tst->data[1]);
return 0;
}


Produces on x86_64 (Dell PC, Core 2 Duo)
1 2
1 2
0x601010 0x601011
0x601010 0x601011

Produces on alpha (DS10, EV67, Fedora 8)
1 2
1 1
0x120012010 0x120012011
0x120012010 0x120012011

Produces on ia64 (SLES 10.1)
1 2
1 2
0x60004010 0x60004011
0x60004010 0x60004011

If you need access to an alpha, I can arrange this!

Sorry, if the component is wrong.


-- 
   Summary: gcc bug on alpha
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oliver at linux-kernel dot at
 GCC build triplet: alpha-redhat-linux
  GCC host triplet: alpha-redhat-linux
GCC target triplet: alpha-redhat-linux


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

[Bug c/36005] New: strange new error: invalid use of void expression in trunk

[marcus at jet dot franken dot de]

with the current GCC trunk checkout I suddenly get an error in attached
testcase.

Not sure if it is valid c.

/home/marcus/projects/gcc.trunk/BIN/bin/gcc -m32 -c  -O2  vxd.i
vxd.i: In function 'VXD_Win32s':
vxd.i:13: error: invalid use of void expression


-- 
   Summary: strange new error: invalid use of void expression in
trunk
   Product: gcc
   Version: 4.4.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=36005

[Bug target/36004] gcc bug on alpha

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal
  Component|c   |target


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

[Bug c/36005] strange new error: invalid use of void expression in trunk

[marcus at jet dot franken dot de]

--- Comment #1 from marcus at jet dot franken dot de  2008-04-22 07:33 
---
Created an attachment (id=15508)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15508&action=view)
vxd.i

gcc -m32 -O2 -c vxd.i


-- 


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

[Bug c++/35650] [4.1/4.2/4.3/4.4 Regression] Can't bind ref-to-function through using-decl. in namespace

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||04/msg01609.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-03-20 19:55:23 |2008-04-22 07:37:27
   date||


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

[Bug target/27880] [4.2/4.3/4.4 regression] undefined reference to `_Unwind_GetIPInfo'

[vapier at gentoo dot org]

--- Comment #24 from vapier at gentoo dot org  2008-04-22 07:51 ---
the proposed patch in question seems to break the opposite scenario on ia64:
--without-system-libunwind


-- 

vapier at gentoo dot org changed:

   What|Removed |Added

 CC||toolchain at gentoo dot org


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

[Bug target/35982] [4.3 regression] ICE while building mplayer on ppc with -O3 -ffast-math -mcpu=970

[irar at il dot ibm dot com]

--- Comment #4 from irar at il dot ibm dot com  2008-04-22 07:57 ---
The problem here is that we do not check the types of interleaved data-refs,
but only their steps (and since float and int are of the same size here, their
steps are equal). And then we treat all the data-refs as if they were of the
same type, the type of the first scalar load, i.e., float in this case.
Therefore, the conversion from vector int to vector float fails, since we have
vector floats on both sides.

It seems like we better prevent vectorization of such mixed types for 4.3.1.
For 4.4 we can do all the loads and permutations on one type, but later convert
to the correct type before performing any operation on the extracted elements.

Ira


-- 

irar at il dot ibm dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |irar at il dot ibm dot com
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-04-21 15:08:02 |2008-04-22 07:57:11
   date||


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

[Bug target/29096] faster _mm_cvtpi32x2_ps for xmmintrin.h

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2008-04-22 08:36 ---
I have tested a couple of approaches using following code:

--cut here--
#include 

__m128 test_0 (__m64 __A, __m64 __B)
{
  __v4sf __zero = (__v4sf) _mm_setzero_ps ();
  __v4sf __sfa = __builtin_ia32_cvtpi2ps (__zero, (__v2si)__A);
  __v4sf __sfb = __builtin_ia32_cvtpi2ps (__zero, (__v2si)__B);
  return (__m128) __builtin_ia32_movlhps (__sfa, __sfb);
}

__m128 test_1 (__m64 __A, __m64 __B)
{
  __v4sf __sfa = __builtin_ia32_cvtpi2ps (__sfa, (__v2si)__A);
  __v4sf __sfb = __builtin_ia32_cvtpi2ps (__sfa, (__v2si)__B);
  return (__m128) (__sfa = __builtin_ia32_movlhps (__sfa, __sfb));
}

__m128 test_2 (__m64 __A, __m64 __B)
{
  __v4sf __zero = (__v4sf) _mm_setzero_ps ();
  __v4sf __sfa = __builtin_ia32_cvtpi2ps (__zero, (__v2si)__A);

  __sfa = __builtin_ia32_movlhps (__sfa, __sfa);
  return (__m128) __builtin_ia32_cvtpi2ps (__sfa, (__v2si)__B);
}

__m128 test_3 (__m64 __A, __m64 __B)
{
  __v4sf __zero = (__v4sf) _mm_setzero_ps ();
  __v4sf __sfa = __builtin_ia32_cvtpi2ps (__zero, (__v2si)__A);
  __v4sf __sfb = __builtin_ia32_cvtpi2ps (__sfa, (__v2si)__B);

  return (__m128) __builtin_ia32_movlhps (__sfa, __sfb);
}

#define N 1024*1024

int main()
{
  __v2si *a, *b;
  __v4sf *c;

  int i;

  a = _mm_malloc (N * sizeof (__v2si), 16);
  b = _mm_malloc (N * sizeof (__v2si), 16);
  c = _mm_malloc (N * sizeof (__v4sf), 16);

  for (i = 0; i < N; i++)
c[i] = test_X (a[i], b[i]);

  return 0;
}
--cut here--

gcc -O2 -msse2 -fomit-frame-pointer:

test_0:
xorps   %xmm1, %xmm1
movaps  %xmm1, %xmm0
cvtpi2ps%mm0, %xmm0
cvtpi2ps%mm1, %xmm1
movlhps %xmm1, %xmm0
ret

test_1:
xorps   %xmm0, %xmm0
cvtpi2ps%mm0, %xmm0
movaps  %xmm0, %xmm1
cvtpi2ps%mm1, %xmm1
movlhps %xmm1, %xmm0
ret

test_2:
xorps   %xmm0, %xmm0
cvtpi2ps%mm0, %xmm0
movlhps %xmm0, %xmm0
cvtpi2ps%mm1, %xmm0
ret

test_3:
xorps   %xmm0, %xmm0
cvtpi2ps%mm0, %xmm0
movaps  %xmm0, %xmm1
cvtpi2ps%mm1, %xmm1
movlhps %xmm1, %xmm0
ret

Timings (10 samples) on xeon-3.6 (32bit):

0: 0.6500s +- 0.03633
1: 0.5868s +- 0.04212
2: 0.7684s +- 0.06498
3: 0.5812s +- 0.03919

Since this is a low-hanging fruit, let's change this function to faster
implementation.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-22 08:36:08
   date||


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

[Bug c/36005] strange new error: invalid use of void expression in trunk

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-04-22 08:58 ---


*** This bug has been marked as a duplicate of 35992 ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/35992] [4.4 Regression] Linux kernel code fails to compile with -Os

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-04-22 08:58 ---
*** Bug 36005 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||marcus at jet dot franken
   ||dot de


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

[Bug tree-optimization/18754] unrolling happens too late/SRA does not happen late enough

[rguenth at gcc dot gnu dot org]

--- Comment #19 from rguenth at gcc dot gnu dot org  2008-04-22 09:31 
---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-08-12 16:58:50 |2008-04-22 09:31:17
   date||


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

[Bug c++/35758] [4.3/4.4 Regression] vector_size attribute lost in function arguments for templates

[jakub at gcc dot gnu dot org]

--- Comment #16 from jakub at gcc dot gnu dot org  2008-04-22 09:48 ---
Especially for 4.3.x getting rid of the
"HACK. GROSS. This is absolutely disgusting."
might not be something desirable for a stable branch.  We've lived with this
gross absolutely disgusting hack for more than 7 years, and the:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00630.html
patch doesn't make the hack IMHO any more disgusting than it was till now,
but fixes an important regression.


-- 


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

[Bug tree-optimization/34223] missed optimization - complete unrolling pass before the vectorizer

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-04-22 09:51 ---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Keywords||missed-optimization
   Last reconfirmed|2007-11-25 12:50:00 |2008-04-22 09:51:07
   date||


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

[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted

[jakub at gcc dot gnu dot org]

--- Comment #16 from jakub at gcc dot gnu dot org  2008-04-22 10:01 ---
Downgrading to P2, the patches so far all seem to be quite risky for the
branches, the wrong-code is on a corner case and isn't a recent regression.

Regarding the comment #14 patch, I'd say the complete_type should be different
from argtype only when !TYPE_UNSIGNED (argtype), for unsigned char or unsigned
short the overflow behavior is well defined.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P1  |P2


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

[Bug tree-optimization/36006] New: [4.4 regression] invalid rtl with -O2

[fxcoudert at gcc dot gnu dot org]

The following is a regression observed with build == host == i686-pc-mingw32
and target == x86_64-pc-mingw32, built from mainline sources. It used to pass
with a build dated 2007-11-30.


$ cat Codelet.f90
program test
  integer, parameter :: wp = 4
  complex(wp), parameter :: i = (0._wp, 1._wp)
  complex(wp) :: c(12)
  integer :: m, N

  N = 12
  c = (/(exp(i*m),m=1,N)/)
  print *, c(1)
end

$ x86_64-pc-mingw32-gfortran Codelet.f90 -O2 -c
Codelet.f90: In function 'test':
Codelet.f90:9: error: invalid rtl sharing found in the insn
(insn 155 154 156 2 Codelet.f90:8 (set (subreg:DI (reg:SC 108) 0)
(reg:DI 154)) -1 (nil))
Codelet.f90:9: error: shared rtx
(subreg:DI (reg:SC 108) 0)
Codelet.f90:9: internal compiler error: internal consistency failure

$ x86_64-pc-mingw32-gfortran -v
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with: ../../trunk/configure --prefix=/home/FX/irun64
--build=i586-pc-mingw32 --target=x86_64-pc-mingw32 --with-gmp=/home/FX/local
--enable-languages=c,fortran --disable-werror --disable-nls --enable-threads
Thread model: win32
gcc version 4.4.0 20080421 (experimental) [trunk revision 134506] (GCC)


-- 
   Summary: [4.4 regression] invalid rtl with -O2
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
 GCC build triplet: i686-pc-mingw32
  GCC host triplet: i686-pc-mingw32
GCC target triplet: x86_64-pc-mingw32


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

[Bug tree-optimization/36006] [4.4 regression] invalid rtl with -O2

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2008-04-22 10:08 
---
Created an attachment (id=15509)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15509&action=view)
All tree dumps (from -fdump-tree-all) for the testcase


-- 


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

[Bug ada/36007] New: [4.4 regression] verify_gimple failed

[schwab at suse dot de]

/tmp/cvs/gcc-20080422/Build/./gcc/xgcc -B/tmp/cvs/gcc-20080422/Build/./gcc/
-B/tmp/cvs/gcc-20080422/Build/root/ia64-suse-linux/bin/
-B/tmp/cvs/gcc-20080422/Build/root/ia64-suse-linux/lib/ -isystem
/tmp/cvs/gcc-20080422/Build/root/ia64-suse-linux/include -isystem
/tmp/cvs/gcc-20080422/Build/root/ia64-suse-linux/sys-include -c -g -O2 -fPIC
-DUSE_GAS_SYMVER  -W -Wall -gnatpg  a-swmwco.ads -o a-swmwco.o
a-swmwco.ads: In function 'Ada.Strings.Wide_Maps.Wide_Constants':
a-swmwco.ads:40: error: non-trivial conversion at assignment
const struct ada__strings__wide_maps__wide_character_ranges___XUB *
struct ada__strings__wide_maps__wide_character_ranges___XUB *
ada__strings__wide_maps__wide_constants__control_set.set.P_BOUNDS =
&ada__strings__wide_maps__wide_constants__control_ranges.F.BOUNDS
a-swmwco.ads:40: error: non-trivial conversion at assignment
const struct ada__strings__wide_maps__wide_character_ranges___XUB *
struct ada__strings__wide_maps__wide_character_ranges___XUB *
ada__strings__wide_maps__wide_constants__graphic_set.set.P_BOUNDS =
&ada__strings__wide_maps__wide_constants__graphic_ranges.F.BOUNDS
+===GNAT BUG DETECTED==+
| 4.4.0 20080422 (experimental) [trunk revision 134549] (ia64-suse-linux-gnu)
GCC error:|
| verify_gimple failed |
| Error detected at a-swmwco.ads:449:6 |


-- 
   Summary: [4.4 regression] verify_gimple failed
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, build
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
GCC target triplet: ia64-*-linux


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

[Bug target/29096] faster _mm_cvtpi32x2_ps for xmmintrin.h

[uros at gcc dot gnu dot org]

--- Comment #2 from uros at gcc dot gnu dot org  2008-04-22 12:41 ---
Subject: Bug 29096

Author: uros
Date: Tue Apr 22 12:41:14 2008
New Revision: 134558

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134558
Log:
PR target/29096
* config/i386/xmmintrin.h (_mm_cvtpi16_ps): Rearrange calls to
builtin functions to generate faster code.
(_mm_cvtpu16_ps): Ditto.
(_mm_cvtpi32x2_ps): Ditto.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/xmmintrin.h


-- 


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

[Bug target/29096] faster _mm_cvtpi32x2_ps for xmmintrin.h

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2008-04-22 12:52 ---
Implemented in 4.4.0


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||04/msg01641.html
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug c++/35747] [4.3/4.4 regression] ICE with undefined variable in statement expression

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-04-22 13:12 ---
Apparently missing pop_stmt_list during error handling.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-03-30 00:52:26 |2008-04-22 13:12:19
   date||


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

[Bug middle-end/36003] [4.4 Regression] df-byte-scan.c changes broke cris-elf compiling libgcc

[zadeck at gcc dot gnu dot org]

--- Comment #2 from zadeck at gcc dot gnu dot org  2008-04-22 13:44 ---
Subject: Bug 36003

Author: zadeck
Date: Tue Apr 22 13:43:47 2008
New Revision: 134559

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134559
Log:
2008-04-22  Kenneth Zadeck <[EMAIL PROTECTED]>

PR middle-end/36003
* passes.c (init_optimization_passes): Remove
pass_fast_rtl_byte_dce.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/passes.c


-- 


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

[Bug c/36008] New: Function produces wrong results when inlined.

[xavier at tddft dot org]

When the attached source file is compiled with 'gcc -O3 -c', the code that uses
it produces wrong results. The problem disappears if 'gcc -O3 -fno-inline -c'
or if the variables inside 'generate_point_symmetry' are declared as 'static'.

This is the output of gcc-4.3 -v :

Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.3/configure --prefix=/opt/gcc/ --program-suffix=-4.3
--enable-languages=c,fortran,c++ --with-arch=core2 --enable-libgomp
Thread model: posix
gcc version 4.3.1 20080419 (prerelease) (GCC) 

This is the system:

Linux corvo 2.6.24.2-corvo-001 #3 SMP PREEMPT x86_64 GNU/Linux
distribution is Debian GNU/Linux 4.0


-- 
   Summary: Function produces wrong results when inlined.
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xavier at tddft dot org
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c/36008] Function produces wrong results when inlined.

[xavier at tddft dot org]

--- Comment #1 from xavier at tddft dot org  2008-04-22 13:53 ---
Created an attachment (id=15510)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15510&action=view)
the code


-- 


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

[Bug c/36008] Function produces wrong results when inlined.

[aldot at gcc dot gnu dot org]

--- Comment #2 from aldot at gcc dot gnu dot org  2008-04-22 14:13 ---
Please provide a self-contained testcase (see http://gcc.gnu.org/bugs.html )
that ideally abort()s on a wrong result.


-- 


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

[Bug tree-optimization/36009] New: PRE causes missed loop store motion, store sinking doesn't work

[rguenth at gcc dot gnu dot org]

double a[16][64], y[64], x[16];
void foo(void)
{
  int i, j;
  for (j = 0; j < 64; ++j)
for (i = 0; i < 16; ++i)
  y[j] = y[j] + a[i][j] * x[i];
}

PRE moves the load of y[j] out of the inner loop like

pretmp = y[j];
for (i = 0; i < 16; ++i)
  {
D.xxx = pretmp + a[i][j] * x[i];
storetmp = D.xxx;
y[j] = storetmp;
  }

which makes loop store motion no longer apply (store sinking is too
broken to fix this as well).


-- 
   Summary: PRE causes missed loop store motion, store sinking
doesn't work
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
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=36009

[Bug c++/35325] [4.3/4.4 regression] ICE with fixed-point types in template parameter

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2008-04-22 14:44 ---
fixed


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/36010] New: Loop interchange not performed

[rguenth at gcc dot gnu dot org]

For the testcase

double a[16][64], y[64], x[16];
void foo(void)
{
  int i, j;
  for (j = 0; j < 64; ++j)
for (i = 0; i < 16; ++i)
  y[j] = y[j] + a[i][j] * x[i];
}

with -O2 -fno-tree-pre -fno-tree-loop-im -ftree-loop-linear loop interchange
is performed but with PRE or lim moving the load (and the store) from/to
y[j] out of the innermost loop the interchange is no longer performed because

  before = gcc_loopnest_to_lambda_loopnest (loop_nest, &oldivs,
&invariants, &lambda_obstack);

returns NULL.


-- 
   Summary: Loop interchange not performed
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
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=36010

[Bug tree-optimization/36011] New: Loop interchange not performed, data dependence analysis defect

[rguenth at gcc dot gnu dot org]

For the testcase

double a[16][16][64], y[16][64], x[16][16];

void foo(void)
{
  int i, j, k;
  for (k = 0; k < 16; ++k)
for (j = 0; j < 64; ++j)
  for (i = 0; i < 16; ++i)
{
  y[k][j] = y[k][j] + a[k][i][j] * x[k][i];
}
}

loop interchange is performed with -O2 -fno-tree-pre -fno-tree-loop-im
-ftree-loop-linear but not with PRE or lim moving the store/load to/from
y[k][j].  The interchange fails because

/* Validate the resulting matrix.  When the transformation
   is not valid, reverse to the previous transformation.  */
if (!lambda_transform_legal_p (trans, depth, dependence_relations))

returns false which is because constants or SSA names from final values
leak into the access fns like

(compute_affine_dependence
  (stmt_a =
pretmp.11_3 = y[k_41][j_40])
  (stmt_b =
y[k_41][j_40] = D.1578_20)
(subscript_dependence_tester
(analyze_overlapping_iterations
  (chrec_a = {0, +, 1}_2)
  (chrec_b = 63)
(analyze_siv_subscript
)
  (overlap_iterations_a = [63]
)
  (overlap_iterations_b = [0]
)

which confuses dependency analysis here:

  else if (!operand_equal_p (access_fn_a, access_fn_b, 0))
{
  /* This can be for example an affine vs. constant dependence
 (T[i] vs. T[3]) that is not an affine dependence and is
 not representable as a distance vector.  */
  non_affine_dependence_relation (ddr);
  return false;


-- 
   Summary: Loop interchange not performed, data dependence analysis
defect
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
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=36011

[Bug tree-optimization/36010] Loop interchange not performed

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-04-22 15:19 ---
perfect_nestify needs to be enhanced to handle this I guess.  In fact we cannot
distribute these loops but need to undo what PRE/lim do.


-- 


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

[Bug tree-optimization/36010] Loop interchange not performed

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-04-22 15:22 ---
Bwaves from SPEC2006 has

...
   do l=1,nb
  y(l,i,j,k)=0.0d0
  do m=1,nb
 y(l,i,j,k)=y(l,i,j,k)+
 1   a(l,m,i,j,k)*x(m,i,j,k)+
 2   axp(l,m,i,j,k)*x(m,ip1,j,k)+
 3   ayp(l,m,i,j,k)*x(m,i,jp1,k)+
 4   azp(l,m,i,j,k)*x(m,i,j,kp1)+
 5   axm(l,m,i,j,k)*x(m,im1,j,k)+
 6   aym(l,m,i,j,k)*x(m,i,jm1,k)+
 7   azm(l,m,i,j,k)*x(m,i,j,km1)
  enddo
   enddo

which we don't distribute either (even with PRE/lim turned off).


-- 


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

[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants

[tromey at gcc dot gnu dot org]

--- Comment #10 from tromey at gcc dot gnu dot org  2008-04-22 15:24 ---
I think this should be fixable now that mapped locations have gone in.
The key is to have c_lex_with_flags return a value for in_system_header
which comes from the token's "original" location, not the macro expansion
location.  I am not sure if this will do the right thing with token pasting.
And, it probably will not work for something like:

/* system */
#define F(x) x
/* user */
F(somethingToCauseAWarning)

It isn't clear to me whether we would want the warning here or not.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org


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

[Bug c++/36012] New: Wrong initialization in operator new.

[s__nakayama at infoseek dot jp]

testcase
#include 
struct foo
{ 
  virtual void bar(){ }
  int foo::*baz;
};

int main()
{
  foo* x = new foo();
  assert (x->baz == foo().baz);
}

result
$ g++43 bug.cpp -o bag; ./bug
assertion "x->baz == foo().baz" failed: file "bug.cpp", line 11


-- 
   Summary: Wrong initialization in operator new.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp


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

[Bug middle-end/36013] New: Wrong code involving restricted pointers to non-restricted pointers

[rainy6144 at gmail dot com]

The program below aborts at runtime when compiled by gcc 4.3.0 with option "-O2
-std=c99" (it runs correctly without optimization or when compiled with "icc
-std=c99 -restrict").  I believe it should have defined behavior according to
the standard (see e.g. PR14192), for p[0] and q[0] are not restricted pointers,
and p[0][0] is based on p[0] but not p.  Intuitively, p and q should behave
like two different arrays of pointers, and we may well want to store aliasing
pointers into them.

This is apparently due to the simplistic find_base_decl() in 4.3.0, which is
quite different the standard's definition of "based on".  If I understand
correctly, for two pointers p and q, only when p is provably based on some
restricted pointer p0 (along all control paths), and q is provably not based on
it, can we be sure that a modification to *q can never change *p.

>From a casual glance of the 4.3.0 source, it seems that "restrict" is not well
supported by the tree passes, but the alias sets in the generated RTL make some
use of it.  Proper support, either at RTL or tree level, may mean a lot of
work, but in the meantime we had better agree on the meaning of the standard
and avoid generating wrong code :)

==
#include 

/* fail by gcc-4.3.0 */
void f(int **restrict p, int **restrict q)
{
  p[0][0] = 1;
  q[0][0] = 2;
  if (p[0][0] != 2) abort();
}

int main(void)
{
  int a;
  int *p1 = &a, *p2 = &a;
  f(&p1, &p2);
  return 0;
}


-- 
   Summary: Wrong code involving restricted pointers to non-
restricted pointers
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rainy6144 at gmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/36014] New: gcc produces broken code when -mregparm=3

[simon at sxw dot org dot uk]

gcc produces broken function entry code when building code with incomplete
prototypes, and -mregparm=3.

The following test case illustrates the problem ...

extern int printf (const char *, ...) __attribute__ ((regparm(0)));

static int test();

int main(int argc, char **argv) {

  test(0,1,2,3,4,5,6,7);
}

static int test(int a, int b, int c, int d, int e, int f, int g, int h) {
  if (a != 0 || b != 1 || c != 2) {
printf("Wrong: Got (%p, %p, %p, %p, %p, %p, %p, %p)", a, b, c, d, e, f, g,
h);
  }

  return 1;
}

When built with gcc -mregparm=3, and run, this produces:

Wrong: Got (0x1, 0xbfc96430, 0xbfc96410, (nil), 0x1, 0x2, 0x3, 0x4)


-- 
   Summary: gcc produces broken code when -mregparm=3
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simon at sxw dot org dot uk
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


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

[Bug target/36015] New: [4.3/4.4 Regression] -mregparm and fn decls without arguments

[jakub at gcc dot gnu dot org]

/* { dg-do run } */
/* { dg-options "-O0" } */
/* { dg-options "-O0 -mregparm=3" { target { { i?86-*-* x86_64-*-* } && ilp32 }
} } */

static int test ();

int
main (void)
{
  test (0, 1, 2, 3, 4, 5, 6, 7);
  return 0;
}

static int
test (int a, int b, int c, int d, int e, int f, int g, int h)
{
  if (a != 0 || b != 1 || c != 2 || d != 3
  || e != 4 || f != 5 || g != 6 || h != 7)
__builtin_abort ();
  return 0;
}

used to work until 4.2.x (tested 3.2, 3.3, 3.4, 4.0, 4.1, 4.2) - in all cases
test was passed arguments in 3 regs by the caller and expecting them there.


-- 
   Summary: [4.3/4.4 Regression] -mregparm and fn decls without
arguments
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: i686-linux


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

[Bug c/36014] gcc produces broken code when -mregparm=3

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-04-22 16:15 ---


*** This bug has been marked as a duplicate of 36015 ***


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/36015] [4.3/4.4 Regression] -mregparm and fn decls without arguments

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-04-22 16:15 ---
*** Bug 36014 has been marked as a duplicate of this bug. ***


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||simon at sxw dot org dot uk


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

[Bug target/34163] 10% performance regression since Nov 1 on Polyhedron's "NF" on AMD64

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2008-04-22 16:43 ---
(In reply to comment #2)
> Well, this bug needs proper analysis and a testcase, but yes, I also see this
> slowdown.

Richi, the only difference in generated code is by backing out your patch [1]

[1] http://gcc.gnu.org/viewcvs?view=rev&revision=129796

Other suspected patches have no effect on generated code for "gfortran
-march=opteron -ffast-math -funroll-loops -ftree-loop-linear -ftree-vectorize
-msse3 -O3"

I will check execution times, but since I have Core2, perhaps there will be no
slowdown. Can you try to benchmark on your target with [1] backed out?


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug target/34163] 10% performance regression since Nov 1 on Polyhedron's "NF" on AMD64

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2008-04-22 16:51 ---
Confirmed also on core2:

benchmarked with patch:

22 Apr 2008 18:47:04 gfortran - Compile nf
command=gfortran -march=opteron -ffast-math -funroll-loops -ftree-loop-linear
-ftree-vectorize -msse3 -O3 nf.s -o nf

22 Apr 2008 18:47:04 gfortran - Execute nf
nf Run #   121.4634021.46340 - Error=100.%
nf Run #   221.4586021.46100 - Error=  0.0112%

Geometric Mean Execution Time =  21.46 seconds

benchmarked without patch:

22 Apr 2008 18:44:51 gfortran - Compile nf
command=gfortran -march=opteron -ffast-math -funroll-loops -ftree-loop-linear
-ftree-vectorize -msse3 -O3 nf.s -o nf

22 Apr 2008 18:44:51 gfortran - Execute nf
nf Run #   119.4612019.46120 - Error=100.%
nf Run #   219.4620019.46160 - Error=  0.0021%

Geometric Mean Execution Time =  19.46 seconds


-- 


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

[Bug c/36008] Function produces wrong results when inlined.

[xavier at tddft dot org]

--- Comment #3 from xavier at tddft dot org  2008-04-22 17:16 ---
The code comes from spglib, a library to calculate symmetry groups from
crystals, so it is quite complex. The problem is that I didn't wrote it I don't
understand it enough to be able to produce a small self-contained test case. I
will try to do it, but this may take me some time.


-- 


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

[Bug testsuite/35981] FAIL: gcc.dg/utf-cvt.c (test for warnings, line 46/47) with -m64

[janis at gcc dot gnu dot org]

--- Comment #5 from janis at gcc dot gnu dot org  2008-04-22 17:21 ---
Subject: Bug 35981

Author: janis
Date: Tue Apr 22 17:20:40 2008
New Revision: 134562

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134562
Log:
2008-04-22  Kris Van Hees <[EMAIL PROTECTED]>

PR testsuite/35981
* g++.dg/ext/utf-cvt.C: Handle 64-bit platforms correctly.
Add tests for 'long long'.
* gcc.dg/utf-cvt.c: Handle 64-bit platforms correctly.
Add tests for 'long long'.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/utf-cvt.C
trunk/gcc/testsuite/gcc.dg/utf-cvt.c


-- 


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

[Bug c++/36016] New: for-loop scoping problem: Method gets called after destructor

[gnu4u at flonatel dot org]

Hello!

In my opinion the g++ compiler has a problem with for-loop scoping.  (Please
see attached code snipplet.)  The output of the program is:

+++ For Loop +++
Constructor of LoopMe with=98
Destructor of LoopMe with=98
LoopMe op+= called
 I'm invalid and destroyed already 
Constructor of LoopMe with=99
Destructor of LoopMe with=99
LoopMe op+= called
 I'm invalid and destroyed already 
Constructor of LoopMe with=100
Destructor of LoopMe with=100
+++ While Loop +++
Constructor of LoopMe with=98
LoopMe op+= called
Destructor of LoopMe with=98
Constructor of LoopMe with=99
LoopMe op+= called
Destructor of LoopMe with=99
Constructor of LoopMe with=100
Destructor of LoopMe with=100

IMHO the while loop is correct, while in the for loop, the destructor is called
too early.

It was also possible to reproduce this on the following architectures:
   * g++ (GCC) 3.3.2 [Build from original sources]
  (sparc, Solaris 8)
   * g++ (GCC) 4.1.0 [Build from original sources]
  (sparc, Solaris 9)
   * g++ (GCC) 4.1.0 [Build from original sources]
  (x86, Redhat9 with kernel 2.6.12.3)
   * g++ (GCC) 4.2.3 (Debian 4.2.3-2) 
  (x86, Debian unstable with kernel 2.6.24-1-686)
   * g++ (GCC) 4.2.3 (Debian 4.2.3-1)
  (x86, Debian unstable with kernel 2.6.23-1-686)
   * g++-4.3 (Debian 4.3-20080227-1) 4.3.0 20080227 (prerelease)
[gcc-4_3-branch revision 132730]
  (x86, Debian unstable with kernel 2.6.24-1-686)

Some searches in this bug database revealed, that Bug#13865 and Bug#16034 look
similar, but both are marked as fixed for some years now.

If you need additional information, just drop me a mail.

Kind regards

Andreas Florath


-- 
   Summary: for-loop scoping problem: Method gets called after
destructor
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu4u at flonatel dot org
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug c++/36016] for-loop scoping problem: Method gets called after destructor

[gnu4u at flonatel dot org]

--- Comment #1 from gnu4u at flonatel dot org  2008-04-22 17:29 ---
Created an attachment (id=15511)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15511&action=view)
Source to reproduce the bug


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[Ralf dot Wildenhues at gmx dot de]

--- Comment #56 from Ralf dot Wildenhues at gmx dot de  2008-04-22 17:51 
---
Subject: Re:  [4.3/4.4 Regression]: Combined gcc +
binutils source tree doesn't bootstrap with --enable-shared

* bonzini at gnu dot org wrote on Tue, Apr 22, 2008 at 08:27:07AM CEST:
> > So I'm not yet convinced this particular race to be a Libtool bug.
> 
> ... but you can assume it "is created once and for all" after it is 
> built (something you can guarantee with Makefile rules).  That's an 
> invariant that libtool's relinking breaks, and that atomic operation 
> would restore.

OK, I understood the issue now.  I'll fix Libtool.  Thanks for
explaining, and persevering.

> Another possibility would be to force libtool to relink at linking time, 
> i.e. keep the fast install, but do the relinking even before the program 
> is invoked (and the wrapper script installed).  But I assume it is a mess?

Yes, that sounds like a mess.


-- 


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

[Bug target/34163] 10% performance regression since Nov 1 on Polyhedron's "NF" on AMD64

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-04-22 18:14 ---
(In reply to comment #3)
> [1] http://gcc.gnu.org/viewcvs?view=rev&revision=129796

It was a correctness fix, which usually will slow down generated code. :)

So you have to look at the difference to make sure that the code generated
before was actually producing no overflows.

Thanks,
Andrew Pinski


-- 


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

[Bug c++/35316] [4.2/4.3/4.4 regression] ICE with typeof/decltype and bit-fields

[jason at gcc dot gnu dot org]

-- 

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 |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-03-03 16:23:09 |2008-04-22 18:38:04
   date||


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

[Bug fortran/35994] [4.3/4.4 regression] MAXLOC and MINLOC off by one with mask

[tkoenig at gcc dot gnu dot org]

--- Comment #2 from tkoenig at gcc dot gnu dot org  2008-04-22 18:43 ---
$ gfortran ga4076.f90 
$ ./a.out
   1 100 T
   2 101 F
   3   1 T
   4  52 F
$ gfortran-4.2 ga4076.f90 
$ ./a.out
   1 100 T
   2 100 T
   3   1 T
   4  51 T
$ gfortran-4.3 -static ga4076.f90 
$ ./a.out
   1 100 T
   2 101 F
   3   1 T
   4  52 F


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2008-04-20 20:50:27 |2008-04-22 18:43:07
   date||
Summary|MAXLOC and MINLOC off by one|[4.3/4.4 regression] MAXLOC
   |with mask   |and MINLOC off by one with
   ||mask
   Target Milestone|--- |4.3.1


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

[Bug fortran/35993] [4.3/4.4 regression] wrong answer for PRODUCT with scalar mask

[tkoenig at gcc dot gnu dot org]

--- Comment #2 from tkoenig at gcc dot gnu dot org  2008-04-22 18:46 ---
A regression (well, sort of; 4.2 failed with the bogus
error message, but at least it didn't generate wrong code):

$ gfortran-4.2 foo.f90 
$ ./a.out
Fortran runtime error: rank of return array does not equal 1


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|wrong answer for PRODUCT|[4.3/4.4 regression] wrong
   |with scalar mask|answer for PRODUCT with
   ||scalar mask
   Target Milestone|--- |4.3.1


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

[Bug fortran/35995] ANY, ALL, and COUNT errors for zero sized sections

[tkoenig at gcc dot gnu dot org]

--- Comment #2 from tkoenig at gcc dot gnu dot org  2008-04-22 18:48 ---
Not a regression, 4.1 through 4.4 all fail.


-- 


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

[Bug fortran/35988] run-time abort for MATMUL of run-time zero sized array

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2008-04-22 18:50 ---
Not a regression, 4.1 and 4.2 fail with the equally bogus
error message

a.out:
../../../../../gcc/branches/gcc-4_1-branch/libgfortran/generated/matmul_r4.c:152:
matmul_r4: Assertion `count == b->dim[0].ubound + 1 - b->dim[0].lbound' failed.


-- 


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

[Bug fortran/35994] [4.3/4.4 regression] MAXLOC and MINLOC off by one with mask

[tkoenig at gcc dot gnu dot org]

--- Comment #3 from tkoenig at gcc dot gnu dot org  2008-04-22 18:57 ---
This one is seriously strange.

It depends on the mask argument being a compile-time constant.
Apparently, simplification goes down a wrong path somewhere.
Looking at the 

$ cat try.f90
  program GA4076

! fails on Windows XP
! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139]

  REAL DDA(100)
  dda = (/(J1,J1=1,100)/)

  IDS = MAXLOC(DDA,1, (/(J1,J1=1,100)/) > 50)
  print *, 2, ids, ids.eq.100 !expect 100

  END 
$ gfortran -fdump-tree-original try.f90
$ ./a.out
   2 101 F

The loop generated for maxloc lacks any reference to the mask:

  pos.2 = 0;
  {
integer(kind=4) S.6;

S.6 = 1;
while (1)
  {
if (S.6 > 100) goto L.1;
if (A.5[S.6 + -1])
  {
offset.3 = 1;
if (dda[S.6 + -1] > limit.4 || pos.2 == 0 && dda[S.6 + -1] ==
limit.4)
  {
limit.4 = dda[S.6 + -1];
pos.2 = S.6 + offset.3;
  }
  }
S.6 = S.6 + 1;
  }
L.1:;
  }
  ids = pos.2;
}

The following works:

$ cat try2.f90
  program GA4076

  REAL DDA(100)
  dda = (/(J1,J1=1,100)/)

  IDS = MAXLOC(DDA,1, dda > 50)
  print *, 2, ids, ids.eq.100 !expect 100

  END 
$ gfortran try2.f90
$ ./a.out
   2 100 T

Paul, can you maybe shed any light on this?


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot org


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

[Bug rtl-optimization/36017] New: [4.3/4.4 Regression] Miscompilation of tail call sqrt

[jakub at gcc dot gnu dot org]

extern double sqrt (double);
extern void abort (void);

__attribute__((noinline)) double
foo (double a)
{
  double b, c, d = 0.7;
  if (a <= d)
b = sqrt (d * a);
  else
{
  c = (1.0 - d) * (1.0 - a);
  b = c > 0 ? 1.0 - sqrt (c) : 1.0;
}
  return b;
}

int
main (void)
{
  double c = foo (0.5);
  __builtin_printf ("%g %g\n", c, sqrt (0.7 * 0.5));
  if (c > 0.5917)
abort ();
  return 0;
}

is miscompiled at -O2 -lm on x86_64-linux, works at -O2
-fno-optimize-sibling-calls.  The problem is that expand_errno_check is being
called on a CALL_EXPR with CALL_EXPR_TAILCALL set, and thus the expanded call
doesn't ever return.  In the likely case that the insn didn't return a NaN
the code jumps around the call, but in this case it doesn't jump to code
following the call (as it doesn't return), but to whatever code comes next.
I'll try to find out why this isn't miscompiled in 4.2.
Anyway, either we should simply clear the CALL_EXPR_TAILCALL bit in
expand_errno_check, or we should branch to (return), rather than a label
emitted
after the call if CALL_EXPR_TAILCALL is set.


-- 
   Summary: [4.3/4.4 Regression] Miscompilation of tail call sqrt
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: critical
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-linux


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

[Bug rtl-optimization/36017] [4.3/4.4 Regression] Miscompilation of tail call sqrt

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |4.3.1


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

[Bug fortran/35993] [4.3/4.4 regression] wrong answer for PRODUCT with scalar mask

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug fortran/35994] [4.3/4.4 regression] MAXLOC and MINLOC off by one with mask

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug target/36015] [4.3/4.4 Regression] -mregparm and fn decls without arguments

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.1


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

[Bug rtl-optimization/36017] [4.3/4.4 Regression] Miscompilation of tail call sqrt

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-04-22 19:53 ---
4.2 would recreate the call:

  /* Wrap the computation of the argument in a SAVE_EXPR, as we may
 need to expand the argument again.  This way, we will not perform
 side-effects more the once.  */
  narg = builtin_save_expr (arg);
  if (narg != arg)
{
  arg = narg;
  arglist = build_tree_list (NULL_TREE, arg);
  exp = build_function_call_expr (fndecl, arglist);
}

and thus the CALL_EXPR_TAILCALL bit would be lost.  Now if target = expand_unop
(mode, builtin_optab, op0, target, 0); fails, then it is certainly better to
preserve the CALL_EXPR_TAILCALL bit.  But for the errno check we need to either
clear it, or branch to (return).


-- 


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

[Bug rtl-optimization/36017] [4.3/4.4 Regression] Miscompilation of tail call sqrt

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-22 20:15:11
   date||


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

[Bug other/36018] New: [4.3/4.4 Regression] powerpc64: internal compiler error: in copy_to_mode_reg, at explow.c:621

[bunk at stusta dot de]

$ powerpc64-linux-gcc -m64 -Wp,-MD,drivers/md/.raid6altivec1.o.d  -nostdinc
-isystem
/usr/local/DIR/gcc-powerpc64-4.3-20080417/lib/gcc/powerpc64-linux/4.3.1/include
-D__KERNEL__ -Iinclude -Iinclude2
-I/home/bunk/linux/kernel-2.6/git/linux-2.6/include -include
include/linux/autoconf.h -Iarch/powerpc
-I/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/md -Idrivers/md -Wall
-Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -O2 -fno-stack-protector -msoft-float
-pipe -I/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc -Iarch/powerpc
-mminimal-toc -mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec
-mno-spe -funit-at-a-time -mno-string -Wa,-maltivec -fomit-frame-pointer
-Wdeclaration-after-statement -Wno-pointer-sign -maltivec -mabi=altivec 
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(raid6altivec1)" 
-D"KBUILD_MODNAME=KBUILD_STR(raid456)" -c -o drivers/md/raid6altivec1.o
drivers/md/raid6altivec1.c
drivers/md/raid6altivec1.c: In function 'raid6_altivec1_gen_syndrome_real':
drivers/md/raid6altivec1.c:88: internal compiler error: in copy_to_mode_reg, at
explow.c:621
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$


-- 
   Summary: [4.3/4.4 Regression] powerpc64: internal compiler error:
in copy_to_mode_reg, at explow.c:621
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu


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

[Bug other/36018] [4.3/4.4 Regression] powerpc64: ICE in copy_to_mode_reg, at explow.c:621

[bunk at stusta dot de]

--- Comment #1 from bunk at stusta dot de  2008-04-22 20:25 ---
Created an attachment (id=15512)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15512&action=view)
preprocessed source


-- 


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

[Bug other/36018] [4.3/4.4 Regression] powerpc64: ICE in copy_to_mode_reg, at explow.c:621

[bunk at stusta dot de]

--- Comment #2 from bunk at stusta dot de  2008-04-22 20:27 ---
No ICE when trying to compile this kernel with gcc 4.3.0, gcc 4.4 wasn't
tested.


-- 


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

[Bug other/36018] [4.3/4.4 Regression] powerpc64: ICE in copy_to_mode_reg, at explow.c:621

[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
   Keywords||ice-on-valid-code
   Target Milestone|--- |4.3.2


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

[Bug c++/36019] New: template parameter does not hide class name

[deba at inf dot elte dot hu]

If a member template is defined with same template parameter name as the class
name, then this parameter does not hide the class name.
The following code explains the problem:

#include 

struct B {
  static const int x = 1;
};

struct A {
  static const int x = 0;
  template 
  static void f() {
std::cerr << A::x << std::endl;
  }
};

int main() {
  A::f();
  return 0;
}

The result of the program is 0, while it should be 1.

Compilation:
> g++ -v -save-temps ns_bug.cc
Using built-in specs.   
Target: i486-linux-gnu  
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2
--program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --disable-libmudflap --enable-targets=all
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu 
Thread model: posix 
gcc version 4.2.3 (Debian 4.2.3-3)  
 /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -E -quiet -v -D_GNU_SOURCE ns_bug.cc
-mtune=generic -fpch-preprocess -o ns_bug.ii
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"  
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../i486-linux-gnu/include"  
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.2
 /usr/include/c++/4.2/i486-linux-gnu
 /usr/include/c++/4.2/backward
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.2.3/include
 /usr/include
End of search list.
 /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -fpreprocessed ns_bug.ii -quiet
-dumpbase ns_bug.cc -mtune=generic -auxbase ns_bug -version -o ns_bug.s
GNU C++ version 4.2.3 (Debian 4.2.3-3) (i486-linux-gnu)
compiled by GNU C version 4.2.3 (Debian 4.2.3-3).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: f63294e1c8ecc1bf2473a5bae1642fbe
 as -V -Qy -o ns_bug.o ns_bug.s
^[[6~GNU assembler version 2.18.0 (i486-linux-gnu) using BFD version (GNU
Binutils for Debian) 2.18.0.20080103
 /usr/lib/gcc/i486-linux-gnu/4.2.3/collect2 --eh-frame-hdr -m elf_i386
--hash-style=both -dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crt1.o
/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crti.o
/usr/lib/gcc/i486-linux-gnu/4.2.3/crtbegin.o
-L/usr/lib/gcc/i486-linux-gnu/4.2.3 -L/usr/lib/gcc/i486-linux-gnu/4.2.3
-L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../.. ns_bug.o
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/i486-linux-gnu/4.2.3/crtend.o
/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crtn.o


-- 
   Summary: template parameter does not hide class name
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: deba at inf dot elte dot hu
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug target/36018] [4.3/4.4 Regression] powerpc64: ICE in copy_to_mode_reg, at explow.c:621

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.2   |4.3.1


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

[Bug c++/35747] [4.3/4.4 regression] ICE with undefined variable in statement expression

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-04-22 22:07 ---
Subject: Bug 35747

Author: jakub
Date: Tue Apr 22 22:06:58 2008
New Revision: 134567

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134567
Log:
PR c++/35747
* semantics.c (finish_stmt_expr): Call pop_stmt_list even if the stmt
expression is errorneous.

* g++.dg/ext/stmtexpr13.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/stmtexpr13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/36012] Wrong initialization in operator new.

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-04-22 22:10 ---
 if (x->baz != (TARGET_EXPR >>
;>).baz)

I believe there's a dup for this ...


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
  Known to fail||2.95.3 3.3.6 4.3.0
   Last reconfirmed|-00-00 00:00:00 |2008-04-22 22:10:07
   date||


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

[Bug c++/35747] [4.3/4.4 regression] ICE with undefined variable in statement expression

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-04-22 22:15 ---
Subject: Bug 35747

Author: jakub
Date: Tue Apr 22 22:14:25 2008
New Revision: 134568

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134568
Log:
PR c++/35747
* semantics.c (finish_stmt_expr): Call pop_stmt_list even if the stmt
expression is errorneous.

* g++.dg/ext/stmtexpr13.C: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/ext/stmtexpr13.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/semantics.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/36013] [4.1/4.3 Regression] Wrong code involving restricted pointers to non-restricted pointers

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-04-22 22:17 ---
Confirmed.  The tree level gets this right and we expand from

  # VUSE 
  D.1761 = *p;
  # SMT.5_9 = VDEF 
  *D.1761 = 1;
  # SMT.5_10 = VDEF 
  **q = 2;
  if (*D.1761 != 2)

and cse1 removes the comparison.


-- 

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
   Keywords||wrong-code
  Known to fail||4.1.3 4.3.0
  Known to work||4.0.4 4.2.3
   Last reconfirmed|-00-00 00:00:00 |2008-04-22 22:17:50
   date||
Summary|Wrong code involving|[4.1/4.3 Regression] Wrong
   |restricted pointers to non- |code involving restricted
   |restricted pointers |pointers to non-restricted
   ||pointers
   Target Milestone|--- |4.1.3


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

[Bug target/34163] 10% performance regression since Nov 1 on Polyhedron's "NF" on AMD64

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-04-22 22:20 ---
Indeed.  It would be interesting to analyze what optimization the folding
enabled
and see if that can be recovered somehow.


-- 


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

[Bug c++/35747] [4.3/4.4 regression] ICE with undefined variable in statement expression

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-04-22 22:21 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/36016] for-loop scoping problem: Method gets called after destructor

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-04-22 22:25 ---
EDG agrees with you.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||wrong-code


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

[Bug tree-optimization/36020] New: shift operator strength reduction in loops not done.

[n dot pipenbrinck at cubic dot org]

Consider this simple loop:

int shift_integer (int value, unsigned int amount)
{
  unsigned int i;

  for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=36020

[Bug fortran/35994] [4.3/4.4 regression] MAXLOC and MINLOC off by one with mask

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2008-04-22 22:34 ---

> Paul, can you maybe shed any light on this?
> 

Not for some days, I'm afraid.  I'm in China, up to my eyeballs with day-time
work.

It'll be high priority when I get back.

Paul


-- 


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

[Bug rtl-optimization/36017] [4.3/4.4 Regression] Miscompilation of tail call sqrt

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-04-22 22:34 ---
Subject: Bug 36017

Author: jakub
Date: Tue Apr 22 22:33:48 2008
New Revision: 134569

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134569
Log:
PR rtl-optimization/36017
* builtins.c (expand_errno_check): Clear CALL_EXPR_TAILCALL before
expanding the library call.

* gcc.dg/pr36017.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr36017.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/36017] [4.3/4.4 Regression] Miscompilation of tail call sqrt

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-04-22 22:37 ---
Subject: Bug 36017

Author: jakub
Date: Tue Apr 22 22:36:27 2008
New Revision: 134570

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134570
Log:
PR rtl-optimization/36017
* builtins.c (expand_errno_check): Clear CALL_EXPR_TAILCALL before
expanding the library call.

* gcc.dg/pr36017.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr36017.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/builtins.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/36012] Wrong initialization in operator new.

[fang at csl dot cornell dot edu]

--- Comment #2 from fang at csl dot cornell dot edu  2008-04-22 22:38 
---
PR 32245?


-- 

fang at csl dot cornell dot edu changed:

   What|Removed |Added

 CC||fang at csl dot cornell dot
   ||edu


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

[Bug tree-optimization/36020] shift operator strength reduction in loops not done.

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-04-22 22:40 ---
this is not strength reduction but the reverse operation, final value
calculation.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-22 22:40:24
   date||


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

[Bug rtl-optimization/36017] [4.3/4.4 Regression] Miscompilation of tail call sqrt

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-04-22 22:43 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/36008] Function produces wrong results when inlined.

[xavier at tddft dot org]

--- Comment #4 from xavier at tddft dot org  2008-04-22 22:49 ---
Created an attachment (id=15513)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15513&action=view)
Test case, 1st file (no includes)


-- 

xavier at tddft dot org changed:

   What|Removed |Added

  Attachment #15510|0   |1
is obsolete||


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

[Bug middle-end/36008] Function produces wrong results when inlined.

[xavier at tddft dot org]

--- Comment #5 from xavier at tddft dot org  2008-04-22 22:49 ---
Created an attachment (id=15514)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15514&action=view)
Test case 2nd file


-- 


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

[Bug middle-end/36008] Function produces wrong results when inlined.

[xavier at tddft dot org]

--- Comment #6 from xavier at tddft dot org  2008-04-22 22:51 ---
I have managed to create a test case:

Correct case:

[EMAIL PROTECTED]:~$ gcc-4.3 bravais.c mathfunc.c -O3 -fno-inline
bravais.c: In function ‘main’:
bravais.c:83: warning: incompatible implicit declaration of built-in function
‘printf’
[EMAIL PROTECTED]:~$ ./a.out 
0 

Wrong case:

[EMAIL PROTECTED]:~$ gcc-4.3 bravais.c mathfunc.c -O3
bravais.c: In function ‘main’:
bravais.c:83: warning: incompatible implicit declaration of built-in function
‘printf’
[EMAIL PROTECTED]:~$ ./a.out 
-1 

Sorry for using two files, but the problem disappears if all functions are in a
single file.


-- 


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

[Bug tree-optimization/36020] shift operator strength reduction in loops not done.

[n dot pipenbrinck at cubic dot org]

--- Comment #2 from n dot pipenbrinck at cubic dot org  2008-04-22 23:10 
---
(In reply to comment #1)
> this is not strength reduction but the reverse operation, final value
> calculation.

Ooops. Sorry for that. Should I rename the entry or can we just live with it?


-- 


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

[Bug c++/35316] [4.2/4.3/4.4 regression] ICE with typeof/decltype and bit-fields

[jason at gcc dot gnu dot org]

--- Comment #1 from jason at gcc dot gnu dot org  2008-04-22 23:14 ---
Subject: Bug 35316

Author: jason
Date: Tue Apr 22 23:13:19 2008
New Revision: 134571

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134571
Log:
PR c++/35316
* semantics.c (finish_decltype_type): Check DECL_BIT_FIELD_TYPE
to see if DECL_BIT_FIELD_TYPE should be used, not some other flag.
* typeck.c (is_bitfield_expr_with_lowered_type): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/decltype11.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/35316] [4.2/4.3/4.4 regression] ICE with typeof/decltype and bit-fields

[jason at gcc dot gnu dot org]

--- Comment #2 from jason at gcc dot gnu dot org  2008-04-23 01:46 ---
Subject: Bug 35316

Author: jason
Date: Wed Apr 23 01:45:30 2008
New Revision: 134578

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134578
Log:
PR c++/35316
* semantics.c (finish_decltype_type): Check DECL_BIT_FIELD_TYPE
to see if DECL_BIT_FIELD_TYPE should be used, not some other flag.
* typeck.c (is_bitfield_expr_with_lowered_type): Likewise.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/cpp0x/decltype11.C
  - copied unchanged from r134571,
trunk/gcc/testsuite/g++.dg/cpp0x/decltype11.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/semantics.c
branches/gcc-4_3-branch/gcc/cp/typeck.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c/36021] New: Out-of-bounds parameter to alloc_size causes gcc to segfault

[df at dfranke dot us]

When declaring a function with __attribute__((alloc_size(n))), gcc segfaults if
n exceeds the number of arguments to the function.


-- 
   Summary: Out-of-bounds parameter to alloc_size causes gcc to
segfault
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: df at dfranke dot us
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/36021] Out-of-bounds parameter to alloc_size causes gcc to segfault

[df at dfranke dot us]

--- Comment #1 from df at dfranke dot us  2008-04-23 02:50 ---
Correction: this occurs only when a function takes no arguments but alloc_size
is used.


-- 


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

[Bug fortran/35988] run-time abort for MATMUL of run-time zero sized array

[tkoenig at gcc dot gnu dot org]

--- Comment #2 from tkoenig at gcc dot gnu dot org  2008-04-23 05:51 ---
Subject: Bug 35988

Author: tkoenig
Date: Wed Apr 23 05:50:54 2008
New Revision: 134579

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134579
Log:
2008-04-23  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/35988
* m4/matmul.m4:  Only issue a runtime error if extents are
non-zero.
* generated/matmul_i1.c:  Regenerated.
* generated/matmul_i2.c:  Regenerated.
* generated/matmul_i4.c:  Regenerated.
* generated/matmul_i8.c:  Regenerated.
* generated/matmul_i16.c:  Regenerated.
* generated/matmul_r4.c:  Regenerated.
* generated/matmul_r8.c:  Regenerated.
* generated/matmul_r10.c:  Regenerated.
* generated/matmul_r16.c:  Regenerated.
* generated/matmul_c4.c:  Regenerated.
* generated/matmul_c8.c:  Regenerated.
* generated/matmul_c10.c:  Regenerated.
* generated/matmul_c16.c:  Regenerated.

2008-04-23  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/35988
* gfortran.dg/matmul_7.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/matmul_7.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/generated/matmul_c10.c
trunk/libgfortran/generated/matmul_c16.c
trunk/libgfortran/generated/matmul_c4.c
trunk/libgfortran/generated/matmul_c8.c
trunk/libgfortran/generated/matmul_i1.c
trunk/libgfortran/generated/matmul_i16.c
trunk/libgfortran/generated/matmul_i2.c
trunk/libgfortran/generated/matmul_i4.c
trunk/libgfortran/generated/matmul_i8.c
trunk/libgfortran/generated/matmul_r10.c
trunk/libgfortran/generated/matmul_r16.c
trunk/libgfortran/generated/matmul_r4.c
trunk/libgfortran/generated/matmul_r8.c
trunk/libgfortran/m4/matmul.m4


-- 


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

[Bug fortran/35988] run-time abort for MATMUL of run-time zero sized array

[tkoenig at gcc dot gnu dot org]

--- Comment #3 from tkoenig at gcc dot gnu dot org  2008-04-23 05:53 ---
Fixed on trunk, closing.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/35990] run-time abort for PACK of run-time zero sized array

[tkoenig at gcc dot gnu dot org]

--- Comment #2 from tkoenig at gcc dot gnu dot org  2008-04-23 05:58 ---
These tests call the library function, so whatever goes
wrong here probably needs to be fixed in the
generated functions as well.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org


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

[Bug c++/36022] New: stl templates exported as weak symbols though visibility hidden is used

[mh+gcc at glandium dot org]

With the following foo.cpp sample:
#include 

__attribute__((visibility("default"))) void foo() {
  int array[] = { 23, 5, -10, 0, 0, 321, 1, 2, 99, 30 };
  int elements = sizeof(array) / sizeof(array[0]); 
  std::sort(array, array + elements);
}

Building with the following command line:
g++-4.3 -shared -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -o foo.so
foo.cpp

Leads to internals being exposed, which is unexpected:
objdump -T -C test2.so | grep std
136d  w   DF .text  003a  Basevoid
std::__unguarded_insertion_sort(int*, int*)
1b18  w   DF .text  0057  Basevoid
std::sort(int*, int*)
147f  w   DF .text  000e  Base   
std::__niter_base::__b(int*)
190b  w   DF .text  0021  Basestd::__lg(long)
1324  w   DF .text  0049  Basevoid
std::__unguarded_linear_insert(int*, int)
141f  w   DF .text  0060  Baseint*
std::__unguarded_partition(int*, int*, int)
1674  w   DF .text  0088  Basevoid
std::make_heap(int*, int*)
1400  w   DF .text  001f  Basevoid
std::iter_swap(int*, int*)
13b5  w   DF .text  002c  Basevoid
std::swap(int&, int&)
16fc  w   DF .text  0054  Basevoid
std::__pop_heap(int*, int*, int*)
19bc  w   DF .text  004f  Baseint*
std::__copy_move_backward_a2(int*, int*, int*)
1a4b  w   DF .text  0079  Basevoid
std::__insertion_sort(int*, int*)
1a0b  w   DF .text  0040  Baseint*
std::copy_backward(int*, int*, int*)
1750  w   DF .text  005d  Basevoid
std::__heap_select(int*, int*, int*)
1284  w   DF .text  00a0  Baseint const&
std::__median(int const&, int const&, int const&)
17ad  w   DF .text  002b  Basevoid
std::pop_heap(int*, int*)
152e  w   DF .text  0146  Basevoid
std::__adjust_heap(int*, long, long, int)
13a7  w   DF .text  000e  Base   
std::__miter_base::__b(int*)
180f  w   DF .text  0034  Basevoid
std::partial_sort(int*, int*, int*)
17d8  w   DF .text  0037  Basevoid
std::sort_heap(int*, int*)
1991  w   DF .text  002b  Baseint*
std::__copy_move_backward_a(int*, int*, int*)
1ac4  w   DF .text  0054  Basevoid
std::__final_insertion_sort(int*, int*)
1843  w   DF .text  00c8  Basevoid
std::__introsort_loop(int*, int*, long)
192c  w   DF .text  0065  Baseint*
std::__copy_move_backward::__copy_move_b(int const*, int const*,
int*)
13e1  w   DF .text  001f  Basevoid
std::__iter_swap::iter_swap(int*, int*)
148d  w   DF .text  00a1  Basevoid
std::__push_heap(int*, long, long, int)


FYI: g++-4.3 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure linux gnu
Thread model: posix
gcc version 4.3.1 20080401 (prerelease) (Debian 4.3.0-3) 

(it also happens with g++-4.2 from debian (4.2.3))


-- 
   Summary: stl templates exported as weak symbols though visibility
hidden is used
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mh+gcc at glandium dot org


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

[Bug c++/36023] New: [4.1/4.3/4.4 regression] ICE with cast to variable-sized object

[reichelt at gcc dot gnu dot org]

The following code snippet triggers an ICE on the 4.3 branch and mainline:


void foo(int i)
{
  (int [i]) { 1 };
}


bug.cc: In function 'void foo(int)':
bug.cc:3: internal compiler error: in tree_low_cst, at tree.c:4879
Please submit a full bug report, [etc.]

This is a regression on the 4.3 branch as 4.3.0 is not affected.
The ICE also appears in GCC 4.1.x, but is is not present in GCC 4.2.x.


-- 
   Summary: [4.1/4.3/4.4 regression] ICE with cast to variable-sized
object
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, 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=36023

[Bug c++/36023] [4.1/4.3/4.4 regression] ICE with cast to variable-sized object

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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