[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

[kcc at gcc dot gnu.org]

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



--- Comment #26 from Kostya Serebryany  2013-02-08 
06:31:26 UTC ---

FTR: here is the perf data for zero-based offset (clang)

https://code.google.com/p/address-sanitizer/wiki/ZeroBasedShadow#Performance

[Bug c++/56251] New: no DW_AT_const_value for static const member of a template class

[chihin.ko at oracle dot com]

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



 Bug #: 56251

   Summary: no DW_AT_const_value  for static const member of a

template class

Classification: Unclassified

   Product: gcc

   Version: 4.6.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: chihin...@oracle.com





If a static const member is in template class, there is no DW_AT_const_value

info,

compare these tvalue/value





< 2><0x005a>  DW_TAG_member

DW_AT_name  "value"

DW_AT_decl_file 0x0001 t.cc

DW_AT_decl_line 0x0009

DW_AT_type  <0x0069>

DW_AT_external  yes(1)

DW_AT_declaration   yes(1)

DW_AT_const_value   200(as signed = -56)  <===

const value

< 1><0x0069>DW_TAG_const_type

  DW_AT_type  <0x002c>



-



< 2><0x007a>  DW_TAG_member

DW_AT_name  "tvalue"

DW_AT_decl_file 0x0001 t.cc

DW_AT_decl_line 0x0005

DW_AT_type  <0x0069>

DW_AT_external  yes(1)

DW_AT_declaration   yes(1)

< no

const value

< 2><0x0087>  DW_TAG_template_type_parameter

DW_AT_name  "T0"





cat t.cc



#include 



template

struct TCC {

static const T0 tvalue = 100;

};



struct CC {

static const int value = 200;

};



int main()

{

CC cc;

TCC tcc;



printf("tcc.value1 = %u \n", tcc.tvalue);

printf("cc.value1 = %u \n", cc.value);

}

[Bug middle-end/56250] Wrong constant folding on unsigned int

[ishiura-compiler at ml dot kwansei.ac.jp]

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



--- Comment #3 from Ishiura Lab Compiler Team  2013-02-08 01:59:18 UTC ---

(In reply to comment #1)

> When I do this:

>  unsigned x = 2;

>  unsigned t = (x/2);

>  unsigned t1 = -t;

>  unsigned t2 = t2/2;

> 

> t2 is 0 which is correct.  I don't see why 2147483647 is correct.



The last line should be

unsigned t2 = t1/2;

[Bug middle-end/56250] Wrong constant folding on unsigned int

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



   Keywords||wrong-code

  Component|c   |middle-end



--- Comment #2 from Andrew Pinski  2013-02-08 
01:54:23 UTC ---

Actually I get the correct results with the split out one.  The problem is

division is being merged together over the negative which is not valid for

wrapping cases.

[Bug c/56250] Wrong constant folding on unsigned int

[pinskia at gcc dot gnu.org]

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



--- Comment #1 from Andrew Pinski  2013-02-08 
01:51:39 UTC ---

When I do this:

 unsigned x = 2;

 unsigned t = (x/2);

 unsigned t1 = -t;

 unsigned t2 = t2/2;



t2 is 0 which is correct.  I don't see why 2147483647 is correct.

[Bug c/56250] New: Wrong constant folding on unsigned int

[ishiura-compiler at ml dot kwansei.ac.jp]

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



 Bug #: 56250

   Summary: Wrong constant folding on unsigned int

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

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

ReportedBy: ishiura-compi...@ml.kwansei.ac.jp





GCC 4.7.2 and 4.8.0 miscompile the following code where UINT_MAX ==

4294967295.



  $ cat bug.c

  int main(void)

  {

 unsigned x = 2;

 return ((unsigned) 0 - ( x / 2 ) ) / 2;

  }

  $ gcc bug.c

  $ ./a.out

  $ echo $?

  0



Unsigned (0-(x/2))/2 should evaluate to 2147483647 instead of 0.  

The following code with variable x replaced by "(unsigned) 2" is

correctly compiled.



  $ cat nobug.c

  int main(void)

  {

 return ((unsigned) 0 - ( (unsigned) 2 / 2 ) ) / 2;

  }

  $ gcc nobug.c

  $ ./a.out

  $ echo $?

  255



The miscompile seems to occur on many versions of gcc (4.2 - 4.8, and

even 4.0 and 3.1 on i686-apple-darwin, 4.4 - 4.6 on

i686-linux-gnu-gcc, etc.)

[Bug other/56249] New: gcc-nm doesn't work if gcc configured with --disable-lto

[benno at benno dot id.au]

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



 Bug #: 56249

   Summary: gcc-nm doesn't work if gcc configured with

--disable-lto

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: other

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

ReportedBy: be...@benno.id.au





Created attachment 29393

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

Only install LTO related binaries if LTO is enabled.



If you try to run gcc-nm without LTO enabled it provides an error: 



Cannot find plugin <..>/liblto_plugin.so



Now, it is reasonable to say "if you didn't configure LTO then why are you

using gcc-nm". My counter would be that I don't think it is necessary for GCC

to build gcc-nm (et. al.) unless LTO is enabled since the binaries can't

possibly work correctly.



I'd propose that these binaries are not built and installed unless LTO is

enabled. The attached patch does this.



Cheers,



Benno

[Bug fortran/56226] Add support for DEC UNION and MAP extensions

[russelljbrennan at gmail dot com]

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



--- Comment #4 from russelljbrennan at gmail dot com 2013-02-08 01:03:12 UTC ---

>From a memory standpoint yes, union/map can be replaced by equivalence.  From

an API standpoint it cannot afaik.  A suggestion for the former lies here

http://stackoverflow.com/questions/14733238/convert-fortran-dec-union-map-extensions-to-anything-else

[Bug fortran/56226] Add support for DEC UNION and MAP extensions

[pinskia at gcc dot gnu.org]

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



--- Comment #3 from Andrew Pinski  2013-02-08 
00:46:19 UTC ---

Union can be replaced with EQUIVALENCE I think.

[Bug debug/55586] Incorrect .debug_line section for function with variable number of arguments in PowerPC

[meissner at gcc dot gnu.org]

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



--- Comment #2 from Michael Meissner  2013-02-07 
23:49:34 UTC ---

As far as I can tell, it is a bug in earlier versions of GDB, and not in the

compiler.



Due to the ABI's, it will only show up in 32-bit powerpc with an older GDB. 

The 64-bit powerpc has a completely different ABI, and for stdarg functions, it

does not pass the values in floating point registers, and it doesn't use CR6 to

indicate that the floating point values were passed.  So there isn't a jump,

etc.



I tested GCC 4.8, 4.7 and found that they essentially generated the same code

for the debugging information.  On my SLES 10 system, I even used the system

compiler which is 4.1.2 based, and it generated the same debug code.  If I used

a GDB that was 7.3 or newer (SLES 11 SP2, IBM Advance Toolchain 5.0, etc.) and

put a breakpoint on the my_function, the debugger puts the breakpoint on the

STWU instruction, and it hits the breakpoint.



If I use the system debugger on SLES 10 which is version 7.1, the debugger

skips the function start, and puts the breakpoint on the first STFD instruction

as you mention, and it won't hit the breakpoint unless you pass floating point

values in the floating point registers.



Here is the assembler output from one of the compilers for -O -m32.  Note,

there is a .loc before the first instruction at line 9 (the beginning of the

function).



my_function:

.LFB12:

.file 1 "bug-55586.c"

.loc 1 9 0

.LVL0:

stwu 1,-128(1)

.LCFI0:

mflr 0

.LCFI1:

stw 31,124(1)

.LCFI2:

stw 0,132(1)

.LCFI3:

stw 4,28(1)

stw 5,32(1)

stw 6,36(1)

stw 7,40(1)

stw 8,44(1)

stw 9,48(1)

stw 10,52(1)

bne 1,.L2

.loc 1 9 0

stfd 1,56(1)

stfd 2,64(1)

stfd 3,72(1)

stfd 4,80(1)

stfd 5,88(1)

stfd 6,96(1)

stfd 7,104(1)

stfd 8,112(1)

.L2:

[Bug c++/56247] [4.6/4.7/4.8 Regression] internal compiler error: in tsubst_copy, at cp/pt.c:12131

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-07

Summary|internal compiler error: in |[4.6/4.7/4.8 Regression]

   |tsubst_copy, at |internal compiler error: in

   |cp/pt.c:12131   |tsubst_copy, at

   ||cp/pt.c:12131

 Ever Confirmed|0   |1



--- Comment #1 from Paolo Carlini  2013-02-07 
23:44:56 UTC ---

Confirmed. 4.5.4 works for me.

[Bug c++/56248] New: [DR 580] access checking of template parameters done too early

[redi at gcc dot gnu.org]

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

 Bug #: 56248
   Summary: [DR 580] access checking of template parameters done
too early
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org


This code based on the example in [class.access]/6 is rejected:

class A {
  typedef int I; // private member
  template struct Q;
  template friend struct R;
protected:
  struct B { };
};
template struct A::Q { };
template struct R { };
struct D: A::B, A { };


t.cc:2:15: error: ‘typedef int A::I’ is private
   typedef int I; // private member
   ^
t.cc:8:13: error: within this context
 template struct A::Q { };
 ^
t.cc:2:15: error: ‘typedef int A::I’ is private
   typedef int I; // private member
   ^
t.cc:9:13: error: within this context
 template struct R { };
 ^
t.cc:6:10: error: ‘struct A::B’ is protected
   struct B { };
  ^
t.cc:10:14: error: within this context
 struct D: A::B, A { };
  ^

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#580 clarifies that
access checking of the template parameters should be delayed until the context
is known.

[Bug target/52555] [4.6/4.7/4.8 Regression] ICE unrecognizable insn with -ffast-math and __attribute__((optimize(xx)))

[aldyh at gcc dot gnu.org]

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



--- Comment #9 from Aldy Hernandez  2013-02-07 
23:24:42 UTC ---

Further reduced testcase, reproducible on both C and C++:



float farg;

unsigned val;



void __attribute__((optimize("O")))

test()

{

  val = __builtin_ceilf(farg);

}

[Bug sanitizer/56245] -fsanitize=address miscompiles GCC

[hjl.tools at gmail dot com]

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



--- Comment #1 from H.J. Lu  2013-02-07 23:00:53 
UTC ---

It is caused by revision 195404:



http://gcc.gnu.org/ml/gcc-cvs/2013-01/msg00659.html

[Bug target/52555] [4.6/4.7/4.8 Regression] ICE unrecognizable insn with -ffast-math and __attribute__((optimize(xx)))

[aldyh at gcc dot gnu.org]

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



--- Comment #8 from Aldy Hernandez  2013-02-07 
22:44:17 UTC ---

I'll take a look.

[Bug target/52555] [4.6/4.7/4.8 Regression] ICE unrecognizable insn with -ffast-math and __attribute__((optimize(xx)))

[aldyh at gcc dot gnu.org]

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



Aldy Hernandez  changed:



   What|Removed |Added



 CC||aldyh at gcc dot gnu.org



--- Comment #7 from Aldy Hernandez  2013-02-07 
22:43:25 UTC ---

I'll take a look.

[Bug c++/56247] New: internal compiler error: in tsubst_copy, at cp/pt.c:12131

[dsagald8 at gmail dot com]

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



 Bug #: 56247

   Summary: internal compiler error: in tsubst_copy, at

cp/pt.c:12131

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: dsaga...@gmail.com





Created attachment 29392

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

Test case



ICE when the same member function pointer (to a base class's method) is used as

a template parameter from two different methods of the same templated child

class. What's a bit unusual here is that the bug is only triggered if the same

instantiation occurs in two different methods.



The reduced test case is short enough to include directly:





struct Base {

void method() {}

};  



typedef void (Base::*MemPtr)();



// Template with a member function pointer "non-type parameter".

template

struct Wrapper {};



template

struct Child : public Base {

// Templated derived class instantiates the Wrapper with the same parameter

// in two different virtual methods.

void foo() { typedef Wrapper<&Base::method> W; }

void bar() { typedef Wrapper<&Base::method> W; }

};



// Instantiate Child with some type. 

template class Child;





Here's the detailed gcc output:

% /usr/local/bin/g++47 -v -save-temps -c bugtest.cc

Using built-in specs.

COLLECT_GCC=/usr/local/bin/g++47

Target: x86_64-portbld-freebsd8.2

Configured with: ./../gcc-4.7-20120818/configure --disable-nls

--enable-languages=c,c++,objc,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

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

--mandir=/usr/local/man --infodir=/usr/local/info/gcc47

--build=x86_64-portbld-freebsd8.2

Thread model: posix

gcc version 4.7.2 20120818 (prerelease) (FreeBSD Ports Collection) 

COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-shared-libgcc' '-mtune=generic'

'-march=x86-64'

 /usr/local/libexec/gcc47/gcc/x86_64-portbld-freebsd8.2/4.7.2/cc1plus -E -quiet

-v src/scratch/bugtest.cc -mtune=generic -march=x86-64 -fpch-preprocess -o

bugtest.ii

ignoring nonexistent directory

"/usr/local/lib/gcc47/gcc/x86_64-portbld-freebsd8.2/4.7.2/../../../../../x86_64-portbld-freebsd8.2/include"

#include "..." search starts here:

#include <...> search starts here:

 /usr/local/lib/gcc47/include/c++/

 /usr/local/lib/gcc47/include/c++//x86_64-portbld-freebsd8.2

 /usr/local/lib/gcc47/include/c++//backward

 /usr/local/lib/gcc47/gcc/x86_64-portbld-freebsd8.2/4.7.2/include

 /usr/local/include

 /usr/local/lib/gcc47/gcc/x86_64-portbld-freebsd8.2/4.7.2/include-fixed

 /usr/include

End of search list.

COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-shared-libgcc' '-mtune=generic'

'-march=x86-64'

 /usr/local/libexec/gcc47/gcc/x86_64-portbld-freebsd8.2/4.7.2/cc1plus

-fpreprocessed bugtest.ii -quiet -dumpbase bugtest.cc -mtune=generic

-march=x86-64 -auxbase bugtest -version -o bugtest.s

GNU C++ (FreeBSD Ports Collection) version 4.7.2 20120818 (prerelease)

(x86_64-portbld-freebsd8.2)

compiled by GNU C version 4.7.2 20120818 (prerelease), GMP version

5.0.1, MPFR version 3.0.0, MPC version 0.8.2

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

GNU C++ (FreeBSD Ports Collection) version 4.7.2 20120818 (prerelease)

(x86_64-portbld-freebsd8.2)

compiled by GNU C version 4.7.2 20120818 (prerelease), GMP version

5.0.1, MPFR version 3.0.0, MPC version 0.8.2

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

Compiler executable checksum: 4c5936a9f1a6230b2e84e5f997572e48

src/scratch/bugtest.cc: In instantiation of 'void Child::bar() [with C =

int]':

src/scratch/bugtest.cc:21:16:   required from here

src/scratch/bugtest.cc:17:49: internal compiler error: in tsubst_copy, at

cp/pt.c:12131

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug c++/56243] [4.8 regression] ICE in tree check: expected field_decl, have identifier_node in fixed_type_or_null, at cp/class.c:6645

[fabien at gcc dot gnu.org]

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



fabien at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |

[Bug c++/56241] [4.6/4.7 Regression] ICE in toplev.c:332 on invalid

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |

Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] ICE in

   |ICE in toplev.c:332 on  |toplev.c:332 on invalid

   |invalid |



