[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost

[markus at trippelsdorf dot de]

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

--- Comment #3 from Markus Trippelsdorf  
2012-07-08 07:08:13 UTC ---
Unfortunately jimis' patch from Bug 53525 doesn't help much:

c++ -c -o pch.hpp.gch /usr/include/boost/math/special_functions.hpp  156.69s
user 0.33s system 99% cpu 2:37.50 total

From "perf top":

 99.78%  cc1plus   [.] gt_pch_p_9line_maps
  0.04%  cc1plus   [.] htab_find_with_hash
  0.02%  cc1plus   [.] gt_pch_p_14lang_tree_node
  0.02%  libc-2.16.so  [.] fwrite_unlocked   ▒
  0.01%  libc-2.16.so  [.] __mempcpy
  0.01%  [kernel]  [k] do_timer 

Zoom into gt_pch_p_9line_maps:

   │ size_t l3 = (size_t)(((*x).info_macro).used);
   │ if ((*x).info_macro.maps != NULL) {
   │   size_t i3;
   │   for (i3 = 0; i3 != (size_t)(l3); i3++) {
  3.89 │109:   cmp%rcx,%rbx
  3.69 │   nop
  3.15 │ ↓ je 188
  3.11 │112:   mov0x18(%rbp),%rax
  3.04 │   add$0x1,%rbx
   │   break;
   │ }
   │ }
   │
   │ void
   │ gt_pch_p_9line_maps (ATTRIBUTE_UNUSED void *this_obj,
  2.76 │11a:   lea(%rbx,%rbx,4),%r15
  3.53 │   shl$0x3,%r15
   │   {
   │ size_t l3 = (size_t)(((*x).info_macro).used);
   │ if ((*x).info_macro.maps != NULL) {
   │   size_t i3;
   │   for (i3 = 0; i3 != (size_t)(l3); i3++) {
   │ switch (((*x).info_macro.maps[i3]).reason ==
LC_ENTER_MACRO)
  3.46 │   lea(%rax,%r15,1),%rdi
  3.42 │   cmpb   $0x4,0x4(%rdi)
  4.40 │ ↑ jne100
   │   case 1:
   │ {
   │   size_t l4 = (size_t)(2 *
((*x).info_macro.maps[i3].d.macro).n_tokens);
   │   {
   │ union tree_node * x5 =
   │   ((*x).info_macro.maps[i3].d.macro.macro) ?
HT_IDENT_TO_GCC_IDENT (HT_NODE (((*x).info_macro.maps[i3].d.macro.macro)))
  4.38 │   mov0x8(%rdi),%rsi
  4.25 │   xor%edx,%edx
  2.22 │   lea-0x18(%rsi),%r8
  2.16 │   test   %rsi,%rsi
  2.68 │   cmovne %r8,%rdx
   │ if ((void *)((*x).info_macro.maps) == this_obj)
  2.72 │   cmp%rax,%r14
   │ break;
   │   case 1:
   │ {
   │   size_t l4 = (size_t)(2 *
((*x).info_macro.maps[i3].d.macro).n_tokens);
   │   {
   │ union tree_node * x5 =
  2.62 │   mov%rdx,0x18(%rsp)
   │   ((*x).info_macro.maps[i3].d.macro.macro) ?
HT_IDENT_TO_GCC_IDENT (HT_NODE (((*x).info_macro.maps[i3].d.macro.macro)))
   │ if ((void *)((*x).info_macro.maps) == this_obj)
  2.68 │ ↓ je 1a0
   │   op (&(x5), cookie);
   │ (*x).info_macro.maps[i3].d.macro.macro = (x5) ?
CPP_HASHNODE (GCC_IDENT_TO_HT_IDENT ((x5))) : NULL;
  2.68 │147:   lea0x18(%rdx),%rsi
  2.85 │   xor%eax,%eax
  3.39 │   test   %rdx,%rdx
  3.11 │   cmovne %rsi,%rax
  3.23 │   mov%rax,0x8(%rdi)
   │   }
   │   if ((*x).info_macro.maps[i3].d.macro.macro_locations
!= NULL) {
  5.10 │   mov0x18(%rbp),%rax
  4.93 │   add%rax,%r15
  5.48 │   cmpq   $0x0,0x18(%r15)
  3.57 │ ↑ je 109
   │ size_t i4;
   │ for (i4 = 0; i4 != (size_t)(l4); i4++) {
   │ }
   │ if ((void *)((*x).info_macro.maps) == this_obj)
  3.20 │   cmp%rax,%r14
  2.82 │ ↑ jne109
   │   op
(&((*x).info_macro.maps[i3].d.macro.macro_locations), cookie);
   │   mov%rcx,0x8(%rsp)
   │   lea0x18(%r15),%rdi
   │   mov%r13,%rsi
   │ → callq  *%r12
   │   mov0x8(%rsp),%rcx
   │   }

[Bug libfortran/49970] "make prefix=... install" doesn't work

[joseph at codesourcery dot com]

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

--- Comment #9 from joseph at codesourcery dot com  2012-07-08 08:20:02 UTC ---
I don't know where the libtool bug tracker is, though I presume it has 
one.

[Bug libfortran/49970] "make prefix=... install" doesn't work

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

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

--- Comment #10 from Andreas Schwab  2012-07-08 08:26:03 
UTC ---
bug-libt...@gnu.org

[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets

[jimis at gmx dot net]

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

--- Comment #23 from jimis  2012-07-08 10:02:14 UTC ---
Iain, ro: Do you know of some darwin or solaris i386 machine where I can test
some changes to this patch? 

Does the bug mentioned in comment #15 and comment #16 needs special configure
flags? Maybe I can reproduce it on x86 somehow? (how to build 64-bit multilib
on 32 bit host?)

[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets

[iains at gcc dot gnu.org]

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

--- Comment #24 from Iain Sandoe  2012-07-08 10:24:45 
UTC ---
(In reply to comment #23)
> Iain, ro: Do you know of some darwin or solaris i386 machine where I can test
> some changes to this patch? 
> 
> Does the bug mentioned in comment #15 and comment #16 needs special configure
> flags? Maybe I can reproduce it on x86 somehow? (how to build 64-bit multilib
> on 32 bit host?)

If you want a patch testing - then I'm sure that Dominique, me or Jack can test
on Darwin.  Unfortunately, I am not in a position to give remote access to my
Darwin boxen.

[Bug libfortran/49970] "make prefix=... install" doesn't work

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|VERIFIED|RESOLVED

--- Comment #11 from Jonathan Wakely  2012-07-08 
11:04:57 UTC ---
(In reply to comment #5)
> DESTDIR is supported just fine, but it is not prefix, it serves different
> purposes. In particular it installs in /$DESTDIR/$prefix but installed package
> would search libraries in /$prefix. 

It should search for everything using relative paths, i.e. relative to wherever
you install it, so DESTDIR should work.

[Bug c++/53892] New: Invalid "duplicate case value" for C++11 utf-16 char literals

[arnetheduck at gmail dot com]

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

 Bug #: 53892
   Summary: Invalid "duplicate case value" for C++11 utf-16 char
literals
Classification: Unclassified
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arnethed...@gmail.com


In the following C++ function:

void f(char16_t c) {
switch(c) {
case u'\u':
case u'\u0001':
break;
}
}

G++, when invoked with "g++ -std=gnu++11 test.cpp" gives the following
unexpected error message:

test.cpp: In function ‘void f(char16_t)’:
test.cpp:5:5: error: duplicate case value
test.cpp:4:5: error: previously used here

Lines 4 & 5 are the two case values. 

Changing either of the values to u'\u0002' makes the code compile correctly.

[Bug c++/53893] New: segfault with invalid c++ code

[pipping at exherbo dot org]

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

 Bug #: 53893
   Summary: segfault with invalid c++ code
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pipp...@exherbo.org


The following piece of invalid C++0x code yields

nannormtest.ii: In member function ‘double std::DenseVector::infinity_norm()
const’:
nannormtest.ii:8:80: internal compiler error: Segmentation fault

[Bug c++/53893] segfault with invalid c++ code

[pipping at exherbo dot org]

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

--- Comment #1 from Elias Pipping  2012-07-08 
11:21:57 UTC ---
Created attachment 27762
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27762
test case

[Bug target/53886] Seg fault in sh_insn_length_adjustment

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #1 from Oleg Endo  2012-07-08 11:33:19 
UTC ---
Ryan, could you please provide the (reduced) source file in question so that we
could add this as a test case to the test suite?

[Bug target/53886] Seg fault in sh_insn_length_adjustment

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu.org

--- Comment #2 from Oleg Endo  2012-07-08 11:40:56 
UTC ---
I'm just guessing here, but this line

&& GET_CODE (PATTERN (NEXT_INSN (PREV_INSN (insn != SEQUENCE

looks suspicious.  Most likely it's a nullptr access.
In sparc.c something similar is being done by the function
'int empty_delay_slot (rtx insn)'

Maybe the patch below could be a fix for the problem?
There are actually more places in sh.c where the usage of NEXT_INSN (PREV_INSN
(insn)) goes unchecked...

Kaz, what do you think?  Does this make any sense?


Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c(revision 189339)
+++ gcc/config/sh/sh.c(working copy)
@@ -9652,6 +9652,15 @@
 #define IS_ASM_LOGICAL_LINE_SEPARATOR(C, STR) ((C) == ';')
 #endif

+static bool
+sequence_insn_p (rtx insn)
+{
+  if (PREV_INSN (insn) == NULL)
+return false;
+
+  return GET_CODE (PATTERN (NEXT_INSN (PREV_INSN (insn == SEQUENCE;
+}
+
 int
 sh_insn_length_adjustment (rtx insn)
 {
@@ -9662,7 +9671,7 @@
 && GET_CODE (PATTERN (insn)) != CLOBBER)
|| CALL_P (insn)
|| (JUMP_P (insn) && !JUMP_TABLE_DATA_P (insn)))
-  && GET_CODE (PATTERN (NEXT_INSN (PREV_INSN (insn != SEQUENCE
+  && ! sequence_insn_p (insn)
   && get_attr_needs_delay_slot (insn) == NEEDS_DELAY_SLOT_YES)
 return 2;

@@ -9671,7 +9680,7 @@
   if (sh_cpu_attr == CPU_SH2E
   && JUMP_P (insn) && !JUMP_TABLE_DATA_P (insn)
   && get_attr_type (insn) == TYPE_CBRANCH
-  && GET_CODE (PATTERN (NEXT_INSN (PREV_INSN (insn != SEQUENCE)
+  && ! sequence_insn_p (insn))
 return 2;

   /* sh-dsp parallel processing insn take four bytes instead of two.  */

[Bug c++/53893] segfault with invalid c++ code

[pipping at exherbo dot org]

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

--- Comment #2 from Elias Pipping  2012-07-08 
11:43:11 UTC ---
% g++-4.7 -v
Using built-in specs.
COLLECT_GCC=g++-4.7
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/paludis/build/sys-devel-gcc-4.7.1/work/gcc-4.7.1/configure
--prefix=/usr --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu
--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
--sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking
--disable-silent-rules --enable-fast-install --libdir=/usr/lib64
--disable-multilib --libdir=/usr/lib64 --enable-clocale=gnu
--enable-languages=c++,fortran --enable-libstdcxx-pch=yes --enable-nls
--program-suffix=-4.7 --with-libelf --with-pkgversion='Exherbo gcc-4.7.1'
--with-system-zlib --disable-graphite --disable-cloog-backend --without-cloog
--without-ppl --disable-libgomp --disable-libssp
Thread model: posix
gcc version 4.7.1 (Exherbo gcc-4.7.1) 
% 

% g++-4.7 -std=c++0x nannormtest.ii
nannormtest.ii: In member function ‘double std::DenseVector::infinity_norm()
const’:
nannormtest.ii:8:80: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
%

[Bug target/53886] Seg fault in sh_insn_length_adjustment

[rmansfield at qnx dot com]

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

--- Comment #3 from Ryan Mansfield  2012-07-08 
11:52:21 UTC ---
Created attachment 27763
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27763
preprocessed src

Sorry, I had tried to attach it during the bug creation but I didn't notice it
didn't take.

[Bug c++/53892] Invalid "duplicate case value" for C++11 utf-16 char literals

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Andreas Schwab  2012-07-08 11:58:31 
UTC ---
.

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

[Bug c++/53690] [C++11] \u0000 and \U00000000 are wrongly encoded as U+0001.

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

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

Andreas Schwab  changed:

   What|Removed |Added

 CC||arnetheduck at gmail dot
   ||com

--- Comment #2 from Andreas Schwab  2012-07-08 11:58:31 
UTC ---
*** Bug 53892 has been marked as a duplicate of this bug. ***

[Bug c++/53893] segfault with invalid c++ code

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-07-08
 Ever Confirmed|0   |1

--- Comment #3 from Jonathan Wakely  2012-07-08 
12:01:08 UTC ---
Confirmed, trunk gives this instead of a segfault:

inv.cc: In member function ‘double std::DenseVector::infinity_norm() const’:
inv.cc:8:80: internal compiler error: tree check: expected tree that contains
‘decl minimal’ structure, have ‘nop_expr’ in decl_linkage, at cp/tree.c:3198
   return infinity_norm_TEMPLATE<( double (*)( double)) std::abs< double>
>();
   
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/53886] Seg fault in sh_insn_length_adjustment

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  2012-07-08 12:19:09 
UTC ---
(In reply to comment #3)
> Created attachment 27763 [details]
> preprocessed src
> 
> Sorry, I had tried to attach it during the bug creation but I didn't notice it
> didn't take.

Thanks.  I could reproduce the problem here.  It seems to happen for
-Os and-m{2a|4*}.

The reason is the subexpression

  PATTERN (NEXT_INSN (PREV_INSN (insn)))

can return nullptr in some cases like this.

The patch below fixes this particular crash, but I'm not sure whether it is
the right thing to do in this case.


Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c(revision 189339)
+++ gcc/config/sh/sh.c(working copy)
@@ -9652,6 +9652,26 @@
 #define IS_ASM_LOGICAL_LINE_SEPARATOR(C, STR) ((C) == ';')
 #endif

+static bool
+sequence_insn_p (rtx insn)
+{
+  rtx prev,next,pat;
+
+  prev = PREV_INSN (insn);
+  if (prev == NULL)
+return false;
+
+  next = NEXT_INSN (prev);
+  if (next == NULL)
+return false;
+
+  pat = PATTERN (next);
+  if (pat == NULL)
+return false;
+
+  return GET_CODE (pat) == SEQUENCE;
+}
+
 int
 sh_insn_length_adjustment (rtx insn)
 {
@@ -9662,7 +9682,7 @@
 && GET_CODE (PATTERN (insn)) != CLOBBER)
|| CALL_P (insn)
|| (JUMP_P (insn) && !JUMP_TABLE_DATA_P (insn)))
-  && GET_CODE (PATTERN (NEXT_INSN (PREV_INSN (insn != SEQUENCE
+  && ! sequence_insn_p (insn)
   && get_attr_needs_delay_slot (insn) == NEEDS_DELAY_SLOT_YES)
 return 2;

@@ -9671,7 +9691,7 @@
   if (sh_cpu_attr == CPU_SH2E
   && JUMP_P (insn) && !JUMP_TABLE_DATA_P (insn)
   && get_attr_type (insn) == TYPE_CBRANCH
-  && GET_CODE (PATTERN (NEXT_INSN (PREV_INSN (insn != SEQUENCE)
+  && ! sequence_insn_p (insn))
 return 2;

   /* sh-dsp parallel processing insn take four bytes instead of two.  */

[Bug target/53886] Seg fault in sh_insn_length_adjustment

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Target|sh4-unknown-linux-gnu   |sh*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-07-08
 Ever Confirmed|0   |1

[Bug target/53886] Seg fault in sh_insn_length_adjustment

[kkojima at gcc dot gnu.org]

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

--- Comment #5 from Kazumoto Kojima  2012-07-08 
13:41:09 UTC ---
(In reply to comment #4)
> The patch below fixes this particular crash, but I'm not sure whether it is
> the right thing to do in this case.

Looks fine to me except that the line

>+  rtx prev,next,pat;

requires space after comma.

[Bug target/53886] Seg fault in sh_insn_length_adjustment

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo  2012-07-08 13:45:28 
UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > The patch below fixes this particular crash, but I'm not sure whether it is
> > the right thing to do in this case.
> 
> Looks fine to me except that the line
> 
> >+  rtx prev,next,pat;
> 
> requires space after comma.

Ah yeah, sure.  Thanks.
I'll submit the patch after testing then.
Maybe backport it to 4.7, too?

[Bug target/53886] Seg fault in sh_insn_length_adjustment

[kkojima at gcc dot gnu.org]

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

--- Comment #7 from Kazumoto Kojima  2012-07-08 
13:59:00 UTC ---
(In reply to comment #6)
> Maybe backport it to 4.7, too?

If it's a regression also on 4.7.  The test case doesn't fail with 4.7.1
on my environment, though.

[Bug c++/53893] segfault with invalid c++ code

[pipping at exherbo dot org]

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

Elias Pipping  changed:

   What|Removed |Added

  Attachment #27762|0   |1
is obsolete||

--- Comment #4 from Elias Pipping  2012-07-08 
14:04:11 UTC ---
Created attachment 27764
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27764
test case

I've reduced it a bit and tried to get it closer to valid code.

[Bug target/51244] SH Target: Inefficient conditional branch

[olegendo at gcc dot gnu.org]

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

--- Comment #41 from Oleg Endo  2012-07-08 
15:03:26 UTC ---
Author: olegendo
Date: Sun Jul  8 15:03:21 2012
New Revision: 189360

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189360
Log:
PR target/51244
* config/sh/sh.md (*branch_true_eq, *branch_false_ne, nott): New insns.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md

gcc-4.7.1 build system question : why is "make bootstrap" with configure option '--enable-languages=c' building the C++ compiler ?

[Jason Vas Dias]

Hi -  I've been regularly building gcc for nearly two decades, and now
attempting to build a bootstrap
"C" only gcc-4.7.1 sufficient only to build binutils (my initial first
step is always to rebuild binutils
with the bootstrap "C" only compiler before doing a complete "make"
with "--enable-languages=all" -
a shame that support for configuring and building binutils along with
gcc has been withdrawn ,
so now I attempt to rebuild binutils separately with the "C" only
bootstrap compiler) .

Now this doesn't work - building "C"-only ( --enable-languages=c )
bootstrap fails building "C++" :

/mnt/sda3/gcc/./prev-gcc/g++ -B/mnt/sda3/gcc/./prev-gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
-I/usr/build2/gcc/gcc-4.7.1/libstdc++-v3/libsupc++
-L/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
 -g -O2 -gtoggle -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
 -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o cc1 c-lang.o
c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o
c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o
c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o
c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o
c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o
c-family/c-semantics.o c-family/c-ada-spec.o i386-c.o default-c.o \
  cc1-checksum.o main.o  libbackend.a libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a   ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a  -lcloog -lppl_c -lppl -lpwl -lgmpxx
-lmpc -lmpfr -lgmp -rdynamic -ldl  -lz
lto/lto.o: In function `lto_ft_typed(tree_node*)':
lto.c:(.text+0x326): undefined reference to `tree_code_type'
lto/lto.o: In function `lto_ft_common(tree_node*)':
lto.c:(.text+0x38b): undefined reference to `tree_code_type'
lto/lto.o: In function `lto_ft_decl_common(tree_node*)':
lto.c:(.text+0x3fb): undefined reference to `tree_code_type'
lto.c:(.text+0x432): undefined reference to `tree_code_type'
lto.c:(.text+0x469): undefined reference to `tree_code_type'
lto/lto.o:lto.c:(.text+0x49e): more undefined references to
`tree_code_type' follow

Boy, does it really mean it when it says "more undefined references to
`tree_code_type' follow" :

 $ grep 'undefined reference' make.bootstrap-cntnd.log  | wc -l
18127

My config.log command :


 generated by GNU Autoconf 2.64.  Invocation command line was

  $ /usr/build2/gcc/gcc-4.7.1/configure --prefix=/usr
--libdir=/usr/lib64 --with-cpu-32=i686 --with-cpu-64=k8
--enable-languages=c --enable-targets=all --enable-multi
lib --enable-threads=posix --enable-tls --enable-lto --enable-shared
--enable-checking=release --with-build-time-tools=/usr/bin
--with-ld=/usr/bin/ld --with-gnu-ld --
with-as=/usr/bin/as --with-gnu-as
--enable-version-specific-runtime-libs --with-system-zlib
--without-included-gettext --enable-bootstrap
--enable-serial-configure --
host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu

## - ##
## Platform. ##
## - ##

hostname = jvdspc
uname -m = x86_64
uname -r = 3.4.4-jvd+
uname -s = Linux
uname -v = #4 SMP Fri Jul 6 20:19:44 GMT 2012

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = x86_64
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

I configured with above command and did:

$ make -j2 bootstrap 2>&1 | tee make.bootstrap.log

This built fine overnight , and when I woke up in the morning the
machine was in a hard lock-up state
(overheating - I'm also investigating a kernel bug on this issue).

The build had created the "stage_final" file and a working prev-gcc/xgcc -
Can anyone suggest why making a "bootstrap" "C" "--enable-languages=c"
compiler should then
go on to build "C++" ?

I'm pretty sure the above error would not have occurred without the
kernel lock-up and interruption,
but nevertheless,  I didn't ask the gcc build system to build C++ yet,
so why did it do so ?

Any ideas / comments would be much appreciated ,
Jason Vas Dias (a Software Engineer) 

Re: gcc-4.7.1 build system question : why is "make bootstrap" with configure option '--enable-languages=c' building the C++ compiler ?

[Jason Vas Dias]

OK, so I'm reconfiguring with :
--enable-languages=c --disable-build-with-cxx
--disable-build-poststage1-with-cxx --enable-stage1-checking=all
--enable-stage1-languages=c
but why should I have to ? Shouldn't "--enable-languages=c" be enough
to disable building the C++ compiler and libstdc++ ?
Thanks & Regards,
 Jason

On Sun, Jul 8, 2012 at 4:06 PM, Jason Vas Dias  wrote:
> Hi -  I've been regularly building gcc for nearly two decades, and now
> attempting to build a bootstrap
> "C" only gcc-4.7.1 sufficient only to build binutils (my initial first
> step is always to rebuild binutils
> with the bootstrap "C" only compiler before doing a complete "make"
> with "--enable-languages=all" -
> a shame that support for configuring and building binutils along with
> gcc has been withdrawn ,
> so now I attempt to rebuild binutils separately with the "C" only
> bootstrap compiler) .
>
> Now this doesn't work - building "C"-only ( --enable-languages=c )
> bootstrap fails building "C++" :
>
> /mnt/sda3/gcc/./prev-gcc/g++ -B/mnt/sda3/gcc/./prev-gcc/
> -B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++
> -B/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
> -B/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
> -I/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
> -I/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
> -I/usr/build2/gcc/gcc-4.7.1/libstdc++-v3/libsupc++
> -L/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
> -L/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
>  -g -O2 -gtoggle -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall
> -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
> -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
>  -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o cc1 c-lang.o
> c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o
> c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o
> c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
> c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o
> c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o
> c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o
> c-family/c-semantics.o c-family/c-ada-spec.o i386-c.o default-c.o \
>   cc1-checksum.o main.o  libbackend.a libcommon-target.a libcommon.a
> ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
> ../libcpp/libcpp.a   ../libiberty/libiberty.a
> ../libdecnumber/libdecnumber.a  -lcloog -lppl_c -lppl -lpwl -lgmpxx
> -lmpc -lmpfr -lgmp -rdynamic -ldl  -lz
> lto/lto.o: In function `lto_ft_typed(tree_node*)':
> lto.c:(.text+0x326): undefined reference to `tree_code_type'
> lto/lto.o: In function `lto_ft_common(tree_node*)':
> lto.c:(.text+0x38b): undefined reference to `tree_code_type'
> lto/lto.o: In function `lto_ft_decl_common(tree_node*)':
> lto.c:(.text+0x3fb): undefined reference to `tree_code_type'
> lto.c:(.text+0x432): undefined reference to `tree_code_type'
> lto.c:(.text+0x469): undefined reference to `tree_code_type'
> lto/lto.o:lto.c:(.text+0x49e): more undefined references to
> `tree_code_type' follow
>
> Boy, does it really mean it when it says "more undefined references to
> `tree_code_type' follow" :
>
>  $ grep 'undefined reference' make.bootstrap-cntnd.log  | wc -l
> 18127
>
> My config.log command :
>
>
>  generated by GNU Autoconf 2.64.  Invocation command line was
>
>   $ /usr/build2/gcc/gcc-4.7.1/configure --prefix=/usr
> --libdir=/usr/lib64 --with-cpu-32=i686 --with-cpu-64=k8
> --enable-languages=c --enable-targets=all --enable-multi
> lib --enable-threads=posix --enable-tls --enable-lto --enable-shared
> --enable-checking=release --with-build-time-tools=/usr/bin
> --with-ld=/usr/bin/ld --with-gnu-ld --
> with-as=/usr/bin/as --with-gnu-as
> --enable-version-specific-runtime-libs --with-system-zlib
> --without-included-gettext --enable-bootstrap
> --enable-serial-configure --
> host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu
>
> ## - ##
> ## Platform. ##
> ## - ##
>
> hostname = jvdspc
> uname -m = x86_64
> uname -r = 3.4.4-jvd+
> uname -s = Linux
> uname -v = #4 SMP Fri Jul 6 20:19:44 GMT 2012
>
> /usr/bin/uname -p = unknown
> /bin/uname -X = unknown
>
> /bin/arch  = x86_64
> /usr/bin/arch -k   = unknown
> /usr/convex/getsysinfo = unknown
> /usr/bin/hostinfo  = unknown
> /bin/machine   = unknown
> /usr/bin/oslevel   = unknown
> /bin/universe  = unknown
>
> I configured with above command and did:
>
> $ make -j2 bootstrap 2>&1 | tee make.bootstrap.log
>
> This built fine overnight , and when I woke up in the morning the
> machine was in a hard lock-up state
> (overheating - I'm also investigating a kernel bug on this issue).
>
> The build had created the "stage_final" file and a working prev-gcc/xgcc -
> Can anyone suggest why making a "bootstrap" "C" "--enable-languages=c"
> compiler should then
> go on to build "C++"

Re: gcc-4.7.1 build system question : why is "make bootstrap" with configure option '--enable-languages=c' building the C++ compiler ?

[Jonathan Wakely]

Hi,

The gcc-bugs mailing list is for automated emails from our Bugzilla
database.  Your question is not about a bug, so would be more
appropriate on the gcc-help mailing list.

The answer to your question is that GCC itself is now built using a
C++ compiler, so it needs to build the C++ compiler to build itself,
see http://gcc.gnu.org/install/configure.html

--enable-build-poststage1-with-cxx
When bootstrapping, build stages 2 and 3 of GCC using a C++
compiler rather than a C compiler. Stage 1 is still built with a C
compiler. This is enabled by default and may be disabled using
--disable-build-poststage1-with-cxx.

[Bug c++/53882] [4.7/4.8 Regression] ICE in type_contains_placeholder_1, at tree.c:3015

[doko at gcc dot gnu.org]

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

--- Comment #3 from Matthias Klose  2012-07-08 
17:59:33 UTC ---
still see this with trunk 189355

[Bug c++/53690] [C++11] \u0000 and \U00000000 are wrongly encoded as U+0001.

[steven at gcc dot gnu.org]

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

--- Comment #3 from Steven Bosscher  2012-07-08 
20:23:40 UTC ---
Test case:

$ cat testsuite/g++.dg/pr53690.C
// { dg-do compile }
// { dg-options "-std=c++11" }

extern "C" int printf (__const char *__restrict __format, ...);

typedef unsigned short uint16_t;
typedef unsigned int uint32_t;

int main() {
uint32_t a = U'\U';
uint32_t b = U'\u';
uint32_t c = U'\x00';
uint32_t d = U'\0';

uint16_t e = u'\U';
uint16_t f = u'\u';
uint16_t g = u'\x00';
uint16_t h = u'\0';

printf("%x %x %x %x %x %x %x %x\n", a, b, c, d, e, f, g, h);

return 0;
}

// { dg-final { scan-tree-dump-not "= 1" "original" } }

[Bug driver/53883] GCC 4.7.1 doesn't build on Mac OS X 10.4.11 Tiger/PowerPC (32-bit), at least with MacPorts

[dwalker07 at yahoo dot com]

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

--- Comment #3 from Daryle Walker  2012-07-08 
20:45:06 UTC ---
(In reply to comment #2)
> (In reply to comment #0)
> > (Should I try building GCC 4.7.1 straight from you guys, without going 
> > through
> > MacPorts?)
> 
> Yes, probably.

I'm working on that now

[Bug preprocessor/53690] [C++11] \u0000 and \U00000000 are wrongly encoded as U+0001.

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC|steven at gcc dot gnu.org   |tromey at redhat dot com
  Component|c++ |preprocessor

--- Comment #4 from Steven Bosscher  2012-07-08 
20:53:32 UTC ---
The bug is in the preprocessor, see libcpp/charset.c:1074:

  if (result == 0)
result = 1;

  return result;
}

That code is older than the revision where libcpp became stand-alone 8 years
ago (r82199), and the initial check-in of gcc/cppcharset.c (r65845) already has
this code, too.

(See also http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01497.html)

One for the libcpp maintainer...

[Bug preprocessor/53690] [C++11] \u0000 and \U00000000 are wrongly encoded as U+0001.

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2012-07-08 
21:44:28 UTC ---
For the record,
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2170.html changed the
behaviour so UCNs corresponding to control characters are allowed in character
and string literals.

[Bug preprocessor/53690] [C++11] \u0000 and \U00000000 are wrongly encoded as U+0001.

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #6 from Steven Bosscher  2012-07-08 
21:59:03 UTC ---
(In reply to comment #5)
> For the record,
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2170.html changed the
> behaviour so UCNs corresponding to control characters are allowed in character
> and string literals.

Yes, see r152614.

[Bug c/53894] New: compile erroe

[869110597 at qq dot com]

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

 Bug #: 53894
   Summary: compile erroe
Classification: Unclassified
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: 869110...@qq.com

[Bug middle-end/53887] [4.8 Regression] ICE in hoist_edge_and_branch_if_true, at tree-switch-conversion.c:79

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-07-09
 CC||steven at gcc dot gnu.org
   Target Milestone|--- |4.8.0
Summary|ICE in  |[4.8 Regression] ICE in
   |hoist_edge_and_branch_if_tr |hoist_edge_and_branch_if_tr
   |ue, at  |ue, at
   |tree-switch-conversion.c:79 |tree-switch-conversion.c:79
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2012-07-09 03:51:38 
UTC ---
It is caused by revision 189173:

http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00077.html

[Bug lto/53895] New: [4.7.2/4.8 Regression][lto] symbol 'std::__once_callable' used as both __thread and non-__thread

[vincenzo.innocente at cern dot ch]

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

 Bug #: 53895
   Summary: [4.7.2/4.8 Regression][lto] symbol
'std::__once_callable' used as both __thread and
non-__thread
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch


I'm sure was working with 4.7.1
works with gcc version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC) 

this is ok
c++ thread.cpp -pthread -std=gnu++0x -O2 
this is not
c++ thread.cpp -pthread -std=gnu++0x -O2 -flto
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/bin/ld: error:
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../lib64/libstdc++.so:
symbol 'std::__once_call' used as both __thread and non-__thread
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/bin/ld: /tmp/innocent/ccd0XlxC.o:
previous definition here
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/bin/ld: error:
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../lib64/libstdc++.so:
symbol 'std::__once_callable' used as both __thread and non-__thread
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/bin/ld: /tmp/innocent/ccd0XlxC.o:
previous definition here
collect2: error: ld returned 1 exit status

ld -v
GNU gold (GNU Binutils 2.22.52.20120515) 1.11
gcc version 4.7.2 20120629 (prerelease) [gcc-4_7-branch revision 189081] (GCC)
gcc version 4.8.0 20120623 (experimental) [trunk revision 188906] (GCC) 
gcc version 4.8.0 20120708 (experimental) [trunk revision 189362] (GCC) 


cat thread.cpp
include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

typedef std::thread Thread;
typedef std::vector ThreadGroup;
typedef std::mutex Mutex;
typedef std::unique_lock Guard;
typedef std::condition_variable Condition;


long long threadId() {
  std::stringstream ss;
  ss << std::this_thread::get_id();
  long long id;
  ss >> id;
  return id; 
}


namespace global {
  // control cout
  Mutex coutLock;
}


int main() {

  return 0;
}

[Bug middle-end/53887] [4.8 Regression] ICE in hoist_edge_and_branch_if_true, at tree-switch-conversion.c:79

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot
   ||de

--- Comment #2 from Markus Trippelsdorf  
2012-07-09 05:18:47 UTC ---
Dup of Bug 53881. Already fixed.

[Bug middle-end/53887] [4.8 Regression] ICE in hoist_edge_and_branch_if_true, at tree-switch-conversion.c:79

[markus at trippelsdorf dot de]

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

--- Comment #3 from Markus Trippelsdorf  
2012-07-09 05:29:23 UTC ---
(In reply to comment #2)
> Dup of Bug 53881. Already fixed.

Sorry this isn't a dup (just the same error message).

Further reduced:


enum
{ Failed, NoError, NoDiskette }
a;
int b, c;
void
fn1 ()
{
if (c)
a << 1;
switch (b)
{
default:
a << 1;
case 0:
b = 0;
case 1:
case NoDiskette:
;
}
}

[Bug lto/53895] [4.7.2/4.8 Regression][lto] symbol 'std::__once_callable' used as both __thread and non-__thread

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-07-09
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2012-07-09 06:28:27 
UTC ---
Does it work with BFD linker?

[Bug middle-end/53887] [4.8 Regression] ICE in hoist_edge_and_branch_if_true, at tree-switch-conversion.c:79

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|steven at gcc dot gnu.org   |
 AssignedTo|unassigned at gcc dot   |steven at gcc dot gnu.org
   |gnu.org |