[Bug other/52663] ICE: in purge_dead_edges, at cfgrtl.c:2462

[dcb314 at hotmail dot com]

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

--- Comment #2 from dcb  2012-03-31 08:23:56 UTC ---

I also see the problem on x86_64-unknown-linux-gnu

[Bug target/52607] v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}

[marc.glisse at normalesup dot org]

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

--- Comment #25 from Marc Glisse  2012-03-31 
09:37:51 UTC ---
The test for AVX2 in expand_vec_perm_interleave2 might be too strict. For the
V4DF shuffle 4,0,2,6, removing that check lets the compiler generate a nice
vunpcklpd+vpermilpd (as opposed to 3 insn with my patch and 5+ without). The
expansion of dfinal is already protected (so the function returns false for
4,2,0,6), I haven't checked whether something else (dremap?) needs protecting,
but it doesn't look like it.

[Bug rtl-optimization/52803] New: [4.8 Regression] ICE: in ira, at ira.c:3616 with -fno-move-loop-invariants on almost any code

[zsojka at seznam dot cz]

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

 Bug #: 52803
   Summary: [4.8 Regression] ICE: in ira, at ira.c:3616 with
-fno-move-loop-invariants on almost any code
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


= testcase.c =
void foo (void) {}
==

Compiler output:
$ gcc -O -fno-move-loop-invariants testcase.c
testcase.c: In function 'foo':
testcase.c:1:1: internal compiler error: in ira, at ira.c:3616
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r186030 - crash
r185937 - crash
4.7 r185191 - OK

