[Bug testsuite/37675] gcc.dg/torture/pr36891.c doesn't work on Linux/ia32

[bonzini at gnu dot org]

-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bonzini at gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
  Component|tree-optimization   |testsuite
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-09-30 09:25:04
   date||


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

[Bug middle-end/37669] [4.4 Regression] ice for legal code with -O2

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2008-09-30 09:26 ---
Must be darwin specific then, can't reproduce on x86_64-linux and from quick
skim of gcc-testresults nobody else that supplied test summary recently managed
to reproduced it.


-- 


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

[Bug testsuite/37675] gcc.dg/torture/pr36891.c doesn't work on Linux/ia32

[bonzini at gcc dot gnu dot org]

--- Comment #1 from bonzini at gnu dot org  2008-09-30 09:27 ---
Subject: Bug 37675

Author: bonzini
Date: Tue Sep 30 09:26:22 2008
New Revision: 140779

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140779
Log:
2008-09-30  Paolo Bonzini  <[EMAIL PROTECTED]>

PR testsuite/36891
PR testsuite/37675
* gcc.dg/torture/pr36891.c: Add -msse on 32-bit i386.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/pr36891.c


-- 


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

[Bug tree-optimization/36891] [4.2/4.3 Regression] ICE with vector division and -ffast-math and LIM

[bonzini at gcc dot gnu dot org]

--- Comment #8 from bonzini at gnu dot org  2008-09-30 09:27 ---
Subject: Bug 36891

Author: bonzini
Date: Tue Sep 30 09:26:22 2008
New Revision: 140779

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140779
Log:
2008-09-30  Paolo Bonzini  <[EMAIL PROTECTED]>

PR testsuite/36891
PR testsuite/37675
* gcc.dg/torture/pr36891.c: Add -msse on 32-bit i386.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/pr36891.c


-- 


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

[Bug testsuite/37675] gcc.dg/torture/pr36891.c doesn't work on Linux/ia32

[bonzini at gnu dot org]

--- Comment #2 from bonzini at gnu dot org  2008-09-30 09:33 ---
fixed.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/37673] Programs fail to execute with a runtime error when locale is set

[ivranos at freemail dot gr]

--- Comment #8 from ivranos at freemail dot gr  2008-09-30 09:51 ---
Note: Change the encoding of your browser and email client to Greek-ISO or
Unicode, so as to see the messages correctly.



locale -a displays the following:

[EMAIL PROTECTED]:~/Desktop/download/extract$ locale -a
C
el_CY.utf8
el_GR.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IN
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZW.utf8
POSIX
[EMAIL PROTECTED]:~/Desktop/download/extract$ 


==> Using these locales in the 3 of the 4 codes supplied, they work OK.


However the code number (3.) works only for "en_US.utf8", and it doesn't work
for "el_GR.utf8".


For "en_US.utf8":

#include 
#include 
#include 


int main()
{
using namespace std;

wcin.imbue(locale("en_US.utf8"));
wcout.imbue(locale("en_US.utf8"));

wstring ws;

wcin>> ws;

wcout<< ws<< endl;
} 


[EMAIL PROTECTED]:~/Desktop/download/extract$ ./main
Test
Test
[EMAIL PROTECTED]:~/Desktop/download/extract$ 


For: "el_GR.utf8"

#include 
#include 
#include 


int main()
{
using namespace std;

wcin.imbue(locale("el_GR.utf8"));
wcout.imbue(locale("el_GR.utf8"));

wstring ws;

wcin>> ws;

wcout<< ws<< endl;
} 


[EMAIL PROTECTED]:~/Desktop/download/extract$ ./main
Δοκιμαστικό

[EMAIL PROTECTED]:~/Desktop/download/extract$



As I said, the locales work in the 3 of the 4 codes supplied, but code number
(3.) doesn't.

So this isn't a "blocker" bug, but there is still a bug with wcin.imbue() and
wcout.imbue() when they are used alone without a 

"locale::global(locale("en_US"));"

or 

"ios_base::sync_with_stdio(false);"


statement.


wofstream works OK without any of the above statements.

For example the code:


#include 
#include 
#include 


int main()
{
using namespace std;

wstring ws=
L"Δοκιμαστικό\n";

wofstream file("filename.txt");

file.imbue(locale("el_GR.utf8"));

   if(file.is_open())
  file<< ws;

}

works OK:

[EMAIL PROTECTED]:~/Desktop/download/extract$ g++ -ansi -pedantic-errors -Wall
main.cpp -o main
[EMAIL PROTECTED]:~/Desktop/download/extract$ cat filename.txt 
Δοκιμαστικό
[EMAIL PROTECTED]:~/Desktop/download/extract$ 


-- 

ivranos at freemail dot gr changed:

   What|Removed |Added

   Severity|blocker |normal
 Status|RESOLVED|UNCONFIRMED
   GCC host triplet||Ubuntu 8.04 x86
 Resolution|DUPLICATE   |


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

[Bug tree-optimization/37664] [4.4 Regression] ice in remove_range_assertions, at tree-vrp.c:5116

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-09-30 10:03 ---
For -fwrapv I wonder why we add TREE_OVERFLOW at all.
force_fit_type_double does:

  /* Size types *are* sign extended.  */
  sign_extended_type = (!TYPE_UNSIGNED (type)
|| (TREE_CODE (type) == INTEGER_TYPE
&& TYPE_IS_SIZETYPE (type)));

  overflow = fit_double_type (low, high, &low, &high, type);

  /* If we need to set overflow flags, return a new unshared node.  */
  if (overflowed || overflow)
{
  if (overflowed
  || overflowable < 0
  || (overflowable > 0 && sign_extended_type))
{
  tree t = make_node (INTEGER_CST);
  TREE_INT_CST_LOW (t) = low;
  TREE_INT_CST_HIGH (t) = high;
  TREE_TYPE (t) = type;
  TREE_OVERFLOW (t) = 1;
  return t;
}
}

but as with -fwrapv signed overflow is defined, I'd say we should clear
sign_extended_type if flag_wrapv (or add " && !flag_wrapv" to the overflowable
> 0 condition).


-- 


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

[Bug libstdc++/35353] C++ wide character locale doesn't work

[paolo dot carlini at oracle dot com]

--- Comment #13 from paolo dot carlini at oracle dot com  2008-09-30 10:21 
---
*** Bug 37673 has been marked as a duplicate of this bug. ***


-- 


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

[Bug libstdc++/37673] Programs fail to execute with a runtime error when locale is set

[paolo dot carlini at oracle dot com]

