[Bug inline-asm/51863] invlpg with -masm=intel generates memory operand size error in assembly stage

[th020394 at gmail dot com]

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

--- Comment #1 from Tyler Hardin  2012-01-15 
06:05:49 UTC ---
Created attachment 26328
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26328
A source file that generates the error.

[Bug inline-asm/51863] New: invlpg with -masm=intel generates memory operand size error in assembly stage

[th020394 at gmail dot com]

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

 Bug #: 51863
   Summary: invlpg with -masm=intel generates memory operand size
error in assembly stage
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: inline-asm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: th020...@gmail.com


The expected behavior would be to generate code analogous to that of the
default -masm=att, which uses no size prefixes to address the memory operand of
invlpg.

The actual behavior is that -masm=intel causes GCC to emit code that uses a
size prefix (like dword, byte, etc.) which causes an error in GAS when the code
is assembled.

The command that generates the error is:
gcc -masm=intel main.c

The same command without -masm=intel works.

Output of "gcc -v"
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6.1/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --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-plugin
--enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=i686-linux-gnu
--host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)

The system type is Linux Mint 12, but I've found the same bug in i686-elf for
GCC 4.6.2.

[Bug c/51862] Over optimization for assignments to char[] defined inner than used

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Andrew Pinski  2012-01-15 
04:46:59 UTC ---
This code is undefined in that buf escapes the scope which causes the undefined
behavior.
   {
char buf[4];
unsigned int ch = strtoul(++p, &pe, 16);
len = convert_UTF32_to_UTF8(buf, ch);
unescape = buf;
}

Any use of buf after the scope closes is undefined.  GCC 4.7.0 optimizes better
with respect of this undefinedness.

[Bug c/51862] Over optimization for assignments to char[] defined inner than used

[naruse at airemix dot jp]

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

--- Comment #1 from Yui NARUSE  2012-01-15 01:25:57 
UTC ---
Created attachment 26327
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26327
the preprocessed file

[Bug c/51862] New: Over optimization for assignments to char[] defined inner than used

[naruse at airemix dot jp]

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

 Bug #: 51862
   Summary: Over optimization for assignments to char[] defined
inner than used
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nar...@airemix.jp


GCC 4.7 optimization out assignments to char[] if the char[] is defined inner
than it is used.

The too simplified case is like following (func() changes buf and enough small
to inline):
char *res;
if (bool) {
  char buf[4];
  func(buf); 
  res = buf;
}
fprintf(stderr, "'%s'\n", res);

= gcc47 -v

Using built-in specs.
COLLECT_GCC=gcc47
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc47/gcc/x86_64-portbld-freebsd9.0/4.7.0/lto-wrapper
Target: x86_64-portbld-freebsd9.0
Configured with: ./../gcc-4.7-20111217/configure --disable-nls
--enable-languages=c,c++,fortran --libdir=/usr/local/lib/gcc47
--libexecdir=/usr/local/libexec/gcc47 --program-suffix=47
--with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc47/include/c++/
--with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local
--with-pkgversion='FreeBSD Ports Collection' --with-system-zlib
--disable-libgcj --prefix=/usr/local --mandir=/usr/local/man
--infodir=/usr/local/info/gcc47 --build=x86_64-portbld-freebsd9.0
Thread model: posix
gcc version 4.7.0 20111217 (experimental) (FreeBSD Ports Collection)

= the complete command line that triggers the bug

% gcc47 -O2 g.c&&./a.out # type "\u0061"
\u0061
1 ''

The resulted output must be following and works with -O0:
1 'a'

= the compiler output (error messages, warnings, etc.)

Using built-in specs.
COLLECT_GCC=gcc47
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc47/gcc/x86_64-portbld-freebsd9.0/4.7.0/lto-wrapper
Target: x86_64-portbld-freebsd9.0
Configured with: ./../gcc-4.7-20111217/configure --disable-nls
--enable-languages=c,c++,fortran --li
bdir=/usr/local/lib/gcc47 --libexecdir=/usr/local/libexec/gcc47
--program-suffix=47 --with-as=/usr/l
ocal/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc47/include/c++/ --with-ld
=/usr/local/bin/ld --with-libiconv-prefix=/usr/local --with-pkgversion='FreeBSD
Ports Collection' --
with-system-zlib --disable-libgcj --prefix=/usr/local --mandir=/usr/local/man
--infodir=/usr/local/i
nfo/gcc47 --build=x86_64-portbld-freebsd9.0
Thread model: posix
gcc version 4.7.0 20111217 (experimental) (FreeBSD Ports Collection)
COLLECT_GCC_OPTIONS='-O2' '-save-temps' '-v' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc47/gcc/x86_64-portbld-freebsd9.0/4.7.0/cc1 -E -quiet -v
g.c -mtune=generic -m
arch=x86-64 -O2 -fpch-preprocess -o g.i
ignoring nonexistent directory
"/usr/local/lib/gcc47/gcc/x86_64-portbld-freebsd9.0/4.7.0/../../../..
/../x86_64-portbld-freebsd9.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc47/gcc/x86_64-portbld-freebsd9.0/4.7.0/include
 /usr/local/include
 /usr/local/lib/gcc47/gcc/x86_64-portbld-freebsd9.0/4.7.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-O2' '-save-temps' '-v' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc47/gcc/x86_64-portbld-freebsd9.0/4.7.0/cc1