[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

--- Comment #9 from Andreas Schwab  2012-03-31 10:14:00 
UTC ---
*** Bug 52663 has been marked as a duplicate of this bug. ***

[Bug other/52663] ICE: in purge_dead_edges, at cfgrtl.c:2462

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Andreas Schwab  2012-03-31 10:14:00 
UTC ---
.

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

[Bug target/52804] New: IRA/RELOAD allocate wrong register on ARM for cortex-m0

[amker.cheng at gmail dot com]

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

 Bug #: 52804
   Summary: IRA/RELOAD allocate wrong register on ARM for
cortex-m0
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amker.ch...@gmail.com


For following code code:
void foo(unsigned char ** i, char *** o,
 unsigned int row, int num);
extern signed long tab[];
extern unsigned int w;
void foo(unsigned char ** i, char *** o,
 unsigned int row, int num)
{
  register int r, g, b;
  register signed long * t = tab;
  register char * pi;
  register char * o0;
  register char * o1;
  register unsigned int c;
  unsigned int n = w;

  while (--num >= 0) {
pi = *i++;
o0 = o[0][row];
o1 = o[1][row];
row++;
for (c = 0; c < n; c++) {
  r = ((int) (pi[0]));
  g = ((int) (pi[1]));
  b = ((int) (pi[2]));
  pi += 3;

  o0[c] = (unsigned char)
((t[r] + t[g] + t[b]));
  o1[c] = (unsigned char)
((t[r] + t[g] + t[b]));
}
  }
}
Compile it with following command:
$ arm-none-eabi-gcc -S -mthumb -mcpu=cortex-m0 -O2 -o foo.S foo.c

comparing ira/reload dump as following:
/*
dump of ira:

(insn 82 81 83 3 (set (reg/f:SI 281 [ *o_15(D) ])
(mem/f:SI (reg/v/f:SI 315 [orig:275 o ] [275]) [2 *o_15(D)+0 S4 A32]))
./gccmpsm0/obj_lite/cjpeg/jccolor-case.E:18 186 {*thumb1_movsi_insn}
 (expr_list:REG_EQUIV (mem/f:SI (reg/v/f:SI 315 [orig:275 o ] [275]) [2
*o_15(D)+0 S4 A32])
(nil)))

(insn 83 82 84 3 (set (reg/v/f:SI 198 [ o0 ])
(mem/f:SI (plus:SI (reg/f:SI 281 [ *o_15(D) ])
(reg:SI 273 [ D.4183 ])) [2 *D.4088_18+0 S4 A32]))
./gccmpsm0/obj_lite/cjpeg/jccolor-case.E:18 186 {*thumb1_movsi_insn}
 (expr_list:REG_DEAD (reg/f:SI 281 [ *o_15(D) ])
(nil)))

(insn 84 83 85 3 (set (reg/f:SI 282 [ MEM[(char * * *)o_15(D) + 4B] ])
(mem/f:SI (plus:SI (reg/v/f:SI 315 [orig:275 o ] [275])
(const_int 4 [0x4])) [2 MEM[(char * * *)o_15(D) + 4B]+0 S4
A32])) ./gccmpsm0/obj_lite/cjpeg/jccolor-case.E:19 186 {*thumb1_movsi_insn}
 (expr_list:REG_EQUIV (mem/f:SI (plus:SI (reg/v/f:SI 315 [orig:275 o ]
[275])
(const_int 4 [0x4])) [2 MEM[(char * * *)o_15(D) + 4B]+0 S4
A32])
(nil)))

(insn 85 84 171 3 (set (reg/v/f:SI 201 [ o1 ])
(mem/f:SI (plus:SI (reg/f:SI 282 [ MEM[(char * * *)o_15(D) + 4B] ])
(reg:SI 273 [ D.4183 ])) [2 *D.4091_23+0 S4 A32]))
./gccmpsm0/obj_lite/cjpeg/jccolor-case.E:19 186 {*thumb1_movsi_insn}
 (expr_list:REG_DEAD (reg/f:SI 282 [ MEM[(char * * *)o_15(D) + 4B] ])
(expr_list:REG_DEAD (reg:SI 273 [ D.4183 ])
(nil


dump of reload:

(note 82 81 207 3 NOTE_INSN_DELETED)

(insn 207 82 208 3 (set (reg:SI 6 r6)
(reg/v/f:SI 9 r9 [orig:275 o ] [275]))
./gccmpsm0/obj_lite/cjpeg/jccolor-case.E:18 186 {*thumb1_movsi_insn}
 (nil))

(insn 208 207 209 3 (set (reg:SI 6 r6)
(mem/f:SI (reg:SI 6 r6) [2 *o_15(D)+0 S4 A32]))
./gccmpsm0/obj_lite/cjpeg/jccolor-case.E:18 186 {*thumb1_movsi_insn}
 (nil))

(insn 209 208 210 3 (set (reg:SI 7 r7)
(mem/f:SI (plus:SI (reg:SI 6 r6)
(reg:SI 3 r3 [orig:273 D.4183 ] [273])) [2 *D.4088_18+0 S4
A32])) ./gccmpsm0/obj_lite/cjpeg/jccolor-case.E:18 186 {*thumb1_movsi_insn}
 (nil))

(insn 210 209 84 3 (set (reg/v/f:SI 12 ip [orig:198 o0 ] [198])
(reg:SI 7 r7)) ./gccmpsm0/obj_lite/cjpeg/jccolor-case.E:18 186
{*thumb1_movsi_insn}
 (nil))

(note 84 210 211 3 NOTE_INSN_DELETED)

(insn 211 84 85 3 (set (reg:SI 0 r0)
(mem/f:SI (plus:SI (reg:SI 6 r6)
(const_int 4 [0x4])) [2 MEM[(char * * *)o_15(D) + 4B]+0 S4
A32])) ./gccmpsm0/obj_lite/cjpeg/jccolor-case.E:19 186 {*thumb1_movsi_insn}
 (nil))

(insn 85 211 171 3 (set (reg/v/f:SI 7 r7 [orig:201 o1 ] [201])
(mem/f:SI (plus:SI (reg:SI 0 r0)
(reg:SI 3 r3 [orig:273 D.4183 ] [273])) [2 *D.4091_23+0 S4
A32])) ./gccmpsm0/obj_lite/cjpeg/jccolor-case.E:19 186 {*thumb1_movsi_insn}
 (nil))

*/
Obviously, r6 is corrupted in insn 208, while it is used in insn 211.
piece of generated assembly codes as following:

foo:
push{r4, r5, r6, r7, lr}
movr5, r9
movr7, fp
movr6, sl
movr4, r8
push{r4, r5, r6, r7}
movsl, r3
lslr2, r2, #2
ldrr3, .L11
subr2, r2, r0
subsp, sp, #20
movr9, r1  *step1
subr2, r2, #4
ldrr1, [r3]
ldrr5, .L11+4
movfp, r0
strr2, [sp, #12]
.L8:
movr6, sl
subr6, r6, #1
movsl, r6
bmi.L10
.L7:
movr0, fp
ldrr4, [sp, #12]
addr0, r0, #4
movr6, r9  *step2
movfp, r0
ldrr6, [r6]  *step3, r6 corrupted
movr3, r4
addr3, 

[Bug java/52805] New: [4.8 Regression] 243 new GCC HEAD@185977 regressions (libjava failures)

[dominiq at lps dot ens.fr]

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

 Bug #: 52805
   Summary: [4.8 Regression] 243 new GCC HEAD@185977 regressions
(libjava failures)
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: hjl.to...@gmail.com, ste...@gcc.gnu.org


Revision 185977:

Author:steven
Date:Thu Mar 29 21:00:23 2012 UTC (38 hours, 29 minutes ago)
Changed paths:2
Log Message:
PR java/52730
* class.c (emit_register_classes_in_jcr_section): New function.
(emit_Jv_RegisterClass_calls): New function, split out from ...
(emit_register_classes): ... here. Reorganize.  Do not call
output_constant.

caused massive failures in the libjava test suite (see
http://gcc.gnu.org/ml/gcc-regression/2012-03/msg00282.html and the recent posts
at http://gcc.gnu.org/ml/gcc-regression/2012-03/ ).

[Bug c++/52680] std::this_thread::sleep_for #ifdef'd out by _GLIBCXX_USE_NANOSLEEP

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2012-03-31 
12:02:43 UTC ---
(In reply to comment #4)
> Where should I specify that flag? _GLIBCXX_USE_NANOSLEEP is still undefined
> when I build gcc with
> 
> configure CFLAGS='-O3' --disable-bootstrap --disable-multilib
> --enable-ibstdccxx-time=rt --enable-languages=c,c++
   ^

But what if you spell it correctly?  ;)

[Bug c++/52806] New: bogus "zero as null pointer constant" warning

[akim.demaille at gmail dot com]

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

 Bug #: 52806
   Summary: bogus "zero as null pointer constant" warning
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: akim.demai...@gmail.com


Well, I suppose that one could argue that this is not a bug,
but then it makes the feature much less useful.

I think that this warning should do nothing when std=c++11 was
not specified and therefore that nullptr is not supported.  Currently
G++ complains about 0 as a pointer even when it does not support
nullptr!

$ cat foo.cc
int *p1 = 0;
int *p2 = nullptr;

$ g++-mp-4.7 -Wzero-as-null-pointer-constant /tmp/foo.cc
/tmp/foo.cc:1:11: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
/tmp/foo.cc:2:11: error: 'nullptr' was not declared in this scope

$ g++-mp-4.7 --version
g++-mp-4.7 (GCC) 4.7.0 20120225 (experimental)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c++/52807] New: static constant member variable undefined

[sidney.cadot at gmail dot com]

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

 Bug #: 52807
   Summary: static constant member variable undefined
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sidney.ca...@gmail.com


The following program compiles but does not link on Linux, g++ 4.6.1, when
compiled with -O0.

$ g++ -O0 showbug.cc -o showbug
/tmp/ccUq3Hog.o: In function `main':
showbug.cc:(.text+0x16): undefined reference to `Foo::FooConstant'
collect2: ld returned 1 exit status

Compiling with any higher optimization level makes the link error disappear.


/// start

#include 

bool b()
{
return true;
}

struct Foo
{
static const int FooConstant = 123;
};

int main()
{
std::cout << (b() ? Foo::FooConstant : Foo::FooConstant) << std::endl;
return 0;
}

/// end

[Bug c++/52807] static constant member variable undefined

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Jonathan Wakely  2012-03-31 
12:37:20 UTC ---
http://gcc.gnu.org/wiki/VerboseDiagnostics#undefined_reference_to_.60S::a.27

[Bug c++/52806] bogus "zero as null pointer constant" warning

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Paolo Carlini  2012-03-31 
12:56:28 UTC ---
Oh well, changing this would be really trivial, but then people would have to
globally switch-on -std=c++11 (which may not be otherwise appropriate) while
working on removing (as much as possible) explicit zeros from C++98-era code. 

But really I don't have a personal strong opinion, and, as I mentioned already,
a patch would be trivial.

Jason, what shall we do?

[Bug c++/52806] bogus "zero as null pointer constant" warning

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  2012-03-31 
13:06:14 UTC ---
And, hey, I don't really see what's the problem with not passing the -Wzero* at
all if you don't want the warning.

That can *always* be done, but if I once and for all prevent the -Wzero* from
doing anything useful (or even being rejeted) when the default -std=c++98 is in
effect, then, people who want to use it order to start removing explicit zeros
(like, in conditionals and in many other context where it can easily be done
without involving nullptr) don't have *any* help from the compiler.

All in all, my current opinion is that we don't want to do this.

[Bug c++/52806] "zero as null pointer constant" in C++98 mode

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2012-03-31 
13:49:10 UTC ---
Note, even in the *specific* case at issue, maybe the user really wanted p1
statically initialized, or wants an early function call, or something like:

  typedef int* pt;
  int* p1 = pt();

(where pt will be std::nullptr_t in C++11 mode), who knows...

[Bug target/52607] v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}

[marc.glisse at normalesup dot org]

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

Marc Glisse  changed:

   What|Removed |Added

  Attachment #26979|0   |1
is obsolete||

--- Comment #26 from Marc Glisse  2012-03-31 
14:02:54 UTC ---
Created attachment 27052
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27052
default case

Updated with your comments, still can't properly test.

[Bug c++/52806] "zero as null pointer constant" in C++98 mode

[akim.demaille at gmail dot com]

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

--- Comment #4 from Akim Demaille  2012-03-31 
14:12:00 UTC ---
(In reply to comment #1)
> Oh well, changing this would be really trivial, but then people would have to
> globally switch-on -std=c++11 (which may not be otherwise appropriate) while
> working on removing (as much as possible) explicit zeros from C++98-era code. 

I don't think this comment makes sense: with what would you want them
to replace these 0, since nullptr is not available?

I'm having precisely this problem in Bison.  I want it to deliver code
which compiles without warning on the user side (so I cannot play
with Autoconf to check for nullptr support), so I use

# ifndef YY_NULL
#  if 201103L <= __cplusplus
#   define YY_NULL nullptr
#  else
#   define YY_NULL 0
#  endif
# endif

Unfortunately the user *will* have warnings if she passes the
warning flag but not -std=c++11.

This is even worse for C++03.

$ g++-mp-4.7 -std=c++03 -Wzero-as-null-pointer-constant /tmp/foo.cc
/tmp/foo.cc:1:11: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
/tmp/foo.cc:2:11: error: 'nullptr' was not declared in this scope

Or, be consistent with the flags that rejected when misused (such as
-Wmissing-prototypes that does not apply to C++) and reject
that warning when not in std=c++11.

The current status introduces non-killable warnings.

[Bug c++/52806] "zero as null pointer constant" in C++98 mode

[akim.demaille at gmail dot com]

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

--- Comment #5 from Akim Demaille  2012-03-31 
14:26:27 UTC ---
(In reply to comment #4)
> I don't think this comment makes sense: with what would you want them
> to replace these 0, since nullptr is not available?

This does not read like I meant, sorry about this.  It should be
"I don't know how to make sense of that comment".

[Bug bootstrap/52808] New: [4.8 Regression] LTO bootstrap failed with bootstrap-profiled

[hjl.tools at gmail dot com]

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

 Bug #: 52808
   Summary: [4.8 Regression] LTO bootstrap failed with
bootstrap-profiled
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: areg.melikadam...@gmail.com


On Linux/x86-64, revision 186029 failed to LTO bootstrap
with bootstrap-profiled, configured with

--prefix=/usr/local --enable-clocale=gnu --with-system-zlib --enable-shared
--with-demangler-in-ld --with-build-config=bootstrap-lto --with-fpmath=sse
--enable-languages=c,c++,fortran,java,lto,objc

and build with "make profiledbootstrap -j8". Stage3 gcc failed
to configure test in libiberty:

configure:4471:  /export/gnu/import/git/gcc-test-profile/bld/./prev-gcc/xgcc
-B/export/gnu/import/git/gcc-test-profile/bld/./prev-gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include-o conftest -g -O2
-flto=jobserver -frandom-seed=1 -fprofile-use  -static-libstdc++ -static-libgcc
 conftest.c  >&5
conftest.c: In function 'main':
conftest.c:29:1: note: file
/export/gnu/import/git/gcc-test-profile/bld/libiberty/conftest.gcda not found,
execution counts estimated
conftest.c:21:1: internal compiler error: in get_loop_body, at cfgloop.c:831
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:4471: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| /* end confdefs.h.  */
| #include 
| #include 
| #if ((' ' & 0x0FF) == 0x020)
| # define ISLOWER(c) ('a' <= (c) && (c) <= 'z')
| # define TOUPPER(c) (ISLOWER(c) ? 'A' + ((c) - 'a') : (c))
| #else
| # define ISLOWER(c)  (('a' <= (c) && (c) <= 'i')   ||
('j' <= (c) && (c) <= 'r')   || ('s' <= (c) && (c) <= 'z'))
| # define TOUPPER(c) (ISLOWER(c) ? ((c) | 0x40) : (c))
| #endif
|
| #define XOR(e, f) (((e) && !(f)) || (!(e) && (f)))
| int
| main ()
| {
|   int i;
|   for (i = 0; i < 256; i++)
| if (XOR (islower (i), ISLOWER (i))
|   || toupper (i) != TOUPPER (i))
|   return 2;
|   return 0;
| }

Revision 185898 is OK.

[Bug bootstrap/52808] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2012-03-31 14:46:11 
UTC ---
A small testcase:

[hjl@gnu-16 bld]$ cat x.c
#include 
#if ((' ' & 0x0FF) == 0x020)
# define ISLOWER(c) ('a' <= (c) && (c) <= 'z')
# define TOUPPER(c) (ISLOWER(c) ? 'A' + ((c) - 'a') : (c))
#else
# define ISLOWER(c)  (('a' <= (c) && (c) <= 'i')   ||
('j' <= (c) && (c) <= 'r')   || ('s' <= (c) && (c) <= 'z'))
# define TOUPPER(c) (ISLOWER(c) ? ((c) | 0x40) : (c))
#endif
#define XOR(e, f) (((e) && !(f)) || (!(e) && (f)))
int
main ()
{
  int i;
  for (i = 0; i < 256; i++)
if (XOR (islower (i), ISLOWER (i))
  || toupper (i) != TOUPPER (i))
  return 2;
  return 0;
}
[hjl@gnu-16 bld]$ gcc -g -O2 -c -fprofile-use x.c
x.c: In function \u2018main\u2019:
x.c:19:1: note: file /export/gnu/import/git/gcc-test-profile/bld/x.gcda not
found, execution counts estimated
x.c:11:1: internal compiler error: in get_loop_body, at cfgloop.c:831
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[hjl@gnu-16 bld]$

[Bug c++/52680] std::this_thread::sleep_for #ifdef'd out by _GLIBCXX_USE_NANOSLEEP

[mkline at cs dot wisc.edu]

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

--- Comment #6 from Matt Kline  2012-03-31 14:52:40 
UTC ---
Well this certainly isn't my brightest moment. That seems to be the problem.

[Bug bootstrap/52808] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2012-03-31 
15:16:11 UTC ---
The error is the same as in pr52797.

[Bug tree-optimization/52797] [4.8 Regression] Revision 185913 causes ICE in get_loop_body, at cfgloop.c:831 on PowerPC

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  2012-03-31 
15:16:18 UTC ---
The error is the same as in pr52808.

[Bug c++/52680] std::this_thread::sleep_for #ifdef'd out by _GLIBCXX_USE_NANOSLEEP

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-03-31
 Ever Confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #7 from Jonathan Wakely  2012-03-31 
15:19:38 UTC ---
ok, great :)  As I said, we do need to revisit the configure-time checks which
determine whether to use nanonsleep and sched_yield. Doing so is on my TODO
list so I'm going to confirm this PR but as an enhancement rather than a bug.

For the benefit of the other maintainers: in some off-list discussion with
Rainer I suggested that we might want to use --enable-libstdcxx-time by default
on Solaris because sched_yield is defined in libposix4 and doesn't depend on
libpthread.  Additionally, we should note that librt(3LIB) on Solaris says:
"The name libposix4 is maintained for backward compatibility and should be
avoided. librt is the preferred name for this library."

[Bug c++/52809] New: Template non-dependent static_assert diagnostics may confuse

[potswa at mac dot com]

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

 Bug #: 52809
   Summary: Template non-dependent static_assert diagnostics may
confuse
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pot...@mac.com


A static_assert declaration that does not depend on template parameters will be
detected and reported while parsing the template, before any instantiation.
This is OK because such a template would have no valid instantiation, which
immediately renders the program ill-formed.

In terms of cosmetic QOI, however, it would be better to clarify the messages
for users who don't know all the rules. Intuitively, the assertion shouldn't be
evaluated until instantiation, regardless of dependence. The user might expect
an uninstantiated template to pass through. We should add something like
"error: template MyTemplate cannot have a valid instantiation" after the
static_assert diagnostic.

Example code and result, as currently implemented:

template< bool b >
struct s {
static_assert( b, "uhoh" );
static_assert( false, "yikes" );
};

s< false > q;

depassert.cpp:4:1: error: static assertion failed: yikes
depassert.cpp: In instantiation of ‘struct s’:
depassert.cpp:7:12:   required from here
depassert.cpp:3:1: error: static assertion failed: uhoh

[Bug c++/52809] Template non-dependent static_assert diagnostics may confuse

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Paolo Carlini  2012-03-31 
16:55:10 UTC ---
If we wanted, I think a simple way to add an inform about a static_assert which
can never be fullfilled, would be adding a flag to finish_static_assert in
order to tell in its body whether is being called from the parser or from pt.c.
Something a bit uncommon, afaik, but seems simple.

Jason, what do you think?

[Bug c++/52654] [C++11] Warn on overflow in user-defined literals

[3dw4rd at verizon dot net]

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

--- Comment #5 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2012-03-31 
16:57:12 UTC ---
Created attachment 27053
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27053
This test should give no warnings.

I think I'm going to have to put off interpreting numbers until the very end
inside the call resolution.  I think I should completely remove the numeric
value from the literal tree.

Sigh.

[Bug c++/40942] GCC accepts code that Comeau and MSVC deems invalid.

[dodji at seketeli dot org]

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

--- Comment #8 from dodji at seketeli dot org  
2012-03-31 17:02:48 UTC ---
A candidate fix was posted to
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01993.html for review.

[Bug c++/52654] [C++11] Warn on overflow in user-defined literals

[3dw4rd at verizon dot net]

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

--- Comment #6 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2012-03-31 
17:06:12 UTC ---
Created attachment 27054
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27054
Test case for overflow warnings.

This test case should give the appropriate warnings.

Also, what about this:

 -3_w;

[Bug bootstrap/52808] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  2012-03-31 17:07:32 
UTC ---
It may be caused by revision 185913:

http://gcc.gnu.org/ml/gcc-cvs/2012-03/msg01244.html

[Bug c++/52654] [C++11] Warn on overflow in user-defined literals

[marc.glisse at normalesup dot org]

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

--- Comment #7 from Marc Glisse  2012-03-31 
17:18:37 UTC ---
(In reply to comment #6)
> Also, what about this:
> 
>  -3_w;

What about it? IIUC, it is just -(3_w), I don't think it requires a particular
treatment.

[Bug c++/52654] [C++11] Warn on overflow in user-defined literals

[3dw4rd at verizon dot net]

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

--- Comment #8 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2012-03-31 
18:29:45 UTC ---
I think it's actually (-3)_w.  The tokenizer would pick the - up and pass -3
along.

The result of applying a literal operator may not be numeric at all i.e.
operator- would mean nothing.

I guess it would be taken care of however -3 would be for unsigned long long.

[Bug java/52805] [4.8 Regression] 243 new GCC HEAD@185977 regressions (libjava failures)

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-03-31
 CC||iains at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Iain Sandoe  2012-03-31 20:08:33 
UTC ---
reverting the change does restore libjava function.

- I took a very quick look at the asm output from a "HelloWorld.class" (with
the patch in place) and it seems reasonable.  Presumably, some more complex
case (my example code only has one class) might be misrepresented.

[Bug target/52811] New: -O3 flag makes xorg-server-1.11.4 compile fail on amd64

[goeland86 at gmail dot com]

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

 Bug #: 52811
   Summary: -O3 flag makes xorg-server-1.11.4 compile fail on
amd64
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: goelan...@gmail.com


When compiling xorg-server-1.11.4 with the -O3 optimization flag enabled, the
compilation of xorg-server fails in xf86EdidModes.c at line 747, about an array
subscript being above array bounds.

Recompiling with the -O2 flag the error disappears without any other changes to
the configuration.

I ran into the problem with gcc-4.5.3 today, but I ran into it several months
back, possibly with 4.5.2 (I'm not quite sure, and didn't think it was gcc
related at the time.)

This happened on Gentoo reportedly to others besides myself, according to
echoes in #gentoo on irc.freenode.net.

[Bug target/52811] -O3 flag makes xorg-server-1.11.4 compile fail on amd64

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-03-31
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2012-03-31 
20:50:24 UTC ---
Please don't expect people to download a whole package, you have the files
already so you can provide the preprocessed source for the file that fails to
compile.

See http://gcc.gnu.org/bugs/

[Bug bootstrap/52812] New: --enable-targets=all --with-multilib-list=m32,m64,mx32 doesn't work with i686-linux

[hjl.tools at gmail dot com]

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

 Bug #: 52812
   Summary: --enable-targets=all --with-multilib-list=m32,m64,mx32
doesn't work with i686-linux
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


When configured with

--enable-targets=all --with-multilib-list=m32,m64,mx32 i686-linux

bootstrap failed with

libtool: compile:  /export/build/gnu/gcc-x32-32bit/build-i686-linux/./gcc/xgcc
-B/export/build/gnu/gcc-x32-32bit/build-i686-linux/./gcc/
-B/usr/gcc-4.8.0-x32/i686-linux/bin/ -B/usr/gcc-4.8.0-x32/i686-linux/lib/
-isystem /usr/gcc-4.8.0-x32/i686-linux/include -isystem
/usr/gcc-4.8.0-x32/i686-linux/sys-include -DHAVE_CONFIG_H -I.
-I/net/gnu-6/export/gnu/import/git/gcc-x32/libgomp
-I/net/gnu-6/export/gnu/import/git/gcc-x32/libgomp/config/linux/x86
-I/net/gnu-6/export/gnu/import/git/gcc-x32/libgomp/config/linux
-I/net/gnu-6/export/gnu/import/git/gcc-x32/libgomp/config/posix
-I/net/gnu-6/export/gnu/import/git/gcc-x32/libgomp -Wall -Werror
-ftls-model=initial-exec -march=i486 -pthread -mtune=i686 -g -O2 -mx32 -MT
barrier.lo -MD -MP -MF .deps/barrier.Tpo -c
/net/gnu-6/export/gnu/import/git/gcc-x32/libgomp/barrier.c  -fPIC -DPIC -o
.libs/barrier.o
/net/gnu-6/export/gnu/import/git/gcc-x32/libgomp/barrier.c:1:0: error: CPU you
selected does not support x86-64 instruction set

The problem are libgomp/configure.tgt has

# Note that bare i386 is not included here.  We need cmpxchg.
i[456]86-*-linux*)
config_path="linux/x86 linux posix"
case " ${CC} ${CFLAGS} " in
  *" -m64 "*)