--- Comment #9 from paolo dot carlini at oracle dot com  2008-09-30 10:21 
---
(In reply to comment #8)
> So this isn't a "blocker" bug, but there is still a bug with wcin.imbue() and
> wcout.imbue() when they are used alone without a 
> 
> "locale::global(locale("en_US"));"
> 
> or 
> 
> "ios_base::sync_with_stdio(false);"

and this is clearly a duplicate of libstdc++/35353, which, note, given the
current wording of the standard, is a Quality of Implementation Issue, not a
proper bug. Anyway, as I said, nothing new here.


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


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/37680] New: ICE: unable to generate reloads for: (insn:QI

[aldot at gcc dot gnu dot org]

Using built-in specs.
Target: m68k-linux-uclibc
Configured with: /there/toolchain_build_m68k/gcc-4.3.2/configure --prefix=/usr
--build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=m68k-linux-uclibc
--enable-languages=c,fortran --with-sysroot=/there/build_m68k/staging_dir
--with-build-time-tools=/there/build_m68k/staging_dir/usr/m68k-linux-uclibc/bin
--disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared
--with-gmp=/there/toolchain_build_m68k/gmp
--with-mpfr=/there/toolchain_build_m68k/mpfr --disable-nls --enable-threads
--disable-multilib --disable-libssp --disable-libssp --disable-libmudflap
--disable-libgomp --enable-decimal-float=no
Thread model: posix
gcc version 4.3.2 (GCC) 
COLLECT_GCC_OPTIONS='-O2' '-fno-strength-reduce' '-fomit-frame-pointer'
'-ffixed-a2' '-c' '-o' 'bug.o' '-w' '-v' '-m68020'

/there/build_m68k/staging_dir/usr/bin/../libexec/gcc/m68k-linux-uclibc/4.3.2/cc1
-fpreprocessed ocfs2_alloc.14.i -quiet -dumpbase ocfs2_alloc.14.i -m68020
-auxbase-strip bug.o -O2 -w -version -fno-strength-reduce -fomit-frame-pointer
-ffixed-a2 -o /tmp/ccPPnDEw.s
GNU C (GCC) version 4.3.2 (m68k-linux-uclibc)
compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e46c73a65794f9c9fe8cc606fdcc10e7
ocfs2_alloc.14.i: In function 'ocfs2_remove_extent':
ocfs2_alloc.14.i:196: error: unable to generate reloads for:
(insn:QI 147 146 148 14 ocfs2_alloc.14.i:99 (parallel [
(set (cc0)
(compare (reg:DI 5 %d5 [orig:56 D.1892 ] [56])
(reg:DI 0 %d0 [108])))
(clobber (reg:DI 109))
]) 12 {*m68k.md:521} (expr_list:REG_DEAD (reg:DI 0 %d0 [108])
(expr_list:REG_UNUSED (reg:DI 109)
(nil
ocfs2_alloc.14.i:196: internal compiler error: in find_reloads, at
reload.c:3767
Please submit a full bug report,


-- 
   Summary: ICE: unable to generate reloads for: (insn:QI
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
 GCC build triplet: i386-pc-linux-gnu
  GCC host triplet: i386-pc-linux-gnu
GCC target triplet: m68k-linux-uclibc


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

[Bug target/37680] ICE: unable to generate reloads for: (insn:QI

[aldot at gcc dot gnu dot org]

--- Comment #1 from aldot at gcc dot gnu dot org  2008-09-30 10:24 ---
Created an attachment (id=16431)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16431&action=view)
reduced from linux-2.6.26.5/fs/ocfs2/alloc.c


-- 


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

[Bug fortran/37445] Host-associated proc not found if same-name generic is use-associated

[pault at gcc dot gnu dot org]

--- Comment #15 from pault at gcc dot gnu dot org  2008-09-30 10:29 ---
(In reply to comment #14)
> Created an attachment (id=16429)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16429&action=view) [edit]
> Reduced test case which is failing with the patch
> 

OK - I'll get onto it!

Thanks

Paul


-- 


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

[Bug middle-end/37221] Missed early loop-unroll optimization - causes 40% degradation on SPU

[rguenth at gcc dot gnu dot org]

-- 

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|2008-08-24 22:04:27 |2008-09-30 10:37:35
   date||


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

[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures

[rguenth at gcc dot gnu dot org]

--- Comment #21 from rguenth at gcc dot gnu dot org  2008-09-30 10:37 
---
Subject: Bug 37491

Author: rguenth
Date: Tue Sep 30 10:36:22 2008
New Revision: 140781

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140781
Log:
2008-09-30  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/37491
* tree-vect-transform.c (vect_create_data_ref_ptr): Properly
build restrict-qualified pointers.
(vectorizable_store): Move alias check later.
(vectorizable_load): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-transform.c


-- 


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

[Bug ada/37681] New: [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error

[ro at gcc dot gnu dot org]

As of 20080929 (rev 140759), libada fails to build on Solaris 10/x86:

/vol/gccsrc/obj/gcc-4.4.0-20080929/10-gcc/./gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.4.0-20080929/10-gcc/./gcc/
-B/vol/gcc/i386-pc-solaris2.10/bin/ -B/vol/gcc/i386-pc-solaris2.10/lib/
-isystem /vol/gcc/i386-pc-solaris2.10/include -isystem
/vol/gcc/i386-pc-solaris2.10/sys-include -c -g -O2 -m64 -fPIC  -W -Wall -gnatpg
-m64  a-finali.adb -o a-finali.o
a-finali.ads:64:09: alignment for "Controlledb44s" must be at least 8
a-finali.ads:64:09: alignment for "Controlledr42s" must be at least 8
a-finali.ads:64:09: alignment for "Controlledt39s" must be at least 8
a-finali.ads:70:09: alignment for "Limited_Controlledb79s" must be at least 8
a-finali.ads:70:09: alignment for "Limited_Controlledr77s" must be at least 8
a-finali.ads:70:09: alignment for "Limited_Controlledt74s" must be at least 8
make[9]: *** [a-finali.o] Error 1

This happens only for the 64-bit libada, so it's probably due to missing
support
for the 64-bit multilib.


-- 
   Summary: [4.4 regression] Building 64-bit libada fails on
Solaris/x86: alignment error
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
 GCC build triplet: i386-pc-solaris2.10
  GCC host triplet: i386-pc-solaris2.10
GCC target triplet: i386-pc-solaris2.10


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

[Bug tree-optimization/37662] [4.4 Regression] ice: tree check: expected ssa_name, have integer_cst in get_value_range, at tree-vrp.c:612

[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|NEW |ASSIGNED
   Last reconfirmed|2008-09-28 18:37:03 |2008-09-30 12:29:56
   date||


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

[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]

-- 

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-09-28 18:23:24 |2008-09-30 12:30:09
   date||


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

[Bug middle-end/37666] [4.4 Regression] ICE compiling newlib

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-09-30 12:41 ---
And w/o preprocessed source we cannot do anything.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug tree-optimization/37664] [4.4 Regression] ice in remove_range_assertions, at tree-vrp.c:5116

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-09-30 12:46 ---
IMHO force_fit_type_double is correct.  We also set TREE_OVERFLOW on
truncations which are implementation defined.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug ada/37681] [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug middle-end/37679] -fstrict-aliasing causes omission of double-to-float conversion

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-09-30 13:01 ---
Fixed in 4.2.0.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c++ |middle-end
  Known to fail|4.1.2   |4.1.0 4.1.2
  Known to work|3.3.5 4.0.2 |3.3.5 4.0.2 4.0.4 4.2.0
 Resolution||FIXED
   Target Milestone|--- |4.2.0


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

[Bug middle-end/37666] [4.4 Regression] ICE compiling newlib

[joel at gcc dot gnu dot org]

--- Comment #3 from joel at gcc dot gnu dot org  2008-09-30 13:06 ---
Created an attachment (id=16432)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16432&action=view)
preprocessed code

Prepropcessed output -- untrimmed


-- 


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

[Bug libstdc++/30085] switch debug mode hash containers from ext to tr1

[paolo at gcc dot gnu dot org]

--- Comment #13 from paolo at gcc dot gnu dot org  2008-09-30 13:50 ---
Subject: Bug 30085

Author: paolo
Date: Tue Sep 30 13:49:15 2008
New Revision: 140787

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140787
Log:
2008-09-30  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/30085 (again)
* include/debug/unordered_map (unordered_map<>, unordered_multimap<>):
Do not derive from _Safe_association, derive from _GLIBCXX_STD_D::
unordered_map / unordered_multimap; add missing member functions.
* include/debug/unordered_set (unordered_set<>, unordered_multiset<>):
Likewise for _GLIBCXX_STD_D::unordered_set / unordered_multiset.
* include/debug/safe_association.h: Remove.
* include/Makefile.am: Adjust.
* include/Makefile.in: Regenerate.
* testsuite/23_containers/unordered_multimap/init-list.cc: Remove
xfail.

Modified:
trunk/libstdc++-v3/ChangeLog


-- 


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

[Bug c++/37682] New: g++ internal error: verify_gimple failed

[holger dot hopp at sap dot com]

With current trunk (rev. 140784) I get following internal error (g++ only).
The error message is similar to bug 37418.
Maybe it's the same problem, but maybe it's not.

$ /holger/gcc/gnu/trunk/install/bin/g++ -c t.c
t.c: In function unsigned int bar(unsigned int, const void*, RefId):
t.c:9: error: non-trivial conversion at assignment
unsigned int
const 
iftmp.0 = refId.refSector;

t.c:9: error: non-trivial conversion at assignment
unsigned int

iftmp.0 = refPtr->refSector;

t.c:9: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Exit 1


Source:

typedef struct
{
  unsigned refKind : 8;
  unsigned refSector : 24;
} RefId;

unsigned foo (const unsigned x);

unsigned bar (const int cond, const RefId * const refPtr, const RefId refId)
{
  return foo ( cond ? ((refId).refSector) : ((*refPtr).refSector) );
}


-- 
   Summary: g++ internal error: verify_gimple failed
   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=37682

[Bug libstdc++/30085] switch debug mode hash containers from ext to tr1

[paolo dot carlini at oracle dot com]

--- Comment #14 from paolo dot carlini at oracle dot com  2008-09-30 13:52 
---
Fixed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/30085] switch debug mode hash containers from ext to tr1

[paolo at gcc dot gnu dot org]

--- Comment #12 from paolo at gcc dot gnu dot org  2008-09-30 13:50 ---
Subject: Bug 30085

Author: paolo
Date: Tue Sep 30 13:48:55 2008
New Revision: 140786

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140786
Log:
2008-09-30  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/30085 (again)
* include/debug/unordered_map (unordered_map<>, unordered_multimap<>):
Do not derive from _Safe_association, derive from _GLIBCXX_STD_D::
unordered_map / unordered_multimap; add missing member functions.
* include/debug/unordered_set (unordered_set<>, unordered_multiset<>):
Likewise for _GLIBCXX_STD_D::unordered_set / unordered_multiset.
* include/debug/safe_association.h: Remove.
* include/Makefile.am: Adjust.
* include/Makefile.in: Regenerate.
* testsuite/23_containers/unordered_multimap/init-list.cc: Remove
xfail.

Removed:
trunk/libstdc++-v3/include/debug/safe_association.h
Modified:
trunk/libstdc++-v3/include/Makefile.am
trunk/libstdc++-v3/include/Makefile.in
trunk/libstdc++-v3/include/debug/unordered_map
trunk/libstdc++-v3/include/debug/unordered_set
trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/init-list.cc


-- 


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

[Bug middle-end/37666] [4.4 Regression] ICE compiling newlib

[joel at gcc dot gnu dot org]

--- Comment #4 from joel at gcc dot gnu dot org  2008-09-30 14:03 ---
Arguments to create ICE were "-O2 -mthumb"


-- 


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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[nickc at redhat dot com]

--- Comment #24 from nickc at redhat dot com  2008-09-30 14:05 ---
Subject: Re:  [cygming] Invalid alignment for SSE store
 to .comm data generated with -O3

> a printf in the code for ff_cos_16 causes the compiler to align the var,
> but at this point it crashes in another place using sse code

So, does this mean that the align patch is working, but that there is 
some other bug that is preventing some sse code from working ?  If so 
then I can formally submit the align patch for approval.

Cheers
   Nick


-- 


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

[Bug ada/37681] [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error

[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=37681

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[sherpya at netfarm dot it]

--- Comment #25 from sherpya at netfarm dot it  2008-09-30 14:10 ---
(In reply to comment #24)
> Subject: Re:  [cygming] Invalid alignment for SSE store
>  to .comm data generated with -O3
> 
> > a printf in the code for ff_cos_16 causes the compiler to align the var,
> > but at this point it crashes in another place using sse code
> 
> So, does this mean that the align patch is working, but that there is 
> some other bug that is preventing some sse code from working ?  If so 
> then I can formally submit the align patch for approval.
> 
> Cheers
>Nick
> 

unfortunately not, with a printf the var is aligned without a printf is not
aligned (someone changes the behavior of the patch), and thus it will crash

the patch seems to make the right job but some other tool in the chain
interferes with it


-- 


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

[Bug c++/37683] New: [4.4 Regression]: Revision 140780 caused g++.dg/warn/Wparentheses-3.C

[hjl dot tools at gmail dot com]

On Linux/ia32, I got

Executing on host:
/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/g++/../../g++
-B/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/g++/../../
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/g++.dg/warn/Wparentheses-3.C
 -nostdinc++
-I/export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
-I/export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libstdc++-v3/include
-I/export/gnu/import/svn/gcc-test/src-trunk/libstdc++-v3/libsupc++
-I/export/gnu/import/svn/gcc-test/src-trunk/libstdc++-v3/include/backward
-I/export/gnu/import/svn/gcc-test/src-trunk/libstdc++-v3/testsuite/util
-fmessage-length=0  -Wparentheses  -S  -o Wparentheses-3.s(timeout = 300)
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/g++.dg/warn/Wparentheses-3.C:
In constructor 'A< >::A()':^M
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/g++.dg/warn/Wparentheses-3.C:10:
warning: suggest explicit braces to avoid ambiguous 'else'^M
output is:
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/g++.dg/warn/Wparentheses-3.C:
In constructor 'A< >::A()':^M
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/g++.dg/warn/Wparentheses-3.C:10:
warning: suggest explicit braces to avoid ambiguous 'else'^M

FAIL: g++.dg/warn/Wparentheses-3.C (test for excess errors)
Excess errors:
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/g++.dg/warn/Wparentheses-3.C:10:
warning: suggest explicit braces to avoid ambiguous 'else'

I configured gcc with

--enable-checking=assert --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld


-- 
   Summary: [4.4 Regression]: Revision 140780 caused
g++.dg/warn/Wparentheses-3.C
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
  GCC host triplet: i686-pc-linux-gnu


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

[Bug c++/37683] [4.4 Regression]: Revision 140780 caused g++.dg/warn/Wparentheses-3.C

[bonzini at gnu dot org]

--- Comment #1 from bonzini at gnu dot org  2008-09-30 14:35 ---
Other gcc-testresults don't indicate the failure for revision 140785 or even
140781.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/37683] [4.4 Regression]: Revision 140780 caused g++.dg/warn/Wparentheses-3.C

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2008-09-30 14:44 ---
(In reply to comment #1)
> Other gcc-testresults don't indicate the failure for revision 140785 or even
> 140781.
> 

Are they run on Linux/ia32 and configured with

--enable-checking=assert --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld

Linux/ia32 and --enable-checking=assert may trigger this bug.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug target/37571] [4.4 regression] Performance regression due to compare/branch fuse optimization

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2008-09-30 14:57 ---
If fixed, then it should be closed as fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug ada/37681] [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error

[ebotcazou at gcc dot gnu dot org]

--- Comment #1 from ebotcazou at gcc dot gnu dot org  2008-09-30 15:01 
---
> This happens only for the 64-bit libada, so it's probably due to missing
> support for the 64-bit multilib.

Yes, it is, the hitch being that there is no port to x86_64/Solaris yet.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-09-30 15:01:45
   date||


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

[Bug c++/37683] [4.4 Regression]: Revision 140780 caused g++.dg/warn/Wparentheses-3.C

[bonzini at gnu dot org]

--- Comment #3 from bonzini at gnu dot org  2008-09-30 15:05 ---
> Linux/ia32 and --enable-checking=assert may trigger this bug.

Well, your own Linux/x86-64 builds do not have this failure, neither normally
nor for -m32.  Either this bug is invalid, or it is a wrong-code somewhere
else.  So, no "may"s please.

Can you put a breakpoint in warning_at for the empty-body warning, and check
what's the value of warn_empty_body?

If warn_empty_body is 1, can you check where it is set to 1?  It should not be
unless -Wempty-body or -Wextra are given.  If it is -1, likewise, it should
have been set to 0 or 1 in opts.c.

If it is 0, can you test the value of "option_enabled (OPT_Wempty_body)"?  It
should also be 0, or option_enabled is miscompiled.


-- 


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

[Bug ada/37681] [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error

[ro at techfak dot uni-bielefeld dot de]

--- Comment #3 from ro at techfak dot uni-bielefeld dot de  2008-09-30 
15:06 ---
Subject: Re:  [4.4 regression] Building 64-bit libada fails on Solaris/x86:
alignment error

ebotcazou at gcc dot gnu dot org writes:

> Yes, it is, the hitch being that there is no port to x86_64/Solaris yet.

I'm just testing the (almost) obvious patch to fix this.  At least the
amd64 libgnat-4.4.so builds now.

Rainer


-- 


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

[Bug ada/37681] [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error

[charlet at adacore dot com]

--- Comment #2 from charlet at adacore dot com  2008-09-30 15:06 ---
Subject: Re:  [4.4 regression] Building 64-bit libada fails
on Solaris/x86: alignment error

> > This happens only for the 64-bit libada, so it's probably due to missing
> > support for the 64-bit multilib.
> 
> Yes, it is, the hitch being that there is no port to x86_64/Solaris yet.

Note that there was supposed to be a way (--disable-multilibada or some such)
to easily disable this, so this should not be blocking.

Arno


-- 


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

[Bug ada/37681] [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error

[charlet at gcc dot gnu dot org]

--- Comment #4 from charlet at gcc dot gnu dot org  2008-09-30 15:06 ---
I'm assuming the proper --disable switch is either already there, if not,
probably worth opening another PR. Keeping this PR as an enhancement request
to add support for x86_64 solaris for Ada.


-- 

charlet at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |enhancement
   Target Milestone|4.4.0   |---


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

[Bug middle-end/37674] Bootstrap failure due to miscompilation of genattrtab

[krebbel at gcc dot gnu dot org]

-- 

krebbel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug ada/37681] [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error

[laurent at guerby dot net]

--- Comment #5 from laurent at guerby dot net  2008-09-30 15:15 ---
Adding Paolo as expert on configury. Rainer, let us know when you've tested
your patch (should be very close to what Eric Botcazou did for sparc-solaris).


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net,
   ||bonzini at gnu dot org


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

[Bug fortran/36592] F2003: Procedure pointer in COMMON

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2008-09-30 15:20 ---
Subject: Bug 36592

Author: burnus
Date: Tue Sep 30 15:19:25 2008
New Revision: 140790

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140790
Log:
2008-09-30  Janus Weil  <[EMAIL PROTECTED]>

PR fortran/36592
* symbol.c (check_conflict): If a symbol in a COMMON block is a
procedure, it must be a procedure pointer.
(gfc_add_in_common): Symbols in COMMON blocks may be variables or
procedure pointers.
* trans-types.c (gfc_sym_type): Make procedure pointers in
* COMMON
blocks work.


2008-09-30  Janus Weil  <[EMAIL PROTECTED]>

PR fortran/36592
* gfortran.dg/proc_ptr_common_1.f90: New.
* gfortran.dg/proc_ptr_common_2.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/proc_ptr_common_1.f90
trunk/gcc/testsuite/gfortran.dg/proc_ptr_common_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/symbol.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/36592] F2003: Procedure pointer in COMMON

[burnus at gcc dot gnu dot org]

--- Comment #6 from burnus at gcc dot gnu dot org  2008-09-30 15:22 ---
FIXED on the trunk (4.4).


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/37674] Bootstrap failure due to miscompilation of genattrtab

[krebbel at gcc dot gnu dot org]

--- Comment #1 from krebbel at gcc dot gnu dot org  2008-09-30 15:30 ---
The failure can currently be seen bootstrapping ira-merge branch (rev.:
140776).

configure --enable-shared --with-system-zlib --enable-threads=posix
--enable-__cxa_atexit --enable-checking --enable-decimal-float
--enable-languages=c


-- 


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

[Bug ada/37681] [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error

[bonzini at gnu dot org]

--- Comment #6 from bonzini at gnu dot org  2008-09-30 15:38 ---
No, there is not yet an extra configure switch for that, but I'll add it.  You
can create a PR and assign it to me.


-- 


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

[Bug target/36851] [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX

[ro at gcc dot gnu dot org]

--- Comment #9 from ro at gcc dot gnu dot org  2008-09-30 15:38 ---
Created an attachment (id=16433)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16433&action=view)
minimized testcase

This minimized version of strstream.ii shows the same bug.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #15992|0   |1
is obsolete||


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

[Bug libgomp/37586] OpenMP thinks that I have 1 processor on an 8 processor pc

[rrpeter at sandia dot gov]

--- Comment #6 from rrpeter at sandia dot gov  2008-09-30 15:54 ---
Subject: Re:  OpenMP thinks that I have 1 processor
 on an 8 processor pc

jakub at gcc dot gnu dot org wrote:
> --- Comment #5 from jakub at gcc dot gnu dot org  2008-09-20 08:22 ---
> No, I didn't mean to ask you to try to work around it, I asked you to
> investigate why omp_get_num_procs returns 1 instead of 8.  The gcc 4.3 vs. 4.4
> difference only affects omp_get_max_threads, not omp_get_num_procs, so even
> omp_get_num_procs reports 1, the options are 1) the process has affinity set 
> to
> just one CPU 2) GOMP_CPU_AFFINITY has been used 3) you have omp_get_num_procs
> defined elsewhere in your program, verify that libgomp function is really 
> used.
> strace -f -e sched_getaffinity dump of the program could reveal 1), 2) can be
> determined by looking at the scripts you use to start the program (or by 
> adding
> getenv call in the program to print that for you), 3) can be seen in the
> debugger and/or by using LD_DEBUG=all env var.
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37586
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>
>   
Hi Jakub,

I finally have a bit of time respond to your last email!

I may be new enough to this to be missing something important.  Why 
don't we start at the beginning?

I compiled everything with -fopenmp flag on the compiler (4.3.2 is the 
version for g++ and gcc)

*

Openmp code exists in only one place in my software.

[EMAIL PROTECTED] rwm]$ find . -name "*.*pp" -exec grep -n -H omp.h {} \;
./umbraModCDF/umbModCDFDataSet.cpp:237:#include 

[EMAIL PROTECTED] rwm]$ find . -name "*.*pp" -exec grep -n -H 
omp_get_num_procs {} \;
./umbraModCDF/umbModCDFDataSet.cpp:246:   cerr << " OPENMP is " << 
_OPENMP << "  Number of processors available:" << omp_get_num_procs() << 
" MAX number of OpenMP threads " << omp_get_max_threads() << endl;
[EMAIL PROTECTED] rwm]$

