[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives

[amodra at gmail dot com]

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



Alan Modra  changed:



   What|Removed |Added



 CC||amodra at gmail dot com



--- Comment #36 from Alan Modra  2013-01-31 07:42:52 
UTC ---

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

[Bug libgomp/56159] config/linux/ptrlock.c lacks acquire barrier

[amodra at gmail dot com]

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



Alan Modra  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #2 from Alan Modra  2013-01-31 07:42:52 
UTC ---

Yes, this is a dup



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

[Bug libgomp/56159] config/linux/ptrlock.c lacks acquire barrier

[Joost.VandeVondele at mat dot ethz.ch]

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



Joost VandeVondele  changed:



   What|Removed |Added



 CC||Joost.VandeVondele at mat

   ||dot ethz.ch



--- Comment #1 from Joost VandeVondele  
2013-01-31 07:28:53 UTC ---

I'm wondering if this is partially discussed in



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561#c32



The PR also discusses how to build libgomp with -fsanitize=thread, which

appears a really good way to help debug threading issues.

[Bug c++/54601] AIX uses atexit which causes unloading of shared modules to break

[dje at gcc dot gnu.org]

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



David Edelsohn  changed:



   What|Removed |Added



  Attachment #29311|0   |1

is obsolete||



--- Comment #11 from David Edelsohn  2013-01-31 
06:11:31 UTC ---

Created attachment 29312

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

__cxa_atexit with new crt file



I think it needs something like this new patch, which adds crtdso.o providing

__dso_handle.  collect2 searches the file properly and finds the destructor.

But I am not sure if the driver will find the file and if the file is installed

correctly yet.

[Bug c++/54601] AIX uses atexit which causes unloading of shared modules to break

[pedzsan at gmail dot com]

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



--- Comment #10 from Perry Smith  2013-01-31 05:50:00 
UTC ---

Can you keep the libraries like you have them with the functions and private

structures for the functions coming from the library but just put the

definition of __dso_handle in crt?

[Bug c++/54601] AIX uses atexit which causes unloading of shared modules to break

[dje at gcc dot gnu.org]

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



--- Comment #9 from David Edelsohn  2013-01-31 04:52:51 
UTC ---

This is going to be more difficult because __dso_handle needs to be provided by

a new crt file supplied by GCC, not by the libraries. That is the way that

every module ends up with a unique value. Otherwise the single __dso_handle is

shared across the entire process.

[Bug libgomp/56159] New: config/linux/ptrlock.c lacks acquire barrier

[amodra at gmail dot com]

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



 Bug #: 56159

   Summary: config/linux/ptrlock.c lacks acquire barrier

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libgomp

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

ReportedBy: amo...@gmail.com

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





Spotted while looking for another bug: gomp_ptrlock_get_slow lacks an acquire

barrier (and do_wait doesn't always provide one).  Thus it's possible to exit

from gomp_ptrlock_get without proper synchronization.  The (unnecessary)

MEMMODEL_ACQUIRE on failing __atomic_compare_exchange_n in gomp_ptrlock_get is

too early.

[Bug c++/54122] [4.7/4.8 Regression] segfault comparing enum class in lambda inside constructor of a templated class

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC||jason at gcc dot gnu.org

   Target Milestone|--- |4.7.3

[Bug c++/54122] [4.7/4.8 Regression] segfault comparing enum class in lambda inside constructor of a templated class

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-30

 Blocks||54367

Summary|gcc segfault comparing enum |[4.7/4.8 Regression]

   |class in lambda inside  |segfault comparing enum

   |constructor of a templated  |class in lambda inside

   |class   |constructor of a templated

   ||class

 Ever Confirmed|0   |1



--- Comment #3 from Paolo Carlini  2013-01-30 
23:57:36 UTC ---

Yes, this is a regression.  Let's add Jason in CC.

[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin

[howarth at nitro dot med.uc.edu]

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



--- Comment #22 from Jack Howarth  2013-01-30 
23:40:56 UTC ---

(In reply to comment #21)



The proposed patch reduces the number of  unexpected failures in the g++

testsuite when using...



make -k check-g++ RUNTESTFLAGS="--target_board=unix'{-fsanitize=address}'"



on x86_64-apple-darwin12 from 323 to only 149 failures. Nice.

[Bug libstdc++/56158] New: bad enum values computed by operator~ in ios_base.h

[richard-gccbugzilla at metafoo dot co.uk]

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



 Bug #: 56158

   Summary: bad enum values computed by operator~ in ios_base.h

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libstdc++

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

ReportedBy: richard-gccbugzi...@metafoo.co.uk





The overloaded operator~s defined for the enumerations in ios_base.h have the

following form:



  Enum operator~(Enum e) { return Enum(~static_cast(e)); }



The ~ creates values outside the range of values of the enumeration type, so

the cast back to the Enum type has an unspecified value (see

[expr.static.cast]p10), and in practice it produces an Enum value outside the

range of representable values for the Enum type, so behavior is undefined.



Fix:



--- include/bits/ios_base.h

+++ include/bits/ios_base.h

@@ -87,7 +87,7 @@



   inline _GLIBCXX_CONSTEXPR _Ios_Fmtflags

   operator~(_Ios_Fmtflags __a)

-  { return _Ios_Fmtflags(~static_cast(__a)); }

+  { return _Ios_Fmtflags(static_cast(__a) ^

static_cast(_S_ios_fmtflags_end - 1)); }



   inline const _Ios_Fmtflags&

   operator|=(_Ios_Fmtflags& __a, _Ios_Fmtflags __b)

@@ -127,7 +127,7 @@



   inline _GLIBCXX_CONSTEXPR _Ios_Openmode

   operator~(_Ios_Openmode __a)

-  { return _Ios_Openmode(~static_cast(__a)); }

+  { return _Ios_Openmode(static_cast(__a) ^

static_cast(_S_ios_openmode_end - 1)); }



   inline const _Ios_Openmode&

   operator|=(_Ios_Openmode& __a, _Ios_Openmode __b)

@@ -165,7 +165,7 @@



   inline _GLIBCXX_CONSTEXPR _Ios_Iostate

   operator~(_Ios_Iostate __a)

-  { return _Ios_Iostate(~static_cast(__a)); }

+  { return _Ios_Iostate(static_cast(__a) ^

static_cast(_S_ios_iostate_end - 1)); }



   inline const _Ios_Iostate&

   operator|=(_Ios_Iostate& __a, _Ios_Iostate __b)

[Bug c/47409] volatile struct member bug

[regehr at cs dot utah.edu]

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



--- Comment #12 from John Regehr  2013-01-30 
23:24:36 UTC ---

(In reply to comment #10)

> As said previously I think that volatile struct members are ill-defined.



As far as the C standard goes, I believe the situation is clear: a volatile

struct member is a volatile-qualified variable and the rules for volatile

variables apply to it.



Clang, for example, turns foo() into a load + store at all optimization levels.

I believe the Intel compiler does as well but I don't have it available right

now.

[Bug bootstrap/53728] [4.6 regression] Bootstrap comparison failure (gcc/varasm.o differs) with CFLAGS="-O2 -march=pentium3"

[ubizjak at gmail dot com]

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



--- Comment #1 from Uros Bizjak  2013-01-30 23:09:05 
UTC ---

Can you try to build from latest 4.6 branch SVN?



The bootstrap works for me with:



CC="gcc -m32" ~/gcc-svn/branches/gcc-4_6-branch/configure

--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --with-arch=i686

--enable-languages=c



and



make -j 8 BOOT_CFLAGS="-O2 -march=pentium3 -pipe" bootstrap-lean



for



gcc version 4.6.4 20130127 (prerelease) [gcc-4_6-branch revision 195496] (GCC)

[Bug target/55146] jumptables with byte entries produce wrong code with -Os/-O2 for SH-1

[olegendo at gcc dot gnu.org]

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



Oleg Endo  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-30

 CC||kkojima at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #3 from Oleg Endo  2013-01-30 22:38:34 
UTC ---

I've checked this issue on rev. 19 (GCC 4.8) and the extu.b insn is emitted

for the test case.



On the 4.7 branch, the error is present.  There the code for the insn

'casesi_worker_1' seems to have a bug:



Index: gcc/config/sh/sh.md

===

--- gcc/config/sh/sh.md(revision 195590)

+++ gcc/config/sh/sh.md(working copy)

@@ -9093,7 +9093,8 @@

 case QImode:

   if (ADDR_DIFF_VEC_FLAGS (diff_vec).offset_unsigned)

 return \"mov.b@(r0,%1),%0\;extu.b%0,%0\";

-  return \"mov.b@(r0,%1),%0\";

+  else

+return \"mov.b@(r0,%1),%0\";

 default:

   gcc_unreachable ();

 }



However, that still doesn't fix the problem.  For some reason 'offset_unsigned'

is always zero and thus the insn doesn't get the chance to output the correct

insn sequence.  The macro 'CASE_VECTOR_SHORTEN_MODE' in sh.h which is supposed

to set the 'offset_unsigned' field to non-zero looks exactly the same on 4.7

and 4.8, so I guess the bug must be somewhere else.

[Bug rtl-optimization/56131] [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux

[mikpe at it dot uu.se]

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



--- Comment #6 from Mikael Pettersson  2013-01-30 
22:20:19 UTC ---

(In reply to comment #5)

> A more structured version of the patch:



After fixing the obvious syntax error



> + If the label is not marked with a bb, assume it's the same bb.  */

> +  */



I tested this on x86_64-linux and sparc64-linux.  On x86_64 there were no test

suite changes, on sparc64 I got



-FAIL: gcc.dg/pr56035.c (internal compiler error)

-FAIL: gcc.dg/pr56035.c (test for excess errors)



which is good, but I also got



+FAIL: g++.old-deja/g++.pt/memtemp52.C -std=c++11 (test for excess errors)



g++.log shows it failed due to an exit 1 from xg++, without diagnostic. 

Re-running that one test manually doesn't fail so I guess it was just a fluke.

[Bug fortran/56149] 64 bit gFortran-C interop hidden character argument length passed as 32 bit value

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #3 from Tobias Burnus  2013-01-30 
22:04:57 UTC ---

> This could be avoided if the format string length where passed as a 64 bit

> integer. [...] It would appear that there is no advantage in passing

> a 32 bit value in this context.



There is a big advantage. It's called backward compatibility. gfortran might

change to 64 bit (on systems with 64bit pointers) - but that will only happen,

when the ABI has to be broken.



This will happen when gfortran has to switch over to a new array descriptor;

that might happen for 4.9 or one release later. See also

http://gcc.gnu.org/wiki/LibgfortranAbiCleanup - third bullet item. [Cf. also PR

47552.]





> At the moment gFortran passes a 32 bit value and allows garbage to remain in

> the HIDWORD so the argument cannot safely be distinguished from a 64 bit

> address.



Is this guaranteed to work? I had the impression that stack variables could

have rather small addresses. Okay, even though should be way larger than 1000

and strings are usually shorter.





> As an aside, I would also suggest that interop programming would be much

> simpler if literal character strings were stored in memory as null-terminated

> strings.



I concur, but it might either cause problems with having character strings,

e.g., in COMMON blocks and other places where the storage size is expected to

match the string size. Or one had to copy the string all the time.



Thus, either C has to handle Fortran's version of strings - or one has to

create a C version of the string by appending the '\0'.



Note that often one does not want to do:

   call c_function( str//C_NULL_CHAR )

but rather:

   call c_function( trim(str)//C_NULL_CHAR )

Namely, one wants to remove the trailing blanks.

[Bug c++/54601] AIX uses atexit which causes unloading of shared modules to break

[dje at gcc dot gnu.org]

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



David Edelsohn  changed:



   What|Removed |Added



  Attachment #29307|0   |1

is obsolete||



--- Comment #8 from David Edelsohn  2013-01-30 21:57:52 
UTC ---

Created attachment 29311

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

Revised __cxa_atexit for libgcc



The revised patch uses LIB2ADDEH to add the functions to libgcc_s.a and

libgcc_eh.a so that only one copy should exist in a process.

[Bug tree-optimization/56157] New: ICE with -ftree-vectorize in in compute_live_loop_exits (4.8 trunk)

[jana at saout dot de]

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

 Bug #: 56157
   Summary: ICE with -ftree-vectorize in in
compute_live_loop_exits (4.8 trunk)
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@saout.de


When compiling mesa-9.0.1 using the latest gcc trunk from SVN, I noticed the
following ICE (seems to have been introduced at least a week ago, worked with
some earlier 4.8.0 versions I haven't pinpointed).

LANG=C gcc -O2 -ftree-vectorize -c lala.c
lala.c: In function ‘fn’:
lala.c:14:6: internal compiler error: in compute_live_loop_exits, at
tree-ssa-loop-manip.c:219
 void fn(unsigned char *dst_row, unsigned dst_stride,
  ^

lala.c:14:6: internal compiler error: Aborted
gcc: internal compiler error: Aborted (program cc1)

(on x86_64, reproducable with and without -m32)

With the following reduced testcase:

--
#include 
#include 

union Pixel {
   uint64_t value;
   struct {
  unsigned short r;
  unsigned short g;
  unsigned short b;
  unsigned short a;
   } chan;
};

void fn(unsigned char *dst_row, unsigned dst_stride,
const unsigned char *src_row, unsigned src_stride,
unsigned width, unsigned height)
{
   unsigned x, y;
   for(y = 0; y < height; y += 1) {
  const unsigned char *src = src_row;
  unsigned char *dst = dst_row;
  for(x = 0; x < width; x += 1) {
 union Pixel pixel;
 pixel.chan.r = (unsigned short)(((unsigned)src[0]) * 0x / 0xff);
 pixel.chan.g = (unsigned short)(((unsigned)src[1]) * 0x / 0xff);
 pixel.chan.b = (unsigned short)(((unsigned)src[2]) * 0x / 0xff);
 pixel.chan.a = (unsigned short)(((unsigned)src[3]) * 0x / 0xff);
 memcpy(dst, &pixel, sizeof pixel);
 src += 4;
 dst += 8;
  }
  dst_row += dst_stride;
  src_row += src_stride/sizeof(*src_row);
   }
}
--

gcc version:

Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-beta20130130/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0-beta20130130/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.8.0_beta20130130/work/gcc-4.8-20130130/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-beta20130130
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-beta20130130/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-beta20130130
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-beta20130130/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-beta20130130/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-beta20130130/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-cloog --disable-isl-version-check
--disable-cloog-version-check --with-cloog-include=/usr/include/cloog
--enable-cloog-backend=isl --enable-lto --enable-nls --without-included-gettext
--with-system-zlib --enable-obsolete --disable-werror --enable-secureplt
--enable-multilib --with-multilib-list=m32,m64
--with-build-config=bootstrap-lto --enable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-beta20130130/python
--enable-checking=release --enable-java-awt=gtk --enable-libstdcxx-time
--enable-languages=c,c++,java,fortran --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo
4.8.0_beta20130130'
Thread model: posix
gcc version 4.8.0-beta20130130 20130130 (experimental) (Gentoo
4.8.0_beta20130130) 

(it says Gentoo because I used the build environment, but it's essentially a
vanilla gcc build which I am regularly throwing the SVN version at and building
the system with)

[Bug target/55939] [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux

[joseph at codesourcery dot com]

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



--- Comment #20 from joseph at codesourcery dot com  2013-01-30 21:11:31 UTC ---

On Tue, 29 Jan 2013, jakub at gcc dot gnu.org wrote:



> Perhaps -fexcess-precision=standard might fix this too (and be less 

> expensive).



Note that -fexcess-precision=standard is not fully implemented for m68k: 

the back-end patterns claiming to carry out SFmode/DFmode operations, that 

actually do XFmode arithmetic, haven't been disabled for 

-fexcess-precision=standard as I did for x86 (along with some related 

fixes for conversions to SFmode/DFmode).  While the disabling of SFmode / 

DFmode operations is just for safety - if the architecture-independent 

parts of GCC are working correctly, it shouldn't matter whether they are 

enabled or not because there will be no arithmetic in those modes in the 

GIMPLE anyway - I don't know if m68k needs similar fixes to conversion 

operations.

[Bug other/19165] (Natural) language independent error / warning classification

[fuscated at gmail dot com]

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



--- Comment #17 from Teodor Petrov  2013-01-30 
20:34:00 UTC ---

(In reply to comment #16)

> 

> If you have some developer power to spare, it may be worthwhile to try to

> tackle this yourself. Otherwise I am afraid this will never be implemented in

> GCC. The patch in comment #10 is very rough and outdated, but the idea is

> simple. Copy diagnostic.c to diagnostic-xml.c and start modifying the output

> functions to emit XML.

Probably, I can spare some time, but I don't have time to spare and be bothered

with all the copyright assignments and other bureaucracy related things.

[Bug c++/56152] explicit template instantiation of protected template function redeclared as public fails

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #1 from Daniel Krügler  
2013-01-30 20:24:06 UTC ---
GCC 4.8.0 trunk behaves similar. I think the situation is currently not clear
by the language. It looks like a manifestation of

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1551

to me. Especially bullet 3 in the P/R looks relevant to me.

[Bug c++/54122] gcc segfault comparing enum class in lambda inside constructor of a templated class

[giel.de.nijs at actian dot com]

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



--- Comment #2 from Giel de Nijs  2013-01-30 
20:05:52 UTC ---

Created attachment 29310

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

Another reproduction



Minimal test case based on actual code that's compiling correctly with both gcc

4.6.3 as well as Visual Studio.







$ /opt/gcc-4.8/bin/g++ -v -save-temps -std=c++11 foo.cpp 

Using built-in specs.

COLLECT_GCC=/opt/gcc-4.8/bin/g++

COLLECT_LTO_WRAPPER=/opt/gcc-4.8/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: ./configure --prefix=/opt/gcc-4.8

Thread model: posix

gcc version 4.8.0 20130127 (experimental) (GCC) 

COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-shared-libgcc'

'-mtune=generic' '-march=x86-64'

 /opt/gcc-4.8/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1plus -E -quiet -v

-D_GNU_SOURCE foo.cpp -mtune=generic -march=x86-64 -std=c++11 -fpch-preprocess

-o foo.ii

ignoring nonexistent directory

"/opt/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include"

#include "..." search starts here:

#include <...> search starts here:



/opt/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0



/opt/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-linux-gnu



/opt/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/backward

 /opt/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include

 /usr/local/include

 /opt/gcc-4.8/include

 /opt/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed

 /usr/include

End of search list.

COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-shared-libgcc'

'-mtune=generic' '-march=x86-64'

 /opt/gcc-4.8/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1plus -fpreprocessed

foo.ii -quiet -dumpbase foo.cpp -mtune=generic -march=x86-64 -auxbase foo

-std=c++11 -version -o foo.s

GNU C++ (GCC) version 4.8.0 20130127 (experimental) (x86_64-unknown-linux-gnu)

compiled by GNU C version 4.8.0 20130127 (experimental), GMP version 5.0.2,

MPFR version 3.1.0, MPC version 0.9

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

GNU C++ (GCC) version 4.8.0 20130127 (experimental) (x86_64-unknown-linux-gnu)

compiled by GNU C version 4.8.0 20130127 (experimental), GMP version 5.0.2,

MPFR version 3.1.0, MPC version 0.9

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

Compiler executable checksum: e8e88d7616898e4a81392bc45bc1dc95

foo.cpp: In lambda function:

foo.cpp:15:12: internal compiler error: Segmentation fault

if(e == enum_0)

^

0xa7db9f crash_signal

../.././gcc/toplev.c:332

0x692c80 lvalue_kind(tree_node const*)

../.././gcc/cp/tree.c:146

0x6932a0 lvalue_kind(tree_node const*)

../.././gcc/cp/tree.c:101

0x693808 lvalue_p(tree_node const*)

../.././gcc/cp/tree.c:267

0x4fd710 standard_conversion

../.././gcc/cp/call.c:1102

0x503cf3 implicit_conversion

../.././gcc/cp/call.c:1694

0x5075d3 build_builtin_candidate

../.././gcc/cp/call.c:2151

0x508b60 add_builtin_candidates

../.././gcc/cp/call.c:2818

0x513e3b build_new_op_1

../.././gcc/cp/call.c:5177

0x514c57 build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,

tree_node*, tree_node**, int)

../.././gcc/cp/call.c:5444

0x626962 build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,

tree_node*, tree_code, tree_node**, int)

../.././gcc/cp/typeck.c:3686

0x606b15 cp_parser_binary_expression

../.././gcc/cp/parser.c:7476

0x606e45 cp_parser_assignment_expression

../.././gcc/cp/parser.c:7584

0x608c42 cp_parser_expression

../.././gcc/cp/parser.c:7735

0x617a32 cp_parser_condition

../.././gcc/cp/parser.c:9410

0x5ff4c2 cp_parser_selection_statement

../.././gcc/cp/parser.c:9187

0x5ff4c2 cp_parser_statement

../.././gcc/cp/parser.c:8756

0x60067e cp_parser_statement_seq_opt

../.././gcc/cp/parser.c:9133

0x601bb5 cp_parser_lambda_body

../.././gcc/cp/parser.c:8647

0x601bb5 cp_parser_lambda_expression

../.././gcc/cp/parser.c:8188

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.

[Bug fortran/56149] 64 bit gFortran-C interop hidden character argument length passed as 32 bit value

[paul.laidler at ntlworld dot com]

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



--- Comment #2 from Paul Laidler  2013-01-30 
19:58:27 UTC ---

Hi



Many thanks for your reply and interest.



The ClearWin+ function winio@ (winio$ in gFortran) emulates the C function

printf that takes a format string then a variable number of arguments

depending on the content of the format. The function can be programmed in C

on the basis that all arguments are passed as 64 bit addresses until you

get to the length of the format string which has a size well below the

minimum possible address value. Any arguments after that will also be

string lengths. The format string cannot be processed to find out what

arguments are supplied until we know its length.



The 32 bit length values are passed correctly by gFortran but occupy 64

bits on  the stack. However, the HIDWORD is not currently set and will

contain whatever is left from its previous use. Nor do we have a null

terminator to calculate the length of the format string directly unless the

programmer supplies one.



Large amounts of code has been written by our users, some of whom are

looking to port to gFortran in the absence of 64 bit FTN95 (the Silverfrost

Fortran compiler). Hence the interest is porting the ClearWin+ library to a

64 bit DLL that is accessible from gFortran code.



Any help or insight that you have would be greatly appreciated.



Paul Laidler





On 30 January 2013 16:22, kargl at gcc dot gnu.org  wrote:



>

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

>

> kargl at gcc dot gnu.org changed:

>

>What|Removed |Added

>

> 

>Priority|P3  |P5

>  CC||kargl at gcc dot gnu.org

>

> --- Comment #1 from kargl at gcc dot gnu.org 2013-01-30 16:22:57 UTC ---

> Do you have a small self-contained example and

> the command lines you use to compile the code?

>

> The hidden string length is a 32-bit integer.

> It will always be a 32-bit integer, so I do

> not see how it can be confused for a 64-bit

> address.

>

> --

> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email

> --- You are receiving this mail because: ---

> You reported the bug.

>

[Bug c++/54122] gcc segfault comparing enum class in lambda inside constructor of a templated class

[giel.de.nijs at actian dot com]

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



--- Comment #1 from Giel de Nijs  2013-01-30 
19:53:35 UTC ---

We hit this bug when trying to compile one of our new projects. I've created a

minimal test case very similar to the one in the report. The bug doesn't hit on

4.6.3 nor on Visual Studio, but gcc 4.7 and 4.8 segfault.

[Bug c/56153] False warning about signed and unsigned type in conditional expression

[d.daniel at propharma dot ch]

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



d.daniel at propharma dot ch changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #4 from d.daniel at propharma dot ch 2013-01-30 19:35:14 UTC ---

I used -W -Wall -Wextra, but actually the warning itself is not false, since in



exp1 ? exp2 : exp3



the conditional expression has a return type that depends on exp3 what exp2

needs to be convertible to. So this warning is generally correct but could be

more precise.

Sorry for the invalid bug report.

[Bug c++/56155] [C++11] enumeration with fixed underlying type - enumerators have wrong type within enumerator-list

[paolo.carlini at oracle dot com]

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



--- Comment #3 from Paolo Carlini  2013-01-30 
19:16:12 UTC ---

I think I thought that Jason's work to completely fix c++/53524 had fixed this

too.

[Bug c/56153] False warning about signed and unsigned type in conditional expression

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  2013-01-30 
19:11:19 UTC ---
I always found the wording of the warning confusing. This is what clang says:

test.c:12:46: warning: operand of ? changes signedness: 'int' to 'unsigned int'
[-Wsign-conversion]
fprintf (stdout, "%d", foo != 0 ? foo->num : -1);
~~~  ^~

And this is what GCC 4.8 says:

/home/manuel/test.c:12:44: warning: signed and unsigned type in conditional
expression [-Wsign-compare]
 fprintf (stdout, "%d", foo != 0 ? foo->num : -1);
^

Note also the different location information.

Note the description of -Wsign-compare:

"Warn when a comparison between signed and unsigned values could produce an
incorrect result when the signed value is converted to unsigned. "

which does not match this warning. It does match the description of
-Wsign-conversion:

"Warn for implicit conversions that may change the sign of an integer value,
like assigning a signed integer expression to an unsigned integer variable."

When using -Wsign-conversion, GCC emits an additional warning:

/home/manuel/test.c:12:1: warning: negative integer implicitly converted to
unsigned type [-Wsign-conversion]
 fprintf (stdout, "%d", foo != 0 ? foo->num : -1);
 ^

(with awful location info).

[Bug c++/56155] [C++11] enumeration with fixed underlying type - enumerators have wrong type within enumerator-list

[paolo.carlini at oracle dot com]

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



--- Comment #2 from Paolo Carlini  2013-01-30 
19:00:29 UTC ---

Weird I thought we fixed this, we should find the relevant old PRs and see why

we are mishandling this specific case.

[Bug rtl-optimization/56144] [4.8 Regression] ICE in get_reload_reg, at lra-constraints.c:421

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #4 from Jakub Jelinek  2013-01-30 
18:38:42 UTC ---

Fixed, thanks.

[Bug other/19165] (Natural) language independent error / warning classification

[manu at gcc dot gnu.org]

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

--- Comment #16 from Manuel López-Ibáñez  2013-01-30 
18:18:35 UTC ---
(In reply to comment #15)
> I'm speaking as one of Code::Blocks' developers:
> If you implement this we'll for sure use it, because we have many complaints
> similar to the one Eclipse's developers have. 

If you have some developer power to spare, it may be worthwhile to try to
tackle this yourself. Otherwise I am afraid this will never be implemented in
GCC. The patch in comment #10 is very rough and outdated, but the idea is
simple. Copy diagnostic.c to diagnostic-xml.c and start modifying the output
functions to emit XML.

> Don't pack the line/column info with the file name, if possible.

This will be trivial to do.

> Also, if it is possible group the notes/instances info with the error/warning
> messages. This way it will allows us to show the information in a better way.

This will be more complicated, because the diagnostics machinery does not have
a concept of multiple messages belonging to the same diagnostic. But I think
this is eventually the way to go (and I think Gabriel, the diagnostics
maintainer, thinks the same) by the way of defining an internal representation
for diagnostics output. (http://gcc.gnu.org/ml/gcc/2012-04/msg00567.html)
Dumping this internal representation in XML format would be easy then.

But designing and implementing this IR does not seem trivial, so you may want
to start with the simple stuff.

[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #45 from Jakub Jelinek  2013-01-30 
18:17:21 UTC ---

Should be fixed now.  Beyond gcc/doc/ documentation and more testcases, I think

http://gcc.gnu.org/wiki/FunctionMultiVersioning and

http://gcc.gnu.org/gcc-4.8/changes.html need updating.

[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work

[jakub at gcc dot gnu.org]

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



--- Comment #22 from Jakub Jelinek  2013-01-30 
18:06:09 UTC ---

Author: jakub

Date: Wed Jan 30 18:05:53 2013

New Revision: 195585



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

Log:

PR sanitizer/55374

* gcc.c (LIBASAN_SPEC): Define just to ADD_STATIC_LIBASAN_LIBS if

LIBASAN_EARLY_SPEC is defined.

(LIBASAN_EARLY_SPEC): Define to empty string if not already defined.

(LINK_COMMAND_SPEC): Add LIBASAN_EARLY_SPEC for -fsanitize=address,

before %o.

* config/gnu-user.h (LIBASAN_EARLY_SPEC): Define.



* g++.dg/asan/large-func-test-1.C: Allow both _Zna[jm] in addition

to _Znw[jm] in the backtrace.  Allow _Zna[jm] to be the first frame

printed in backtrace.

* g++.dg/asan/deep-stack-uaf-1.C: Use malloc instead of operator new

to avoid errors about mismatched allocation vs. deallocation.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/gnu-user.h

trunk/gcc/gcc.c

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/g++.dg/asan/deep-stack-uaf-1.C

trunk/gcc/testsuite/g++.dg/asan/large-func-test-1.C

[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.

[jakub at gcc dot gnu.org]

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



--- Comment #44 from Jakub Jelinek  2013-01-30 
18:04:49 UTC ---

Author: jakub

Date: Wed Jan 30 18:04:34 2013

New Revision: 195584



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

Log:

PR c++/55742

* config/i386/i386.c (ix86_valid_target_attribute_inner_p): Diagnose

invalid args instead of ICEing on it.

(ix86_valid_target_attribute_tree): Return error_mark_node if

ix86_valid_target_attribute_inner_p failed.

(ix86_valid_target_attribute_p): Return false only if

ix86_valid_target_attribute_tree returned error_mark_node.  Allow

target("default") attribute.

(sorted_attr_string): Change argument from const char * to tree,

merge in all target attribute arguments rather than just one.

Formatting fix.  Use XNEWVEC instead of xmalloc and XDELETEVEC

instead of free.  Avoid using strcat.

(ix86_mangle_function_version_assembler_name): Mangle

target("default") as if no target attribute is present.  Adjust

sorted_attr_string caller.  Avoid leaking memory.  Use XNEWVEC

instead of xmalloc and XDELETEVEC instead of free.

(ix86_function_versions): Don't return true if one of the decls

doesn't have target attribute.  If they don't and one of the decls

is DECL_FUNCTION_VERSIONED, report an error.  Adjust

sorted_attr_string caller.  Use XDELETEVEC instead of free.

(ix86_supports_function_versions): Remove.

(make_name): Fix up formatting.

(make_dispatcher_decl): Remove resolver_name and its initialization.

Avoid leaking memory.

(is_function_default_version): Return true if there is

target("default") attribute rather than no target attribute at all.

(make_resolver_func): Avoid leaking memory.

(ix86_generate_version_dispatcher_body): Likewise.

(TARGET_OPTION_SUPPORTS_FUNCTION_VERSIONS): Remove.

* target.def (supports_function_versions): Remove.

* doc/tm.texi.in (SUPPORTS_FUNCTION_VERSIONS): Remove.

* doc/tm.texi: Regenerated.



* c-common.c (handle_target_attribute): Revert 2012-12-26 change.



* g++.dg/mv1.C: Moved to...

* g++.dg/ext/mv1.C: ... here.  Adjust test.

* g++.dg/mv2.C: Moved to...

* g++.dg/ext/mv2.C: ... here.  Adjust test.

* g++.dg/mv3.C: Moved to...

* g++.dg/ext/mv3.C: ... here.

* g++.dg/mv4.C: Moved to...

* g++.dg/ext/mv4.C: ... here.

* g++.dg/mv5.C: Moved to...

* g++.dg/ext/mv5.C: ... here.  Adjust test.

* g++.dg/mv6.C: Moved to...

* g++.dg/ext/mv6.C: ... here.  Adjust test.

* g++.dg/ext/mv7.C: New test.

* g++.dg/ext/mv8.C: New test.

* g++.dg/ext/mv9.C: New test.

* g++.dg/ext/mv10.C: New test.

* g++.dg/ext/mv11.C: New test.



Added:

trunk/gcc/testsuite/g++.dg/ext/mv1.C

  - copied, changed from r195583, trunk/gcc/testsuite/g++.dg/mv1.C

trunk/gcc/testsuite/g++.dg/ext/mv10.C

trunk/gcc/testsuite/g++.dg/ext/mv11.C

trunk/gcc/testsuite/g++.dg/ext/mv2.C

  - copied, changed from r195583, trunk/gcc/testsuite/g++.dg/mv2.C

trunk/gcc/testsuite/g++.dg/ext/mv3.C

  - copied unchanged from r195583, trunk/gcc/testsuite/g++.dg/mv3.C

trunk/gcc/testsuite/g++.dg/ext/mv4.C

  - copied unchanged from r195583, trunk/gcc/testsuite/g++.dg/mv4.C

trunk/gcc/testsuite/g++.dg/ext/mv5.C

  - copied, changed from r195583, trunk/gcc/testsuite/g++.dg/mv5.C

trunk/gcc/testsuite/g++.dg/ext/mv6.C

  - copied, changed from r195583, trunk/gcc/testsuite/g++.dg/mv6.C

trunk/gcc/testsuite/g++.dg/ext/mv7.C

trunk/gcc/testsuite/g++.dg/ext/mv8.C

trunk/gcc/testsuite/g++.dg/ext/mv9.C

Removed:

trunk/gcc/testsuite/g++.dg/mv1.C

trunk/gcc/testsuite/g++.dg/mv2.C

trunk/gcc/testsuite/g++.dg/mv3.C

trunk/gcc/testsuite/g++.dg/mv4.C

trunk/gcc/testsuite/g++.dg/mv5.C

trunk/gcc/testsuite/g++.dg/mv6.C

Modified:

trunk/gcc/ChangeLog

trunk/gcc/c-family/ChangeLog

trunk/gcc/c-family/c-common.c

trunk/gcc/config/i386/i386.c

trunk/gcc/doc/tm.texi

trunk/gcc/doc/tm.texi.in

trunk/gcc/target.def

trunk/gcc/testsuite/ChangeLog

[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158

[mikpe at it dot uu.se]

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



--- Comment #16 from Mikael Pettersson  2013-01-30 
17:50:07 UTC ---

Sorry I quoted the wrong fragment from 175r.fwprop, the correct fragment is:



(insn 288 287 289 41 (set (reg/f:SI 124 [ D.1812 ])

(mem/f:SI (reg:SI 145 [ ivtmp.80 ]) [5 MEM[base: D.1914_291, offset:

0B]+0 S4 A16])) pr43437-2.c:278 37 {*movsi_m68k2}

 (nil))



(insn 289 288 290 41 (set (reg:SI 145 [ ivtmp.80 ])

(plus:SI (reg:SI 145 [ ivtmp.80 ])

(const_int 4 [0x4]))) pr43437-2.c:278 132 {*addsi3_internal}

 (nil))

[Bug fortran/56156] Reject calls to external procedures using non-module declared TYPEs

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



Summary|Reject INTERFACE blocks in  |Reject calls to external

   |procedures which import |procedures using non-module

   |local nonseq. TYPE decls|declared TYPEs



--- Comment #2 from Tobias Burnus  2013-01-30 
17:39:37 UTC ---

Actually, the INTERFACE might be even valid. (Cf. discussion at c.l.f)



A simpler approach would be to just reject



  call s()andcall bar(s)



where "s" is declared via an INTERFACE, is not a procedure pointer nor a dummy

argument and uses as result value or dummy argument an extensible derived type

which is not declared in the specification part of a module.





Additionally, besides INTERFACE, also implicit typing can lead to invalid code,

if one implicitly types the function result. (It probably requires an internal

procedure where the type is declared in the enclosing procedure.)

[Bug c++/56155] [C++0X] enumeration with fixed underlying type - enumerators have wrong type within enumerator-list

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-30

Summary|[C++0X] enumeration with|[C++0X] enumeration with

   |fixed underlying type - |fixed underlying type -

   |enum literals have wrong|enumerators have wrong type

   |type|within enumerator-list

 Ever Confirmed|0   |1



--- Comment #1 from Jonathan Wakely  2013-01-30 
17:35:21 UTC ---

The type of the enumerator is only wrong within the enumerator-list, once the

enumeration declaration is complete sizeof(Z_) is 1 as expected.

[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158

[mikpe at it dot uu.se]

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



--- Comment #15 from Mikael Pettersson  2013-01-30 
17:34:11 UTC ---

(In reply to comment #1)

> The bug, duplicated by compiling attachment 26150 [details], from bug 43437 
> comment 16,

> with a cross-compiler to m68k-elf with -O -c, exposes a reload problem.  
> Before

> reload, we have this insn:

> 

> (insn 288 287 290 40 (set (reg/f:SI 124 [ D.1788 ])

> (mem/f:SI (post_inc:SI (reg:SI 145 [ ivtmp.76 ])) [5 MEM[base:

> D.1889_285, offset: 0B]+0 S4 A16])) pr52306.c:278 37 {*movsi_m68k2}

>  (expr_list:REG_INC (reg:SI 145 [ ivtmp.76 ])

> (nil)))



But isn't this already invalid, as it has both a post_inc and a REG_INC of the

same (reg:SI 145 [ ivtmp.76 ]) operand?



This is produced by the auto_inc_dec pass.  Before that we have (175r.fwprop2):



(insn 188 187 190 22 (set (reg/v:SI 76 [ i ])

(plus:SI (reg/v:SI 76 [ i ])

(const_int 1 [0x1]))) pr43437-2.c:222 132 {*addsi3_internal}

 (nil))



(insn 190 188 191 22 (set (cc0)

(compare (reg/v:SI 76 [ i ])

(reg/v:SI 68 [ n ]))) pr43437-2.c:222 14 {*m68k.md:486}

 (nil))



which auto_inc_dec turns into (176r.auto_inc_dec):



  289 r145:SI=r145:SI+0x4

  288 r124:SI=[r145:SI]

  288 r124:SI=[r145:SI]

found mem(288) *(r[145]+0)

  289 r145:SI=r145:SI+0x4

found post inc(289) r[145]+=4

trying SIMPLE_POST_INC

rescanning insn with uid = 288.

deleting insn with uid = 288.

deleting insn with uid = 289.

success   288 r124:SI=[r145:SI++]

  REG_INC: r145:SI

...

  288 r124:SI=[r145:SI++]

  REG_INC: r145:SI

...

(insn 288 287 290 41 (set (reg/f:SI 124 [ D.1812 ])

(mem/f:SI (post_inc:SI (reg:SI 145 [ ivtmp.80 ])) [5 MEM[base:

D.1914_291, offset: 0B]+0 S4 A16])) pr43437-2.c:278 37 {*movsi_m68k2}

 (expr_list:REG_INC (reg:SI 145 [ ivtmp.80 ])

(nil)))



Is this valid?

[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin

[glider at google dot com]

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



--- Comment #21 from Alexander Potapenko  2013-01-30 
17:30:18 UTC ---

Created attachment 29309

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

Dummy patch that reverses the order of the constructors



Attached is a hacky POC patch that intends to just reverse the order of

constructors in the module. It fixes the current problem with ASan ctor being

the last one (it is the first one now), yet it doesn't fix the missing support

for priorities.

It also contains a fixed-size array of ctors, which needs to be replaced with

some dynamic structure. I also have no idea what rtx is and whether it remains

allocated throughout the compilation or we're just using dangling pointers.

[Bug c/56153] False warning about signed and unsigned type in conditional expression

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #2 from Jakub Jelinek  2013-01-30 
17:24:59 UTC ---

1 is signed too, but has the same value when converted to unsigned, while that

is not the case for -1.  Use -1U if you want to avoid the warning.

[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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-01-30

 CC||aoliva at gcc dot gnu.org

   Target Milestone|--- |4.7.3

 Ever Confirmed|0   |1

[Bug rtl-optimization/56144] [4.8 Regression] ICE in get_reload_reg, at lra-constraints.c:421

[vmakarov at gcc dot gnu.org]

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



--- Comment #3 from Vladimir Makarov  2013-01-30 
17:20:47 UTC ---

Author: vmakarov

Date: Wed Jan 30 17:20:39 2013

New Revision: 195582



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

Log:

2013-01-30  Vladimir Makarov  



PR rtl-optimization/56144

* lra-constraints.c (get_reload_reg): Don't reuse reload pseudo

for values with side effects.



2013-01-30  Vladimir Makarov  



PR rtl-optimization/56144

* gcc.dg/pr56144.c: New.





Added:

trunk/gcc/testsuite/gcc.dg/pr56144.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/lra-constraints.c

trunk/gcc/testsuite/ChangeLog

[Bug lto/56061] [4.8 Regression] ICE in lto1 (in inline_call, at ipa-inline-transform.c:267)

[hubicka at ucw dot cz]

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



--- Comment #8 from Jan Hubicka  2013-01-30 17:16:25 UTC 
---

> They are useful.  It should be technically possible to support -O1 vs. -O0,

> and if not, we have means to forcefully enable -O1 at link-time (which we

> should do then).

I personally lean towards making all early passes -O level agnostic and

prohibit

mixing of LTO -O0 and optimized objects..

I do not see much of other options for making LTO .o files ready for

distribution

in libraries in longer run.



Honza

[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 #1 from Jakub Jelinek  2013-01-30 
17:16:08 UTC ---

Created attachment 29308

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

gcc48-pr56154.patch



Untested fix, together with guality testcases that show the issue.  On x86_64,

without the dwarf2out.c change I see with:

make check-gcc \

RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} guality.exp=pr56154*.c'

Running target unix/-m32

Using /usr/share/dejagnu/baseboards/unix.exp as board description file for

target.

Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.

Using /usr/src/gcc/gcc/testsuite/config/default.exp as tool-and-target-specific

interface file.

Running /usr/src/gcc/gcc/testsuite/gcc.dg/guality/guality.exp ...

FAIL: gcc.dg/guality/pr56154-2.c  -O1  line pr56154-2.c:30 x == 28

FAIL: gcc.dg/guality/pr56154-2.c  -O2  line pr56154-2.c:30 x == 28

FAIL: gcc.dg/guality/pr56154-2.c  -O3 -fomit-frame-pointer  line pr56154-2.c:30

x == 28

FAIL: gcc.dg/guality/pr56154-2.c  -O3 -g  line pr56154-2.c:30 x == 28

FAIL: gcc.dg/guality/pr56154-3.c  -O1  line pr56154-3.c:22 x == 28

FAIL: gcc.dg/guality/pr56154-3.c  -O2  line pr56154-3.c:22 x == 28

FAIL: gcc.dg/guality/pr56154-3.c  -O3 -fomit-frame-pointer  line pr56154-3.c:22

x == 28

FAIL: gcc.dg/guality/pr56154-3.c  -O3 -g  line pr56154-3.c:22 x == 28



Running target unix/-m64

Using /usr/share/dejagnu/baseboards/unix.exp as board description file for

target.

Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.

Using /usr/src/gcc/gcc/testsuite/config/default.exp as tool-and-target-specific

interface file.

Running /usr/src/gcc/gcc/testsuite/gcc.dg/guality/guality.exp ...

FAIL: gcc.dg/guality/pr56154-1.c  -O1  line pr56154-1.c:17 x.a == 4

FAIL: gcc.dg/guality/pr56154-1.c  -O1  line pr56154-1.c:20 x.a == 6

FAIL: gcc.dg/guality/pr56154-1.c  -O2  line pr56154-1.c:17 x.a == 4

FAIL: gcc.dg/guality/pr56154-1.c  -O2  line pr56154-1.c:20 x.a == 6

FAIL: gcc.dg/guality/pr56154-1.c  -O3 -fomit-frame-pointer  line pr56154-1.c:17

x.a == 4

FAIL: gcc.dg/guality/pr56154-1.c  -O3 -fomit-frame-pointer  line pr56154-1.c:20

x.a == 6

FAIL: gcc.dg/guality/pr56154-1.c  -O3 -g  line pr56154-1.c:17 x.a == 4

FAIL: gcc.dg/guality/pr56154-1.c  -O3 -g  line pr56154-1.c:20 x.a == 6

FAIL: gcc.dg/guality/pr56154-1.c  -Os  line pr56154-1.c:17 x.a == 4

FAIL: gcc.dg/guality/pr56154-1.c  -Os  line pr56154-1.c:20 x.a == 6

FAIL: gcc.dg/guality/pr56154-2.c  -O1  line pr56154-2.c:30 x == 28

FAIL: gcc.dg/guality/pr56154-2.c  -O2  line pr56154-2.c:30 x == 28

FAIL: gcc.dg/guality/pr56154-2.c  -O3 -fomit-frame-pointer  line pr56154-2.c:30

x == 28

FAIL: gcc.dg/guality/pr56154-2.c  -O3 -g  line pr56154-2.c:30 x == 28

FAIL: gcc.dg/guality/pr56154-2.c  -Os  line pr56154-2.c:30 x == 28

FAIL: gcc.dg/guality/pr56154-3.c  -O1  line pr56154-3.c:22 x == 28

FAIL: gcc.dg/guality/pr56154-3.c  -O2  line pr56154-3.c:22 x == 28

FAIL: gcc.dg/guality/pr56154-3.c  -O3 -fomit-frame-pointer  line pr56154-3.c:22

x == 28

FAIL: gcc.dg/guality/pr56154-3.c  -O3 -g  line pr56154-3.c:22 x == 28

FAIL: gcc.dg/guality/pr56154-3.c  -Os  line pr56154-3.c:22 x == 28



while with it everything passes.

[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin

[glider at google dot com]

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



--- Comment #20 from Alexander Potapenko  2013-01-30 
17:07:25 UTC ---

(In reply to comment #19)

> Well, if somebody does the work and in a clean way that won't penalize targets

> with sane linkers and object formats, I'm not objecting, I just am not going 
> to

> spend time on this.  If clang can handle ctor priorities right at least inside

> of each individual CUs, perhaps those that care about targets which don't

> support that in the linker can add similar support to gcc (what I've been

> suggesting, if priorities aren't supported by linker, don't emit stuff right

> away, but just queue it and at the end sort it and emit.



Looks like you're right and the constructors are just being emitted by

machopic_asm_out_constructor() in gcc/config/darwin.c, so ASan just has no

chance to add his ctor before the default one.



I suppose this can be fixed in gcc/config/darwin.c, but we don't have enough

knowledge and/or cycles for this. Perhaps the right thing to do is to file a

bug against the owner of that file.

[Bug target/39064] libiberty md5.h needs uintptr_t

[ktietz at gcc dot gnu.org]

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



Kai Tietz  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #8 from Kai Tietz  2013-01-30 17:00:12 
UTC ---

Fixed

[Bug c++/54601] AIX uses atexit which causes unloading of shared modules to break

[dje at gcc dot gnu.org]

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



--- Comment #7 from David Edelsohn  2013-01-30 16:59:13 
UTC ---

Created attachment 29307

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

cxa_atexit implementation in libgcc



This version of the patch implements __cxa_atexit and __cxa_finalize in libgcc,

not libsupc++, with no modifications to collect2.  I am not sure if using a low

priority C destructor to run __cxa_finalize early in the destructor list is

correct. The original collect2 patch ran it last, after other destructors,

which I believe is incorrect and does not match crtstuff.c semantics for ELF. 

When I configured GCC with the patch and --enable__cxa-atexit, I saw a few

additional C++ errors in the testsuite.

[Bug target/39064] libiberty md5.h needs uintptr_t

[ktietz at gcc dot gnu.org]

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



--- Comment #7 from Kai Tietz  2013-01-30 16:58:22 
UTC ---

Author: ktietz

Date: Wed Jan 30 16:58:10 2013

New Revision: 195581



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

Log:

PR other/54620

PR target/39064

* md5.h (md5_uintptr, md5_uint32): Define as uintptr_t/uint32_t if

stdint.h and sys/types.h headers are present.

* sha1.h (sha1_uintptr, sha1_uint32): Likewise.





Modified:

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

branches/gcc-4_6-branch/include/md5.h

branches/gcc-4_6-branch/include/sha1.h

[Bug other/54620] sha1.c has incorrect math if sizeof(size_t) is 8

[ktietz at gcc dot gnu.org]

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



--- Comment #4 from Kai Tietz  2013-01-30 16:58:24 
UTC ---

Author: ktietz

Date: Wed Jan 30 16:58:10 2013

New Revision: 195581



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

Log:

PR other/54620

PR target/39064

* md5.h (md5_uintptr, md5_uint32): Define as uintptr_t/uint32_t if

stdint.h and sys/types.h headers are present.

* sha1.h (sha1_uintptr, sha1_uint32): Likewise.





Modified:

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

branches/gcc-4_6-branch/include/md5.h

branches/gcc-4_6-branch/include/sha1.h

[Bug target/39064] libiberty md5.h needs uintptr_t

[ktietz at gcc dot gnu.org]

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



--- Comment #6 from Kai Tietz  2013-01-30 16:56:50 
UTC ---

Author: ktietz

Date: Wed Jan 30 16:56:36 2013

New Revision: 195580



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

Log:

2013-01-30  Kai Tietz  



PR other/54620

PR target/39064

* md5.h (md5_uintptr, md5_uint32): Define as uintptr_t/uint32_t if

stdint.h and sys/types.h headers are present.

* sha1.h (sha1_uintptr, sha1_uint32): Likewise.





Modified:

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

branches/gcc-4_7-branch/include/md5.h

branches/gcc-4_7-branch/include/sha1.h

[Bug other/54620] sha1.c has incorrect math if sizeof(size_t) is 8

[ktietz at gcc dot gnu.org]

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



--- Comment #3 from Kai Tietz  2013-01-30 16:56:50 
UTC ---

Author: ktietz

Date: Wed Jan 30 16:56:36 2013

New Revision: 195580



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

Log:

2013-01-30  Kai Tietz  



PR other/54620

PR target/39064

* md5.h (md5_uintptr, md5_uint32): Define as uintptr_t/uint32_t if

stdint.h and sys/types.h headers are present.

* sha1.h (sha1_uintptr, sha1_uint32): Likewise.





Modified:

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

branches/gcc-4_7-branch/include/md5.h

branches/gcc-4_7-branch/include/sha1.h

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[dje at gcc dot gnu.org]

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



David Edelsohn  changed:



   What|Removed |Added



 CC||pedzsan at gmail dot com



--- Comment #18 from David Edelsohn  2013-01-30 
16:52:41 UTC ---

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

[Bug c/55105] use of LD_LIBRARY_PATH incorrect for AIX -- cause trunk build to fail

[dje at gcc dot gnu.org]

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



David Edelsohn  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||dje at gcc dot gnu.org

 Resolution||DUPLICATE



--- Comment #2 from David Edelsohn  2013-01-30 16:52:41 
UTC ---

Duplicate.



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

[Bug target/39064] libiberty md5.h needs uintptr_t

[ktietz at gcc dot gnu.org]

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



--- Comment #5 from Kai Tietz  2013-01-30 16:51:03 
UTC ---

Author: ktietz

Date: Wed Jan 30 16:50:49 2013

New Revision: 195579



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

Log:

PR other/54620

PR target/39064

* md5.h (md5_uintptr, md5_uint32): Define as uintptr_t/uint32_t if

stdint.h and sys/types.h headers are present.

* sha1.h (sha1_uintptr, sha1_uint32): Likewise.





Modified:

trunk/include/ChangeLog

trunk/include/md5.h

trunk/include/sha1.h

[Bug other/54620] sha1.c has incorrect math if sizeof(size_t) is 8

[ktietz at gcc dot gnu.org]

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



--- Comment #2 from Kai Tietz  2013-01-30 16:51:03 
UTC ---

Author: ktietz

Date: Wed Jan 30 16:50:49 2013

New Revision: 195579



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

Log:

PR other/54620

PR target/39064

* md5.h (md5_uintptr, md5_uint32): Define as uintptr_t/uint32_t if

stdint.h and sys/types.h headers are present.

* sha1.h (sha1_uintptr, sha1_uint32): Likewise.





Modified:

trunk/include/ChangeLog

trunk/include/md5.h

trunk/include/sha1.h

[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin

[jakub at gcc dot gnu.org]

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



--- Comment #19 from Jakub Jelinek  2013-01-30 
16:43:03 UTC ---

Well, if somebody does the work and in a clean way that won't penalize targets

with sane linkers and object formats, I'm not objecting, I just am not going to

spend time on this.  If clang can handle ctor priorities right at least inside

of each individual CUs, perhaps those that care about targets which don't

support that in the linker can add similar support to gcc (what I've been

suggesting, if priorities aren't supported by linker, don't emit stuff right

away, but just queue it and at the end sort it and emit.

[Bug fortran/56156] Reject INTERFACE blocks in procedures which import local nonseq. TYPE decls

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #1 from Tobias Burnus  2013-01-30 
16:41:21 UTC ---

(In reply to comment #0)

> Using an abstract interface is fine as one can use it as procedure pointer



I wanted to write "for proc-pointers". However, it can also be used as

proc-pointer, which should be also valid:



  POINTER :: S

  INTERFACE

SUBROUTINE S(X)

  IMPORT :: T

  TYPE(T) :: X

END SUBROUTINE S

  END INTERFACE

[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin

[kcc at gcc dot gnu.org]

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



--- Comment #18 from Kostya Serebryany  2013-01-30 
16:36:01 UTC ---

Yea... We don't have interest in supporting gcc-asan-darwin, sorry.

[Bug rtl-optimization/56144] [4.8 Regression] ICE in get_reload_reg, at lra-constraints.c:421

[vmakarov at gcc dot gnu.org]

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



--- Comment #2 from Vladimir Makarov  2013-01-30 
16:33:20 UTC ---

I am working on it.  The fix will be ready today.

[Bug fortran/56156] New: Reject INTERFACE blocks in procedures which import local nonseq. TYPE decls

[burnus at gcc dot gnu.org]

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



 Bug #: 56156

   Summary: Reject INTERFACE blocks in procedures which import

local nonseq. TYPE decls

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: rejects-valid

  Severity: normal

  Priority: P3

 Component: fortran

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

ReportedBy: bur...@gcc.gnu.org





Cf. https://groups.google.com/forum/#!topic/comp.lang.fortran/q63uc66POm4



The following code is invalid as one is not able to write a conforming

subroutine "S":



PROGRAM MAIN

 TYPE T

   INTEGER :: Y

 END TYPE T

 INTERFACE

   SUBROUTINE S(X)

 IMPORT :: T

 TYPE(T) :: X

   END SUBROUTINE S

 END INTERFACE





Hence, gfortran should reject procedures, declared in an INTERFACE block

(unless ABSTRACT), if they use a non-BIND(C), non-SEQUENCE TYPE which has been

declared in a procedure.



Using an abstract interface is fine as one can use it as procedure pointer:

  procedure(s), pointer :: p

  p => sub2  ! sub2 is an internal procedure



While sequence types, bind(c) types and types declared in the specification

part of a module are valid for obvious reasons.

[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin

[jakub at gcc dot gnu.org]

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



--- Comment #17 from Jakub Jelinek  2013-01-30 
16:32:11 UTC ---

Solaris doesn't support Asan in gcc, and perhaps it is time to admit that

Darwin doesn't either.

[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin

[howarth at nitro dot med.uc.edu]

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



--- Comment #16 from Jack Howarth  2013-01-30 
16:31:14 UTC ---

This limitation all exists for clang on darwin...



http://llvm.org/bugs/show_bug.cgi?id=12556

[Bug c++/56155] New: [C++0X] enumeration with fixed underlying type - enum literals have wrong type

[mib.bugzilla at gmail dot com]

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

 Bug #: 56155
   Summary: [C++0X] enumeration with fixed underlying type - enum
literals have wrong type
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mib.bugzi...@gmail.com


For an enumeration whose underlying type is fixed, the values of the
enumeration are the values of the underlying type. gcc appears to be ignoring
the underlying type, as the value of E_ in this example is 4

 gpp48 bug1.cpp -std=c++0x
bug1.cpp: In function âint main()â:
bug1.cpp:4:3: error: static assertion failed: E_ should be 1
   static_assert( E_ == 1, "E_ should be 1");
   ^

enum e_ : unsigned char { Z_, E_=sizeof(Z_) };
#include 
int main(void) {
  static_assert( E_ == 1, "E_ should be 1");
  printf("z is %d e is %d\n", Z_, E_ ); // prints 4
  printf("sizeof unsigned char is %d\n", sizeof(unsigned char)); // prints 1
  printf("sizeof e_ is %d\n", sizeof(e_)); // prints 1
  return 0;
}

[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin

[howarth at nitro dot med.uc.edu]

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



--- Comment #15 from Jack Howarth  2013-01-30 
16:28:17 UTC ---

It also seems that Solaris 2 will suffer from this issue when not using Gold...



#ifndef USE_GLD

/* The Solaris linker doesn't understand constructor priorities.  */

#undef SUPPORTS_INIT_PRIORITY

#define SUPPORTS_INIT_PRIORITY 0

#endif

[Bug fortran/56149] 64 bit gFortran-C interop hidden character argument length passed as 32 bit value

[kargl at gcc dot gnu.org]

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



kargl at gcc dot gnu.org changed:



   What|Removed |Added



   Priority|P3  |P5

 CC||kargl at gcc dot gnu.org



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

Do you have a small self-contained example and

the command lines you use to compile the code?



The hidden string length is a 32-bit integer.

It will always be a 32-bit integer, so I do

not see how it can be confused for a 64-bit

address.

[Bug c/56153] False warning about signed and unsigned type in conditional expression

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

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



--- Comment #1 from Andreas Schwab  2013-01-30 16:16:15 
UTC ---

foo->num is unsigned, -1 is signed.

[Bug rtl-optimization/56151] Performance degradation after r194054 on x86 Atom.

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 CC||steven at gcc dot gnu.org

  Component|tree-optimization   |rtl-optimization



--- Comment #2 from Richard Biener  2013-01-30 
16:04:03 UTC ---

Steven, that's



 2012-12-02  Steven Bosscher  



+   * optabs.c (add_equal_note): Do not create self-referencing REG_EQUAL

+   notes.

+   * fwprop.c (forward_propagate_and_simplify): Likewise.

[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin

[howarth at nitro dot med.uc.edu]

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



--- Comment #14 from Jack Howarth  2013-01-30 
15:57:11 UTC ---

(In reply to comment #13)



See in gcc/config/darwin.h...



/* The Apple assembler and linker do not support constructor priorities.  */

#undef SUPPORTS_INIT_PRIORITY

#define SUPPORTS_INIT_PRIORITY 0



and http://trac.macports.org/ticket/37664 discusses this limitation as well.

Can't we just latch onto the SUPPORTS_INIT_PRIORITY being defined to 0  on

darwin to force __asan_init to be emiited (perhaps in the constructor)? If a

single call to __asan_init would suffice shouldn't that work because the

constructor should be called before the destructor in real code?

[Bug tree-optimization/56150] [4.8 Regression] ICE segfault in do_pre / tail_merge_optimize

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-01-30

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

   |gnu.org |

   Target Milestone|--- |4.8.0

Summary|ICE segfault in do_pre /|[4.8 Regression] ICE

   |tail_merge_optimize |segfault in do_pre /

   ||tail_merge_optimize

 Ever Confirmed|0   |1



--- Comment #2 from Richard Biener  2013-01-30 
15:56:27 UTC ---

Confirmed.



1119case GIMPLE_ASSIGN:

1120  lhs1 = gimple_get_lhs (s1);

1121  lhs2 = gimple_get_lhs (s2);

1122  if (gimple_vdef (s1))

1123{

1124  if (vn_valueize (gimple_vdef (s1)) != vn_valueize

(gimple_vdef (s2)))



s2 isn't a store.



Index: gcc/tree-ssa-tail-merge.c

===

--- gcc/tree-ssa-tail-merge.c   (revision 195574)

+++ gcc/tree-ssa-tail-merge.c   (working copy)

@@ -1121,6 +1121,8 @@ gimple_equal_p (same_succ same_succ, gim

   lhs2 = gimple_get_lhs (s2);

   if (gimple_vdef (s1))

{

+ if (!gimple_vdef (s2))

+   return false;

  if (vn_valueize (gimple_vdef (s1)) != vn_valueize (gimple_vdef (s2)))

return false;

  if (TREE_CODE (lhs1) != SSA_NAME



fixes it.

[Bug debug/56154] New: [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



 Bug #: 56154

   Summary: [4.7/4.8 Regression] Bad .debug_loc generated for some

code

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: debug

AssignedTo: ja...@gcc.gnu.org

ReportedBy: ja...@gcc.gnu.org





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

without inline asm, but with inline asm even before, we can end up with

a .debug_loc location list which for the first function in .text starts with

0, 0 entry.



See https://bugzilla.redhat.com/show_bug.cgi?id=904252 for more details.

[Bug c/56153] New: False warning about signed and unsigned type in conditional expression

[d.daniel at propharma dot ch]

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



 Bug #: 56153

   Summary: False warning about signed and unsigned type in

conditional expression

Classification: Unclassified

   Product: gcc

   Version: 4.6.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

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

ReportedBy: d.dan...@propharma.ch





The following code creates a warning "signed and unsigned type in conditional

expression" but there is no such comparison:



typedef struct {

   unsigned int num;

   const char *str;

} FooBar;



FooBar *foo = (FooBar *)malloc (sizeof (FooBar));

foo->num = 0; 

foo->str = "Hello World";

fprintf (stdout, "%d", foo != 0 ? foo->num : -1);



If instead, the following code gets compiled, no warning is issued:



// .. the same as above

fprintf (stdout, "%d", foo != 0 ? foo->num : 1);

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

[rguenth at gcc dot gnu.org]

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



--- Comment #17 from Richard Biener  2013-01-30 
15:40:57 UTC ---

(In reply to comment #16)

> The following (old!?) idea helps though:

> 

> Index: gcc/tree-ssa-loop-manip.c

> ===

> --- gcc/tree-ssa-loop-manip.c   (revision 195574)

> +++ gcc/tree-ssa-loop-manip.c   (working copy)

> @@ -536,7 +536,7 @@ rewrite_into_loop_closed_ssa (bitmap cha

> 

>/* Fix up all the names found to be used outside their original

>   loops.  */

> -  update_ssa (TODO_update_ssa);

> +  update_ssa (TODO_update_ssa_no_phi);

>  }

> 

>  /* Check invariants of the loop closed ssa form for the USE in BB.  */

> 

> why would adding a copy on an edge (thus a new def) require us to insert

> new PHI nodes?  With that patch:

> 

>  tree SSA incremental:   0.06 ( 0%) usr

>  TOTAL :  46.36

> 

> Of course I must not remember sth here ...



Multiple exits.



Btw, it's all virtual loop-closed PHI nodes we insert.  Thus, reverting



2012-08-23  Richard Guenther  



* tree-ssa-loop-manip.c (add_exit_phis_var): Allow virtual operands.

(find_uses_to_rename_use): Likewise.

(find_uses_to_rename_bb): Likewise.

(find_uses_to_rename_stmt): Walk over all operands.



improves compile-time here (until somebody fixes the testcase so there is

a real use on each exit).

[Bug bootstrap/56128] [4.8 Regression] libsanitizer doesn't build with broken kernel headers

[dvyukov at google dot com]

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



Dmitry Vyukov  changed:



   What|Removed |Added



 CC||dvyukov at google dot com



--- Comment #7 from Dmitry Vyukov  2013-01-30 
15:32:02 UTC ---

Fixed upstream:

http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_linux.cc?r1=173933&r2=173932&pathrev=173933

[Bug c++/56152] New: explicit template instantiation of protected template function redeclared as public fails

[froydnj at gcc dot gnu.org]

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

 Bug #: 56152
   Summary: explicit template instantiation of protected template
function redeclared as public fails
Classification: Unclassified
   Product: gcc
   Version: 4.4.7
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: froy...@gcc.gnu.org


Compiling the following testcase:

enum Flavor {
  A,
  B
};

template
class C
{
protected:
  template
  static T f(T x)
  {
if (F == A)
  return x;
else
  return ~x;
  }
};

class AC : public C
{
private:
  typedef C super;

public:
  using super::f;
};

unsigned int
explicit_variable(unsigned int x)
{
  unsigned int (*func)(unsigned int) = AC::f;

  return func(x);
}

unsigned int
explicit_call_instantiation(unsigned int x)
{
  return AC::f(x);
}

unsigned int
implicit_call_instantiation(unsigned int x)
{
  return AC::f(x);
}

produces:

template-instantiation-bug.cpp: In function ‘unsigned int
explicit_variable(unsigned int)’:
template-instantiation-bug.cpp:11:12: error: ‘static T C::f(T) [with T =
unsigned int, Flavor F = (Flavor)0u]’ is protected
template-instantiation-bug.cpp:32:44: error: within this context
template-instantiation-bug.cpp:11:12: error: ‘static T C::f(T) [with T =
unsigned int, Flavor F = (Flavor)0u]’ is protected
template-instantiation-bug.cpp:32:44: error: within this context
template-instantiation-bug.cpp:11:12: error: ‘static T C::f(T) [with T =
unsigned int, Flavor F = (Flavor)0u]’ is protected
template-instantiation-bug.cpp:32:44: error: within this context

It is not obvious to me that this is the right answer, given that both
explicit_call_instantiation and implicit_call_instantiation work.

All versions of GCC that I've tested reject the testcase (4.4 - 4.8).  Clang
(2.8 - 3.2) accepts the testcase.  MSVC version 9 rejects it.  My MSVC version
10 installation appears to be busted, or I'd test it there too.

[Bug tree-optimization/56151] Performance degradation after r194054 on x86 Atom.

[ysrumyan at gmail dot com]

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



--- Comment #1 from Yuri Rumyantsev  2013-01-30 
15:20:07 UTC ---

Created attachment 29306

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

testcase to reproduce

[Bug tree-optimization/56151] New: Performance degradation after r194054 on x86 Atom.

[ysrumyan at gmail dot com]

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



 Bug #: 56151

   Summary: Performance degradation after r194054 on x86 Atom.

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

ReportedBy: ysrum...@gmail.com





For simple test-case extracted from one important benchmark we see number

instrctions increasing after fix r194054. If we compile test-case with compiler

built before this revision we have only 6 instructions for store stmt:



movl%edx, %ebx

movl%edx, %ebp

sarl$5, %ebx

andl$31, %ebp

movlsetmask(,%ebp,4), %ebp

orl%ebp, (%edi,%ebx,4)



but after this fix we got 9 instrctions for it:



movl%edx, %ebx

movl56(%esp), %esi

sarl$5, %ebx

movl%edx, %ebp

andl$31, %ebp

leal(%esi,%ebx,4), %esi

movl(%esi), %ebx

orlsetmask(,%ebp,4), %ebx

movl%ebx, (%esi)



To reproduce it is sufficient to compile with the following options:



-O2 -ffast-math -msse2 -mfpmath=sse -m32 -march=atom -mtune=atom

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

[janus at gcc dot gnu.org]

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



--- Comment #31 from janus at gcc dot gnu.org 2013-01-30 15:02:46 UTC ---

(In reply to comment #30)

> > ToDo: The test case in comment 4 still fails (cf. also comment 23 - 27).

> 

> Note that after revision 195562, the test in comment #4 and its subsequent

> modifications are no longer "memory hogs" and now give the ICE in a fraction 
> of

> second.



Right.





> Question: does the patch in comment #23 apply on top of r195562?



Yes, it should.

[Bug tree-optimization/56150] ICE segfault in do_pre / tail_merge_optimize

[francesco.zappa.nardelli at gmail dot com]

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



--- Comment #1 from Francesco Zappa Nardelli  2013-01-30 14:44:45 UTC ---

Sorry, forgot to specify: 



  Target: x86_64-unknown-linux-gnu

[Bug tree-optimization/56150] New: ICE segfault in do_pre / tail_merge_optimize

[francesco.zappa.nardelli at gmail dot com]

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

 Bug #: 56150
   Summary: ICE segfault in do_pre / tail_merge_optimize
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: francesco.zappa.narde...@gmail.com


The program below makes 

  gcc version 4.8.0 20130130 (experimental) (GCC)

crash (ICE) at optimisation level -O2 and -O3:

$ gcc -O2 5-min.c
5-min.c: In function ‘func_1’:
5-min.c:9:6: internal compiler error: Segmentation fault
 void func_1 () {
  ^
0x8e59af crash_signal
../../gcc-svn-src/gcc/toplev.c:332
0xa434a7 vn_valueize
../../gcc-svn-src/gcc/tree-ssa-sccvn.h:226
0xa434a7 gimple_equal_p
../../gcc-svn-src/gcc/tree-ssa-tail-merge.c:1124
0xa434a7 find_duplicate
../../gcc-svn-src/gcc/tree-ssa-tail-merge.c:1214
0xa434a7 find_clusters_1
../../gcc-svn-src/gcc/tree-ssa-tail-merge.c:1409
0xa434a7 find_clusters
../../gcc-svn-src/gcc/tree-ssa-tail-merge.c:1430
0xa455ec tail_merge_optimize(unsigned int)
../../gcc-svn-src/gcc/tree-ssa-tail-merge.c:1634
0xa0b69c do_pre
../../gcc-svn-src/gcc/tree-ssa-pre.c:4754

Here is the program 5-min.c:

struct {
  int f4;
} g1;

long g2;

volatile long g3;

void func_1 () {
if (g2)
g1 = g1;
else
g3;
}

void main () {
}

[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin

[jakub at gcc dot gnu.org]

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



--- Comment #13 from Jakub Jelinek  2013-01-30 
14:41:14 UTC ---

(In reply to comment #12)

> This one is a necessary one.

> asan_finish_file inserts __asan_init into the array of constructors (aka

> __mod_init_func section). But for some reason it is inserted at the end of 
> that

> array, while the constructors are being executed from the start of the array 
> at

> program startup. That's why the program crashes (because it's trying to 
> execute

> some instrumented code that accesses the shadow memory, which isn't mapped

> yet), and the real question is how do we put the new constructor first 
> provided

> that the ctor priorities do not work well on Darwin.



Guess if Darwin ignores priority, then the reason for that is that

asan_finish_file which adds the ctor is called very late during compilation

(and has to be, otherwise it e.g. wouldn't know if it is needed at all and what

globals need to be registered).

And the bug is clear, config/darwin* shouldn't ignore the priority.  If the

object format is lame enough and doesn't support priorities, at least the

routines should ensure the right priority ordering within the same compilation

unit (whether by not emitting anything right away and queueing it up for emit

very late, sorted according to the priority, or something else, I don't care).

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

[rguenth at gcc dot gnu.org]

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



--- Comment #16 from Richard Biener  2013-01-30 
14:38:29 UTC ---

The following (old!?) idea helps though:



Index: gcc/tree-ssa-loop-manip.c

===

--- gcc/tree-ssa-loop-manip.c   (revision 195574)

+++ gcc/tree-ssa-loop-manip.c   (working copy)

@@ -536,7 +536,7 @@ rewrite_into_loop_closed_ssa (bitmap cha



   /* Fix up all the names found to be used outside their original

  loops.  */

-  update_ssa (TODO_update_ssa);

+  update_ssa (TODO_update_ssa_no_phi);

 }



 /* Check invariants of the loop closed ssa form for the USE in BB.  */



why would adding a copy on an edge (thus a new def) require us to insert

new PHI nodes?  With that patch:



 tree SSA incremental:   0.06 ( 0%) usr

 TOTAL :  46.36



Of course I must not remember sth here ...

[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin

[glider at google dot com]

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



--- Comment #12 from Alexander Potapenko  2013-01-30 
14:32:54 UTC ---

> The question is why does...

> 

>   if (builtin_decl_implicit_p (BUILT_IN_ASAN_INIT))

> return;

> 

> in initialize_sanitizer_builtins() not emit a __asan_init while apparently...

I'm guessing initialize_sanitizer_builtins() just warms something up, but

doesn't actually emit any code. IANAGCCH though.



> tree fn = builtin_decl_implicit (BUILT_IN_ASAN_INIT);

> 

> in asan_finish_file() emits an apparenty unnecessary one in the wrong section.



This one is a necessary one.

asan_finish_file inserts __asan_init into the array of constructors (aka

__mod_init_func section). But for some reason it is inserted at the end of that

array, while the constructors are being executed from the start of the array at

program startup. That's why the program crashes (because it's trying to execute

some instrumented code that accesses the shadow memory, which isn't mapped

yet), and the real question is how do we put the new constructor first provided

that the ctor priorities do not work well on Darwin.

[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin

[howarth at nitro dot med.uc.edu]

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



--- Comment #11 from Jack Howarth  2013-01-30 
14:23:51 UTC ---

(In reply to comment #10)

> I suppose this isn't important. __mod_term_func are destructors, and they even

> aren't called in the crashing program.



The question is why does...



  if (builtin_decl_implicit_p (BUILT_IN_ASAN_INIT))

return;



in initialize_sanitizer_builtins() not emit a __asan_init while apparently...



tree fn = builtin_decl_implicit (BUILT_IN_ASAN_INIT);



in asan_finish_file() emits an apparenty unnecessary one in the wrong section.

[Bug fortran/56149] New: 64 bit gFortran-C interop hidden character argument length passed as 32 bit value

[paul.laidler at ntlworld dot com]

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



 Bug #: 56149

   Summary: 64 bit gFortran-C interop hidden character argument

length passed as 32 bit value

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: enhancement

  Priority: P3

 Component: fortran

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

ReportedBy: paul.laid...@ntlworld.com





This is not so much a bug but a significant gFortran limitation in my project

to port ClearWin+ to gFortran. Users will not want to edit all their "printf"

calls so that format strings become null terminated. This could be avoided if

the format string length where passed as a 64 bit integer. At the moment

gFortran passes a 32 bit value and allows garbage to remain in the HIDWORD so

the argument cannot safely be distinguished from a 64 bit address.



It would appear that there is no advantage in passing a 32 bit value in this

context.



As an aside, I would also suggest that interop programming would be much

simpler if literal character strings were stored in memory as null-terminated

strings.

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

[rguenth at gcc dot gnu.org]

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



--- Comment #15 from Richard Biener  2013-01-30 
13:50:04 UTC ---

All of the tree SSA incremental time is spent in computing the IDFs.  With

a patch to cache IDF on def-blocks nothing is gained.



Unpatched, n = 1:

 tree SSA incremental:  48.86 (51%) usr

 TOTAL :  94.88



I tried replacing the work-stack vector with a sparseset to avoid visiting

a block twice (and thus avoid doing the EXECUTE_IF_AND_COMPL_IN_BITMAP

twice which the 2nd time has no bits).  To no avail - sparseset seems to

have a higher overhead.

 tree SSA incremental:  52.25 (53%) usr

 TOTAL :  98.60



Also the phi-insertion-point update can be done with bitmap_ior_into

(slows things down tremendously):

 tree SSA incremental:  75.56 (62%) usr

 TOTAL : 121.73



combined with using a sparse-set for iteration:

 tree SSA incremental:  78.28 (63%) usr

 TOTAL : 124.72



arranging for the work_stack to be large enough to hold 2*n_basic_blocks

we can use quick_push in the inner loop.

 tree SSA incremental:  47.05 (51%) usr

 TOTAL :  91.60

[Bug fortran/56138] Deferred-length character RESULT: ICE in gfc_add_modify_loc

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|RESOLVED|ASSIGNED

 Resolution|FIXED   |



--- Comment #6 from Tobias Burnus  2013-01-30 
13:49:27 UTC ---

REOPEN.



As Dominique showed (thanks!), this bug is not fixed. It is only fixed if the

function is 'contained' in another one (e.g. main program) or in a module.



Additionally, the gfortran.dg/allocatable_function_6.f90 also passes without

the patch.





Paul's patch fixes the issue (similarly to my original patch, which, however,

regressed).



As Paul's patch doesn't regress: OK with reverting my patch and changing the

test case to a noncontained procedure (plus interface block in the caller).

[Bug lto/56061] [4.8 Regression] ICE in lto1 (in inline_call, at ipa-inline-transform.c:267)

[d.g.gorbachev at gmail dot com]

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



--- Comment #7 from Dmitry Gorbachev  
2013-01-30 13:39:37 UTC ---

> The other way around, compiling and installing with

> -O2 but then at link time use -O0 -g to get a debug

> build is more questionable



> However, I still don't see the point of "-O0 -flto"

> at link-time. We should either force it to be at

> least -O1 or (in my opinion better) give an error.



I think it could make sense. For example, I compile a certain static library

with `-O3 -flto', without `-g' (it's considered already debugged) and without

`-fno-fat-lto-objects' (so it can be used either with or without LTO); it is

shared between several programs. The programs have their own static libs, which

are compiled with `-g -O1 -flto -fno-fat-lto-objects' (could be `-O0', but

doesn't work, PR55102). Then, they are linked using `-g -O0 -flto' to get a

(partially) debug enabled program, or with `-O3 -flto' for a fully optimized

program.



> the docs have this example



Yes, but there is an aforementioned bug 55102.

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

[dominiq at lps dot ens.fr]

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



--- Comment #30 from Dominique d'Humieres  
2013-01-30 13:34:31 UTC ---

> ToDo: The test case in comment 4 still fails (cf. also comment 23 - 27).



Note that after revision 195562, the test in comment #4 and its subsequent

modifications are no longer "memory hogs" and now give the ICE in a fraction of

second.



r195562 is also likely to have changed the compiler behavior of some of my

tests derived from pr55959 (see pr55959 comment #4).



Question: does the patch in comment #23 apply on top of r195562?

[Bug fortran/55959] [OOP] ICE in in gfc_simplify_expr, at fortran/expr.c:1920

[dominiq at lps dot ens.fr]

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



--- Comment #4 from Dominique d'Humieres  2013-01-30 
13:28:58 UTC ---

The behavior of the test in comment #0 modified with the following patch



--- pr55959.f902013-01-13 12:23:04.0 +0100

+++ pr55959_0_db.f902013-01-13 12:43:43.0 +0100

@@ -27,7 +27,8 @@ contains



 function pdf_point_getx(this)

 class(pdf_point), intent(in) :: this

-real pdf_point_getx(this%dims)

+!real pdf_point_getx(2)

+real, dimension(getdims(this)) :: pdf_point_getx(x)

 pdf_point_getx(1) = this%p%x

 pdf_point_getx(2) = this%p%y

 end function pdf_point_getx

@@ -40,7 +41,8 @@ program abstract

 type(pdf_point) pp

 namelist /nml_pp/ pp



-print nml_pp

-print pp%getx()

+print *, nml_pp

+print *, pp%getx()

+contains



-end program abstract 

+end program abstract



has changed from



pr55959_0_db.f90:31.57:



real, dimension(getdims(this)) :: pdf_point_getx(x)

 1

Error: Expression at (1) must be of INTEGER type, found REAL

f951: internal compiler error: in replace_comp, at fortran/expr.c:4356



f951: internal compiler error: Abort trap

gfortran: internal compiler error: Abort trap (program f951)

Abort



with revision 195548, to



pr55959_0_db.f90:31.57:



real, dimension(getdims(this)) :: pdf_point_getx(x)

 1

Error: Expression at (1) must be of INTEGER type, found REAL

pr55959_0_db.f90:31.57:



real, dimension(getdims(this)) :: pdf_point_getx(x)

 1

Error: Expression at (1) must be of INTEGER type, found REAL

pr55959_0_db.f90:31.57:



real, dimension(getdims(this)) :: pdf_point_getx(x)

 1

Error: Expression at (1) must be of INTEGER type, found REAL

pr55959_0_db.f90:31.57:



real, dimension(getdims(this)) :: pdf_point_getx(x)

 1

Error: Expression at (1) must be of INTEGER type, found REAL

pr55959_0_db.f90:31.57:



real, dimension(getdims(this)) :: pdf_point_getx(x)

 1

Error: Expression at (1) must be of INTEGER type, found REAL

pr55959_0_db.f90:40.8:



use pdfs

1

Fatal Error: Can't open module file 'pdfs.mod' for reading at (1): No such file

or directory



with revision 195570 (likely due to r 195562), i.e., the ICE is gone, but the

error is duplicated 5 times.



Same thing with the following change



--- pr55959.f902013-01-13 12:23:04.0 +0100

+++ pr55959_0_db_1.f902013-01-13 12:45:10.0 +0100

@@ -27,7 +27,8 @@ contains



 function pdf_point_getx(this)

 class(pdf_point), intent(in) :: this

-real pdf_point_getx(this%dims)

+!real pdf_point_getx(2)

+real, dimension(getdims(this)) :: pdf_point_getx

 pdf_point_getx(1) = this%p%x

 pdf_point_getx(2) = this%p%y

 end function pdf_point_getx

@@ -40,7 +41,8 @@ program abstract

 type(pdf_point) pp

 namelist /nml_pp/ pp



-print nml_pp

-print pp%getx()

+print *, nml_pp

+print *, pp%getx()

+contains



-end program abstract 

+end program abstract

[Bug fortran/56138] Deferred-length character RESULT: ICE in gfc_add_modify_loc

[dominiq at lps dot ens.fr]

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



--- Comment #5 from Dominique d'Humieres  2013-01-30 
13:05:48 UTC ---

Compiling the test in comment #0 still gives the same ICE with revision 195570.

The tests in comment #1 and gfortran.dg/allocatable_function_6.f90 compile and

execute without error.



One thing I don't understand is that



  CHARACTER(LEN=:), ALLOCATABLE :: s_to_c



is accepted in the test in comment #1, but rejected with (3 times)



  CHARACTER(LEN=:),ALLOCATABLE :: chars

   1

Error: Deferred-length character component 'chars' at (1) is not yet supported



in the code at ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1913.txt.



This seems to be due to



> type VARYING_STRING

>   CHARACTER(LEN=:),ALLOCATABLE :: chars

> end type VARYING_STRING



i.e.,  "CHARACTER(LEN=:),ALLOCATABLE :: chars" being in a type definition.

Would it be possible to have a more explicit error?

[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin

[glider at google dot com]

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



--- Comment #10 from Alexander Potapenko  2013-01-30 
12:29:00 UTC ---

I suppose this isn't important. __mod_term_func are destructors, and they even

aren't called in the crashing program.

[Bug other/19165] (Natural) language independent error / warning classification

[fuscated at gmail dot com]

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



Teodor Petrov  changed:



   What|Removed |Added



 CC||fuscated at gmail dot com



--- Comment #15 from Teodor Petrov  2013-01-30 
12:13:52 UTC ---

I'm speaking as one of Code::Blocks' developers:

If you implement this we'll for sure use it, because we have many complaints

similar to the one Eclipse's developers have. 



(After one such complaint I've found this bug, by the way).



Some suggestions: 

Don't pack the line/column info with the file name, if possible.

So the proposed diagnostic from this:



inicializaci�n de un miembro de matriz flexible en un contexto anidado





will turn in to this, which will be easier to parse:



inicializaci�n de un miembro de matriz flexible en un contexto anidado





Also, if it is possible group the notes/instances info with the error/warning

messages. This way it will allows us to show the information in a better way.

[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||vmakarov at gcc dot gnu.org

   Target Milestone|--- |4.8.0

[Bug inline-asm/56148] New: [4.8 Regression] inline asm matching constraint with different mode

[jakub at gcc dot gnu.org]

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

 Bug #: 56148
   Summary: [4.8 Regression] inline asm matching constraint with
different mode
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


void
foo (void)
{
  unsigned char e[16];
  unsigned long a, b, c, d;
  __asm__ __volatile__ ("" : "=d" (a), "=&c" (c), "=&D" (d), "=&a" (b)
   : "0" (-1U), "mr" (e), "1" (128 >> 5), "2" (e), "3" (-1U));
}

is rejected since LRA merge on x86_64-linux at -O2:
rh905862.i: In function ‘foo’:
rh905862.i:6:3: error: ‘asm’ operand has impossible constraints
   __asm__ __volatile__ ("" : "=d" (a), "=&c" (c), "=&D" (d), "=&a" (b)
   ^

The testcase is questionable, because a, c and b are DImode, while -1U, 128 >>
5
and -1U are all SImode using 0/1/3 constraints matching those DImodes.
But we accept it with reload or with -O0 even with LRA.

[Bug other/56141] 4.8.0 git version fails to config - there is no cloog-ppl-0.18.0

[jarausch at igpm dot rwth-aachen.de]

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



--- Comment #5 from jarausch at igpm dot rwth-aachen.de 2013-01-30 11:54:14 UTC 
---

Many thanks for your help,



Helmut.

[Bug c++/53609] Wrong variadic template pack expansion in alias template

[dodji at gcc dot gnu.org]

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



Dodji Seketeli  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #4 from Dodji Seketeli  2013-01-30 
11:44:49 UTC ---

Fixed in trunk (4.8)

[Bug c/47409] volatile struct member bug

[jakub at gcc dot gnu.org]

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



--- Comment #11 from Jakub Jelinek  2013-01-30 
11:43:38 UTC ---

Or the FE should expand the structure assignment in that case to some other

stmts based on what the right semantics is (using loops for larger objects

etc.) and only keep aggregate assignments in the IL for non-volatile (neither

object itself, nor any of the fields) assignments.

[Bug other/56141] 4.8.0 git version fails to config - there is no cloog-ppl-0.18.0

[rguenth at gcc dot gnu.org]

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



--- Comment #4 from Richard Biener  2013-01-30 
11:40:54 UTC ---

(In reply to comment #3)

> (In reply to comment #2)

> > If you're doing a non-default build (e.g. using cloog) you need to say 
> > exactly

> > what you're doing and provide the FULL configure command.

> > 

> > Trunk no longer uses PPL, it uses ISL, see

> > http://gcc.gnu.org/install/prerequisites.html

> 

> There one can read

> CLooG 0.18.0

>  Necessary to build GCC with the Graphite loop optimizations. 

> 

> Isn't that true anymore?



It is.  You need CLooG and ISL compared to CLooG-PPL and PPL previously.

[Bug lto/56147] [4.8 Regression] ICE on invalid code in lto_symtab_merge_decls_1

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #4 from Richard Biener  2013-01-30 
11:40:19 UTC ---

Fixed.

[Bug lto/56147] [4.8 Regression] ICE on invalid code in lto_symtab_merge_decls_1

[rguenth at gcc dot gnu.org]

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



--- Comment #3 from Richard Biener  2013-01-30 
11:39:28 UTC ---

Author: rguenth

Date: Wed Jan 30 11:39:19 2013

New Revision: 195575



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

Log:

2013-01-30  Richard Biener  



PR lto/56147

* lto-symtab.c (lto_symtab_merge_decls_1): Guard DECL_BUILT_IN

check.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/lto-symtab.c

[Bug c/47409] volatile struct member bug

[rguenth at gcc dot gnu.org]

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



--- Comment #10 from Richard Biener  2013-01-30 
11:38:30 UTC ---

struct s2 {

  volatile int x;

};



struct s2 s;



void foo (void) {

  s = s;

}



As said previously I think that volatile struct members are ill-defined.

The only way for the middle-end to see the volatileness in the above

s = s copy is if the frontend would make 's' volatile.  That is,

effectively make it



struct s2 {

  volatile int x;

};



typedef volatile struct s2 S;



S s;



as there is otherwise no way to mark 's' in s = s with TREE_THIS_VOLATILE

(it's the plain decl, which in the original testcase is not volatile).