[Bug c/35634] [4.6/4.7/4.8 Regression] operand of pre-/postin-/decrement not promoted

[jaak at ristioja dot ee]

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



Jaak Ristioja  changed:



   What|Removed |Added



 CC||jaak at ristioja dot ee



--- Comment #34 from Jaak Ristioja  2012-11-19 
08:24:00 UTC ---

Bump! I don't want to be impolite, but quoting

http://blog.regehr.org/archives/482

  "In LLVM/Clang the bug was not known but was fixed in less than 24 hours."



Seriously...

[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically

[jakub at gcc dot gnu.org]

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



--- Comment #14 from Jakub Jelinek  2012-11-19 
08:54:47 UTC ---

I bet 9.5% or more of that is due to the PLT call.  The thing is, even when you

have initial-exec TLS model code, if you link it into an executable and the

referenced TLS variable is in the executable, the linker TLS transitions

optimization changes the IE model into LE model, so instead of something like:

  mov0x2009a9(%rip),%rax

  mov%fs:(%rax),%eax

you'll end up with

  mov$-4,%rax

  mov%fs:(%rax),%eax

or so (compared to

  mov%fs:-4,%eax

if it was local-exec model from the beginning).  Given the amount of code in

__tsan_read8, I seriously doubt it is noticeable.  So, please compare libtsan

built with -fPIC -ftls-model=initial-exec with libtsan built with -fPIE

(-ftls-model=local-exec).  The former will not require any special hacks and

will work just fine even with shared libraries, the latter won't.

[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically

[konstantin.s.serebryany at gmail dot com]

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



--- Comment #15 from Konstantin Serebryany  2012-11-19 09:03:35 UTC ---

You are right that "-fPIC -ftls-model=initial-exec" does not affect performance 

if we link libtsan statically (I checked). 

As you say, the linker nukes one of the loads. 



But if we link libtsan.so dynamically, we still get both sources of overhead.

[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically

[konstantin.s.serebryany at gmail dot com]

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



--- Comment #16 from Konstantin Serebryany  2012-11-19 09:06:26 UTC ---

So, using "-fPIC -ftls-model=initial-exec" is a great idea, it will allow 

to build the files once and have both static and dynamic library.

But we need to agree that the dynamic library is noticeably slower.

[Bug debug/51358] [4.8 Regression] incorrect/missing location for function arg, -O0, without VTA

[jakub at gcc dot gnu.org]

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



--- Comment #9 from Jakub Jelinek  2012-11-19 
09:09:59 UTC ---

I don't see the link between the bugreport and dwarf4, why do you think this is

a regression?

[Bug bootstrap/55388] New: [4.8 regression] ICE in int_mode_for_mode at stor-layout.c:423 breaks sparc64-linux bootstrap

[mikpe at it dot uu.se]

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



 Bug #: 55388

   Summary: [4.8 regression] ICE in int_mode_for_mode at

stor-layout.c:423 breaks sparc64-linux bootstrap

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: bootstrap

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: mi...@it.uu.se





Attempting to bootstrap gcc-4.8-20121118 on sparc64-linux fails with:



make[5]: Entering directory

`/mnt/scratch/objdir48/sparc-unknown-linux/libstdc++-v3/libsupc++'

/bin/sh ../libtool --tag CXX --tag disable-shared   --mode=compile

/mnt/scratch/objdir48/./gcc/xgcc -shared-libgcc -B/mnt/scratch/objdir48/./gcc

-nostdinc++ -L/mnt/scratch/objdir48/sparc-unknown-linux/libstdc++-v3/src

-L/mnt/scratch/objdir48/sparc-unknown-linux/libstdc++-v3/src/.libs

-B/mnt/scratch/install48/sparc-unknown-linux/bin/

-B/mnt/scratch/install48/sparc-unknown-linux/lib/ -isystem

/mnt/scratch/install48/sparc-unknown-linux/include -isystem

/mnt/scratch/install48/sparc-unknown-linux/sys-include   

-I/mnt/scratch/gcc-4.8-20121118/libstdc++-v3/../libgcc

-I/mnt/scratch/objdir48/sparc-unknown-linux/libstdc++-v3/include/sparc-unknown-linux

-I/mnt/scratch/objdir48/sparc-unknown-linux/libstdc++-v3/include

-I/mnt/scratch/gcc-4.8-20121118/libstdc++-v3/libsupc++  -prefer-pic

-D_GLIBCXX_SHARED  -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi 

-fdiagnostics-show-location=once-ffunction-sections -fdata-sections 

-frandom-seed=class_type_info.lo -g -O2 -D_GNU_SOURCE  -c -o class_type_info.lo

/mnt/scratch/gcc-4.8-20121118/libstdc++-v3/libsupc++/class_type_info.cc

libtool: compile:  /mnt/scratch/objdir48/./gcc/xgcc -shared-libgcc

-B/mnt/scratch/objdir48/./gcc -nostdinc++

-L/mnt/scratch/objdir48/sparc-unknown-linux/libstdc++-v3/src

-L/mnt/scratch/objdir48/sparc-unknown-linux/libstdc++-v3/src/.libs

-B/mnt/scratch/install48/sparc-unknown-linux/bin/

-B/mnt/scratch/install48/sparc-unknown-linux/lib/ -isystem

/mnt/scratch/install48/sparc-unknown-linux/include -isystem

/mnt/scratch/install48/sparc-unknown-linux/sys-include

-I/mnt/scratch/gcc-4.8-20121118/libstdc++-v3/../libgcc

-I/mnt/scratch/objdir48/sparc-unknown-linux/libstdc++-v3/include/sparc-unknown-linux

-I/mnt/scratch/objdir48/sparc-unknown-linux/libstdc++-v3/include

-I/mnt/scratch/gcc-4.8-20121118/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -Wall

-Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once

-ffunction-sections -fdata-sections -frandom-seed=class_type_info.lo -g -O2

-D_GNU_SOURCE -c

/mnt/scratch/gcc-4.8-20121118/libstdc++-v3/libsupc++/class_type_info.cc  -fPIC

-DPIC -D_GLIBCXX_SHARED -o class_type_info.o

/mnt/scratch/gcc-4.8-20121118/libstdc++-v3/libsupc++/class_type_info.cc: In

member function 'virtual bool __cxxabiv1::__class_type_info::__do_upcast(const

__cxxabiv1::__class_type_info*, void**) const':

/mnt/scratch/gcc-4.8-20121118/libstdc++-v3/libsupc++/class_type_info.cc:46:6:

internal compiler error: in int_mode_for_mode, at stor-layout.c:423

 bool __class_type_info::

  ^

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

make[5]: *** [class_type_info.lo] Error 1

make[5]: Leaving directory

`/mnt/scratch/objdir48/sparc-unknown-linux/libstdc++-v3/libsupc++'

make[4]: *** [all-recursive] Error 1

make[4]: Leaving directory

`/mnt/scratch/objdir48/sparc-unknown-linux/libstdc++-v3'

make[3]: *** [all] Error 2

make[3]: Leaving directory

`/mnt/scratch/objdir48/sparc-unknown-linux/libstdc++-v3'

make[2]: *** [all-stage2-target-libstdc++-v3] Error 2

make[2]: Leaving directory `/mnt/scratch/objdir48'

make[1]: *** [stage2-bubble] Error 2

make[1]: Leaving directory `/mnt/scratch/objdir48'

make: *** [bootstrap] Error 2



This problem was not present in 4.8-2012.



I'll try to derive a minimized test case later today (-ENOTIME right now).

[Bug fortran/55352] [4.7/4.8 Regression] Erroneous gfortran warning of unused module variable when variable is only used in namelist

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



Summary|Erroneous gfortran warning  |[4.7/4.8 Regression]

   |of unused module variable   |Erroneous gfortran warning

   |when variable is only used  |of unused module variable

   |in namelist |when variable is only used

   ||in namelist



--- Comment #7 from janus at gcc dot gnu.org 2012-11-19 09:24:53 UTC ---

(In reply to comment #6)

> The fix will presumably make it into the 4.8 release, but will probably not be

> backported to 4.7 (unless you can show that the bug is a regression, i.e. did

> not occur in a previous release of gfortran - I haven't checked this).



Just checked: The bogus warning with -Wall reported here seems to be a 4.7

regression indeed. I verified that it does not occur with 4.3.4, 4.5.3 and

4.6.0.

[Bug bootstrap/55370] [4.8 Regression] Bad libgcc.map

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2012-11-19

 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #1 from Jakub Jelinek  2012-11-19 
09:31:37 UTC ---

Created attachment 28729

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28729

gcc48-pr55370.patch



Untested fix.

[Bug rtl-optimization/55315] comparing address to constant is folded in cse

[vries at gcc dot gnu.org]

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



--- Comment #2 from vries at gcc dot gnu.org 2012-11-19 09:35:53 UTC ---

Author: vries

Date: Mon Nov 19 09:35:48 2012

New Revision: 193616



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

Log:

2012-11-19  Tom de Vries  



PR rtl-optimization/55315



* rtlanal.c (nonzero_address_p): Don't assume a nonzero address plus a

const is a nonzero address.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/rtlanal.c

[Bug rtl-optimization/55315] comparing address to constant is folded in cse

[vries at gcc dot gnu.org]

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



--- Comment #3 from vries at gcc dot gnu.org 2012-11-19 09:35:59 UTC ---

Author: vries

Date: Mon Nov 19 09:35:54 2012

New Revision: 193617



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

Log:

2012-11-19  Tom de Vries  



PR rtl-optimization/55315



* gcc.target/mips/pr55315.c: New test.



Added:

trunk/gcc/testsuite/gcc.target/mips/pr55315.c

Modified:

trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/55236] gcc.c-torture/execute/pr22493-1.c FAILs with -fPIC

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



   Target Milestone|--- |4.8.0

Summary|[4.8 Regression]|gcc.c-torture/execute/pr224

   |gcc.c-torture/execute/pr224 |93-1.c FAILs with -fPIC

   |93-1.c FAILs with -fPIC |



--- Comment #3 from Jakub Jelinek  2012-11-19 
09:38:45 UTC ---

Fixed on the trunk so far, the branches still miscompile the testcase.

[Bug rtl-optimization/55315] comparing address to constant is folded in cse

[vries at gcc dot gnu.org]

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



vries at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED

 AssignedTo|unassigned at gcc dot   |vries at gcc dot gnu.org

   |gnu.org |



--- Comment #4 from vries at gcc dot gnu.org 2012-11-19 09:38:52 UTC ---

Patch and test-cases checked in, marking as resolved fixed.

[Bug tree-optimization/55329] [4.8 Regression] ICE: internal compiler error: in operator[], at vec.h:487 with -O -fno-guess-branch-probability -fnon-call-exceptions --param=early-inlining-insns=111

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #6 from Jakub Jelinek  2012-11-19 
09:45:49 UTC ---

Fixed.

[Bug other/55313] libsanitizer cannot be installed

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 Status|WAITING |REOPENED



--- Comment #5 from Eric Botcazou  2012-11-19 
09:58:06 UTC ---

Configured with: ../src/configure --prefix=/usr/gnat

--with-libelf=/red.a/gnatmail/gcc-x/build-red/x86_64-linux/libmpfr/install

--with-mpc=/red.a/gnatmail/gcc-x/build-red/x86_64-linux/libmpfr/install

--with-gmp=/red.a/gnatmail/gcc-x/build-red/x86_64-linux/libmpfr/install

--with-mpfr=/red.a/gnatmail/gcc-x/build-red/x86_64-linux/libmpfr/install

--build=x86_64-pc-linux-gnu --enable-languages=c,ada,c++ --disable-nls

--without-libiconv-prefix --disable-libmudflap --disable-libstdcxx-pch

--disable-libada --enable-checking=yes,rtl --enable-__cxa_atexit

--enable-threads=posix --disable-multilib

--with-bugurl=URL:mailto:rep...@adacore.com

--with-build-time-tools=/red.a/gnatmail/gcc-x/build-red/x86_64-linux/gnat/obj

[Bug other/55389] New: library cannot be rebuilt by make all-target

[ebotcazou at gcc dot gnu.org]

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



 Bug #: 55389

   Summary: library cannot be rebuilt by make all-target

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: other

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ebotca...@gcc.gnu.org





This is the same issue as PR libitm/52197, but for libsanitizer: you cannot

rebuild the library by the usual make all-target-libsanitizer or make

all-target.  Do a rm -rf $(target)libsanitizer and then issue one of the former

two commands, you get:



/bin/sh ../libtool --tag=CXX   --mode=compile

-B/home/eric/install/gcc/x86_64-suse-linux/bin/

-B/home/eric/install/gcc/x86_64-suse-linux/lib/ -isystem

/home/eric/install/gcc/x86_64-suse-linux/include -isystem

/home/eric/install/gcc/x86_64-suse-linux/sys-include-D_GNU_SOURCE -D_DEBUG

-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS  -I.

-I/home/eric/svn/gcc/libsanitizer/interception  -I

/home/eric/svn/gcc/libsanitizer/include   -Wall -W -Wno-unused-parameter

-Wwrite-strings -pedantic -Wno-long-long  -fPIC -fno-builtin -fno-exceptions

-fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros

-Wno-c99-extensions  -g -O2 -D_GNU_SOURCE -MT interception_linux.lo -MD -MP -MF

.deps/interception_linux.Tpo -c -o interception_linux.lo

/home/eric/svn/gcc/libsanitizer/interception/interception_linux.cc

libtool: compile: unrecognized option

`-B/home/eric/install/gcc/x86_64-suse-linux/bin/'

libtool: compile: Try `libtool --help' for more information.

make[2]: *** [interception_linux.lo] Error 1

make[2]: Leaving directory

`/home/eric/build/gcc/native/x86_64-suse-linux/libsanitizer/interception'

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory

`/home/eric/build/gcc/native/x86_64-suse-linux/libsanitizer'

make: *** [all-target-libsanitizer] Error 2

[Bug other/11219] 'make distclean' aborts (bugs in boehm-gc, zlib Makefiles)

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||WONTFIX



--- Comment #3 from Eric Botcazou  2012-11-19 
10:06:02 UTC ---

'make distclean' is a lost cause.

[Bug other/11571] objdir/intl not cleaned up by 'make distclean'

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||WONTFIX



--- Comment #10 from Eric Botcazou  2012-11-19 
10:06:54 UTC ---

'make distclean' is a lost cause.

[Bug c/36367] warning for questionable compound expression

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 Status|REOPENED|NEW

[Bug target/55390] New: [4.8 Regression] Error when building with -mfpmath=sse

[d.g.gorbachev at gmail dot com]

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



 Bug #: 55390

   Summary: [4.8 Regression] Error when building with -mfpmath=sse

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: d.g.gorbac...@gmail.com





If I build GCC having -march=pentium4 -mfpmath=sse in CFLAGS_FOR_TARGET, it

fails with the following error:



../../../gcc-4.8/libatomic/load_n.c:1:0: error: SSE instruction set disabled,

using 387 arithmetics [-Werror]



because -march=i586 appended in the makefile. It should also add -mfpmath=387

then.

[Bug bootstrap/55391] New: [4.8 regression] ICE in adjust_address_1 at emit-rtl.c:2180 breaks bulding cross to sparc64-linux

[mikpe at it dot uu.se]

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



 Bug #: 55391

   Summary: [4.8 regression] ICE in adjust_address_1 at

emit-rtl.c:2180 breaks bulding cross to sparc64-linux

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: bootstrap

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: mi...@it.uu.se





Attempting to build gcc-4.8-20121118 as a cross from x86_64-linux to

sparc64-linux fails with:



libtool: compile:  /mnt/scratch/objdir/./gcc/g++ -B/mnt/scratch/objdir/./gcc/

-nostdinc++ -nostdinc++

-I/mnt/scratch/objdir/sparc64-unknown-linux/libstdc++-v3/include/sparc64-unknown-linux

-I/mnt/scratch/objdir/sparc64-unknown-linux/libstdc++-v3/include

-I/mnt/scratch/gcc-4.8-20121118/libstdc++-v3/libsupc++

-I/mnt/scratch/gcc-4.8-20121118/libstdc++-v3/include/backward

-I/mnt/scratch/gcc-4.8-20121118/libstdc++-v3/testsuite/util

-L/mnt/scratch/objdir/sparc64-unknown-linux/libstdc++-v3/src

-L/mnt/scratch/objdir/sparc64-unknown-linux/libstdc++-v3/src/.libs

-B/home/mikpe/pkgs/linux-x86_64/cross-sparc64/sparc64-unknown-linux/bin/

-B/home/mikpe/pkgs/linux-x86_64/cross-sparc64/sparc64-unknown-linux/lib/

-isystem

/home/mikpe/pkgs/linux-x86_64/cross-sparc64/sparc64-unknown-linux/include

-isystem

/home/mikpe/pkgs/linux-x86_64/cross-sparc64/sparc64-unknown-linux/sys-include

-DHAVE_CONFIG_H -I. -I/mnt/scratch/gcc-4.8-20121118/libitm

-I/mnt/scratch/gcc-4.8-20121118/libitm/config/linux/sparc

-I/mnt/scratch/gcc-4.8-20121118/libitm/config/linux

-I/mnt/scratch/gcc-4.8-20121118/libitm/config/sparc

-I/mnt/scratch/gcc-4.8-20121118/libitm/config/posix

-I/mnt/scratch/gcc-4.8-20121118/libitm/config/generic

-I/mnt/scratch/gcc-4.8-20121118/libitm -ftls-model=initial-exec -Wall -pthread

-Werror -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4

-g -O2 -D_GNU_SOURCE -MT method-serial.lo -MD -MP -MF .deps/method-serial.Tpo

-c /mnt/scratch/gcc-4.8-20121118/libitm/method-serial.cc -o method-serial.o

In file included from /mnt/scratch/gcc-4.8-20121118/libitm/libitm_i.h:87:0,

 from /mnt/scratch/gcc-4.8-20121118/libitm/method-serial.cc:25:

/mnt/scratch/gcc-4.8-20121118/libitm/method-serial.cc: In member function

'virtual _ITM_TYPE_CE {anonymous}::serialirr_dispatch::ITM_RCE(const

_ITM_TYPE_CE*)':

/mnt/scratch/gcc-4.8-20121118/libitm/dispatch.h:37:41: internal compiler error:

in adjust_address_1, at emit-rtl.c:2180

 return load(ptr, abi_dispatch::LSMOD);  \

 ^

(long stack dump omitted)



Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.

make[4]: *** [method-serial.lo] Error 1

make[4]: Leaving directory `/mnt/scratch/objdir/sparc64-unknown-linux/libitm'

make[3]: *** [all-recursive] Error 1

make[3]: Leaving directory `/mnt/scratch/objdir/sparc64-unknown-linux/libitm'

make[2]: *** [all] Error 2

make[2]: Leaving directory `/mnt/scratch/objdir/sparc64-unknown-linux/libitm'

make[1]: *** [all-target-libitm] Error 2

make[1]: Leaving directory `/mnt/scratch/objdir'

make: *** [all] Error 2



Found while checking to see if the native ICE reported in PR55388 could be

reproduced with a cross.  Disabling libitm allows the build to complete.  (I

also had to disable libsanitizer to work around a build error there.)



Starting a bisection...

[Bug bootstrap/54128] [4.8 Regression] GCC does not bootstrap on little endian mips due to mis-compare on tree-data-ref.c

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||aoliva at gcc dot gnu.org,

   ||jakub at gcc dot gnu.org,

   ||vmakarov at gcc dot gnu.org



--- Comment #13 from Jakub Jelinek  2012-11-19 
10:46:02 UTC ---

The first ira.c hunk doesn't make much sense to me, DF_INSN_UID_DEFS should be

NULL on any DEBUG_INSN.  The second might be acceptable, though I'd say the

problem might be elsewhere, in particular calls that return values in multiple

registers, but only a subset of those registers is actually used in the code.

To some extent the issue can be seen also on i?86, -m32 -O2 -g:

long long bar (void);

int

foo (void)

{

  long long a = bar ();

  long long b = a;

  return b + 1;

}

The call has REG_UNUSED (reg:SI 1 dx) note, so in theory debug insns after the

call shouldn't be using it, but they do.  And valtrack is a little bit lost on

it,

it feels it is not ok to do it, but when trying to fix it up it does the same

thing (again and again).  So we end up with a series of debug insns like:

(debug_insn 33 5 24 2 (var_location:SI D#4 (reg:SI 1 dx [+4 ])) -1

 (nil))

(debug_insn 24 33 23 2 (var_location:SI D#3 (debug_expr:SI D#4)) -1

 (nil))

(debug_insn 23 24 22 2 (var_location:SI D#2 (debug_expr:SI D#3)) -1

 (nil))

(debug_insn 22 23 7 2 (var_location:SI D#1 (debug_expr:SI D#2)) -1

 (nil))

(debug_insn 7 22 8 2 (var_location:DI a (concatn/v:DI [

(reg:SI 0 ax [orig:65 b ] [65])

(debug_expr:SI D#1)

])) mmm.c:5 -1

 (nil))

Wonder if we shouldn't make it explicitly valid that REG_UNUSED registers from

a CALL can be referenced in the following debug_insn, provided there are no

intervening real insns in between, and teach valtrack.c not to add the extra

debug temporaries on each invocation for those.  Then the ira.c change would be

certainly a must (I think it is desirable anyway), I'd hope there aren't too

big -fcompare-debug risks otherwise, because it is only extending the lifetime

of the hard register to debug insns immediately following the call and thus not

extending it over any other real insns.

[Bug translation/55392] New: Internal compiler error in get_expr_operands, c++11 without optimization

[david at aitellu dot com]

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



 Bug #: 55392

   Summary: Internal compiler error in get_expr_operands, c++11

without optimization

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: translation

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: da...@aitellu.com





I have tried compiling this code both with gcc 4.7.2 and the gcc-snapshot of

4.8 from Ubuntu (gcc version 4.8.0 20121008 (experimental) [trunk revision

192192]) and it crashes in both cases. My command line is simply:

g++ -Wall -g -O0 -std=c++11



GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

Compiler executable checksum: be9316d4d24873f9eb2c1149d4699d98

unhandled expression in get_expr_operands():

 

unit size 

align 64 symtab -1455709008 alias set -1 canonical type

0x7f16a97731f8 fields  context



full-name "class TightTree >"

needs-constructor X(constX&) this=(X&) n_parents=1 use_template=1

interface-unknown

pointer_to_this  reference_to_this

 chain >

readonly sizes-gimplified unsigned DI

size 

unit size 

align 64 symtab -1460303440 alias set -1 canonical type 0x7f16a939f738>

readonly used unsigned nonlocal decl_7 DI file

/home/gurgeh/projs/hg/Turtle/src/TightStructures/tight_tree.hpp line 102 col 41

size  unit size 

align 64 offset_align 128

offset  constant 0>

bit offset  constant 0> context  chain

>



/home/gurgeh/projs/hg/Turtle/src/TightStructures/test_ttree.cpp: In lambda

function:

/home/gurgeh/projs/hg/Turtle/src/TightStructures/test_ttree.cpp:62:92: internal

compiler error: in get_expr_operands, at tree-ssa-operands.c:984

 BOOST_AUTO_TEST_SUITE_END()



The place where it crashes is inside a unit test, using the Boost unit test

framework.



clang 3.1 compiles the code fine.



The last line of the output is, oddly,

"The bug is not reproducible, so it is likely a hardware or OS problem." But I

don't understand this. I can certainly reproduce it 100% of the times, with

both 4.7 and 4.8.

[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically

[dvyukov at google dot com]

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



--- Comment #17 from Dmitry Vyukov  2012-11-19 
10:53:04 UTC ---

>When building libtsan as a shared library (for which I had to hack our assembly

>blobs a bit) we get two sources of slowdown: 

>  1. __tsan_read8 and friends are called through PLT

>  2. __tsan_read8 and friends use one extra load to get to TLS



> I bet 9.5% or more of that is due to the PLT call.



That's not the overhead you are looking for, Luke.



We currently compile with -fPIC and link statically, linker inserts only 1

memory dereference in this case. However, -fPIC affects code generation in

compiler, it has to reserve more registers for tls access code and has to

allocate stack frame because of the potential call. Only that causes *20%*

slowdown on a real application (not a synthetic benchmark).



Kostya, to evaluate initial-exec you need to insure that code characteristics

of __tsan_read/write are not affected, i.e. 0 stack spills and analyze script

passes. Everything else we have w/o initial-exec.

[Bug target/55390] [4.8 Regression] Error when building with -mfpmath=sse

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||jakub at gcc dot gnu.org

 Resolution||INVALID



--- Comment #1 from Jakub Jelinek  2012-11-19 
11:03:02 UTC ---

No, I'd say it is a user error and you should build with -msse2 -mfpmath=sse2

explicitly in the CFLAGS*.  Whatever place is passing -march=i486 or

-march=i586 can't guess what you added to CFLAGS, and -mfpmath=387 isn't always

the right thing.

[Bug c++/55393] New: gcc/g++ multiplies two unsigned integers using the IMULQ instruction

[cosmos at claycon dot org]

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



 Bug #: 55393

   Summary: gcc/g++ multiplies two unsigned integers using the

IMULQ instruction

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: cos...@claycon.org





g++ -Wall -Wextra -O2 -o mult mult.cpp

g++ (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)

64bit



mult.cpp:



#include 



void

display(

unsigned long int num,

unsigned long int mult)

{

unsigned long int tmp = num * mult;

std::cout << "mult " << mult << "\n num " << num

<< "\n tmp " << tmp << std::endl;



if (tmp < num)

std::cout << "overflow" << std::endl;

}



int

main(

int /* argc */,

char ** /* argv */)

{

unsigned long int num = 99;

unsigned long int mult = 1024;



display(num, mult);

return 0;

}



Problem:

"overflow" is not displayed as expected.



Analysis:

gcc generates an IMULQ instruction to calculate the value of tmp.

The value of num has bit 63 set.  Since IMULQ sees that argument

as signed, it results in an incorrect number that happens to be

greater than num.



IMULQ will generate the wrong result when the result just fits

into 64 bits too, even though the result would have been correct

(with no overflow) had the proper instruction been used.



Fix:

Whenever the multiplication operands are both unsigned, gcc should

generate an unsigned multiply instruction (MULQ in this case), unless

it can prove that the result would fit into 63 bits.

[Bug middle-end/55359] [4.8 Regression] ICE in simplify_subreg accessing an unaligned subvector

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-19

 CC||jakub at gcc dot gnu.org,

   ||rsandifo at gcc dot gnu.org

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #1 from Jakub Jelinek  2012-11-19 
11:40:05 UTC ---

Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192741

lowpart_bit_field_p looks weird, I don't see how BITS_PER_WORD is relevant

there, what IMHO matters is whether the subreg is valid or not.  While the

first hunk that uses this function uses validate_subreg, the second one doesn't

and

attempts to create an invalid subreg (subreg:V2DF (reg:OI) 8), where the byte

offset is not a multiple of V2DFmode size.

[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields

[redi at gcc dot gnu.org]

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



--- Comment #5 from Jonathan Wakely  2012-11-19 
11:47:20 UTC ---

(In reply to comment #4)

> Is this bug planned to be fixed in future?



Yes, of course. It's a bug.



> Can I help in any way to do that?



Sure, you could look in gcc/cp/*.c for the message

  "bit-field .* with non-integral type"

and see what conditions it depends on and why it disallows scoped enumeration

types.

[Bug bootstrap/55391] [4.8 regression] ICE in adjust_address_1 at emit-rtl.c:2180 breaks bulding cross to sparc64-linux

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 CC||ebotcazou at gcc dot

   ||gnu.org



--- Comment #1 from Eric Botcazou  2012-11-19 
11:48:03 UTC ---

> Found while checking to see if the native ICE reported in PR55388 could be

> reproduced with a cross.  Disabling libitm allows the build to complete.  (I

> also had to disable libsanitizer to work around a build error there.)

> 

> Starting a bisection...



I have a successful bootstrap on 20121117 so it's very recent.

[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields

[redi at gcc dot gnu.org]

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



--- Comment #6 from Jonathan Wakely  2012-11-19 
11:52:38 UTC ---

The check is for an unscoped enumeration type which does seem intentional.



This change allows the example to compile:



--- cp/decl2.c.orig 2012-11-19 11:50:28.842443803 +

+++ cp/decl2.c  2012-11-19 11:46:08.445472115 +

@@ -1026,7 +1026,7 @@

   if (TREE_CODE (value) == VOID_TYPE)

 return void_type_node;



-  if (!INTEGRAL_OR_UNSCOPED_ENUMERATION_TYPE_P (TREE_TYPE (value))

+  if (!INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (value))

   && (POINTER_TYPE_P (value)

   || !dependent_type_p (TREE_TYPE (value

 {



It emits a warning though:



e.cc:5:19: warning: 'MyClass::Field1' is too small to hold all values of 'enum

class MyEnum' [enabled by default]

[Bug translation/52289] translatable string typo: "must not be have"

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-19

 CC||pbrook at gcc dot gnu.org

 Ever Confirmed|0   |1

[Bug translation/53764] Typo in translatable string: "literalto"

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-19

 Ever Confirmed|0   |1

[Bug target/54067] arm-none-eabi with -mapcs and attribute((interrupt)) generates wrong stack alignment

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



  Component|translation |target



--- Comment #3 from Jonathan Wakely  2012-11-19 
11:57:43 UTC ---

(wrong component)

[Bug c++/55392] Internal compiler error in get_expr_operands, c++11 without optimization

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2012-11-19

  Component|translation |c++

 Ever Confirmed|0   |1

   Severity|major   |normal



--- Comment #1 from Jonathan Wakely  2012-11-19 
11:58:21 UTC ---

The testcase is missing.

[Bug translation/52284] translatable string typo: "compatable"

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #1 from Jonathan Wakely  2012-11-19 
12:01:18 UTC ---

Fixed by http://gcc.gnu.org/viewcvs?view=revision&revision=187959

[Bug bootstrap/55391] [4.8 regression] ICE in adjust_address_1 at emit-rtl.c:2180 breaks bulding cross to sparc64-linux

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-19

 CC||rsandifo at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #2 from Eric Botcazou  2012-11-19 
12:05:27 UTC ---

It's http://gcc.gnu.org/ml/gcc-cvs/2012-11/msg00548.html

[Bug rtl-optimization/55342] [4.8 Regression] [LRA,x86] Non-optimal code for simple loop with LRA

[ysrumyan at gmail dot com]

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



--- Comment #2 from Yuri Rumyantsev  2012-11-19 
12:06:20 UTC ---

The patching compiler produces better binaries but we still have -6%

performance degradation on corei7. The main cause of it it that LRA compiler

generates spill of 'pure' byte 'g' whereas old compiler generates spill for 'm'

that is negation of 'g':



gcc wwithout LRA (assembly part the head of loop)



.L7:

movzbl1(%edi), %edx

leal3(%edi), %ebp

movzbl(%edi), %ebx

movl%ebp, %edi

notl%edx   // perform negation on register

movb%dl, 3(%esp)



gcc with LRA



.L7:

movzbl(%edi), %ebx

leal3(%edi), %ebp

movzbl1(%edi), %ecx

movl%ebp, %edi

movzbl-1(%ebp), %edx

notl%ebx

notl%ecx

movb%dl, (%esp)

cmpb%cl, %bl

notb(%esp) // perform nagation in memory



i.e. wwe have redundant load and store form/to stack.



I assume that this should be fixed also.

[Bug c++/55368] Comma before semicolon in struct definition is not rejected

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot

   |gnu.org |com



--- Comment #1 from Paolo Carlini  2012-11-19 
12:11:06 UTC ---

On it.

[Bug c++/55392] Internal compiler error in get_expr_operands, c++11 without optimization

[david at aitellu dot com]

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



--- Comment #2 from David Fendrich  2012-11-19 
12:19:55 UTC ---

Created attachment 28730

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28730

Lzma compressed .ii file from -save-temps



I attached this file uncompressed to the original post, but it seems to have

been to large.

[Bug c++/55394] New: Using call_once without -lpthread compiles without warning

[G.J.Giezeman at uu dot nl]

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



 Bug #: 55394

   Summary: Using call_once without -lpthread compiles without

warning

Classification: Unclassified

   Product: gcc

   Version: 4.6.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: g.j.gieze...@uu.nl





Created attachment 28731

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28731

Source file



A source file which contains call_once will compile without any errors or

warnings, even when libpthread is not linked. At run time, an exception will be

thrown with a very unhelpful message. The attached source file demonstrates the

problem.



$ g++ -Wall -Wextra -std=c++0x callonce.cpp

$ ./a.out

terminate called after throwing an instance of 'std::system_error'

  what():  Unknown error -1

Aborted (core dumped)



Linking libpthread will remove the problem.



$ g++ -Wall -Wextra -std=c++0x callonce.cpp -lpthread

$ ./a.out

$ 



In the actual use case, call_once was called in a library that could be used in

both multithreaded and singlethreaded code. That made it a hard to trace bug.



$ g++ -v

Using built-in specs.

COLLECT_GCC=g++

COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper

Target: x86_64-linux-gnu

Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro

4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs

--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr

--program-suffix=-4.6 --enable-shared --enable-linker-build-id

--with-system-zlib --libexecdir=/usr/lib --without-included-gettext

--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6

--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu

--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object

--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686

--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu

--host=x86_64-linux-gnu --target=x86_64-linux-gnu

Thread model: posix

gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

[Bug bootstrap/55391] [4.8 regression] ICE in adjust_address_1 at emit-rtl.c:2180 breaks bulding cross to sparc64-linux

[mikpe at it dot uu.se]

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



--- Comment #3 from Mikael Pettersson  2012-11-19 
12:38:47 UTC ---

(In reply to comment #2)

> It's http://gcc.gnu.org/ml/gcc-cvs/2012-11/msg00548.html



My bisection identified the same rev (193601).

[Bug rtl-optimization/52576] fib.c (attached) is slower on current (4.8.0) than 4.6.x

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-19

 CC||jakub at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Jakub Jelinek  2012-11-19 
12:49:07 UTC ---

Seems this has regressed (at least for -O3 -m64 -mtune=generic on SandyBridge

CPU) with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179284 and improved

again (in fact, seems to be faster than before) with LRA merge

http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192719 .  So, can we mark this

as fixed for 4.8?

[Bug c++/54207] [4.7/4.8 Regression] ICE in build_noexcept_spec when bool is #defined/typedef'd

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org

   Target Milestone|--- |4.7.3

[Bug c++/55392] Internal compiler error in get_expr_operands, c++11 without optimization

[markus at trippelsdorf dot de]

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



Markus Trippelsdorf  changed:



   What|Removed |Added



 CC||markus at trippelsdorf dot

   ||de



--- Comment #3 from Markus Trippelsdorf  
2012-11-19 12:51:51 UTC ---

Most likely a dup of Bug 53137.

[Bug other/55389] library cannot be rebuilt by make all-target

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-19

 CC||aoliva at gcc dot gnu.org,

   ||bonzini at gnu dot org,

   ||jakub at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Jakub Jelinek  2012-11-19 
13:02:03 UTC ---

Yeah, happened to me too.  Any ideas what needs to be done to fix this?

[Bug other/55389] library cannot be rebuilt by make all-target

[bonzini at gnu dot org]

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



--- Comment #2 from Paolo Bonzini  2012-11-19 13:05:51 
UTC ---

Can you post the full log of a rm+make?

[Bug c++/55392] Internal compiler error in get_expr_operands, c++11 without optimization

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|WAITING |UNCONFIRMED

 Ever Confirmed|1   |0



--- Comment #4 from Jonathan Wakely  2012-11-19 
13:30:09 UTC ---

(In reply to comment #2)

> I attached this file uncompressed to the original post, but it seems to have

> been to large.



Which is usually a hint you should reduce it:

http://gcc.gnu.org/bugs/minimize.html



However I think Markus is right and it's probably a dup anyway.

[Bug c++/54325] [4.7/4.8 Regression] C++11 uniform initialization syntax for argument-less abstract base class constructor fails

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org,

   ||jason at gcc dot gnu.org

   Target Milestone|--- |4.7.3



--- Comment #3 from Jakub Jelinek  2012-11-19 
13:33:41 UTC ---

I think this is probably caused by

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

[Bug c++/41958] [c++0x] bogus variadic partial ordering code

[jason at gcc dot gnu.org]

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



--- Comment #9 from Jason Merrill  2012-11-19 
13:42:06 UTC ---

(In reply to comment #8)

> The note describing the resolution of 1395 says "preferring an omitted

> parameter over a parameter pack".



"omitted parameter" here means no parameter.  The second overload has a

parameter, 'd'.

[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release

[jakub at gcc dot gnu.org]

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



--- Comment #11 from Jakub Jelinek  2012-11-19 
13:44:21 UTC ---

Author: jakub

Date: Mon Nov 19 13:44:15 2012

New Revision: 193620



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

Log:

PR middle-end/54630

* tree-ssa-coalesce.c (coalesce_ssa_name): Remove static

keyword from ssa_name_hash var.



* class.c (fixed_type_or_null_ref_ht): New variable.

(fixed_type_or_null): Use it instead of local static ht.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/class.c

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-ssa-coalesce.c

[Bug c++/55394] Using call_once without -lpthread compiles without warning

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



   Severity|normal  |enhancement



--- Comment #1 from Jonathan Wakely  2012-11-19 
13:44:48 UTC ---

(In reply to comment #0)

> A source file which contains call_once will compile without any errors or

> warnings, even when libpthread is not linked.



Obviously this is because compiling and linking are separate steps. The

compiler front-end doesn't know in advance whether the linker will be invoked

correctly.



It might be possible to do something similar to PR 52681 to improve the

exception's message.

[Bug other/55333] libsanitizer StackTrace::FastUnwindStack wrong x32

[konstantin.s.serebryany at gmail dot com]

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



Konstantin Serebryany  changed:



   What|Removed |Added



 CC||konstantin.s.serebryany at

   ||gmail dot com



--- Comment #4 from Konstantin Serebryany  2012-11-19 13:59:31 UTC ---

upstream: http://llvm.org/viewvc/llvm-project?rev=168306&view=rev

[Bug rtl-optimization/55393] gcc/g++ multiplies two unsigned integers using the IMULQ instruction

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #1 from Jakub Jelinek  2012-11-19 
14:02:38 UTC ---

99UL is 0xde0b6b3a763UL, that definitely doesn't have bit

63 set, and that times 1024UL is 0x82dace9d8c00UL which is bigger than

0xde0b6b3a763UL, so can you shed some light why you think it should print

overflow?  I don't see any bug in the generated code, only in your assumptions.

[Bug c++/55261] [C++0x] ICE (SIGSEGV) when inheriting implicit constructor

[jason at gcc dot gnu.org]

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



--- Comment #1 from Jason Merrill  2012-11-19 
14:05:46 UTC ---

Author: jason

Date: Mon Nov 19 14:05:36 2012

New Revision: 193621



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

Log:

PR c++/55261

* class.c (add_implicitly_declared_members): Use

lookup_fnfields_slot to get the base constructors.



Added:

trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor14.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/class.c

[Bug c++/55262] [C++0x] g++.dg/cpp0x/inh-ctor10.C ICEs with -g

[jason at gcc dot gnu.org]

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



--- Comment #1 from Jason Merrill  2012-11-19 
14:05:58 UTC ---

Author: jason

Date: Mon Nov 19 14:05:48 2012

New Revision: 193622



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

Log:

PR c++/55262

* method.c (implicitly_declare_fn): Set DECL_PARM_INDEX on

the parms of an inheriting ctor.



Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/method.c

trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor10.C

[Bug bootstrap/54329] [4.8 Regression] gcc/cfgcleanup.o differs

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2012-11-19

 CC||jakub at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #8 from Jakub Jelinek  2012-11-19 
14:36:53 UTC ---

Can you still reproduce it?  Are you using stock trunk, not some extra patches

on top of it?  If you rebuild the source file which failed checksum checking

with the options passed to g++ normally to compile it plus -fcompare-debug,

does it fail with an -fcompare-debug failure?  If yes, please attach the

preprocessed source of it and all command line options.

[Bug c++/55368] Comma before semicolon in struct definition is not rejected

[paolo at gcc dot gnu.org]

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



--- Comment #2 from paolo at gcc dot gnu.org  
2012-11-19 14:41:33 UTC ---

Author: paolo

Date: Mon Nov 19 14:41:26 2012

New Revision: 193624



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

Log:

/cp

2012-11-19  Paolo Carlini  



PR c++/55368

* parser.c (cp_parser_member_declaration): Emit an error in case

of stray comma at end of member declaration.



/testsuite

2012-11-19  Paolo Carlini  



PR c++/55368

* g++.dg/parse/struct-5.C: New.



Added:

trunk/gcc/testsuite/g++.dg/parse/struct-5.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/parser.c

trunk/gcc/testsuite/ChangeLog

[Bug c++/55368] Comma before semicolon in struct definition is not rejected

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #3 from Paolo Carlini  2012-11-19 
14:42:48 UTC ---

Fixed for 4.8.0.

[Bug c++/55261] [C++0x] ICE (SIGSEGV) when inheriting implicit constructor

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #2 from Paolo Carlini  2012-11-19 
14:50:15 UTC ---

Fixed for 4.8.0.

[Bug c++/55262] [C++0x] g++.dg/cpp0x/inh-ctor10.C ICEs with -g

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #2 from Paolo Carlini  2012-11-19 
14:51:13 UTC ---

Fixed for 4.8.0.

[Bug libstdc++/55394] Using call_once without -lpthread compiles without warning

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



  Component|c++ |libstdc++



--- Comment #2 from Paolo Carlini  2012-11-19 
14:55:50 UTC ---

Library anyway.

[Bug c++/55392] Internal compiler error in get_expr_operands, c++11 without optimization

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #5 from Paolo Carlini  2012-11-19 
14:58:49 UTC ---

Let's resolve as Dup and remember to double check the fix on this testcase too.



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

[Bug c++/53137] [4.7/4.8 Regression] g++ segfault

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC||david at aitellu dot com



--- Comment #13 from Paolo Carlini  2012-11-19 
14:58:49 UTC ---

*** Bug 55392 has been marked as a duplicate of this bug. ***

[Bug target/55276] [4.8 regression] ppc: callee-saved vector registers not preserved

[dje at gcc dot gnu.org]

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



David Edelsohn  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-19

 Ever Confirmed|0   |1



--- Comment #2 from David Edelsohn  2012-11-19 15:40:05 
UTC ---

The patch looks correct, but the testcase only demonstrates the problem by

looking at assembly, not by checking for correct results.

[Bug target/55351] can't build libgcc for -m5-compact variant in SH64

[nickc at redhat dot com]

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



--- Comment #1 from Nick Clifton  2012-11-19 16:01:36 
UTC ---

Created attachment 28732

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28732

Fixes to allow libgcc to build for the sh64-linux target



I am no SH expert, so this patch may well be wrong.  But it does allow libgcc

to built (for all supported multilibs) for the sh64-linux target.



There seem to be three problems:



  1. As reported in this PR, the sdivsi3 function is being built for the

L_div_table target when it clearly uses instructions that are not supported by

the target SH variant.  I have assumed that this is a mistake and so stopped

the function from being built for the m5-compact multilib.



  2. The udiv_qrnnd_16 function is not being built.  It is built for non-Linux

Sh targets, so I have assumed that it is an oversight and added it to the list

of functions to build.



  3. The m5-media64 and m5-media64-nofpu multilibs need the linker to support a

shlefl64_linux emulation.  The linker does not do this, so I have suppressed

all multilibs based on these options.

[Bug other/55389] library cannot be rebuilt by make all-target

[jakub at gcc dot gnu.org]

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



--- Comment #3 from Jakub Jelinek  2012-11-19 
16:10:38 UTC ---

Created attachment 28733

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28733

log



rm -rf x86_64-*/{,32/}libsanitizer; make all-target-libsanitizer

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[dodji at seketeli dot org]

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

--- Comment #6 from dodji at seketeli dot org  
2012-11-19 16:17:20 UTC ---
> I think this his how the macro expansion was designed to work: It
> shows the location of the token that triggered the error.

Yes.  And there are cases where the GCC way seems to make more sense;
for instance:
$ cat -n test.c
 1#define OPERATE(OPRD1, OPRT, OPRD2) \
 2  OPRD1 OPRT OPRD2;
 3
 4#define SHIFTL(A,B) \
 5  OPERATE (A,<<,B)
 6
 7#define MULT(A) \
 8  SHIFTL (A,1)
 9
10void
11g ()
12{
13  MULT (1.0);// 1.0 << 1; <-- so this is an error.
14}
$ 

With GCC:

./test.c: In function ‘g’:
./test.c:5:14: error: invalid operands to binary << (have ‘double’ and ‘int’)
   OPERATE (A,<<,B)
  ^
./test.c:2:9: note: in definition of macro ‘OPERATE’
   OPRD1 OPRT OPRD2;
 ^
./test.c:8:3: note: in expansion of macro ‘SHIFTL’
   SHIFTL (A,1)
   ^
./test.c:13:3: note: in expansion of macro ‘MULT’
   MULT (1.0);// 1.0 << 1; <-- so this is an error.
   ^
$

With Clang:

test.c:13:3: error: invalid operands to binary expression ('double' and 'int')
  MULT (1.0);// 1.0 << 1; <-- so this is an error.
  ^~
test.c:8:3: note: expanded from macro 'MULT'
  SHIFTL (A,1)
  ^
test.c:5:14: note: expanded from macro 'SHIFTL'
  OPERATE (A,<<,B)
 ^
test.c:2:9: note: expanded from macro 'OPERATE'
  OPRD1 OPRT OPRD2;
  ~ ^~
1 error generated.
$

So, at line 13.3, I think it doesn't make sense to talk about a binary
expression (which is related to the '<<' operator).

So yes, we chose to first point to the token on which the error
appeared, and then print the context of the macro expansion all the way
to the expansion point.

Now I am not sure what the best approach should be.

> I also agree that the clang way makes more sense in this case.

Indeed.

[Bug c++/55355] internal compiler error: in tree_low_cst, at tree.c:6415

[rcp at sentientmeat dot ca]

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



Richard Perrin  changed:



   What|Removed |Added



 Status|RESOLVED|UNCONFIRMED

 Resolution|WORKSFORME  |



--- Comment #5 from Richard Perrin  2012-11-19 
16:18:58 UTC ---

I really am relying on a fix in 4_6-branch (perhaps back-port of the fix that's

in 4.7?). Other issues prevent us from adopting gcc 4.7.

[Bug translation/53764] Typo in translatable string: "literalto"

[ian at gcc dot gnu.org]

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



--- Comment #1 from ian at gcc dot gnu.org  2012-11-19 
16:28:17 UTC ---

Author: ian

Date: Mon Nov 19 16:28:04 2012

New Revision: 193626



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

Log:

PR translation/53764

compiler: Fix typo in error message.



Reported by Roland Stigge.



Modified:

trunk/gcc/go/gofrontend/parse.cc

[Bug translation/53764] Typo in translatable string: "literalto"

[ian at airs dot com]

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



Ian Lance Taylor  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 CC||ian at airs dot com

Version|4.7.1   |4.8.0

 Resolution||FIXED



--- Comment #2 from Ian Lance Taylor  2012-11-19 16:29:28 
UTC ---

Fixed in mainline.  Thanks.

[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields

[volodya at netfolder dot ru]

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

--- Comment #7 from Vladimir  2012-11-19 16:31:15 
UTC ---
OK, I will see this message soon.

P.S. For now, I have to use Intel Compiller, which isn't good due limited
platform support (x86 and amd64).
---Исходное сообщение---
От: "redi at gcc dot gnu.org"
Отпр.:  19.11.2012, 15:47 
Кому: volo...@netfolder.ru
Тема: [Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields



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

--- Comment #5 from Jonathan Wakely  2012-11-19
11:47:20 UTC ---
(In reply to comment #4)
> Is this bug planned to be fixed in future?

Yes, of course. It's a bug.

> Can I help in any way to do that?

Sure, you could look in gcc/cp/*.c for the message
  "bit-field .* with non-integral type"
and see what conditions it depends on and why it disallows scoped enumeration
types.

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[dodji at seketeli dot org]

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

--- Comment #7 from dodji at seketeli dot org  
2012-11-19 16:34:11 UTC ---
"manu at gcc dot gnu.org"  a écrit:

> On the other hand, let's consider:
> pr55252.c:
>
> #define bar 256
> #include "pr55252.h"
>
> pr55252.h:
>
> #pragma GCC system_header
> signed char foo = bar;
>
>
>
> In this case, I would expect the warning to be suppressed (as it is with
>
> -ftrack-macro-expansion=0). However, since the warning is actually
> given in the C file, it is emitted. I am getting more and more
> convinced that expanding to spelling point might not be the best (I
> think Paolo Bonzini raised this issue at the time...).

I am thinking that a way to really handle this correctly is to have the
concept of the location of the "current expression", which the current
token belongs to.

In this case, we are emitting the warning on the token 'bar' (which is
spelled in the C file), while the relevant expression (the variable
declaration) is in a header file.

The diagnostics machinery should be able to say "is the current
expression in a header file?", and act appropriately.

Would that make sense in the grand scheme of things?

[Bug target/54083] FAIL: gcc.dg/torture/pr53922.c on *-apple-darwin*

[dominiq at lps dot ens.fr]

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



--- Comment #11 from Dominique d'Humieres  
2012-11-19 16:48:30 UTC ---

Author:hjl

Date:Mon Nov 5 21:59:49 2012 UTC (13 days, 18 hours ago)

New Revision: 193193



URL: http://gcc.gnu.org/viewcvs?view=revision&sortby=date&revision=193193

Log:

* gcc.dg/torture/pr53922.c: Use -Wl,-undefined,dynamic_lookup on

darwin.



Modified:

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/gcc.dg/torture/pr53922.c



This does not fix the failures for powerpc-apple-darwin9.

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[manu at gcc dot gnu.org]

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

--- Comment #8 from Manuel López-Ibáñez  2012-11-19 
16:50:34 UTC ---
(In reply to comment #7)
> Would that make sense in the grand scheme of things?

The idea seems good. It would also handle comment #4 testcase. However, I am
not sure how you would implement this.

A different issue is why the macro unwinder cares about system-headers? See
comment #3.

[Bug target/55276] [4.8 regression] ppc: callee-saved vector registers not preserved

[dje at gcc dot gnu.org]

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



--- Comment #3 from David Edelsohn  2012-11-19 16:58:42 
UTC ---

Author: dje

Date: Mon Nov 19 16:58:31 2012

New Revision: 193628



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

Log:

2012-11-19  Mans Rullgard  



PR target/55276

* config/rs6000/rs6000.c (rs6000_stack_info): Always set vrsave_mask

for TARGET_ALTIVEC_ABI.  Zero vrsave_save_offset if

!TARGET_ALTIVEC_VRSAVE.

(rs6000_emit_prologue): For SAVE_INLINE_VLRs, check vrsave_size

not vrsave_mask.



Modified:

trunk/gcc/ChangeLog

[Bug target/54083] FAIL: gcc.dg/torture/pr53922.c on *-apple-darwin*

[howarth at nitro dot med.uc.edu]

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



Jack Howarth  changed:



   What|Removed |Added



 CC||howarth at nitro dot

   ||med.uc.edu



--- Comment #12 from Jack Howarth  2012-11-19 
17:00:21 UTC ---

(In reply to comment #11)

> Author:hjl

> Date:Mon Nov 5 21:59:49 2012 UTC (13 days, 18 hours ago)

> New Revision: 193193

> 

> URL: http://gcc.gnu.org/viewcvs?view=revision&sortby=date&revision=193193

> Log:

> * gcc.dg/torture/pr53922.c: Use -Wl,-undefined,dynamic_lookup on

> darwin.

> 

> Modified:

> trunk/gcc/testsuite/ChangeLog

> trunk/gcc/testsuite/gcc.dg/torture/pr53922.c

>  

> This does not fix the failures for powerpc-apple-darwin9.



This is will never be fixable for darwin9 short of using a newer linker as the

test case for radr://10466868, "-undefined dynamic_lookup linker bug" fails

under Xcode 3.1.4.



17-Nov-2011 08:22 PM Jack Howarth:

Summary: The following weak.c test case reveals a linker bug in -undefined

dynamic_lookup in Xcode 4.2/4.2.1 under both darwin10 and darwin11.



--- weak.c -

#include 



char *myweakfunc(void) __attribute__((weak)) ;



int main(int argc, char **argv)

{

  if (myweakfunc)

printf ("found myweakfunc %s\n", myweakfunc());

  else

printf("Weak func not found\n");

  return 0;

}

---



Steps to Reproduce:

1) Install Xcode 4.2 on darwin10 or darwin11.

2) Compile the weak.c test case with...



/usr/bin/llvm-gcc weak.c -o wk -undefined dynamic_lookup



3) Execute the resulting "wk" executable



Expected Results:



I expected the same results as is seen when the weak.c test case is compiled

with llvm-gcc from Xcode 3.2.6...



howarth% /Developer-3.2.6/usr/bin/llvm-gcc weak.c -o wk -undefined

dynamic_lookup

howarth% ./wk

Weak func not found



Actual Results:



The resulting binary fails to execute with the runtime error...



dyld: Symbol not found: _myweakfunc

  Referenced from: /Users/howarth/./wk

  Expected in: flat namespace

 in /Users/howarth/./wk

Trace/BPT trap



This behavior was works in Xcode 3.2.6 up to Xcode 4.2 where it was broken

again. It was fixed again after Xcode 4.4.1 and we should be careful to test

for this linker behavior in the FSF gcc testsuite to insure that Apple doesn't

break it again.



Note that MacPorts provides an ld64 package on powerpc darwin9 which is based

on the linker from Xcode 3.2.6 which should work.

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[dodji at seketeli dot org]

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

--- Comment #9 from dodji at seketeli dot org  
2012-11-19 17:05:57 UTC ---
"manu at gcc dot gnu.org"  a écrit:

> Hum, I am not sure why the macro unwinder avoids unwinding if the
> macro comes from a system-header. If a warning message comes from a
> system-header, then it should have been suppressed earlier and never
> reach the macro unwinder.  Otherwise, we already have emitted the
> diagnostic, so the macro unwinder just provides more context.

Yeah. I agree this is weird.

There are cases where the spelling location is in normal main file, but
some locations in its macro expansion context are e.g, for built-in
tokens.  In that case we can get ugly diagnostic prefixes like:

  :0:0: warning: conversion to 'float' alters 'int' constant value

This is what the commit r186970 tries to fix.  Please read the commit
log (that contains useful information about the context of the bug,
besides the ChangeLog that we like to put in there) of that revision to
understand why we are skipping each locus that comes from a system
header too.

I guess a way to handle this is to 

1/ make the macro unwinder call
linemap_unwind_to_first_non_reserved_loc at the beginning of the
unwind process and start unwinding from there

2/  during the rest of the unwind process, dismiss reserved
locations only.  Not those coming from system headers.

Would this make sense?

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[dodji at seketeli dot org]

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

--- Comment #10 from dodji at seketeli dot org  
2012-11-19 17:18:00 UTC ---
"manu at gcc dot gnu.org"  a écrit:

> The idea seems good. It would also handle comment #4 testcase.

Yeah, and I think it would be a step in the direction of printing ranges
for expressions.  I know you and I share a (not so) secret dream of
seeing taht in GCC one day.  :-)

> However, I am not sure how you would implement this.

That is the real issue, I guess.

I suspect this could be like opening a can of worms.  In G++, I guess
I'd start with updating the hypothetical 'current expression' variable
in cp_parser_expression.  But then we need to handle tentative parsing.
That is, if we are in a tentative parse, save the new 'current
expression' on the side, and really save it when the parse is
committed.

And pray for the fall-outs to not be in the order of dozens.  :-)

> different issue is why the macro unwinder cares about system-headers? See
> comment #3.

Right, I have replied to that in an earlier comment.

Thanks.

[Bug c++/55355] internal compiler error: in tree_low_cst, at tree.c:6415

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||WORKSFORME



--- Comment #6 from Paolo Carlini  2012-11-19 
17:19:45 UTC ---

Very unlikely. If you find the patch which fixed it, and it's simple enough,

send a message to gcc or gcc-patches and try to ask.

[Bug c++/55355] internal compiler error: in tree_low_cst, at tree.c:6415

[rcp at sentientmeat dot ca]

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



--- Comment #7 from Richard Perrin  2012-11-19 
17:24:14 UTC ---

So 4.6 branch is dead? Or no more i386 support?

[Bug c++/55355] internal compiler error: in tree_low_cst, at tree.c:6415

[paolo.carlini at oracle dot com]

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



--- Comment #8 from Paolo Carlini  2012-11-19 
17:25:08 UTC ---

Note that, as I said already, I can't reproduce anywhere, not even in current

4_6-branch (on x86_64-linux -m32). Did you actually try it?

[Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu

[doko at gcc dot gnu.org]

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



 Bug #: 55395

   Summary: [4.8 Regression] libgfortran bootstrap failure on

powerpc-linux-gnu

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: d...@gcc.gnu.org





seen with Mon Nov 19 12:07:37 UTC 2012 (revision 193619), powerpc only:



/bin/bash ./libtool  --tag=CC   --mode=compile

/build/buildd/gcc-4.8-4.8-20121119/build/./gcc/xgcc

-B/build/buildd/gcc-4.8-4.8-20121119/build/./gcc/ -B/usr/powerpc-linux-gnu/bin/

-B/usr/powerpc-linux-gnu/lib/ -isystem /usr/powerpc-linux-gnu/include -isystem

/usr/powerpc-linux-gnu/sys-include-DHAVE_CONFIG_H -I.

-I../../../src/libgfortran  -iquote../../../src/libgfortran/io

-I../../../src/libgfortran/../gcc -I../../../src/libgfortran/../gcc/config 

-I../.././gcc -I../../../src/libgfortran/../libgcc -I../libgcc  -std=gnu99

-Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra

-Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections  -g -O2

-MT list_read.lo -MD -MP -MF .deps/list_read.Tpo -c -o list_read.lo `test -f

'io/list_read.c' || echo '../../../src/libgfortran/'`io/list_read.c

libtool: compile:  /build/buildd/gcc-4.8-4.8-20121119/build/./gcc/xgcc

-B/build/buildd/gcc-4.8-4.8-20121119/build/./gcc/ -B/usr/powerpc-linux-gnu/bin/

-B/usr/powerpc-linux-gnu/lib/ -isystem /usr/powerpc-linux-gnu/include -isystem

/usr/powerpc-linux-gnu/sys-include -DHAVE_CONFIG_H -I.

-I../../../src/libgfortran -iquote../../../src/libgfortran/io

-I../../../src/libgfortran/../gcc -I../../../src/libgfortran/../gcc/config

-I../.././gcc -I../../../src/libgfortran/../libgcc -I../libgcc -std=gnu99 -Wall

-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra

-Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2

-MT list_read.lo -MD -MP -MF .deps/list_read.Tpo -c

../../../src/libgfortran/io/list_read.c  -fPIC -DPIC -o .libs/list_read.o

../../../src/libgfortran/io/list_read.c:2382:21: error: endl causes a section

type conflict with endl

   static const char endl[] = "\n";

 ^

make[5]: *** [list_read.lo] Error 1

make[5]: Leaving directory

`/build/buildd/gcc-4.8-4.8-20121119/build/powerpc-linux-gnu/libgfortran'

make[4]: *** [all] Error 2

make[4]: Leaving directory

`/build/buildd/gcc-4.8-4.8-20121119/build/powerpc-linux-gnu/libgfortran'

make[3]: *** [all-target-libgfortran] Error 2

[Bug debug/55094] [4.7/4.8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2224

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org

   |gnu.org |



--- Comment #2 from Jakub Jelinek  2012-11-19 
17:37:28 UTC ---

Created attachment 28734

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28734

gcc48-pr55094.patch



Untested fix.

[Bug middle-end/55381] [4.8 Regression]: build fails on cris-elf building libgfortran with host-gcc-4.4, ICE compiling matmul_i1.c

[pthaugen at gcc dot gnu.org]

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



Pat Haugen  changed:



   What|Removed |Added



 CC||pthaugen at gcc dot gnu.org



--- Comment #5 from Pat Haugen  2012-11-19 
17:49:21 UTC ---

I'm seeing the same failure for PowerPC build of trunk.

[Bug bootstrap/55384] [4.8 Regresson] VEC merge AIX bootstrap failure

[dje at gcc dot gnu.org]

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



--- Comment #6 from David Edelsohn  2012-11-19 18:07:35 
UTC ---

Author: dje

Date: Mon Nov 19 18:07:21 2012

New Revision: 193629



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

Log:

Add PR bootstrap/55384 to ChangeLog entry.



Modified:

trunk/gcc/ChangeLog

[Bug middle-end/54921] [4.8 Regression] wrong code with -Os -fno-omit-frame-pointer -fsched2-use-superblocks -fstack-protector -ftree-slp-vectorize

[jakub at gcc dot gnu.org]

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



--- Comment #4 from Jakub Jelinek  2012-11-19 
18:07:33 UTC ---

Created attachment 28735

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28735

gcc48-pr54921.patch



Untested updated patch.

[Bug bootstrap/55384] [4.8 Regresson] VEC merge AIX bootstrap failure

[dje at gcc dot gnu.org]

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



David Edelsohn  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #7 from David Edelsohn  2012-11-19 18:15:24 
UTC ---

Patch to system.h committed.

[Bug target/55276] [4.8 regression] ppc: callee-saved vector registers not preserved

[dje at gcc dot gnu.org]

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



David Edelsohn  changed:



   What|Removed |Added



 Status|NEW |WAITING



--- Comment #4 from David Edelsohn  2012-11-19 18:16:32 
UTC ---

I committed the patch, but this should have a testcase as well.

[Bug rtl-optimization/55360] [TileGX] Passing structure by value on stack needlessly writes to and reads from memory

[colanderman at gmail dot com]

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



--- Comment #2 from Chris King  2012-11-19 
18:47:39 UTC ---

Possibly, though I doubt it.  PR 28831 has more to do with eliding copies of

the struct in its entirety; the problem I'm having centers around accessing

individual elements.  If PR 28831 were the cause, I would expect both my test

cases (with and without bit-fields) to behave identically, however they do not.



It's possible that fixing PR 28831 may hide this bug in my particular use case

(by avoiding the stack allocation in the first place), but I believe the

difference in handling of normal fields vs. bit fields to be a distinct bug.

[Bug middle-end/32647] spill failures with hard-register variable

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



 CC||vmakarov at gcc dot gnu.org

  Known to fail||



--- Comment #2 from Uros Bizjak  2012-11-19 18:50:46 
UTC ---

Adding CC.

[Bug middle-end/55359] [4.8 Regression] ICE in simplify_subreg accessing an unaligned subvector

[rsandifo at gcc dot gnu.org]

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



--- Comment #2 from rsandifo at gcc dot gnu.org  
2012-11-19 19:00:01 UTC ---

Sorry for the breakage.



(In reply to comment #1)

> Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192741

> lowpart_bit_field_p looks weird, I don't see how BITS_PER_WORD is relevant

> there, what IMHO matters is whether the subreg is valid or not.  While the

> first hunk that uses this function uses validate_subreg, the second one 
> doesn't

> and

> attempts to create an invalid subreg (subreg:V2DF (reg:OI) 8), where the byte

> offset is not a multiple of V2DFmode size.



I suppose we're going to have to decide whether simplify_subreg should

do the validation itself, or whether it's up to the caller.

simplify_subreg asserts things that validate_subreg checks,

which implies the latter, but simplify_gen_subreg explicitly

calls validate_subreg.



Personally I'd prefer it if simplify_subreg and simplify_gen_subreg

checked for invalid subregs and return null.  Does that sound OK?

[Bug middle-end/55359] [4.8 Regression] ICE in simplify_subreg accessing an unaligned subvector

[jakub at gcc dot gnu.org]

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



--- Comment #3 from Jakub Jelinek  2012-11-19 
19:11:29 UTC ---

Guess it is ok.

[Bug middle-end/55359] [4.8 Regression] ICE in simplify_subreg accessing an unaligned subvector

[rsandifo at gcc dot gnu.org]

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



rsand...@gcc.gnu.org  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |rsandifo at gcc dot gnu.org

   |gnu.org |



--- Comment #4 from rsandifo at gcc dot gnu.org  
2012-11-19 19:13:37 UTC ---

OK, thanks, I'll give it a go.

[Bug c++/55385] g++ failed to call final overrider of a virtual function.

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #1 from Daniel Krügler  
2012-11-19 19:16:43 UTC ---
I can see the exact same behaviour in gcc 4.8.0 20121104 (experimental).

I agree that the current behaviour looks like a defect defect and my tentative
guess is that this might be due to

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#608

[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

[hjl at gcc dot gnu.org]

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



--- Comment #38 from hjl at gcc dot gnu.org  2012-11-19 
19:17:17 UTC ---

Author: hjl

Date: Mon Nov 19 19:17:05 2012

New Revision: 193635



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

Log:

Workaround PR middle-end/55142



gcc/



2012-11-19  H.J. Lu  



Backported from mainline

2012-11-13  Eric Botcazou  

H.J. Lu  



PR middle-end/55142

* config/i386/i386.c (legitimize_pic_address): Properly handle

REG + CONST.

(ix86_print_operand_address): Set code to 'k' when forcing

addr32 prefix.  For x32, zero-extend negative displacement if

it < -16*1024*1024.



gcc/testsuite/



2012-11-19  H.J. Lu  



Backported from mainline

2012-11-13  H.J. Lu  



PR middle-end/55142

* gcc.target/i386/pr55142-1.c: New file.

* gcc.target/i386/pr55142-2.c: Likewise.



Added:

branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/pr55142-1.c

branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/pr55142-2.c

Modified:

branches/gcc-4_7-branch/gcc/ChangeLog

branches/gcc-4_7-branch/gcc/config/i386/i386.c

branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug bootstrap/55388] [4.8 regression] ICE in int_mode_for_mode at stor-layout.c:423 breaks sparc64-linux bootstrap

[mikpe at it dot uu.se]

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



--- Comment #1 from Mikael Pettersson  2012-11-19 
19:32:37 UTC ---

Fails at r193600 so not the same reason as PR55391.  Bisecting...

[Bug c++/55367] Probably problem with c++ vptr under templates and multiple inheritance

[wriabi at email dot com]

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



--- Comment #6 from walid riabi  2012-11-19 19:48:12 
UTC ---

I'm a candidate:)

[Bug rtl-optimization/55396] New: -O2 -m32 -fno-omit-frame-pointer: internal compiler error: in check_rtl, at lra.c:2007

[gcc at breakpoint dot cc]

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



 Bug #: 55396

   Summary: -O2 -m32 -fno-omit-frame-pointer: internal compiler

error: in check_rtl, at lra.c:2007

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: rtl-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: g...@breakpoint.cc





Created attachment 28736

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28736

pre-processed file



Compiling the linux kernel ends with:



|kernel/sched/core.c: In function '__schedule':

|kernel/sched/core.c:2891:1: internal compiler error: in check_rtl, at

lra.c:2007

| }

| ^



While removing Compiler options the ICE goes away if one of the following

options 

is removed: "-O2 -m32 -fno-omit-frame-pointer"



gcc -v says:

Using built-in specs.

COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gcc

COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.8.0/lto-wrapper

Target: x86_64-linux-gnu

Configured with: ../src/configure -v --with-pkgversion='Debian 20121116-1'

--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs

--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++

--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id

--with-system-zlib --disable-nls --with-sysroot=/ --enable-clocale=gnu

--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object

--enable-plugin --disable-browser-plugin --enable-java-awt=gtk

--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-snap/jre

--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-snap

--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-snap

--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar

--enable-objc-gc --with-arch-32=i586 --with-abi=m64

--with-multilib-list=m32,m64 --with-tune=generic --disable-werror

--enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu

--target=x86_64-linux-gnu

Thread model: posix

gcc version 4.8.0 20121116 (experimental) [trunk revision 193562] (Debian

20121116-1)

[Bug other/55313] libsanitizer cannot be installed

[hjl.tools at gmail dot com]

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



--- Comment #6 from H.J. Lu  2012-11-19 20:54:53 
UTC ---

It works for me on Fedora 17 with



--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld

--enable-languages=c,ada,c++  --prefix=/usr/gcc-4.8.0

--with-local-prefix=/usr/local --enable-gnu-indirect-function

--build=x86_64-pc-linux-gnu --disable-libmudflap --disable-libstdcxx-pch

--disable-libada --enable-checking=yes,rtl

--with-bugurl=URL:mailto:rep...@adacore.com --disable-multilib

--with-fpmath=sse



Please show me the outputs of



# tail x86_64-pc-linux-gnu/libsanitizer/asan/libasan.la 

# tail x86_64-pc-linux-gnu/libstdc++-v3/src/libstdc++.la 



Are you using Debian?  What is the minimum configure option

to trigger this?

[Bug c/55397] New: [asan] -faddress-sanitizer should define a CPP macro

[hjl.tools at gmail dot com]

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



 Bug #: 55397

   Summary: [asan] -faddress-sanitizer should define a CPP macro

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: hjl.to...@gmail.com





See:



http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01601.html

[Bug bootstrap/54795] [4.8 Regression] Random profiledbootstrap failure with LTO

[hjl.tools at gmail dot com]

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



--- Comment #13 from H.J. Lu  2012-11-19 21:04:12 
UTC ---

On hjl/asan branch, I got



(gdb) r

Starting program:

/export/build/gnu/gcc-lto-asan/build-x86_64-linux/prev-gcc/cc1 -fpreprocessed

/tmp/x.i -quiet -dumpbase x.i -mtune=generic -march=x86-64 -auxbase x -version

-flto -o x.s

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib64/libthread_db.so.1".

GNU C (GCC) version 4.8.0 20121117 (experimental) (x86_64-unknown-linux-gnu)

compiled by GNU C version 4.8.0 20121117 (experimental), GMP version 5.0.2,

MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

GNU C (GCC) version 4.8.0 20121117 (experimental) (x86_64-unknown-linux-gnu)

compiled by GNU C version 4.8.0 20121117 (experimental), GMP version 5.0.2,

MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

Compiler executable checksum: 0e1eacd90672aa3f29692f9d3d99b1be

=



Breakpoint 5, __asan_report_error (pc=25644090, bp=140737488345632, 

sp=140737488345624, addr=34167900, is_write=, access_size=4)

at /export/gnu/import/git/gcc/libsanitizer/asan/asan_report.cc:464

464 bug_descr, (void*)addr, pc, bp, sp);

(gdb) bt

#0  __asan_report_error (pc=25644090, bp=140737488345632, sp=140737488345624, 

addr=34167900, is_write=, access_size=4)

at /export/gnu/import/git/gcc/libsanitizer/asan/asan_report.cc:464

#1  0x01f6bc04 in __asan::__asan_report_load4 (addr=)

at /export/gnu/import/git/gcc/libsanitizer/asan/asan_rtl.cc:194

#2  0x01874c3a in lto_write_options ()

at /export/gnu/import/git/gcc/gcc/lto-opts.c:92

#3  0x0135e932 in produce_asm_for_decls ()

at /export/gnu/import/git/gcc/gcc/lto-streamer-out.c:1407

#4  0x012a3458 in ipa_write_summaries_2(opt_pass*, lto_out_decl_state*)

[clone .565573] (pass=0x2689880 , 

state=0x718cce40) at /export/gnu/import/git/gcc/gcc/passes.c:2430

#5  0x0135b2a0 in ipa_write_summaries_1 (encoder=0x77d6c5c0)

at /export/gnu/import/git/gcc/gcc/passes.c:2460

#6  ipa_write_summaries () at /export/gnu/import/git/gcc/gcc/passes.c:2514

#7  0x00b16399 in ipa_passes ()

at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1908

#8  compile () at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1994

#9  0x00b16d2a in finalize_compilation_unit ()

at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2122

#10 0x00b17271 in c_write_global_declarations ()

at /export/gnu/import/git/gcc/gcc/c/c-decl.c:10128

#11 0x00b2c258 in compile_file ()

---Type  to continue, or q  to quit---

at /export/gnu/import/git/gcc/gcc/toplev.c:559

#12 0x00b2e4b0 in do_compile ()

at /export/gnu/import/git/gcc/gcc/toplev.c:1881

#13 toplev_main (argc=14, argv=0x7fffe108)

at /export/gnu/import/git/gcc/gcc/toplev.c:1957

#14 0x0038f3a21675 in __libc_start_main () from /lib64/libc.so.6

#15 0x0056df51 in _start ()

(gdb) c

Continuing.

==1834== ERROR: AddressSanitizer global-buffer-overflow on address

0x02095c5c at pc 0x1874c3a bp 0x7fffda20 sp 0x7fffda18

READ of size 4 at 0x02095c5c thread T0

#0 0x1874c39

(/export/build/gnu/gcc-lto-asan/build-x86_64-linux/prev-gcc/cc1+0x1874c39)

0x02095c5c is located 4 bytes to the left of global variable '__FUNCTION__

(/tmp/ccHvMX0o.ltrans5.o)' (0x2095c60) of size 22

  '__FUNCTION__ (/tmp/ccHvMX0o.ltrans5.o)' is ascii string

'c_parser_if_statement'

0x02095c5c is located 30 bytes to the right of global variable

'__FUNCTION__ (/tmp/ccHvMX0o.ltrans5.o)' (0x2095c20) of size 30

  '__FUNCTION__ (/tmp/ccHvMX0o.ltrans5.o)' is ascii string

'c_parser_declaration_or_fndef'

Shadow byte and word:

  0x10412b8b: f9

  0x10412b88: f9 f9 f9 f9 00 00 06 f9

More shadow bytes:

  0x10412b68: f9 f9 f9 f9 00 00 03 f9

  0x10412b70: f9 f9 f9 f9 00 00 06 f9

  0x10412b78: f9 f9 f9 f9 00 00 03 f9

  0x10412b80: f9 f9 f9 f9 00 00 00 06

=>0x10412b88: f9 f9 f9 f9 00 00 06 f9

  0x10412b90: f9 f9 f9 f9 00 00 00 02

  0x10412b98: f9 f9 f9 f9 00 00 00 01

  0x10412ba0: f9 f9 f9 f9 00 00 06 f9

  0x10412ba8: f9 f9 f9 f9 00 00 04 f9

Stats: 2M malloced (2M for red zones) by 3332 calls

Stats: 0M realloced by 285 calls

Stats: 1M freed by 1187 calls

Stats: 0M really freed by 0 calls

Stats: 8M (2059 full pages) mmaped in 16 calls

  mmaps   by size class: 7:4095; 8:2047; 9:1023; 10:511; 11:255; 12:128; 13:64;

14:32; 15:16; 16:8; 17:20; 18:2; 

  mallocs by size class: 7:2075; 8:747; 9:65; 10:95; 11:226; 12:52; 13:44;

14:1; 15:5; 16:1; 17:20; 18:1; 

  frees   by size class: 7:457; 8:359; 9:46; 10:80; 11:154; 12:46; 13:20; 14:1;

15:4; 17:20; 

  rfrees  by size class: 

Stats: malloc large: 27 small slow: 54

==1834