All of the OpenMP code that I have is in the following function

**
#include 

void test_openmp()
{  
   cerr << "\nEnter test_openmp() " << endl;

#ifdef _OPENMP
//omp_set_dynamic(true);
//omp_set_num_threads(8);
   cerr << " OPENMP is " << _OPENMP << "  Number of processors 
available:" << omp_get_num_procs() << " MAX number of OpenMP threads " 
<< omp_get_max_threads() << endl;
   char *GCU = getenv("GOMP_CPU_AFFINITY");
   if(GCU != NULL)
  cerr << " GOMP_CPU_AFFINITY is " << GCU << "\n"<< endl;
   else
  cerr << " GOMP_CPU_AFFINITY is unknown" << endl;

#endif

   cerr << "\nExit test_openmp()\n" << endl;
   cerr.flush();
}

***

Output snippet is:
Enter test_openmp()
 OPENMP is 200505  Number of processors available:1 MAX number of OpenMP 
threads 1
 GOMP_CPU_AFFINITY is unknown

Exit test_openmp()



I ran strace and I got some results.  In the output I see:
sched_getaffinity(3502, 128,  { ff, 0, 0, 0 }) = 32

 sched_getaffinity(3502, 128,  { 1, 0, 0, 0 }) = 32
...
sched_getaffinity(3502, 128,  { 1, 0, 0, 0 }) = 32