;;
  *)
if test -z "$with_arch"; then
  XCFLAGS="${XCFLAGS} -march=i486 -mtune=${target_cpu}"
fi  
esac
;;  

and libitm/configure.tgt has

  i[3456]86)
case " ${CC} ${CFLAGS} " in
  *" -m64 "*)
;;  
  *)  
if test -z "$with_arch"; then
  XCFLAGS="${XCFLAGS} -march=i486 -mtune=${target_cpu}"
  XCFLAGS="${XCFLAGS} -fomit-frame-pointer"
fi  
esac
ARCH=x86
;;  

-mx32 case is missing.

[Bug bootstrap/52784] i386-apple-darwin multilib bootstrap broken

[hjl at gcc dot gnu.org]

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

--- Comment #5 from hjl at gcc dot gnu.org  2012-03-31 
21:03:42 UTC ---
Author: hjl
Date: Sat Mar 31 21:03:36 2012
New Revision: 186049

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186049
Log:
Don't check TARGET_64BIT if TARGET_64BIT_DEFAULT is false

2012-03-31  H.J. Lu  

PR bootstrap/52784
* config/i386/i386.c (ix86_option_override_internal): Don't
check TARGET_64BIT if TARGET_64BIT_DEFAULT is false.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c

[Bug bootstrap/52812] --enable-targets=all --with-multilib-list=m32,m64,mx32 doesn't work with i686-linux

