[Bug rtl-optimization/37948] [4.4 Regression] IRA generates slower code for -mtune=core2

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2008-10-29 05:44 ---
It looks like the cost of loading/storing FP values aren't appropriate for
Core 2. With this patch:

[EMAIL PROTECTED] i386]$ diff -up i386.c.foo i386.c
--- i386.c.foo  2008-10-28 21:56:19.0 -0700
+++ i386.c  2008-10-28 22:01:53.0 -0700
@@ -990,9 +990,9 @@ struct processor_costs core2_cost = {
   Relative to reg-reg move (2).  */
   {4, 4, 4},   /* cost of storing integer registers */
   2,   /* cost of reg,reg fld/fst */
-  {6, 6, 6},   /* cost of loading fp registers
+  {12, 12, 12},/* cost of loading fp registers
   in SFmode, DFmode and XFmode */
-  {4, 4, 4},   /* cost of storing fp registers
+  {6, 6, 8},   /* cost of storing fp registers
   in SFmode, DFmode and XFmode */
   2,   /* cost of moving MMX register */
   {6, 6},  /* cost of loading MMX registers
@@ -1000,9 +1000,9 @@ struct processor_costs core2_cost = {
   {4, 4},  /* cost of storing MMX registers
   in SImode and DImode */
   2,   /* cost of moving SSE register */
-  {6, 6, 6},   /* cost of loading SSE registers
+  {8, 8, 8},   /* cost of loading SSE registers
   in SImode, DImode and TImode */
-  {4, 4, 4},   /* cost of storing SSE registers
+  {8, 8, 8},   /* cost of storing SSE registers
   in SImode, DImode and TImode */
   2,   /* MMX or SSE register to integer */
   32,  /* size of l1 cache.  */
[EMAIL PROTECTED] i386]$

I got

[EMAIL PROTECTED] gcc]$  ./xgcc -B./ -m32 -O2 /tmp/foo.c -o core2.sse 
-mtune=core2 
-msse3 -mfpmath=sse
[EMAIL PROTECTED] gcc]$  ./xgcc -B./ -m32 -O2 /tmp/foo.c -o core2 -mtune=core2
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -m32 -O2 /tmp/foo.c -o o2  -msse3 
-mfpmath=sse
[EMAIL PROTECTED] gcc]$  ./xgcc -B./ -m32 -O2 /tmp/foo.c -o o2.sse
[EMAIL PROTECTED] gcc]$ time ./o2

real0m7.163s
user0m7.161s
sys 0m0.001s
[EMAIL PROTECTED] gcc]$ time ./core2

real0m7.833s
user0m7.829s
sys 0m0.001s
[EMAIL PROTECTED] gcc]$ time ./o2.sse

real0m7.795s
user0m7.794s
sys 0m0.000s
[EMAIL PROTECTED] gcc]$ time ./core2.sse

real0m7.339s
user0m7.337s
sys 0m0.001s
[EMAIL PROTECTED] gcc]$

But even with this patch, IRA still generates slower codes:

[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -m32 -O2 /tmp/foo.c -o core2.noira 
-mtune=core2
-fno-ira
[EMAIL PROTECTED] gcc]$ time ./core2.noira

real0m7.444s
user0m7.441s
sys 0m0.001s
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -m32 -O2 /tmp/foo.c -o core2.sse.noira
-mtune=core2 -fno-ira -msse3 -mfpmath=sse
[EMAIL PROTECTED] gcc]$ time ./core2.sse.noira

real0m7.229s
user0m7.224s
sys 0m0.000s
[EMAIL PROTECTED] gcc]$


-- 


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

[Bug rtl-optimization/37948] New: [4.4 Regression] IRA generates slower code for -mtune=core2

[hjl dot tools at gmail dot com]

+++ This bug was initially created as a clone of Bug #37364 +++

Testcase in PR 37364:

http://gcc.gnu.org/bugzilla/attachment.cgi?id=16536

shows IRA generates slower code for -mtune=core2.

$ gcc -m32 -O2 -mssse3 -mfpmath=sse 36.c
$ time -p ./a.out
real 7.97
$ gcc -m32 -O2 -mssse3 -mfpmath=sse -mtune=core2 -o core2.exe 36.c
$ time -p ./core2.exe
real 12.27


-- 
   Summary: [4.4 Regression] IRA generates slower code for -
mtune=core2
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization, ra
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: i686-pc-linux-gnu
 BugsThisDependsOn: 37364


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

[Bug libfortran/37707] Namelist read of array of derived type incorrect

[jvdelisle at gcc dot gnu dot org]

--- Comment #35 from jvdelisle at gcc dot gnu dot org  2008-10-29 04:48 
---
Subject: Bug 37707

Author: jvdelisle
Date: Wed Oct 29 04:47:20 2008
New Revision: 141421

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141421
Log:
2008-10-28  Jerry DeLisle  <[EMAIL PROTECTED]

PR libfortran/37707
* gfortran.dg/namelist_18.f90: Revise.
* gfortran.dg/namelist_55.f90: New test.
* gfortran.dg/namelist_56.f90: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_55.f90
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_56.f90
Modified:
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_18.f90


-- 


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

[Bug libfortran/37707] Namelist read of array of derived type incorrect

[jvdelisle at gcc dot gnu dot org]

--- Comment #34 from jvdelisle at gcc dot gnu dot org  2008-10-29 04:47 
---
Fixed on 4.3, closing


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libfortran/37707] Namelist read of array of derived type incorrect

[jvdelisle at gcc dot gnu dot org]

--- Comment #33 from jvdelisle at gcc dot gnu dot org  2008-10-29 04:45 
---
Subject: Bug 37707

Author: jvdelisle
Date: Wed Oct 29 04:44:15 2008
New Revision: 141420

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141420
Log:
2008-10-28  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libfortran/37707
Backport from trunk.
* io/list_read.c (read_character): Remove code to look ahead in
namelist
reads to descriminate non-delimited strings from namelist objects.
* io/write.c (namelist_write): Delimit character strings with quote or
apostrophe, defaulting to quote.

Modified:
branches/gcc-4_3-branch/libgfortran/ChangeLog
branches/gcc-4_3-branch/libgfortran/io/list_read.c
branches/gcc-4_3-branch/libgfortran/io/write.c


-- 


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

[Bug middle-end/37943] [graphite] ICE : in build_graphite_scops, at graphite.c:1823

[grosser at gcc dot gnu dot org]

-- 

grosser at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |grosser at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-10-29 04:40:55
   date||


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

[Bug middle-end/37886] [graphite] ICE: Segmentation fault

[grosser at gcc dot gnu dot org]

--- Comment #6 from grosser at gcc dot gnu dot org  2008-10-29 04:37 ---
Fix committed.


-- 

grosser at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c/37947] p->count += inc(p); // value of p->count is wrong, if inc(p) not only returns an int but also increases p->counter

[micirio at gmx dot net]

--- Comment #3 from micirio at gmx dot net  2008-10-29 01:44 ---
Thanks for the quick answer. Is it possible to get a warning if I write
undefined code like this? -Wall didn't tell me anything.

I'm asking, because I need to convert an existing (old) project where I found
this line that caused a segfault at a very other point in the source. So a
warning would avoid some odd surprises.


-- 


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

[Bug c/37947] p->count += inc(p); // value of p->count is wrong, if inc(p) not only returns an int but also increases p->counter

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-10-29 01:34 ---
counter += inc(&counter);

That is undefined code as you access counter without a sequence point where you
assign it.
So it is valid for GCC to change the above to:
int tmp = counter;
tmp += inc(&counter);
counter = tmp;

Or
int tmp = inc(&counter);
counter += tmp;

The same thing happens with p->counter += inc(p);
 except instead s/counter/p->counter/ and s/&counter/p/.

Thanks,
Andrew Pinski


-- 

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=37947

[Bug c/37947] p->count += inc(p); // value of p->count is wrong, if inc(p) not only returns an int but also increases p->counter

[micirio at gmx dot net]

--- Comment #1 from micirio at gmx dot net  2008-10-29 01:29 ---
Created an attachment (id=16579)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16579&action=view)
test.i


-- 


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

[Bug c/37947] New: p->count += inc(p); // value of p->count is wrong, if inc(p) not only returns an int but also increases p->counter

[micirio at gmx dot net]