I will let you interpret  the output which is reproduce in full below.

[EMAIL PROTECTED] rwm]$ strace -f -e sched_getaffinity uview 
./viewer_scripts/viewer_CDF.tcl
Process 3503 attached (waiting for parent)
Process 3503 resumed (parent 3502 ready)
Process 3503 detached
--- SIGCHLD (Child exited) @ 0 (0) ---
provided packge "ucl" version 4.7.1
STATUS> Umbra installed at UmbraPath -> /home/hopper/UMBRA_4
STATUS> Use UmbraPath variable to refer to this location
STATUS> uview is using gui from developerViewer
STATUS> loading umbraConfig.tcl from uclLoad.tcl
STATUS> searching for umbra config files in path 
/home/hopper/UMBRA_4/umbra/SNL/rwm . /home/hopper/UMBRA_4
library r {umb {4.7.1 debug {Sep 29 2008} 13:08:47}} {usg {4.7.1 debug 
{Sep 29 2008} 13:08:56}} {ucl {4.7.1 debug {Sep 29 2008} 13:08:55}}
STATUS> loading ustk library from uclLoad.tcl

*-*
*  The C-Space Toolkit (C) software contained in this program is 
the  *
*  property of Sandia 
Corporation.*
*  Copyright 1995-2003 (C) Sandia Corporation.  All rights 
reserved.  *
* 
*
*  The C-Space Toolkit (``CSTk'') was developed at Sandia 
National*
*  Laboratories, which is operated by the Sandia Corporation under 
contract   *
*  for the United States Department of Energy.  The CSTk is is protected 
by   *
*  copyright under the laws of the United States.  CSTk software is not 
to*
*  be used, disclosed, or duplicated without explicit written 
authorization   *
*  from Sandia 
Corporation.   *
*-*

STATUS> loading gener

[Bug c++/37683] [4.4 Regression]: Revision 140780 caused g++.dg/warn/Wparentheses-3.C

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2008-09-30 16:10 ---
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01620.html

makes nested_if uninitialized for g++.dg/warn/Wparentheses-3.C:

--- gcc/cp/parser.c (revision 138452)
+++ gcc/cp/parser.c (working copy)
@@ -7120,7 +7120,17 @@ cp_parser_selection_statement (cp_parser
/* Parse the then-clause.  */
in_statement = parser->in_statement;
parser->in_statement |= IN_IF_STMT;
-   cp_parser_implicitly_scoped_statement (parser, &nested_if);
+   if (cp_lexer_next_token_is (parser->lexer, CPP_SEMICOLON))
+ {
+   location_t loc = cp_lexer_peek_token (parser->lexer)->location;
+   add_stmt (build_empty_stmt ());
+   cp_lexer_consume_token (parser->lexer);
+   if (!cp_lexer_next_token_is_keyword (parser->lexer, RID_ELSE))
+ warning (OPT_Wempty_body, "%Hsuggest braces around "
+  "empty body in an % statement", &loc);
+ }
+   else
+ cp_parser_implicitly_scoped_statement (parser, &nested_if);
parser->in_statement = in_statement;

I saw this bug on Linux/ia32 and Linux/ia64. This patch:

--- ./parser.c.foo  2008-09-30 08:41:24.0 -0700
+++ ./parser.c  2008-09-30 09:06:05.0 -0700
@@ -7163,6 +7163,7 @@ cp_parser_selection_statement (cp_parser
if (!cp_lexer_next_token_is_keyword (parser->lexer, RID_ELSE))
  warning_at (loc, OPT_Wempty_body, "suggest braces around "
  "empty body in an % statement");
+   nested_if = false;
  }
else
  cp_parser_implicitly_scoped_statement (parser, &nested_if);

works for me.


-- 


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

[Bug c++/37682] g++ internal error: verify_gimple failed

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-09-30 16:24 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[pinskia at gcc dot gnu dot org]

--- Comment #14 from pinskia at gcc dot gnu dot org  2008-09-30 16:24 
---
*** Bug 37682 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||holger dot hopp at sap dot
   ||com


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

[Bug middle-end/37669] [4.4 Regression] ice for legal code with -O2

[pinskia at gcc dot gnu dot org]

--- Comment #11 from pinskia at gcc dot gnu dot org  2008-09-30 16:26 
---
>Must be darwin specific then, can't reproduce on x86_64-linux

Has anyone tried bootstrapping on i686-linux-gnu with PIC enabled lately?  This
might show the same issue.


-- 


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

[Bug c/37684] New: [graphite] basic block containing VDEF of a scalar does not dominate basic block containing VUSE of the same scalar

[hjagasia at gcc dot gnu dot org]

When translate_clast is called for a scop, scalar definitions are optimized out
and hence any subsequent uses of those scalars, outside the scop, represents a
problem. Also as code is generated for a scop, basic blocks in the scop are
moved around such that the block which contains the definition of a scalar no
longer dominates the basic block outside the scop which contains a use of that
scalar.

Attached reduced testcase block-3.c (derived from cpu2006-401.bzip2-bzlib.c)
fails in gloog->verify_ssa->verify_use at below:
>>>
  else if (bb != def_bb
   && !dominated_by_p (CDI_DOMINATORS, bb, def_bb))
{
  error ("definition in block %i does not dominate use in block %i",
 def_bb->index, bb->index);
  err = true;
}
>>>
Before translate_clast is called, here is an excerpt from the function:
:
  # SMT.48_24 = PHI 
  # i_28 = PHI 
  # SMT.49_29 = PHI 
  # SMT.48_20 = VDEF 
  # SMT.49_21 = VDEF 
  s_5->inUse[i_28] = 0;
  i_10 = i_28 + 1;
  if (i_10 <= 255)
goto ;
  else
goto ;

:
  goto ;

:

:
  # VUSE 
  D.1656_11 = s_5->blockNo;
  D.1657_12 = D.1656_11 + 1;
  # SMT.48_22 = VDEF 
  # SMT.49_23 = VDEF 
  s_5->blockNo = D.1657_12;
  return;

At this point bb 3 which contains the VDEF for SMT.48_20 and SMT.49_21
dominates bb 6 which contains the VUSE for the same. The VDEF is associated
with s_5->blockNo and the VUSE with s_5->inUse[i_28].

After translate_clast is called, here is an excerpt from the function:
BZ2_bzCompressInit (struct bz_stream * strm, int blockSize100k, int verbosity,
int workFactor)
{
  struct EState * D.1728;
  int D.1725;
  int D.1726;
  int D.1727;
  int graphiteIV.63;
  int graphiteIV.62;
  Int32 pretmp.52;
  int D.1656;
  int D.1657;
  Int32 i;
  struct EState * s;
  void * D.1643;
  void * D.1642;
  void * (*) (void *, int, int) D.1641;

:
  # VUSE 
  D.1641_2 = strm_1(D)->bzalloc;
  # VUSE 
  D.1642_3 = strm_1(D)->opaque;
  # SMT.47_17 = VDEF 
  # SMT.48_18 = VDEF 
  # SMT.49_19 = VDEF 
  D.1643_4 = D.1641_2 (D.1642_3, 304, 1);
  s_5 = (struct EState *) D.1643_4;

:
  # graphiteIV.62_13 = PHI <0(2), graphiteIV.62_6(8)>
  graphiteIV.62_6 = graphiteIV.62_13 + 1;
  if (graphiteIV.62_6 <= 3)
goto ;
  else
goto ;

:
  graphiteIV.63_9 = graphiteIV.62_13 * 64;

:
  # graphiteIV.63_27 = PHI 
  # SMT.48_24 = PHI <>
  # SMT.49_29 = PHI <>
  graphiteIV.63_25 = graphiteIV.63_27 + 1;
  D.1725_26 = graphiteIV.62_13 * 64;
  D.1726_30 = D.1725_26 + 63;
  D.1727_31 = MIN_EXPR ;
  if (graphiteIV.63_25 <= D.1727_31)
goto ;
  else
goto ;

:
  goto ;

:
  goto ;

:
Invalid sum of outgoing probabilities 0.0%
Invalid sum of incoming frequencies 25, should be 9900
  D.1728_32 = (struct EState *) D.1643_4;
  D.1728_32->inUse[graphiteIV.63_27] = 0;
  goto ;

:
Invalid sum of incoming frequencies 0, should be 9800

:

:
  # VUSE 
  D.1656_11 = s_5->blockNo;
  D.1657_12 = D.1656_11 + 1;
  # SMT.48_22 = VDEF 
  # SMT.49_23 = VDEF 
  s_5->blockNo = D.1657_12;
  return;

}

During translate_clast the scop is transformed and the scalar VDEFS for
SMT.48_20, SMT.49_21 are removed by graphite. Also bb 3 no longer
dominates bb 6.


-- 
   Summary: [graphite] basic block containing VDEF of a scalar does
not dominate basic block containing VUSE of the same
scalar
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: hjagasia at gcc dot gnu dot org
ReportedBy: hjagasia at gcc dot gnu dot org
 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=37684

[Bug c/37684] [graphite] basic block containing VDEF of a scalar does not dominate basic block containing VUSE of the same scalar

[hjagasia at gcc dot gnu dot org]

--- Comment #1 from hjagasia at gcc dot gnu dot org  2008-09-30 16:34 
---
Created an attachment (id=16434)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16434&action=view)
Reduced test case derived from CPU2006 401.bzip2 benchmark