--- Comment #6 from Jakub Jelinek  2013-02-07 
22:02:48 UTC ---

Fixed for 4.8+ so far.

[Bug pending/55996] [meta-bug] GCC 4.9 pending patches

[law at redhat dot com]

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



--- Comment #3 from Jeffrey A. Law  2013-02-07 22:00:03 
UTC ---

Patch to enable printing of escaped curlys and bars in assembler output.



http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01145.html

[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271

[dominiq at lps dot ens.fr]

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



--- Comment #45 from Dominique d'Humieres  
2013-02-07 21:59:38 UTC ---

> ... Bootstrap regression

> tested for tm.exp and libitm subdirectory on x86_64-apple-darwin10 with Xcode

> 4.2 and x86_64-apple-darwin12 with Xcode 4.6. Can someone test darwin9 and

> x86_64-apple-darwin10 with Xcode 3.2.6 to make sure that the linker bug

> mentioned in the previous patch

> (http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00851.html) doesn't re-appear?



With the new patch, the same tests (tm.exp and libitm) passed without

regression on

x86_64-apple-darwin10 with Xcode 3.2.6. If needed I can repeat it for ppc-d9,

but

don't expect any result before the end of the week-end.

[Bug go/56173] Several libgo tests FAIL on Solaris/SPARC

[ian at airs dot com]

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



Ian Lance Taylor  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #4 from Ian Lance Taylor  2013-02-07 21:41:36 
UTC ---

These cases are all fixed.  They were all due to a bug in the md5 package.  You

were right: it was an endianness issue.

[Bug go/56173] Several libgo tests FAIL on Solaris/SPARC

[ian at gcc dot gnu.org]

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



--- Comment #3 from ian at gcc dot gnu.org  2013-02-07 
21:40:17 UTC ---

Author: ian

Date: Thu Feb  7 21:40:10 2013

New Revision: 195867



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

Log:

PR go/56173

crypto/md5: fix for big-endian processors



Modified:

trunk/libgo/go/crypto/md5/md5block.go

[Bug other/44116] 64bit inodes for source code causes "Value too large for defined data type" (XFS,inode64)

[pinskia at gcc dot gnu.org]

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



--- Comment #7 from Andrew Pinski  2013-02-07 
21:31:13 UTC ---

Fixed so closing; 4.6.x and above is only supported for fixing bugs now.

[Bug c++/56241] [4.6/4.7/4.8 Regression] ICE in toplev.c:332 on invalid

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2013-02-07 
21:28:27 UTC ---

Author: jakub

Date: Thu Feb  7 21:27:55 2013

New Revision: 195866



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

Log:

PR c++/56241

* init.c (build_vec_init): Don't append NULL values into new_vec.

(build_zero_init_1): Don't push anything into v if recursive call

returned NULL_TREE.

(build_value_init_noctor): Don't push anything into v if

build_value_init call returned NULL_TREE.



* g++.dg/parse/crash61.C: New test.



Added:

trunk/gcc/testsuite/g++.dg/parse/crash61.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/init.c

trunk/gcc/testsuite/ChangeLog

[Bug other/44116] 64bit inodes for source code causes "Value too large for defined data type" (XFS,inode64)

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.6.0



--- Comment #6 from Andrew Pinski  2013-02-07 
21:23:22 UTC ---

Fixed so closing; 4.6.

[Bug middle-end/54582] gap in FORTIFY checking of buffer lengths

[dcb314 at hotmail dot com]

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



--- Comment #13 from David Binderman  2013-02-07 
21:21:56 UTC ---

Created attachment 29391

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

C++ source code



This code doesn't understand all sprintf % specifiers.



It is future work to make it understand more specifiers.

[Bug middle-end/54582] gap in FORTIFY checking of buffer lengths

[dcb314 at hotmail dot com]

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



--- Comment #12 from David Binderman  2013-02-07 
21:19:15 UTC ---

I coded up some of my ideas into the attached C++ source code.



Then I modified builtins.c and did a bootstrap.

My small patch seems to be working well.



I'm sure someone could convert my C++ code into something

that follows the compiler coding conventions, add test cases etc.

[Bug other/44116] 64bit inodes for source code causes "Value too large for defined data type" (XFS,inode64)

[gcc at breakpoint dot cc]

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



Sebastian Andrzej Siewior  changed:



   What|Removed |Added



 CC||gcc at breakpoint dot cc,

   ||iant at google dot com



--- Comment #5 from Sebastian Andrzej Siewior  
2013-02-07 21:17:46 UTC ---

I run into this myself today with an older compiler. This has been fixed in svn

commit 166230. The fix is part of gcc-4.6.0+ and it does not look like it has

been backported.

It can be closed now :)

[Bug middle-end/55943] [4.6/4.7/4.8 Regression] ICE in gen_reg_rtx

[aldyh at gcc dot gnu.org]

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



Aldy Hernandez  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-07

 CC||aldyh at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #3 from Aldy Hernandez  2013-02-07 
21:13:06 UTC ---

Confirmed with a cross to --target=ia64-linux-gnu.

[Bug debug/53948] [4.8 Regression] Assignment line missing for -O0 -g

[law at redhat dot com]

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



--- Comment #8 from Jeffrey A. Law  2013-02-07 20:46:10 
UTC ---

Also note the patch, to the best of my knowledge, was not ping'd.  As a

regression (and a P1 regression I might add) I would have expected Steven to

ping the patch and/or Jakub to have pushed harder for reversion of the original

patch which caused the regression per our patch reversion policy.



Either way it was not handled well. 





WRT on-the side datastructures.  The on-the-side structure here is the existing

tree structures.  At some point all the linkage between RTL structures and tree

structures needs to be sorted out, but I don't think now is the time nor do I

think the amount of usage here justifies using a precious bit in our base rtl

structure.

[Bug debug/53948] [4.8 Regression] Assignment line missing for -O0 -g

[jakub at gcc dot gnu.org]

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



--- Comment #7 from Jakub Jelinek  2013-02-07 
20:40:31 UTC ---

