[Bug c/57725] conflicting language extensions

[jbeulich at novell dot com]

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

--- Comment #5 from jbeulich at novell dot com ---
How that? How is code supposed to find out then?

Perhaps briefly explaining where this is coming from originally might help: The
Xen hypervisor (as much as Linux) has a number of linker script constructs like

  .xsm_initcall.init : {
   __xsm_initcall_start = .;
   *(.xsm_initcall.init)
   __xsm_initcall_end = .;
  } :text

If there's no matching input section at all, the two boundary symbols will end
up equal. How would C code be supposed to find out if the comparison result is
unspecified?

And remember, this is not a problem with default visibility (presumably because
the code needs to be prepared for link time overrides of the symbols), but Xen
likes to get built with non-default visibility in order to avoid expensive GOT
indirections when accessing data despite the necessary use of -fPIC.

[Bug middle-end/36041] Speed up builtin_popcountll

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek  ---
Created attachment 30382
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30382&action=edit
gcc49-pr36041.patch

Untested libgcc2.c implementation (no hw support).  HW support is IMHO best
dealt on the compiler side doing something, already a PLT call is fairly
expensive, but it depends if __builtin_popcount* is used in a hot loop or in
cold code (in the latter case it really doesn't matter).

I've looked at code generated for:
int
foo (unsigned long long i)
{
  i = i - ((i >> 1) & 0x);
  i = (i & 0x) + ((i >> 2) & 0x);
  i = (i + (i >> 4)) & 0xF0F0F0F0F0F0F0F;
  return (i * 0x101010101010101) >> 56;
}

int
bar (unsigned long long i)
{
  unsigned int i1 = i, i2 = i >> 32;
  i1 = i1 - ((i1 >> 1) & 0x);
  i2 = i2 - ((i2 >> 1) & 0x);
  i1 = (i1 & 0x) + ((i1 >> 2) & 0x);
  i2 = (i2 & 0x) + ((i2 >> 2) & 0x);
  i1 = (i1 + (i1 >> 4)) & 0xF0F0F0F;
  i2 = (i2 + (i2 >> 4)) & 0xF0F0F0F;
  return ((i1 + i2) * 0x1010101) >> 24;
}

int
baz (unsigned long long i)
{
  i = i - ((i >> 1) & 0x);
  i = (i & 0x) + ((i >> 2) & 0x);
  i = (i + (i >> 4)) & 0xF0F0F0F0F0F0F0F;
  return unsigned int) i) + (unsigned int) (i >> 32)) * 0x1010101) >> 24;
}
on gcc -O2 -m32 and picked the second variant as shortest for the UDWtype
implementation, I guess that is likely the case on most targets.  Note that the
patch still doesn't attempt to figure out if UWtype multiplication is expensive
or not, perhaps a useful test would be whether we emit __umul3 for that
mode inside of libgcc - we'd need to define some macro and if multiplication is
expensive use the shifts + additions alternative instead.

[Bug c++/57724] wrong error: returning a value from a constructor

[joerg.rich...@pdv-fs.de]

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

--- Comment #5 from Jörg Richter  ---
BTW: There is currently a discussion [1] on this topic on the 
"ISO C++ Standard - Discussion" list.

[1]
https://groups.google.com/a/isocpp.org/d/msg/std-discussion/ehqGBMsswjk/nbsubYASnPgJ

[Bug tree-optimization/57723] Missed optimization: recursion around empty function

[petschy at gmail dot com]

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

--- Comment #7 from petschy at gmail dot com ---
Is it a plausible assumption that if a function is not marked as 'noreturn' and
the loop doesn't change the program's state then the loop could be optimized
away?

Cases:
- the loop terminates, but the state is not changed, NOP
- the loop does not terminate (in this case a cycle of the Node's), but the
function should return (no noreturn attr), so this is probably a bug in the prg

I can't think of any cases right now for the second point where that would be
the desired behaviour of the program, instead of a bug. Please comment on this.

[Bug fortran/53801] gfortran warning

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-06-27
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
Could we close this PR as INVALID?

[Bug fortran/54048] Uninitialized input_location in front-end initialization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-06-27
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Is this still present? If yes can tou provide a reproducer?

[Bug target/57717] error: unrecognizable insn compiling ./strtod_l.c from glibc on powerpc-gnuspe

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #3 from Alan Modra  ---
Created attachment 30383
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30383&action=edit
potential fix

This reverts part of the patch identified in comment #1, and cures the testcase
failure.

[Bug fortran/54048] Uninitialized input_location in front-end initialization

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Mikael Morin  ---
(In reply to Dominique d'Humieres from comment #1)
> Is this still present? If yes can tou provide a reproducer?

No. As far as I remember, it used to happen on any testcase, for example:

!!!
end
!!!

It seems to work now.  Valgrind reports errors, but they seem to be deep down
the middle-end, and unrelated to this.  Closing.

[Bug fortran/54788] ICE on pointer-array element assignment

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-27
 Ever confirmed|0   |1

--- Comment #6 from Dominique d'Humieres  ---
I still get an ICE for the second test in comment #1 at revision 200429. The
backtrace is

Program received signal SIGSEGV, Segmentation fault.
gfc_array_size (array=0x141b148d0, result=0x7fff5fbfd300) at
../../work/gcc/fortran/array.c:2087
2087  if (as->type == AS_ASSUMED_RANK)
(gdb) bt 
#0  gfc_array_size (array=0x141b148d0, result=0x7fff5fbfd300) at
../../work/gcc/fortran/array.c:2087
#1  0x00010003f1a0 in gfc_check_pointer_assign (lvalue=0x141b143f0,
rvalue=0x141b148d0) at ../../work/gcc/fortran/expr.c:3648
#2  0x0001000a060e in resolve_code (code=, ns=) at ../../work/gcc/fortran/resolve.c:9815
#3  0x0001000a18c4 in resolve_codes (ns=) at
../../work/gcc/fortran/resolve.c:14474
#4  0x000100091f1d in gfc_resolve (ns=) at
../../work/gcc/fortran/resolve.c:14502
#5  0x000100085f2b in gfc_parse_file () at
../../work/gcc/fortran/parse.c:4442
#6  0x0001000c6316 in gfc_be_parse_file () at
../../work/gcc/fortran/f95-lang.c:189
#7  0x000100793294 in compile_file () at ../../work/gcc/toplev.c:544
#8  0x000100795389 in toplev_main (argc=2, argv=0x7fff5fbfd7a8) at
../../work/gcc/toplev.c:1872
#9  0x00019ca4 in start (pc=, bases=0x0) at
../../../work/libgcc/config/unwind-dw2-fde-darwin.c:272

With the following (untested) patch

--- ../_clean/gcc/fortran/array.c2013-06-08 11:35:26.0 +0200
+++ gcc/fortran/array.c2013-06-27 11:06:24.0 +0200
@@ -2084,7 +2084,7 @@ spec_size (gfc_array_spec *as, mpz_t *re
   mpz_t size;
   int d;

-  if (as->type == AS_ASSUMED_RANK)
+  if (!as || as->type == AS_ASSUMED_RANK)
 return false;

   mpz_init_set_ui (*result, 1);

one gets the error

  a(0:0) => b
1
Error: Rank remapping target must be rank 1 or simply contiguous at (1)

[Bug fortran/54679] Erroneous "Expected P edit descriptor" in conjunction with L descriptor

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-27
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Still present at revision 200429.

[Bug fortran/57697] Segfault with defined assignment for components during intrinsic assignment

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-27
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
(In reply to Tobias Burnus from comment #3)
> > Should not this go to PR57696?
>
> No. The examples are similar, but they expose rather different bugs.

So confirmed.

[Bug fortran/57590] [OOP] class containers are recycled between symbols more than they should be

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-27
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/57611] [Fortran-Dev Regression] Too much memory allocated (gfortran.dg/coarray_lib_alloc_2.f90)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-27
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/57496] I/O: WRITE(*,*) HUGE(0._10) gives SIGFPE with -ffpe-trap=overflow

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-27
 Ever confirmed|0   |1

--- Comment #5 from Dominique d'Humieres  ---
Still present at revision 200429 for huge(0.0_10).

[Bug target/57731] New: [4.9 Regression] ICE in extract_insn, at recog.c:2158 (arm-linux)

[doko at gcc dot gnu.org]

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

Bug ID: 57731
   Summary: [4.9 Regression] ICE in extract_insn, at recog.c:2158
(arm-linux)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

Created attachment 30384
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30384&action=edit
preprocessed source

seen with trunk 20130620 on arm-linux-gnueabihf

$ /usr/lib/gcc-snapshot/bin/g++ -c -O2 SVGStyledLocatableElement.ii
In file included from ../../khtml/svg/SVGStyledLocatableElement.cpp:27:0:
../../khtml/svg/SVGStyledLocatableElement.h: In member function 'virtual
WebCore::FloatRect
WebCore::SVGStyledLocatableElement::_ZTv0_n24_NK7WebCore25SVGStyledLocatableElement7getBBoxEv()
const':
../../khtml/svg/SVGStyledLocatableElement.h:45:27: error: unrecognizable insn:
 virtual FloatRect getBBox() const;
   ^
(call_insn/j 10 9 11 2 (parallel [
(set (parallel:BLK [
(expr_list:REG_DEP_TRUE (reg:SF 16 s0)
(const_int 0 [0]))
(expr_list:REG_DEP_TRUE (reg:SF 17 s1)
(const_int 4 [0x4]))
(expr_list:REG_DEP_TRUE (reg:SF 18 s2)
(const_int 8 [0x8]))
(expr_list:REG_DEP_TRUE (reg:SF 19 s3)
(const_int 12 [0xc]))
])
(call (mem:SI (symbol_ref:SI ("*.LTHUNK10") [flags 0x3]
) [0 *.LTHUNK10 S4 A32])
(const_int 0 [0])))
(return)
(use (const_int 0 [0]))
]) -1
 (nil)
(expr_list:REG_CFA_WINDOW_SAVE (use (reg:SI 0 r0))
(nil)))
../../khtml/svg/SVGStyledLocatableElement.h:45:27: internal compiler error: in
extract_insn, at recog.c:2158
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug fortran/56596] Invalid read of size 4 gfortran.dg/class_array_7.f03

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-06-27
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
I no longer see the valgrind error at revision 200078 (clean tree). Can this be
confirmed?

On my working tree (r200429, several patches) using valgrind with
--leak-check=full gives

