[Bug middle-end/56098] conditional write through volatile pointer produces unintended read

[mikpe at it dot uu.se]

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



Mikael Pettersson  changed:



   What|Removed |Added



 CC||mikpe at it dot uu.se



--- Comment #1 from Mikael Pettersson  2013-01-25 
08:42:56 UTC ---

gcc 3.3.6 to 4.2.4 generate:



problem:

.LFB2:

movqptr(%rip), %rax

testl   %edi, %edi

movl$1, (%rax)

je  .L4

movl$2, (%rax)

.L4:

rep ; ret



which looks Ok to me.  From 4.3.6 up to 4.7.2 we get the broken code Werner

showed.  3.2.3 generates different broken code:



problem:

.LFB1:

xorl%eax, %eax

movqptr(%rip), %rdx

testl   %edi, %edi

setne   %al

movl$1, (%rdx)

incl%eax

movl%eax, (%rdx)

ret

[Bug tree-optimization/56035] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 (loop n’s header does not belong directly to it !)

[mpolacek at gcc dot gnu.org]

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



--- Comment #7 from Marek Polacek  2013-01-25 
08:52:33 UTC ---

Author: mpolacek

Date: Fri Jan 25 08:52:02 2013

New Revision: 195462



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

Log:

Fix PR56035.



Added:

trunk/gcc/testsuite/gcc.dg/pr56035.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/cfgloopmanip.c

trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/56035] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 (loop n’s header does not belong directly to it !)

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #8 from Marek Polacek  2013-01-25 
08:53:16 UTC ---

Fixed.

[Bug debug/54793] the location of a formal_parameter is not started from a function entry with -mfentry

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2013-01-25 
09:08:14 UTC ---

Well, we can also just use the first NOTE_INSN_BASIC_BLOCK resp.

NOTE_INSN_FUNCTION_BEG, whichever comes first.

The bigger problem with that ia64, pa and a few other targets use both

PROLOGUE_BEFORE_EPILOGUE and non-default function_prologue hook, which emits

some assembly stuff (even when they HAVE_prologue).  Perhaps for those targets

we'd need to emit the profiler code right away, and only postpone it until the

first NOTE_INSN_BASIC_BLOCK/NOTE_INSN_FUNCTION_BEG if function_prologue hook is

the default.

[Bug target/54222] [avr] Implement fixed-point support

[gjl at gcc dot gnu.org]

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



--- Comment #10 from Georg-Johann Lay  2013-01-25 
09:28:14 UTC ---

Author: gjl

Date: Fri Jan 25 09:28:09 2013

New Revision: 195464



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

Log:

gcc/

PR target/54222

* config/avr/builtins.def (DEF_BUILTIN): Add LIBNAME argument.

Add NULL LIBNAME argument to existing definitions.

(ABSHR, ABSR, ABSLR, ABSLLR, ABSHK, ABSK, ABSLK, ABSLLK): New.

* config/avr/avr-c.c (DEF_BUILTIN): Add LIBNAME argument.

* config/avr/avr.c (DEF_BUILTIN): Same.

(avr_init_builtins): Pass down LIBNAME to add_builtin_function.

(avr_expand_builtin): Expand to a vanilla call if a libgcc

implementation is available (DECL_ASSEMBLER_NAME is set).

(avr_fold_absfx): New static function.

(avr_fold_builtin): Use it to handle: AVR_BUILTIN_ABSHR,

AVR_BUILTIN_ABSR, AVR_BUILTIN_ABSLR, AVR_BUILTIN_ABSLLR,

AVR_BUILTIN_ABSHK, AVR_BUILTIN_ABSK, AVR_BUILTIN_ABSLK,

AVR_BUILTIN_ABSLLK.

* config/avr/stdfix.h (abshr, absr, abslr, absllr)

(abshk, absk, abslk, absllk): Provide as static inline functions.



gcc/testsuite/

PR target/54222

* gcc.target/avr/torture/builtins-3-absfx.c: New test.





Added:

trunk/gcc/testsuite/gcc.target/avr/torture/builtins-3-absfx.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/avr/avr-c.c

trunk/gcc/config/avr/avr.c

trunk/gcc/config/avr/builtins.def

trunk/gcc/config/avr/stdfix.h

trunk/gcc/testsuite/ChangeLog

[Bug debug/54793] the location of a formal_parameter is not started from a function entry with -mfentry

[jakub at gcc dot gnu.org]

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



--- Comment #6 from Jakub Jelinek  2013-01-25 
09:35:17 UTC ---

Created attachment 29271

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

gcc48-pr54793.patch



So, e.g. this seems to work for me from quick testing.  The insn chain scanning

is there e.g. to emit the profiler stuff right away when final_start_function

is called from output_mi_thunk on various targets.

[Bug middle-end/55308] /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale"

[mexas at bristol dot ac.uk]

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



--- Comment #5 from Anton Shterenlikht  2013-01-25 
09:37:38 UTC ---

I'm building gcc-4.8-20130113.

I tried your patch, although my line numbers

are different:



# diff -u10 configure.ac.orig configure.ac

--- configure.ac.orig   2013-01-11 11:46:21.0 +

+++ configure.ac2013-01-25 09:28:24.0 +

@@ -3153,21 +3153,21 @@

 if test x$on_solaris = xyes && test x$gas_flag = xno; then

   conftest_s='

.section ".tdata",#alloc,#write,#tls'

tls_first_major=0

tls_first_minor=0

 else

   conftest_s='

.section ".tdata","awT",@progbits'

tls_first_major=2

tls_first_minor=14

-   tls_as_opt="-32 --fatal-warnings"

+   tls_as_opt="--fatal-warnings"

 fi

 conftest_s="$conftest_s

 foo:   .long   25

.text

sethi   %tgd_hi22(foo), %o0

add %o0, %tgd_lo10(foo), %o1

add %l7, %o1, %o0, %tgd_add(foo)

call__tls_get_addr, %tgd_call(foo)

sethi   %tldm_hi22(foo), %l1

add %l1, %tldm_lo10(foo), %l2

# 

# diff -u10 configure.orig configure

--- configure.orig  2013-01-11 11:46:21.0 +

+++ configure   2013-01-25 09:28:27.0 +

@@ -23390,21 +23390,21 @@

 if test x$on_solaris = xyes && test x$gas_flag = xno; then

   conftest_s='

.section ".tdata",#alloc,#write,#tls'

tls_first_major=0

tls_first_minor=0

 else

   conftest_s='

.section ".tdata","awT",@progbits'

tls_first_major=2

tls_first_minor=14

-   tls_as_opt="-32 --fatal-warnings"

+   tls_as_opt="--fatal-warnings"

 fi

 conftest_s="$conftest_s

 foo:   .long   25

.text

sethi   %tgd_hi22(foo), %o0

add %o0, %tgd_lo10(foo), %o1

add %l7, %o1, %o0, %tgd_add(foo)

call__tls_get_addr, %tgd_call(foo)

sethi   %tldm_hi22(foo), %l1

add %l1, %tldm_lo10(foo), %l2

#





I then get this failure:



gmake[4]: Leaving directory