The following programm prints out "1", it should print "4" (like it does with
gcc-3.3.6:

// Start of test.c
#include 
#include 

struct test
{
unsigned long counter;
};

unsigned long inc(struct test *tp)
{
tp->counter += 3;
return 1;
}

int main()
{
struct test *p;
p = (struct test*) malloc(sizeof(struct test));

p->counter = 0;
p->counter += inc(p);
printf("%ld\n", p->counter);

free(p);
return 0;
}
// End of test.c



The following programm is not affected and prints out "4":

// Start of test2.c
#include 
#include 

unsigned long inc(unsigned long *c)
{
*c += 3;
return 1;
}

int main()
{
unsigned long counter;

counter = 0;
counter += inc(&counter);
printf("%ld\n", counter);

return 0;
}
// End of test2.c


// Start output of "gcc -v -save-temps -Wall test.c"
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/home/portage/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.2
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-libunwind-exceptions
--disable-multilib --enable-libmudflap --disable-libssp --enable-java-awt=gtk
--with-arch=i686 --enable-languages=c,c++,java,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion=Gentoo 4.1.2 p1.1
Thread model: posix
gcc version 4.1.2 (Gentoo 4.1.2 p1.1)
 /usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1 -E -quiet -v test.c -march=i686
-Wall -fpch-preprocess -o test.i
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include
 /usr/include
End of search list.
 /usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1 -fpreprocessed test.i -quiet
-dumpbase test.c -march=i686 -auxbase test -Wall -version -o test.s
GNU C version 4.1.2 (Gentoo 4.1.2 p1.1) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.2 (Gentoo 4.1.2 p1.1).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: db0ff7bf11ec8c21ed7c44c88f5253be
 /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/bin/as -V
-Qy -o test.o test.s
GNU assembler version 2.18 (i686-pc-linux-gnu) using BFD version (GNU Binutils)
2.18
 /usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../crt1.o
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../crti.o
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/crtbegin.o
-L/usr/lib/gcc/i686-pc-linux-gnu/4.1.2 -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.2
-L/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/lib
-L/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../.. test.o -lgcc --as-needed
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/crtend.o
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../crtn.o
// End output of "gcc -v -save-temps -Wall test.c"


-- 
   Summary: p->count += inc(p);  // value of p->count is wrong, if
inc(p) not only returns an int but also increases p-
>counter
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: micirio at gmx dot net


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

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

[howarth at nitro dot med dot uc dot edu]

--- Comment #29 from howarth at nitro dot med dot uc dot edu  2008-10-28 
23:37 ---
I have verified that the fink build system wasn't in fact setting CPPFLAGS to
null
or anything else. So this problem is real when CPPFLAGS doesn't exist,


-- 


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

[Bug c++/37946] ICE with enum class

[piotr dot rak at gmail dot com]

--- Comment #1 from piotr dot rak at gmail dot com  2008-10-28 23:35 ---
Created an attachment (id=16578)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16578&action=view)
Test case


-- 


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

[Bug testsuite/37241] [4.4 Regression]: FAIL: g++.dg/abi/key2.C

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-10-28 23:33 ---
Not P1, as it is just a testcase issue, not compiler bug.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P1  |P2


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

[Bug c++/37946] New: ICE with enum class

[piotr dot rak at gmail dot com]

Following (valid I believe) code causes internal compiler error:
enum class E : char
{
e1,
e2
};

inline E operator| (E a1, E a2)
{
char ret = static_cast (a1) 
| static_cast (a2);
return static_cast(ret);
}
 g++-4.4.0-alpha20081010 -v -c -std=c++0x enum_class_ice.cc 
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/paludis/sys-devel-gcc-4.4.0_alpha20081010/work/gcc-4.4-20081010/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.4.0-alpha20081010
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20081010
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20081010/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20081010/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-multilib --enable-libmudflap
--disable-libssp --enable-cld --disable-libgcj --with-arch=i686
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo
4.4.0_alpha20081010'
Thread model: posix
gcc version 4.4.0-alpha20081010  (experimental) (Gentoo 4.4.0_alpha20081010) 
COLLECT_GCC_OPTIONS='-v' '-c' '-std=c++0x' '-E' '-shared-libgcc'
'-mtune=generic' '-march=i686'
 /usr/libexec/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/cc1plus -E -quiet -v
-D_GNU_SOURCE enum_class_ice.cc -mtune=generic -march=i686 -std=c++0x
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/include/g++-v4

/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/include/g++-v4/i686-pc-linux-gnu
 /usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/include/g++-v4/backward
 /usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/include
 /usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/include-fixed
 /usr/include
End of search list.
COMPILER_PATH=/usr/libexec/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/:/usr/libexec/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/libexec/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/../../../../i686-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/../../../../i686-pc-linux-gnu/lib/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-c' '-std=c++0x' '-E' '-shared-libgcc'
'-mtune=generic' '-march=i686'
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/paludis/sys-devel-gcc-4.4.0_alpha20081010/work/gcc-4.4-20081010/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.4.0-alpha20081010
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20081010
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20081010/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20081010/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-multilib --enable-libmudflap
--disable-libssp --enable-cld --disable-libgcj --with-arch=i686
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo
4.4.0_alpha20081010'
Thread model: posix
gcc version 4.4.0-alpha20081010  (experimental) (Gentoo 4.4.0_alpha20081010) 
COLLECT_GCC_OPTIONS='-v' '-c' '-std=c++0x' '-o'
'/home/prak/.ccache/tmp.hash.sandra.23558.o' '-shared-libgcc' '-mtune=generic'
'-march=i686'
 /usr/libexec/gcc/i686-pc-linux-gnu/4.4.0-alpha20081010/cc1plus -fpreprocessed
/home/prak/.ccache/enum_class.tmp.sandra.23558.ii -quiet -dumpbase
enum_class.tmp.sandra.23558.ii -mtune=generic -march=i686 -auxbase-strip
/home/prak/.ccache/tmp.hash.sandra.23558.o -std=c++0x -version -o
/tmp/ccpib1aZ.s
GNU C++ (Gentoo 4.4.0_alpha20081010) version 4.4.0-alpha20081010 
(experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.4.0-alpha20081010  (experi

[Bug testsuite/37241] [4.4 Regression]: FAIL: g++.dg/abi/key2.C

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-10-28 23:22 ---
The section does not change so there is no need for the .section in the
scan-assembler:
.globl __ZTV1f
.weak_definition __ZTV1f
.section __DATA,__const_coal,coalesced
.align 3
__ZTV1f:
.long   0
.long   __ZTI1f
.long   __ZN1f1gEv
.long   __ZN1f1hEv
.globl __ZTI1f
.weak_definition __ZTI1f
.align 2
__ZTI1f:


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|target  |testsuite
  GCC build triplet|*-apple-darwin* |
   GCC host triplet|*-apple-darwin* |


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

[Bug target/37878] [4.4 regression] PPC64 ldu command generated with invalid offset

[dje at gcc dot gnu dot org]

--- Comment #12 from dje at gcc dot gnu dot org  2008-10-28 23:13 ---
Created an attachment (id=16577)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16577&action=view)
another refinement

Jakub suggested a further refinement to hoist a common sub-expression.


-- 

dje at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #16576|0   |1
is obsolete||


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

[Bug target/37878] [4.4 regression] PPC64 ldu command generated with invalid offset

[dje at gcc dot gnu dot org]

--- Comment #11 from dje at gcc dot gnu dot org  2008-10-28 22:35 ---
Created an attachment (id=16576)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16576&action=view)
disallow illegal displacement wrapped in PRE_MODIFY or PRE_INC/DEC

I think this patch accomplishes the effect but easier to follow with the
address form localized in one place.


-- 


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

[Bug ada/37945] GNAT Sockaddr and Sockaddr_In does not match c-structures on RTEMS

[joel at gcc dot gnu dot org]

--- Comment #1 from joel at gcc dot gnu dot org  2008-10-28 22:00 ---
This does not impact the SVN trunk.  

This requires adding g-socthi-rtems.ads and corresponding Makefile.in change. I
will prepare and test a complete patch.

We wondered if this is broken for FreeBSD as well.  We use the FreeBSD TCP/IP
stack in RTEMS and it should be broken the same way.  Can someone confirm that?


-- 

joel at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |blocker


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

[Bug middle-end/37339] [4.4 Regression] gcc.dg/pr33645-3.c scan-assembler-not var1_t

[sje at cup dot hp dot com]

--- Comment #4 from sje at cup dot hp dot com  2008-10-28 21:51 ---
I have posted a patch in which I propose removing this test.  It has not gotten
any feedback yet.

http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00826.html


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||10/msg00826.html


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

[Bug ada/37945] GNAT Sockaddr and Sockaddr_In does not match c-structures on RTEMS