==85435== 80 bytes in 1 blocks are definitely lost in loss record 1 of 2
==85435==at 0x100013679: malloc (vg_replace_malloc.c:266)
==85435==by 0x11358: __realloc_MOD_reallocate (class_array_7.f03:31)
==85435==by 0x119C6: MAIN__ (class_array_7.f03:55)
==85435==by 0x11B5B: main (class_array_7.f03:49)

(no error without --leak-check=full). Investigating.

[Bug c++/57279] [C++11] alias declaration fails to declare function types with cv-qualifiers

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||doko at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Matthias Klose  ---
closing. this apparently did get into the 4.8.1 release. however can't change
the milestone back to 4.8.1.

[Bug c++/57279] [C++11] alias declaration fails to declare function types with cv-qualifiers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|4.8.2   |4.8.1

--- Comment #4 from Jonathan Wakely  ---
Trunk: http://gcc.gnu.org/r198975
4.8.1: http://gcc.gnu.org/r198976

[Bug bootstrap/57486] bootstrap fails on 4.8 and google/4.8 branch on RHEL6.1 platform

[dtemirbulatov at gmail dot com]

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

Dinar Temirbulatov  changed:

   What|Removed |Added

 CC||dtemirbulatov at gmail dot com

--- Comment #2 from Dinar Temirbulatov  ---
Created attachment 30385
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30385&action=edit
preporcessed graphite.c with -dD option

[Bug target/57623] BEXTR intrinsic has memory operands switched around (fails to compile code)

[sgunderson at bigfoot dot com]

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

--- Comment #6 from sgunderson at bigfoot dot com ---
BZHI seems to have the same problem.

[Bug bootstrap/57486] bootstrap fails on 4.8 and google/4.8 branch on RHEL6.1 platform

[dtemirbulatov at gmail dot com]

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

--- Comment #3 from Dinar Temirbulatov  ---
Hello, Richard. I have got this error with gcc-4.8.x-google branch under the
RedHat based system. Here is command-line to reproduce the error: g++ -c
graphite.i -o graphite.o -fno-exceptions -fno-rtti -O2.

[Bug target/57624] BZHI instrinsic is missing

[sgunderson at bigfoot dot com]

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

--- Comment #2 from sgunderson at bigfoot dot com ---
Shouldn't really the documentation say so, then? The entire GCC manual seems to
make no note of this header at all, as far as I can see.

[Bug go/57689] [4.8 Regression] ICE (segfault) building libgo on ia64-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #2 from Matthias Klose  ---
building with BOOT_CFLAGS set to -g -O1 or -g -Og doesn't show the ICE and
builds libgo. Attaching test results later.

gcc-bugs@gcc.gnu.org

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |glisse at gcc dot 
gnu.org

--- Comment #7 from Marc Glisse  ---
r200463 | glisse | 2013-06-27 13:34:48 +0200 (Thu, 27 Jun 2013) | 11 lines

2013-06-27  Marc Glisse  

PR c++/57172
gcc/cp/
* pt.c (more_specialized_fn): If both arguments are references,
give priority to an lvalue.

gcc/testsuite/
* g++.dg/cpp0x/pr57172.C: New testcase.

[Bug tree-optimization/57732] New: [4.8 / 4.9 Regression] ICE (segfault in libisl) building drizzle on 32bit targets (at least arm-linux and i586-linux)

[doko at gcc dot gnu.org]

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

Bug ID: 57732
   Summary: [4.8 / 4.9 Regression] ICE (segfault in libisl)
building drizzle on 32bit targets (at least arm-linux
and i586-linux)
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

Created attachment 30386
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30386&action=edit
preprocessed source

g++ -c -g -O2 -std=gnu++98 -fPIE -floop-parallelize-all -fno-strict-aliasing 
cmpfunc.ii 

leaving out the -floop-parallelize-all avoids the ICE.

(gdb) bt
#0  0xf7f5859c in ?? () from /usr/lib/i386-linux-gnu/libisl.so.10
#1  0xf7f58629 in ?? () from /usr/lib/i386-linux-gnu/libisl.so.10
#2  0xf7f512b7 in isl_tab_rollback () from /usr/lib/i386-linux-gnu/libisl.so.10
#3  0xf7f5307b in ?? () from /usr/lib/i386-linux-gnu/libisl.so.10
#4  0xf7f59376 in ?? () from /usr/lib/i386-linux-gnu/libisl.so.10
#5  0xf7f59355 in ?? () from /usr/lib/i386-linux-gnu/libisl.so.10
#6  0xf7f59355 in ?? () from /usr/lib/i386-linux-gnu/libisl.so.10
#7  0xf7f59355 in ?? () from /usr/lib/i386-linux-gnu/libisl.so.10
#8  0xf7f5a283 in ?? () from /usr/lib/i386-linux-gnu/libisl.so.10
#9  0xf7f5a506 in ?? () from /usr/lib/i386-linux-gnu/libisl.so.10
#10 0xf7f5ac09 in ?? () from /usr/lib/i386-linux-gnu/libisl.so.10
#11 0xf7efb5b2 in ?? () from /usr/lib/i386-linux-gnu/libisl.so.10
#12 0xf7f0d3d3 in ?? () from /usr/lib/i386-linux-gnu/libisl.so.10
#13 0xf7f0e067 in ?? () from /usr/lib/i386-linux-gnu/libisl.so.10
#14 0xf7ee0728 in ?? () from /usr/lib/i386-linux-gnu/libisl.so.10
#15 0xf7ee07f3 in ?? () from /usr/lib/i386-linux-gnu/libisl.so.10
#16 0xf7ee16e9 in isl_access_info_compute_flow () from
/usr/lib/i386-linux-gnu/libisl.so.10
#17 0xf7ee1f09 in ?? () from /usr/lib/i386-linux-gnu/libisl.so.10
#18 0xf7f61d6a in ?? () from /usr/lib/i386-linux-gnu/libisl.so.10
#19 0xf7ee9d21 in isl_hash_table_foreach () from
/usr/lib/i386-linux-gnu/libisl.so.10
#20 0xf7f62c4e in isl_union_map_foreach_map () from
/usr/lib/i386-linux-gnu/libisl.so.10
#21 0xf7ee228c in isl_union_map_compute_flow () from
/usr/lib/i386-linux-gnu/libisl.so.10
#22 0x088c9ee7 in compute_deps(scop*, vec,
isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**,
isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**,
isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**) ()
#23 0x088ca821 in loop_is_parallel_p(loop*, htab*, int) ()
#24 0x088c8d15 in ?? ()
#25 0x088c8c02 in ?? ()
#26 0x088c9390 in gloog(scop*, htab*) ()
#27 0x088c62db in graphite_transform_loops() ()
#28 0x085ec5a4 in ?? ()
#29 0x08497fae in execute_one_pass(opt_pass*) ()
#30 0x08498385 in execute_pass_list(opt_pass*) ()
#31 0x08498398 in execute_pass_list(opt_pass*) ()
#32 0x08498398 in execute_pass_list(opt_pass*) ()
#33 0x08498398 in execute_pass_list(opt_pass*) ()
#34 0x082dc43b in ?? ()
#35 0x082dda15 in compile() ()
#36 0x082dde9a in finalize_compilation_unit() ()
#37 0x081a82ad in cp_write_global_declarations() ()
#38 0x0852c96d in ?? ()
#39 0x0852e454 in toplev_main(int, char**) ()

[Bug target/57623] BEXTR intrinsic has memory operands switched around (fails to compile code)

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 30387
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30387&action=edit
gcc49-pr57623.patch

BZHI has a similar problem, but due to the non-canonical order of AND arguments
in the pattern I doubt you can actually reproduce the problem (because combine
will never match it, so pretty much always will the insn use only register
arguments).  The attached patch should fix both of those issues.

[Bug target/57623] BEXTR intrinsic has memory operands switched around (fails to compile code)

[sgunderson at bigfoot dot com]

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

--- Comment #8 from sgunderson at bigfoot dot com ---
I really did spot the BZHI problem in actual code; that's how I found out :-) I
rewrote it slightly and the problem disappeared, though.

[Bug target/57623] BEXTR intrinsic has memory operands switched around (fails to compile code)

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Then please provide preprocessed testcase for it (plus command line options). 
Because I'm really curious how it could have been matched.

[Bug fortran/57733] New: pointer assignment internal compiler error

[nerge at informatik dot uni-hamburg.de]

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

Bug ID: 57733
   Summary: pointer assignment internal compiler error
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nerge at informatik dot uni-hamburg.de

Created attachment 30388
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30388&action=edit
minimal example

pointer assignment within function crashes:

function arguments: pointer and allocatable array
- array will be allocated in function 
- afterwards the array will be assigned to the pointer and this crashes with at
least gcc 4.6.3, 4.7.1, 4.8.1, and 4.9:

pointer_test_gfortran.f90: In function ‘test_dyn_coor_3_3d’:
pointer_test_gfortran.f90:80:0: internal compiler error: Segmentation fault
 ptr%x => array%x%x
 ^
libbacktrace could not find executable to open

- minimal example is attached

- the assignment of the array to a local pointer works well

[Bug target/57623] BEXTR intrinsic has memory operands switched around (fails to compile code)

[sgunderson at bigfoot dot com]

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

--- Comment #10 from sgunderson at bigfoot dot com ---
On Thu, Jun 27, 2013 at 12:27:02PM +, jakub at gcc dot gnu.org wrote:
> Then please provide preprocessed testcase for it (plus command line options). 
> Because I'm really curious how it could have been matched.

Sorry, the code is a) not so easy to make public right now, and b) this
particular edit has been lost in the mists of time (like I said, I wrote it
slightly differently and then it was gone). But the scrollback in my terminal
still has this for “proof”:

sesse@gruessi:~/addie$ g++-4.8 -O2 -march=native -o addie addie.cc 
/tmp/ccJweT2R.s: Assembler messages:
/tmp/ccJweT2R.s:82: Error: operand size mismatch for `bzhi'

Sorry I couldn't be more helpful. :-)

/* Steinar */

[Bug target/57623] BEXTR intrinsic has memory operands switched around (fails to compile code)

[sgunderson at bigfoot dot com]

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

--- Comment #11 from sgunderson at bigfoot dot com ---
On Thu, Jun 27, 2013 at 12:32:18PM +, sgunderson at bigfoot dot com wrote:
> Sorry, the code is a) not so easy to make public right now, and b) this
> 
> particular edit has been lost in the mists of time (like I said, I wrote it
> 
> slightly differently and then it was gone). But the scrollback in my termin
> al
> 
> still has this for “proof”:

Hah, I reproduced it. I'll try to distill it down to a small test case.

/* Steinar */

[Bug tree-optimization/57723] Missed optimization: recursion around empty function

[matz at gcc dot gnu.org]

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

--- Comment #8 from Michael Matz  ---
(In reply to petschy from comment #7)
> Is it a plausible assumption that if a function is not marked as 'noreturn'
> and the loop doesn't change the program's state then the loop could be
> optimized away?

It's not unplausible, but still wrong, see below.  GCC optimizes empty
loops only away if the functions containing them are marked pure or const (the
argument being that an infinite loop is in itself a side-effect observable from
outside).  This could be extended to also do that for functions without the
noreturn attribute.

But it would be a relatively large change in semantics.  That is because
noreturn attributes are optional; functions that don't return aren't
required to be so marked, so in practice a missing noreturn attribute
doesn't mean anything.  So, when GCC starts to remove infinite loops in
functions missing it (in practice most functions) this might change behaviour
(which you already can have with the unsafe-loop-optimization flag).

The problem lies with multi-threaded programs.  A function containing
an infinite loop could be stopped from a different thread.  While I'll
happily admit that this is a quite unlikely behaviour, you can construct
a valid program that will break with infinite-loop removal.

So it seems that if any other attribute should trigger this in addition
to const/pure (which have other effects of course), it would have to
be a new one, with positive meaning, ala "this-function-does-return".

I'm not aware of anyone sufficiently motivated to work on this.  Perhaps
you are, if so, look for finite_loop_p() in tree-ssa-loop-niter.c for
the place to lookup the new attribute, and builtin-attrs.def for the place
to define a new attribute.

> Cases:
> - the loop terminates, but the state is not changed, NOP
> - the loop does not terminate (in this case a cycle of the Node's), but the
> function should return (no noreturn attr), so this is probably a bug in the
> prg
> 
> I can't think of any cases right now for the second point where that would
> be the desired behaviour of the program, instead of a bug. Please comment on
> this.

See the multi-threading example.

[Bug target/57623] BEXTR intrinsic has memory operands switched around (fails to compile code)

[sgunderson at bigfoot dot com]

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

--- Comment #12 from sgunderson at bigfoot dot com ---
Created attachment 30389
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30389&action=edit
BZHI bug example (compile with g++-4.8 -O2 -mbmi2 -c foo.cc)

[Bug target/57623] BEXTR intrinsic has memory operands switched around (fails to compile code)

[sgunderson at bigfoot dot com]

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

--- Comment #13 from sgunderson at bigfoot dot com ---
There. That ought to satisfy your curiosity. :-) I get:

sesse@gruessi:~/addie$ g++-4.8 -O2 -mbmi2 -c foo.cc
/tmp/ccX2oEfE.s: Assembler messages:
/tmp/ccX2oEfE.s:21: Error: operand size mismatch for `bzhi'

due to

bzhi_ZL5shift(,%rax,8), %rdx, %rdx

[Bug target/57623] BEXTR intrinsic has memory operands switched around (fails to compile code)

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Ah, right, it isn't the combiner in your case, but register allocator, yes,
that can happen.  The patch I've attached should fix that too.

[Bug target/56788] _mm_frcz_sd and _mm_frcz_ss ignore their second argument

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||dwarak.rajagopal at amd dot 
com,
   ||harsha.jagasia at amd dot com

--- Comment #2 from Marc Glisse  ---
Adding the authors of this code in Cc:, I don't know if they still work at AMD
though.

[Bug fortran/57733] pointer assignment internal compiler error

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-27
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed, the backtrace is

Program received signal SIGSEGV, Segmentation fault.
0x000100109630 in gfc_trans_pointer_assignment (expr1=, expr2=)
at ../../_clean/gcc/fortran/trans-expr.c:6551
warning: Source file is more recent than executable.
6551  gfc_add_modify (&lse.post, GFC_DECL_SPAN(decl), tmp);
(gdb) bt
#0  0x000100109630 in gfc_trans_pointer_assignment (expr1=, expr2=)
at ../../_clean/gcc/fortran/trans-expr.c:6551
#1  0x0001000caa87 in trans_code (code=, cond=) at ../../_clean/gcc/fortran/trans.c:1543
#2  0x0001000f5cb4 in gfc_generate_function_code (ns=)
at ../../_clean/gcc/fortran/trans-decl.c:5479
#3  0x0001000f5b08 in gfc_generate_function_code (ns=)
at ../../_clean/gcc/fortran/trans-decl.c:4612
#4  0x00010008609c in gfc_parse_file () at
../../_clean/gcc/fortran/parse.c:4509
#5  0x0001000c6006 in gfc_be_parse_file () at
../../_clean/gcc/fortran/f95-lang.c:189
#6  0x00010078b844 in compile_file () at ../../_clean/gcc/toplev.c:544
#7  0x00010078d939 in toplev_main (argc=2, argv=0x7fff5fbfd920) at
../../_clean/gcc/toplev.c:1872
#8  0x00019a94 in start (pc=, bases=0x0) at
../../../_clean/libgcc/config/unwind-dw2-fde-darwin.c:272

[Bug middle-end/57670] Member-pointer calls should not be redirected to builtin_unreachable

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Martin Jambor  ---
Author: jamborm
Date: Tue Jun 25 11:09:21 2013
New Revision: 200393

URL: http://gcc.gnu.org/viewcvs?rev=200393&root=gcc&view=rev
Log:
2013-06-25  Martin Jambor  

PR middle-end/57670
* cgraph.h (cgraph_indirect_call_info): New flag member_ptr.
* ipa-prop.c (ipa_print_node_jump_functions): Mark member pointer
calls in the dump.
(ipa_note_param_call): Initialize member_ptr flag.
(ipa_analyze_indirect_call_uses): Set member_ptr flag.
(ipa_make_edge_direct_to_target): Bail out if member_ptr is set.
(ipa_write_indirect_edge_info): Stream member_ptr flag.
(ipa_read_indirect_edge_info): Likewise.

testsuite/
* g++.dg/ipa/pr57670.C (H): New test.


Added:
trunk/gcc/testsuite/g++.dg/ipa/pr57670.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.h
trunk/gcc/ipa-prop.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/57723] Missed optimization: recursion around empty function

[mikpe at it dot uu.se]

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

--- Comment #9 from Mikael Pettersson  ---
(In reply to Michael Matz from comment #8)
> (the
> argument being that an infinite loop is in itself a side-effect observable
> from
> outside).

Exactly.

> A function containing
> an infinite loop could be stopped from a different thread.

We have production code which does that, except the stopping (and redirection
to another context) is done from a separate monitor process via ptrace().

GCC "optimizing" away infinite loops is just plain wrong, at least for ordinary
systems programming languages.

[Bug c++/57734] New: Returning template alias to enum class fails with "invalid declarator"

[rschumacher at tamu dot edu]

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

Bug ID: 57734
   Summary: Returning template alias to enum class fails with
"invalid declarator"
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rschumacher at tamu dot edu

Created attachment 30390
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30390&action=edit
Test file exhibiting the bug (test.ii).

When attempting to return a template alias to an enum class, g++ emits the
error "invalid declarator before 'foo'".

Code:

enum class eclass { zero };

template
using eclass_alias = eclass;

template
eclass_alias foo(T0 f) { return eclass_alias::zero; }

int main() {}

Command Line:

g++-4.9 -v -save-temps -std=c++11 test.cpp

Compiler Output:

test.cpp:7:18: error: invalid declarator before ‘foo’
 eclass_alias foo(T0 f) { return eclass_alias::zero; }
  ^

Compiler Specs:

Using built-in specs.
COLLECT_GCC=g++-4.9
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/ras0219/abs/gcc-git/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share/gcc-4.9
--with-bugurl='http://aur.archlinux.org/packages.php?ID=16045'
--enable-languages=c,c++,lto --enable-shared --enable-threads=posix
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-clocale=gnu --disable-libstdcxx-pch --enable-gnu-unique-object
--enable-linker-build-id --enable-cloog-backend=isl
--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default
--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu
--disable-install-libiberty --disable-multilib --disable-libssp
--disable-werror --enable-checking=release --program-suffix=-4.9
--enable-version-specific-runtime-libs : (reconfigured)
/home/ras0219/abs/gcc-git/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share/gcc-4.9
--with-bugurl='http://aur.archlinux.org/packages.php?ID=16045'
--enable-languages=c,c++,lto --enable-shared --enable-threads=posix
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-clocale=gnu --disable-libstdcxx-pch --enable-gnu-unique-object
--enable-linker-build-id --enable-cloog-backend=isl
--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default
--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu
--disable-install-libiberty --disable-multilib --disable-libssp
--disable-werror --enable-checking=release --program-suffix=-4.9
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.9.0 20130627 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1plus -E -quiet -v -D_GNU_SOURCE
test.cpp -mtune=generic -march=x86-64 -std=c++11 -fpch-preprocess -o test.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/c++

/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/c++/x86_64-unknown-linux-gnu
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/c++/backward
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include
 /usr/local/include
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1plus -fpreprocessed test.ii
-quiet -dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test -std=c++11
-version -o test.s
GNU C++ (GCC) version 4.9.0 20130627 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.0 20130627 (experimental), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.9.0 20130627 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.0 20130627 (experimental), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 527d08db754c44431edf3997957f9281

System Info:

Linux phylactery 3.9.6-1-ARCH #1 SMP PREEMPT Fri Jun 14 08:12:55 CEST 2013
x86_64 GNU/Linux

[Bug c++/57734] Returning template alias to enum class fails with "invalid declarator"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-27
 Ever confirmed|0   |1

[Bug fortran/57733] pointer assignment internal compiler error

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #2 from Mikael Morin  ---
Dup of PR34640?

[Bug c/57725] conflicting language extensions

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  ---
On Thu, 27 Jun 2013, jbeulich at novell dot com wrote:

> How that? How is code supposed to find out then?

Why does the code want to find out?  If it's using these extensions it's 
saying it's OK with the consequences of objects being at the same address, 
including indeterminate comparisons where one of the objects might be 
zero-size.

If you want to compare symbols without optimization, you should be able to 
use asms to hide from the compiler exactly what's being compared.

[Bug c/57725] conflicting language extensions

[jbeulich at novell dot com]

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

--- Comment #7 from jbeulich at novell dot com ---
That's why I gave the example of where this is coming from - the code obviously
wants to be able to determine whether the data block between the two labels is
empty. And no, using asm()-s for this sort of thing is about the last thing I'd
consider acceptable.

[Bug c++/57735] New: ICE with -mtune=xscale (error: could not split insn) when building webkit

[Martin.Jansa at gmail dot com]

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

Bug ID: 57735
   Summary: ICE with -mtune=xscale (error: could not split insn)
when building webkit
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Martin.Jansa at gmail dot com

Created attachment 30391
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30391&action=edit
JSGlobalObjectFunctions.cpp.tar.bz2

I'll try to attach smaller test-case later, but real-world reproducer follows:

/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/xscalete-oe-linux-gnueabi/arm-oe-linux-gnueabi-g++
-v
Using built-in specs.
COLLECT_GCC=/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/xscalete-oe-linux-gnueabi/arm-oe-linux-gnueabi-g++
COLLECT_LTO_WRAPPER=/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/xscalete-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.8.1/lto-wrapper
Target: arm-oe-linux-gnueabi
Configured with:
/OE/shr-core/tmp-eglibc/work-shared/gcc-4.8.1-r0/gcc-4.8.1/configure
--build=x86_64-linux --host=x86_64-linux --target=arm-oe-linux-gnueabi
--prefix=/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr
--exec_prefix=/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr
--bindir=/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/xscalete-oe-linux-gnueabi
--sbindir=/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/xscalete-oe-linux-gnueabi
--libexecdir=/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/xscalete-oe-linux-gnueabi
--datadir=/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/share
--sysconfdir=/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/etc
--sharedstatedir=/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/com
--localstatedir=/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/var
--libdir=/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/lib/xscalete-oe-linux-gnueabi
--includedir=/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include
--oldincludedir=/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include
--infodir=/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/share/info
--mandir=/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/share/man
--disable-silent-rules --disable-dependency-tracking
--with-libtool-sysroot=/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux
--with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix
--disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu
--enable-libstdcxx-pch --program-prefix=arm-oe-linux-gnueabi-
--without-local-prefix --enable-target-optspace --enable-lto --enable-libssp
--disable-bootstrap --disable-libmudflap --with-system-zlib
--with-linker-hash-style=gnu --enable-linker-build-id --with-ppl=no
--with-cloog=no --enable-checking=release --enable-cheaders=c_global
--with-float=soft
--with-gxx-include-dir=/OE/shr-core/tmp-eglibc/sysroots/spitz/usr/include/c++
--with-sysroot=/OE/shr-core/tmp-eglibc/sysroots/spitz
--with-build-sysroot=/OE/shr-core/tmp-eglibc/sysroots/spitz
--enable-poison-system-directories --disable-libunwind-exceptions
--with-mpfr=/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr
--with-system-zlib --disable-nls
Thread model: posix
gcc version 4.8.1 (GCC) 


/OE/shr-core/tmp-eglibc/work/xscalete-oe-linux-gnueabi/webkit-efl/1.9.3+svnr120144-r3/src/Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp:150:1:
error: could not split insn
 }
 ^