`/usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libgcc'

/usr/ports/lang/gcc48/work/build/./gcc/xgcc

-B/usr/ports/lang/gcc48/work/build/./gcc/ -B/usr/local/

sparc64-portbld-freebsd10.0/bin/ -B/usr/local/sparc64-portbld-freebsd10.0/lib/

-isystem /usr/local/

sparc64-portbld-freebsd10.0/include -isystem

/usr/local/sparc64-portbld-freebsd10.0/sys-include

-g -O2 -pipe -I/usr/local/include -fno-strict-aliasing -O2  -g -O2 -pipe

-I/usr/local/include -fno-

strict-aliasing -DIN_GCC   -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual

-Wstrict-prototypes

-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fPIC

-pthread -g -DIN_LIBGCC2 -f

building-libgcc -fno-stack-protector   -fPIC -pthread -I. -I. -I../.././gcc

-I../.././../gcc-4.8-20

130113/libgcc -I../.././../gcc-4.8-20130113/libgcc/.

-I../.././../gcc-4.8-20130113/libgcc/../gcc -I

../.././../gcc-4.8-20130113/libgcc/../include  -DHAVE_CC_TLS  -o _muldc3.o -MT

_muldc3.o -MD -MP -M

F _muldc3.dep -DL_muldc3 -c ../.././../gcc-4.8-20130113/libgcc/libgcc2.c

-fvisibility=hidden -DHIDE

_EXPORTS

In file included from ../.././../gcc-4.8-20130113/libgcc/libgcc2.c:58:0:

../.././../gcc-4.8-20130113/libgcc/libgcc2.h:254:16: warning: conflicting types

for built-in functi

on '__divdc3' [enabled by default]

 #define __N(a) __ ## a

^

../.././../gcc-4.8-20130113/libgcc/libgcc2.h:363:19: note: in expansion of

macro '__N'

 #define __divdc3  __N(divdc3)

   ^

../.././../gcc-4.8-20130113/libgcc/libgcc2.h:452:15: note: in expansion of

macro '__divdc3'

 extern DCtype __divdc3 (DFtype, DFtype, DFtype, DFtype);

   ^

../.././../gcc-4.8-20130113/libgcc/libgcc2.h:254:16: warning: conflicting types

for built-in functi

on '__muldc3' [enabled by default]

 #define __N(a) __ ## a

^

../.././../gcc-4.8-20130113/libgcc/libgcc2.h:351:19: note: in expansion of

macro '__N'

 #define __muldc3  __N(muldc3)

   ^

../.././../gcc-4.8-20130113/libgcc/libgcc2.h:453:15: note: in expansion of

macro '__muldc3'

 extern DCtype __muldc3 (DFtype, DFtype, DFtype, DFtype);

   ^

../.././../gcc-4.8-20130113/libgcc/libgcc2.h:254:16: warning: conflicting types

for built-in functi

on '__divtc3' [enabled by default]

 #define __N(a) __ ## a

^

../.././../gcc-4.8-20130113/libgcc/libgcc2.h:369:19: note: in expansion of

macro '__N'

 #define __divtc3  __N(divtc3)



../.././../gcc-4.8-20130113/libgcc/libgcc2.h:473:15: note: in expansion of

macro '__divtc3'

 extern TCtype __divtc3 (TFtype, TFtype, TFtype, TFtype);

   ^

../.././../gcc-4.8-20130113/libgcc/libgcc2.h:254:16: warning: conflicting types

for built-in functi

on '__multc3' [enabled by default]

 #define __N(a) __ ## a

^

../.././../gcc-4.8-20130113/libgcc/libgcc2.h:357:19: note: in ex

[Bug libstdc++/56103] New: Overwrite classes on destruction for debug

[glisse at gcc dot gnu.org]

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



 Bug #: 56103

   Summary: Overwrite classes on destruction for debug

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: enhancement

  Priority: P3

 Component: libstdc++

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

ReportedBy: gli...@gcc.gnu.org

CC: r...@gcc.gnu.org





See the discussion starting here for more details:

http://gcc.gnu.org/ml/libstdc++/2013-01/msg00064.html



Overwriting classes like string or vector with garbage when they are destructed

can help detect uses after destruction.



Note that there is a suggestion to handle it at the compiler level for all

classes, instead of manually for a few classes of the standard library.

[Bug c++/56104] New: Wrong "dereferencing type-punned pointer" warning

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

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



 Bug #: 56104

   Summary: Wrong "dereferencing type-punned pointer" warning

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: joerg.rich...@pdv-fs.de





cat > t.cc <

struct Wrap

{

inline static void call( Foo cc )

{

  (cc.*MEMFUNC)(); // <- warning here

}

};



void bar()

{

  Wrap::call( Foo() );

}

EOF



/tools/pkg/gcc/4.7.2/bin/g++ -Wall -O2 -c -o t.o t.cc





Outputs:

t.cc: In instantiation of 'static void Wrap::call(Foo) [with

MEMSIG = void (Foo::*)(); MEMSIG MEMFUNC = &Foo::call]':

t.cc:18:38:   required from here

t.cc:12:7: warning: dereferencing type-punned pointer will break

strict-aliasing rules [-Wstrict-aliasing]



I think this warning is wrong.

[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts

[jakub at gcc dot gnu.org]

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



--- Comment #12 from Jakub Jelinek  2013-01-25 
11:29:13 UTC ---

Created attachment 29272

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

gcc48-pr56094.patch



input_location is used heavily in the gimplifier, gimplify_expr sets it from

the expression being currently gimplified (if it has any), and for temporaries

and their initializers that are created while gimplifying that stmt it is

intentional to use the location of that expression.



I've bootstrapped/regtested this patch on i686-linux (no ada) so far, the lex.c

hunk is to avoid ICEs when e.g. tree-parloops.c calls the make_type langhook

(but there are other callers of that) with input_location of UNKNOWN_LOCATION.

I was surprised there weren't regressions, given that input_location is used

implicitly e.g. by all error/warning calls, unless they supply their own

location.

[Bug libstdc++/56103] Overwrite classes on destruction for debug

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-25

 Ever Confirmed|0   |1

[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts

[manu at gcc dot gnu.org]

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

--- Comment #13 from Manuel López-Ibáñez  2013-01-25 
11:43:37 UTC ---
(In reply to comment #12)
> Created attachment 29272 [details]
> gcc48-pr56094.patch
> 
> input_location is used heavily in the gimplifier, gimplify_expr sets it from
> the expression being currently gimplified (if it has any), and for temporaries
> and their initializers that are created while gimplifying that stmt it is
> intentional to use the location of that expression.

You are explaining how it works right now. What I am asking is how we want it
to work, that is, why the gimplifier needs to care about input_location and
cannot use *always* the location of the expression being gimplified (or some
sub-expression) or UNKNOWN_LOCATION for things that are compiler generated.

Moreover, if gimplifying occurs after parsing is completed, why do we need to
use input_location as a communication device between parts of the gimplifier,
why not just use some gimplifier-specific state or pass down specific
locations.

> I've bootstrapped/regtested this patch on i686-linux (no ada) so far, the 
> lex.c
> hunk is to avoid ICEs when e.g. tree-parloops.c calls the make_type langhook
> (but there are other callers of that) with input_location of UNKNOWN_LOCATION.
> I was surprised there weren't regressions, given that input_location is used
> implicitly e.g. by all error/warning calls, unless they supply their own
> location.

Does the diagnostic machinery assert that input_location != UNKNOWN_LOCATION? I
think not. I seem to remember that we sometimes generate:

warning:0:0: something

but I am not sure if this happens for warning_at(UNKNOWN_LOCATION).

[Bug libmudflap/56105] New: Simple ANSI C 89 code -> Mudflap false violation

[m.labanowicz at gmail dot com]

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



 Bug #: 56105

   Summary: Simple ANSI C 89 code -> Mudflap false violation

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libmudflap

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

ReportedBy: m.labanow...@gmail.com





$ gcc --version

gcc (Ubuntu/Linaro 4.7.2-11precise2) 4.7.2



$ gawk '{printf("%02u: %s\n", NR, $0);}' bar.c

01: long bar_fun(unsigned idx) {

02:   long bar_cfg [][2] = {

03: {9, 0}, {8, 1}, {7, 2}, {6, 3},

04: {5, 4}, {4, 5}, {3, 6}, {2, 7},

05: {0, 9}

06:   };

07:   return (idx < (unsigned)(sizeof(bar_cfg) / sizeof(*bar_cfg)))

08: ? bar_cfg[idx][1] : -1;

09: }



$ gawk '{printf("%02u: %s\n", NR, $0);}' main.c

01: #include  /* printf */

02: #include  /* EXIT_SUCCESS */

03: long bar_fun(unsigned idx);

04: static long foo_fun(unsigned idx) {

05:   long const TOSTEP [][2] = {

06: {0, 9}, {1, 8}, {2, 7}, {3, 6},

07: {4, 5}, {5, 4}, {6, 3}, {7, 2},

08: {8, 1}, {9, 0}

09:   };

10:   return (idx < (unsigned)(sizeof(TOSTEP) / sizeof(*TOSTEP)))

11: ? (int)(TOSTEP[idx][1]) : -1;

12: }

13: int main(void) {

14:   printf("foo_fun = %ld\r\n", foo_fun(4));

15:   printf("bar_fun = %ld\r\n", bar_fun(4));

16:   return EXIT_SUCCESS;

17: }



$ gcc -ansi -pedantic -Wall -W -Werror -fmudflap bar.c main.c -lmudflap -o

a.out



$ echo ":${MUDFLAP_OPTIONS}:"

::



$ ./a.out

***

mudflap violation 1 (register): time=1359114674.510460 ptr=0xbfd664d0 size=80

pc=0xb76c3b4e

  /usr/lib/i386-linux-gnu/libmudflap.so.0(__mf_register+0x3e) [0xb76c3b4e]

  ./a.out() [0x8048ab9]

  ./a.out(__libc_csu_init+0x52) [0x8048b62]

Nearby object 1: checked region begins 8B before and ends 71B into

mudflap object 0x89081e8: name=`constant'