-- 


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

[Bug tree-optimization/37684] [graphite] basic block containing VDEF of a scalar does not dominate basic block containing VUSE of the same scalar

[hjagasia at gcc dot gnu dot org]

--- Comment #2 from hjagasia at gcc dot gnu dot org  2008-09-30 16:40 
---
Created an attachment (id=16435)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16435&action=view)
This patch fixes the reduced test case block-3.c

Until graphite can handle scalars and also update dominance properly (planned
for gcc 4.5), this patch will work by limiting the scop that contains bb 3,
which in turn contains the VDEFs for SMT.48_20, SMT.49_21, such that no code is
generated for it.

This patch depends on the patch submitted for 37485.


-- 


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

[Bug tree-optimization/37662] [4.4 Regression] ice: tree check: expected ssa_name, have integer_cst in get_value_range, at tree-vrp.c:612

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-09-30 17:02 ---
Subject: Bug 37662

Author: jakub
Date: Tue Sep 30 17:00:49 2008
New Revision: 140792

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140792
Log:
PR tree-optimization/37662
PR tree-optimization/37663
* tree-vrp.c (simplify_truth_ops_using_ranges): Don't call
get_value_range with non-SSA_NAME.  Don't assert operands have been
folded, instead just bail out.

* gcc.c-torture/compile/pr37662.c: New test.
* gcc.dg/pr37663.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr37662.c
trunk/gcc/testsuite/gcc.dg/pr37663.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c


-- 


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