[hjl at gcc dot gnu.org]

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

--- Comment #1 from hjl at gcc dot gnu.org  2012-03-31 
21:08:26 UTC ---
Author: hjl
Date: Sat Mar 31 21:08:22 2012
New Revision: 186050

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186050
Log:
Handle -mx32 like -m64

libgomp/

2012-03-31  H.J. Lu  

PR bootstrap/52812
* configure.tgt (i[456]86-*-linux*): Handle -mx32 like -m64.

libitm/

2012-03-31  H.J. Lu  

PR bootstrap/52812
* configure.tgt (i[456]86-*-linux*): Handle -mx32 like -m64.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/configure.tgt
trunk/libitm/ChangeLog
trunk/libitm/configure.tgt

[Bug bootstrap/52812] --enable-targets=all --with-multilib-list=m32,m64,mx32 doesn't work with i686-linux

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.8.0

--- Comment #2 from H.J. Lu  2012-03-31 21:56:32 
UTC ---
Fixed.

[Bug target/52811] -O3 flag makes xorg-server-1.11.4 compile fail on amd64

[goeland86 at gmail dot com]

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

--- Comment #2 from goeland86 at gmail dot com 2012-03-31 22:04:50 UTC ---
Apologies. I will upload the proper files as soon as possible - at the moment I
have gentoo installing the whole system having fixed the bug. I will re-create
the conditions tomorrow and upload the required data then. I was told to report
this bug to gcc, and have been a bit hasty.