(insn 505 8094 507 (set (reg:SI 1 r1 [orig:494 D.142559 ] [494])
(plus:SI (reg/v:SI 5 r5 [orig:157 character ] [157])
(const_int -17179934720 [0xfffb])))
/OE/shr-core/tmp-eglibc/work/xscalete-oe-linux-gnueabi/webkit-efl/1.9.3+svnr120144-r3/src/Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp:108
5 {*arm_addsi3}
 (nil))
/OE/shr-core/tmp-eglibc/work/xscalete-oe-linux-gnueabi/webkit-efl/1.9.3+svnr120144-r3/src/Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp:150:1:
internal compiler error: in final_scan_insn, at final.c:2897
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
{standard input}: Assembler messages:
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive

Removing -mtune=xscale is enough to pass that (the same source builds fine for
other devices I'm using), using -mtune=arm926ej-s also works.

Attached archive contains 3 files:
-rw-r--r-- 1 bitbake bitbake 1932165 Jun 27 17:37
CMakeFiles/javascriptcore_efl.dir/runtime/JSGlobalObjectFunctions.cpp.E#
preprocessed source
-rw-r--r-- 1 bitbake bitbake3809 Jun 27 17:45
CMakeFiles/javascriptcore_efl.dir/runtime/JSGlobalObjectFunctions.cpp.cmd  #
command line used
-rw-r--r-- 1 bitbake bitbake   28308 Jun 27 17:46
CMakeFiles/javascriptcore_efl.dir/runtime/JSGlobalObjectFunctions.cpp.log  #
output with couple of warnings before that ICE

Sorry for packing it, I wasn't s

[Bug go/57689] [4.8 Regression] ICE (segfault) building libgo on ia64-linux-gnu

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor  ---
That makes it sound like the problem is that stage2 GCC is mis-compiling stage3
GCC, and that it's only a coincidence that the error occurs when building
libgo.

[Bug middle-end/56977] gcc -Og incorrectly warns about 'constant zero length parameter'

[harald at gigawatt dot nl]

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

--- Comment #6 from Harald van Dijk  ---
FWIW, I've done some more testing with that on top of 4.8.1 and haven't been
able to find anything that breaks that wasn't already broken without it. Nice,
thanks.

[Bug rtl-optimization/57676] [4.8/4.9 Regression] ICE: Maximum number of LRA constraint passes is achieved (30)

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
That is a pretty interesting test case.  Roughly speaking, we have chains of
divmodsi4 insns:

p1 / p2
...
p3 / p1

P1 (and many others) gets AX.  But it is necessary for P3 in the second insn. 
So on each LRA pass, there is a generation of reloads for one pseudo as P1. 
For these test case, LRA needs 36 passes (on each pass only 2 insns are
processed).  The current max number of passes is 30.

The simplest solution is to increase the max number of passes (and I probably
do it as the first solution).  But it is not the best solution as we don't know
how long the insn chain can be.  We need something smarter but currently I have
no ideas how to do it for any length of such insn chain.

[Bug target/57735] ICE with -mtune=xscale (error: could not split insn) when building webkit

[ktkachov at gcc dot gnu.org]

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

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed with 4.8.1
Works with 4.7 and current trunk 4.9 though.

Fails for -mcpu=xscale , iwmmxt and iwmmxt2

Trying to reduce...

[Bug target/57623] BEXTR intrinsic has memory operands switched around (fails to compile code)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-27
 Ever confirmed|0   |1

--- Comment #15 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jun 27 16:44:17 2013
New Revision: 200477

URL: http://gcc.gnu.org/viewcvs?rev=200477&root=gcc&view=rev
Log:
PR target/57623
* config/i386/i386.md (bmi2_bzhi_3): Swap AND arguments
to match RTL canonicalization.  Swap predicates and
constraints of operand 1 and 2.

* gcc.target/i386/bmi2-bzhi-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/bmi2-bzhi-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

Author: jakub
Date: Thu Jun 27 16:45:44 2013
New Revision: 200478

URL: http://gcc.gnu.org/viewcvs?rev=200478&root=gcc&view=rev
Log:
PR target/57623
* config/i386/i386.md (bmi2_bzhi_3): Swap AND arguments
to match RTL canonicalization.  Swap predicates and
constraints of operand 1 and 2.

* gcc.target/i386/bmi2-bzhi-1.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/bmi2-bzhi-1.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/i386/i386.md
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

Author: jakub
Date: Thu Jun 27 16:48:05 2013
New Revision: 200479

URL: http://gcc.gnu.org/viewcvs?rev=200479&root=gcc&view=rev
Log:
PR target/57623
* config/i386/i386.md (bmi_bextr_): Swap predicates and
constraints of operand 1 and 2.

* gcc.target/i386/bmi-bextr-3.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/bmi-bextr-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

Author: jakub
Date: Thu Jun 27 16:49:38 2013
New Revision: 200480

URL: http://gcc.gnu.org/viewcvs?rev=200480&root=gcc&view=rev
Log:
PR target/57623
* config/i386/i386.md (bmi_bextr_): Swap predicates and
constraints of operand 1 and 2.

* gcc.target/i386/bmi-bextr-3.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/bmi-bextr-3.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/i386/i386.md
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug c/57725] conflicting language extensions

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com  ---
On Thu, 27 Jun 2013, jbeulich at novell dot com wrote:

> That's why I gave the example of where this is coming from - the code 
> obviously
> wants to be able to determine whether the data block between the two labels is
> empty. And no, using asm()-s for this sort of thing is about the last thing 
> I'd
> consider acceptable.