[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 #2 from jakub at gcc dot gnu dot org  2008-09-30 17:02 ---
Subject: Bug 37663

Author: jakub
Date: Tue Sep 30 17:00:49 2008
New Revision: 140792

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140792
Log:
PR tree-optimization/37662
PR tree-optimization/37663
* tree-vrp.c (simplify_truth_ops_using_ranges): Don't call
get_value_range with non-SSA_NAME.  Don't assert operands have been
folded, instead just bail out.

* gcc.c-torture/compile/pr37662.c: New test.
* gcc.dg/pr37663.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr37662.c
trunk/gcc/testsuite/gcc.dg/pr37663.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c


-- 


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

[Bug tree-optimization/37662] [4.4 Regression] ice: tree check: expected ssa_name, have integer_cst in get_value_range, at tree-vrp.c:612

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-09-30 17:02 ---
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=37662

[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 #3 from jakub at gcc dot gnu dot org  2008-09-30 17:03 ---
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=37663

[Bug tree-optimization/37568] [4.4 regression] ICE returning a struct

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-09-30 17:19 ---
Testing it now.


-- 


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

[Bug c++/37685] New: C++ over-eager optimization when working with a pointer

[jrenggli at gmail dot com]

The following code results in an error when optimized using -O2 or -O3 flag,
but works fine with -O1. I've also been able to "confuse" the optimizer by
adding some code just after or before the line "iX += pA2->iX;" but I'm not
sure how safe that method is.

-- Full code starts here --

#include 

class A
{
  private:
int32_t iX;

  public:
explicit A(int x) : iX(x) {}

  public:
A& operator*=(const A& a);

  public:
int32_t getX() const { return iX; }
};



A& A::operator*=(const A& B)
{
  const A* pA2 = &B;

  int iBothSigns = 0;
  if (iX >= 0 && pA2->iX >= 0)
  {
iBothSigns = 1;
  }
  else if (iX < 0 && pA2->iX < 0)
  {
iBothSigns = -1;
  }

  iX += pA2->iX;

  if (iX >= 0 && iBothSigns == -1) // Expected
  {
std::cout << "OK" << std::endl;
return *this;
  }
  else if (iX < 0 && iBothSigns == 1) // Not expected
  {
std::cout << "Unexpected" << std::endl;
return *this;
  }
std::cout << "Error" << std::endl;

  return *this;
}



int main()
{
A n1(-2147483648);
A n2(-2147483648);

std::cout << "1: expected -2147483648, got " << n1.getX() << std::endl;
std::cout << "2: expected -2147483648, got " << n2.getX() << std::endl;
n1 *= n2;
std::cout << "3: expected previous line to be OK" << std::endl;
return 0;
}

-- end of code --

-- compiler output --

g++ -o bugreport.o -c -v -Wall -O3 -pedantic -ansi -save-temps bugreport.cpp
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --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
--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 (Ubuntu 4.2.3-2ubuntu7)
 /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -E -quiet -v -D_GNU_SOURCE
bugreport.cpp -mtune=generic -ansi -Wall -pedantic -O3 -fpch-preprocess -o
bugreport.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 bugreport.ii -quiet
-dumpbase bugreport.cpp -mtune=generic -ansi -auxbase-strip bugreport.o -O3
-Wall -pedantic -ansi -version -fstack-protector -fstack-protector -o
bugreport.s
GNU C++ version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) (i486-linux-gnu)
compiled by GNU C version 4.2.3 (Ubuntu 4.2.3-2ubuntu7).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129349
Compiler executable checksum: 9cf91ba46d80e564052e4fbab0d6561b
bugreport.cpp:55: warning: this decimal constant is unsigned only in ISO C90
bugreport.cpp:56: warning: this decimal constant is unsigned only in ISO C90
 as --traditional-format -V -Qy -o bugreport.o bugreport.s
GNU assembler version 2.18.0 (i486-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.18.0.20080103
g++ -o bugreport bugreport.o


-- 
   Summary: C++ over-eager optimization when working with a pointer
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jrenggli at gmail dot com


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

[Bug regression/37686] New: Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.

[luisgpm at linux dot vnet dot ibm dot com]

After this patch:

http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140660

Building bzip2 with peak flags AND -mcpu=power4 for ppc (-O3 -mcpu=power4
-ffast-math -funroll-loops -ftree-loop-linear -fpeel-loops) started ICE'ing.

Here is the backtrace:

#0  0x103a2c3c in gimple_bb (g=0x4) at
/home/luis/src/gcc/HEAD/gcc/gimple.h:1071
#1  0x103a2b80 in gsi_start (seq=0xf76882b0) at
/home/luis/src/gcc/HEAD/gcc/gimple.h:4298
#2  0x103a5a48 in gsi_start_phis (bb=0xf7664b40) at
/home/luis/src/gcc/HEAD/gcc/gimple-iterator.c:770
#3  0x105e601c in verify_stmts () at
/home/luis/src/gcc/HEAD/gcc/tree-cfg.c:4177
#4  0x107e80cc in verify_ssa (check_modified_stmt=1 '\001') at
/home/luis/src/gcc/HEAD/gcc/tree-ssa.c:750
#5  0x10476c30 in execute_function_todo (data=0x4043) at
/home/luis/src/gcc/HEAD/gcc/passes.c:999
#6  0x1047657c in do_per_function (callback=0x10476898 ,
data=0x4043) at /home/luis/src/gcc/HEAD/gcc/passes.c:841
#7  0x10476d38 in execute_todo (flags=16451) at
/home/luis/src/gcc/HEAD/gcc/passes.c:1025
#8  0x10477c54 in execute_one_pass (pass=0x10eeabd4) at
/home/luis/src/gcc/HEAD/gcc/passes.c:1301
#9  0x10477ec4 in execute_pass_list (pass=0x10eeabd4) at
/home/luis/src/gcc/HEAD/gcc/passes.c:1327
#10 0x10477ef0 in execute_pass_list (pass=0x10eeaa9c) at
/home/luis/src/gcc/HEAD/gcc/passes.c:1328
#11 0x10477ef0 in execute_pass_list (pass=0x10eea494) at
/home/luis/src/gcc/HEAD/gcc/passes.c:1328
#12 0x106656a8 in tree_rest_of_compilation (fndecl=0xf7e74180) at
/home/luis/src/gcc/HEAD/gcc/tree-optimize.c:418
#13 0x10930d78 in cgraph_expand_function (node=0xf7e78300) at
/home/luis/src/gcc/HEAD/gcc/cgraphunit.c:1038
#14 0x10930fe0 in cgraph_expand_all_functions () at
/home/luis/src/gcc/HEAD/gcc/cgraphunit.c:1097
#15 0x109317a8 in cgraph_optimize () at
/home/luis/src/gcc/HEAD/gcc/cgraphunit.c:1302
#16 0x10033998 in c_write_global_declarations () at
/home/luis/src/gcc/HEAD/gcc/c-decl.c:8073
#17 0x105c9624 in compile_file () at /home/luis/src/gcc/HEAD/gcc/toplev.c:979
#18 0x105cc214 in do_compile () at /home/luis/src/gcc/HEAD/gcc/toplev.c:2190
#19 0x105cc2a8 in toplev_main (argc=30, argv=0xff880e44) at
/home/luis/src/gcc/HEAD/gcc/toplev.c:
#20 0x100f90fc in main (argc=30, argv=0xff880e44) at
/home/luis/src/gcc/HEAD/gcc/main.c:35

The failing line is "return g->gsbase.bb;", because "g" isn't really a valid
pointer:

(gdb) p g
$1 = (const_gimple) 0x4


-- 
   Summary: Building of CPU2000's bzip2 with peak flags with -
mcpu=power4 fails with an ICE.
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: luisgpm at linux dot vnet dot ibm dot com
 GCC build triplet: powerpc*-*-*
  GCC host triplet: powerpc*-*-*
GCC target triplet: powerpc*-*-*


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

[Bug libfortran/37687] New: error: Link tests are not allowed after GCC_NO_EXECUTABLES while checking for symbol versioning support

[aldot at gcc dot gnu dot org]

checking whether symbol versioning is supported... configure: error: Link tests
are not allowed after GCC_NO_EXECUTABLES.
make[2]: *** [configure-target-libgfortran] Error 1

This affects both libgfortran and libssp.
Seen with:
gcc version 4.4.0 20080930 (experimental) [trunk revision 140790] (GCC)


-- 
   Summary: error: Link tests are not allowed after
GCC_NO_EXECUTABLES while checking for symbol versioning
support
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
 GCC build triplet: i386-pc-linux-gnu
  GCC host triplet: i386-pc-linux-gnu
GCC target triplet: powerpc-linux-uclibc


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

[Bug other/37463] [4.4 regression] All Solaris/x86 eh tests fail

[ro at techfak dot uni-bielefeld dot de]

--- Comment #3 from ro at techfak dot uni-bielefeld dot de  2008-09-30 
18:09 ---
Subject: Re:  [4.4 regression] All Solaris/x86 eh tests fail

I've done some further debugging: contrary to what gdb suggested, the
reason for the abort is the gcc_assert call in unwind-dw2.c
(uw_init_context_1):

  code = uw_frame_state_for (context, &fs);
  gcc_assert (code == _URC_NO_REASON);

Single-stepping at the assembler level, I find that code is
_URC_END_OF_STACK, i.e. _Unwind_Find_FDE () in uw_frame_state_for ()
returned NULL.

Since this code is such a maze, I'm hard pressed to further debug this, so
any guidance is appreciated.

Rainer


-- 


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

Re: [Bug c++/37685] New: C++ over-eager optimization when working with a pointer

[Andrew Thomas Pinski]

Sent from my iPhone

On Sep 30, 2008, at 10:26 AM, "jrenggli at gmail dot com" <[EMAIL PROTECTED] 
> wrote:


The following code results in an error when optimized using -O2 or - 
O3 flag,
but works fine with -O1. I've also been able to "confuse" the  
optimizer by
adding some code just after or before the line "iX += pA2->iX;" but  
I'm not

sure how safe that method is.

-- Full code starts here --

#include 

class A
{
 private:
   int32_t iX;

 public:
   explicit A(int x) : iX(x) {}

 public:
   A& operator*=(const A& a);

 public:
   int32_t getX() const { return iX; }
};



A& A::operator*=(const A& B)
{
 const A* pA2 = &B;

 int iBothSigns = 0;
 if (iX >= 0 && pA2->iX >= 0)
 {
   iBothSigns = 1;
 }
 else if (iX < 0 && pA2->iX < 0)
 {
   iBothSigns = -1;
 }

 iX += pA2->iX;

 if (iX >= 0 && iBothSigns == -1) // Expected



Signed interger overflow is undefined.





 {
   std::cout << "OK" << std::endl;
   return *this;
 }
 else if (iX < 0 && iBothSigns == 1) // Not expected
 {
   std::cout << "Unexpected" << std::endl;
   return *this;
 }
   std::cout << "Error" << std::endl;

 return *this;
}



int main()
{
   A n1(-2147483648);
   A n2(-2147483648);

   std::cout << "1: expected -2147483648, got " << n1.getX() <<  
std::endl;
   std::cout << "2: expected -2147483648, got " << n2.getX() <<  
std::endl;

   n1 *= n2;
   std::cout << "3: expected previous line to be OK" << std::endl;
   return 0;
}

-- end of code --

-- compiler output --

g++ -o bugreport.o -c -v -Wall -O3 -pedantic -ansi -save-temps  
bugreport.cpp

Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --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

--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 (Ubuntu 4.2.3-2ubuntu7)
/usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -E -quiet -v -D_GNU_SOURCE
bugreport.cpp -mtune=generic -ansi -Wall -pedantic -O3 -fpch- 
preprocess -o

bugreport.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  
bugreport.ii -quiet
-dumpbase bugreport.cpp -mtune=generic -ansi -auxbase-strip  
bugreport.o -O3

-Wall -pedantic -ansi -version -fstack-protector -fstack-protector -o
bugreport.s
GNU C++ version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) (i486-linux-gnu)
   compiled by GNU C version 4.2.3 (Ubuntu 4.2.3-2ubuntu7).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min- 
heapsize=129349

Compiler executable checksum: 9cf91ba46d80e564052e4fbab0d6561b
bugreport.cpp:55: warning: this decimal constant is unsigned only in  
ISO C90
bugreport.cpp:56: warning: this decimal constant is unsigned only in  
ISO C90

as --traditional-format -V -Qy -o bugreport.o bugreport.s
GNU assembler version 2.18.0 (i486-linux-gnu) using BFD version (GNU  
Binutils

for Ubuntu) 2.18.0.20080103
g++ -o bugreport bugreport.o


--
  Summary: C++ over-eager optimization when working with a  
pointer

  Product: gcc
  Version: 4.2.3
   Status: UNCONFIRMED
 Severity: normal
 Priority: P3
Component: c++
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: jrenggli at gmail dot com


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

[Bug c++/37685] C++ over-eager optimization when working with a pointer

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2008-09-30 18:11 ---
Subject: Re:   New: C++ over-eager optimization when working with a pointer



Sent from my iPhone

On Sep 30, 2008, at 10:26 AM, "jrenggli at gmail dot com"
<[EMAIL PROTECTED] 
 > wrote:

> The following code results in an error when optimized using -O2 or - 
> O3 flag,
> but works fine with -O1. I've also been able to "confuse" the  
> optimizer by
> adding some code just after or before the line "iX += pA2->iX;" but  
> I'm not
> sure how safe that method is.
>
> -- Full code starts here --
>
> #include 
>
> class A
> {
>  private:
>int32_t iX;
>
>  public:
>explicit A(int x) : iX(x) {}
>
>  public:
>A& operator*=(const A& a);
>
>  public:
>int32_t getX() const { return iX; }
> };
>
> 
>
> A& A::operator*=(const A& B)
> {
>  const A* pA2 = &B;
>
>  int iBothSigns = 0;
>  if (iX >= 0 && pA2->iX >= 0)
>  {
>iBothSigns = 1;
>  }
>  else if (iX < 0 && pA2->iX < 0)
>  {
>iBothSigns = -1;
>  }
>
>  iX += pA2->iX;
>
>  if (iX >= 0 && iBothSigns == -1) // Expected


Signed interger overflow is undefined.



>
>  {
>std::cout << "OK" << std::endl;
>return *this;
>  }
>  else if (iX < 0 && iBothSigns == 1) // Not expected
>  {
>std::cout << "Unexpected" << std::endl;
>return *this;
>  }
>std::cout << "Error" << std::endl;
>
>  return *this;
> }
>
> 
>
> int main()
> {
>A n1(-2147483648);
>A n2(-2147483648);
>
>std::cout << "1: expected -2147483648, got " << n1.getX() <<  
> std::endl;
>std::cout << "2: expected -2147483648, got " << n2.getX() <<  
> std::endl;
>n1 *= n2;
>std::cout << "3: expected previous line to be OK" << std::endl;
>return 0;
> }
>
> -- end of code --
>
> -- compiler output --
>
> g++ -o bugreport.o -c -v -Wall -O3 -pedantic -ansi -save-temps  
> bugreport.cpp
> Using built-in specs.
> Target: i486-linux-gnu
> Configured with: ../src/configure -v
> --enable-languages=c,c++,fortran,objc,obj-c++,treelang --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
> --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 (Ubuntu 4.2.3-2ubuntu7)
> /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -E -quiet -v -D_GNU_SOURCE
> bugreport.cpp -mtune=generic -ansi -Wall -pedantic -O3 -fpch- 
> preprocess -o
> bugreport.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  
> bugreport.ii -quiet
> -dumpbase bugreport.cpp -mtune=generic -ansi -auxbase-strip  
> bugreport.o -O3
> -Wall -pedantic -ansi -version -fstack-protector -fstack-protector -o
> bugreport.s
> GNU C++ version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) (i486-linux-gnu)
>compiled by GNU C version 4.2.3 (Ubuntu 4.2.3-2ubuntu7).
> GGC heuristics: --param ggc-min-expand=99 --param ggc-min- 
> heapsize=129349
> Compiler executable checksum: 9cf91ba46d80e564052e4fbab0d6561b
> bugreport.cpp:55: warning: this decimal constant is unsigned only in  
> ISO C90
> bugreport.cpp:56: warning: this decimal constant is unsigned only in  
> ISO C90
> as --traditional-format -V -Qy -o bugreport.o bugreport.s
> GNU assembler version 2.18.0 (i486-linux-gnu) using BFD version (GNU  
> Binutils
> for Ubuntu) 2.18.0.20080103
> g++ -o bugreport bugreport.o
>
>
> -- 
>   Summary: C++ over-eager optimization when working with a  
> pointer
>   Product: gcc
>   Version: 4.2.3
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: c++
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: jrenggli at gmail dot com
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37685
>


-- 


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

[Bug c++/37685] C++ over-eager optimization when working with a pointer

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2008-09-30 18:13 
---
Indeed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug other/37463] [4.4 regression] All Solaris/x86 eh tests fail

[ebotcazou at gcc dot gnu dot org]

--- Comment #4 from ebotcazou at gcc dot gnu dot org  2008-09-30 18:18 
---
Yep, same on SPARC.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-09-30 18:18:17
   date||


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

[Bug other/37463] [4.4 regression] All Solaris/x86 eh tests fail

[ebotcazou at gcc dot gnu dot org]

--- Comment #5 from ebotcazou at gcc dot gnu dot org  2008-09-30 18:19 
---
See http://sourceware.org/ml/binutils/2008-09/msg00195.html
Now someone needs to write a configure test for the compiler.


-- 


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

[Bug c++/37685] C++ over-eager optimization when working with a pointer

[jrenggli at gmail dot com]

--- Comment #3 from jrenggli at gmail dot com  2008-09-30 18:39 ---
Sorry about that, now that you say it it makes so much sense! I feel a bit
silly, but at least I learned something :)


-- 


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

[Bug fortran/37688] New: Relax "Symbol is used before it is typed" checking

[burnus at gcc dot gnu dot org]

This is mostly encountered for bounds of automatic arrays. The following is
invalid, but accepted by most compilers:

subroutine foo(x,n)
  implicit none
  real:: x(n)
  integer :: n

It is also accepted by gfortran (unless -std=f2008 etc. is used). However,
currently gfortran (since 4.4 / since PR 32095 / PR 34228) unconditionally
rejects code of the kind:

subroutine foo(x,n)
  implicit none
  real:: x(n+1) ! expression:  "variable + constant"
  integer :: n

with the message "Symbol '%s' is used before it is typed at %L". While this is
useful to prevent circular usage (cf. PR 32095) simple EXPR_OP as above, esp.
those which only involve +-*/ could be allowed. (They occure in real-world
code.)


-- 
   Summary: Relax "Symbol is used before it is typed" checking
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  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=37688

[Bug libfortran/37687] error: Link tests are not allowed after GCC_NO_EXECUTABLES while checking for symbol versioning support

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-09-30 18:49 ---
Mark as duplicate of PR 37634.

That libgfortran does not work with GCC_NO_EXECUTABLES is a known, but unfixed
problem. See PR 37634. If you have some time, you could try whether the
suggested fixes there are enough. In any case I would like to see a patch -
thus if you have time ...

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


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/37634] Fix libgfortran compiling to support GCC_NO_EXECUTABLES

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-09-30 18:49 ---
*** Bug 37687 has been marked as a duplicate of this bug. ***


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu dot org


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

[Bug fortran/37688] Relax "Symbol is used before it is typed" checking

[domob at gcc dot gnu dot org]

--- Comment #1 from domob at gcc dot gnu dot org  2008-09-30 18:49 ---
Confirmed.  I'll work this out.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||domob at gcc dot gnu dot org
 AssignedTo|unassigned at gcc dot gnu   |domob at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-09-30 18:49:20
   date||


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

[Bug tree-optimization/37662] [4.4 Regression] ice: tree check: expected ssa_name, have integer_cst in get_value_range, at tree-vrp.c:612

[bonzini at gnu dot org]

--- Comment #6 from bonzini at gnu dot org  2008-09-30 19:06 ---
Are you going to commit my tree-ssa-propagate.c patch separately, or should I
wait for 4.5?


-- 


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

[Bug other/37463] [4.4 regression] All Solaris/x86 eh tests fail

[ro at techfak dot uni-bielefeld dot de]

--- Comment #6 from ro at techfak dot uni-bielefeld dot de  2008-09-30 
19:22 ---
Subject: Re:  [4.4 regression] All Solaris/x86 eh tests fail

ebotcazou at gcc dot gnu dot org writes:

> See http://sourceware.org/ml/binutils/2008-09/msg00195.html

Thanks for the info.

> Now someone needs to write a configure test for the compiler.

I'm a bit unsure how to test this right now: what I find is that C objects
have read-only .eh_frame sections and use .cfi* directives, while C++, Java
and Ada objects have read-write .eh_frame sections and still use .eh_frame
sections directly emitted by the compiler.

Rainer


-- 


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

[Bug c++/37556] [4.4 regression] ICE with invalid typedef

[simartin at gcc dot gnu dot org]

--- Comment #4 from simartin at gcc dot gnu dot org  2008-09-30 19:27 
---
Subject: Bug 37556

Author: simartin
Date: Tue Sep 30 19:25:35 2008
New Revision: 140794

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140794
Log:
gcc/cp/

2008-09-30  Simon Martin  <[EMAIL PROTECTED]>

PR c++/37555
PR c++/37556
* decl.c (grokdeclarator): Set the type for typedefs to a
nested-name-specifier to error_mark_node.

gcc/testsuite/

2008-09-30  Simon Martin  <[EMAIL PROTECTED]>

PR c++/37555
* g++.dg/parse/error32.C: New test.

PR c++/37556
* g++.dg/parse/error33.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/parse/error32.C
trunk/gcc/testsuite/g++.dg/parse/error33.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/37555] [4.2/4.3/4.4 regression] ICE with invalid typedef

[simartin at gcc dot gnu dot org]

--- Comment #3 from simartin at gcc dot gnu dot org  2008-09-30 19:27 
---
Subject: Bug 37555

Author: simartin
Date: Tue Sep 30 19:25:35 2008
New Revision: 140794

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140794
Log:
gcc/cp/

2008-09-30  Simon Martin  <[EMAIL PROTECTED]>

PR c++/37555
PR c++/37556
* decl.c (grokdeclarator): Set the type for typedefs to a
nested-name-specifier to error_mark_node.

gcc/testsuite/

2008-09-30  Simon Martin  <[EMAIL PROTECTED]>

PR c++/37555
* g++.dg/parse/error32.C: New test.

PR c++/37556
* g++.dg/parse/error33.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/parse/error32.C
trunk/gcc/testsuite/g++.dg/parse/error33.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c/37689] New: [4.4 Regression] ICE compiling newlib

[joel at gcc dot gnu dot org]