(In reply to comment #6)

> Not true: http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00847.html



http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01104.html ?

[Bug target/56043] ICE in rs6000_builtin_vectorized_libmass for vsx-mass-1.c

[meissner at gcc dot gnu.org]

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



--- Comment #1 from Michael Meissner  2013-02-07 
20:27:19 UTC ---

Created attachment 29390

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

Patch to fix the problem



There are two problems here.



The first problem is the segmentation fault if the builtin function does not

have an implicit function.  The patch adds code to return NULL_TREE in this

case, rather than cause a segmentation violation due to a NULL pointer.



However, in the case of powerpc-none-eabi, the vsx-mass-1.c test would still

fail, since some of the builtin functions are not treated as builtin (such as

atan2, which is what caused the fault).  Since the MASS library is only

available for powerpc Linux, I have restricted the test to only run on

powerpc*-*-linux*.

[Bug debug/53948] [4.8 Regression] Assignment line missing for -O0 -g

[stevenb.gcc at gmail dot com]

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



--- Comment #6 from stevenb.gcc at gmail dot com  
2013-02-07 20:24:07 UTC ---

On Thu, Feb 7, 2013 at 9:04 PM, law at redhat dot com wrote:

> The real way to get the prior behaviour without reverting the patch is to

> either explicitly mark parameters so we can check for them in this one hunk of

> code.



That is what I did in http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00847.html



>  Or to create a helper function in a suitable location that can map from

> a reg to its decl, then check if it's a parameter.  Given that flags in the

> main rtl structures are generally scarce, I think the latter is a better

> solution given how rarely we need to make this distinction.



I used an rtl flag because I could make one available. Structures on

the side always make me nervous, they tend to be fragile and hard to

update.





> It's unfortunate that this P1 regression was left languishing, half analyzed 
> in

> our tree for 6+ months ;(



Not true: http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00847.html



It's unfortunate that the patch was never reviewed.

[Bug c/56246] [4.8 regression] ICE in assign_by_spills, at lra-assigns.c:1262

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-07

 CC||jakub at gcc dot gnu.org,

   ||vmakarov at gcc dot gnu.org

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #1 from Jakub Jelinek  2013-02-07 
20:19:09 UTC ---

-m32 -march=i686 -mtune=generic -O2 -fno-omit-frame-pointer -fpic

needed for me.

Regressed with LRA merge.

[Bug target/56043] ICE in rs6000_builtin_vectorized_libmass for vsx-mass-1.c

[meissner at gcc dot gnu.org]

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



Michael Meissner  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-02-07

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

   |gnu.org |

 Ever Confirmed|0   |1

[Bug rtl-optimization/56195] [4.8 Regression] Error: incorrect register `%rdi' used with `l' suffix (at -O2)

[vmakarov at redhat dot com]

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



--- Comment #7 from Vladimir Makarov  2013-02-07 
20:08:47 UTC ---

(In reply to comment #6)

> Actually, that one doesn't really work, because we have pseudo rather than 
> hard

> reg at that point, which will never simplify.

> 

> With this:

> 

> --- lra-constraints.c.jj2013-02-07 18:34:39.0 +0100

> +++ lra-constraints.c2013-02-07 20:58:25.558920536 +0100

> @@ -421,8 +421,20 @@ get_reload_reg (enum op_type type, enum

>if (rtx_equal_p (curr_insn_input_reloads[i].input, original)

>&& in_class_p (curr_insn_input_reloads[i].reg, rclass, &new_class))

>  {

> -  *result_reg = curr_insn_input_reloads[i].reg;

> -  regno = REGNO (*result_reg);

> +  rtx reg = curr_insn_input_reloads[i].reg;

> +  regno = REGNO (reg);

> +  /* If input is equal to original and both are VOIDmode,

> + GET_MODE (reg) might be still different from mode.

> + Ensure we don't return *result_reg with wrong mode.  */

> +  if (GET_MODE (reg) != mode)

> +{

> +  if (GET_MODE_SIZE (GET_MODE (reg)) < GET_MODE_SIZE (mode))

> +continue;

> +  reg = lowpart_subreg (mode, reg, GET_MODE (reg));

> +  if (reg == NULL_RTX || GET_CODE (reg) != SUBREG)

> +continue;

> +}

> +  *result_reg = reg;

>if (lra_dump_file != NULL)

>  {

>fprintf (lra_dump_file, " Reuse r%d for reload ", regno);

> 

> the assembly difference is:

> 

> -cmpl(%rdi), %rdi

> +cmpl(%rdi), %edi

> 

> which is desirable in this case, but not sure if all get_reload_reg callers

> will grok a SUBREG instead of REG returned in *result_reg.



This version of patch looks ok for me.  I have no worry about get_reload_reg

callers.  It should work fine (that is a difference from reload pass when you

should care about secondary reloads etc).



Thanks for working on this, Jakub,

[Bug debug/53948] [4.8 Regression] Assignment line missing for -O0 -g

[law at redhat dot com]

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



Jeffrey A. Law  changed:



   What|Removed |Added



 CC||law at redhat dot com

 AssignedTo|steven at gcc dot gnu.org   |law at gcc dot gnu.org



--- Comment #5 from Jeffrey A. Law  2013-02-07 20:04:00 
UTC ---

So, the real problem here is that replacing



VAR_OR_FUNCTION_DECL_P && ! DECL_ARTIFICAL



with REG_USERVAR_P



is not the same.  In particular the former is _false_ for parameters and the

latter is true.  c#3 is totally wrong, parameters are marked with

REG_USERVAR_P.



The real way to get the prior behaviour without reverting the patch is to

either explicitly mark parameters so we can check for them in this one hunk of

code.  Or to create a helper function in a suitable location that can map from

a reg to its decl, then check if it's a parameter.  Given that flags in the

main rtl structures are generally scarce, I think the latter is a better

solution given how rarely we need to make this distinction.



It's unfortunate that this P1 regression was left languishing, half analyzed in

our tree for 6+ months ;(

[Bug rtl-optimization/56195] [4.8 Regression] Error: incorrect register `%rdi' used with `l' suffix (at -O2)

[jakub at gcc dot gnu.org]

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



--- Comment #6 from Jakub Jelinek  2013-02-07 
20:02:20 UTC ---

Actually, that one doesn't really work, because we have pseudo rather than hard

reg at that point, which will never simplify.



With this:



--- lra-constraints.c.jj2013-02-07 18:34:39.0 +0100

+++ lra-constraints.c2013-02-07 20:58:25.558920536 +0100

@@ -421,8 +421,20 @@ get_reload_reg (enum op_type type, enum

   if (rtx_equal_p (curr_insn_input_reloads[i].input, original)

   && in_class_p (curr_insn_input_reloads[i].reg, rclass, &new_class))

 {

-  *result_reg = curr_insn_input_reloads[i].reg;

-  regno = REGNO (*result_reg);

+  rtx reg = curr_insn_input_reloads[i].reg;

+  regno = REGNO (reg);

+  /* If input is equal to original and both are VOIDmode,

+ GET_MODE (reg) might be still different from mode.

+ Ensure we don't return *result_reg with wrong mode.  */

+  if (GET_MODE (reg) != mode)

+{

+  if (GET_MODE_SIZE (GET_MODE (reg)) < GET_MODE_SIZE (mode))

+continue;

+  reg = lowpart_subreg (mode, reg, GET_MODE (reg));

+  if (reg == NULL_RTX || GET_CODE (reg) != SUBREG)

+continue;

+}

+  *result_reg = reg;

   if (lra_dump_file != NULL)

 {

   fprintf (lra_dump_file, " Reuse r%d for reload ", regno);



the assembly difference is:



-cmpl(%rdi), %rdi

+cmpl(%rdi), %edi



which is desirable in this case, but not sure if all get_reload_reg callers

will grok a SUBREG instead of REG returned in *result_reg.

[Bug rtl-optimization/56195] [4.8 Regression] Error: incorrect register `%rdi' used with `l' suffix (at -O2)

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2013-02-07 
19:47:04 UTC ---

So something like:



--- lra-constraints.c.jj2013-02-07 18:34:39.0 +0100

+++ lra-constraints.c2013-02-07 20:41:17.051986353 +0100

@@ -421,7 +421,21 @@ get_reload_reg (enum op_type type, enum

   if (rtx_equal_p (curr_insn_input_reloads[i].input, original)

   && in_class_p (curr_insn_input_reloads[i].reg, rclass, &new_class))

 {

-  *result_reg = curr_insn_input_reloads[i].reg;

+  rtx reg = curr_insn_input_reloads[i].reg;

+  /* If input is equal to original and both are VOIDmode,

+ GET_MODE (reg) might be still different from mode.

+ Ensure we don't return *result_reg with wrong mode.  */

+  if (GET_MODE (reg) != mode)

+{

+  if (GET_MODE_SIZE (GET_MODE (reg)) < GET_MODE_SIZE (mode))

+continue;

+  reg = simplify_subreg (mode, reg, GET_MODE (reg),

+ subreg_lowpart_offset (mode,

+GET_MODE (reg)));

+  if (reg == NULL_RTX || !REG_P (reg))

+continue;

+}

+  *result_reg = reg;

   regno = REGNO (*result_reg);

   if (lra_dump_file != NULL)

 {



?

[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271

[howarth at nitro dot med.uc.edu]

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



--- Comment #44 from Jack Howarth  2013-02-07 
19:33:24 UTC ---

Created attachment 29389

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

revised patch to fix darwin10 under Xcode 4.2



The attached patch removes the " && !defined (__MACH__)" hacks from

libitm/alloc_cpp.cc and libitm/eh_cpp.cc so that the symbols for _ZdlPv*, etc

can be found on darwin10 with Xcode 4.2 (which doesn't set

HAVE_ELF_STYLE_WEAKREF in configure but also doesn't define the weak dummy

functions because of fast c++ weak-symbol coalescing). Bootstrap regression

tested for tm.exp and libitm subdirectory on x86_64-apple-darwin10 with Xcode

4.2 and x86_64-apple-darwin12 with Xcode 4.6. Can someone test darwin9 and

x86_64-apple-darwin10 with Xcode 3.2.6 to make sure that the linker bug

mentioned in the previous patch

(http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00851.html) doesn't re-appear?

[Bug rtl-optimization/56195] [4.8 Regression] Error: incorrect register `%rdi' used with `l' suffix (at -O2)

[vmakarov at redhat dot com]

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



Vladimir Makarov  changed:



   What|Removed |Added



 CC||vmakarov at redhat dot com



--- Comment #4 from Vladimir Makarov  2013-02-07 
19:24:58 UTC ---

(In reply to comment #3)

> I'd say the bug is in get_reload_reg.

> Changing pseudo 118 in operand 0 of insn 90 on equiv 0

> Changing address in insn 90 r59:DI -- no change

> Changing pseudo 59 in address of insn 90 on equiv 0

>   Creating newreg=137, assigning class GENERAL_REGS to address r137

>  Choosing alt 1 in insn 90:  (0) r  (1) rm

>  Reuse r137 for reload 0, change to class INDEX_REGS for r137

>90: flags:CCGC=cmp(r137:DI,[r137:DI])

> Inserting insn reload before:

>   256: r137:DI=0

> 

> 

> 3065  if (get_reload_reg (type, mode, old, goal_alt[i], "", &new_reg)

> 3066  && type != OP_OUT)

> 

> calls it with

> type=OP_IN, mode=SImode, original=const0_rtx, rclass=GENERAL_REGS

> but returns new_reg = (reg:DI 137).

> That is because:

>   if (rtx_equal_p (curr_insn_input_reloads[i].input, original)

>   && in_class_p (curr_insn_input_reloads[i].reg, rclass, &new_class))

> doesn't check any mode if original (and curr_insn_input_reloads[i].input) are

> VOIDmode as in this case.  So, either this can be fixed by doing:

>if (rtx_equal_p (curr_insn_input_reloads[i].input, original)

> -  && in_class_p (curr_insn_input_reloads[i].reg, rclass, &new_class))

> +  && in_class_p (curr_insn_input_reloads[i].reg, rclass, &new_class)

> +  && GET_MODE (curr_insn_input_reloads[i].reg) == mode)

> , or we could try better, if the GET_MODE (curr_insn_input_reloads[i].reg)

> is wider than mode, see if we can create a lowpart subreg thereof and return

> that, and only give up (i.e. continue looping) if creation of the lowpart

> subreg for some reason failed.

> 

> Vlad, what do you think?



I think, the second solution with lowpart is better.



Would you like to make a patch or may be you prefer that I work on it?

[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #15 from Uros Bizjak  2013-02-07 19:20:07 
UTC ---

Fixed.

[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c

[uros at gcc dot gnu.org]

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



--- Comment #14 from uros at gcc dot gnu.org 2013-02-07 19:18:40 UTC ---

Author: uros

Date: Thu Feb  7 19:18:27 2013

New Revision: 195865



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

Log:

Backport from mainline

2013-02-07  Uros Bizjak  



PR bootstrap/56227

* ggc-page.c (ggc_print_statistics): Use HOST_LONG_LONG_FORMAT

instead of "ll".

* config/i386/i386.c (ix86_print_operand): Ditto.



lto/ChangeLog:



Backport from mainline

2013-02-07  Uros Bizjak  



PR bootstrap/56227

* lto.c (lto_resolution_ready): Use %wx instead of

HOST_WIDE_INT_PRINT_HEX_PURE in the argument to internal_error.





Modified:

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

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

branches/gcc-4_7-branch/gcc/ggc-page.c

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

branches/gcc-4_7-branch/gcc/lto/lto.c

[Bug middle-end/56231] warning traces have bogus line information when using LTO

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez  2013-02-07 
19:10:17 UTC ---
/* Reason for creating a new line map with linemap_add.  LC_ENTER is
   when including a new file, e.g. a #include directive in C.
   LC_LEAVE is when reaching a file's end.  LC_RENAME is when a file
   name or line number changes for neither of the above reasons
   (e.g. a #line directive in C); LC_RENAME_VERBATIM is like LC_RENAME
   but a filename of "" is not specially interpreted as standard
   input. LC_ENTER_MACRO is when a macro expansion is about to start.  */

So perhaps the secret is to use just LC_ENTER?

[Bug c/56246] New: [4.8 regression] ICE in assign_by_spills, at lra-assigns.c:1262

[ppluzhnikov at google dot com]

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



 Bug #: 56246

   Summary: [4.8 regression] ICE in assign_by_spills, at

lra-assigns.c:1262

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

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

ReportedBy: ppluzhni...@google.com





Test case:



void NoBarrier_AtomicExchange (long long *ptr) {

  while (__sync_val_compare_and_swap (ptr, 1, 0) );

}



Using g++ (GCC) 4.8.0 20130205 (experimental):



g++ -c -m32 -O2 -fPIC -fno-omit-frame-pointer test.ii



test.ii: In function 'void NoBarrier_AtomicExchange(long long int*)':

test.ii:3:1: internal compiler error: in assign_by_spills, at

lra-assigns.c:1262

 }

 ^

0x995de3 assign_by_spills

../../gcc/lra-assigns.c:1262

0x996a93 lra_assign()

../../gcc/lra-assigns.c:1419

0x992d11 lra(_IO_FILE*)

../../gcc/lra.c:2308

0x95ae78 do_reload

../../gcc/ira.c:4623

0x95ae78 rest_of_handle_reload

../../gcc/ira.c:4736

Please submit a full bug report,

with preprocessed source if appropriate.





Same crash after update to r195864.

[Bug c++/56243] [4.8 regression] ICE in tree check: expected field_decl, have identifier_node in fixed_type_or_null, at cp/class.c:6645

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-07

 CC||fabien at gcc dot gnu.org,

   ||jakub at gcc dot gnu.org,

   ||jason at gcc dot gnu.org

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #1 from Jakub Jelinek  2013-02-07 
18:13:55 UTC ---

Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193504

[Bug target/50678] [4.7/4.8 Regression] FAIL: c52104y on x86_64-apple-darwin10

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #82 from Eric Botcazou  2013-02-07 
18:13:13 UTC ---

Hopefully fixed once for all.

[Bug c++/56241] [4.6/4.7/4.8 Regression] ICE in toplev.c:332 on invalid

[jakub at gcc dot gnu.org]

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



--- Comment #4 from Jakub Jelinek  2013-02-07 
18:09:29 UTC ---

Created attachment 29388

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

gcc48-pr56241.patch



Patch with also the two other spots changed.

[Bug target/50678] [4.7/4.8 Regression] FAIL: c52104y on x86_64-apple-darwin10

[ebotcazou at gcc dot gnu.org]

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



--- Comment #81 from Eric Botcazou  2013-02-07 
18:09:02 UTC ---

Author: ebotcazou

Date: Thu Feb  7 18:08:41 2013

New Revision: 195864



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

Log:

PR target/50678

* init.c (__darwin_major_version): New function for x86-64/Darwin.

(__gnat_adjust_context_for_raise) [Darwin]: Disable the workaround

on Darwin 12 and above.



Modified:

branches/gcc-4_6-branch/gcc/ada/ChangeLog

branches/gcc-4_6-branch/gcc/ada/init.c

[Bug target/50678] [4.7/4.8 Regression] FAIL: c52104y on x86_64-apple-darwin10

[ebotcazou at gcc dot gnu.org]

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



--- Comment #80 from Eric Botcazou  2013-02-07 
18:08:21 UTC ---

Author: ebotcazou

Date: Thu Feb  7 18:07:58 2013

New Revision: 195863



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

Log:

PR target/50678

* init.c (__darwin_major_version): New function for x86-64/Darwin.

(__gnat_adjust_context_for_raise) [Darwin]: Disable the workaround

on Darwin 12 and above.



Modified:

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

branches/gcc-4_7-branch/gcc/ada/init.c

[Bug target/50678] [4.7/4.8 Regression] FAIL: c52104y on x86_64-apple-darwin10

[ebotcazou at gcc dot gnu.org]

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



--- Comment #79 from Eric Botcazou  2013-02-07 
18:07:40 UTC ---

Author: ebotcazou

Date: Thu Feb  7 18:07:18 2013

New Revision: 195862



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

Log:

PR target/50678

* init.c (__darwin_major_version): New function for x86-64/Darwin.

(__gnat_adjust_context_for_raise) [Darwin]: Disable the workaround

on Darwin 12 and above.



Modified:

trunk/gcc/ada/ChangeLog

trunk/gcc/ada/init.c

[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c

[uros at gcc dot gnu.org]

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



--- Comment #13 from uros at gcc dot gnu.org 2013-02-07 18:02:00 UTC ---

Author: uros

Date: Thu Feb  7 18:01:40 2013

New Revision: 195860



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

Log:

PR bootstrap/56227

* ggc-page.c (ggc_print_statistics): Use HOST_LONG_LONG_FORMAT

instead of "ll".

* config/i386/i386.c (ix86_print_operand): Ditto.



lto/ChangeLog:



PR bootstrap/56227

* lto.c (lto_resolution_ready): Use %wx instead of

HOST_WIDE_INT_PRINT_HEX_PURE in the argument to internal_error.





Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/i386/i386.c

trunk/gcc/ggc-page.c

trunk/gcc/lto/ChangeLog

trunk/gcc/lto/lto.c

[Bug c++/56239] [4.6/4.7 Regression] parse error calling operator() on parenthesized value-initialized temporary

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

  Known to work||4.8.0

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

   |gnu.org |

Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] parse

   |parse error calling |error calling operator() on

   |operator() on parenthesized |parenthesized

   |value-initialized temporary |value-initialized temporary



--- Comment #6 from Jakub Jelinek  2013-02-07 
17:54:11 UTC ---

Fixed on the trunk so far.

[Bug rtl-optimization/56225] [4.8 Regression] ICE in lra-constraints.c when executing the testsuite with -m32 -march=pentium3

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #3 from Jakub Jelinek  2013-02-07 
17:51:35 UTC ---

Fixed.

[Bug c++/56239] [4.6/4.7/4.8 Regression] parse error calling operator() on parenthesized value-initialized temporary

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2013-02-07 
17:50:15 UTC ---

Author: jakub

Date: Thu Feb  7 17:49:59 2013

New Revision: 195859



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

Log:

PR c++/56239

* parser.c (cp_parser_token_starts_cast_expression): Renamed to...

(cp_parser_tokens_start_cast_expression): ... this.  Change parameter

to cp_parser *, call cp_lexer_peek_token first.  For CPP_OPEN_PAREN,

return true only if 2nd token isn't CPP_CLOSE_PAREN.

(cp_parser_cast_expression): Adjust caller.



* g++.dg/parse/pr56239.C: New test.



Added:

trunk/gcc/testsuite/g++.dg/parse/pr56239.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/parser.c

trunk/gcc/testsuite/ChangeLog

[Bug c++/56241] [4.6/4.7/4.8 Regression] ICE in toplev.c:332 on invalid

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|ASSIGNED|NEW

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

   ||gnu.org



--- Comment #3 from Jason Merrill  2013-02-07 
17:38:58 UTC ---

Oops, didn't notice you had attached a patch until after I hit save.



(In reply to comment #2)

> Created attachment 29386 [details]

> gcc48-pr56241.patch



This is OK.

[Bug c++/56238] [4.7/4.8 regression] ICE in tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_conversions, at cp/search.c:2515

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |

[Bug target/56164] [avr] ICE: spill fail with __flash keyword

[gjl at gcc dot gnu.org]

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



Georg-Johann Lay  changed:



   What|Removed |Added



   Last reconfirmed|2013-01-31 00:00:00 |2013-02-07 0:00



--- Comment #4 from Georg-Johann Lay  2013-02-07 
17:45:56 UTC ---

Confirmed with:



gcc version 4.7.3 20130207 (prerelease) [gcc-4_7-branch revision 195858] (GCC)



Configured with:



../../gcc.gnu.org/gcc-4_7-branch/configure --target=avr

--prefix=/local/gnu/install/gcc-4.7 --disable-nls --with-dwarf2

--enable-languages=c,c++ --enable-target-optspace=yes --with-avrlibc=yes



Invocation:



avr-gcc spill-flash-2.c -S -Os -mmcu=atmega8



spill-flash.c: In function 'psy':

spill-flash.c:18:1: error: unable to find a register to spill in class

'POINTER_REGS'

spill-flash.c:18:1: error: this is the insn:

(insn 26 25 28 2 (set (reg:SF 59 [ D.1370 ])

(unspec:SF [

(reg:HI 30 r30)

(const_int 0 [0])

] UNSPEC_LPM)) spill-flash.c:9 9 {load_sf}

 (expr_list:REG_DEAD (reg:HI 30 r30)

(nil)))

spill-flash.c:18: confused by earlier errors, bailing out

[Bug c++/56237] [4.6/4.7 regression] ICE in lang_* check: failed in push_local_name, at cp/decl.c:924

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



  Known to work||4.8.0

Summary|[4.6/4.7/4.8 regression]|[4.6/4.7 regression] ICE in

   |ICE in lang_* check: failed |lang_* check: failed in

   |in push_local_name, at  |push_local_name, at

   |cp/decl.c:924   |cp/decl.c:924



--- Comment #6 from Jakub Jelinek  2013-02-07 
17:44:49 UTC ---

Fixed on the trunk so far.

[Bug c++/56237] [4.6/4.7/4.8 regression] ICE in lang_* check: failed in push_local_name, at cp/decl.c:924

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2013-02-07 
17:38:43 UTC ---

Author: jakub

Date: Thu Feb  7 17:38:33 2013

New Revision: 195858



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

Log:

PR c++/56237

* decl.c (push_local_name): Look at DECL_DISCRIMINATOR (t)

only if DECL_DISCRIMINATOR_SET_P (t) rather than just

DECL_LANG_SPECIFIC (t).



* g++.dg/abi/mangle61.C: New test.



Added:

trunk/gcc/testsuite/g++.dg/abi/mangle61.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/decl.c

trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/56245] New: -fsanitize=address miscompiles GCC

[hjl.tools at gmail dot com]

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



 Bug #: 56245

   Summary: -fsanitize=address miscompiles GCC

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: sanitizer

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

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

CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org,

ja...@gcc.gnu.org, k...@gcc.gnu.org





On hjl/asan-bad branch, bootstrapping GCC with



--enable-languages=c,c++,fortran,java,lto,objc,obj-c++,go --disable-werror

--with-build-config="bootstrap-asan"



gave



/export/build/gnu/gcc-asan/build-x86_64-linux/./prev-gcc/xg++

-B/export/build/gnu/gcc-asan/build-x86_64-linux/./prev-gcc/

-B/usr/local/x86_64-unknown-linux-gnu/bin/ -nostdinc++

-B/export/build/gnu/gcc-asan/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs

-B/export/build/gnu/gcc-asan/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/export/build/gnu/gcc-asan/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/export/build/gnu/gcc-asan/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include

-I/export/gnu/import/git/gcc/libstdc++-v3/libsupc++

-L/export/build/gnu/gcc-asan/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs

-L/export/build/gnu/gcc-asan/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

  -O2 -g  -fsanitize=address -DIN_GCC   -fno-exceptions -fno-rtti

-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings

-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long

-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H

-DGENERATOR_FILE -static-libstdc++ -static-libgcc -fsanitize=address

-static-libasan

-B/export/build/gnu/gcc-asan/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libsanitizer/asan/.libs

 -o build/gengtype \

build/gengtype.o build/errors.o build/gengtype-lex.o build/gengtype-parse.o

build/gengtype-state.o build/version.o .././libiberty/libiberty.a

build/gengtype  \

-S /export/gnu/import/git/gcc/gcc -I gtyp-input.list -w

tmp-gtype.state

/bin/sh /export/gnu/import/git/gcc/gcc/../move-if-change tmp-gtype.state

gtype.state

build/gengtype  \

-r gtype.state

gengtype: Internal error: abort in get_output_file_with_visibility, at

gengtype.c:2183

make[5]: *** [s-gtype] Error 1

make[5]: *** Waiting for unfinished jobs

rm gcj-dbtool.pod gcov.pod jcf-dump.pod cpp.pod jv-convert.pod gcj.pod

gc-analyze.pod gfdl.pod grmic.pod gij.pod gfortran.pod gcc.pod fsf-funding.pod

gccgo.pod

make[5]: Leaving directory `/export/build/gnu/gcc-asan/build-x86_64-linux/gcc'

make[4]: *** [all-stage2-gcc] Error 2

make[4]: Leaving directory `/export/build/gnu/gcc-asan/build-x86_64-linux'

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

make[3]: Leaving directory `/export/build/gnu/gcc-asan/build-x86_64-linux'

make[2]: *** [bootstrap] Error 2

make[2]: Leaving directory `/export/build/gnu/gcc-asan/build-x86_64-linux'

1348.17user 91.95system 7:04.60elapsed 339%CPU (0avgtext+0avgdata

581820maxresident)k

338704inputs+4772512outputs (11984major+55486772minor)pagefaults 0swaps

make[1]: *** [bootstrap] Error 2

make[1]: Leaving directory `/export/build/gnu/gcc-asan'

[Bug c++/56241] [4.6/4.7/4.8 Regression] ICE in toplev.c:332 on invalid

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |

[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

[dvyukov at google dot com]

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



--- Comment #25 from Dmitry Vyukov  2013-02-07 
17:18:05 UTC ---

On Thu, Feb 7, 2013 at 9:00 PM, jakub at gcc dot gnu.org

 wrote:

>

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

>

> --- Comment #24 from Jakub Jelinek  2013-02-07 
> 17:00:17 UTC ---

> (In reply to comment #23)

>> #1 afaict, the asan pass happens in the middle of the gcc optimization flow.

>> imho it should happen as late as possible so that the instrumentation

>> happens on fully optimized code.

>

> Our current plan for 4.9 is add __builtin_asan_mem_test (address, length,

> is_write) or similar builtin, where the current asan pass would just insert

> these builtins.  Then, we'd teach the alias oracle and other code about these

> builtins (that they shouldn't be optimized away, unless dominated by similar

> test on the same address with same or bigger length, without an intervening

> call that could free memory, and that they on the other side don't modify any

> memory), teach the vectorizer how to vectorize these builtins and look at 
> other

> passes where it might prevent some optimizations (I guess vectorization will 
> be

> the most important though).  And, finally have some later pass that will do 
> the

> optimization Dodji just wrote, but on the builtins in the IL, with some

> propagation etc. (and could handle tsan builtins too), and then lower this

> special asan builtin to the shadow memory load + test + __asan_report*.



If a memory access is *post* dominated by a memory access to the same

location, then the first one can be eliminated even if there are

intervening function calls, because it's impossible to make an

unaddressable variable addressable again.

This is not true for tsan, though.

[Bug c++/56235] [4.8 regression] Bogus "error: invalid conversion from ‘unsigned char’ to ‘B::Mode’ [-fpermissive]"

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #3 from Jason Merrill  2013-02-07 
17:15:06 UTC ---

Fixed.

[Bug rtl-optimization/56225] [4.8 Regression] ICE in lra-constraints.c when executing the testsuite with -m32 -march=pentium3

[vmakarov at gcc dot gnu.org]

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



--- Comment #2 from Vladimir Makarov  2013-02-07 
17:15:30 UTC ---

Author: vmakarov

Date: Thu Feb  7 17:15:02 2013

New Revision: 195856



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

Log:

2013-02-07  Vladimir Makarov  



PR rtl-optimization/56225

* lra-constraints.c (process_alt_operands): Check that reload hard

reg can hold value for strict_low_part.



2013-02-07  Vladimir Makarov  



PR rtl-optimization/56225

* gcc.target/i386/pr56225.c: New test.





Added:

trunk/gcc/testsuite/gcc.target/i386/pr56225.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/lra-constraints.c

trunk/gcc/testsuite/ChangeLog

[Bug go/56171] syscall FAILs on Solaris

[ro at gcc dot gnu.org]

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



--- Comment #4 from Rainer Orth  2013-02-07 17:06:27 UTC 
---

Created attachment 29387

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

proposed patch



2013-02-06  Rainer Orth  



PR go/56171

* mksysinfo.sh (AF_LOCAL): Provide via AF_UNIX if missing.



* configure.ac: Check for nanosleep in librt.

* configure: Regenerate.



* Makefile.am (CHECK): Add $(LIBS) to GOLIBS.

* Makefile.in: Regenerate.

[Bug go/56172] net FAILs on Solaris

[ian at gcc dot gnu.org]

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



--- Comment #6 from ian at gcc dot gnu.org  2013-02-07 
17:04:37 UTC ---

Author: ian

Date: Thu Feb  7 17:04:24 2013

New Revision: 195855



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

Log:

PR go/56172

net: Skip TestMulticastListener on Solaris



>From Rainer Orth.



Modified:

trunk/libgo/go/net/multicast_posix_test.go

[Bug go/56171] syscall FAILs on Solaris

[ro at gcc dot gnu.org]

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



Rainer Orth  changed:



   What|Removed |Added



 Status|RESOLVED|REOPENED

   Last reconfirmed||2013-02-07

 Resolution|FIXED   |

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #3 from Rainer Orth  2013-02-07 17:02:35 UTC 
---

The test still doesn't pass on Solaris for a couple of reasons:



* passfd_test.go still uses AF_LOCAL which is missing on Solaris 9 and 10.  I'm

  attaching a patch that defines it from AF_UNIX if missing.



* Once it compiles, the test fails to link before Solaris 11:



Undefined   first referenced

 symbol in file

nanosleep   _gotest_.o  (symbol belongs to implicit

depe

ndency /lib/librt.so.1)

ld: fatal: symbol referencing errors. No output written to a.out

collect2: error: ld returned 1 exit status

FAIL: syscall



  We need two things to fix this: also check for nanosleep in librt, just as we

  do for sched_yield, and add $(LIBS) to GOLIBS so testcases are also linked

with

  -lrt if necessary.  The attached patch also handles this.



After those changes, the testcase compiles and links, but still fails:



--- FAIL: TestPassFD (0.11 seconds)

:0: child process: "WriteMsgUnix: write unix: bad file number", 

FAIL

FAIL: syscall



In truss, it seems the same fds (4, 5) are closed twice, yielding EBADF

the second time.  For fd 4, I found those stacktraces when the closes happen:



  12   4387 close:return fd = 4 errno = 0



  libc.so.1`__close+0x7

  a.out`syscall.Close+0x1b

  libgo.so.3.0.1`os.close.pN7_os.file+0x5d

  libgo.so.3.0.1`os.Close.pN7_os.File+0x2a

  a.out`syscall_test.$thunk4+0x2a

  libgo.so.3.0.1`runtime.Goexit+0x42

  libgo.so.3.0.1`testing.FailNow.pN14_testing.common+0x22

  libgo.so.3.0.1`testing.Fatalf.pN14_testing.common+0x65

  a.out`syscall_test.TestPassFD+0xd77

  libgo.so.3.0.1`testing.$thunk10+0xe2

  libgo.so.3.0.1`kickoff+0x39

  libc.so.1`resumecontext

  libgo.so.3.0.1`testing.RunTests+0x461

  libgo.so.3.0.1`testing.Main+0x470

  a.out`main.main+0x63

  libgo.so.3.0.1`runtime_main+0x7b

  libgo.so.3.0.1`kickoff+0x39

  libc.so.1`resumecontext

  a.out`main+0x4b

  a.out`_start+0x83



  12   4387 close:return fd = 4 errno = 9



  libc.so.1`__close+0x7

  a.out`syscall.Close+0x1b

  a.out`syscall_test.$thunk2+0x2a

  libgo.so.3.0.1`runtime.Goexit+0x42

  libgo.so.3.0.1`testing.FailNow.pN14_testing.common+0x22

  libgo.so.3.0.1`testing.Fatalf.pN14_testing.common+0x65

  a.out`syscall_test.TestPassFD+0xd77

  libgo.so.3.0.1`testing.$thunk10+0xe2

  libgo.so.3.0.1`kickoff+0x39

  libc.so.1`resumecontext

  libgo.so.3.0.1`testing.RunTests+0x461

  libgo.so.3.0.1`testing.Main+0x470

  a.out`main.main+0x63

  libgo.so.3.0.1`runtime_main+0x7b

  libgo.so.3.0.1`kickoff+0x39

  libc.so.1`resumecontext

  a.out`main+0x4b

  a.out`_start+0x83



I haven't yet made the necessary connections to the code to explain this.



  Rainer

In

[Bug driver/56244] -O3 should imply -funroll-loops

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-02-07

Version|unknown |4.8.0

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

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #1 from Andrew Pinski  2013-02-07 
17:01:58 UTC ---

Cavium also adds it by default to -O3 for the Octeon toolchains.  For 4.9, I

will dig up the patch and post it.

[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

[jakub at gcc dot gnu.org]

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



--- Comment #24 from Jakub Jelinek  2013-02-07 
17:00:17 UTC ---

(In reply to comment #23)

> #1 afaict, the asan pass happens in the middle of the gcc optimization flow.

> imho it should happen as late as possible so that the instrumentation 

> happens on fully optimized code. 



Our current plan for 4.9 is add __builtin_asan_mem_test (address, length,

is_write) or similar builtin, where the current asan pass would just insert

these builtins.  Then, we'd teach the alias oracle and other code about these

builtins (that they shouldn't be optimized away, unless dominated by similar

test on the same address with same or bigger length, without an intervening

call that could free memory, and that they on the other side don't modify any

memory), teach the vectorizer how to vectorize these builtins and look at other

passes where it might prevent some optimizations (I guess vectorization will be

the most important though).  And, finally have some later pass that will do the

optimization Dodji just wrote, but on the builtins in the IL, with some

propagation etc. (and could handle tsan builtins too), and then lower this

special asan builtin to the shadow memory load + test + __asan_report*.



> #2 asan speed is very sensitive to quality of regalloc. It would be 
> interesting

> (and useful anyway) to implement zero-offset-shadow

> (https://code.google.com/p/address-sanitizer/wiki/ZeroBasedShadow)

> and see how much it helps with performance. 

> If more than clang's 5% -- we have issues with regalloc, otherwise see #1

[Bug rtl-optimization/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher

[hjl.tools at gmail dot com]

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



H.J. Lu  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed|2012-04-05 00:00:00 |2013-02-07

 Ever Confirmed|0   |1



--- Comment #17 from H.J. Lu  2013-02-07 16:33:24 
UTC ---

The fix is on hjl/x32/gcc-4_7-branch branch.

[Bug c++/56235] [4.8 regression] Bogus "error: invalid conversion from ‘unsigned char’ to ‘B::Mode’ [-fpermissive]"

[jason at gcc dot gnu.org]

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



--- Comment #2 from Jason Merrill  2013-02-07 
16:32:39 UTC ---

Author: jason

Date: Thu Feb  7 16:32:28 2013

New Revision: 195854



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

Log:

PR c++/56235

* method.c (do_build_copy_constructor): Don't bother turning

scalars from lvalues to xvalues.

(do_build_copy_assign): Likewise.



Added:

trunk/gcc/testsuite/g++.dg/init/bitfield4.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/method.c

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

[howarth at nitro dot med.uc.edu]

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



--- Comment #46 from Jack Howarth  2013-02-07 
16:27:41 UTC ---

(In reply to comment #42)



Full regression test results on x86_64-apple-darwin12 are at...



http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg00745.html

[Bug driver/56244] New: -O3 should imply -funroll-loops

[Joost.VandeVondele at mat dot ethz.ch]

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



 Bug #: 56244

   Summary: -O3 should imply -funroll-loops

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: driver

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

ReportedBy: joost.vandevond...@mat.ethz.ch





As suggested by Richard, -O3 should imply -funroll-loops



http://gcc.gnu.org/ml/gcc/2013-02/msg00073.html



I think this makes a lot of sense. For our simulation codes, we essentially add

it 'by default' yielding small but measurable speedups (1%?).



Having it on by default (like vectorization), will likely improve the

heuristics, and the interaction with e.g. vectorization will improve.

[Bug c++/56241] [4.6/4.7/4.8 Regression] ICE in toplev.c:332 on invalid

[jakub at gcc dot gnu.org]

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



--- Comment #2 from Jakub Jelinek  2013-02-07 
16:25:21 UTC ---

Created attachment 29386

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

gcc48-pr56241.patch



Fixed thusly, build_constructor doesn't like elts with NULL values, such elts

shouldn't be added at all.



I wonder about several other places in init.c where I believe NULL elt->value

could be added:

  ce.value = build_zero_init_1 (TREE_TYPE (type),

 /*nelts=*/NULL_TREE,

 static_storage_p, NULL_TREE);

  v->quick_push (ce);

in build_zero_init_1 (perhaps vec_alloc should be moved right before the

quick_push and both calls guarded with ce.value != NULL condition), and

  ce.value = build_value_init (TREE_TYPE (type), complain);

  v->quick_push (ce);

in build_value_init_noctor (likewise).

[Bug c++/56243] New: [4.8 regression] ICE in tree check: expected field_decl, have identifier_node in fixed_type_or_null, at cp/class.c:6645

[ppluzhnikov at google dot com]

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

 Bug #: 56243
   Summary: [4.8 regression] ICE in tree check: expected
field_decl, have identifier_node in
fixed_type_or_null, at cp/class.c:6645
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com


Google ref b/8153611
Looks very similar to PR53816.

Test:

class A
{
virtual int String ();
};

class F: public A { };

template < typename V > class G
{
V value;
};

class D
{
template < int N > void Verify(const int (&p1)[N]) const {
  for (int iter; G < A > *x = 0;)
  {
F& name = x->value;
name.String ();
  }
}
};



ICE with g++ (GCC) 4.8.0 20130205 (experimental).

g++ -c  t.ii  # ok

g++ -c -std=c++11 t.ii
t.ii: In member function ‘void D::Verify(const int (&)[N]) const’:
t.ii:19:22: internal compiler error: tree check: expected field_decl, have
identifier_node in fixed_type_or_null, at cp/class.c:6645
 name.String ();
  ^
0xc6159a tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:8946
0x5cd853 tree_check
../../gcc/tree.h:3669
...

[Bug middle-end/56242] New: [4.8 Regression] libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:175:0: ICE: Segmentation fault

[danglin at gcc dot gnu.org]

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



 Bug #: 56242

   Summary: [4.8 Regression]

libjava/classpath/gnu/javax/swing/text/html/parser/sup

port/textPreProcessor.java:175:0: ICE: Segmentation

fault

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

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

ReportedBy: dang...@gcc.gnu.org

  Host: hppa2.0w-hp-hpux11.11

Target: hppa2.0w-hp-hpux11.11

 Build: hppa2.0w-hp-hpux11.11





/opt/gnu/bin/bash ./libtool --tag=GCJ   --mode=compile

/test/gnu/gcc/objdir/./gc

c/gcj -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/

-B/test/gnu/gcc/objd

ir/./gcc/ -B/opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/bin/

-B/opt/gnu/gcc/gcc-4

.8/hppa2.0w-hp-hpux11.11/lib/ -isystem

/opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.1

1/include -isystem /opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/sys-include   

-fc

lasspath= -fbootclasspath=../../../gcc/libjava/classpath/lib --encoding=UTF-8

-W

no-deprecated -fbootstrap-classes -g -O2  -c -o

gnu/javax/swing/text/html/parser

/support.lo

-fsource-filename=/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava

/classpath/lib/classes -MT gnu/javax/swing/text/html/parser/support.lo -MD -MP

-

MF gnu/javax/swing/text/html/parser/support.deps

@gnu/javax/swing/text/html/pars

er/support.list

libtool: compile:  /test/gnu/gcc/objdir/./gcc/gcj

-B/test/gnu/gcc/objdir/hppa2.0

w-hp-hpux11.11/libjava/ -B/test/gnu/gcc/objdir/./gcc/

-B/opt/gnu/gcc/gcc-4.8/hpp

a2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/lib/

-isyst

em /opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/include -isystem

/opt/gnu/gcc/gcc-

4.8/hppa2.0w-hp-hpux11.11/sys-include -fclasspath=

-fbootclasspath=../../../gcc/

libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g

-O

2 -c

-fsource-filename=/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/classp

ath/lib/classes -MT gnu/javax/swing/text/html/parser/support.lo -MD -MP -MF

gnu/

javax/swing/text/html/parser/support.deps

@gnu/javax/swing/text/html/parser/supp

ort.list  -fPIC -o gnu/javax/swing/text/html/parser/.libs/support.o

/test/gnu/gcc/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:

In class 'gnu.javax.swing.text.html.parser.support.textPreProcessor':

/test/gnu/gcc/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:

In method

'gnu.javax.swing.text.html.parser.support.textPreProcessor.preprocessPreformatted(java.lang.StringBuffer)':

In file included from

/test/gnu/gcc/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/support/parameterDefaulter.java:104:0,

 from

/test/gnu/gcc/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/support/gnuStringIntMapper.java:111,

 from

/test/gnu/gcc/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/support/Parser.java:1530,

 from

/test/gnu/gcc/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/support/Parser.java:248,

 from

/test/gnu/gcc/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/support/Parser.java:137,

 from :12:

/test/gnu/gcc/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:175:0:

internal compiler error: Segmentation fault

   return toCharArray(a_text);

 ^

libbacktrace could not find executable to open

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

make[3]: *** [gnu/javax/swing/text/html/parser/support.lo] Error 1

make[3]: *** Waiting for unfinished jobs

make[3]: Leaving directory `/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava'

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



Starting program: /test/gnu/gcc/objdir/gcc/jc1 /var/tmp//cckrnrz2jx

-fuse-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions

-fkeep-inline-functions -quiet -dumpbase cckrnrz2jx -auxbase-strip

gnu/javax/swing/text/html/parser/.libs/support.o -g -O2 -Wno-deprecated

-version -ffilelist-file -fencoding=UTF-8 -fbootstrap-classes

-fsource-filename=/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/classpath/lib/classes

-fPIC -fbootclasspath=./:../../../gcc/libjava/classpath/lib/ -faux-classpath

cckrnrz2jx.zip -MD_ -MT gnu/javax/swing/text/html/parser/support.lo -MF

gnu/javax/swing/text/html/parser/support.deps -o cckrnrz2jx.s

warning: Private mapping of shared library text was not specified

by the executable; setting a breakpoint in a shared library which

is not privately mapped will not work.  See the HP-UX 11i v3 chatr

manpage for methods to privately map shared library text.

GNU Java (GCC) version 4.8.0 20130206 (experimental) [trunk revision 19581

[Bug tree-optimization/52868] [4.7/4.8 Regression] 4.6 is faster on Atom

[aldyh at gcc dot gnu.org]

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



Aldy Hernandez  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-02-07

 CC||aldyh at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #4 from Aldy Hernandez  2013-02-07 
16:11:34 UTC ---

Isn't this a duplicate of PR 52272?  That is, fixing 52272, along with the

410.bwaves regressions, also fixes this PR?



Can we close this as a duplicate?

[Bug c++/56241] [4.6/4.7/4.8 Regression] ICE in toplev.c:332 on invalid

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



   Priority|P3  |P4

 Status|UNCONFIRMED |NEW

   Keywords||error-recovery

   Last reconfirmed||2013-02-07

 CC||jakub at gcc dot gnu.org

 Ever Confirmed|0   |1

Summary|ICE in toplev.c:332 on  |[4.6/4.7/4.8 Regression]

   |invalid |ICE in toplev.c:332 on

   ||invalid

   Target Milestone|--- |4.6.4



--- Comment #1 from Jakub Jelinek  2013-02-07 
15:25:48 UTC ---

Usually delta reduction test scripts and similar should be verifying that the

expected error occurs (expected many times) and no further errors are

introduced during the reduction.



Anyway, this started to ICE with:

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

[Bug debug/56154] [4.7 Regression] Bad .debug_loc generated for some code

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



Summary|[4.7/4.8 Regression] Bad|[4.7 Regression] Bad

   |.debug_loc generated for|.debug_loc generated for

   |some code   |some code



--- Comment #3 from Jakub Jelinek  2013-02-07 
15:18:55 UTC ---

Fixed on the trunk so far.

[Bug c++/56237] [4.6/4.7/4.8 regression] ICE in lang_* check: failed in push_local_name, at cp/decl.c:924

[jason at gcc dot gnu.org]

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



--- Comment #4 from Jason Merrill  2013-02-07 
15:18:07 UTC ---

(In reply to comment #3)

> Created attachment 29383 [details]

> gcc48-pr56237.patch



OK.

[Bug c++/56241] New: ICE in toplev.c:332 on invalid

[ppluzhnikov at google dot com]

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

 Bug #: 56241
   Summary: ICE in toplev.c:332 on invalid
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com


This is a result of test reduction gone bad. The test is invalid, but shouldn't
crash the compiler.

struct pair {
  constexpr pair (const) :
  };
template < 0 >
make_pair () {
}
pair prefix[] = { 0, make_pair }

Using g++ (GCC) 4.8.0 20130205 (experimental):

g++ -c -std=c++11 t.ii
t.ii:2:19: error: ISO C++ forbids declaration of ‘parameter’ with no type
[-fpermissive]
   constexpr pair (const) :
   ^
t.ii: In constructor ‘constexpr pair::pair(int)’:
t.ii:2:26: error: expected identifier at end of input
   constexpr pair (const) :
  ^
t.ii:2:26: error: expected ‘{’ at end of input
t.ii: At global scope:
t.ii:4:12: error: expected identifier before numeric constant
 template < 0 >
^
t.ii:4:12: error: expected ‘>’ before numeric constant
t.ii:5:12: error: ISO C++ forbids declaration of ‘make_pair’ with no type
[-fpermissive]
 make_pair () {
^
t.ii:7:32: error: conversion from ‘’ to
non-scalar type ‘pair’ requested
 pair prefix[] = { 0, make_pair }
^
t.ii:7:32: internal compiler error: Segmentation fault
0xa7fd6f crash_signal
../../gcc/toplev.c:332
0xc69563 non_type_check
../../gcc/tree.h:3847
0xc69563 build_constructor(tree_node*, vec*)
../../gcc/tree.c:1422
...

[Bug libstdc++/56193] ios_base should replace operator void* with explicit operator bool in C++11 onwards.

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED

   Target Milestone|4.9.0   |4.8.0



--- Comment #2 from Paolo Carlini  2013-02-07 
15:13:27 UTC ---

Fixed by http://gcc.gnu.org/ml/gcc-cvs/2013-02/msg00222.html

[Bug tree-optimization/55022] [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619

[dominiq at lps dot ens.fr]

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



--- Comment #12 from Dominique d'Humieres  
2013-02-07 15:11:23 UTC ---

If I replace the loop

  DO i = Spx , Epx

 vn1 = U(i,Apy)*NX1(i) + V(i,Apy)*NY1(i)

 P(i,Apy) = P(i,Apy)/DEXP(GMA*vn1/AS1(i))

 U(i,Apy) = 0.0

 V(i,Apy) = 0.0

 T(i,Apy) = TWX_0

 RHO(i,Apy) = P(i,Apy)*R_0

 AS1(i) = A_0

 E(i,Apy) = E_0

 U1(i,Apy) = RHO(i,Apy)

 U2(i,Apy) = 0.0

 U3(i,Apy) = 0.0

 U4(i,Apy) = RHO(i,Apy)*E_0

  ENDDO



with



  DO i = Spx , Epx

 vn1 = GMA*(U(i,Apy)*NX1(i) + V(i,Apy)*NY1(i))/AS1(i)

 P(i,Apy) = P(i,Apy)/DEXP(vn1)

 RHO(i,Apy) = P(i,Apy)*R_0

 AS1(i) = A_0

 E(i,Apy) = E_0

 U1(i,Apy) = RHO(i,Apy)

 U4(i,Apy) = RHO(i,Apy)*E_0

  ENDDO

  U(Spx:Epx,Apy) = 0.0

  V(Spx:Epx,Apy) = 0.0

  T(Spx:Epx,Apy) = TWX_0

  U2(Spx:Epx,Apy) = 0.0

  U3(Spx:Epx,Apy) = 0.0



Then the test does not abort with NaNs, but the result seems wrong:



1729  0.40924060378447885 

1737  0.41934356330600248 



compared to



1729  0.40411964185599653 

1737  0.41528583240265665

[Bug c++/56239] [4.6/4.7/4.8 Regression] parse error calling operator() on parenthesized value-initialized temporary

[jason at gcc dot gnu.org]

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



--- Comment #4 from Jason Merrill  2013-02-07 
15:02:53 UTC ---

(In reply to comment #3)

> gcc48-pr56239.patch



OK.



> BTW, I wonder where the standard resolves the ambiguity between parsing it as 
> a

> function call with parenthesized ctor and between a cast.



8.2/2:



The ambiguity arising from the similarity between a function-style cast and a

type-id can occur in different contexts. The ambiguity appears as a choice

between a function-style cast expression and a declaration of a type. The

resolution is that any construct that could possibly be a type-id in its

syntactic context shall be considered a type-id.

[Bug tree-optimization/55022] [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|WAITING |NEW



--- Comment #11 from Dominique d'Humieres  
2013-02-07 14:57:40 UTC ---

I have reduced botwall.f90 to



!*==BOTWALL.spg  processed by SPAG 6.55Dc at 09:26 on 23 Sep 2005

!

  SUBROUTINE BOTWALL(Spx,Epx,Apy,Mxpx,U1,U2,U3,U4,Iv)

  IMPLICIT REAL*8(A-H,O-Z)

  PARAMETER (NX=150,NY=150)

  DIMENSION U(NX,NY) , V(NX,NY) , RHO(NX,NY) , T(NX,NY) , E(NX,NY)

  DIMENSION AS1(NX) , AS2(NX) , AS3(NY) , AS4(NY) , NX1(NX) ,   &

 &  NY1(NX)

  DIMENSION NX2(NX) , NY2(NX) , SIG(NX) , P(NX,NY)

  DIMENSION U1(NX,NY) , U2(NX,NY) , U3(NX,NY) , U4(NX,NY)

  INTEGER Spx , Epx , Apy

  REAL*8 NX1 , NX2 , NY1 , NY2 , MINlet(NY)

  COMMON /BNDRY / U , V , P , RHO , T , E , AS1 , AS2 , AS3 , AS4 , &

 &NX1 , NY1 , NX2 , NY2 , SIG , GMA , S0 , T0 , P0 ,&

 &PE , HOO , RR , MINlet

!

  TWX_0 = 272.77

  E_0 = RR*TWX_0/(GMA-1.)

  R_0 = 1.0/(TWX_0*RR)

  A_0 = DSQRT(GMA*TWX_0*RR)

  DO i = Spx , Epx

!

! BOTTOM WALL CONDITIONS FOR SUBSONIC FLOW

!

 vn1 = U(i,Apy)*NX1(i) + V(i,Apy)*NY1(i)

 P(i,Apy) = P(i,Apy)/DEXP(GMA*vn1/AS1(i))

 U(i,Apy) = 0.0

 V(i,Apy) = 0.0

 T(i,Apy) = TWX_0

 RHO(i,Apy) = P(i,Apy)*R_0

 AS1(i) = A_0

 E(i,Apy) = E_0

 U1(i,Apy) = RHO(i,Apy)

 U2(i,Apy) = 0.0

 U3(i,Apy) = 0.0

 U4(i,Apy) = RHO(i,Apy)*E_0

  ENDDO

!  print *, U1(Spx:Epx,Apy)

!  print *, U2(Spx:Epx,Apy)

!  print *, U3(Spx:Epx,Apy)

!  print *, U4(Spx:Epx,Apy)

  print *, U1(Spx:Spx+4,Apy)

  print *, U2(Spx:Spx+4,Apy)

  print *, U3(Spx:Spx+4,Apy)

  print *, U4(Spx:Spx+4,Apy)

  stop

  CONTINUE

  END



With the following compilation (gfc: gcc 4.8 r195848, gfortran: 4.7.2)



gfc -c -O2 -fgraphite-identity air_main.f90

gfortran -c -O2 -fgraphite-identity topwall.f90

gfortran -c -O2 -fgraphite-identity botwall_db.f90

gfc air_main.o botwall_db.o topwall.o



I get



   1.29015797368009301.29015797368009321.2901579736800932  

 1.29015797368009321.2901579736800932 

   0.0.0.  

 0.0. 

   0.0.0.  

 0.0. 

   252499.997252500.003252500.003  

 252500.003252500.003 



If I use



gfc -c -O2 -fgraphite-identity botwall_db.f90

gfc air_main.o botwall_db.o topwall.o



I get



   1.29015792171653841.2004768371581.200476837158  

 1.2004768371581.200476837158 

   0.6.5847860013093756E-016  -2.6339144005237502E-015 

 0.7.7354314600658297E-015

   0.2.3705229604713751E-014   2.3705229604713751E-014 

 2.3705229604713751E-014   2.6300466964223820E-014

   252500.000252500.009252500.009  

 252500.009252500.009 



(In reply to comment #9)

> I'm sorry, but the reporter is going to have to reduce this significantly

> before we can debug this.  This is a huge mess of spaghetti code with tons of

> global and common variables scattered throughout, as well as state being 
> passed

> around in files.

>

> Dominique, please reduce this to the smallest amount of reproducible code, so

> we can attack this.  Avoid reading and writing to files (as I see, these have

> only a minimal amount of data anyhow), and global variables if at all 
> possible.



Well, I am only the reporter. The code is not mine and this makes the task to

reduce it while keeping the wrong code quite difficult (and cumbersome). 



> Please only keep the code that is relevant to reproduce the problem.



I'll try to provide a self contained test, but not before the week-end.

[Bug debug/56154] [4.7/4.8 Regression] Bad .debug_loc generated for some code

[jakub at gcc dot gnu.org]

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



--- Comment #2 from Jakub Jelinek  2013-02-07 
14:48:51 UTC ---

Author: jakub

Date: Thu Feb  7 14:48:39 2013

New Revision: 195850



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

Log:

PR debug/56154

* dwarf2out.c (dwarf2_debug_hooks): Set end_function hook to

dwarf2out_end_function.

(in_first_function_p, maybe_at_text_label_p,

first_loclabel_num_not_at_text_label): New variables.

(dwarf2out_var_location): In the first function find out

lowest loclabel_num N where .LVLN is known not to be equal

to .Ltext0.

(find_empty_loc_ranges_at_text_label, dwarf2out_end_function): New

functions.



* gcc.dg/guality/pr56154-1.c: New test.

* gcc.dg/guality/pr56154-2.c: New test.

* gcc.dg/guality/pr56154-3.c: New test.

* gcc.dg/guality/pr56154-4.c: New test.

* gcc.dg/guality/pr56154-aux.c: New file.



Added:

trunk/gcc/testsuite/gcc.dg/guality/pr56154-1.c

trunk/gcc/testsuite/gcc.dg/guality/pr56154-2.c

trunk/gcc/testsuite/gcc.dg/guality/pr56154-3.c

trunk/gcc/testsuite/gcc.dg/guality/pr56154-4.c

trunk/gcc/testsuite/gcc.dg/guality/pr56154-aux.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/dwarf2out.c

trunk/gcc/testsuite/ChangeLog

[Bug middle-end/56231] warning traces have bogus line information when using LTO

[rguenth at gcc dot gnu.org]

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



--- Comment #4 from Richard Biener  2013-02-07 
14:35:24 UTC ---

(In reply to comment #3)

> (In reply to comment #1)

> > Index: gcc/lto-streamer-in.c

> > ===

> > --- gcc/lto-streamer-in.c   (revision 195841)

> > +++ gcc/lto-streamer-in.c   (working copy)

> > @@ -164,13 +164,8 @@ lto_input_location (struct bitpack_d *bp

> >  data_in->current_col = bp_unpack_var_len_unsigned (bp);

> > 

> >if (file_change)

> > -{

> > -  if (prev_file)

> > -   linemap_add (line_table, LC_LEAVE, false, NULL, 0);

> > -

> > -  linemap_add (line_table, LC_ENTER, false, data_in->current_file,

> > -  data_in->current_line);

> > -}

> > +linemap_add (line_table, LC_RENAME, false, data_in->current_file,

> > +data_in->current_line);

> >else if (line_change)

> >  linemap_line_start (line_table, data_in->current_line,

> > data_in->current_col);

> 

> Does not work because of

> 

> const struct line_map *

> linemap_add (struct line_maps *set, enum lc_reason reason,

>  unsigned int sysp, const char *to_file, linenum_type to_line)

> {

> ...

>   /* When we enter the file for the first time reason cannot be

>  LC_RENAME.  */

>   linemap_assert (!(set->depth == 0 && reason == LC_RENAME));

> 

> trying

> 

> Index: gcc/lto-streamer-in.c

> ===

> --- gcc/lto-streamer-in.c   (revision 195846)

> +++ gcc/lto-streamer-in.c   (working copy)

> @@ -165,11 +165,12 @@ lto_input_location (struct bitpack_d *bp

> 

>if (file_change)

>  {

> -  if (prev_file)

> -   linemap_add (line_table, LC_LEAVE, false, NULL, 0);

> -

> -  linemap_add (line_table, LC_ENTER, false, data_in->current_file,

> -  data_in->current_line);

> +  if (!prev_file)

> +   linemap_add (line_table, LC_ENTER, false, data_in->current_file,

> +data_in->current_line);

> +  else

> +   linemap_add (line_table, LC_RENAME, false, data_in->current_file,

> +data_in->current_line);

>  }

>else if (line_change)

>  linemap_line_start (line_table, data_in->current_line,

> data_in->current_col);

> 

> we'll still eventually enter a file multiple times that way.  But let's see

> if it makes a difference...



Doesn't make a difference.

[Bug middle-end/56231] warning traces have bogus line information when using LTO

[rguenth at gcc dot gnu.org]

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



--- Comment #3 from Richard Biener  2013-02-07 
14:01:50 UTC ---

(In reply to comment #1)

> Index: gcc/lto-streamer-in.c

> ===

> --- gcc/lto-streamer-in.c   (revision 195841)

> +++ gcc/lto-streamer-in.c   (working copy)

> @@ -164,13 +164,8 @@ lto_input_location (struct bitpack_d *bp

>  data_in->current_col = bp_unpack_var_len_unsigned (bp);

> 

>if (file_change)

> -{

> -  if (prev_file)

> -   linemap_add (line_table, LC_LEAVE, false, NULL, 0);

> -

> -  linemap_add (line_table, LC_ENTER, false, data_in->current_file,

> -  data_in->current_line);

> -}

> +linemap_add (line_table, LC_RENAME, false, data_in->current_file,

> +data_in->current_line);

>else if (line_change)

>  linemap_line_start (line_table, data_in->current_line,

> data_in->current_col);



Does not work because of



const struct line_map *

linemap_add (struct line_maps *set, enum lc_reason reason,

 unsigned int sysp, const char *to_file, linenum_type to_line)

{

...

  /* When we enter the file for the first time reason cannot be

 LC_RENAME.  */

  linemap_assert (!(set->depth == 0 && reason == LC_RENAME));



trying



Index: gcc/lto-streamer-in.c

===

--- gcc/lto-streamer-in.c   (revision 195846)

+++ gcc/lto-streamer-in.c   (working copy)

@@ -165,11 +165,12 @@ lto_input_location (struct bitpack_d *bp



   if (file_change)

 {

-  if (prev_file)

-   linemap_add (line_table, LC_LEAVE, false, NULL, 0);

-

-  linemap_add (line_table, LC_ENTER, false, data_in->current_file,

-  data_in->current_line);

+  if (!prev_file)

+   linemap_add (line_table, LC_ENTER, false, data_in->current_file,

+data_in->current_line);

+  else

+   linemap_add (line_table, LC_RENAME, false, data_in->current_file,

+data_in->current_line);

 }

   else if (line_change)

 linemap_line_start (line_table, data_in->current_line,

data_in->current_col);



we'll still eventually enter a file multiple times that way.  But let's see

if it makes a difference...

[Bug middle-end/56231] warning traces have bogus line information when using LTO

[rguenth at gcc dot gnu.org]

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



--- Comment #2 from Richard Biener  2013-02-07 
13:54:20 UTC ---

To clarify, we are also switching between different translation-units main

filenames - but I don't think we can easily distinguish this from #includes.

Well, maybe we can, if at compile-time we can identify the "main" source

via libcpp.

[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 #45 from Dominique d'Humieres  
2013-02-07 13:54:07 UTC ---

(In reply to comment #43)

> On x86_64-apple-darwin12, while the proposed patch from Comment 42 bootstraps

> fine, it does produce a new regression at -m64...



This is pr50077 and it has nothing to do with the patch (look at your tests,

e.g., http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg00522.html).



BTW the patch did not cause any new failure on x86_64-apple-darwin10 (as did

the previous version).

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

[howarth at nitro dot med.uc.edu]

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



--- Comment #44 from Jack Howarth  2013-02-07 
13:49:36 UTC ---

Created attachment 29385

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

assembly file for failing gcc.target/i386/pr49866.c compilation at -m64



Compiled with...



/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc

-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/

-fno-diagnostics-show-caret -O2 -mcmodel=large -c -m64 -o pr49866.o

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130206/gcc/testsuite/gcc.target/i386/pr49866.c

--save-temps

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

[howarth at nitro dot med.uc.edu]

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



--- Comment #43 from Jack Howarth  2013-02-07 
13:45:45 UTC ---

(In reply to comment #42)

On x86_64-apple-darwin12, while the proposed patch from Comment 42 bootstraps

fine, it does produce a new regression at -m64...



Executing on host: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc

-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/ 

-fno-diagnostics-show-caret   -O2 -mcmodel=large -c  -m64 -o pr49866.o

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130206/gcc/testsuite/gcc.target/i386/pr49866.c

   (timeout = 300)

/var/tmp//ccgCyUt7.s:11:junk `@PLTOFF' after expression^M

/var/tmp//ccgCyUt7.s:14:junk `@PLTOFF' after expression^M

/var/tmp//ccgCyUt7.s:17:junk `@PLTOFF' after expression^M

/var/tmp//ccgCyUt7.s:48:junk `@PLTOFF' after expression^M

compiler exited with status 1

output is:

/var/tmp//ccgCyUt7.s:11:junk `@PLTOFF' after expression^M

/var/tmp//ccgCyUt7.s:14:junk `@PLTOFF' after expression^M

/var/tmp//ccgCyUt7.s:17:junk `@PLTOFF' after expression^M

/var/tmp//ccgCyUt7.s:48:junk `@PLTOFF' after expression^M



FAIL: gcc.target/i386/pr49866.c (test for excess errors)

[Bug fortran/56226] Add support for DEC UNION and MAP extensions

[russelljbrennan at gmail dot com]

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



--- Comment #2 from russelljbrennan at gmail dot com 2013-02-07 13:31:16 UTC ---

It seems to me that the UNION/MAP pair is analogous to a basic form of a c/c++

union of structs.  Could the corresponding code not be ganked and fitted to

this application?  I did notice in the IBM link that you provided that unions

are only defined in an enclosing record structure... RECORDs and STRUCTUREs are

easily replace with UDTs.  It would make sense to me to allow UNION/MAP inside

UDTs as well as RECORDs and STRUCTUREs.

[Bug c++/56239] [4.6/4.7/4.8 Regression] parse error calling operator() on parenthesized value-initialized temporary

[jakub at gcc dot gnu.org]

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



--- Comment #3 from Jakub Jelinek  2013-02-07 
13:14:12 UTC ---

Created attachment 29384

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

gcc48-pr56239.patch



If () is the only problem, then it can be fixed e.g. by the following patch

(untested so far, except for make -C gcc check-g++).



BTW, I wonder where the standard resolves the ambiguity between parsing it as a

function call with parenthesized ctor and between a cast.  For zero operands it

is not ambiguous, but if there is one or more operands, apparently it should be

parsed as cast, but I haven't found where the standard says so.

struct S { int operator()(int, int); };

int main() { (S())(1, 2); }

//int main() { S s; s(1, 2); }

[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



URL||http://gcc.gnu.org/ml/gcc-p

   ||atches/2013-02/msg00298.htm

   ||l

   Target Milestone|--- |4.7.3



--- Comment #12 from Uros Bizjak  2013-02-07 12:59:43 
UTC ---

Patch at [1].



[1] http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00298.html

[Bug other/56240] New: -fopenmp and -pthread behave inconsistently with respect to -nostdlib

[yury at shurup dot com]

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



 Bug #: 56240

   Summary: -fopenmp and -pthread behave inconsistently with

respect to -nostdlib

Classification: Unclassified

   Product: gcc

   Version: 4.4.5

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: other

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

ReportedBy: y...@shurup.com





Hello,



As reported in #25460, if gcc is passed -nostdlib and -pthread options, the

libraries implied by -pthread are not added. It was decided that this is the

correct behavior and hence the bug was closed.



Now, if gcc is passed -nostdlib and -fopenmp, the libraries implied by -fopenmp

(and -pthread) are in fact added to the executable. The same test case as in

#25460 can be used to verify this (you have to use libtool 2.4.2+, however,

because earlier versions were filtering out OpenMP flags).



This behavior seems to be inconsistent to me.



In order to make it consistent, either the decision in #25460 can be

reconsidered and gcc can be made to adhere to -pthread even if -nostdlib is

specified, or the effect of -fopenmp can be changed in a way that gcc will not

add -lgomp and libraries implied by -pthread anymore.



I think that the first option is better, because the current behavior of

-fopenmp seems to make total sense to me, and, as a nice side effect, changing

the behavior of -pthread to match -fopenmp will "unbreak" libtool linking of

C++ programs that use threads.



The reasons why libtool uses -nostdlib / adds stubs directly and whether it

should do it or not can be debated, but they are outside the scope of this

report.



Thank you for your time,

--Yury.

[Bug web/56233] Bugzilla: files (*.c, *.diff, etc.) wrongly recognized as application/octet-stream

[LpSolit at netscape dot net]

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

Frédéric Buclin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #5 from Frédéric Buclin  2013-02-07 
12:26:56 UTC ---
Click the "Show Advanced Fields" link at the top of the page to see all fields,
including the ability to select the MIME type.

[Bug c++/56239] [4.6/4.7/4.8 Regression] parse error calling operator() on parenthesized value-initialized temporary

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC||manu at gcc dot gnu.org



--- Comment #2 from Paolo Carlini  2013-02-07 
11:59:32 UTC ---

Let's add Manuel in CC.