-fpreprocessed g.i -quiet -dumpbase g.c -mtune=generic -march=x86-64 -auxbase g
-O2 -version -o g.s
GNU C (FreeBSD Ports Collection) version 4.7.0 20111217 (experimental)
(x86_64-portbld-freebsd9.0)
compiled by GNU C version 4.7.0 20111217 (experimental), GMP version
5.0.2, MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (FreeBSD Ports Collection) version 4.7.0 20111217 (experimental)
(x86_64-portbld-freebsd9.0)
compiled by GNU C version 4.7.0 20111217 (experimental), GMP version
5.0.2, MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 7130d1c9d6c474bcedaf92254d46803f
COLLECT_GCC_OPTIONS='-O2' '-save-temps' '-v' '-mtune=generic' '-march=x86-64'
 /usr/local/bin/as -v -o g.o g.s
GNU assembler version 2.22 (x86_64-portbld-freebsd9.0) using BFD version (GNU
Binutils) 2.22
COMPILER_PATH=/usr/local/libexec/gcc47/gcc/x86_64-portbld-freebsd9.0/4.7.0/:/usr/local/libexec/gcc47/gcc/x86_64-portbld-freebsd9.0/4.7.0/:/usr/local/libexec/gcc47/gcc/x86_64-portbld-freebsd9.0/:/usr/local/lib/gcc47/gcc/x86_64-portbld-freebsd9.0/4.7.0/:/usr/local/lib/gcc47/gcc/x86_64-portbld-freebsd9.0/:/usr/local/lib/gcc47/gcc/x86_64-portbld-freebsd9.0/4.7.0/../../../../../x86_64-portbld-freebsd9.0/bin/
LIBRARY_PATH=/usr/local/lib/gcc47/gcc/x86_64-portbld-freebsd9.0/4.7.0/:/usr/local/lib/gcc47/gcc/x86_64-portbld-freebsd9.0/4.7.0/../../../../../x86_64-portbld-freebsd9.0/lib/:/usr/local/lib/gcc47/gcc/x86_64-portbld-freebsd9.0/4.7.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-O2'

[Bug target/51861] Incorrect generated code with __builtin_unreachable() on MIPS

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Andrew Pinski  2012-01-15 
00:03:46 UTC ---
Fixed by http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01991.html aka
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51187 .  This is already fixed. 
The issue is unreachable with switch statements and delay slot scheduling was
causing the issue.

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

[Bug rtl-optimization/51187] miscompilation of genrecog.c at -O2 for --target=avr

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||maarten at treewalker dot
   ||org

--- Comment #11 from Andrew Pinski  2012-01-15 
00:03:46 UTC ---
*** Bug 51861 has been marked as a duplicate of this bug. ***

[Bug fortran/40963] ICE segfault - c_loc with derived type component as argument

[pastewka at gmail dot com]

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

Lars Pastewka  changed:

   What|Removed |Added

 CC||pastewka at gmail dot com

--- Comment #4 from Lars Pastewka  2012-01-14 
23:50:04 UTC ---
I encountered the same bug in gfortran 4.7.0 20110329 and 4.5.2.

Are there any updates on this bug?

[Bug target/51861] New: Incorrect generated code with __builtin_unreachable() on MIPS

[maarten at treewalker dot org]

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

 Bug #: 51861
   Summary: Incorrect generated code with __builtin_unreachable()
on MIPS
Classification: Unclassified
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: maar...@treewalker.org
  Host: i686-linux
Target: mipsel-linux
 Build: i686-linux


Created attachment 26326
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26326
Minimal test case

If I compile the attached test case for little endian MIPS with the options
"-O2 -march=mips32", the generated code will hang at runtime instead of
returning the correct value (30).

Minor changes to the code can produce a correct answer, a segfault, or various
wrong answers. The test case is relatively large for a minimal test case (about
30 lines), but I couldn't reduce it any further.

The original problem also occurs with GCC 4.6.1; I haven't tested the test case
with that version.

The problem occurs at -O2 and -O3, not at lower optimization levels; I haven't
tested higher levels.

Without the "-march=mips32" option I get the wrong answer (20), but no hang.

When compiling for x86_64 the problem does not occur.

The problem occurs with both the C and the C++ compiler.