[Bug inline-asm/52813] New: %rsp in clobber list is silently ignored

[jhaberman at gmail dot com]

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

 Bug #: 52813
   Summary: %rsp in clobber list is silently ignored
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jhaber...@gmail.com


The following test program crashes even though I correctly listed %rsp as
clobbered:

--

int main() {
  asm volatile ("movq $0, %%rsp" : : : "%rsp");
  return 0;
}

--

I would prefer gcc to error out in this case instead of silently ignoring my
instruction.

[Bug c++/52814] New: Internal compiler error: segmentation fault

[sparsh0mittal at gmail dot com]

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

 Bug #: 52814
   Summary: Internal compiler error: segmentation fault
Classification: Unclassified
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sparsh0mit...@gmail.com


I am compiling Sniper-multicore simulator files. On ubuntu it compiles fine
(where boost is already there). On my red-hat (RHEL 5.2), where I don't have
root permission, I installed gcc-4.6.0 and boost-1.49 and am trying to compile
Sniper files. However, gcc fails:

/home/sparsh/bin/gccbin/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus
-fpreprocessed clock_skew_minimization.ii -quiet -dumpbase
clock_skew_minimization.cc -mtune=generic -march=x86-64 -auxbase-strip
/home/sparsh/ddrive/test/sniper/pin/../pin/clock_skew_minimization.o -g -g -O3
-O3 -O3 -Wall -Wextra -Wcast-align -Wno-unused-parameter -Wno-unknown-pragmas
-std=c++0x -version -fno-strict-aliasing -fno-stack-protector
-fomit-frame-pointer -fPIC -o clock_skew_minimization.s
GNU C++ (GCC) version 4.6.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0, GMP version 5.0.2, MPFR version 3.1.0,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.6.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0, GMP version 5.0.2, MPFR version 3.1.0,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 92a6c3dce9332c98e77c2cc0d9d9f40f
g++: internal compiler error: Segmentation fault (program cc1plus)