bounds=[0xbfd664d8,0xbfd6651f] size=72 area=static check=0r/0w liveness=0

alloc time=1359114674.510456 pc=0xb76c3b4e

number of nearby objects: 1

foo_fun = 5

bar_fun = 4



-[END]---

[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  2013-01-25 
12:04:59 UTC ---
(In reply to comment #13)

> You are explaining how it works right now. What I am asking is how we want it
> to work, that is, why the gimplifier needs to care about input_location and
> cannot use *always* the location of the expression being gimplified (or some
> sub-expression) or UNKNOWN_LOCATION for things that are compiler generated.

Because not all the gimplifier routines see the current expression as whole,
they can work on some subexpression etc., and not all expressions have
location.  So, you generally want to use a location of some expression (if
known) for all the subexpressions that don't have their own location.
Currently that is performed in the gimplifier by saving the current location
in input_location variable and then lots of code use that.  Alternative to that
is use some different variable, gimplifier_location or whatever.  But you'd
really need to change lots of code for that, and I'd be afraid that some code
that needs that could be shared between FEs and the gimplifier.  E.g. make_node
uses input_location, which is desirable in the FEs, but with such a change
would be undesirable in the gimplifier.

> Does the diagnostic machinery assert that input_location != UNKNOWN_LOCATION? 
> I
> think not. I seem to remember that we sometimes generate:
> 
> warning:0:0: something
> 
> but I am not sure if this happens for warning_at(UNKNOWN_LOCATION).

E.g. for warning_at, instead of printing say:
qqq.c: In function ‘foo’:
qqq.c:4:34: warning: argument to ‘sizeof’ in ‘__builtin_memset’ call is the
same expression as the destination; did you mean to provide an explicit length?
[-Wsizeof-pointer-memaccess]
if the first argument is changed to UNKNOWN_LOCATION, it prints:
qqq.c: In function ‘foo’:
cc1: warning: argument to ‘sizeof’ in ‘__builtin_memset’ call is the same
expression as the destination; did you mean to provide an explicit length?
[-Wsizeof-pointer-memaccess]

[Bug libstdc++/56106] New: complex pow improvements

[glisse at gcc dot gnu.org]

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



 Bug #: 56106

   Summary: complex pow improvements

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libstdc++

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

ReportedBy: gli...@gcc.gnu.org





See this discussion for more details:

http://gcc.gnu.org/ml/libstdc++/2013-01/msg00058.html



Several improvements seem possible.



1) in pow(const complex<_Tp>& __x, const _Tp& __y), if _GLIBCXX_USE_C99_COMPLEX

&& !_GLIBCXX_FAST_MATH, we could convert y to a complex and call the libc

version, more accurate than chaining several calls. (I mention

_GLIBCXX_FAST_MATH assuming that the version with polar, exp and log is faster

than the general libc version, I don't know if that is really the case)



2) among the pow(complex,scalar) overloads, those for which scalar is an

integer could be split out and implemented with recursive squaring (as

currently done in C++03 mode for int only). Note that when the exponent is not

-1, 0, 1 or 2, this might also require _GLIBCXX_FAST_MATH ||

!_GLIBCXX_USE_C99_COMPLEX as it may not give anymore the correctly rounded

result.



Note that the libc version may already test for real or small integer

arguments, so we can't expect a huge performance benefit from not calling it in

these cases.

[Bug libgcc/56101] pthread program abort

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-25

 Ever Confirmed|0   |1



--- Comment #1 from Jonathan Wakely  2013-01-25 
12:38:31 UTC ---

(In reply to comment #0)

> /remote/depotsrc/depotsrc/amd64-2.6/local_install/gcc-4.7.2_test2/bin/g++ -I.

> -Wall -Wextra -fno-strict-aliasing -fwrapv -m64 -c  -msse2 -mfpmath=sse 

> -fno-omit-frame-pointer -fno-dollars-in-identifiers -save-temps -pthread -o

> tmain.o tmain.C

> /remote/depotsrc/depotsrc/amd64-2.6/local_install/gcc-4.7.2_test2/bin/g++

> -static-libgcc -static-libstdc++  -o mtest tmain.o -pthread -lm -ldl



Most of these flags are irrelevant, only these are needed to reproduce it:



   -static-libgcc -static-libstdc++ -pthread



If either libgcc or libstdc++ is dynamically linked it doesn't abort

[Bug c++/56104] Wrong "dereferencing type-punned pointer" warning

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #1 from Daniel Krügler  
2013-01-25 13:03:27 UTC ---
I can see the same warning for gcc 4.8.0 20130120 (experimental). It's
essential to have -02 set (maybe even higher). I agree that the diagnostics
seems incorrect and the code seems to be well-formed and well-defined.

[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 #42 from Jack Howarth  2013-01-25 
13:23:12 UTC ---

Full regression testing on x86_64-apple-darwin12 of proposed patch to supply

dummy functions as a static archive shows no regressions in any tm tests...



http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg02648.html

[Bug fortran/56107] New: [4.8 Regression] FAIL: gfortran.dg/class_optional_2.f90 -O2 execution test

[ubizjak at gmail dot com]

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



 Bug #: 56107

   Summary: [4.8 Regression] FAIL:

gfortran.dg/class_optional_2.f90  -O2  execution test

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

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

ReportedBy: ubiz...@gmail.com

CC: ja...@gcc.gnu.org, j...@gcc.gnu.org

  Host: x86_64-pc-linux-gnu

Target: i686-pc-linux-gnu





Recent gfortran regression on i686-pc-linux-gnu:



Program aborted. Backtrace:

#0  0xF7EC75C3

#1  0xF7EC903F

#2  0xF7F80A67

#3  0x80488F4 in a3a1.2065.constprop.8 at class_optional_2.f90:0

FAIL: gfortran.dg/class_optional_2.f90  -O2  execution test



Regressed between revision 195413 vs revision 195410 [1].



Added CCs of suspected comitters.



[1] http://gcc.gnu.org/ml/gcc-regression/2013-01/msg00255.html

[Bug c/56108] New: Asm statement in transaction_relaxed crashes compiler.

[srdjan.stipic at gmail dot com]

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

 Bug #: 56108
   Summary: Asm statement in transaction_relaxed crashes compiler.
Classification: Unclassified
   Product: gcc
   Version: trans-mem
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: srdjan.sti...@gmail.com


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

Asm statement in transaction_relaxed crashes compiler.

Example:

// file: min.c
int main() {
  __transaction_relaxed{ asm(""); }
  return 0;
}

Compiler error:

~# gcc -fgnu-tm min.c -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.2-2ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) 
COLLECT_GCC_OPTIONS='-fgnu-tm' '-v' '-mtune=generic' '-march=x86-64' '-pthread'
 /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1 -quiet -v -imultiarch x86_64-linux-gnu
-D_REENTRANT min.c -quiet -dumpbase min.c -mtune=generic -march=x86-64 -auxbase
min -version -fgnu-tm -fstack-protector -o /tmp/cckJBrnc.s
GNU C (Ubuntu/Linaro 4.7.2-2ubuntu1) version 4.7.2 (x86_64-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/4.7/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C (Ubuntu/Linaro 4.7.2-2ubuntu1) version 4.7.2 (x86_64-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: efa32fef7aa241fa03ac6d7ad2a4a2cf
min.c: In function ‘main’:
min.c:1:5: internal compiler error: in expand_block_tm, at trans-mem.c:2375
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccPdFHFN.out file, please attach this to
your bugreport.

[Bug fortran/56107] [4.8 Regression] FAIL: gfortran.dg/class_optional_2.f90 -O2 execution test

[janus at gcc dot gnu.org]

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



--- Comment #1 from janus at gcc dot gnu.org 2013-01-25 14:27:10 UTC ---

This is probably a duplicate of PR 55978 (which, however, was claimed to be due

to r195125, which does not match the interval in comment 0).

[Bug fortran/56107] [4.8 Regression] FAIL: gfortran.dg/class_optional_2.f90 -O2 execution test

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.8.0

[Bug c++/56104] [4.7/4.8 Regression] Wrong "dereferencing type-punned pointer" warning

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-25

 CC||jakub at gcc dot gnu.org

   Target Milestone|--- |4.7.3

Summary|Wrong "dereferencing|[4.7/4.8 Regression] Wrong

   |type-punned pointer"|"dereferencing type-punned

   |warning |pointer" warning

 Ever Confirmed|0   |1



--- Comment #2 from Jakub Jelinek  2013-01-25 
14:35:46 UTC ---

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

Of course, might be a FE bug which has been just latent before.

[Bug fortran/54107] [4.8 Regression] Memory hog with abstract interface

[janus at gcc dot gnu.org]

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



--- Comment #11 from janus at gcc dot gnu.org 2013-01-25 14:36:34 UTC ---

(In reply to comment #9)

> Maybe we could remove gfc_copy_formal_args{,_ppc} completely.  After all, we

> keep a pointer to the interface, so the dummy arguments remain available

> through sym->ts.interface->formal.



Yes, I think this should work in principle. Also it seems to be the only sane

way to avoid the infinite-loop problem.

[Bug middle-end/56098] [4.6/4.7/4.8 Regression] conditional write through volatile pointer produces unintended read

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-25

 CC||matz at gcc dot gnu.org

   Target Milestone|--- |4.6.4

Summary|conditional write through   |[4.6/4.7/4.8 Regression]

   |volatile pointer produces   |conditional write through

   |unintended read |volatile pointer produces

   ||unintended read

 Ever Confirmed|0   |1



--- Comment #2 from Richard Biener  2013-01-25 
14:42:43 UTC ---

This is cselim at work, preparing the way for if-conversion of the store ...



It shouldn't do this for volatiles of course.



Workaround: -fno-tree-cselim

[Bug fortran/54107] [4.8 Regression] Memory hog with abstract interface

[janus at gcc dot gnu.org]

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



--- Comment #12 from janus at gcc dot gnu.org 2013-01-25 14:43:51 UTC ---

Created attachment 29274

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

patch v2



Here is an updated version of Mikael's patch, which is free of testsuite

regressions.





It fixes comment #0, but fails with a very strange backtrace on comment 4:



gfortran-4.8: internal compiler error: Segmentation fault (program f951)

0x4069a3 execute

/home/jweil/gcc48/trunk/gcc/gcc.c:2789

0x40adb1 do_spec_1

/home/jweil/gcc48/trunk/gcc/gcc.c:4581

0x40e36e process_brace_body

/home/jweil/gcc48/trunk/gcc/gcc.c:5838

0x40e18a handle_braces

/home/jweil/gcc48/trunk/gcc/gcc.c:5752

0x40ce19 do_spec_1

/home/jweil/gcc48/trunk/gcc/gcc.c:5235

0x40e36e process_brace_body

/home/jweil/gcc48/trunk/gcc/gcc.c:5838

0x40e18a handle_braces

/home/jweil/gcc48/trunk/gcc/gcc.c:5752

0x40ce19 do_spec_1

/home/jweil/gcc48/trunk/gcc/gcc.c:5235

0x40d225 do_spec_1

/home/jweil/gcc48/trunk/gcc/gcc.c:5340

0x40e36e process_brace_body

/home/jweil/gcc48/trunk/gcc/gcc.c:5838

0x40e18a handle_braces

/home/jweil/gcc48/trunk/gcc/gcc.c:5752

0x40ce19 do_spec_1

/home/jweil/gcc48/trunk/gcc/gcc.c:5235

0x40e36e process_brace_body

/home/jweil/gcc48/trunk/gcc/gcc.c:5838

0x40e18a handle_braces

/home/jweil/gcc48/trunk/gcc/gcc.c:5752

0x40ce19 do_spec_1

/home/jweil/gcc48/trunk/gcc/gcc.c:5235

0x40a40b do_spec_2

/home/jweil/gcc48/trunk/gcc/gcc.c:4282

0x40a329 do_spec(char const*)

/home/jweil/gcc48/trunk/gcc/gcc.c:4249

[Bug tree-optimization/56097] [4.7 Regression] Segmentation fault with -01 -ftree-vrp -ftree-loop-distribution -funswitch-loops

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Target||i?86-*-*

  Known to work||4.6.3, 4.8.0

   Target Milestone|--- |4.7.3

Summary|Segmentation fault with -01 |[4.7 Regression]

   |-ftree-vrp  |Segmentation fault with -01

   |-ftree-loop-distribution|-ftree-vrp

   |-funswitch-loops|-ftree-loop-distribution

   ||-funswitch-loops

  Known to fail||4.7.2



--- Comment #1 from Richard Biener  2013-01-25 
14:46:04 UTC ---

Confirmed with -m32 codegen on the 4.7 branch, works on the trunk and with 4.6.

[Bug libstdc++/56109] New: Add light-weight ABI-compatible debug checks to standard containers

[ppluzhnikov at google dot com]

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



 Bug #: 56109

   Summary: Add light-weight ABI-compatible debug checks to

standard containers

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: enhancement

  Priority: P3

 Component: libstdc++

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

ReportedBy: ppluzhni...@google.com





Google has implemented a series of patches which allows us to catch many STL

mis-use bugs cheaply and in ABI-compatible way:



http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01186.html

http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01074.html and more ...

(just look for __google_stl in google/integration branch).



Some of the bugs we catch this way are not visible to "standard" tools like

Valgrind and AddressSanitizer.



These bugs (and more) *are* visible to _GLIBCXX_DEBUG mode, but we've not been

able to use that mode due to source incompatibilities, and it has ABI

implications as well.



Please consider adding a light-weight ABI-compatible debug mode to trunk, once

it re-opens for stage 1.

[Bug c++/56104] [4.7/4.8 Regression] Wrong "dereferencing type-punned pointer" warning

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jason at gcc dot gnu.org



--- Comment #3 from Jakub Jelinek  2013-01-25 
14:57:47 UTC ---

Guess the relevant change in the patch is:

--- trunk/gcc/cp/typeck.c2011/07/19 13:28:15176460

+++ trunk/gcc/cp/typeck.c2011/07/19 14:01:59176461

@@ -3078,8 +3078,7 @@

 return error_mark_node;

 }

   /* ...and then the delta in the PMF.  */

-  instance_ptr = build2 (POINTER_PLUS_EXPR, TREE_TYPE (instance_ptr),

- instance_ptr, fold_convert (sizetype, delta));

+  instance_ptr = fold_build_pointer_plus (instance_ptr, delta);



   /* Hand back the adjusted 'this' argument to our caller.  */

   *instance_ptrptr = instance_ptr;

where we didn't fold the POINTER_PLUS_EXPR in this case before (delta is 0

here), but now we do.

The above is followed by:

  /* Next extract the vtable pointer from the object.  */

  vtbl = build1 (NOP_EXPR, build_pointer_type (vtbl_ptr_type_node),

 instance_ptr);

  vtbl = cp_build_indirect_ref (vtbl, RO_NULL, complain);

  if (vtbl == error_mark_node)

return error_mark_node;

and during cp_build_indirect_ref this warns, instance_ptr here is ADDR_EXPR of

cc VAR_DECL, and as the class type of cc isn't virtual, it doesn't have a

vtable pointer at the beginning.

[Bug c++/56104] [4.7/4.8 Regression] Wrong "dereferencing type-punned pointer" warning

[jakub at gcc dot gnu.org]

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



--- Comment #4 from Jakub Jelinek  2013-01-25 
15:05:48 UTC ---

Given the

/* If the object is not dynamic the access invokes undefined

   behavior.  As it is not executed in this case silence the

   spurious warnings it may provoke.  */

comment after it, can't we just build the INDIRECT_REF by hand instead of

cp_build_indirect_ref ?  Or revert richi's hunk and force always

POINTER_PLUS_EXPR, even for zero offset?  Then this warning isn't emitted.

[Bug c++/56104] [4.7/4.8 Regression] Wrong "dereferencing type-punned pointer" warning

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #5 from Jason Merrill  2013-01-25 
15:32:17 UTC ---

If we know the dynamic type of the object, we can avoid building the

questionable code in the first place.

[Bug tree-optimization/56034] [4.8 Regression] ICE: verify_gimple failed (invalid PHI argument) with -ftree-loop-distribution

[mpolacek at gcc dot gnu.org]

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



--- Comment #4 from Marek Polacek  2013-01-25 
15:33:57 UTC ---

So, we replace

# a.0_26 = PHI 

with

# a.0_26 = PHI <.MEM_10(5)>

This happens when we call rewrite_into_loop_closed_ssa in case we're actually

performing some loop distribution transformation.  Then we call update_ssa and

here with

  FOR_EACH_VEC_ELT (symbols_to_rename, i, sym) 

insert_updated_phi_nodes_for (sym, dfs, blocks_to_update,

  update_flags);

change the PHI argument.

[Bug middle-end/56098] [4.6/4.7/4.8 Regression] conditional write through volatile pointer produces unintended read

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #3 from Jakub Jelinek  2013-01-25 
15:34:58 UTC ---

Created attachment 29275

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

gcc48-pr56098.patch



Untested fix.

[Bug fortran/55907] [4.6/4.7/4.8 Regression] ICE with -fno-automatic -finit-local-zero

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Keywords||ice-on-valid-code

   Last reconfirmed||2013-01-25

 CC||janus at gcc dot gnu.org

 Ever Confirmed|0   |1

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

   |gfc_get_symbol_decl, at |ICE with -fno-automatic

   |fortran/trans-decl.c:1418   |-finit-local-zero



--- Comment #1 from janus at gcc dot gnu.org 2013-01-25 16:30:22 UTC ---

Confirmed. Fails with 4.6, 4.7 and trunk, while it works at least with 4.3.



Reduced/modified test case:



subroutine cchaine (i)

  implicit none

  integer :: i

  character(len=i) :: chaine

  write(*,*) chaine

end subroutine 







Backtrace on trunk:



internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1441

 subroutine cchaine (i)

 ^

0x6500e4 gfc_get_symbol_decl(gfc_symbol*)

/home/jweil/gcc48/trunk/gcc/fortran/trans-decl.c:1441

0x65b9e6 generate_local_decl

/home/jweil/gcc48/trunk/gcc/fortran/trans-decl.c:4601

0x611b36 do_traverse_symtree

/home/jweil/gcc48/trunk/gcc/fortran/symbol.c:3449

0x611c02 gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*))

/home/jweil/gcc48/trunk/gcc/fortran/symbol.c:3474

0x65c020 generate_local_vars

/home/jweil/gcc48/trunk/gcc/fortran/trans-decl.c:4760

0x65dad4 gfc_generate_function_code(gfc_namespace*)

/home/jweil/gcc48/trunk/gcc/fortran/trans-decl.c:5334

0x62ea00 gfc_generate_code(gfc_namespace*)

/home/jweil/gcc48/trunk/gcc/fortran/trans.c:1705

0x5cdff5 translate_all_program_units

/home/jweil/gcc48/trunk/gcc/fortran/parse.c:4463

0x5ce65b gfc_parse_file()

/home/jweil/gcc48/trunk/gcc/fortran/parse.c:4677

0x61adad gfc_be_parse_file

/home/jweil/gcc48/trunk/gcc/fortran/f95-lang.c:189

[Bug target/56110] New: Sub-optimal code: unnecessary CMP after AND

[til...@code-monkey.de]

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



 Bug #: 56110

   Summary: Sub-optimal code: unnecessary CMP after AND

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

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

ReportedBy: til...@code-monkey.de

Target: arm





Compiling this code



unsigned f1 (unsigned x, unsigned m)

{

if (m & 0x008080)

x >>= 8;



return x;

}



with gcc 4.7.2 gives this code for ARMv5:



$ armv5tel-softfloat-linux-gnueabi-gcc -O2 -S -o- f1.c

[...]

ldrr3, .L6

andr3, r1, r3   @ XXX

cmpr3, #0   @ XXX

movner0, r0, lsr #8

bxlr

[...]



AFAICS we could get rid of the CMP if we used ANDS instead of AND:



ldrr3, .L6

andsr3, r1, r3

movner0, r0, lsr #8

bxlr

[Bug fortran/55907] [4.6/4.7/4.8 Regression] ICE with -fno-automatic -finit-local-zero

[dominiq at lps dot ens.fr]

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



--- Comment #2 from Dominique d'Humieres  2013-01-25 
17:12:52 UTC ---

Revision 183136 (2012-01-12) is OK; revision 183306 (2012-01-19) gives the ICE.

This is due to a change made on 4.7 and backported to 4.6.

[Bug fortran/55907] [4.6/4.7/4.8 Regression] ICE with -fno-automatic -finit-local-zero

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #3 from Dominique d'Humieres  2013-01-25 
17:21:14 UTC ---

I'll bet on r183180 (pr51800). CCed Tobias.

[Bug fortran/55978] [4.8 Regression] class_optional_2.f90 -Os fails

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 CC||ubizjak at gmail dot com



--- Comment #9 from Dominique d'Humieres  2013-01-25 
17:44:18 UTC ---

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

[Bug fortran/56107] [4.8 Regression] FAIL: gfortran.dg/class_optional_2.f90 -O2 execution test

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #2 from Dominique d'Humieres  2013-01-25 
17:44:18 UTC ---

As said in pr55978 comment #2, the bug is latent on some platforms (e.g.,

darwin) so it may not be triggered by the testsuite and may need to use

valgrind to see it. As any latent bug it may be exposed in the test suite by

unrelated changes (I still don't see it on darwin at r195432). Si I am marking

the PR as a duplicate of pr55978.



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

[Bug c++/56111] New: {float,double} complex not accepted by g++-4.8 anymore

[jtaylor.debian at gmail dot com]

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



 Bug #: 56111

   Summary: {float,double} complex not accepted by g++-4.8 anymore

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: jtaylor.deb...@gmail.com





the C99 float and double complex is not accepted by g++ 4.8 r195467 anymore in

c++98 or c++11.

Even though its technically not part of c++98 it worked in all gcc versions I

ever used.

Is this change intentional? It will break the compilation of a bunch of

scientific c++ software using C libraries.



$ cat test.c

#include 

int testing(float complex a);



int main()

{

float complex a = 1;

return testing(a);

}

$ gcc-4.7 test.c -c

$ gcc-4.8 test.c -c

$ g++-4.7 test.c -c



$ g++-4.8 test.c -c

test.c:2:27: error: expected ',' or '...' before 'a'

 int testing(float complex a);

   ^

test.c: In function 'int main()':

test.c:6:15: error: expected initializer before 'a'

 float complex a = 1;

   ^

test.c:7:16: error: 'a' was not declared in this scope

 return testing(a);

^

$ g++-4.8 -std=c++98 test.c -c

test.c:2:27: error: expected ',' or '...' before 'a'

 int testing(float complex a);

   ^

test.c: In function 'int main()':

test.c:6:15: error: expected initializer before 'a'

 float complex a = 1;

   ^

test.c:7:16: error: 'a' was not declared in this scope

 return testing(a);

^

$ g++-4.8 --version

g$-4.8 (Debian 4.8-20130123-1) 4.8.0 20130123 (experimental) [trunk revision

195400]

Copyright (C) 2013 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.





also reproduced with svn trunk r195467 built on a fedora 11 machine.

using ccomplex and -std=c++11 does not work either.

[Bug c++/56104] [4.7/4.8 Regression] Wrong "dereferencing type-punned pointer" warning

[jason at gcc dot gnu.org]

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



--- Comment #6 from Jason Merrill  2013-01-25 
17:55:22 UTC ---

Author: jason

Date: Fri Jan 25 17:55:09 2013

New Revision: 195470



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

Log:

PR c++/56104

* typeck.c (get_member_function_from_ptrfunc): Optimize if the

dynamic type has no virtual functions.



Added:

trunk/gcc/testsuite/g++.dg/warn/pmf2.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/typeck.c

trunk/gcc/testsuite/g++.old-deja/g++.mike/pmf1.C

[Bug tree-optimization/56034] [4.8 Regression] ICE: verify_gimple failed (invalid PHI argument) with -ftree-loop-distribution

[rguenth at gcc dot gnu.org]

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



--- Comment #5 from Richard Biener  2013-01-25 
18:16:08 UTC ---

(In reply to comment #4)

> So, we replace

> # a.0_26 = PHI 

> with

> # a.0_26 = PHI <.MEM_10(5)>

> This happens when we call rewrite_into_loop_closed_ssa in case we're actually

> performing some loop distribution transformation.  Then we call update_ssa and

> here with

>   FOR_EACH_VEC_ELT (symbols_to_rename, i, sym) 

> insert_updated_phi_nodes_for (sym, dfs, blocks_to_update,

>   update_flags);

> change the PHI argument.



Note that this only can happen if a.0_10 was released but still used before.



I'm still going to look into this after I return on monday.

[Bug tree-optimization/53787] Possible IPA-SRA / IPA-CP improvement

[jamborm at gcc dot gnu.org]

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



--- Comment #16 from Martin Jambor  2013-01-25 
18:32:39 UTC ---

I do have a caller of the clone (in the WPA dump):



init_.constprop.2/71 (init_.constprop.2) @0x7f10180f06f0

  Type: function

  ...

  Clone of init_/41

  ...

  Called by: driver_.constprop.1/70 (1.00 per call) 

  Calls: memcpy/49 (1.00 per call) 



that is not the problem.  The problem is that the pass-through jump

function for npart does not have the agg_preserved flag set.  Ido not

yet know why that is the case, nevertheless it means the value is not

propagated to init.  I will have a detailed look, thanks a lot for

the testcase.

[Bug c++/56111] {float,double} complex not accepted by g++-4.8 anymore

[glisse at gcc dot gnu.org]

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



Marc Glisse  changed:



   What|Removed |Added



 CC||glisse at gcc dot gnu.org



--- Comment #1 from Marc Glisse  2013-01-25 19:14:03 
UTC ---

You need to write _Complex or __complex__. complex is a macro that breaks code

from the standard library (think std::complex) so we are forced to

undefine it. See PR54112 for details of the change.



If we really wanted to, I guess we could #undef complex at the beginning of

 and condition the #undef in  to the fact that 

has been included before...

[Bug libstdc++/56112] New: [4.8 Regression] cannot create unordered_map from range of types convertible to value_type

[redi at gcc dot gnu.org]

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



 Bug #: 56112

   Summary: [4.8 Regression] cannot create unordered_map from

range of types convertible to value_type

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: rejects-valid

  Severity: normal

  Priority: P3

 Component: libstdc++

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

ReportedBy: r...@gcc.gnu.org





#include 



struct S

{

operator std::pair() const { return {}; }

};



int main()

{

S s[1];

std::unordered_map m(s, s+1);   // error



std::pair p = *s;  // OK

m.insert(s, s+1);  // OK

}





This is valid (value_type is EmplaceConstructible into the container from s[0])

but it fails to compile because of the change to use std::__detail::_Select1st

instead of std::_Select1st



The template argument for _Select1st::operator() cannot be deduced from the

object of type S. The problem boils down to this:



#include 



struct S

{

operator std::pair() const { return {}; }

};



void f()

{

S s;

std::get<0>(s);

}



This is not valid, but the range constructors of unordered_map and

unordered_multimap assume using std::get<0> on the iterator's value type will

work, which is not a valid assumption.

[Bug debug/54410] [4.6/4.7/4.8 Regression] doubled DW_TAG_template_type_param

[law at redhat dot com]

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



Jeffrey A. Law  changed:



   What|Removed |Added



 CC||law at redhat dot com

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

   |DW_TAG_template_type_param  |doubled

   ||DW_TAG_template_type_param



--- Comment #1 from Jeffrey A. Law  2013-01-25 19:54:54 
UTC ---

Based on private email with Tom, GCC 4.5 does not emit duplicates for the

parameter while 4.6 and 4.8 (and presumably 4.7) do.  Adding regression marker.

[Bug c++/56095] [4.6/4.7/4.8 Regression] Crash casting function pointer as non-type template argument

[jason at gcc dot gnu.org]

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



--- Comment #7 from Jason Merrill  2013-01-25 
20:01:35 UTC ---

Author: jason

Date: Fri Jan 25 20:01:29 2013

New Revision: 195474



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

Log:

PR c++/56095

* pt.c (convert_nontype_argument_function): Handle invalid input.

(convert_nontype_argument): Likewise.



Added:

trunk/gcc/testsuite/g++.dg/template/fn-ptr2.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/pt.c

[Bug middle-end/56098] [4.6/4.7/4.8 Regression] conditional write through volatile pointer produces unintended read

[jakub at gcc dot gnu.org]

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



--- Comment #4 from Jakub Jelinek  2013-01-25 
20:04:01 UTC ---

Author: jakub

Date: Fri Jan 25 20:03:54 2013

New Revision: 195475



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

Log:

PR tree-optimization/56098

* tree-ssa-phiopt.c (nt_init_block): Don't call add_or_mark_expr

for stmts with volatile ops.

(cond_store_replacement): Don't optimize if assign has volatile ops.

(cond_if_else_store_replacement_1): Don't optimize if either

then_assign or else_assign have volatile ops.

(hoist_adjacent_loads): Don't optimize if either def1 or def2 have

volatile ops.



* gcc.dg/pr56098-1.c: New test.

* gcc.dg/pr56098-2.c: New test.



Added:

trunk/gcc/testsuite/gcc.dg/pr56098-1.c

trunk/gcc/testsuite/gcc.dg/pr56098-2.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-ssa-phiopt.c

[Bug c++/56095] [4.6/4.7 Regression] Crash casting function pointer as non-type template argument

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



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

   |Crash casting function  |casting function pointer as

   |pointer as non-type |non-type template argument

   |template argument   |



--- Comment #8 from Jakub Jelinek  2013-01-25 
20:04:59 UTC ---

Fixed on the trunk so far.

[Bug middle-end/56098] [4.6/4.7 Regression] conditional write through volatile pointer produces unintended read

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



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

   |conditional write through   |conditional write through

   |volatile pointer produces   |volatile pointer produces

   |unintended read |unintended read



--- Comment #5 from Jakub Jelinek  2013-01-25 
20:05:48 UTC ---

Fixed on the trunk so far.

[Bug c++/56095] [4.6/4.7 Regression] Crash casting function pointer as non-type template argument

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED

   Target Milestone|4.6.4   |4.8.0



--- Comment #9 from Jason Merrill  2013-01-25 
20:20:22 UTC ---

And we usually don't backport fixes for invalid code.

[Bug c++/56104] [4.7/4.8 Regression] Wrong "dereferencing type-punned pointer" warning

[jason at gcc dot gnu.org]

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



--- Comment #7 from Jason Merrill  2013-01-25 
20:26:56 UTC ---

Author: jason

Date: Fri Jan 25 20:26:46 2013

New Revision: 195476



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

Log:

PR c++/56104

* typeck.c (get_member_function_from_ptrfunc): Don't fold

POINTER_PLUS_EXPR.



Added:

branches/gcc-4_7-branch/gcc/testsuite/g++.dg/warn/pmf2.C

Modified:

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

branches/gcc-4_7-branch/gcc/cp/typeck.c

[Bug c++/56104] [4.7/4.8 Regression] Wrong "dereferencing type-punned pointer" warning

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



   Keywords||diagnostic

 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #8 from Jason Merrill  2013-01-25 
20:29:22 UTC ---

Fixed for 4.8 by not building the questionable code at all; fixed for 4.7 by

reverting the fold_build_pointer_plus change.

[Bug middle-end/53518] [4.8 regression] testsuite_abi_check.cc doesn't compile

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 CC||jason at gcc dot gnu.org

 Resolution|FIXED   |DUPLICATE



--- Comment #11 from Jason Merrill  2013-01-25 
20:35:52 UTC ---





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

[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 CC||ro at gcc dot gnu.org



--- Comment #18 from Jason Merrill  2013-01-25 
20:35:52 UTC ---

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

[Bug c/56113] New: out of memory when compiling a function with many goto labels (50k > )

[aixer77 at gmail dot com]

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



 Bug #: 56113

   Summary: out of memory when compiling a function with many goto

labels (50k > )

Classification: Unclassified

   Product: gcc

   Version: 4.6.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

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

ReportedBy: aixe...@gmail.com





Out of memory when compiling a function with many goto labels (50k > )



gcc 4.6.3 compiler(running on top of ubuntu 12.04 32-bit) failed to output an

object for a function when it comes with extremely large number of goto

labels.



Attached is a simple script that generates the test source file. Here's how to

reproduce a failure with the script.



~$./goto_gen.py 6 t.c



~$ time cc -O1 -o t t.c



cc1: out of memory allocating 4064 bytes after a total of 2309808128 bytes



real11m44.371s

user11m42.592s

sys0m1.876s



~$ time cc -O0 -o t t.c



real22m5.106s

user22m3.539s

sys0m1.640s





As you can see from the above, -O1 option trigger the problem while -O0

doesn't.



Could you anyone tell me how to workaround this situation? Or which specific

optimization option causes the issue?



Thanks a lot for your help in advance.



Regards, Kangkook

[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|RESOLVED|REOPENED

 Resolution|FIXED   |



--- Comment #19 from Jason Merrill  2013-01-25 
20:37:07 UTC ---

This change turns out to be wrong; we don't want to export the construction

vtables, as they should only be referenced by the VTTs which are emitted along

with them.  If other code is referring to those symbols, that's the bug that

should be fixed.

[Bug c/56113] out of memory when compiling a function with many goto labels (50k > )

[aixer77 at gmail dot com]

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



--- Comment #1 from Kangkook  2013-01-25 20:39:06 UTC 
---

Created attachment 29276

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

a script to generates the code that reproduces the bug

[Bug other/54814] [4.8 Regression] ICE: unable to find a register to spill in class 'R0_REG'

[gjl at gcc dot gnu.org]

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



Georg-Johann Lay  changed:



   What|Removed |Added



   Keywords||patch

  Known to work||4.7.0, 4.7.2



--- Comment #14 from Georg-Johann Lay  2013-01-25 
20:55:53 UTC ---

Attachment 28990 is pending review at



http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01255.html



with the following ChangeLog:



PR other/54814

* reload.c (find_valid_class_1): Use in_hard_reg_set_p instead of

TEST_HARD_REG_BIT.

[Bug fortran/54107] [4.8 Regression] Memory hog with abstract interface

[mikael at gcc dot gnu.org]

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



--- Comment #13 from Mikael Morin  2013-01-25 
20:58:10 UTC ---

(In reply to comment #12)

> Here is an updated version of Mikael's patch, which is free of testsuite

> regressions.



Indeed, it was not that difficult after all. :-)

Are procedure dummy arguments mutually exclusive with non-NULL procedure

interface, so that there is no dummy ambiguity in the array spec and char

length?



> 

> It fixes comment #0, but fails with a very strange backtrace on comment 4:



It seems to be an infinite recursion in gfc_get_function_type:



gfc_get_function_type (gfc_symbol * sym)

{

  [...]

  for (f = gfc_sym_get_dummy_args (sym); f; f = f->next)

{

  arg = f->sym;

  if (arg)

{

  [...]

  if (arg->attr.flavor == FL_PROCEDURE)

{

  type = gfc_get_function_type (arg);

  type = build_pointer_type (type);

}

[Bug fortran/55905] [OOP] [F008] ICE for polymorphic dummy argument with an allocatable coarray component

[damian at rouson dot net]

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



--- Comment #2 from Damian Rouson  2013-01-25 
21:32:40 UTC ---

Hi Janus,



I've added Karla Morris to the cc list for this bug.  She discovered it

independently so I guess this one is now stumbling block for two projects.  Any

thoughts about a fix?



Damian

[Bug libstdc++/37522] [4.4 regression] Incorrect vswprintf prototype breaks __to_xstring

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 CC||jason at gcc dot gnu.org



--- Comment #14 from Jason Merrill  2013-01-25 
21:36:48 UTC ---

(In reply to comment #11)

> Don't open an new bug, don't reopen this bug.  I assume you are using

> none-trunk version of mingw-w64, are you?  If so, please switch to

> trunk-version.



When exactly was this fixed on the trunk?  The mingw32-headers package on

Fedora 17 (2.0.999-0.8.trunk.20121016) still has this issue.



(In reply to comment #13)

> No, it isn't.  It is v2.x branch as written even in file-name.  But please 
> stop

> using gcc-bugreports to get answered your user-questions.  Use mingw-w64's

> mailing-list instead.



Often GCC works around problems with older versions of other tools; it seems

reasonable to me to do the same in this case, especially since there isn't yet

a release with this issue fixed.

[Bug other/56076] [4.8 regression] Several 64-bit libgo tests FAIL in read_line_header

[ian at gcc dot gnu.org]

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



--- Comment #2 from ian at gcc dot gnu.org  2013-01-25 
22:36:16 UTC ---

Author: ian

Date: Fri Jan 25 22:36:11 2013

New Revision: 195478



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

Log:

PR other/56076

* dwarf.c (read_line_header): Don't crash if DW_AT_comp_dir

attribute was not seen.



Modified:

trunk/libbacktrace/ChangeLog

trunk/libbacktrace/dwarf.c

[Bug middle-end/56098] [4.6/4.7 Regression] conditional write through volatile pointer produces unintended read

[werner at almesberger dot net]

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



--- Comment #6 from werner at almesberger dot net 2013-01-25 22:46:17 UTC ---

Thanks for the analysis and the fixes ! I'll try them soonish.



Regarding work-arounds, the ones I mentioned for my original code snippet

(i.e., -O1 or -fno-strict-aliasing) aren't sufficient in the following more

general case:



volatile void *p;



#define P  (*(volatile int *) (p+8))





void foo(int x)

{

P = 1;

if (x)

P = 2;

}



This is for gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2 on x86-64. The offset (8)

may be architecture-specific. For values < 8, correct code is generated with

-O1 (but not -O2 or higher).



The good news is that -fno-tree-cselim does indeed avoid the bad read in all

cases I've tried, with any optimization level.

[Bug target/56114] New: x86_64-linux-gnu-gcc generate wrong asm instruction MOVABS for intel syntax

[akobets at mail dot ru]

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



 Bug #: 56114

   Summary: x86_64-linux-gnu-gcc generate wrong asm instruction

MOVABS for intel syntax

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

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

ReportedBy: akob...@mail.ru





For example file l.c



long foo2 (void)

{

  return *(volatile long*)0xFEE0;

}



x86_64-linux-gnu-gcc -c -save-temps l.c -O2 -masm=intel

cat l.s

.file"l.c"

.intel_syntax noprefix

.text

.p2align 4,,15

.globlfoo2

.typefoo2, @function

foo2:

.LFB0:

.cfi_startproc

movabsrax, 4276092928

ret



This is erroneous instruction, because movabs rax, 4276092928 loads immediate

data. This code must be

movabsrax, [4276092928]

with square brackets.



When we try to read 32-bit data from memory, then we get error message

long foo2 (void)

{

  return *(volatile int*)0xFEE0;

}

x86_64-linux-gnu-gcc -c -save-temps l.c -O2 -masm=intel

cat l.s

.file"l.c"

.intel_syntax noprefix

.text

.p2align 4,,15

.globlfoo2

.typefoo2, @function

foo2:

.LFB0:

.cfi_startproc

movabseax, 4276092928

cdqe

ret



Because movabs allows load 64-bit only immediate data. Here is GCC loose square

brackets.

[Bug fortran/56079] [4.7/4.8 Regression] ICE with C_PTR renaming and TRANSFER

[tkoenig at gcc dot gnu.org]

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



--- Comment #3 from Thomas Koenig  2013-01-25 
22:56:43 UTC ---

This also fails in the same place (without renaming):



program gar_nichts

   use ISO_C_BINDING, only :: C_PTR, C_NULL_PTR

   type(c_ptr) nada

   call foo(transfer(C_NULL_PTR,nada))

end program gar_nichts

[Bug target/56114] x86_64-linux-gnu-gcc generate wrong asm instruction MOVABS for intel syntax

[akobets at mail dot ru]

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



Alexander Kobets  changed:



   What|Removed |Added



 CC||akobets at mail dot ru



--- Comment #1 from Alexander Kobets  2013-01-25 
23:06:39 UTC ---

For *(volatile int*)0xFEE0



x86_64-linux-gnu-gcc -c -save-temps l.c -O2 -masm=intel

l.s: Assembler messages:

l.s:10: Error: operand type mismatch for `movabs'



Alse tried

gcc version 4.7.3 20130119 (prerelease) (GCC)

with same result.

[Bug fortran/56079] [4.7/4.8 Regression] ICE with C_PTR renaming and TRANSFER

[tkoenig at gcc dot gnu.org]

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



--- Comment #4 from Thomas Koenig  2013-01-25 
23:10:28 UTC ---

(In reply to comment #3)



Sorry, an error in the test case.  This has the same error:



program gar_nichts

   use ISO_C_BINDING

   type(c_ptr) nada

   call foo(transfer(C_NULL_PTR,nada))

!   call foo(transfer(0_8, nada))

end program gar_nichts



The test case works if the constant 0_8 is used instead.

[Bug other/56076] [4.8 regression] Several 64-bit libgo tests FAIL in read_line_header

[ian at airs dot com]

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



Ian Lance Taylor  changed:



   What|Removed |Added



 CC||ian at airs dot com



--- Comment #3 from Ian Lance Taylor  2013-01-25 23:13:56 
UTC ---

With any luck Jakub's patch will fix the crash in libbacktrace.  But

libbacktrace is crashing trying to dump a stack trace from the real problem,

which is the assertion error in runtime_lfstackpush.



The current code is taking advantage of an x86_64 characteristic: all addresses

only use the low 48 bits.  On SPARC64 this is not true.  The code in lfstack.c

will have to change accordingly.

[Bug other/56076] [4.8 regression] Several 64-bit libgo tests FAIL in read_line_header

[ian at gcc dot gnu.org]

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



--- Comment #4 from ian at gcc dot gnu.org  2013-01-25 
23:43:27 UTC ---

Author: ian

Date: Fri Jan 25 23:43:23 2013

New Revision: 195479



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

Log:

PR other/56076

runtime: Support sparc64 in lfstack.



Modified:

trunk/libgo/runtime/lfstack.c

[Bug other/56076] [4.8 regression] Several 64-bit libgo tests FAIL in read_line_header

[ian at airs dot com]

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



Ian Lance Taylor  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #5 from Ian Lance Taylor  2013-01-25 23:43:57 
UTC ---

May be fixed now.  Not sure.

[Bug middle-end/56108] Asm statement in transaction_relaxed crashes compiler.

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

Version|trans-mem   |4.8.0

   Keywords||trans-mem

   Last reconfirmed||2013-01-25

  Component|c   |middle-end

 Ever Confirmed|0   |1



--- Comment #1 from Andrew Pinski  2013-01-25 
23:45:48 UTC ---

Confirmed.

[Bug libstdc++/37522] [4.4 regression] Incorrect vswprintf prototype breaks __to_xstring

[ktietz at gcc dot gnu.org]

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



--- Comment #15 from Kai Tietz  2013-01-25 23:53:37 
UTC ---

Issue was fixed on trunk.  As far as I know should rawhide Fedora have fixed

that issue already.  Nevertheless we could define the broken-vsprintf macro

based on header-version.

I will come up with a patch for that.

[Bug middle-end/56098] [4.6/4.7 Regression] conditional write through volatile pointer produces unintended read

[werner at almesberger dot net]

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



--- Comment #7 from werner at almesberger dot net 2013-01-26 02:09:33 UTC ---

I'm happy to confirm that trunk (for x86-64) now passes all variations of this

theme I tried with flying colors. Thanks again !

[Bug c/56115] New: Internal compiler error / unable to generate a relocatable output with object file(which is with lto info).

[tanjinfa at huawei dot com]

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



 Bug #: 56115

   Summary: Internal compiler error / unable to generate a

relocatable output with object file(which is with lto

info).

Classification: Unclassified

   Product: gcc

   Version: 4.7.1

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

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

ReportedBy: tanji...@huawei.com





I was testing this test case ./gcc.c-torture/execute/vshuf-v8qi.c individually.

The host_triplet is i586-suse-linux,build_triplet is i586-suse-linux,and

target_triplet arm-eabi.

Then  I got a compiler crash.

I cooked it down to the example below:



>armeb-linux-gnueabi-gcc crash.c -c  -flto -O2  -o crash.out

>arm-eabi-gcc -r -nostdlib -flto crash.out -o a.out



In file included from crash.c:8:0,

 from :0:

crash.c: In function 'main':

crash.c:12:7: internal compiler error: in expand_expr_real_2, at expr.c:8808

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

lto-wrapper: ./new/install/bin/armeb-linux-gnueabi-gcc returned 1 exit status

/home/tjf/SVN/new/install/bin/../lib/gcc/armeb-linux-gnueabi/4.7.1/../../../../armeb-linux-gnueabi/bin/ld:

lto-wrapper failed

collect2: error: ld returned 1 exit status



---crash.c--

typedef char V __attribute__((vector_size(8)));

struct S

{

  V in;

  V mask;

  V out;

};

struct S sss={{ 0, 1, 2, 3, 4, 5, 6, 7 },{ 8, 9, 10, 11, 12, 13, 14, 15 },{ 0,

1, 2, 3, 4, 5, 6, 7 }};

extern void abort(void);

int main()

{

V r = __builtin_shuffle(sss.in,sss.mask);

__builtin_memcmp(&r,&sss.out, sizeof(V));

abort();

  return 0;

}

[Bug c/56115] Internal compiler error / unable to generate a relocatable output with object file(which is with lto info).

[tanjinfa at huawei dot com]

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



--- Comment #1 from William  2013-01-26 02:41:14 
UTC ---

oops!I make a mistake,actually I test the crash.c like this:

>armeb-linux-gnueabi-gcc crash.c -c  -flto -O2  -o crash.out

>armeb-linux-gnueabi-gcc -r -nostdlib -flto crash.out -o a.out

[Bug lto/56115] Internal compiler error / unable to generate a relocatable output with object file(which is with lto info).

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



   Keywords||ice-on-valid-code

  Component|c   |lto



--- Comment #2 from Andrew Pinski  2013-01-26 
02:46:11 UTC ---

The bug is related to -O2 -flto and then -O0 -flto.

[Bug go/53679] Build failure in libgo

[vapier at gentoo dot org]

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



--- Comment #6 from Mike Frysinger  2013-01-26 
03:20:51 UTC ---

Ian has pushed the patch to trunk:

http://gcc.gnu.org/viewcvs?view=revision&revision=195482

[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



  Attachment #28065|0   |1

is obsolete||

 Status|REOPENED|ASSIGNED

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

   |gnu.org |



--- Comment #20 from Jason Merrill  2013-01-26 
05:38:54 UTC ---

Created attachment 29277

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

proposed patch



This patch fixes the bug by setting DECL_VISIBILITY_SPECIFIED on the

constructor vtable.  Interestingly, can_refer_decl_in_current_unit_p only

checks for that in deciding whether or not it's safe to refer to an external

decl, not what the specified visibility is; as a result, this issue wasn't

showing up on linux-gnu because the standard library has an explicit

visibility("default").  On targets that don't use attribute visibility, this

was having trouble because the symbol had unspecified visibility at compile

time but then was made hidden by the linker script.  Is there something better

we can do about symbols that may or may not end up hidden at link time?



I think this change to make the constructor vtables hidden is safe because the

optimizer change that caused us to refer to them inappropriately is new in 4.8,

so we don't have to worry about ABI issues with earlier releases.



Any thoughts?