When compiling to an object file, the fetch_value() function is just 5
instructions when the generated code is bad, while it is over 20 instructions
when the generated code is correct (for example, at -O1 or if the unused "case
4:" is commented out). So perhaps an invalid optimization is performed.

For easier testing, you can enable the printf: this doesn't change the behavior
related to the bug, but it does violate the demand for test cases to have no
external dependencies, so I used the return value of main() for the submitted
version.



GCC was configured with:
/home/mth/opendingux-buildroot/output/toolchain/gcc-4.5.1/configure
--prefix=/opt/opendingux-toolchain/usr --build=i686-pc-linux-gnu
--host=i686-pc-linux-gnu --target=mipsel-unknown-linux-uclibc
--enable-languages=c,c++ --with-sysroot=/opt/opendingux-toolchain
--with-build-time-tools=/opt/opendingux-toolchain/usr/mipsel-unknown-linux-uclibc/bin
--disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --disable-libssp
--disable-multilib --disable-tls --enable-shared
--with-gmp=/home/mth/opendingux-buildroot/output/toolchain/gmp
--with-mpfr=/home/mth/opendingux-buildroot/output/toolchain/mpfr
--with-mpc=/home/mth/opendingux-buildroot/output/toolchain/mpc --disable-nls
--enable-threads --disable-decimal-float --with-float=soft --with-abi=32
--with-tune=mips32 --with-pkgversion='Buildroot 2010.11-g76b414b'
--with-bugurl=http://bugs.buildroot.net/

[Bug target/22473] FAIL: gcc.c-torture/execute/conversion.c execution -O[012]

[danglin at gcc dot gnu.org]

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

--- Comment #5 from John David Anglin  2012-01-14 
21:17:03 UTC ---
(In reply to comment #4)
> This is a binutils bug.  Single word conversions need to
> use the 0E opcode rather than the 0C opcode that's currently
> generated for fcnv,t,sgl,uwd.

Changed my mind.  The same code doesn't fail on HP-UX.  This
appears to be a Linux kernel bug as the instruction seems
to be emulated.

[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto

[pinskia at gcc dot gnu.org]

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

--- Comment #31 from Andrew Pinski  2012-01-14 
19:01:47 UTC ---
(In reply to comment #20)
> Doesn't powerpc-darwin have the same problem? 

Yes that was recorded in PR 10901 :)

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[redi at gcc dot gnu.org]

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

--- Comment #51 from Jonathan Wakely  2012-01-14 
18:12:25 UTC ---
Created attachment 26325
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26325
enable  tests on aix

David, would you be able to apply this patch and let me know the results of
running the libstdc++ testsuite?
(Just "make check RUNTESTFLAGS=conformance.exp=30_threads/*" in the
libstdc++-v3 build dir, if you don't want to wait for the whole testsuite to
finish.)

It enables a subset of the 30_threads test for AIX, if these pass we can try
enabling some more, if they fail then I'll try to find out why.

[Bug other/50925] [4.7 Regression][avr] ICE at spill_failure, at reload1.c:2118

[denisc at gcc dot gnu.org]

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

--- Comment #15 from denisc at gcc dot gnu.org 2012-01-14 18:11:33 UTC ---
Author: denisc
Date: Sat Jan 14 18:11:29 2012
New Revision: 183183

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183183
Log:
PR target/50925
* config/avr/avr-protos.h: Revert change of 2012-01-09.
* config/avr/avr.c: Likewise.
* config/avr/avr.h: Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr-protos.h
trunk/gcc/config/avr/avr.c
trunk/gcc/config/avr/avr.h

[Bug rtl-optimization/48496] [4.7 Regression] 'asm' operand requires impossible reload in libffi/src/ia64/ffi.c

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  2012-01-14 
17:45:28 UTC ---
Doesn't this code violate strict aliasing though?  And, it passes with
-fno-strict-aliasing.  Therefore, I think it would be better to fix up the
strict aliasing violation in libffi. completely untested patch:

--- libffi/src/ia64/ffi.c2010-08-11 21:08:14.0 +0200
+++ libffi/src/ia64/ffi.c2012-01-14 18:43:35.652923850 +0100
@@ -324,13 +324,17 @@ ffi_call(ffi_cif *cif, void (*fn)(void),
 case FFI_TYPE_FLOAT:
   if (gpcount < 8 && fpcount < 8)
 stf_spill (&stack->fp_regs[fpcount++], *(float *)avalue[i]);
-  stack->gp_regs[gpcount++] = *(UINT32 *)avalue[i];
+  {
+UINT32 tmp;
+memcpy (&tmp, avalue[i], sizeof (UINT32));
+stack->gp_regs[gpcount++] = tmp;
+  }
   break;

 case FFI_TYPE_DOUBLE:
   if (gpcount < 8 && fpcount < 8)
 stf_spill (&stack->fp_regs[fpcount++], *(double *)avalue[i]);
-  stack->gp_regs[gpcount++] = *(UINT64 *)avalue[i];
+  memcpy (&stack->gp_regs[gpcount++], avalue[i], sizeof (UINT64));
   break;

 case FFI_TYPE_LONGDOUBLE:

With that IMHO this should be just a P2, not P1.

[Bug c++/14179] [4.4/4.5/4.6/4.7 Regression] out of memory while parsing array with many initializers

[jason at gcc dot gnu.org]

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

--- Comment #64 from Jason Merrill  2012-01-14 
17:06:46 UTC ---
Yep, it turned out that there was a lot of allocation overhead from vector
allocation in the token buffer.  After fixing that as well with the patch at

http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00732.html

this testcase is down to 967MB VM size.  The only obvious area of improvement
left is the 67MB of garbage from unnecessary reshape_init copying, which seems
like more work than it's worth for this testcase, and definitely not something
for 4.7.

[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto

[jakub at gcc dot gnu.org]

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

--- Comment #30 from Jakub Jelinek  2012-01-14 
16:56:10 UTC ---
(In reply to comment #28)
> Created attachment 26324 [details]
> a first attempt at a fix
> 
> this is pretty much the first ever RTL I've written 
> ... so comments welcome ... 
> 
> I've had a quick look at the output on a couple of test-cases and it seems to
> DTRT .. but it's "hardly tested" so far.

That #if TARGET_MACHO and if (TARGET_MACHO) is unneeded, the condition already
guards it.  If it was using some darwin specific functions or macros, you'd
just surround the body in #if TARGET_MACHO.
Furthermore, you don't know during expansion whether the PIC pointer will be
emitted or not, therefore probably the nonlocal goto receiver (with the
condition you've used) should be initially an instruction with unspec_volatile
UNSPECV_NONLOCAL_GOTO_RECEIVER or so, and only split after prologue is emitted,
either into nothing (if the PIC register doesn't need to be restored), or to
the actual instructions.

[Bug c++/51832] [4.7 regression] Rev.182970 causes LTO link errors (multiple definitions of allocator_traits)

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-14
 CC||steven at gcc dot gnu.org
 Ever Confirmed|0   |1

[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto

[iains at gcc dot gnu.org]

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

--- Comment #29 from Iain Sandoe  2012-01-14 16:37:38 
UTC ---
never mind, it doesn't bootstrap...

[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto

[iains at gcc dot gnu.org]

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

--- Comment #28 from Iain Sandoe  2012-01-14 15:58:32 
UTC ---
Created attachment 26324
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26324
a first attempt at a fix

this is pretty much the first ever RTL I've written 
... so comments welcome ... 

I've had a quick look at the output on a couple of test-cases and it seems to
DTRT .. but it's "hardly tested" so far.

[Bug libstdc++/51823] [DR 198] reverse iterator returns uninitialized values

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  2012-01-14 
15:43:52 UTC ---
Created attachment 26323
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26323
implement DR 198

it's ugly, but it works

[Bug c++/14179] [4.4/4.5/4.6/4.7 Regression] out of memory while parsing array with many initializers

[hubicka at ucw dot cz]

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

--- Comment #63 from Jan Hubicka  2012-01-14 14:18:27 
UTC ---
> Making the change to convert_to_integer mentioned in 12245 reduces VM size to
> 1509M; there's another 190M of garbage from cp_parser_initializer_list, but
> that still doesn't account for all the increase in VM size.
--enable-gather-detailed-mem-stats dump should pinpoint this quite easilly...

Honza

[Bug fortran/51800] [4.6/4.7 Regression] Error: Automatic array 'dummy' at (1) cannot have an initializer

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #6 from Tobias Burnus  2012-01-14 
13:28:58 UTC ---
FIXED on the trunk (4.7) and on the 4.6 branch.

Thanks Mario for the report!

[Bug fortran/51800] [4.6/4.7 Regression] Error: Automatic array 'dummy' at (1) cannot have an initializer

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2012-01-14 
13:28:10 UTC ---
Author: burnus
Date: Sat Jan 14 13:28:05 2012
New Revision: 183181

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183181
Log:
2012-01-14  Tobias Burnus  

PR fortran/51800
* resolve.c (build_default_init_expr): Also initialize
nonconstant-length strings with -finit-character=.

2012-01-14  Tobias Burnus  

PR fortran/51800
* gfortran.dg/init_flag_8.f90: New.
* gfortran.dg/init_flag_9.f90: New.


Added:
branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/init_flag_8.f90
branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/init_flag_9.f90
Modified:
branches/gcc-4_6-branch/gcc/fortran/ChangeLog
branches/gcc-4_6-branch/gcc/fortran/resolve.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug bootstrap/51860] [4.7 regression] s390 esa mode bootstrap comparison failure since transactional memory branch merge

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Target||s390-ibm-linux
   Priority|P3  |P1
   Host||s390-ibm-linux
Summary|[4.7 regression] s390 esa   |[4.7 regression] s390 esa
   |mode bootstrap comparison   |mode bootstrap comparison
   |failure since transactional |failure since transactional
   |memory branch   |memory branch merge
  Build||s390-ibm-linux

[Bug bootstrap/51860] New: [4.7 regression] s390 esa mode bootstrap comparison failure since transactional memory branch

[krebbel at gcc dot gnu.org]

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

 Bug #: 51860
   Summary: [4.7 regression] s390 esa mode bootstrap comparison
failure since transactional memory branch
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kreb...@gcc.gnu.org


Since revision r181154 the ESA mode bootstrap fails on s390 with a bootstrap
comparison failure (the daily built builds with --with-mode=zarch).

The c_common_nodes_and_builtins function does seem to have a different size
comparing the two stages.

stage2: 83336 c_common_nodes_and_builtins()
stage3: 83528 c_common_nodes_and_builtins()

I have a closer look next week.

[Bug lto/51859] New: wrapped symbols (wrap linker option) do not link

[ncahill_alt at yahoo dot com]

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

 Bug #: 51859
   Summary: wrapped symbols (wrap linker option) do not link
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ncahill_...@yahoo.com


The following command,
> gcc -flto -Wl,-wrap,malloc -o a a.c
produces the following error,

`__wrap_malloc' referenced in section `.text' of
/tmp/ccCKjgAw.ltrans0.ltrans.o: defined in discarded section `.text' of
/tmp/ccREUpxM.o (symbol from plugin)
collect2: ld returned 1 exit status

Here is the test case:

--- a.c ---
void * __wrap_malloc(int bytes)
{
 __real_malloc(bytes);
}

int main()
{
 int *p = (int *)malloc(4);
 *p = 2;
 free(p);
 return 0;
}
--- end a.c ---

This has the result that xorg-server 1.11.2 does not build with lto enabled.
Thank you.

Neil.

[Bug fortran/51800] [4.6/4.7 Regression] Error: Automatic array 'dummy' at (1) cannot have an initializer

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2012-01-14 
12:06:04 UTC ---
Author: burnus
Date: Sat Jan 14 12:05:59 2012
New Revision: 183180

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183180
Log:
2012-01-14  Tobias Burnus  

PR fortran/51800
* resolve.c (build_default_init_expr): Also initialize
nonconstant-length strings with -finit-character=.

2012-01-14  Tobias Burnus  

PR fortran/51800
* gfortran.dg/init_flag_8.f90: New.
* gfortran.dg/init_flag_9.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/init_flag_8.f90
trunk/gcc/testsuite/gfortran.dg/init_flag_9.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/51816] [4.7 Regression] Wrong error when use..., only : operator() twice

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #6 from Tobias Burnus  2012-01-14 
12:06:41 UTC ---
FIXED on the trunk (4.7).

Thanks for the report Harald!

[Bug fortran/51816] [4.7 Regression] Wrong error when use..., only : operator() twice

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2012-01-14 
12:04:25 UTC ---
Author: burnus
Date: Sat Jan 14 12:04:20 2012
New Revision: 183179

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183179
Log:
2011-01-14  Tobias Burnus  

PR fortran/51816
* module.c (read_module): Don't make nonexisting
intrinsic operators as found.
(rename_list_remove_duplicate): New function.
(gfc_use_modules): Use it.

2011-01-14  Tobias Burnus  

PR fortran/51816
* gfortran.dg/use_18.f90: New.
* gfortran.dg/use_19.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/use_18.f90
trunk/gcc/testsuite/gfortran.dg/use_19.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/testsuite/ChangeLog

[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto

[jakub at gcc dot gnu.org]

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

--- Comment #27 from Jakub Jelinek  2012-01-14 
11:48:37 UTC ---
(In reply to comment #25)
> BTW what happens on i?86-linux-* with -fpic?

You haven't read #c17, right?

But if you want even further details:
Both x and y there have:
call__x86.get_pc_thunk.bx
addl$_GLOBAL_OFFSET_TABLE_, %ebx
i.e. %ebx after these two insns doesn't contain some address within the
function,
but address of the _GLOBAL_OFFSET_TABLE_ symbol in the current shared library
or binary.  So, there is no need to restore anything, as nonlocal goto can only
be from a nested function to a function within the same translation unit and
thus shared library or binary, thus they have the same %ebx value.

[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto

[iains at gcc dot gnu.org]

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

--- Comment #26 from Iain Sandoe  2012-01-14 11:42:41 
UTC ---
(In reply to comment #25)

> > I guess xfailing is the thing to do for now ...
> 
> I hate xfail in this kind of situation: I see it as a hypocritical way to say
> "won't fix". Note the test passes with -fno-pic, so I'ld prefer an additional
> option -fno-pic for darwin.

well, I tend to agree about xfails hiding problems away - not a fan either.

However, this problem is not directly related to the test-case (it just happens
to reveal it).

I think we will try to fix this bug - it seems quite serious ... so we could
also decide to live with the test-suite noise?

> BTW what happens on i?86-linux-* with -fpic?

I think as Jakub mentioned, the _GOT solution will not exhibit this problem.

[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto

[dominiq at lps dot ens.fr]

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

--- Comment #25 from Dominique d'Humieres  
2012-01-14 11:33:20 UTC ---
> I don't think this is a regression - I think it's been there for(ever/long
> time).

I don't want to waste time arguing about the regression tag, but
gcc.dg/tree-prof/pr44777.c and its avatars gcc.c-torture/execute/comp-goto-2.c
and gcc.c-torture/execute/920501-7.c pass (I do not say work) with 
-fprofile-generate -D_PROFILE_GENERATE -m32 for gcc 4.6.2 or for trunk with
r182920 reverted on x86_64-apple-darwin10 (i.e. no pr44777 on this platform).

> I guess xfailing is the thing to do for now ...

I hate xfail in this kind of situation: I see it as a hypocritical way to say
"won't fix". Note the test passes with -fno-pic, so I'ld prefer an additional
option -fno-pic for darwin.

BTW what happens on i?86-linux-* with -fpic?

[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto

[iains at gcc dot gnu.org]

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

--- Comment #24 from Iain Sandoe  2012-01-14 11:28:11 
UTC ---
(In reply to comment #23)
> How would that help?  

well, I wasn't suggesting that it was a complete solution (and I get that we
need to provide the nonlocal_goto_receiver).

My point is that, at the moment, 'foo' from your example below is not saving
the PIC register if it doesn't use it.
so there is no place to restore it from, (and no local label to subtract to
correct its value).

I was figuring the nonlocal_goto_receiver would need to restore in the case
that foo does not use the PIC reg, and correct the value by subtracting a local
offset  if it does. 

With nonlocal goto, you need to recompute the PIC
> register (if different from the function doing nonlocal goto) in the nonlocal
> goto receiver.
> Consider:
> extern void baz (void (*) (void));
> volatile int z, z1;
> static volatile int z2, z3;
> int
> foo (void)
> {
>   __label__ l;
>   void bar ()
>   {
> goto l;
>   }
>   baz (bar);
>   return z1 + z3;
> l:
>   return z + z2;
> }
> If you attempt to restore the PIC register in bar before doing the jump,
> you'd restore it to baz PIC register rather than foo PIC register.
> md.texi clearly hints it:
> @cindex @code{nonlocal_goto_receiver} instruction pattern
> @item @samp{nonlocal_goto_receiver}
> This pattern, if defined, contains code needed at the target of a
> nonlocal goto after the code already generated by GCC@.  You will not
> normally need to define this pattern.  A typical reason why you might
> need this pattern is if some value, such as a pointer to a global table,
> must be restored when the frame pointer is restored.  Note that a nonlocal
> goto only occurs within a unit-of-translation, so a global table pointer
> that is shared by all functions of a given module need not be restored.
> There are no arguments.
> 
> darwin clearly doesn't have a PIC pointer shared by all functions of a given
> module, therefore it needs to be restored.

[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto

[jakub at gcc dot gnu.org]

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

--- Comment #23 from Jakub Jelinek  2012-01-14 
11:03:26 UTC ---
How would that help?  With nonlocal goto, you need to recompute the PIC
register (if different from the function doing nonlocal goto) in the nonlocal
goto receiver.
Consider:
extern void baz (void (*) (void));
volatile int z, z1;
static volatile int z2, z3;
int
foo (void)
{
  __label__ l;
  void bar ()
  {
goto l;
  }
  baz (bar);
  return z1 + z3;
l:
  return z + z2;
}
If you attempt to restore the PIC register in bar before doing the jump,
you'd restore it to baz PIC register rather than foo PIC register.
md.texi clearly hints it:
@cindex @code{nonlocal_goto_receiver} instruction pattern
@item @samp{nonlocal_goto_receiver}
This pattern, if defined, contains code needed at the target of a
nonlocal goto after the code already generated by GCC@.  You will not
normally need to define this pattern.  A typical reason why you might
need this pattern is if some value, such as a pointer to a global table,
must be restored when the frame pointer is restored.  Note that a nonlocal
goto only occurs within a unit-of-translation, so a global table pointer
that is shared by all functions of a given module need not be restored.
There are no arguments.

darwin clearly doesn't have a PIC pointer shared by all functions of a given
module, therefore it needs to be restored.

[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto

[iains at gcc dot gnu.org]

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

--- Comment #22 from Iain Sandoe  2012-01-14 10:34:19 
UTC ---
I suppose that, for a start, if a function contains a non-local-label, then the
pro/epilogue should save/restore all call-saved regs?

[Bug target/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE

[iains at gcc dot gnu.org]

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

--- Comment #21 from Iain Sandoe  2012-01-14 10:22:31 
UTC ---
(In reply to comment #20)
> Doesn't powerpc-darwin have the same problem?  Not sure if it defaults to
> -fpic, perhaps just with explicit -fpic?

powerpc makes provision (in the ABI) to save the pic reg in nested functions -
so it might have a different/or no problem.

> Are you ok with dropping the Regression tag 

I don't think this is a regression - I think it's been there for(ever/long
time).

(or, just xfailing the testcase on
> *-darwin* for now with a reference to this PR)

I guess xfailing is the thing to do for now - maybe give Mike a day or two in
case there's a really easy fix.

 (it's not as simple as just doing that subtraction, as there is no guarantee
that x uses or even saves the PIC reg as things stand) ... 

I am not familiar with how the non-local goto system works, so there's some
reading for me to do before even cooking up a test...

[Bug target/48949] [4.6/4.7 Regression] gcc-4.6.0 regression with complex.h on i386-pc-solaris2.10

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  2012-01-14 
10:20:34 UTC ---
(In reply to comment #8)
> > Please answer comment #3.
> 
> Answers provided on bug report 50944.

Clearly the system complex.h is being used, does that mean that the header
hasn't been fixincluded at all?  The diff is against a wrong header, you are
diffing system complex.h against C++.
Can you look into your logs if you have message like:
Applying solaris_complex  to complex.h
in your build log?  Can you look into your build tree if you have
gcc/include-fixed/complex.h
header?  Did it get installed?
/usr/local/gcc-4.6.0/x86_64-SunOS-core2/lib/gcc/i386-pc-solaris2.10/4.6.0/include-fixed/complex.h
would be the installed location of the file.

[Bug target/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  2012-01-14 
10:14:33 UTC ---
Doesn't powerpc-darwin have the same problem?  Not sure if it defaults to
-fpic, perhaps just with explicit -fpic?
Are you ok with dropping the Regression tag (or, just xfailing the testcase on
*-darwin* for now with a reference to this PR) - as it really doesn't seem to
be a regression, if the testcase ever didn't crash, it was by pure luck that it
clobbered something that didn't result in a visible failure immediately.

[Bug target/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||mrs at gcc dot gnu.org
  Component|middle-end  |target

--- Comment #19 from Iain Sandoe  2012-01-14 10:02:25 
UTC ---
(In reply to comment #18)
> Probably for TARGET_MACHO && !TARGET_64BIT && flag_pic you want to define
> "nonlocal_goto_receiver" pattern that would compute the right PIC pointer 
> value
> at that point (not sure if the assembler/linker would be happy by doing
> something like
> call ___x86.get_pc_thunk.bx
> L1:
> add $(L002$pb-L1), %ebx
> in the nonlocal goto receiver.

I concur with the observation that we are not restoring the PIC reg (and we
need to).

[with a very quick look, we seem to be trampling on it anyway in the nested
func, even without gcov]

Thus changing to target bug.

I suppose the subtraction in your example should be feasible with a scattered
reloc on ia32, but I'd have to check.
 (on x86-64 this is not relevant since we work %rip as per linux).

Have to add it to the TODO - unless Mike has any immediate ideas?

[Bug c++/51832] [4.7 regression] Rev.182970 causes LTO link errors (multiple definitions of allocator_traits)

[marc.glisse at normalesup dot org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||marc.glisse at normalesup
   ||dot org

--- Comment #9 from Marc Glisse  2012-01-14 
09:56:20 UTC ---
(In reply to comment #7)
> Can anybody else except Jason reproduce this issue?

It does happen with the gcc I built yesterday on an up-to-date debian testing
box (using the testcase from comment #2). Just so you know you're not the only
one...

stedding /tmp $ /tmp/gcc-2012-01-13/inst/bin/g++ foo.cpp foo.cpp -flto
-std=gnu++0x -v
Using built-in specs.
COLLECT_GCC=/tmp/gcc-2012-01-13/inst/bin/g++
COLLECT_LTO_WRAPPER=/tmp/gcc-2012-01-13/inst/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /data/repos/gcc/trunk/configure
--prefix=/tmp/gcc-2012-01-13/inst --enable-languages=c,c++ --with-system-zlib
--disable-nls --enable-libstdcxx-time=yes
Thread model: posix
gcc version 4.7.0 20120113 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-flto' '-std=gnu++11' '-v' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /tmp/gcc-2012-01-13/inst/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/cc1plus
-quiet -v -D_GNU_SOURCE foo.cpp -quiet -dumpbase foo.cpp -mtune=generic
-march=x86-64 -auxbase foo -std=gnu++11 -version -flto -o /tmp/ccsHpwDx.s
GNU C++ (GCC) version 4.7.0 20120113 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.0 20120113 (experimental), GMP version 5.0.2,
MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/tmp/gcc-2012-01-13/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/tmp/gcc-2012-01-13/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0

/tmp/gcc-2012-01-13/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/x86_64-unknown-linux-gnu

/tmp/gcc-2012-01-13/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/backward
 /tmp/gcc-2012-01-13/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include
 /usr/local/include
 /tmp/gcc-2012-01-13/inst/include
 /tmp/gcc-2012-01-13/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include-fixed
 /usr/include
End of search list.
GNU C++ (GCC) version 4.7.0 20120113 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.0 20120113 (experimental), GMP version 5.0.2,
MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: fd54b59ce46d25c505f29ce3b2761268
COLLECT_GCC_OPTIONS='-flto' '-std=gnu++11' '-v' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 as --64 -o /tmp/ccYykeUv.o /tmp/ccsHpwDx.s
COLLECT_GCC_OPTIONS='-flto' '-std=gnu++11' '-v' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /tmp/gcc-2012-01-13/inst/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/cc1plus
-quiet -v -D_GNU_SOURCE foo.cpp -quiet -dumpbase foo.cpp -mtune=generic
-march=x86-64 -auxbase foo -std=gnu++11 -version -flto -o /tmp/ccsHpwDx.s
GNU C++ (GCC) version 4.7.0 20120113 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.0 20120113 (experimental), GMP version 5.0.2,
MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/tmp/gcc-2012-01-13/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/tmp/gcc-2012-01-13/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0

/tmp/gcc-2012-01-13/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/x86_64-unknown-linux-gnu

/tmp/gcc-2012-01-13/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/backward
 /tmp/gcc-2012-01-13/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include
 /usr/local/include
 /tmp/gcc-2012-01-13/inst/include
 /tmp/gcc-2012-01-13/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include-fixed
 /usr/include
End of search list.
GNU C++ (GCC) version 4.7.0 20120113 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.0 20120113 (experimental), GMP version 5.0.2,
MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: fd54b59ce46d25c505f29ce3b2761268
COLLECT_GCC_OPTIONS='-flto' '-std=gnu++11' '-v' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 as --64 -o /tmp/ccsaZaCu.o /tmp/ccsHpwDx.s
COMPILER_PATH=/tmp/gcc-2012-01-13/inst/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/:/tmp/gcc-2012-01-13/inst/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/:/t

[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø

[zeratul976 at hotmail dot com]

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

--- Comment #8 from Nathan Ridge  2012-01-14 
08:40:35 UTC ---
(In reply to comment #6)
> (In reply to comment #2)
> > you could also try building with --enable-checking=valgrind
> 
> When I try to build gcc with --enable-checking=valgrind, I get the following
> error:
> 
> --13242-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x2a
> 
> valgrind: m_debuginfo/readdwarf.c:2292 (copy_convert_CfiExpr_tree): Assertion
> 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.
> ==13242==at 0x3802B1F7: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)

I built valgrind from source and ran cc1plus under valgrind (this is what
--enable-checking=valgrind would have done, right?).

Attached is the valgrind output. Is there anything helpful in there?

[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø

[zeratul976 at hotmail dot com]

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

--- Comment #7 from Nathan Ridge  2012-01-14 
08:39:44 UTC ---
Created attachment 26322
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26322
valgrind output

[Bug c/51853] MPFR assertion failure with Python: p >= 2 && p <= ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))

[julien at trigofacile dot com]

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

--- Comment #3 from Julien ÉLIE  2012-01-14 
08:13:45 UTC ---
Created attachment 26321
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26321
Result of preprocessed file

[Bug c/51853] MPFR assertion failure with Python: p >= 2 && p <= ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))

[julien at trigofacile dot com]

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

Julien ÉLIE  changed:

   What|Removed |Added

  Component|target  |c

--- Comment #2 from Julien ÉLIE  2012-01-14 
08:12:29 UTC ---
longobject.i is attached.
Here is the result of "gcc -save-temps":

$ /home/iulius/autobuild/bin/gcc-core-4.6.2/bin/gcc -v -save-temps -pthread -c
-fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes 
-I. -IInclude -I./Include   -DPy_BUILD_CORE -o Objects/longobject.o
Objects/longobject.c
Using built-in specs.
COLLECT_GCC=/home/iulius/autobuild/bin/gcc-core-4.6.2/bin/gcc
COLLECT_LTO_WRAPPER=/home/iulius/autobuild/bin/gcc-core-4.6.2/libexec/gcc/hppa2.0-unknown-linux-gnu/4.6.2/lto-wrapper
Target: hppa2.0-unknown-linux-gnu
Configured with: ../gcc-core-4.6.2-src/configure
--prefix=/home/iulius/autobuild/bin/gcc-core-4.6.2
--with-gmp=/home/iulius/autobuild/bin/gmp-5.0.2
--with-mpfr=/home/iulius/autobuild/bin/mpfr-3.1.0
--with-mpc=/home/iulius/autobuild/bin/mpc-0.9 --disable-nls
--enable-threads=posix --disable-multilib
Thread model: posix
gcc version 4.6.2 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-pthread' '-c' '-fno-strict-aliasing'
'-g' '-O2' '-D' 'NDEBUG' '-g' '-fwrapv' '-O3' '-Wall' '-Wstrict-prototypes'
'-I' '.' '-I' 'Include' '-I' './Include' '-D' 'Py_BUILD_CORE' '-o'
'Objects/longobject.o'

/home/iulius/autobuild/bin/gcc-core-4.6.2/libexec/gcc/hppa2.0-unknown-linux-gnu/4.6.2/cc1
-E -quiet -v -I . -I Include -I ./Include -D NDEBUG -D Py_BUILD_CORE
Objects/longobject.c -Wall -Wstrict-prototypes -fno-strict-aliasing -fwrapv -g
-g -fworking-directory -O2 -O3 -fpch-preprocess -o longobject.i
ignoring nonexistent directory
"/home/iulius/autobuild/bin/gcc-core-4.6.2/lib/gcc/hppa2.0-unknown-linux-gnu/4.6.2/../../../../hppa2.0-unknown-linux-gnu/include"
ignoring duplicate directory "./Include"
#include "..." search starts here:
#include <...> search starts here:
 .
 Include

/home/iulius/autobuild/bin/gcc-core-4.6.2/lib/gcc/hppa2.0-unknown-linux-gnu/4.6.2/include
 /usr/local/include
 /home/iulius/autobuild/bin/gcc-core-4.6.2/include

/home/iulius/autobuild/bin/gcc-core-4.6.2/lib/gcc/hppa2.0-unknown-linux-gnu/4.6.2/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-pthread' '-c' '-fno-strict-aliasing'
'-g' '-O2' '-D' 'NDEBUG' '-g' '-fwrapv' '-O3' '-Wall' '-Wstrict-prototypes'
'-I' '.' '-I' 'Include' '-I' './Include' '-D' 'Py_BUILD_CORE' '-o'
'Objects/longobject.o'

/home/iulius/autobuild/bin/gcc-core-4.6.2/libexec/gcc/hppa2.0-unknown-linux-gnu/4.6.2/cc1
-fpreprocessed longobject.i -quiet -dumpbase longobject.c -auxbase-strip
Objects/longobject.o -g -g -O2 -O3 -Wall -Wstrict-prototypes -version
-fno-strict-aliasing -fwrapv -o longobject.s
GNU C (GCC) version 4.6.2 (hppa2.0-unknown-linux-gnu)
compiled by GNU C version 4.6.2, GMP version 5.0.2, MPFR version 3.1.0, MPC
version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.6.2 (hppa2.0-unknown-linux-gnu)
compiled by GNU C version 4.6.2, GMP version 5.0.2, MPFR version 3.1.0, MPC
version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 6576c6dbf099889f96aaa25f3debe8a2
init2.c:52: MPFR assertion failed: p >= 2 && p <=
((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
Objects/longobject.c: In function 'PyLong_FromString':
Objects/longobject.c:1852:43: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø

[zeratul976 at hotmail dot com]

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

--- Comment #6 from Nathan Ridge  2012-01-14 
08:06:03 UTC ---
(In reply to comment #2)
> you could also try building with --enable-checking=valgrind

When I try to build gcc with --enable-checking=valgrind, I get the following
error:

--13242-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x2a

valgrind: m_debuginfo/readdwarf.c:2292 (copy_convert_CfiExpr_tree): Assertion
'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.
==13242==at 0x3802B1F7: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)