File is attached.

[Bug c++/52814] Internal compiler error: segmentation fault

[sparsh0mittal at gmail dot com]

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

--- Comment #1 from rohit  2012-03-31 22:55:31 
UTC ---
Created attachment 27056
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27056
preprocessed file with shows error

[Bug c++/52814] Internal compiler error: segmentation fault

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Severity|critical|normal

[Bug c++/52639] ice in supportable_widening_operation

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-03-31
 Ever Confirmed|0   |1

--- Comment #2 from Paolo Carlini  2012-03-31 
23:17:45 UTC ---
Please, do your best to reduce the size of the reproducer:
http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction

[Bug c++/52470] ice in copy_binfo

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #4 from Paolo Carlini  2012-03-31 
23:28:47 UTC ---
Duplicate.

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

[Bug c++/52685] [4.7/4.8 Regression] ICE in copy_binfo

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #4 from Paolo Carlini  2012-03-31 
23:28:47 UTC ---
*** Bug 52470 has been marked as a duplicate of this bug. ***

[Bug java/52815] New: class.c:2815:53: error: 'JCR_SECTION_NAME' was not declared in this scope

[danglin at gcc dot gnu.org]

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

 Bug #: 52815
   Summary: class.c:2815:53: error: 'JCR_SECTION_NAME' was not