[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|blocker |normal


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

[Bug middle-end/37339] [4.4 Regression] gcc.dg/pr33645-3.c scan-assembler-not var1_t

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-10-28 21:37 ---
*** Bug 37944 has been marked as a duplicate of this bug. ***


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||eric dot weddington at atmel
   ||dot com


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

[Bug target/37944] [4.4 Regression] FAIL: gcc.dg/pr33645-3.c scan-assembler-not var1_t

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-10-28 21:37 ---


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


-- 

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=37944

[Bug ada/37945] New: GNAT Sockaddr and Sockaddr_In does not match c-structures on RTEMS

[petri dot rokka at tut dot fi]

RTEMS has FreeBSD style structures:

Sockaddr and Sockaddr_In should have the 8bit Len and Family variable instead
of
16 family in gcc/ada/socthi.ads.

Bug prevents at least binding local address to socket, connecting tcp socket or
sending udp data.

diff g-socthi.ads g-socthi-rtems.ads
145c145,146
<   Sa_Family : C.unsigned_short;
---
>   Sa_Len: C.unsigned_char;
>   Sa_Family : C.unsigned_char;
156c157,158
<   Sin_Family : C.unsigned_short  := Constants.AF_INET;
---
>   Sin_Len: C.unsigned_char   := 0;
>   Sin_Family : C.unsigned_char   := Constants.AF_INET;


diff g-socthi.adb g-socthi-rtems.adb
451c451
<   Sin.Sin_Family := C.unsigned_short (Family);
---
>   Sin.Sin_Family := C.unsigned_char (Family);


-- 
   Summary: GNAT Sockaddr and Sockaddr_In does not match c-
structures on RTEMS
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: petri dot rokka at tut dot fi


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

[Bug c/23144] [4.2/4.3/4.4 Regression] invalid parameter forward declarations not diagnosed

[jsm28 at gcc dot gnu dot org]

--- Comment #9 from jsm28 at gcc dot gnu dot org  2008-10-28 20:25 ---
*** Bug 37940 has been marked as a duplicate of this bug. ***


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janis at gcc dot gnu dot org


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

[Bug c/37940] no error detected for semicolon in C function declaration

[jsm28 at gcc dot gnu dot org]

--- Comment #1 from jsm28 at gcc dot gnu dot org  2008-10-28 20:25 ---


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


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic

[burnus at gcc dot gnu dot org]

--- Comment #16 from burnus at gcc dot gnu dot org  2008-10-28 20:15 ---
> Well, I think it may be more complicated.  Have I mentioned 
> how much I hate TRANSFER. :(

Well, I didn't do much with TRANSFER, but I fully understand you.

> To make matters worse, with trunk I see
>   call sub(x,0.)
>   i = x
>  NaN -2147483648
> FFC0

Looks OK to me as run-time behaviour. If you want to catch this, simply compile
gfortran with -ffpe-trap=invalid.


> gfc_mpfr_to_mpz but also gfc_real2int and gfc_complex2int.

I don't think so. You have in gfc_real2int the call:
  gfc_mpfr_to_mpz (result->value.integer, src->value.real);
and in gfc_complex2int you have
  gfc_mpfr_to_mpz (result->value.integer, src->value.complex.r);
Thus you really only need to modify gfc_mpfr_to_mpz.


-- 


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

[Bug target/37944] New: [4.4 Regression] FAIL: gcc.dg/pr33645-3.c scan-assembler-not var1_t

[eric dot weddington at atmel dot com]

Regression test failure:
FAIL: gcc.dg/pr33645-3.c scan-assembler-not var1_t

Executing on host: /usr/local/avrdev/gcc/build/gcc/xgcc
-B/usr/local/avrdev/gcc/build/gcc/
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr33645-3.c   -O2
-fno-unit-at-a-time -DSTACK_SIZE=2048 -DNO_TRAMPOLINES -S  -DSIGNAL_SUPPRESS
-mmcu=atmega128   -o pr33645-3.s(timeout = 300)
PASS: gcc.dg/pr33645-3.c (test for excess errors)
FAIL: gcc.dg/pr33645-3.c scan-assembler-not var1_t

Known success on 2008-09-02 trunk revision 139891
Known fail on 2008-09-04 trunk revision 139992
Still fails on trunk revision 141408


-- 
   Summary: [4.4 Regression] FAIL: gcc.dg/pr33645-3.c scan-
assembler-not var1_t
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot weddington at atmel dot com
GCC target triplet: avr-*-*


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

[Bug tree-optimization/37663] [4.4 Regression] ice in simplify_truth_ops_using_ranges, at tree-vrp.c:6335

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-10-28 20:09 ---
Next time, please don't reopen the original PR.  Whether the test fails on avr
or not doesn't have anything to do with the fact that the original bug has been
fixed.  IMHO either open a new PR and link it to the original PR, or
(preferrably) just submit a patch to gcc-patches to modify the testcase.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/37663] [4.4 Regression] ice in simplify_truth_ops_using_ranges, at tree-vrp.c:6335

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-10-28 20:07 ---
Subject: Bug 37663

Author: jakub
Date: Tue Oct 28 20:06:08 2008
New Revision: 141414

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141414
Log:
PR tree-optimization/37663
* gcc.dg/pr37663.c: Require int32plus.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr37663.c


-- 


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

[Bug middle-end/37943] [graphite] ICE : in build_graphite_scops, at graphite.c:1823

[mitul dot thakkar at amd dot com]

--- Comment #1 from mitul dot thakkar at amd dot com  2008-10-28 20:05 
---
Created an attachment (id=16575)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16575&action=view)
Reduced Test Case


-- 


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

[Bug middle-end/37943] New: [graphite] ICE : in build_graphite_scops, at graphite.c:1823

[mitul dot thakkar at amd dot com]

gcc -c -O3 -floop-block  test_graphite.c

test_graphite.c: In function 'compress':
test_graphite.c:17: internal compiler error: in build_graphite_scops, at
graphite.c:1823
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [graphite] ICE : in build_graphite_scops, at
graphite.c:1823
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mitul dot thakkar at amd dot com
 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=37943

[Bug tree-optimization/37663] [4.4 Regression] ice in simplify_truth_ops_using_ranges, at tree-vrp.c:6335

[eric dot weddington at atmel dot com]

--- Comment #4 from eric dot weddington at atmel dot com  2008-10-28 19:56 
---
Reopening bug.
New test case gcc.dg/pr37663.c fails for AVR with:
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr37663.c: In function 'foo':

/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr37663.c:11: warning: overflow
in implicit constant conversion


Line 11:
  int y = -1885403717;

This test case assumes that an int is 32 bits. An int is 16 bits on AVR.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 GCC target triplet|i686-pc-linux-gnu   |i686-pc-linux-gnu avr-*-*
 Resolution|FIXED   |


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

[Bug c/37924] [4.2/4.3 Regression] ice in smallest_mode_for_size, at stor-layout.c:219

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-10-28 19:06 ---
Fixed in 4.4 so far.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.2.4 4.3.2 4.4.0   |4.2.4 4.3.2
  Known to work|4.1.2   |4.1.2 4.4.0
Summary|[4.2/4.3/4.4 Regression] ice|[4.2/4.3 Regression] ice in
   |in smallest_mode_for_size,  |smallest_mode_for_size, at
   |at stor-layout.c:219|stor-layout.c:219


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

[Bug c/37924] [4.2/4.3/4.4 Regression] ice in smallest_mode_for_size, at stor-layout.c:219

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-10-28 19:04 ---
Subject: Bug 37924

Author: jakub
Date: Tue Oct 28 19:02:36 2008
New Revision: 141413

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141413
Log:
PR c/37924
* combine.c (make_compound_operation): Don't call make_extraction with
non-positive length.
(simplify_shift_const_1): Canonicalize count even if complement_p.

* gcc.c-torture/execute/pr37924.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr37924.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic

[burnus at gcc dot gnu dot org]

--- Comment #14 from burnus at gcc dot gnu dot org  2008-10-28 18:56 ---
> When I run
>   program test
>   integer i
>   i = transfer(-1,1.0)
>   print *, i
>   end
> 
> I get -2147483648 with gcc-4.2, ifort, and pgf90 on x86_64 Linux, and same
> value with xlf on AIX with power5.

Ditto for openf95. g95 warns (integer overflow) and prints "0"; NAG f95 gives
an "Error: Result of TRANSFER is Not a Number". At run time, gfortran, g95 and
NAG f95 (w/ IEEE exceptions disabled) processes it and print "-2147483648".


I agree with Steve that assigning NaN and INF to an integer does not make
sense. What integer matches NaN - none! One can assign the bit pattern of NaN,
i.e.   "i = transfer(NaN, 0)" but that is something completely different and
"well" defined.