But that doesn't explain why it matters whether it's empty - why you 
aren't e.g. just iterating over objects between the labels (with an 
iteration that happens to do nothing if it's empty) or some such operation 
involving the difference between the labels (that happens to do nothing if 
the difference is 0).  It never matters whether __init_array_start and 
__init_array_end are the same, or whether they compare equal or not, for 
example, because code that uses them naturally iterates over an array 
between them.  I suppose such iterations use an ordered comparison with 
the end pointer, and comparing whether one pointer is less than another 
would work for you if you know the order the pointers would go in if 
unequal (but the compiler doesn't).

It's intrinsic to using empty objects that it *doesn't matter to your 
code* when odd things happen about objects at the same address.  If it 
matters whether addresses derived from different objects compare distinct 
(including whether it's determinate whether they compare distinct), don't 
use empty objects.

[Bug target/57736] New: [4.8/4.9 Regression] ICE in emit_move_insn with __builtin_ia32_rdtsc

[amonakov at gcc dot gnu.org]

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

Bug ID: 57736
   Summary: [4.8/4.9 Regression] ICE in emit_move_insn with
__builtin_ia32_rdtsc
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
CC: uros at gcc dot gnu.org

Regressed with r192589.

[Bug target/57736] [4.8/4.9 Regression] ICE in emit_move_insn with __builtin_ia32_rdtsc

[amonakov at gcc dot gnu.org]

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

--- Comment #1 from Alexander Monakov  ---
Oops, submitted too soon.

echo 'f(){__builtin_ia32_rdtsc();}' | gcc -xc - -S -o-
: In function ‘f’:
:1:25: internal compiler error: in emit_move_insn, at expr.c:3486
0x6d9c63 emit_move_insn(rtx_def*, rtx_def*)
gcc/expr.c:3485
0xb8063c ix86_expand_builtin
gcc/config/i386/i386.c:31916
0x5ef5ec expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
gcc/builtins.c:5807
0x6d420e expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
gcc/expr.c:10207
0x60e5ab expand_call_stmt
gcc/cfgexpand.c:2119
0x60e5ab expand_gimple_stmt_1
gcc/cfgexpand.c:2157
0x60e5ab expand_gimple_stmt
gcc/cfgexpand.c:2309
0x60f3b3 expand_gimple_basic_block
gcc/cfgexpand.c:4143
0x610f84 gimple_expand_cfg
gcc/cfgexpand.c:4662

[Bug libgomp/57737] New: -fopenmp + -femit-struct-debug-reduced/baseonly = internal compiler error: Segmentation fault

[evgeny.gavrin at hotmail dot com]

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

Bug ID: 57737
   Summary: -fopenmp + -femit-struct-debug-reduced/baseonly =
internal compiler error: Segmentation fault
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: evgeny.gavrin at hotmail dot com
CC: jakub at gcc dot gnu.org

Created attachment 30392
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30392&action=edit
File to reproduce bug

Compilation of debug-1.c file from ./libgomp/testsuite with the following
options: -g -fopenmp -O0 -gdwarf-2 -femit-struct-debug-reduced - causes
segfault in the compiler.

The described bug is actual for GCC versions 4.4, 4.6, 4.7.
Works for -femit-struct-debug-reduced and -femit-struct-debug-baseonly

I've attached both problem example and preprocessed file to the report.

Console logs: 

egavrin@debian:~/dev/vd-issues/report-omp-failtest$ gcc-4.7 -g -fopenmp -O0
-gdwarf-2 -femit-struct-debug-baseonly ./debug-1.c
./debug-1.c: In function ‘f7._omp_fn.0’:
./debug-1.c:136:11: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccWoFu5C.out file, please attach this to
your bugreport.

egavrin@debian:~/dev/vd-issues/report-omp-failtest$ gcc-4.7 -g -fopenmp -O0
-gdwarf-2 -femit-struct-debug-reduced ./debug-1.c
./debug-1.c: In function ‘f7._omp_fn.0’:
./debug-1.c:136:11: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccw1Cilr.out file, please attach this to
your bugreport.

Host system info:
Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2+deb7u2 x86_64 GNU/Linux

[Bug libgomp/57737] -fopenmp + -femit-struct-debug-reduced/baseonly = internal compiler error: Segmentation fault

[evgeny.gavrin at hotmail dot com]

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

--- Comment #1 from Evgeny Gavrin  ---
Created attachment 30393
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30393&action=edit
preprocessed file

[Bug libgomp/57737] -fopenmp + -femit-struct-debug-reduced/baseonly = internal compiler error: Segmentation fault

[evgeny.gavrin at hotmail dot com]

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

--- Comment #2 from Evgeny Gavrin  ---
Created attachment 30394
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30394&action=edit
preprocessed file

[Bug bootstrap/57738] New: gcc-4.8.1 bootstrap gets unrecognized symbol type "gnu_unique_object" (centos6.4)

[karl at freefriends dot org]

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

Bug ID: 57738
   Summary: gcc-4.8.1 bootstrap gets unrecognized symbol type
"gnu_unique_object" (centos6.4)
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: karl at freefriends dot org

I'm trying to compile gcc-4.8.1 from the original source on CentOS 6.4
(32-bit).  I unpacked gcc and mpc-1.0.1, mpfr-3.1.2, gmp-5.1.2 (the latest
released versions of each), made symlinks to the libs, and ran configure from a
sibling directory, like this:

tar xf gcc-4.8.1.tar.bz2 
...
mkdir gccbuild
cd gccbuild
../gcc-4.8.1/configure --prefix=/usr/local/gnu --enable-languages=c,c++,objc
make bootstrap

This went along fine for quite a while, but then aborted with (full command
below; it's just whatever gcc's make does):
g++ -c  -DIN_GCC_FRONTEND -g -DIN_GCC [...] ../../gcc-4.8.1/gcc/cp/except.c
/tmp/ccKcKFPk.s: Assembler messages:
/tmp/ccKcKFPk.s:7332: Error: unrecognized symbol type "gnu_unique_object"
/tmp/ccKcKFPk.s:8051: Error: unrecognized symbol type "gnu_unique_object"
make[3]: *** [cp/except.o] Error 1
make[3]: Leaving directory `/u/local/gnu/src/gccb/gcc'

Looking at the configure output, I see:
  checking assembler for gnu_unique_object... no

So, on the face of it, it seems that cp/except.c shouldn't be trying to use
this feature?

FWIW, /usr/bin/as --version on this system (CentOS 6.4, fully patched) says:
  GNU assembler version 2.20.51.0.2-5.36.el6 20100205

Thanks,
Karl

For the record, here is the full compile line that failed.
g++ -c  -DIN_GCC_FRONTEND -g -DIN_GCC   -fno-exceptions -fno-rtti
-fasynchronou\
s-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual
-Wmissing-format-attribute\
 -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-com\
mon  -DHAVE_CONFIG_H -I. -Icp -I../../gcc-4.8.1/gcc -I../../gcc-4.8.1/gcc/cp
-I\
../../gcc-4.8.1/gcc/../include -I../../gcc-4.8.1/gcc/../libcpp/include
-I/usr/l\
ocal/gnu/src/gccb/./gmp -I/usr/local/gnu/src/gcc-4.8.1/gmp
-I/usr/local/gnu/src\
/gccb/./mpfr/src -I/usr/local/gnu/src/gcc-4.8.1/mpfr/src
-I/usr/local/gnu/src/g\
cc-4.8.1/mpc/src  -I../../gcc-4.8.1/gcc/../libdecnumber
-I../../gcc-4.8.1/gcc/.\
./libdecnumber/bid -I../libdecnumber -I../../gcc-4.8.1/gcc/../libbacktrace   
.\
./../gcc-4.8.1/gcc/cp/except.c -o cp/except.o

[Bug bootstrap/57738] gcc-4.8.1 bootstrap gets unrecognized symbol type "gnu_unique_object" (centos6.4)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
This is a bug in your host's g++ and not the compiling g++
cp/except.c does not use gnu_unique_object directly, g++ does though.

[Bug c++/57739] New: Weaker diagnostics of failed overload resolution when operators are declared as friends instead of externally

[unmobile at gmail dot com]

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

Bug ID: 57739
   Summary: Weaker diagnostics of failed overload resolution when
operators are declared as friends instead of
externally
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unmobile at gmail dot com

Created attachment 30395
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30395&action=edit
Base example of almost-OK error reporting

$ /opt/local/bin/g++-mp-4.9 --version
g++-mp-4.9 (MacPorts gcc49 4.9-20130623_0) 4.9.0 20130623 (experimental)
Copyright (C) 2013 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.

$ /opt/local/bin/g++-mp-4.9 -c puptest.C
puptest.C: In member function 'void SDAG::Closure::packClosure(PUP::er&)':
puptest.C:34:9: error: no match for 'operator|' (operand types are 'PUP::er'
and 'A {aka int}')
   p | continuations;
 ^
puptest.C:34:9: note: candidates are:
puptest.C:24:8: note: void SDAG::operator|(PUP::er&, SDAG::Closure&)
   void operator|(PUP::er &p, Closure &a);
^
puptest.C:24:8: note:   no known conversion for argument 2 from 'A {aka int}'
to 'SDAG::Closure&'
puptest.C:28:8: note: void SDAG::operator|(PUP::er&, SDAG::Closure*&)
   void operator|(PUP::er &p, Closure* &a);
^
puptest.C:28:8: note:   no known conversion for argument 2 from 'A {aka int}'
to 'SDAG::Closure*&'


$ /opt/local/bin/g++-mp-4.9 -c puptest_friend.C
puptest_friend.C: In member function 'void
SDAG::Closure::packClosure(PUP::er&)':
puptest_friend.C:34:9: error: no match for 'operator|' (operand types are
'PUP::er' and 'A {aka int}')
   p | continuations;
 ^

[Bug c++/57739] Weaker diagnostics of failed overload resolution when operators are declared as friends instead of externally

[unmobile at gmail dot com]

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

--- Comment #1 from Phil Miller  ---
Created attachment 30396
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30396&action=edit
Example of completely unhelpful overload resolution

[Bug c++/57739] Weaker diagnostics of failed overload resolution when operators are declared as friends instead of externally

[unmobile at gmail dot com]

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

--- Comment #2 from Phil Miller  ---
I've observed the same behavior as far back as g++ 4.4.3, modulo differences in
column number and caret display.

[Bug target/57736] [4.8/4.9 Regression] ICE in emit_move_insn with __builtin_ia32_rdtsc

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.8.2

[Bug target/57736] [4.8/4.9 Regression] ICE in emit_move_insn with __builtin_ia32_rdtsc

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-06-27
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Created attachment 30397
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30397&action=edit
gcc49-pr57736.patch

Untested fix.  If target == NULL and mode == VOIDmode, then this is a return
value ignored call.  Some of the calls like __builtin_nanq etc. are const and
thus will be optimized away even at -O0 when lhs is missing, but as rdtsc{,p}
and rdpmc aren't const/pure, they are kept.

[Bug target/57224] Remove __builtin_ia32_cmpngtss and __builtin_ia32_cmpngess

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |glisse at gcc dot 
gnu.org

--- Comment #1 from Marc Glisse  ---
r200492 | glisse | 2013-06-27 22:07:32 +0200 (Thu, 27 Jun 2013) | 7 lines

2013-06-27  Marc Glisse  

PR target/57224
* config/i386/i386.c (enum ix86_builtins, bdesc_args): Remove
IX86_BUILTIN_CMPNGTSS and IX86_BUILTIN_CMPNGESS.

[Bug libstdc++/57740] New: C++11 std::thread not usable with static linking

[roland at gnu dot org]

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

Bug ID: 57740
   Summary: C++11 std::thread not usable with static linking
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland at gnu dot org
  Host: x86_64-linux-gnu

Created attachment 30398
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30398&action=edit
test case

This bug goes back at least to 4.6, but I don't really care about anything
older than 4.8.

On x86_64-linux-gnu (and others), the attached test works when compiled with:
g++ -std=c++0x -pthread std_mutex.cc -o std_mutex
but when compiled with:
g++ -std=c++0x -static -pthread std_mutex.cc -o std_mutex
it either throws an error or just crashes.

The underlying problem is excessive use of weak references in gthr-posix.h.

I already have a fix and a testsuite addition in hand and will post them to
gcc-patches soon.

[Bug libstdc++/57740] C++11 std::thread not usable with static linking

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think it is bad form to use static linking with pthreads.

[Bug libstdc++/57740] C++11 std::thread not usable with static linking

[roland at gnu dot org]

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

--- Comment #2 from roland at gnu dot org ---
(In reply to Andrew Pinski from comment #1)
> I think it is bad form to use static linking with pthreads.

Nonsense.  There is code specifically to ensure it works.
The additions for C++11 thread interfaces just didn't do it right.

[Bug tree-optimization/57723] Missed optimization: recursion around empty function

[petschy at gmail dot com]

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

--- Comment #10 from petschy at gmail dot com ---
Thanks for the explanation. The multithreaded argument is sound, but then, on
second thought, even in single threaded programs the state might be altered by
a signal handler, or another process if the memory is shared, so the
optimization might break the program. The bottom line is that the compiler
doesn't have enough information, so it must be conservative, hence the loop
stays in.

Adding a new fn attribute probably wouldn't be enough, since in general there
might be more than one potentially infinite loop inside the fn, with different
semantics, so optimizing all of them away still could be improper. Hence the
attribute should apply to a given loop only ('finite'), but implementing it is
probably too much trouble for this rare case, and the compiler still needs to
eliminate the recursion, too, which might be more complex, eg multiple
functions calling each other in the general case.

For my specific case, I can solve the problem by providing a trait for the
allocator which says 'free() is NOP, so don't bother', then the top level
function can decide what to do, traverse & free or do nothing.

Mikael: could you please provide some info on the ptrace() wizardy you
mentioned, if it's not confidental? I got curious.

Based on the discussion so far, do you think that clang is overly smart in this
case, producing potentially broken code? free_all2() was compiled into a single
ret, and the other two functions lack the recursion, only have the node
traversal of the current level, which seems to be an error to me, because if
there is an infinite loop on one of the levels, the program's behaviour will be
different when compiled with optimizations. If I set n_->down to null before
the recursive call, it generated the expected code, which is interesting, since
then the loop is more likely on the 'finite side'.

Thanks, Peter

[Bug libstdc++/57740] C++11 std::thread not usable with static linking

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
gthr-posix.h uses weakrefs and that is the right thing to do, the APIs are
meant to be used regardless of whether libpthread has been linked in or not.
The only reliable way to statically link libpthread.a from my experience is
what we do in Fedora, i.e. ld -r the whole content of libpthread.a into
libpthread.o and include that only in libpthread.a.  While some libpthread.a
objects have some dependencies, they have just a fraction of the needed ones.

[Bug tree-optimization/57719] [4.8/4.9 Regression] wrong code at -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

--- Comment #2 from Zhendong Su  ---
Hi Jakub, below are three additional (possibly related) testcases that may help
you folks diagnose the issue; they (including the original testcase) all
manifest differently: 

-

test #2: wrong code from both gcc trunk and 4.8 at -O3 in 32-bit mode only: 


int printf (const char *, ...);

int c, e[2], f, g, *l; 
long long h;

int foo ()
{
  int s[1];
  int i = 0;
  for (; i < 1; i++)
s[0] = 0;
  h = 0;
  for (; h; h = 1) { 
int *dp[1] = {&s[0]};
*dp[0] = 0;
  }
  g = 0;
  return 0;
}

void bar ()
{
  for (; c < 2; c++) { 
int *ip = &f;
*ip = 0;
*ip = 0 < foo (); 
l = &e[c];
*ip = 1;
*l = 0;
  }
}

int main ()
{
  bar ();
  printf ("%d\n", f);
  return 0;
}

-

test #3: wrong code from gcc trunk (but not gcc 4.8) at -O3 in 32-bit mode
only: 


int printf (const char *, ...);

int f1;
int a, b, c; 
volatile int d;
int e[2], f, g; 
long long h;
int j, k, *l; 

short fn1 (unsigned short ui1)
{
  return ui1 - a;
}

int fn4 (int p)
{
  int s[1];
  int *tp = &f;
  int *cp = &g;
  int i = 0;
  for (; i < 1; i++)
s[0] = 0;
  h = 0;
  for (; h; h = 1) { 
int *dp[1] = {&s[0]};
*dp[0] = 0;
  }
  *cp = p % (1 ^ *tp);
  return 0;
}

void
fn5 ()
{
  unsigned short t = 0;
  for (; c < 2; c++) { 
int *ip = &f1;
b = 0;
j = 0;
d ^ (*ip = 0); 
t = fn1 (k);
*ip = e[0] < fn4 (t);
l = &e[c];
*ip = 1;
*l = 0;
  }
}

int
main ()
{
  fn5 ();
  printf ("%d\n", f1);
  return 0;
}

-

test #4: wrong code from gcc trunk (but not gcc 4.8) at -O3 in both 32-bit and
64-bit modes: 


int printf (const char *, ...);

int a;
int b;
int c;
volatile int d;
int e; 
int f[2];
int g;
int h;
int j;
int *k = &f[0];
int l;

short
fn1 (unsigned short p)
{
  return p * a;
}

int
fn2 (int p)
{
  int m[1];
  int i = 0;
  for (; i < 1; i++)
m[0] = 0;
  g = 0; 
  for (; g; g = 1) {
int *n[1] = {&m[0]};
  }
  l = p % (1 ^ *k);
  return 0;
}

int
main ()
{
  unsigned short o = 0;
  int *p;
  for (; c < 2; c++) {
int *q = &e;
b = 0;
h = 0;
d ^ (*q = 0);
o = fn1 (j);
*q = f[0] < fn2 (o);
p = &f[c];
*q = 1;
fn2 (0);
*p = 0;
  }
  printf ("%d\n", e);
  return 0;
}

[Bug libstdc++/57740] C++11 std::thread not usable with static linking

[roland at gnu dot org]

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

--- Comment #4 from roland at gnu dot org ---
weakrefs are right for the conditional cases.

For the functions that underlie std::thread et al, it can never be meaningful
to use those interfaces and fail to link with -lpthread.

The Fedora hack just masks bugs like this one.  It's not the right thing to do
at all.  The right thing is to fix the bugs.  I have a fix, demonstrating it's
certainly not impossible.

[Bug libstdc++/57740] C++11 std::thread not usable with static linking

[roland at gnu dot org]

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

--- Comment #5 from roland at gnu dot org ---
So my draft fix actually breaks the dynamic case.  For the unconditional calls,
weak is right in the shared library but strong is right in the static library.
But unlike normal libraries, libstdc++ goes out of its way to get compiled only
once, using PIC-compiled objects in the static library too.  So there is no
obvious way for gthr-posix.h to behave differently in the static and shared
cases, which is the only correct thing for it to do.

[Bug libstdc++/57740] C++11 std::thread not usable with static linking

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Note also that libstdc++.a can be used together with libpthread.so or
libstdc++.so with libpthread.a (g++ -static-libstdc++ etc.).

[Bug tree-optimization/57741] New: ICE in tree.c:build_int_cst_wide starting in revision 200394

[pthaugen at gcc dot gnu.org]

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

Bug ID: 57741
   Summary: ICE in tree.c:build_int_cst_wide starting in revision
200394
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, jakub at gcc dot gnu.org
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux

Created attachment 30399
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30399&action=edit
Reduced testcase

CPU2000 benchmarks mesa and apsi fail to build starting with r200394. Reduced
testcase from mesa attatched.

[pthaugen@igoo delta]$ ~/install/gcc/trunk/bin/gcc -c -O3 -mcpu=power7 -m64
-funroll-loops triangle.c 
triangle.c: In function 'general_textured_triangle':
triangle.c:339:1: internal compiler error: in build_int_cst_wide, at
tree.c:1214
 general_textured_triangle (GLcontext * ctx, GLuint v0, GLuint v1, GLuint v2,
 ^
0x1086129f build_int_cst_wide(tree_node*, unsigned long, long)
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree.c:1214
0x10861837 double_int_to_tree(tree_node*, double_int)
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree.c:1068
0x1081488b get_initial_def_for_induction
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-loop.c:3279
0x1081488b vectorizable_induction(gimple_statement_d*, gimple_stmt_iterator_d*,
gimple_statement_d**)
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-loop.c:5351
0x1080cb97 vect_transform_stmt(gimple_statement_d*, gimple_stmt_iterator_d*,
bool*, _slp_tree*, _slp_instance*)
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-stmts.c:5784
0x10811c9f vect_transform_loop(_loop_vec_info*)
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-loop.c:5602
0x108346d7 vectorize_loops()
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vectorizer.c:123
0x10747443 tree_vectorize
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa-loop.c:222
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug libstdc++/57740] C++11 std::thread not usable with static linking

[roland at gnu dot org]

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

--- Comment #7 from roland at gnu dot org ---
(In reply to Jakub Jelinek from comment #6)
> Note also that libstdc++.a can be used together with libpthread.so or
> libstdc++.so with libpthread.a (g++ -static-libstdc++ etc.).

If libstdc++.a had strong references, it would work fine with libpthread.so
too.
That is the case that IMHO actually matters (-static-libstdc++ is important to
avoid DSO dependencies specific to the GCC version, which varies across
installations in incompatible ways far more than libc/libpthread versions).

libstdc++.so's weak references can never work with libpthread.a unless there
are other strong references elsewhere in the link.  But I'm hard-pressed to
think of a scenario in which someone actually wants libstdc++.so with
libpthread.a.

[Bug c++/57509] Segmentation fault when using __builtin_shuffle in templated class.

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Marc Glisse  ---
r200495 | glisse | 2013-06-27 23:29:22 +0200 (Thu, 27 Jun 2013) | 20 lines

2013-06-27  Marc Glisse  

PR c++/57509

gcc/c-family/
* c-common.h (c_build_vec_perm_expr): New complain argument.
* c-common.c (c_build_vec_perm_expr): Likewise.
Use save_expr also in C++.

gcc/cp/
* typeck.c (cp_build_vec_perm_expr): New function.
* cp-tree.h: Declare it.
* parser.c (cp_parser_postfix_expression): Call it.
* pt.c (tsubst_copy): Handle VEC_PERM_EXPR.
(tsubst_copy_and_build): Likewise.

gcc/testsuite/
* g++.dg/ext/pr57509.C: New file.

[Bug fortran/57456] [OOP] CLASS + CHARACTER ALLOCATE with typespec: For arrays, the typespec is ignored

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-06-27
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Is not this PR supposed to have been fixed (partially) by revision 199528?

Revision 199528

Author:burnus
Date:Fri May 31 09:41:53 2013 UTC (3 weeks, 6 days ago)
Changed paths:6
Log Message:
2013-05-31  Tobias Burnus  

PR fortran/57456
* trans-array.c (gfc_array_init_size): Use passed type spec,
when available.
(gfc_array_allocate): Pass typespec on.
* trans-array.h (gfc_array_allocate): Update prototype.
* trans-stmt.c (gfc_trans_allocate): Pass typespec on.

2013-05-31  Tobias Burnus  

PR fortran/57456
* gfortran.dg/class_array_17.f90: New.

Note that the problem in comment #2 is still there at revision 200486.

[Bug fortran/57456] [OOP] CLASS + CHARACTER ALLOCATE with typespec: For arrays, the typespec is ignored

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #4 from Tobias Burnus  ---
(In reply to Dominique d'Humieres from comment #3)
> Is not this PR supposed to have been fixed (partially) by revision 199528?

Yes. The patch fixes the derived-type issue - but it doesn't solve the
CHARACTER issue. As written in comment 2, the proper way is use one common code
in gfc_trans_allocate, which calculates the byte size, and use it both for
scalars (directly in gfc_trans_allocate) and for arrays in gfc_array_allocate
-> gfc_array_init_size. (One also should evaluate the LEN= expression only
once.)

[Bug fortran/56596] Invalid read of size 4 gfortran.dg/class_array_7.f03

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
This seems to have been fixed between revision 199435 (2013-05-30) and revision
199885 (2013-06-03): revision 199528?

The error

==15298== 80 bytes in 1 blocks are definitely lost in loss record 1 of 2
==15298==at 0x100013679: malloc (vg_replace_malloc.c:266)
==15298==by 0x11358: __realloc_MOD_reallocate (class_array_7.f03:31)
==15298==by 0x119C6: MAIN__ (class_array_7.f03:55)
==15298==by 0x11B5B: main (class_array_7.f03:49)

appeared between revisions 200350 (2013-06-23) with the patch of revision
200361 and a clean revision 200361 (2013-06-24). Could it be caused by revision
200360?

[Bug libstdc++/57740] C++11 std::thread not usable with static linking

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to roland from comment #7)
> -static-libstdc++ is important
> to avoid DSO dependencies specific to the GCC version, which varies across
> installations in incompatible ways far more than libc/libpthread versions).

No it does not.  Or rather there have not been an ABI change in libstdc++ since
3.4.  If you compile with the oldest distro you support, it should work across
all distros just fine.  Just C++11 support was not part of most older distros
because they came out before 2011 :).

[Bug tree-optimization/57741] ICE in tree.c:build_int_cst_wide starting in revision 200394

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-06-27
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 30400
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30400&action=edit
gcc49-pr57741.patch

Untested fix.

[Bug libstdc++/57740] C++11 std::thread not usable with static linking

[roland at gnu dot org]

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

--- Comment #9 from roland at gnu dot org ---
(In reply to Andrew Pinski from comment #8)
> (In reply to roland from comment #7)
> > -static-libstdc++ is important
> > to avoid DSO dependencies specific to the GCC version, which varies across
> > installations in incompatible ways far more than libc/libpthread versions).
> 
> No it does not.  Or rather there have not been an ABI change in libstdc++
> since 3.4.  If you compile with the oldest distro you support, it should
> work across all distros just fine.  Just C++11 support was not part of most
> older distros because they came out before 2011 :).

I think I've run into actual problems of this nature.  Perhaps it was with 3.4
or earlier, or perhaps I'm misremembering.  The only specific scenario I can
recall at the moment might not have been a version skew issue, but rather the
need to have libstdc++.so.N at runtime at all.

[Bug tree-optimization/57742] New: memset(malloc(n),0,n) -> calloc(n,1)

[glisse at gcc dot gnu.org]

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

Bug ID: 57742
   Summary: memset(malloc(n),0,n) -> calloc(n,1)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org

Hello,

calloc can sometimes be significantly faster than malloc+bzero because it has
special knowledge that some memory is already zero. When other optimizations
simplify some code to malloc+memset(0), it would thus be nice to replace it
with calloc. Sadly, I don't think there is a way to do a similar optimization
in C++ with new, which is where such code most easily appears (creating
std::vector(1) for instance). And there would also be the complication
there that the size of the memset would be a bit smaller than that of the
malloc (using calloc would still be fine, but it gets harder to know if it is
an improvement).

[Bug c++/57743] New: Code accepted by other recent compilers, but not by g++ - possibly failure to activate ADL

[unmobile at gmail dot com]

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

Bug ID: 57743
   Summary: Code accepted by other recent compilers, but not by
g++ - possibly failure to activate ADL
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unmobile at gmail dot com

Created attachment 30401
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30401&action=edit
Reduced test case

$ g++ --version
g++ (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3

$ g++ -c puptest0.C
puptest0.C: In member function ‘void SDAG::Closure::packClosure(PUP::er&)’:
puptest0.C:27: error: no match for ‘operator|’ in ‘p |
((SDAG::Closure*)this)->SDAG::Closure::continuations’

Tested with 4.8 and snapshots of 4.9, and all they add to that output (appears
in at least 4.3, 4.4, and 4.6) is column numbering and caret marking of that
exact spot.
(g++-mp-4.9 --version gives "g++-mp-4.9 (MacPorts gcc49 4.9-20130623_0) 4.9.0
20130623 (experimental)")

Reduced test case attached. Defining either of the tested macros lets the code
compile. Commenting either of the friend declarations also lets the code
compile. Moving the friend declarations out of the structure definition (and
making them non-friend) lets the code compile.

The code in question is accepted by clang of various versions including 3.3,
IBM XL C++ 12.01, Intel C++ versions 12.1.5.339 and 13.1 (but rejected by 11.1
with a similar error), and PGI C++ from 11.0 through 13.3.

MSVC++ v16 rejects it (not sure what year that's from). Cray's compiler v8 also
rejects it, again similarly.

The rejections from other compilers, and g++'s own when I vary conditions (cf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57739) might be enlightening. Intel
11.1 and Cray v8 provide no additional information, while MS VC++ is similar to
the related case output:

puptest0.C(27) : error C2679: binary '|' : no operator found which takes a
right-hand operand of type 'A' (or there is no acceptable conversion)
puptest0.C(24): could be 'void SDAG::operator |(PUP::er &,SDAG::Closure
&)'
puptest0.C(25): or   'void SDAG::operator |(PUP::er &,SDAG::Closure
*&)'
while trying to match the argument list '(PUP::er, A)'

Going by the fact that where versions differ, the later version accepts, I
believe that there is a bug in g++ rejecting this code. It seems like any
little tweak lets the compiler apply argument dependent lookup and resolve the
operator successfully, but I don't know why it isn't already.

[Bug tree-optimization/57741] ICE in tree.c:build_int_cst_wide starting in revision 200394

[pthaugen at gcc dot gnu.org]

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

--- Comment #2 from Pat Haugen  ---
Created attachment 30402
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30402&action=edit
full .i file

The proposed patch fixes the error for the reduced testcase and also fixes the
problem for the apsi benchmark, but mesa still hits the same error. Attatching
full .i file. Note that -ffast-math is also needed to reproduce this error.


[pthaugen@igoo 0004]$ /home/pthaugen/install/gcc/trunk/bin/gcc -c -m64 -O3
-mcpu=power7 -funroll-loops -ffast-math triangle.i
triangle.c: In function 'general_textured_triangle':
triangle.c:471:13: internal compiler error: in build_int_cst_wide, at
tree.c:1214
 static void general_textured_triangle( GLcontext *ctx, GLuint v0, GLuint v1,
 ^
0x1086156f build_int_cst_wide(tree_node*, unsigned long, long)
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree.c:1214
0x10861b07 double_int_to_tree(tree_node*, double_int)
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree.c:1068
0x1081405b get_initial_def_for_induction
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-loop.c:3353
0x1081405b vectorizable_induction(gimple_statement_d*, gimple_stmt_iterator_d*,
gimple_statement_d**)
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-loop.c:5362
0x1080cd27 vect_transform_stmt(gimple_statement_d*, gimple_stmt_iterator_d*,
bool*, _slp_tree*, _slp_instance*)
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-stmts.c:5784
0x10811f1f vect_transform_loop(_loop_vec_info*)
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-loop.c:5613
0x108349a7 vectorize_loops()
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vectorizer.c:123
0x107475c3 tree_vectorize
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa-loop.c:222

[Bug c++/57743] Code accepted by other recent compilers, but not by g++ - possibly failure to activate ADL

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Note int does not have an associated namespace which is the issue here.  There
is a defect report against the C++ standard about that.

[Bug target/57744] New: Power8 support has problems with quad word atomic instructions

[meissner at gcc dot gnu.org]

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

Bug ID: 57744
   Summary: Power8 support has problems with quad word atomic
instructions
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org

The lqarx and stqcx. instructions will sometimes generate code using an
odd/even register combination.  The assembler complains about this, since only
even/odd registers can be used.

This is due to the atomic support for quad using PTImode to force allocation of
an even/odd register pair.  However, since MODES_TIEABLE_P(PTImode, TImode)
returns 1, the compiler felt it could tie together the value originally in a
TImode register with the PTImode register, and an odd/even TImode had already
been allocated.

In looking at MODES_TIEABLE_P, I feel that small integer modes (QImode, HImode,
SImode) should not be tied with larger modes like DImode, since DImode can go
in floating point registers, but SImode can't.

[Bug c++/57745] New: missing recursive lifetime extension within std::initializer_list

[richard-gccbugzilla at metafoo dot co.uk]

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

Bug ID: 57745
   Summary: missing recursive lifetime extension within
std::initializer_list
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk

Consider:

#include 
struct A {
   A() { std::cout << " A()" << std::endl; }
  ~A() { std::cout << "~A()" << std::endl; }
};
struct B {
  const A &a;
  ~B() { std::cout << "~B()" << std::endl; }
};
struct C {
  std::initializer_list b;
  ~C() { std::cout << "~C()" << std::endl; }
};
int main() {
  const C &c = C{ { { A() }, { A() } } };
  std::cout << "-" << std::endl;
}

This should print:

 A()
 A()
-
~C()
~B()
~A()
~B()
~A()

... but g++ destroys the two A temporaries at the end of the full-expression.
They are lifetime-extended because they are bound to B::a references in the
aggregate-initialization of the B subobjects of the underlying array of the
initializer_list, which is itself lifetime-extended.

[Bug target/57744] Power8 support has problems with quad word atomic instructions

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-06-27
 Ever confirmed|0   |1

[Bug target/57744] Power8 support has problems with quad word atomic instructions

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 30403
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30403&action=edit
Program to show the bug

Compile with -O3 -mcpu=power8 -c -save-temps to make sure the assembler tries
to assemble the file.

[Bug target/57744] Power8 support has problems with quad word atomic instructions

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Created attachment 30404
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30404&action=edit
Proposed patch to fix problem

[Bug libstdc++/57740] C++11 std::thread not usable with static linking

[joseph at codesourcery dot com]

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

--- Comment #10 from joseph at codesourcery dot com  ---
On Thu, 27 Jun 2013, pinskia at gcc dot gnu.org wrote:

> No it does not.  Or rather there have not been an ABI change in libstdc++ 
> since
> 3.4.  If you compile with the oldest distro you support, it should work across
> all distros just fine.  Just C++11 support was not part of most older distros
> because they came out before 2011 :).

Compiling with a (newer) cross compiler built with a sysroot from the old 
distro has various advantages over actually trying to build directly on 
the old distro - but you do then need to use -static-libstdc++ 
-static-libgcc to avoid depending on newer shared libraries.  (Actually, a 
sysroot just containing the old glibc libraries, with all other libraries 
linked in statically, seems to work better in my experience than a 
complete old-distro sysroot with old versions of lots of libraries; there 
are lots of ways an old library can cause problems for building new 
software where complete absence of that library is detected at configure 
time and doesn't cause problems.)

In theory this (building widely portable binaries) is what LSB toolchains 
are for, but I don't think they are widely used.

[Bug c++/57745] missing recursive lifetime extension within std::initializer_list

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  ---
First blush seems related to PR54293, but I didn't study the latter seriously
enough.

[Bug c++/57746] New: rejected valid specialization of member function of class template (I think)

[luto at mit dot edu]

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

Bug ID: 57746
   Summary: rejected valid specialization of member function of
class template (I think)
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luto at mit dot edu

Note: I could easily be wrong here...

template
struct X
{
  static int val;
  static void func();
};

extern template struct X;

template<> int X::val = 5;  // OK
template<> void X::func() {}  // Error

g++ 4.7.2 and some pre-4.8 build say "error: specialization of ‘static void
X::func() [with T = int]’ after instantiation".  Oddly, both accept the
specialization of val.  clang++ rejects both.

The relevant part of the standard is probably [temp.explicit.4], which says:

A declaration of a function template, a member function or static data member
of a class template, or a member function template of a class or class template
shall precede an explicit instantiation of that entity. A definition of a class
template, a member class of a class template, or a member class template of a
class or class template shall precede an explicit instantiation of that entity
unless the explicit instantiation is preceded by an explicit specialization of
the entity with the same template arguments. If the declaration of the explicit
instantiation names an implicitly-declared special member function (Clause 12),
the program is ill-formed.

The two specializations are definitions, not declarations, as far as I know. 
Therefore, [temp.explicit.4] shouldn't apply.

[Bug c++/57747] New: The progress indicator always shows 38%

[dscott at hmc dot edu]

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

Bug ID: 57747
   Summary: The progress indicator always shows 38%
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dscott at hmc dot edu

We had a large project which repeatedly hit a compiler or linker error at 38%. 
The build is managed by CMake, and worked correctly before we introduced the
bugs that caused the aforementioned compiler/linker errors.  We finally fixed
the bugs in our code, then re-ran CMake (clearing its cache), ran make clean,
and then ran make.  We were very confused to see the progress indicator always
read 38%.  We terminated compilation and did another make clean.  We then
allowed make to run all the way through --- and the build ran successfully from
start to finish.  However, at every single step along the way, the progress was
reported as 38%.

[Bug c++/57747] The progress indicator always shows 38%

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Manuel López-Ibáñez  ---
GCC does not print any progress indicator, so it sounds like a CMake bug: 

http://www.cmake.org/Wiki/CMake_FAQ#I_found_a_Bug.21_What_should_I_do.3F

[Bug target/57717] error: unrecognizable insn compiling ./strtod_l.c from glibc on powerpc-gnuspe

[raj.khem at gmail dot com]

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

--- Comment #4 from Khem Raj  ---
I have backported this fix to 4.8 branch and tested it and it fixed the issue.
Below is the patch for 4.8


Index: gcc-4.8.1/gcc/config/rs6000/rs6000.c
===
--- gcc-4.8.1.orig/gcc/config/rs6000/rs6000.c   2013-05-09 18:54:06.0
-0700
+++ gcc-4.8.1/gcc/config/rs6000/rs6000.c2013-06-27 08:22:40.459021366
-0700
@@ -5431,11 +5431,12 @@

 case TFmode:
 case TDmode:
-case TImode:
   if (TARGET_E500_DOUBLE)
return (SPE_CONST_OFFSET_OK (offset)
&& SPE_CONST_OFFSET_OK (offset + 8));
+/* Fall through.  */

+case TImode:
   extra = 8;
   if (!worst_case)
break;

[Bug target/57748] New: ICE on ARM with -mfloat-abi=softfp -mfpu=neo

[raj.khem at gmail dot com]

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

Bug ID: 57748
   Summary: ICE on ARM with -mfloat-abi=softfp -mfpu=neo
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raj.khem at gmail dot com

Created attachment 30405
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30405&action=edit
testcase

Attached testcase causes and ICE on gcc 4.8+ and happens on trunk too. It works
ok on 4.7

./gcc/cc1 ~/callchain.i -mfpu=neon -Os -mfloat-abi=softfp


util/callchain.c: In function 'append_chain':
util/callchain.c:374:18: internal compiler error: in expand_assignment, at
expr.c:4676
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/57748] ICE on ARM with -mfloat-abi=softfp -mfpu=neo

[raj.khem at gmail dot com]

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

Khem Raj  changed:

   What|Removed |Added

 Target||arm-none-linux-gnueabi
  Build||x86_64-linux

--- Comment #1 from Khem Raj  ---
Here is how compiler is configured

configure --build=x86_64-linux --host=x86_64-linux
--target=arm-none-linux-gnueabi
--prefix=/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/x86_64-linux/usr
--exec_prefix=/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/x86_64-linux/usr
--bindir=/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/x86_64-linux/usr/bin/ppce500v2-angstrom-linux-gnuspe.gcc-cross-initial
--sbindir=/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/x86_64-linux/usr/bin/ppce500v2-angstrom-linux-gnuspe.gcc-cross-initial
--libexecdir=/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/x86_64-linux/usr/libexec/ppce500v2-angstrom-linux-gnuspe.gcc-cross-initial
--datadir=/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/x86_64-linux/usr/share
--sysconfdir=/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/x86_64-linux/etc
--sharedstatedir=/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/x86_64-linux/com
--localstatedir=/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/x86_64-linux/var
--libdir=/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/x86_64-linux/usr/lib/ppce500v2-angstrom-linux-gnuspe.gcc-cross-initial
--includedir=/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/x86_64-linux/usr/include
--oldincludedir=/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/x86_64-linux/usr/include
--infodir=/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/x86_64-linux/usr/share/info
--mandir=/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/x86_64-linux/usr/share/man
--disable-silent-rules --disable-dependency-tracking
--with-libtool-sysroot=/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/x86_64-linux
--with-newlib --without-headers --disable-shared --disable-threads
--disable-multilib --disable-__cxa_atexit --enable-languages=c
--program-prefix=powerpc-angstrom-linux-gnuspe-
--with-sysroot=/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/p2020ds
--with-build-sysroot=/builds1/angstrom/build/tmp-angstrom_next-eglibc/work/ppce500v2-angstrom-linux-gnuspe/gcc-cross-initial/4.8.1-r0/gcc-4.8.1/build.x86_64-linux.powerpc-angstrom-linux-gnuspe/tmpsysroot
--disable-libmudflap --disable-libgomp --disable-libssp --disable-libquadmath
--with-system-zlib --disable-lto --disable-plugin --enable-decimal-float=no
--disable-nls

[Bug target/57748] ICE on ARM with -mfloat-abi=softfp -mfpu=neo

[raj.khem at gmail dot com]

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

Khem Raj  changed:

   What|Removed |Added

 CC||mjambor at suse dot cz

--- Comment #2 from Khem Raj  ---
I have traced it to this commit r187101

2012-05-03  Martin Jambor  

* builtins.c (get_object_alignment_1): Return whether we can determine
the alignment or conservatively assume byte alignment.  Return the
alignment by reference.  Use get_pointer_alignment_1 for dereference
alignment.
(get_pointer_alignment_1): Return whether we can determine the
alignment or conservatively assume byte alignment.  Return the
alignment by reference.  Use get_ptr_info_alignment to get SSA name
alignment.
(get_object_alignment): Update call to get_object_alignment_1.
(get_object_or_type_alignment): Likewise, fall back to type alignment
only when it returned false.
(get_pointer_alignment): Update call to get_pointer_alignment_1.
* fold-const.c (get_pointer_modulus_and_residue): Update call to
get_object_alignment_1.
* ipa-prop.c (ipa_modify_call_arguments): Update call to
get_pointer_alignment_1.
* tree-sra.c (build_ref_for_offset): Likewise, fall back to the type
of MEM_REF or TARGET_MEM_REF only when it returns false.
* tree-ssa-ccp.c (get_value_from_alignment): Update call to
get_object_alignment_1.
(ccp_finalize): Use set_ptr_info_alignment.
* tree.h (get_object_alignment_1): Update declaration.
(get_pointer_alignment_1): Likewise.
* gimple-pretty-print.c (dump_gimple_phi): Use get_ptr_info_alignment.
(dump_gimple_stmt): Likewise.
* tree-flow.h (ptr_info_def): Updated comments of fields align and
misalign.
(get_ptr_info_alignment): Declared.
(mark_ptr_info_alignment_unknown): Likewise.
(set_ptr_info_alignment): Likewise.
(adjust_ptr_info_misalignment): Likewise.
* tree-ssa-address.c (copy_ref_info): Use new access functions to get
and set alignment of SSA names.
* tree-ssa-loop-ivopts.c (rewrite_use_nonlinear_expr): Call
mark_ptr_info_alignment_unknown.
* tree-ssanames.c (get_ptr_info_alignment): New function.
(mark_ptr_info_alignment_unknown): Likewise.
(set_ptr_info_alignment): Likewise.
(adjust_ptr_info_misalignment): Likewise.
(get_ptr_info): Call mark_ptr_info_alignment_unknown.
* tree-vect-data-refs.c (vect_create_addr_base_for_vector_ref):
Likewise.
(bump_vector_ptr): Likewise.
* tree-vect-stmts.c (create_array_ref): Use set_ptr_info_alignment.
(vectorizable_store): Likewise.
(vectorizable_load): Likewise.