/home/joel/work-gnat/svn/m32c-work/b-gcc/./gcc/xgcc
-B/home/joel/work-gnat/svn/m32c-work/b-gcc/./gcc/ -nostdinc
-B/home/joel/work-gnat/svn/m32c-work/b-gcc/m32c-elf/m32cm/newlib/ -isystem
/home/joel/work-gnat/svn/m32c-work/b-gcc/m32c-elf/m32cm/newlib/targ-include
-isystem /home/joel/work-gnat/svn/gcc/newlib/libc/include
-B/home/joel/work-gnat/svn/m32c-install/m32c-elf/bin/
-B/home/joel/work-gnat/svn/m32c-install/m32c-elf/lib/ -isystem
/home/joel/work-gnat/svn/m32c-install/m32c-elf/include -isystem
/home/joel/work-gnat/svn/m32c-install/m32c-elf/sys-include  -mcpu=m32cm
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"1.16.0\" -DPACKAGE_STRING=\"newlib\ 1.16.0\"
-DPACKAGE_BUGREPORT=\"\" -I. -I../../../../../../../gcc/newlib/libm/math
-I../../../../../../../gcc/newlib/libm/math/../common -Os
-DPREFER_SIZE_OVER_SPEED -DABORT_PROVIDED -DSMALL_MEMORY
-DMISSING_SYSCALL_NAMES -fno-builtin  -g -O2-mcpu=m32cm -c -o
lib_a-ef_atan2.o `test -f 'ef_atan2.c' || echo
'../../../../../../../gcc/newlib/libm/math/'`ef_atan2.c
../../../../../../../gcc/newlib/libm/math/ef_atan2.c: In function
‘__ieee754_atan2f’:
../../../../../../../gcc/newlib/libm/math/ef_atan2.c:101: internal compiler
error: in purge_dead_edges, at cfgrtl.c:2327
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.4 Regression] ICE compiling newlib
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: m32c-elf


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

[Bug c/37689] [4.4 Regression] ICE compiling newlib

[joel at gcc dot gnu dot org]

--- Comment #1 from joel at gcc dot gnu dot org  2008-09-30 19:32 ---
Created an attachment (id=16436)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16436&action=view)
preprocessed code

 /home/joel/work-gnat/svn/m32c-work/b-gcc/./gcc/xgcc
-B/home/joel/work-gnat/svn/m32c-work/b-gcc/./gcc/ -Os -c j.c

Fails at -O2
Compiles at --O0


-- 


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

[Bug other/37463] [4.4 regression] All Solaris/x86 eh tests fail

[ebotcazou at gcc dot gnu dot org]

--- Comment #7 from ebotcazou at gcc dot gnu dot org  2008-09-30 19:41 
---
> I'm a bit unsure how to test this right now: what I find is that C objects
> have read-only .eh_frame sections and use .cfi* directives, while C++, Java
> and Ada objects have read-write .eh_frame sections and still use .eh_frame
> sections directly emitted by the compiler.

I think that we should assemble some C code with CFI directives and see whether
the resulting .eh_frame is read-only; if so, HAVE_GAS_CFI_DIRECTIVE must be set
to 0 instead of 1.  This should discriminate between 2.18 and upcoming 2.19.

That the non-C compilers still emit .eh_frame directly is unexpected I'd think.


-- 


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

[Bug c++/37555] [4.2/4.3/4.4 regression] ICE with invalid typedef

[simartin at gcc dot gnu dot org]

--- Comment #4 from simartin at gcc dot gnu dot org  2008-09-30 19:57 
---
Subject: Bug 37555

Author: simartin
Date: Tue Sep 30 19:56:13 2008
New Revision: 140796

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140796
Log:
gcc/cp/

2008-09-30  Simon Martin  <[EMAIL PROTECTED]>

PR c++/37555
* decl.c (grokdeclarator): Set the type for typedefs to a
nested-name-specifier to error_mark_node.

gcc/testsuite/

2008-09-30  Simon Martin  <[EMAIL PROTECTED]>

PR c++/37555
* g++.dg/parse/error32.C: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/parse/error32.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/decl.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/37556] [4.4 regression] ICE with invalid typedef

[simartin at gcc dot gnu dot org]

--- Comment #5 from simartin at gcc dot gnu dot org  2008-09-30 19:59 
---
Fixed


-- 

simartin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/30680] Spurious "might be used uninitialized" warning in STL use.

[pdemarco at ppg dot com]

--- Comment #3 from pdemarco at ppg dot com  2008-09-30 20:00 ---
(In reply to comment #2)
> maybe the same bug to 22207?

yeah, probably the same as bug 22207, but that one is only fixed on 4.0.0

We need a fix on 3.x.x


-- 

pdemarco at ppg dot com changed:

   What|Removed |Added

 CC||pdemarco at ppg dot com


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

[Bug c++/37555] [4.2 regression] ICE with invalid typedef

[simartin at gcc dot gnu dot org]

--- Comment #5 from simartin at gcc dot gnu dot org  2008-09-30 20:01 
---
Fixed in 4.3.3 and 4.4.0.


-- 

simartin at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.4.0 4.0.0 |4.0.0
  Known to work||4.3.3 4.4.0
Summary|[4.2/4.3/4.4 regression] ICE|[4.2 regression] ICE with
   |with invalid typedef|invalid typedef


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

[Bug tree-optimization/37568] [4.4 regression] ICE returning a struct

[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-
   ||09/msg01994.html
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-09-30 20:22:20
   date||


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

[Bug c/35434] [4.2/4.3/4.4 regression] ICE with attribute alias

[reichelt at gcc dot gnu dot org]

--- Comment #2 from reichelt at gcc dot gnu dot org  2008-09-30 21:33 
---
The second (weakref) case has been fixed on mainline and the 4.3 branch
by the patch for PR37645. The attribute is ignored and the code compiled:

bug.c:1: warning: 'weakref' attribute ignored

The first (alias) case still crashes, though.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.2/4.3/4.4 regression] ICE|[4.2/4.3/4.4 regression] ICE
   |with attribute alias/weakref|with attribute alias


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

[Bug ada/37681] [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error

[ro at techfak dot uni-bielefeld dot de]

--- Comment #7 from ro at techfak dot uni-bielefeld dot de  2008-09-30 
21:37 ---
Subject: Re:  [4.4 regression] Building 64-bit libada fails on Solaris/x86:
alignment error

Patch here:

http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01990.html


-- 


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

[Bug c++/32385] [4.2/4.3/4.4 regression] ICE with struct in default argument of template function

[reichelt at gcc dot gnu dot org]

--- Comment #3 from reichelt at gcc dot gnu dot org  2008-09-30 21:44 
---
With the patch for PR37649 the testcase doesn't ICE on mainline anymore.
According to Paolo's comment, this is still rejects-valid, though.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords|error-recovery, ice-on- |ice-on-valid-code, rejects-
   |invalid-code|valid


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

[Bug tree-optimization/35011] [4.3 regression] ICE with -fcheck-data-deps

[reichelt at gcc dot gnu dot org]

--- Comment #6 from reichelt at gcc dot gnu dot org  2008-09-30 21:55 
---
Seems as if this one got fixed on mainline with the tuples merge.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.3/4.4 regression] ICE|[4.3 regression] ICE with -
   |with -fcheck-data-deps  |fcheck-data-deps


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

[Bug tree-optimization/35737] [4.2/4.3/4.4 regression] ICE with __builtin_setjmp and complex variable

[rth at gcc dot gnu dot org]

-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-03-30 00:24:46 |2008-09-30 22:44:29
   date||


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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[dannysmith at users dot sourceforge dot net]

--- Comment #26 from dannysmith at users dot sourceforge dot net  
2008-10-01 01:33 ---
(In reply to comment #14)
> Hi Guys,
> 
>   I am not able to reproduce the build problems that were reported with the
> first version of my patch, but then again I do not have a native cygwin build
> system or a system in which I can bootstrap mingw32.  I think that Brian may
> well be right however in that the patch is behaving badly when it manually
> switches into the .bss section.  I have uploaded a revised version of the 
> patch
> which uses the correct gcc function to perform the section switch, so please
> can anyone who is interested give this new patch a run.


This latter patch, applied to R139853 [*] (just before the big IRA merge) does
not cause the build problems of the prior patch but does not solve the problem
either.

With this patch, using your _align.c test case which I uploaded in previous
comment:

gcc -DHAVE_ALIGNED_COMMON _align.c  && a.exe
fails.

The assembler code, specifically the .balign 32 directive applied to the
_common object looks like it should do the right thing, but doesn't (:

.file   "_align.c"
.bss
.balign 1
.comm   _a, 1
.balign 32
.comm   _common, 64
.globl _b
.section.bss,"w"
_b:
.space 1
.globl _bss
.align 32
_bss:
.space 64
.globl _c
.data
_c:
.byte   1
.globl _data
.align 32
_data:
.long   1
.space 4
.long   2
.space 4
.long   3
.space 12
.long   4
.space 28
.text
.globl _test
.def_test;  .scl2;  .type   32; .endef
_test:
pushl   %ebp
movl%esp, %ebp
subl$8, %esp
movl8(%ebp), %eax
addl$8, %eax
andl$7, %eax
testl   %eax, %eax
jne L2
movl8(%ebp), %eax
addl$16, %eax
andl$15, %eax
testl   %eax, %eax
jne L2
movl8(%ebp), %eax
addl$32, %eax
andl$31, %eax
testl   %eax, %eax
je  L4
L2:
call_abort
L4:
leave
ret
.def___main;.scl2;  .type   32; .endef
.globl _main
.def_main;  .scl2;  .type   32; .endef
_main:
pushl   %ebp
movl%esp, %ebp
andl$-16, %esp
subl$16, %esp
call___main
movl$_common, (%esp)
call_test
movl$_bss, (%esp)
call_test
movl$_data, (%esp)
call_test
movl$0, (%esp)
call_exit
.def_abort; .scl2;  .type   32; .endef
.def_exit;  .scl2;  .type   32; .endef




[*] Since the IRA merge, mingw32  has been broken, failing to compile libstdc++
and raising many (>500 in gcc.dg) new testcase errors.  


-- 


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