NAG's arithmetic exception also makes sense.

Steve wrote:
> In thinking about transfer(-1,1.0), this may also be invalid

With Fortran 2003's IEEE support the latter should be valid (if a given
"processor" supports the needed IEEE features and similar restrictions).

Dominque wrote:
> I think the conversion of NaN to int is buggy since the behavior is
> platform/option dependent. Your patch just prevents to reach the bug. It 
> always make me nervous when a bug is hidden without being understood.

I think such an investigation makes sense in general but for the error message
   "gmp: overflow in mpz type"
it might not be needed: It simply states that MPFR/GMP does not like the
conversion. If there are any other code paths, the patch does not make it more
likely that they are hit.


>From the patch:

+  gfc_error ("Conversion of exceptional value at %L", where);

I don't like this error message - when I read it I don't understand the meaning
of "exceptional". How about something like the following:

- "Conversion of non-representable value (NaN or Infinity) at %L"
- "Conversion of non-representable value at %L"
- "Conversion of NaN or Infinity at %L"
- "Conversion of Not-a-Number or Infinity at %L"
or ... ?


Dominique just wrote:
> Is -3.40282347E+38 more valid than NaN or -Inf?

I believe it is. You can convert "-3.40282347E+38" into an integer and you get:
-34028234700.
You can now assign that integer to your integer variable. You probably loose
some digits as the variable is too small ("overflows" but actually it is rather
a cut off of digits, ignoring the sign bit for the moment).

But which integer matches INF? 9 with infinitely many trailing 9s. Or do
you prefer to have 1 with infinitely many trailing 0s. Depending what you
choose and taking the last n bits you get different values for your variable.

And for NaN: I frankly have no idea to what integer this is supposed to match.

If you talk about bit patterns the situation is completely different. You can
assign the bit pattern of NaN to any integer, real, logical etc. variable if
you want. For instance   transfer(-1, 0.0)  is a perfectly fine real number,
which you also may assign to any other real or complex number. You may also
TRANSFER it bitwise to an integer number (which gives the number you started
with: "-1"). But if you try to assign the number, you are in trouble (see
above).

---

>From comment 1:

  Adw_xabcd_8(1:n) = transfer(-1,1.0) ! Adw_xabcd_8 is REAL

That makes sense: One assigns NaN to a real variable (though a comment would be
helpful). However

  Adw_Fn_I (n) = transfer(-1,1.0) ! Adw_Fn_I is an INTEGER

does not make sense as there is no NaN for integers. Here, one could have used
"-HUGE(Adw_Fn_I)" or similar. I think the programmer simply missed that
Adw_Fn_I is no real variable; as long as compiler digest this number it does
its purpose - initializing the variable with garbage, but syntactically it does
not make sense - and a compiler has all rights to reject it.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org


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