declared in this scope
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11


/test/gnu/gcc/objdir/./prev-gcc/g++ -B/test/gnu/gcc/objdir/./prev-gcc/
-B/opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/bin/ -nostdinc++
-B/test/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-B/test/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs
-I/test/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-L/test/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.
libs
-L/test/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs
-c  -DIN_GCC_FRONTEND -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -
Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
-DHAVE_CONFIG_H -I. -Ijava -I../../gcc/gcc -I../../gcc/gcc/java
-I../../gcc/gcc/
../include -I../../gcc/gcc/../libcpp/include -I/opt/gnu/gcc/gmp/include 
-I../..
/gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
  ../../gcc/gcc/java/decl.c -o java/decl.o
../../gcc/gcc/java/class.c: In function 'void
emit_register_classes_in_jcr_secti
on()':
../../gcc/gcc/java/class.c:2815:53: error: 'JCR_SECTION_NAME' was not declared
i
n this scope

[Bug java/52815] class.c:2815:53: error: 'JCR_SECTION_NAME' was not declared in this scope

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #1 from John David Anglin  2012-04-01 
01:28:26 UTC ---
Target doesn't have named sections, so TARGET_USE_JCR_SECTION
shouldn't be defined.  JCR_SECTION_NAME isn't defined on 32-bit
HP-UX.