[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts

[domob at gcc dot gnu dot org]

--- Comment #12 from domob at gcc dot gnu dot org  2008-10-28 18:46 ---
(In reply to comment #11)
> Well, may patch is made against trunk, so I will leave it as is for now.
> If Daniel commits his patch for PR35861, I can provide an updated patch.
> I quickly looked at it, and it should be rather straightforward (it looks like
> a tabs problem only).

I do think it is a trivial merge, too.  But as discussed with Dominique on IRC,
I think we could also review and check-in your patch prior to mine, as it is
simpler and might get review faster.  Then I'd do the merge.


-- 


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

[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts

[mikael dot morin at tele2 dot fr]

--- Comment #11 from mikael dot morin at tele2 dot fr  2008-10-28 18:43 
---
(In reply to comment #9)
> 
> Some synchronization seems needed.
> 

Well, may patch is made against trunk, so I will leave it as is for now.
If Daniel commits his patch for PR35861, I can provide an updated patch.
I quickly looked at it, and it should be rather straightforward (it looks like
a tabs problem only).


-- 


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

[Bug fortran/37926] Program gives wrong output (connected to char len)

[pault at gcc dot gnu dot org]

--- Comment #2 from pault at gcc dot gnu dot org  2008-10-28 18:42 ---
(In reply to comment #1)
Tobias,

Isn't the problem the following?

parm.22.dim[0].lbound = 1;
parm.22.dim[0].ubound = D.1616;
parm.22.dim[0].stride = NON_LVALUE_EXPR ;
parm.22.data = (void *) &(*ifm.21)[0];
parm.22.offset = NON_LVALUE_EXPR ;
D.1623 = _gfortran_internal_pack (&parm.22);  / void* result /
D.1625 = mysize (D.1623); / mysize expects struct
array1_integer(kind=4) & a   /
D.1627 = MAX_EXPR  * 64;
if (D.1627 < 0)
  {
_gfortran_runtime_error (&"Attempt to allocate a negative amount of
memory."[1]{lb: 1 sz: 1});
  }
D.1628 = __builtin_malloc (MAX_EXPR <(integer(kind=8)) D.1627, 1>);
if (D.1628 == 0B)
  {
_gfortran_os_error (&"Memory allocation failed"[1]{lb: 1 sz: 1});
  }
pstr.23 = (character(kind=1)[1:MAX_EXPR ] *) D.1628;
p (pstr.23, MAX_EXPR , D.1614, mysize);


Thus it's the internal_pack that does this in.

Paul


-- 


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

[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #13 from sgk at troutmask dot apl dot washington dot edu  
2008-10-28 18:40 ---
Subject: Re:  gfortran error and ICE at automatic type conversion with transfer
intrinsic

On Tue, Oct 28, 2008 at 05:51:06PM -, dominiq at lps dot ens dot fr wrote:
> 
> > i = NaN is an assignment not a bitwise copy.  This isn't platform
> > dependent nor option dependent.  You simply can't assign a NaN to
> > an INTEGER.
> 
> Before the assignment, there is an attempt to convert the real 'NaN' to a
> default integer.

i = 1.23456 --> i = 1
i = 3.14149 --> i = 3
i = NaN --> i = what goes here?

> This conversion is platform dependent. Now consider the following code:
> 
> i = -huge(1.0)
> print *, i, -huge(1.0)
> end
> 
> which compiles without problem with the option -fno-range-check and gives at

As soon as you used the -fno-range-check option, you are telling
gfortran to violate the standard.  gfortran can do whatever it
pleases.

troutmask:kargl[213] gfc -o z -fno-range-check -fdump-parse-tree j.f90

  ASSIGN MAIN__:i 340282346638528859811704183484516925440
  WRITE UNIT=6 FMT=-1
TRANSFER MAIN__:i
TRANSFER 3.40282347e38
  DT_END

Looks like the well-known integer wrap around issue.

What is mod(34028..., 2^32)?  Could also be 2^31 - 1; too lazy
to investigate any farther.

> run time:
> 
>0 -3.40282347E+38
> 
> Is -3.40282347E+38 more valid than NaN or -Inf? Or is that the extension has
> not been defined for the later real values?

What happens without -fno-range-check?

> > In thinking about transfer(-1,1.0), this may also be invalid
> > because the standard forbids calling an intrinsic procedure
> > if it will return a result outside the representable range of
> > the return type.  There is probably some argument on whether
> > NaN is this range.  
> 
> My point of view has always been that +/-Inf and NaN's should abort the
> executable, but I seems alone to think so! 

See -ffpe-trap option.


-- 


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

[Bug c/37940] New: no error detected for semicolon in C function declaration

[janis at gcc dot gnu dot org]

The following code has an extra semi-colon at the end of the function prototype
declaring bad_func1:

  void bad_func1 (unsigned long long arg1, const char *arg2 ; );

  void bad_func2 ()
  {
const char *foo = "foo";
bad_func1 (0, foo);
  }

GCC 3.4 reports an error:

elm3b187% /home/janis/tools/gcc-3.4-anonsvn/bin/gcc -c bug.c
bug.c:1: error: parameter "arg1" has just a forward declaration
bug.c:1: error: parameter "arg2" has just a forward declaration

GCC 4.0 and later (including current mainline) accept the code with no error or
warning, even with -Wall, and generate code as if the prototype did not exist
rather than generating code as if the semicolon did not exist.


-- 
   Summary: no error detected for semicolon in C function
declaration
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org


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

[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts

[mikael dot morin at tele2 dot fr]

--- Comment #10 from mikael dot morin at tele2 dot fr  2008-10-28 18:27 
---
Created an attachment (id=16574)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16574&action=view)
first fix

This patch tries to solve the problem by changing the (2) condition. 
It tries to use an ss whose starting value is zero when there is one (In this
case it is that of (/1,1,1/)). 

The regression tests pass with both this patch applied and that one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610#c21
reverted (ICEing is better than wrong-coding). 

I was initially dissatisfied by this patch as it was not changing the beginning
of gfc_trans_create_temp_array, which was leaving room for another case where
the loop would not start at zero. I failed to find such a case though. 

However, I believe it is still valuable as it produces a (just a little) better
code (see array indexes) than the other one. 
Now I suggest we apply both patches. 
Any comments ?


-- 


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

[Bug libfortran/37839] st_parameter_dt has unwanted padding, is out of sync with compiler

[sje at cup dot hp dot com]

--- Comment #9 from sje at cup dot hp dot com  2008-10-28 18:26 ---
Further investigation shows that it is not the size of common that is the
problem.  The bug is related to the new union of st_parameter_43 and
st_parameter_44.  Specifically, st_parameter_44 contains pos which is type
GFC_IO_INT which is 8 bytes on IA64 and requires an 8 byte alignment.  This
causes the entire st_parameter_44 structure to require 8 byte alignment and the
union that it is part of to require 8 byte alignment.  This changes the
layout/offset of fields in the p and q parts of the st_parameter_dt structure.

The compiler definition of st_parameter_dt, created from ioparm.def,  does not
know anything about the union that is used in the library and just lays out the
fields as if there was no *_44 structure and no union and this layout is then
different then the library layout.


-- 


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

[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic

[dominiq at lps dot ens dot fr]

--- Comment #12 from dominiq at lps dot ens dot fr  2008-10-28 17:51 ---
(In reply to comment #8)
> i = NaN is an assignment not a bitwise copy.  This isn't platform
> dependent nor option dependent.  You simply can't assign a NaN to
> an INTEGER.

Before the assignment, there is an attempt to convert the real 'NaN' to a
default integer.
This conversion is platform dependent. Now consider the following code:

i = -huge(1.0)
print *, i, -huge(1.0)
end

which compiles without problem with the option -fno-range-check and gives at
run time:

   0 -3.40282347E+38

Is -3.40282347E+38 more valid than NaN or -Inf? Or is that the extension has
not been defined for the later real values?

> In thinking about transfer(-1,1.0), this may also be invalid
> because the standard forbids calling an intrinsic procedure
> if it will return a result outside the representable range of
> the return type.  There is probably some argument on whether
> NaN is this range.  

My point of view has always been that +/-Inf and NaN's should abort the
executable, but I seems alone to think so! 

I also find very weird to assign transfer(integer, real) to an integer. I don't
see the logic of this construct: what is it supposed to do?

Note also that the behavior of gfortran is not consistent, as shown by the
following test:

[ibook-dhum] f90/bug% cat > pr37930_db_1.f90
r = transfer(-1,1.0)
i = r
print *, i
end
[ibook-dhum] f90/bug% gfc pr37930_db_1.f90
[ibook-dhum] f90/bug% a.out 
 -2147483648


-- 


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

[Bug fortran/35810] [TR 15581 / F2003] Automatic reallocation on assignment to allocatable variables

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-10-28 17:37 ---
Segfault with return values of allocatable functions.

A code which does not work is the following TR15581-conform program.
It seqfaults (SIGABRT) and valgrind shows errors of the kind:

==12853== Invalid write of size 4
==12853==at 0x400966: MAIN__ (aa.f90:7)
==12853==  Address 0x58e7b4c is 0 bytes after a block of size 4 alloc'd
==12853==at 0x4C256AE: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==12853==by 0x4008A4: MAIN__ (aa.f90:4)

Test case:

implicit none
integer,allocatable :: j(:)
integer :: i
allocate(j(1))
do i = 1,20
! deallocate(j)
 j = alloc()
end do
contains
function alloc()
  integer, allocatable :: alloc(:)
  allocate(alloc(1))
end function
end


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|enhancement |normal
   Keywords||wrong-code
Summary|[F2003] Automatic   |[TR 15581 / F2003] Automatic
   |reallocation on assignment  |reallocation on assignment
   |to allocatable variables|to allocatable variables


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

[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts

[dominiq at lps dot ens dot fr]

--- Comment #9 from dominiq at lps dot ens dot fr  2008-10-28 17:18 ---
The patch in comment #8 works as expected on my tests and regtest without
regression but conflicts with the patch for pr35681 in
http://gcc.gnu.org/ml/fortran/2008-10/msg00256.html.

Some synchronization seems needed.


-- 


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

[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic

[deji_aking at yahoo dot ca]

--- Comment #11 from deji_aking at yahoo dot ca  2008-10-28 17:07 ---
(In reply to comment #10)
> Subject: Re:  gfortran error and ICE at automatic type conversion with 
> transfer
> intrinsic
> 

> > When I run
> > 
> >   program test
> >   integer i
> >   i = transfer(-1,1.0)
> >   print *, i
> >   end
> > 
> > I get -2147483648 with gcc-4.2, ifort, and pgf90 on x86_64 Linux, and same
> > value with xlf on AIX with power5.
> > 
> 
> What does 
> 
> program test
> print *, transfer(-1,1.0)
> end program test
> 
> print with those compilers?
> 
NaN with all the compilers on x86_64 Linux and -NaNQ with xlf on power5 AIX.


-- 


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

[Bug target/37939] [4.2/4.3/4.4 Regression] CRIS port: no addi insn

[hp at gcc dot gnu dot org]

--- Comment #2 from hp at gcc dot gnu dot org  2008-10-28 16:56 ---
...and the ASHIFT is what is incoming to combine, despite there being a
multiplication in the code, all fine and by definition.


-- 


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

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

[howarth at nitro dot med dot uc dot edu]

--- Comment #28 from howarth at nitro dot med dot uc dot edu  2008-10-28 
16:55 ---
Doh, it may be an issue with the fink packaging system. They have a command...

NoSetCPPFLAGS: True

which I assumed was unsetting CPPFLAGS within fink but it very well may
be just setting CPPFLAGS to a null string. I'll remove that and substitute
the use of "unsetenv CPPFLAGS" instead. I update the bug report later this
evening with the results.


-- 


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

[Bug target/37939] [4.2/4.3/4.4 Regression] CRIS port: no addi insn

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2008-10-28 16:54 ---
Forgot to mention that combine "simplifies" the ASHIFT to a MULT, despite not
being in an address.  The corresponding address mode exists, and having the
same shape for both the separate insns and the addressing mode serves the
purpose for the time being, but it might be seen as an RTX canonicalization bug
on part of the combine pass.


-- 


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

[Bug target/37939] [4.2/4.3/4.4 Regression] CRIS port: no addi insn

[hp at gcc dot gnu dot org]

-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hp at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
  Known to fail||4.3.3
  Known to work||3.2.1
   Last reconfirmed|-00-00 00:00:00 |2008-10-28 16:51:37
   date||


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

[Bug target/37939] New: [4.2/4.3/4.4 Regression] CRIS port: no addi insn

[hp at gcc dot gnu dot org]

The CRIS port no longer emits an addi insn for (a << N) + b, where N = {1, 2}.
Trivial test-case:
/* Make sure ADDI is combined and emitted successfully.
   See also PRX.  */
/* { dg-do compile } */
/* { dg-options "-O2" } */
/* { dg-final { scan-assembler "addi" } } */
/* { dg-final { scan-assembler-not "lsl" } } */

int xyzzy (int r10, int r11)
{
  return r11 * 4 + r10;
}

This insn was created and emitted for e.g. 3.2.1
A look at the combine dump shows that the cost for the individual insns is 5
for the shift (the constant counts as 1 as per cris_rtx_costs) and 4 for the
add.  However, the combined cost is 10, also as per cris_rtx_costs, because the
insn is (perhaps wrongly) specified as (plus (mult 4 reg1) reg2) and the MULT
cost is 6 as per cris_rtx_costs and the PLUS counts as 4.
The way the target address cost function is called has changed, and
cris_address_cost needs adjustment.  Actually, it needs a rewrite, but an
adjustment will do for the 4.3 and 4.4/trunk, being in stage 3.
Patch in progress.


-- 
   Summary: [4.2/4.3/4.4 Regression] CRIS port: no addi insn
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-*-* and crisv32-*-*


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

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

[bonzini at gnu dot org]

--- Comment #27 from bonzini at gnu dot org  2008-10-28 16:39 ---
Ah, I missed that.  But yes, only libcpp/Makefile is supposed to have INCINTL.


-- 


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

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

[howarth at nitro dot med dot uc dot edu]

--- Comment #26 from howarth at nitro dot med dot uc dot edu  2008-10-28 
16:34 ---
No, I said earlier that the proposed patch doesn't work. Note that INCINTL
doesn't even appear in either the toplevel Makefile or the Makefile in intl
with your patch. It does appear in the libcpp Makefile but is set to nothing.


-- 


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

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

[bonzini at gnu dot org]

--- Comment #25 from bonzini at gnu dot org  2008-10-28 16:28 ---
Subject: Re:  [4.4 Regression] CPPFLAGS now unset for
 stage 1 build of libcpp files.

You do know that A=B in the command line overrides A=C in the makefile
right? :-)

Does the patch work?


-- 


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

[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.

[howarth at nitro dot med dot uc dot edu]

--- Comment #24 from howarth at nitro dot med dot uc dot edu  2008-10-28 
16:21 ---
I still don't understand how the stage1 build of libcpp manages to ignore the
CFLAGS setting in the libccp level Makefile. This would suggest that the stage
1
build of libcpp is entirely handled by the toplevel Makefile and the Makefile
in libcpp is ignored, no? I only see three instance of CPPFLAGS in the libcpp
level Makefile...

CPPFLAGS = -I/sw/include
...
ALL_CFLAGS = $(CFLAGS) $(WARN_CFLAGS) $(INCLUDES) $(CPPFLAGS)
...
COMPILE.base = $(CC) $(DEFS) $(INCLUDES) $(CPPFLAGS) $(ALL_CFLAGS) -c

I don't see how, even if CPPFLAGS is unset at the toplevel, that the setting of
CPPFLAGS is ignored if the libcpp level Makefile is actually being used in the
stage 1 build of libcpp.


-- 


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

[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #10 from sgk at troutmask dot apl dot washington dot edu  
2008-10-28 16:19 ---
Subject: Re:  gfortran error and ICE at automatic type conversion with transfer
intrinsic

On Tue, Oct 28, 2008 at 03:47:30PM -, deji_aking at yahoo dot ca wrote:
> 
> 
> --- Comment #9 from deji_aking at yahoo dot ca  2008-10-28 15:47 ---
> (In reply to comment #7)
> > > What does ... print?
> > 
> > NaN on both ppc/intel-Darwin9.
> > 
> > > My patch simply fixes the ICE in gfortran.
> > 
> > I think the conversion of NaN to int is buggy since the behavior is
> > platform/option dependent. Your patch just prevents to reach the bug.
> > It always
> > make me nervous when a bug is hidden without being understood.
> > 
> When I run
> 
>   program test
>   integer i
>   i = transfer(-1,1.0)
>   print *, i
>   end
> 
> I get -2147483648 with gcc-4.2, ifort, and pgf90 on x86_64 Linux, and same
> value with xlf on AIX with power5.
> 

What does 

program test
print *, transfer(-1,1.0)
end program test

print with those compilers?


-- 


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

[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic

[deji_aking at yahoo dot ca]

--- Comment #9 from deji_aking at yahoo dot ca  2008-10-28 15:47 ---
(In reply to comment #7)
> > What does ... print?
> 
> NaN on both ppc/intel-Darwin9.
> 
> > My patch simply fixes the ICE in gfortran.
> 
> I think the conversion of NaN to int is buggy since the behavior is
> platform/option dependent. Your patch just prevents to reach the bug. It 
> always
> make me nervous when a bug is hidden without being understood.
> 
When I run

  program test
  integer i
  i = transfer(-1,1.0)
  print *, i
  end

I get -2147483648 with gcc-4.2, ifort, and pgf90 on x86_64 Linux, and same
value with xlf on AIX with power5.


-- 


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

[Bug c++/37932] narrowing conversion with -std=c++0x

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2008-10-28 15:41 ---
Jason, what you think about this?

In any case, there are some issues with this code:

First, it would be better to print the type of the expression (%qT) rather than
the expression itself (%qE), because it is informative and in many cases we
cannot reconstruct the expression in any sensible way.

Also, that function could share a lot of code with conversion_warning in
c-common.c.

Finally, it is missing a proper comment above it.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at redhat dot com,
   ||manu at gcc dot gnu dot org


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

[Bug c++/37933] reference to ... is amibgous: same error shown twice for same line of code

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2008-10-28 15:27 ---
Confirmed also in mainline.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2008-10-28 15:27:52
   date||


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

gcc-bugs@gcc.gnu.org

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2008-10-28 15:24 ---
I can reproduce in vanilla 4.2.4 and 4.1.2 but cannot reproduce in 4.3.2 and
trunk. Not sure if this is a regression from 4.0 or earlier but in any case it
is fixed in 4.3.2 and mainline and there no more planned releases of the 4.2
branch.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
  Known to fail||4.2.4 4.1.2
  Known to work||4.3.2 4.4.0
 Resolution||FIXED


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

[Bug target/36568] infinite _Unwind_Backtrace / thread stack unwinding.

[pluto at agmk dot net]

--- Comment #7 from pluto at agmk dot net  2008-10-28 15:18 ---
(In reply to comment #5)
> This is a glibc bug then.
> 

hmm, Ulrich Drepper rejects this bug report.
http://sources.redhat.com/bugzilla/show_bug.cgi?id=6693#c1


-- 


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

[Bug c++/37934] show a warning when a symbol is unused and completely removed from the output file

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2008-10-28 15:10 ---
I think this is just some bit missing in our Wunused. We currently do this for
explicit static, so it shouldn't be hard to do it for the implicit one.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-10-28 15:10:32
   date||


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

[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #8 from sgk at troutmask dot apl dot washington dot edu  
2008-10-28 15:03 ---
Subject: Re:  gfortran error and ICE at automatic type conversion with transfer
intrinsic

On Tue, Oct 28, 2008 at 02:36:07PM -, dominiq at lps dot ens dot fr wrote:
> 
> > What does ... print?
> 
> NaN on both ppc/intel-Darwin9.
> 
> > My patch simply fixes the ICE in gfortran.
> 
> I think the conversion of NaN to int is buggy since the behavior
> is platform/option dependent. Your patch just prevents to reach
> the bug. It always make me nervous when a bug is hidden without
> being understood.

i = NaN is an assignment not a bitwise copy.  This isn't platform
dependent nor option dependent.  You simply can't assign a NaN to
an INTEGER.

In thinking about transfer(-1,1.0), this may also be invalid
because the standard forbids calling an intrinsic procedure
if it will return a result outside the representable range of
the return type.  There is probably some argument on whether
NaN is this range.  


-- 


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

[Bug libgomp/37938] libgomp testsuite failures on ia64-linux

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-10-28 15:02 ---
BTW, using + reduction in the same loop (and with asm optimization barrier for
that variable) I see the reduction computed value always correct, so the loop
body is executed the correct number of times.  That means in some cases the
memory reads/writes between GOMP_atomic_{start,end} must overlap between
threads.


-- 


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

[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts

[mikael dot morin at tele2 dot fr]

--- Comment #8 from mikael dot morin at tele2 dot fr  2008-10-28 14:42 
---
Created an attachment (id=16573)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16573&action=view)
second fix

This patch solves the problem by releasing the (4) condition, making the loop
bounds reset unconditional at the beginning of gfc_trans_create_temp_array. 
This is harmless because most of the time the loop->from is already zero (there
was an assertion for that before PR31610) and the code adds nothing, while in
other cases the bounds reset is executed. 


I had initially a problem though, because then the array indexes for accessing
elements of (/1,1,1/) were wrong as the offset for that array was set too
early, taking the initial loop bounds into account instead of the later
zero-based ones. 

I looked at what happened in the case of i as its indexes were not
miscalculated and found that there was a code for that at the end of
gfc_conv_loop_setup.

What this patch does is remove the code setting the offset according to the
loop in gfc_trans_array_constructor, and allow GFC_SS_CONSTRUCTOR in
gfc_conv_loop_setup's code.


This patch passes the regression tests without any new failure.


-- 


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

[Bug libgomp/37938] New: libgomp testsuite failures on ia64-linux

[jakub at gcc dot gnu dot org]

In one bootstrap/regtest on 16way Itanium 2 I saw
FAIL: libgomp.c/atomic-4.c execution test
FAIL: libgomp.c/nqueens-1.c execution test
FAIL: libgomp.c/pr29947-1.c execution test
FAIL: libgomp.c/sort-1.c execution test
FAIL: libgomp.c++/task-3.C  -O3 -fomit-frame-pointer  execution test
FAIL: libgomp.c++/task-3.C  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: libgomp.c++/task-5.C  -O1  execution test
FAIL: libgomp.c++/task-5.C  -O3 -g  execution test
in another one:
FAIL: libgomp.c/nqueens-1.c execution test
FAIL: libgomp.c/sort-1.c execution test
FAIL: libgomp.c++/collapse-2.C  -O2  execution test
FAIL: libgomp.c++/task-3.C  -Os  execution test
WARNING: program timed out.
FAIL: libgomp.c++/task-5.C  -O1  execution test
WARNING: program timed out.
FAIL: libgomp.c++/task-5.C  -O2  execution test

Trying atomic-4.c by hand, I see it aborts most of the time and even:
extern void abort (void);

int
main (void)
{
  int d = 0;
  int i;

#pragma omp parallel for shared (d)
for (i = 0; i < 10; i++)
  {
GOMP_atomic_start ();
d = d + 1;
GOMP_atomic_end ();
  }
  if (d != 10)
{
  __builtin_printf ("d is %d\n", d);
  return 1;
}
  return 0;
}
fails quite often (with OMP_NUM_THREADS=16 very soon, 50% in the first
invocation, with e.g. OMP_NUM_THREADS=4 less often, but still within first 40
invocations).  When it fails (both for original atomic-4.c and this testcase) d
is (slightly) smaller than it should be (say 1 through 10 smaller than
expected), but the test never hangs.  If just __sync builtin is used instead of
GOMP_atomic_{start,end} pair (e.g. when double instead of long double is used
in atomic-4.c, or int), then I couldn't reproduce any failures.  This happens
both with trunk libgomp and 4.1.2-RH system libgomp.  I wonder if we need a
barrier somewhere in ia64 specific code or something.

GOMP_atomic_start just uses gomp_mutex_lock (&atomic_lock); and GOMP_atomic_end
gomp_mutex_unlock (&atomic_lock);.  I haven't seen similar problems on other
arches, so I'm afraid this is ia64 specific.


-- 
   Summary: libgomp testsuite failures on ia64-linux
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: ia64-linux


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

[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic

[dominiq at lps dot ens dot fr]

--- Comment #7 from dominiq at lps dot ens dot fr  2008-10-28 14:36 ---
> What does ... print?

NaN on both ppc/intel-Darwin9.

> My patch simply fixes the ICE in gfortran.

I think the conversion of NaN to int is buggy since the behavior is
platform/option dependent. Your patch just prevents to reach the bug. It always
make me nervous when a bug is hidden without being understood.


-- 


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

[Bug fortran/35840] ICE for character expression in I/O specifier

[mikael dot morin at tele2 dot fr]

--- Comment #18 from mikael dot morin at tele2 dot fr  2008-10-28 14:08 
---
The final patch is here:
http://gcc.gnu.org/ml/fortran/2008-10/msg00104.html


-- 


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

[Bug fortran/35820] internal compiler error with nested FORALL

[mikael dot morin at tele2 dot fr]

--- Comment #9 from mikael dot morin at tele2 dot fr  2008-10-28 14:06 
---
So that they are not lost, patches are here:
http://gcc.gnu.org/ml/fortran/2008-10/msg00153.html
http://gcc.gnu.org/ml/fortran/2008-10/msg00181.html
http://gcc.gnu.org/ml/fortran/2008-10/msg00212.html

See the follow-up threads and the mailing list archive for comments.


-- 


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

[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #6 from sgk at troutmask dot apl dot washington dot edu  
2008-10-28 14:03 ---
Subject: Re:  gfortran error and ICE at automatic type conversion with transfer
intrinsic

On Tue, Oct 28, 2008 at 01:30:28PM -, dominiq at lps dot ens dot fr wrote:
> 
> --- Comment #5 from dominiq at lps dot ens dot fr  2008-10-28 13:30 
> ---
> On *-Darwin9 I get:
> 
>   i = transfer(-1,1.0)
>  1
> Error: Arithmetic overflow converting REAL(4) to INTEGER(4) at (1). This check
> can be disabled with the option -fno-range-check

What does 

program test
print *, transfer(-1,1.0)
end program test

print?

> I have not tested the patch in
> http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01183.html, but I am afraid that
> it will just hide the bug.

The actual bug is in the Fortran code!  My patch simply fixes the
ICE in gfortran.  By itself, transfer(-1,1.0) is valid and it so
happens to be an NaN.  i = NaN is invalid (although I doubt the
standard will actually say i = NaN is invalid in a straight forward
manner).


-- 


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

[Bug fortran/37937] New: Bind(C) diagnostic when using c_double for COMPLEX variables

[burnus at gcc dot gnu dot org]

REAL(c_double) matches "double" and is OK. However,
COMPLEX(c_double)  is invalid as the proper kind parameter
   is c_double_complex matching "double _Complex"

Internally, both yield the same value and also sizeof(0.0_c_double) and
sizeof(real(cmplx(0.0, c_double_cmpl)) is the same. Thus one could simply
accept c_double as synonym for c_double_complex.

gfortran, however, has checks build in which ensure the right KIND is used;
there is room for improvement however:

! --
use iso_c_binding
implicit none
real(c_double) :: r
complex(c_double) :: c ! << Wrong
type(c_ptr) :: ptr
ptr = c_loc(c) ! <<< ERROR here
end
! --

Error: C kind parameter is for type REAL but symbol 'c' at (1) is of type
COMPLEX


Expected: The error is printed in the "COMPLEX(c_double)" line and not in the
"c_loc" line. The other question is whether a WARNING is enough or whether one
wants to have an ERROR.


PS: Found at
http://www.lrz-muenchen.de/services/software/mathematik/gsl/fortran/README
"- gfortran 4.3.x does not support complex(c_double)."


-- 
   Summary: Bind(C) diagnostic when using c_double for COMPLEX
variables
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

gcc-bugs@gcc.gnu.org

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2008-10-28 13:34 
---
Cannot be reproduced in mainline and 4_3-branch.


-- 


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

gcc-bugs@gcc.gnu.org

[jeff_harris at kentrox dot com]

--- Comment #1 from jeff_harris at kentrox dot com  2008-10-28 13:27 ---
Created an attachment (id=16572)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16572&action=view)
Source code for bug


-- 


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

[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2008-10-28 13:30 ---
On *-Darwin9 I get:

  i = transfer(-1,1.0)
 1
Error: Arithmetic overflow converting REAL(4) to INTEGER(4) at (1). This check
can be disabled with the option -fno-range-check

If I use the option -fno-range-check I get:

gfortran: Internal error: Illegal instruction (program f951)
Please submit a full bug report.
See  for instructions.

on Intel and

Out of stack space.
Try running 'limit stacksize unlimited' in the shell to raise its limit.

on ppc.

I have not tested the patch in
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01183.html, but I am afraid that
it will just hide the bug.


-- 


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

gcc-bugs@gcc.gnu.org

[jeff_harris at kentrox dot com]

--- Comment #2 from jeff_harris at kentrox dot com  2008-10-28 13:27 ---
Compiled as: g++ -Wall -O2 -v -save-temps badref2.cpp


-- 


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

gcc-bugs@gcc.gnu.org

[jeff_harris at kentrox dot com]

I have found an error in the optimizer that is causing it to over-optimze a
conditional operator, ?:.  The optimizer will always choose the first option
regardless of the value of the condition.  In the code, the call to setHelpInt1
is always passed the value for UP even though DOWN is the correct option at
runtime.  Subsequent uses of the same condition produce the correct output. 
Swapping UP and DOWN in getState() causes DOWN to be forced.

The incorrect output generated is:
setInt 1 to 1
setInt 2 to 2
val: 2

The correct output is:
setInt 1 to 2
setInt 2 to 2
val: 2


A slight change in the code will cause the error to not occur.  Any of the
following changes will cause the optimizer to work correctly:
- Make getState() not inlined
- Change the getState() function to write out the conditional operator as an
if/else statement
- Remove the if(gok) test in main()
- Change if(gok) to if(gflags) in main()
- Compile with -O instead of -O2
- Change the signature of setHelpInt2 to take a const int instead of a const
int&.  This is the strangest 'fix' as it occurs after the call to setHelpInt1.

The error is present on a RHEL 5.1 64-bit system with GCC 4.1.2 with the
specified configuration:
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)
 /usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1plus -E -quiet -v -D_GNU_SOURCE
badref2.cpp -mtune=generic -Wall -O2 -fpch-preprocess -o badref2.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2

/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux
 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/backward
 /usr/local/include
 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include
 /usr/include
End of search list.
 /usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1plus -fpreprocessed badref2.ii
-quiet -dumpbase badref2.cpp -mtune=generic -auxbase badref2 -O2 -Wall -version
-o badref2.s
GNU C++ version 4.1.2 20070626 (Red Hat 4.1.2-14) (x86_64-redhat-linux)
compiled by GNU C version 4.1.2 20070626 (Red Hat 4.1.2-14).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 6f6d1884a37abf7abe8da2d985ac9045
 as -V -Qy -o badref2.o badref2.s
GNU assembler version 2.17.50.0.6-5.el5 (x86_64-redhat-linux) using BFD version
2.17.50.0.6-5.el5 20061020
 /usr/libexec/gcc/x86_64-redhat-linux/4.1.2/collect2 --eh-frame-hdr -m
elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtbegin.o
-L/usr/lib/gcc/x86_64-redhat-linux/4.1.2
-L/usr/lib/gcc/x86_64-redhat-linux/4.1.2
-L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64 badref2.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtend.o
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crtn.o

It has also been reproduced on a PPC cross-compiler with GCC 4.2.1.  Both
systems exhibit the same behavior regarding the changes that fix the problem.
Using built-in specs.
Target: powerpc-ai-linux
Configured with: /tmphome/jeffh/dev/toolkit-rh5/modules/gcc/configure
--prefix=/usr/local/ai/ppc826x-lx2.4-1.70
--srcdir=/tmphome/jeffh/dev/toolkit-rh5/modules/gcc --enable-languages=c,c++
--target=powerpc-ai-linux
--with-libs=/usr/local/ai/ppc826x-lx2.4-1.70/target/lib
--with-headers=/usr/local/ai/ppc826x-lx2.4-1.70/target/usr/include
--enable-shared --disable-nls --with-cpu=603e --enable-threads
--enable-__cxa_atexit --with-gnu-ld --with-gnu-as
Thread model: posix
gcc version 4.2.1
 /usr/local/ai/ppc826x-lx2.4-1.70/libexec/gcc/powerpc-ai-linux/4.2.1/cc1plus -E
-quiet -v -D_GNU_SOURCE -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix
-Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix badref2.cpp
-mcpu=603e -O2 -fpch-preprocess -o badref2.ii
#include "..." search starts here:
#include <...> search starts here:

/usr/local/ai/ppc826x-lx2.4-1.70/lib/gcc/powerpc-ai-linux/4.2.1/../../../../powerpc-ai-linux/include/c++/4.2.1

/usr/local/ai/ppc826x-lx2.4-1.70/lib/gcc/powerpc-ai-linux/4.2.1/../../../../powerpc-ai-linux/include/c++/4.2.1/powerpc-ai-linux

/us

[Bug libgomp/37935] New: omp_set_schedule not documented in libgomp.texi

[burnus at gcc dot gnu dot org]

I just saw that at least omp_set_schedule but maybe all new OpenMP 3 functions
are not documented in libgomp.texi.


-- 
   Summary: omp_set_schedule not documented in libgomp.texi
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: documentation, openmp
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug middle-end/37913] [4.4 Regression] ICE: Segmentation fault in link_block, cfg.c:153

[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-
   ||10/msg01190.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-10-25 09:46:53 |2008-10-28 13:09:04
   date||


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

[Bug c++/37934] New: show a warning when a symbol is unused and completely removed from the output file

[edwintorok at gmail dot com]

Consider the testcase below.

$ cat test.cpp
namespace x {
extern const char ** const foo;
extern const char ** const bar;
};

using namespace x;

namespace {
const char* X;
};

const char ** const foo = &X;
const char ** const x::bar = &X;

$ g++ test.cpp -Wall -Wunused -Wextra -c -o test.o
$ nm test.o | c++filt
 b (anonymous namespace)::X
 R x::bar

foo is completely removed from the output, and no warning is shown.

It would be useful to show a warning here.

For example in the above testcase I forgot to add the x:: namespace qualifier
to foo (the extern declaration was in a header and I didn't notice it was part
of a namespace). 
Since I didn't get any warning, I got a linker error, and had to spend some
time tracing down this typo in my code.
Had I seen a warning from the compiler that 'foo' is not used
and will get removed I would have immediately noticed the absence of the x::
namespace qualifier.


-- 
   Summary: show a warning when a symbol is unused and completely
removed from the output file
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug c++/37933] New: reference to ... is amibgous: same error shown twice for same line of code

[edwintorok at gmail dot com]

$ cat test.cpp
namespace x {
extern char *foo;
};
using namespace x;
char *foo;
char bar()
{
return *foo;
}

$ g++ test.cpp -fsyntax-only
test.cpp: In function ‘char bar()’:
test.cpp:8: error: reference to ‘foo’ is ambiguous
test.cpp:5: error: candidates are: char* foo
test.cpp:2: error: char* x::foo
test.cpp:8: error: reference to ‘foo’ is ambiguous
test.cpp:5: error: candidates are: char* foo
test.cpp:2: error: char* x::foo

The same error is shown twice.
I think it would be enough to show the error once.

This is with:
$ g++ -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--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.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1)

Same happens with g++-4.2, and trunk (r141407), g++-4.1 appears to infloop.


-- 
   Summary: reference to ... is amibgous: same error shown twice for
same line of code
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts

[mikael dot morin at tele2 dot fr]

--- Comment #7 from mikael dot morin at tele2 dot fr  2008-10-28 12:21 
---
This is happening because
(1) gfc_trans_constant_array_constructor sets loop->temp_dim to 1.
(2) gfc_conv_loop_setup choses the last ss whose shape is known (that of i). 
(3) gfc_conv_loop_setup sets loop bounds (-1->1) according to the chosen ss
(i). 
(4) gfc_trans_create_temp_array conditionally resets the loop bounds (if n >=
loop->temp_dim).
(5) gfc_trans_create_temp_array later assumes that the loop starts at zero. 


(2) explains why it works with y(i+(/1,1,1/)) but not with y((/1,1,1/)+i)
My patch in comment #3 changes the "last ss" to "first ss" and of course it
doesn't work as was said in comment #6

I have two fixes almost ready. 


-- 


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

[Bug c++/26693] [4.2/4.3/4.4 regression] Access checks not performed for types in templates

[dodji at gcc dot gnu dot org]

-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-09-01 20:49:21 |2008-10-28 12:16:16
   date||


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

[Bug middle-end/37931] [4.4 Regression] ice: verify_gimple failed

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-10-28 10:38 ---
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=37931

[Bug middle-end/37931] [4.4 Regression] ice: verify_gimple failed

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-10-28 10:36 ---
Subject: Bug 37931

Author: jakub
Date: Tue Oct 28 10:34:51 2008
New Revision: 141406

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141406
Log:
PR middle-end/37931
* fold-const.c (distribute_bit_expr): Convert common, left and
right arguments to type.

* gcc.c-torture/execute/pr37931.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr37931.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/37932] New: narrowing conversion with -std=c++0x

[holger dot hopp at sap dot com]

There some confusing/wrong error messages with the -std=c++0x option.
All three example statements below work fine without -std=c++0x and with
gcc versions <= 4.3. Seems to be a gcc bug and no C++0x demand (at least
the first 2 example statements).


typedef enum { AA=1, BB=2 } my_enum;

typedef struct { my_enum a:4 ; unsigned b:28; } stru;

void foo (char c, my_enum x, int i)
{
  char arr[2] = {c+'0', 0};
  stru s = {x,0};
  stru t = {i,0};
}


$ g++ -std=c++0x -c tst.c
tst.c: In function 'void foo(char, my_enum, int)':
tst.c:7: error: narrowing conversion of '(((int)c) + 48)' to 'char' inside { }
tst.c:8: error: narrowing conversion of 'x' to 'unsigned char:4' inside { }
tst.c:9: error: narrowing conversion of 'i' to 'unsigned char:4' inside { }


gcc trunk rev. 141404


-- 
   Summary: narrowing conversion with -std=c++0x
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: holger dot hopp at sap dot com
 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=37932

[Bug c/37931] [4.4 Regression] ice: verify_gimple failed

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-10-28 07:54 ---
Even smaller:
int a;
unsigned int b;

int
foo (void)
{
  return (a | 1) & (b | 1);
}


-- 

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-10-28 07:47:39 |2008-10-28 07:54:17
   date||


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

[Bug c/37931] [4.4 Regression] ice: verify_gimple failed

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-10-28 07:47 ---
Smaller testcase:
int
foo (void)
{
  int a = 0, b = 0;
  unsigned int c = 0;
  return (a | b == b) & (c | 1);
}


-- 

jakub 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-10-28 07:47:39
   date||
Summary|ice: verify_gimple failed   |[4.4 Regression] ice:
   ||verify_gimple failed
   Target Milestone|--- |4.4.0


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