[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



Uros Bizjak  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-02-10

 Ever Confirmed|0   |1



--- Comment #2 from Uros Bizjak  2013-02-10 07:57:30 
UTC ---

Please test the source from the latest 4.6 SVN branch.

[Bug tree-optimization/56273] [4.8 regression] Bogus -Warray-bounds warning

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



   Keywords||diagnostic,

   ||missed-optimization

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-10

  Component|other   |tree-optimization

 Ever Confirmed|0   |1



--- Comment #2 from Andrew Pinski  2013-02-10 
07:34:54 UTC ---

The problem is a missing VRP.  Basically ivopts changes:

  if (j_10 != 9)



Which works into:



  j_10 = ivtmp.12_56;

  if (ivtmp.12_56 != 9)

goto ;

  else

goto ;





Which does not work as VRP cannot figure out j_10 will never be 9.

I have some patches to VRP which improves this but I don't remember if it fixes

this case where there is an assignment which is used later on.

[Bug other/56273] [4.8 regression] Bogus -Warray-bounds warning

[daniel at constexpr dot org]

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



--- Comment #1 from Daniel Scharrer  2013-02-10 
07:07:40 UTC ---

The same code and command-line arguments do not produce a warning in gcc 4.7.2,

4.6.3, 4.5.4 and clang 3.2 as well as clang's static analyzer.

[Bug other/56273] New: [4.8 regression] Bogus -Warray-bounds warning

[daniel at constexpr dot org]

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

 Bug #: 56273
   Summary: [4.8 regression] Bogus -Warray-bounds warning
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dan...@constexpr.org


The following C++ code cause current gcc master to emit an incorrect array
bounds warning:

$ cat test.cpp 

struct type {
  bool a, b;
  bool get_b() { return b; }
};

type stuff[9u];

void bar();

void foo() {

  for(unsigned i = 0u; i < 9u; i++) {

if(!stuff[i].a) {
  continue;
}

bar();

for(unsigned j = i + 1u; j < 9u; j++) {
  if(stuff[j].a && stuff[j].get_b()) {
return;
  }
}

  }
}

$ g++-4.8.0-pre -Warray-bounds -O3 -c test.cpp
test.cpp: In function ‘void foo()’:
test.cpp:22:17: warning: array subscript is above array bounds [-Warray-bounds]
   if(stuff[j].a && stuff[j].get_b()) {
 ^

I appreciate static analyzers as much as everyone, but having false positives
in the normal warnings (especially ones enabled at -Wall) can be annoying.

GCC was build from git master just now:

$ g++-4.8.0-pre -v
Using built-in specs.   
COLLECT_GCC=g++-4.8.0-pre
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0-pre/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.8.0_pre/work/gcc-4.8.0-/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-pre
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check
--with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls
--without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --enable-multilib
--with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/python
--enable-checking=release --disable-libgcj --enable-libstdcxx-time
--enable-languages=c,c++,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_pre'
Thread model: posix
gcc version 4.8.0-pre 20130210 (experimental) commit
bc85f3af1b43674782c9b5bb2240117f293b5530 (Gentoo 4.8.0_pre)

[Bug c++/56272] New: Poor diagnostics for error: specialization of ... after instantiation

[ppluzhnikov at google dot com]

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

 Bug #: 56272
   Summary: Poor diagnostics for error: specialization of ...
after instantiation
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com


Test case:

template  class A
{
void Invert ()
{
A < double >a;
}
};

template class A;

template <> void A < double >::Invert ();



g++ -c t.ii
t.ii:11:40: error: specialization of ‘void A::Invert() [with T = double]’
after instantiation

Yes, but where was instantiation triggered?

In this reduced test case, it's obvious, but in a real test case I have 2MB of
text, the code builds fine with gcc-4.7, and the instantiation point is nowhere
to be seen.

[Bug ada/56271] New: GCC build errors when building ada and using LDFLAGS

[karlson2k at gmail dot com]

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



 Bug #: 56271

   Summary: GCC build errors when building ada and using LDFLAGS

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: ada

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

ReportedBy: karlso...@gmail.com

  Host: i686-pc-mingw32

Target: i686-pc-mingw32

 Build: x86_64-w64-mingw32, i686-w64-mingw32





GCC is configured with 



LDFLAGS="-L/home/xxx/mingw-w64/packages/gcc/packages/gmp/gmp-5.1.0-i686/lib"

../../source/gcc-4.7.2/configure --build=i686-pc-mingw32 --host=i686-pc-mingw32

--target=i686-w64-mingw32 --disable-nls --disable-multilib

--prefix=/home/xxx/mingw-w64/mingw-w64-i686

--with-sysroot=/home/xxx/mingw-w64/mingw-w64-i686

--with-native-system-header-dir=/i686-w64-mingw32/include

--with-host-libstdcxx=/mingw/lib/gcc/mingw32/4.7.2/libstdc++.a

--disable-cloog-version-check --disable-ppl-version-check

--with-mpc=/home/xxx/mingw-w64/packages/gcc/packages/mpc/mpc-1.0.1-i686

--with-mpfr=/home/xxx/mingw-w64/packages/gcc/packages/mpfr/mpfr-3.1.1-i686

--with-gmp=/home/xxx/mingw-w64/packages/gcc/packages/gmp/gmp-5.1.0-i686

--with-ppl=/home/xxx/mingw-w64/packages/gcc/packages/ppl/ppl-1.0-i686

--with-isl=/home/xxx/mingw-w64/packages/gcc/packages/isl/isl-0.11.1-i686

--with-cloog=/home/xxx/mingw-w64/packages/gcc/packages/cloog-ppl/cloog-ppl-0.15.11-i686

--enable-languages=ada,c,c++ --enable-threads=win32

--enable-fully-dynamic-string --disable-sjlj-exceptions

--with-multilib-list=m32 --with-arch=pentium3

--enable-leading-mingw64-underscores --with-dwarf2 --enable-lto

--disable-win32-registry --with-win32-nlsapi=unicode --enable-libstdcxx-debug



Building ada is always produce some errors like 



if [ -f gnat1.exe ] ; \

then \

  make "ADA_CFLAGS=" "BISON=bison" "BISONFLAGS=" "CFLAGS=-pipe

-D__USE_MINGW_ACCESS "

"LDFLAGS=-L/home/xxx/mingw-w64/packages/gcc/packages/gmp/gmp-5.1.0-i686/lib

"FLEX=flex" "FLEXFLAGS=" "LN=ln" "LN_S=cp -pR"

"MAKEINFO=makeinfo--split-size=500" "MAKEINFOFLAGS=--no-split"

"MAKEOVERRIDES=" "SHELL=/bin/sh" "exeext=.exe" "build_exeext=.exe" "objext=.o"

"exec_prefix=/home/xxx/mingw-w64/mingw-w64-i686"

"prefix=/home/xxx/mingw-w64/mingw-w64-i686" "local_prefix=/usr/local"

"gxx_include_dir=/home/xxx/mingw-w64/mingw-w64-i686/lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/c++/4.7.2"

"build_tooldir=/home/xxx/mingw-w64/mingw-w64-i686/i686-w64-mingw32"

"gcc_tooldir=/home/xxx/mingw-w64/mingw-w64-i686/lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32"

"bindir=/home/xxx/mingw-w64/mingw-w64-i686/bin"

"libexecsubdir=/home/xxx/mingw-w64/mingw-w64-i686/libexec/gcc/i686-w64-mingw32/4.7.2"

"datarootdir=/home/xxx/mingw-w64/mingw-w64-i686/share"

"datadir=/home/xxx/mingw-w64/mingw-w64-i686/share"

"localedir=/home/xxx/mingw-w64/mingw-w64-i686/share/locale" "ADA_FOR_BUILD="

"ADA_INCLUDE_DIR=/home/xxx/mingw-w64/mingw-w64-i686/lib/gcc/i686-w64-mingw32/4.7.2/adainclude"

"ADA_RTL_OBJ_DIR=/home/xxx/mingw-w64/mingw-w64-i686/lib/gcc/i686-w64-mingw32/4.7.2/adalib"

"ADAFLAGS=-gnatpg -gnata -gnatwns -W -Wall" "ADA_FOR_TARGET="

"INSTALL=/bin/install -c" "INSTALL_DATA=/bin/install -c -m 644"

"INSTALL_PROGRAM=/bin/install -c" install-gnatlib; \

fi

/bin/sh: -c: line 2: unexpected EOF while looking for matching `"'

/bin/sh: -c: line 4: syntax error: unexpected end of file

make[1]: [ada.install-common] Error 2 (ignored)



As you can see make parameter "LDFLAGS=... don't have closing double quote.

The reason for this is as follows: 'root' Makefile adds to LDFLAGS: 



LDFLAGS += -Wl,--stack,12582912



, so ./gcc/Makefile has 



LDFLAGS = 

-L/home/Karlson/mingw-w64/packages/gcc/packages/gmp/gmp-5.1.0-i686/lib

-Wl,--stack,12582912



that flag in included into FLAGS_TO_PASS by



FLAGS_TO_PASS = \

"ADA_CFLAGS=$(ADA_CFLAGS)" \

"BISON=$(BISON)" \

"BISONFLAGS=$(BISONFLAGS)" \

"CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \

"LDFLAGS=$(LDFLAGS)" \

"FLEX=$(FLEX)" \...



which is filtered in included makefile

source/gcc/ada/gcc-interface/Make-lang.in:



COMMON_FLAGS_TO_PASS = $(filter-out -pedantic -W%, $(FLAGS_TO_PASS))



This filter is supposed to exclude '-pedantic' and all warning control flags,

but in real:

1. Don't filter out option not surrounded by spaces, like CFLAGS=-pedantic

2. With '-W%' filter out with closing quote in "LDFLAGS=-L/some/path

-Wl,--stack,12582912"

3. Filter out all -Wp,... -Wl,... -Wa,.. options as well

[Bug tree-optimization/56270] loop over array of struct float causes compiler error: segmentation fault

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |tree-optimization

--- Comment #1 from Andrew Pinski  2013-02-09 
23:47:26 UTC ---
pinskia@server:~/src/local$ ~/local-gcc/bin/x86_64-unknown-linux-gnu-gcc-4.7.0
-O3  t.c 
mbb.c: In function ‘Compute’:
mbb.c:33:6: internal compiler error: vector VEC(tree,base) index domain error,
in vectorizable_store at tree-vect-stmts.c:3920
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


But works on the trunk.

[Bug c/56270] New: loop over array of struct float causes compiler error: segmentation fault

[4303843KIWEMNPULN at kabelmail dot de]

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



 Bug #: 56270

   Summary: loop over array of struct float causes compiler error:

segmentation fault

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

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

ReportedBy: 4303843kiwemnp...@kabelmail.de





Created attachment 29408

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

Preprocessed file, comment, compiler call, compiler configuration



Compiling a loop over an array of struct with members of type float leads to:

internal compiler error: Segmentation Fault



Occurs optimizing with -O3



Affected gcc versions: 4.7.2, 4.6.3, 4.6.1, 4.5.2 (at least)

NOT affected versions: 3.4.3 (at least)



Platforms: Solaris 11.1, Ubuntu 12.04.2 LTS (precise), Linux Mint 12 (Lisa);

(Ubuntu and LinuxMint in Virtual Box)



Solaris uname -a: SunOS xxx 5.11 11.1 i86pc i386 i86pc

Ubuntu uname -a Linux xxx 3.2.0-37-generic #58-Ubuntu SMP Thu Jan 24 15:28:10

UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

LinuxMint uname -a: Linux xxx 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7

14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux





Attachment contains preprocessed file and further information

[Bug go/56017] libgo testsuite does not support cross testing

[ian at airs dot com]

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



--- Comment #13 from Ian Lance Taylor  2013-02-09 23:20:42 
UTC ---

Those problems may be fixed, let me know what the next one is.

[Bug go/56017] libgo testsuite does not support cross testing

[ian at gcc dot gnu.org]

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



--- Comment #12 from ian at gcc dot gnu.org  2013-02-09 
23:19:41 UTC ---

Author: ian

Date: Sat Feb  9 23:19:33 2013

New Revision: 195927



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

Log:

PR go/56017

libgo testsuite: If using DejaGNU, don't frob the log file.



Modified:

trunk/libgo/Makefile.am

trunk/libgo/Makefile.in

[Bug go/56017] libgo testsuite does not support cross testing

[ian at gcc dot gnu.org]

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



--- Comment #11 from ian at gcc dot gnu.org  2013-02-09 
23:02:27 UTC ---

Author: ian

Date: Sat Feb  9 23:02:09 2013

New Revision: 195926



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

Log:

PR go/56017

libgo DejaGNU testsuite: Load timeout.exp before go.exp.



Modified:

trunk/libgo/testsuite/lib/libgo.exp

[Bug c/53529] assembler errors while building a cross compiler if . (dot) is in your PATH

[pinskia at gcc dot gnu.org]

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



--- Comment #4 from Andrew Pinski  2013-02-09 
23:00:37 UTC ---

(In reply to comment #3)

> Similar error is always on MinGW hosts. MinGW has '.' in front of PATH by

> default.

> So if try to build GCC with language that require C++ or to build GCC by C++,

> you'll always get 



I fixed that issue in 4.8, see PR 54279.  The original issue of as/ld in the

PATH is recorded here.

[Bug fortran/56269] I've installed gcc but gfortran doesn't work, see in the attached file

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #9 from Andrew Pinski  2013-02-09 
22:57:37 UTC ---

configure:12799: checking for Fortran compiler version

configure:12808:  --version >&5

../gcc-4.7.2/libgfortran/configure: line 12810: --version: command not found



You also seem like you are build libgfortran by itself which is not supported

at all.

[Bug fortran/56269] I've installed gcc but gfortran doesn't work, see in the attached file

[mikael at gcc dot gnu.org]

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



--- Comment #8 from Mikael Morin  2013-02-09 
22:40:10 UTC ---

Something is seriously flawed on your side.

What is your toplevel configure command?

[Bug libstdc++/56257] std::vector allows access to the elements of _Vector_base

[bangerth at gmail dot com]

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



--- Comment #3 from Wolfgang Bangerth  2013-02-09 
21:37:55 UTC ---

:-) Sure, and of course I did tell him "don't do that". In essence it's a

question of how easy it is to shoot yourself in the foot by exposing internal

details of the implementation.

[Bug go/56017] libgo testsuite does not support cross testing

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

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



--- Comment #10 from Andreas Schwab  2013-02-09 21:03:35 
UTC ---

mv: cannot stat ‘.././libgo/libgo.sum’: No such file or directory

mv: cannot stat ‘.././libgo/libgo.log’: No such file or directory

cat: .././libgo/libgo.sum.sep: No such file or directory

cat: .././libgo/libgo.log.sep: No such file or directory

grep: .././libgo/libgo.sum.sep: No such file or directory

expr: syntax error

/bin/sh: line 28: test: : integer expression expected

grep: .././libgo/libgo.sum.sep: No such file or directory

expr: syntax error

/bin/sh: line 33: test: : integer expression expected

grep: .././libgo/libgo.sum.sep: No such file or directory

expr: syntax error

/bin/sh: line 38: test: : integer expression expected

/bin/sh: line 45: test: : integer expression expected

/bin/sh: line 48: test: : integer expression expected

/bin/sh: line 51: test: : integer expression expected

/bin/sh: line 57: test: : integer expression expected

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

[jason at gcc dot gnu.org]

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



--- Comment #5 from Jason Merrill  2013-02-09 
20:54:05 UTC ---

Author: jason

Date: Sat Feb  9 20:53:59 2013

New Revision: 195924



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

Log:

PR c++/56247

* pt.c (eq_specializations): Set comparing_specializations.

* tree.c (cp_tree_equal): Check it.

* cp-tree.h: Declare it.



Added:

branches/gcc-4_6-branch/gcc/testsuite/g++.dg/template/ptrmem23.C

Modified:

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

branches/gcc-4_6-branch/gcc/cp/cp-tree.h

branches/gcc-4_6-branch/gcc/cp/pt.c

branches/gcc-4_6-branch/gcc/cp/tree.c

[Bug go/56017] libgo testsuite does not support cross testing

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

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



--- Comment #9 from Andreas Schwab  2013-02-09 20:49:39 
UTC ---

# DejaGnu does not have proper library search paths for load_lib.   

# We have to explicitly load everything that go.exp wants to load.

[Bug go/56017] libgo testsuite does not support cross testing

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

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



--- Comment #8 from Andreas Schwab  2013-02-09 20:48:07 
UTC ---

The others were already loaded via libgo.exp.



Looking for ../../../../gcc/libgo/testsuite/../../gcc/testsuite/lib/prune.exp

Found ../../../../gcc/libgo/testsuite/../../gcc/testsuite/lib/prune.exp

Looking for

../../../../gcc/libgo/testsuite/../../gcc/testsuite/lib/target-libpath.exp

Found

../../../../gcc/libgo/testsuite/../../gcc/testsuite/lib/target-libpath.exp

Looking for ../../../../gcc/libgo/testsuite/../../gcc/testsuite/lib/wrapper.exp

Found ../../../../gcc/libgo/testsuite/../../gcc/testsuite/lib/wrapper.exp

Looking for

../../../../gcc/libgo/testsuite/../../gcc/testsuite/lib/gcc-defs.exp

Found ../../../../gcc/libgo/testsuite/../../gcc/testsuite/lib/gcc-defs.exp

Looking for ../../../../gcc/libgo/testsuite/../../gcc/testsuite/lib/go.exp

Found ../../../../gcc/libgo/testsuite/../../gcc/testsuite/lib/go.exp

Looking for library file ../lib/timeout.exp

Looking for library file /usr/share/dejagnu/timeout.exp

Looking for library file /usr/share/dejagnu/lib/timeout.exp

Looking for library file ../../../../gcc/dejagnu/lib/timeout.exp

Looking for library file ../../../../gcc/libgo/testsuite/lib/timeout.exp

Looking for library file /usr/share/dejagnu/lib/timeout.exp

Looking for library file ./timeout.exp

Looking for library file ../../../../dejagnu/lib/timeout.exp

ERROR: Couldn't find library file timeout.exp.

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

[jason at gcc dot gnu.org]

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



--- Comment #4 from Jason Merrill  2013-02-09 
20:47:31 UTC ---

Author: jason

Date: Sat Feb  9 20:47:24 2013

New Revision: 195923



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

Log:

PR c++/56247

* pt.c (eq_specializations): Set comparing_specializations.

* tree.c (cp_tree_equal): Check it.

* cp-tree.h: Declare it.



Added:

branches/gcc-4_7-branch/gcc/testsuite/g++.dg/template/ptrmem23.C

Modified:

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

branches/gcc-4_7-branch/gcc/cp/cp-tree.h

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

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

[Bug fortran/56269] I've installed gcc but gfortran doesn't work, see in the attached file

[shimonya at gmail dot com]

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



--- Comment #7 from shimonya at gmail dot com 2013-02-09 20:45:33 UTC ---

Thank you. I renamed it and now I get a new error (see in the new attached

file).(In reply to comment #6)

> Created attachment 29407 [details]

> This is the new config.log file

[Bug fortran/56269] I've installed gcc but gfortran doesn't work, see in the attached file

[shimonya at gmail dot com]

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



--- Comment #6 from shimonya at gmail dot com 2013-02-09 20:43:49 UTC ---

Created attachment 29407

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

This is the new config.log file

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

[jason at gcc dot gnu.org]

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



--- Comment #3 from Jason Merrill  2013-02-09 
20:39:21 UTC ---

Author: jason

Date: Sat Feb  9 20:39:13 2013

New Revision: 195922



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

Log:

PR c++/56247

* pt.c (eq_specializations): Set comparing_specializations.

* tree.c (cp_tree_equal): Check it.

* cp-tree.h: Declare it.



Added:

trunk/gcc/testsuite/g++.dg/template/ptrmem23.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/cp-tree.h

trunk/gcc/cp/pt.c

trunk/gcc/cp/tree.c

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

[jason at gcc dot gnu.org]

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



--- Comment #2 from Jason Merrill  2013-02-09 
20:38:44 UTC ---

Author: jason

Date: Sat Feb  9 20:38:33 2013

New Revision: 195920



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

Log:

PR c++/56238

* pt.c (build_non_dependent_expr): Don't try to fold

instantiation-dependent expressions.

(instantiation_dependent_r) [TRAIT_EXPR]: Split out.

[BIND_EXPR]: Treat as dependent.



Added:

trunk/gcc/testsuite/g++.dg/template/cast2.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/pt.c

[Bug fortran/51976] [F2003] Support deferred-length character components of derived types (allocatable string length)

[pault at gcc dot gnu.org]

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



--- Comment #7 from Paul Thomas  2013-02-09 20:33:56 
UTC ---

Created attachment 29406

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

Draft patch for the PR



This turned out to be easier than I expected.  It obviously needs a bit of

cleaning up; deferred character length variables should be made consistent with

their variable cousins.  This will not take much doing and I expect to submit

the patch tomorrow.



Bootstraps and regtests on trunk.  Proto-testcase:

  type t

character(len=:), allocatable :: str_comp

  end type t

  type(t) :: x

  allocate (x%str_comp, source = "abc")

  print *, len (x%str_comp), x%str_comp



  deallocate (x%str_comp)



  allocate (x%str_comp, source = "abcdefghijklmnop")

  print *, len (x%str_comp), x%str_comp



  x%str_comp = "xyz"

  print *, len (x%str_comp), x%str_comp



  x%str_comp = "abcdefghijklmnop"

  call foo (x%str_comp)

contains

  subroutine foo (chr)

character (*) :: chr

print *, len (chr), chr

  end subroutine

end



Cheers



Paul

[Bug c/53529] assembler errors while building a cross compiler if . (dot) is in your PATH

[karlson2k at gmail dot com]

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



Evgeny Grin  changed:



   What|Removed |Added



 CC||karlson2k at gmail dot com



--- Comment #3 from Evgeny Grin  2013-02-09 
20:30:33 UTC ---

Similar error is always on MinGW hosts. MinGW has '.' in front of PATH by

default.

So if try to build GCC with language that require C++ or to build GCC by C++,

you'll always get 



g++.exe: fatal error: -fuse-linker-plugin, but liblto_plugin-0.dll not found



when building inside sources/gcc/gcc subdirectory.



When building GCC using C, there no such problem as temporal GCC renamed to

xgcc.exe . But when building GCC using C++, temporal g++.exe is placed in gcc

subdirectory and erroneously called instead of host g++ if PATH variable is

prefixed by '.:'



That's the reason because all MinGW GCC builds are failed when building using

C++.

Tried with GCC 4.7.2

[Bug fortran/56269] I've installed gcc but gfortran doesn't work, see in the attached file

[mikael at gcc dot gnu.org]

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



--- Comment #5 from Mikael Morin  2013-02-09 
20:22:52 UTC ---

(In reply to comment #4)

> (In reply to comment #3)

> > Thank you for your fast reply.

> > What can I do in order to have only version 4.7.2?

> 

> Obviously, you can remove/uninstall version 4.5.3 (the fortran compiler only).

> Or remove it from the PATH environment variable.



Or move it to somewhere else.

Or rename it to something else.

[Bug fortran/56269] I've installed gcc but gfortran doesn't work, see in the attached file

[mikael at gcc dot gnu.org]

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



--- Comment #4 from Mikael Morin  2013-02-09 
20:21:51 UTC ---

(In reply to comment #3)

> Thank you for your fast reply.

> What can I do in order to have only version 4.7.2?



Obviously, you can remove/uninstall version 4.5.3 (the fortran compiler only).

Or remove it from the PATH environment variable.

[Bug fortran/56224] [4.8 Regression] gfortran -fopenmp cannot find omp_lib.h

[tkoenig at gcc dot gnu.org]

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



Thomas Koenig  changed:



   What|Removed |Added



URL||http://gcc.gnu.org/ml/gcc-p

   ||atches/2013-02/msg00415.htm

   ||l



--- Comment #4 from Thomas Koenig  2013-02-09 
20:13:24 UTC ---

Patch has been posted.

[Bug fortran/56269] I've installed gcc but gfortran doesn't work, see in the attached file

[shimonya at gmail dot com]

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



--- Comment #3 from shimonya at gmail dot com 2013-02-09 20:00:07 UTC ---

Thank you for your fast reply.

What can I do in order to have only version 4.7.2? (In reply to comment #2)

> You seem to have a version mix of 4.5.3 and 4.7.2

[Bug fortran/56269] I've installed gcc but gfortran doesn't work, see in the attached file

[mikael at gcc dot gnu.org]

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



Mikael Morin  changed:



   What|Removed |Added



 CC||mikael at gcc dot gnu.org



--- Comment #2 from Mikael Morin  2013-02-09 
19:54:30 UTC ---

You seem to have a version mix of 4.5.3 and 4.7.2

[Bug fortran/56269] I've installed gcc but gfortran doesn't work, see in the attached file

[shimonya at gmail dot com]

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



--- Comment #1 from shimonya at gmail dot com 2013-02-09 19:39:14 UTC ---

Created attachment 29405

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

This is the config.log file

[Bug fortran/56269] New: I've installed gcc but gfortran doesn't work, see in the attached file

[shimonya at gmail dot com]

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



 Bug #: 56269

   Summary: I've installed gcc but gfortran doesn't work, see in

the attached file

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

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

ReportedBy: shimo...@gmail.com





Hello,



I've got the following error:



configure: error: GNU Fortran is not working; please report a bug in

http://gcc.gnu.org/bugzilla, attaching /usr/local/contrib/build2/config.log



Thanks!

[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regression of 410.bwaves on x86.

[aldyh at gcc dot gnu.org]

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



--- Comment #17 from Aldy Hernandez  2013-02-09 
19:15:15 UTC ---

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

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

[aldyh at gcc dot gnu.org]

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



Aldy Hernandez  changed:



   What|Removed |Added



 Status|WAITING |RESOLVED

 Resolution||DUPLICATE



--- Comment #5 from Aldy Hernandez  2013-02-09 
19:15:15 UTC ---





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

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

[aldyh at gcc dot gnu.org]

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



--- Comment #10 from Aldy Hernandez  2013-02-09 
19:07:44 UTC ---

Created attachment 29404

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

untested patch



Untested proposed patch.

[Bug c++/55842] [4.7/4.8 Regression] C++11 ICE with boost multi-precision and boost variant

[koraq at xs4all dot nl]

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



--- Comment #8 from koraq at xs4all dot nl 2013-02-09 19:01:13 UTC ---

Thanks for fixing it, I can confirm this issue has been fixed. I ran into a

similar problem and filed it as bug 56268.

[Bug c++/56268] [4.7/4.8 Regression] C++11 ICE with boost multi-precision and boost variant during assignment

[koraq at xs4all dot nl]

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



--- Comment #1 from koraq at xs4all dot nl 2013-02-09 18:59:52 UTC ---

Created attachment 29403

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

Preprocessed source

[Bug c++/56268] New: [4.7/4.8 Regression] C++11 ICE with boost multi-precision and boost variant during assignment

[koraq at xs4all dot nl]

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



 Bug #: 56268

   Summary: [4.7/4.8 Regression] C++11 ICE with boost

multi-precision and boost variant during assignment

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: ko...@xs4all.nl





Created attachment 29402

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

Sample code to reproduce the problem



This issue is quite similar to bug 55842.



Compiling the attached sample file leads to an internal compiler error.

The problem only occurs with GCC-4.7 from Debian Unstable 4.7.2-5 and the

upcoming 4.8 from Debian Experimental 4.8-20130127-1. Tested on an amd64

system. (GCC 4.6 works, properly.)



I'm using a checkout of the latest boost release tree.



The command to reproduce the issue is:

gcc-4.8 -std=c++11 -c -I/src/boost/release test.cpp





In file included from /src/boost/release/boost/config.hpp:57:0,

 from /src/boost/release/boost/variant/detail/config.hpp:16,

 from /src/boost/release/boost/variant/variant.hpp:23,

 from /src/boost/release/boost/variant.hpp:17,

 from test.cpp:2:

/src/boost/release/boost/type_traits/has_nothrow_copy.hpp: In instantiation of

'const bool

boost::detail::has_nothrow_copy_imp > >::value':

/src/boost/release/boost/type_traits/has_nothrow_copy.hpp:32:1:   required from

'struct

boost::has_nothrow_copy > >'

/src/boost/release/boost/variant/variant.hpp:1908:17:   required from 'void

boost::variant::assigner::internal_visit(const RhsT&, int) [with RhsT

=

boost::multiprecision::number >; T0_ =

boost::multiprecision::number >; T1 = boost::detail::variant::void_; T2 = boost::detail::variant::void_;

T3 = boost::detail::variant::void_; T4 = boost::detail::variant::void_; T5 =

boost::detail::variant::void_; T6 = boost::detail::variant::void_; T7 =

boost::detail::variant::void_; T8 = boost::detail::variant::void_; T9 =

boost::detail::variant::void_; T10 = boost::detail::variant::void_; T11 =

boost::detail::variant::void_; T12 = boost::detail::variant::void_; T13 =

boost::detail::variant::void_; T14 = boost::detail::variant::void_; T15 =

boost::detail::variant::void_; T16 = boost::detail::variant::void_; T17 =

boost::detail::variant::void_; T18 = boost::detail::variant::void_; T19 =

boost::detail::variant::void_]'

/src/boost/release/boost/variant/detail/visitation_impl.hpp:130:9:   required

from 'typename Visitor::result_type

boost::detail::variant::visitation_impl_invoke_impl(int, Visitor&, VoidPtrCV,

T*, mpl_::true_) [with Visitor =

boost::variant > >::assigner; VoidPtrCV = const void*; T =

boost::multiprecision::number >; typename Visitor::result_type = void; mpl_::true_ = mpl_::bool_]'

/src/boost/release/boost/variant/detail/visitation_impl.hpp:173:9:   required

from 'typename Visitor::result_type

boost::detail::variant::visitation_impl_invoke(int, Visitor&, VoidPtrCV, T*,

NoBackupFlag, int) [with Visitor =

boost::variant > >::assigner; VoidPtrCV = const void*; T =

boost::multiprecision::number >; NoBackupFlag =

boost::variant > >::has_fallback_type_; typename Visitor::result_type = void]'

/src/boost/release/boost/variant/detail/visitation_impl.hpp:256:5:   required

from 'typename Visitor::result_type

boost::detail::variant::visitation_impl(int, int, Visitor&, VoidPtrCV,

mpl_::false_, NoBackupFlag, Which*, step0*) [with Which = mpl_::int_<0>; step0

=

boost::detail::variant::visitation_impl_step,

boost::multiprecision::number >, boost::mpl::l_end> >, boost::mpl::l_iter >; Visitor =

boost::variant > >::assigner; VoidPtrCV = const void*; NoBackupFlag =

boost::variant > >::has_fallback_type_; typename Visitor::result_type = void; mpl_::false_

= mpl_::bool_]'

/src/boost/release/boost/variant/variant.hpp:2326:13:   required from 'static

typename Visitor::result_type boost::variant::internal_apply_visitor_impl(int, int, Visitor&, VoidPtrCV) [with Visitor

=

boost::variant > >::assigner; VoidPtrCV = const void*; T0_ =

boost::multiprecision::number >; T1 = boost::detail::variant::void_; T2 = boost::detail::variant::void_;

T3 = boost::detail::variant::void_; T4 = boost::detail::variant::void_; T5 =

boost::detail::variant::void_; T6 = boost::detail::variant::void_; T7 =

boost::detail::variant::void_; T8 = boost::detail::variant::void_; T9 =

boost::detail::variant::void_; T10 = boost::detail::variant::void_; T11 =

boost::detail::variant::void_; T12 = boost::detail::variant::void_; T13 =

boost::detail::variant::void_; T14 = boost::detail::variant::void_; T15 =

boost::detail::variant::void_; T16 = boost::detail::variant::void_; T17 =

boost::detail::variant::void_; T18 = boost::detail::variant::void_; T19 =

boost::detail::variant::void_; typename Visito

[Bug libstdc++/56267] New: [4.7/4.8 Regression] unordered containers require Assignable hash function

[redi at gcc dot gnu.org]

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

 Bug #: 56267
   Summary: [4.7/4.8 Regression] unordered containers require
Assignable hash function
Classification: Unclassified
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org




#include 

struct hash : std::hash
{
  hash& operator=(const hash&) = delete;
};

int main()
{
  std::unordered_set s{ 0, 1, 2 };
  auto i = s.begin(0);
  i = i;
}


The standard does not require hash functions to be assignable.

We must cache the hash code unless is_copy_assignable is true, I'm testing
the fix.

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

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #11 from Jakub Jelinek  2013-02-09 
18:45:14 UTC ---

Fixed.

[Bug libstdc++/56111] [4.8 Regression] {float,double,long double} complex not accepted anymore

[jakub at gcc dot gnu.org]

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



--- Comment #14 from Jakub Jelinek  2013-02-09 
18:42:48 UTC ---

Given this is now P1, could the #c9 patch be committed soon, and perhaps just

defer a testcase for it when Marc returns?

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

[jakub at gcc dot gnu.org]

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



--- Comment #10 from Jakub Jelinek  2013-02-09 
18:41:05 UTC ---

Author: jakub

Date: Sat Feb  9 18:41:00 2013

New Revision: 195918



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

Log:

PR other/56245

* regex.c (PTR_INT_TYPE): Define.

(EXTEND_BUFFER): Change incr type from int to PTR_INT_TYPE.



Modified:

trunk/libiberty/ChangeLog

trunk/libiberty/regex.c

[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array

[janus at gcc dot gnu.org]

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



--- Comment #12 from janus at gcc dot gnu.org 2013-02-09 18:25:33 UTC ---

I just noticed that there is already related diagnostics in resolve.c

(resolve_global_procedure):



/* F2003, 12.3.1.1 (2d); F2008, 12.4.2.2 (2e)   */

else if (arg->sym->ts.type == BT_CLASS)

  {

gfc_error ("Procedure '%s' at %L with polymorphic dummy "

   "argument '%s' must have an explicit interface",

   sym->name, &sym->declared_at, arg->sym->name);

break;

  }



As a consequnce, whole_file_20.f03 now fails (due to a double error message).



Further, abstract_type_6.f03 fails, which is fixed by this:



Index: abstract_type_6.f03

===

--- abstract_type_6.f03 (revision 195915)

+++ abstract_type_6.f03 (working copy)

@@ -46,7 +46,7 @@



 SUBROUTINE bottom_c(obj)

CLASS(Bottom) :: obj

-   CALL top_c(obj)

+   CALL top_c(obj)   ! { dg-error "requires an explicit interface" }

! other stuff

 END SUBROUTINE bottom_c 

 end module

[Bug lto/52516] FAIL: gfortran.dg/lto/pr45586* f_lto_pr45586*_0.o-f_lto_pr45586_0.o link, -O0 -flto (internal compiler error)

[hp at gcc dot gnu.org]

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



--- Comment #3 from Hans-Peter Nilsson  2013-02-09 
18:19:28 UTC ---

I suggest this be marked as xfail, referring to PR45586.

[Bug go/56017] libgo testsuite does not support cross testing

[ian at airs dot com]

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



--- Comment #7 from Ian Lance Taylor  2013-02-09 18:17:13 
UTC ---

Sorry about that, I was told that it worked.



Can you figure out why it doesn't work?  It seems straightforward enough.  The

file gcc/testsuite/lib/go.exp does a load_lib of other files from that

directory.

[Bug fortran/56266] New: ICE on invalid in gfc_match_varspec

[abensonca at gmail dot com]

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



 Bug #: 56266

   Summary: ICE on invalid in gfc_match_varspec

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

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

ReportedBy: abenso...@gmail.com





The following causes an ICE with trunk (and 4.6 and 4.7):



module t



  type nc

   contains

 procedure :: encM => em

  end type nc



contains



  double precision function em(self)

implicit none

class  (nc), intent(inout) :: c

em=0.0d0

return

  end function em



  double precision function cem(c)

implicit none

class  (nc), intent(inout) :: c



cem=c(i)%encM()

return

  end function cem



end program p



$ gfortran -v

Using built-in specs.

COLLECT_GCC=gfortran

COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-

linux-gnu/4.8.0/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: ../gcc-trunk/configure --

prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --

disable-multilib --with-gmp=/home/abenson/Galacticus/Tools

Thread model: posix

gcc version 4.8.0 20130208 (experimental) (GCC) 

$ gfortran -o bug.exe bug.F90

f951: internal compiler error: in gfc_match_varspec, at fortran/primary.c:1960

0x540478 gfc_match_varspec(gfc_expr*, int, bool, bool)

../../gcc-trunk/gcc/fortran/primary.c:1957

0x541a99 gfc_match_rvalue(gfc_expr**)

../../gcc-trunk/gcc/fortran/primary.c:3118

0x528d8e match_primary

../../gcc-trunk/gcc/fortran/matchexp.c:157

0x528d8e match_level_1

../../gcc-trunk/gcc/fortran/matchexp.c:211

0x528d8e match_mult_operand

../../gcc-trunk/gcc/fortran/matchexp.c:265

0x528fc8 match_add_operand

../../gcc-trunk/gcc/fortran/matchexp.c:354

0x5292e4 match_level_2

../../gcc-trunk/gcc/fortran/matchexp.c:478

0x529382 match_level_3

../../gcc-trunk/gcc/fortran/matchexp.c:549

0x529495 match_level_4

../../gcc-trunk/gcc/fortran/matchexp.c:597

0x529495 match_and_operand

../../gcc-trunk/gcc/fortran/matchexp.c:691

0x529652 match_or_operand

../../gcc-trunk/gcc/fortran/matchexp.c:720

0x529742 match_equiv_operand

../../gcc-trunk/gcc/fortran/matchexp.c:763

0x529834 match_level_5

../../gcc-trunk/gcc/fortran/matchexp.c:809

0x528be1 gfc_match_expr(gfc_expr**)

../../gcc-trunk/gcc/fortran/matchexp.c:868

0x522631 gfc_match(char const*, ...)

../../gcc-trunk/gcc/fortran/match.c:1103

0x523b19 gfc_match_assignment()

../../gcc-trunk/gcc/fortran/match.c:1301

0x537449 match_word

../../gcc-trunk/gcc/fortran/parse.c:65

0x537bdb match_word

../../gcc-trunk/gcc/fortran/parse.c:326

0x537bdb decode_statement

../../gcc-trunk/gcc/fortran/parse.c:326

0x539194 next_free

../../gcc-trunk/gcc/fortran/parse.c:777

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.



This is with gfortran 4.8.0 r195874



The code is invalid because of this line:



cem=c(i)%encM()



both because "c" is not an array, and "i" is not declared (and the function is 

"IMPLICIT NONE")

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

[georggcc at googlemail dot com]

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



--- Comment #83 from Georg  2013-02-09 18:10:26 
UTC ---

(In reply to comment #82)

> Hopefully fixed once for all.



Just to confirm:



=== acats Summary ===

# of expected passes2320

# of unexpected failures0



=== gnat Summary ===



# of expected passes1158

# of expected failures  17

# of unsupported tests  5



$ gcc/xgcc -v

Using built-in specs.

COLLECT_GCC=gcc/xgcc

Target: x86_64-apple-darwin11.4.2

Configured with: /Users/bauhaus/src/gcc/configure

--prefix=/Users/bauhaus/bauhaus/mine --disable-nls --disable-libstdcxx-pch

--enable-languages=c,ada,c++,fortran CC=gcc

Thread model: posix

gcc version 4.8.0 20130208 (experimental) [trunk revision 195897] (GCC)

[Bug go/56017] libgo testsuite does not support cross testing

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

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



Andreas Schwab  changed:



   What|Removed |Added



 Status|RESOLVED|REOPENED

 Resolution|FIXED   |



--- Comment #6 from Andreas Schwab  2013-02-09 18:08:51 
UTC ---

Which does not work.



ERROR: Couldn't find library file timeout.exp.

[Bug go/56017] libgo testsuite does not support cross testing

[ian at airs dot com]

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



Ian Lance Taylor  changed:



   What|Removed |Added



 Status|REOPENED|RESOLVED

 Resolution||FIXED



--- Comment #5 from Ian Lance Taylor  2013-02-09 17:56:13 
UTC ---

I committed a patch for that failure yesterday.

[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array

[abensonca at gmail dot com]

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



--- Comment #11 from Andrew Benson  2013-02-09 
17:06:18 UTC ---

Thanks for figuring out the problem here. When I specify an interface for the

procedure pointer in the original code that I derived the test case from,

everything works OK.

[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array

[abensonca at gmail dot com]

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



--- Comment #10 from Andrew Benson  2013-02-09 
17:01:22 UTC ---

You're right - comment 1.

[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array

[janus at gcc dot gnu.org]

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



--- Comment #9 from janus at gcc dot gnu.org 2013-02-09 16:58:54 UTC ---

(In reply to comment #8)

> On the test case in comment 2,



comment 1?





> ifort v11.1 reports:

> 

> > ifort -o bug.exe bug.F90 

> bug.F90(23): error #6592: This symbol must be a defined parameter, an

> enumerator, or an argument of an inquiry function that evaluates to a

> compile-time constant.   [FF]

>   procedure(  ), pointer   :: f => ff

> ---^

> bug.F90(23): error #6973: This is not a valid initialization expression.   
> [FF]

>   procedure(  ), pointer   :: f => ff

> ---^

> compilation aborted for bug.F90 (code 1)

> 

> Same for the scalar case.



Thanks for checking. Probably ifort does not support pointer initialization yet

(which is a F08 feature).





> Interestingly, the workaround doesn't work under ifort - it seems not to like:

> 

>   procedure(ff), pointer :: f => ff

> 

> but instead needs:

> 

>   procedure(ff), pointer :: f

>   f => ff



Again, pointer initialization.





> In fact, if I use:

> 

>   procedure(), pointer :: f

>   f => ff

> 

> then it compiles without any warnings/errors but segfaults at runtime.

> 

> With:

> 

> 

>   procedure(ff), pointer :: f

>   f => ff

> 

> it compiles and runs as expected.



Good, that's compatible with gfortran's behavior (which is fine, since the test

case is invalid). Apparently ifort also lacks diagnostics for this.

[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



   Priority|P3  |P1

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-09

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1

[Bug tree-optimization/56265] New: [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[jakub at gcc dot gnu.org]

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



 Bug #: 56265

   Summary: [4.8 Regression] ICE in ipa_make_edge_direct_to_target

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: ice-on-valid-code

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

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

CC: hubi...@gcc.gnu.org





int baz ();

struct A

{

  virtual int fn2 () = 0;

  virtual int *fn3 ();

  double *fn4 ();

  int fn5 (int);

  template 

  void fn1 (A &, T) { fn3 (); fn4 (); fn2 (); }

};

struct B : A

{

  int fn2 () { return 6; }

  void fn3 (int, double);

  B (bool = true);

  B (int, int);

};

template 

void

foo (B &x, A &y, A &z)

{

  y.fn2 ();

  z.fn2 ();

  int i = baz ();

  int j = (y.fn3 ())[i];

  x.fn3 (j, (y.fn4 ())[i] + (z.fn4 ())[z.fn5 (j)]);

}

inline B

operator+ (A &y, A &z)

{

  B x;

  foo (x, y, z);

  return x;

}

void

bar ()

{

  B a, b, c (4, 0), d;

  a.fn1 (b, .6);

  baz ();

  c + d;

}



ICEs at -O2, starting with

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

[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array

[abensonca at gmail dot com]

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



--- Comment #8 from Andrew Benson  2013-02-09 
16:50:54 UTC ---

On the test case in comment 2, ifort v11.1 reports:



> ifort -o bug.exe bug.F90 

bug.F90(23): error #6592: This symbol must be a defined parameter, an

enumerator, or an argument of an inquiry function that evaluates to a

compile-time constant.   [FF]

  procedure(  ), pointer   :: f => ff

---^

bug.F90(23): error #6973: This is not a valid initialization expression.   [FF]

  procedure(  ), pointer   :: f => ff

---^

compilation aborted for bug.F90 (code 1)



Same for the scalar case.



Interestingly, the workaround doesn't work under ifort - it seems not to like:



  procedure(ff), pointer :: f => ff



but instead needs:



  procedure(ff), pointer :: f

  f => ff



In fact, if I use:



  procedure(), pointer :: f

  f => ff



then it compiles without any warnings/errors but segfaults at runtime.



With:





  procedure(ff), pointer :: f

  f => ff



it compiles and runs as expected.

[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #7 from janus at gcc dot gnu.org 2013-02-09 15:52:55 UTC ---

Here is a patch which rejects comment 0 and 1:



Index: gcc/fortran/interface.c

===

--- gcc/fortran/interface.c(revision 195915)

+++ gcc/fortran/interface.c(working copy)

@@ -3202,6 +3202,13 @@ gfc_procedure_use (gfc_symbol *sym, gfc_actual_arg

  "at %L", &a->expr->where);

   return FAILURE;

 }

+

+  if (a->expr && a->expr->ts.type == BT_CLASS)

+{

+  gfc_error ("Polymorphic argument requires an explicit interface "

+ "at %L", &a->expr->where);

+  return FAILURE;

+}

 }



   return SUCCESS;





I think it's ok to throw an error (and not just a warning), because a

polymorphic actual arg can only be passed to a polymorphic formal arg, which is

invalid in connection with an implicit interface.

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

[janus at gcc dot gnu.org]

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



--- Comment #6 from janus at gcc dot gnu.org 2013-02-09 15:34:34 UTC ---

The patch in comment 5 regtests cleanly!

[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-09

 Ever Confirmed|0   |1



--- Comment #6 from janus at gcc dot gnu.org 2013-02-09 15:30:13 UTC ---

(In reply to comment #5)

> I sincerely hope that all the test cases in this PR are invalud. One should

> check the standard!



Whew, good luck:



F08, chapter 12.4.2.2:

A procedure other than a statement function shall have an explicit interface if

it is referenced and

(1) a reference to the procedure appears

(a) with an argument keyword (12.5.2), or

(b) in a context that requires it to be pure,

(2) the procedure has a dummy argument that

(a) has the ALLOCATABLE, [...] attribute,

(b) is an assumed-shape array,

(c) is a coarray,

(d) is of a parameterized derived type, or

(e) is polymorphic,





It seems this is not something that the compiler is required to diagnose

(probably because that can be hard or impossible in certain cases), but the

programmer is responsible for checking this.



For comment 1, we should probably throw a warning (at least), but for comment 4

and 5 there is not much we can do, I guess.



In general I would advise against using procedure pointers without interface

(and EXTERNAL declarations), in particular in OOP code (but also in other

cases, because the compiler cannot do any type checking of the arguments, etc).





In summary: All test cases shown here are invalid, the compiler is not strictly

required to detect this, but we should at least throw a warning where possible

(e.g. comment 0 and 1).

[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files

[karlson2k at gmail dot com]

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



Evgeny Grin  changed:



   What|Removed |Added



 CC||karlson2k at gmail dot com



--- Comment #14 from Evgeny Grin  2013-02-09 
15:03:24 UTC ---

Reconfirming this problem for GCC 4.7.2



Configured with:

../../source/gcc-4.7.2/configure --build=i686-pc-mingw32 --host=i686-pc-mingw32

--target=i686-w64-mingw32 --disable-nls --disable-multilib

--prefix=/home/xxx/mingw-w64/mingw-w64-i686

--with-sysroot=/home/xxx/mingw-w64/mingw-w64-i686

--with-native-system-header-dir=/i686-w64-mingw32/include

--with-host-libstdcxx=/mingw/lib/gcc/mingw32/4.7.2/libstdc++.a

--disable-cloog-version-check --disable-ppl-version-check

--with-mpc=/home/xxx/mingw-w64/packages/gcc/packages/mpc/mpc-1.0.1-i686

--with-mpfr=/home/xxx/mingw-w64/packages/gcc/packages/mpfr/mpfr-3.1.1-i686

--with-gmp=/home/xxx/mingw-w64/packages/gcc/packages/gmp/gmp-5.1.0-i686

--with-ppl=/home/xxx/mingw-w64/packages/gcc/packages/ppl/ppl-1.0-i686

--with-isl=/home/xxx/mingw-w64/packages/gcc/packages/isl/isl-0.11.1-i686

--with-cloog=/home/xxx/mingw-w64/packages/gcc/packages/cloog-ppl/cloog-ppl-0.15.11-i686

--enable-languages=ada,c,c++ --enable-threads=win32

--enable-fully-dynamic-string --disable-sjlj-exceptions

--with-multilib-list=m32 --with-arch=pentium3

--enable-leading-mingw64-underscores --with-dwarf2 --enable-lto

--disable-win32-registry --with-win32-nlsapi=unicode --enable-libstdcxx-debug



Failed at:

rm -rf adainclude

rm -rf adalib

cp -p ../.././gcc/ada/rts adainclude

cp: omitting directory `../.././gcc/ada/rts'

make[1]: *** [gnatlib-plain] Error 1

make[1]: Leaving directory

`/home/xxx/mingw-w64/packages/gcc/build/4.7.2-i686-w64-mingw32/i686-w64-mingw32/libada'

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

[Bug tree-optimization/56264] [4.8 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:557

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 CC||rguenth at gcc dot gnu.org

Summary|ICE in  |[4.8 Regression] ICE in

   |check_loop_closed_ssa_use,  |check_loop_closed_ssa_use,

   |at  |at

   |tree-ssa-loop-manip.c:557   |tree-ssa-loop-manip.c:557



--- Comment #2 from Marek Polacek  2013-02-09 
13:36:55 UTC ---

Started with http://gcc.gnu.org/viewcvs?view=revision&revision=195879

[Bug tree-optimization/56264] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:557

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-09

 CC||mpolacek at gcc dot gnu.org

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #1 from Marek Polacek  2013-02-09 
12:14:45 UTC ---

Confirmed.

[Bug tree-optimization/56264] New: ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:557

[antoine.balestrat at gmail dot com]

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

 Bug #: 56264
   Summary: ICE in check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:557
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antoine.balest...@gmail.com


Using GCC 4.8.0 as of 220130209 :

$ cat check.c
int a, b, c;

void f(void)
{
if(b)
{
for(a = 0; a < 1; a++)
lbl:
c = c && b ? : 0;

c = 0;
goto lbl;
}

if(a)
goto lbl;
}

$ xgcc -w -O2 -funswitch-loops check.c
check.c: In function ‘f’:
check.c:3:6: internal compiler error: in check_loop_closed_ssa_use, at 
tree-ssa-loop-manip.c:557
 void f(void)
  ^
0x9d90f6 check_loop_closed_ssa_use
../../srcdir/gcc/tree-ssa-loop-manip.c:556
0x9dac42 verify_loop_closed_ssa(bool)
../../srcdir/gcc/tree-ssa-loop-manip.c:602
0x83eede execute_function_todo
../../srcdir/gcc/passes.c:1974
0x83f757 execute_todo
../../srcdir/gcc/passes.c:1999
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/56263] [avr] Provide strict address-space checking

[gjl at gcc dot gnu.org]

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



Georg-Johann Lay  changed:



   What|Removed |Added



   Priority|P3  |P5

 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-02-09

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1

[Bug target/56263] New: [avr] Provide strict address-space checking

[gjl at gcc dot gnu.org]

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



 Bug #: 56263

   Summary: [avr] Provide strict address-space checking

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: enhancement

  Priority: P3

 Component: target

AssignedTo: g...@gcc.gnu.org

ReportedBy: g...@gcc.gnu.org

CC: demiurg_...@freemail.ru

Target: avr





Created attachment 29401

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

Test case that shall error with strict address spaces



The intrinsic address spaces introduced with PR49868 are imlemented in such a

way that each address space is a subset of each other.



This allows code like follows to operate as expected and without warnings:



char read_char (const char *address, int data_in_flash)

{

if (data_in_flash)

return *(const __flash char*) address;

else

return *address;

}



Currently, targetm.addr_space_subset_p returns always true in order to allow

pointer casts like above without diagnostics.



avr.c:avr_addr_space_subset_p() could be implemented in such a way, that it

returns true iff the respective ASes are physical subsets of each other, and

not only if their address, regarded as number, are subsets.



In order not to change the current ABI, this can be achieved by a new command

line option like -maddr-space-subset that allows the user to pick the model of

his favor.

[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array

[janus at gcc dot gnu.org]

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



--- Comment #5 from janus at gcc dot gnu.org 2013-02-09 10:17:16 UTC ---

One can play the same game with scalars, where the situation is even more

severe:



module t



  type :: nc

 integer :: n = 1

  end type nc



contains



  subroutine ff(self)

implicit none

class(nc), intent(in) :: self

write (0,*) '  --> content of self%n) is ',self%n

  end subroutine



end module t



program p

  use t

  implicit none

  type(nc) :: c

  procedure(), pointer   :: f => ff



  call ff(c)

  call f(c)



end program p





The dump shows:



  {

struct __class_t_Nc class.1;



class.1._vptr = (struct __vtype_t_Nc * {ref-all}) &__vtab_t_Nc;

class.1._data = &c;

ff (&class.1);

  }

  f (&c);



i.e. we set up a polymorphic temporary for the 'ff' call, which we don't do for

'f' since we don't know that it expects a CLASS argument.



Fixing this for the array case would be possible, if we just use the

'polymorphic' version of the array descriptor everywhere.



In the scalar case, we would have to set up a class container, for every call

to a procedure pointer without interface, which is passed a TYPE or CLASS

argument. This would then in turn mean we have to wrap the argument of the

original function 'ff' in a class container, even if it is TYPE. AFAICS, this

could even mean we need an class container (or array descriptor) for *every*

TYPE(t) variable, which would be a rather dramatic change in implementation

(and in principle also affects pure F95 code).



I sincerely hope that all the test cases in this PR are invalud. One should

check the standard!



Btw, do other compilers handle this stuff?

[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array

[janus at gcc dot gnu.org]

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



--- Comment #4 from janus at gcc dot gnu.org 2013-02-09 10:08:23 UTC ---

Actually I wonder whether the test case is really valid. The problem is: When

declaring the procedure pointer without an interface, we don't know which kind

of argument it expects. Here is a slightly modified variant:



module t



  type :: nc

 integer :: n = 1

  end type nc



contains



  subroutine ff(self)

implicit none

class(nc), intent(in), dimension(:) :: self

write (0,*) '  --> content of self(1)%n) is ',self(1)%n

  end subroutine



end module t



program p

  use t

  implicit none

  type(nc), dimension(1:10) :: c

  procedure(), pointer   :: f => ff



  call ff(c)

  call f(c)



end program p





As the dump shows, we set up a different array descriptor for both cases, since

we don't know that the procedure pointer expects a polymorphic argument:



  {

struct array1_nc parm.2;

struct __class_t_Nc_1_0 class.1;



class.1._vptr = (struct __vtype_t_Nc * {ref-all}) &__vtab_t_Nc;

parm.2.dtype = 297;

parm.2.dim[0].lbound = 1;

parm.2.dim[0].ubound = 10;

parm.2.dim[0].stride = 1;

parm.2.data = (void *) &c[0];

parm.2.offset = -1;

class.1._data = parm.2;

ff (&class.1);

  }

  {

struct array1_nc parm.3;



parm.3.dtype = 297;

parm.3.dim[0].lbound = 1;

parm.3.dim[0].ubound = 10;

parm.3.dim[0].stride = 1;

parm.3.data = (void *) &c[0];

parm.3.offset = -1;

f ((struct nc[0:] *) parm.3.data);

  }

[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array

[janus at gcc dot gnu.org]

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



--- Comment #3 from janus at gcc dot gnu.org 2013-02-09 10:03:06 UTC ---

Fortunately there is a simple workaround: Declaring the procedure pointer as



  procedure(ff), pointer   :: f => ff



makes the segfault go away. The call is then done in the same way as the direct

call to 'ff':



{

  struct __class_t_Nc_1_0 class.2;



  class.2._data = VIEW_CONVERT_EXPR(c._data);

  class.2._vptr = c._vptr;

  f (&class.2);

}

[Bug fortran/55362] [4.6/4.7 Regression] ICE with size() on character pointer

[pault at gcc dot gnu.org]

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



Paul Thomas  changed:



   What|Removed |Added



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

   |ICE with size() on  |with size() on character

   |character pointer   |pointer



--- Comment #5 from Paul Thomas  2013-02-09 09:55:35 
UTC ---

I'll deal with 4.6 and 4.7 tomorrow



Paul

[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



   Keywords||wrong-code

 CC||janus at gcc dot gnu.org

Summary|seg fault call procedure|[OOP] seg fault call

   |pointer on polymorphic  |procedure pointer on

   |array   |polymorphic array



--- Comment #2 from janus at gcc dot gnu.org 2013-02-09 09:52:54 UTC ---

(In reply to comment #1)

>   allocate(c(10))

>   call f(c)



Adding in here a call to "ff(c)", the dump reveals the difference between the

two calls:





  static struct __class_t_Nc_1_0a c = {};

  static void (*) () f = ff;



[..]

__builtin_memset (c._data.data, 0, 40);

c._data.dtype = 297;

c._data.dim[0].lbound = 1;

c._data.dim[0].ubound = 10;

c._data.dim[0].stride = 1;

c._data.offset = -1;

(struct __vtype_t_Nc *) c._vptr = &__vtab_t_Nc;



{

  struct __class_t_Nc_1_0 class.2;



  class.2._data = VIEW_CONVERT_EXPR(c._data);

  class.2._vptr = c._vptr;

  ff (&class.2);

}



f ((struct nc[0:] * restrict) c._data.data);





The first part simply sets up the array descriptor for c after the allocation.

Then comes the call to 'ff' (in curly brackets), which is done correctly

(although I'm not quite sure why the temporary 'class.2' is needed). In the

call to 'f', we wrongly pass c._data.data, while we should rather pass 'c' as a

whole (or with a temporary as in the 'ff' case?).

[Bug fortran/55362] [4.6/4.7/4.8 Regression] ICE with size() on character pointer

[pault at gcc dot gnu.org]

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



--- Comment #4 from Paul Thomas  2013-02-09 09:49:52 
UTC ---

Author: pault

Date: Sat Feb  9 09:49:49 2013

New Revision: 195915



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

Log:

2013-02-09  Paul Thomas  



PR fortran/55362

* check.c (array_check): It is an error if a procedure is

passed.



2013-02-09  Paul Thomas  



PR fortran/55362

* gfortran.dg/intrinsic_size_4.f90 : New test.





Added:

trunk/gcc/testsuite/gfortran.dg/intrinsic_size_4.f90

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/check.c

trunk/gcc/testsuite/ChangeLog

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

[ubizjak at gmail dot com]

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



--- Comment #18 from Uros Bizjak  2013-02-09 09:47:51 
UTC ---

Fixed again on 4.7 branch by #including "output.h" in lto.c.

[Bug target/56256] [4.8 Regression] inline asm with {|} alternatives in it no longer accepted

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #3 from Jakub Jelinek  2013-02-09 
09:31:34 UTC ---

Fixed.

[Bug target/56256] [4.8 Regression] inline asm with {|} alternatives in it no longer accepted

[jakub at gcc dot gnu.org]

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



--- Comment #2 from Jakub Jelinek  2013-02-09 
09:30:49 UTC ---

Author: jakub

Date: Sat Feb  9 09:30:45 2013

New Revision: 195913



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

Log:

PR target/56256

* config/rs6000/rs6000.h (ASSEMBLER_DIALECT): Define.



* gcc.target/powerpc/pr56256.c: New test.



Added:

trunk/gcc/testsuite/gcc.target/powerpc/pr56256.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/rs6000/rs6000.h

trunk/gcc/testsuite/ChangeLog

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

[ubizjak at gmail dot com]

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

--- Comment #17 from Uros Bizjak  2013-02-09 08:17:41 
UTC ---
(In reply to comment #16)
> I didn't notice that my backport to 4.7 caused:
> 
> ../../gcc-svn/branches/gcc-4_7-branch/gcc/lto/lto.c:1060:68: warning: format
> ‘%wx’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long
> unsigned int’ [-Wformat]
> 
> However, "%wx" _is_ correct in this case, and it works for 4.8 without
> problems. 
> 
> Joseph, is there some additional magic that has to be added in lto/lto.c for
> %wx to pass the check?

To answer my own question - we have this typedef in output.h:

/* This is a magic identifier which allows GCC to figure out the type
   of HOST_WIDE_INT for %wd specifier checks.  You must issue this
   typedef before using the __asm_fprintf__ format attribute.  */
typedef HOST_WIDE_INT __gcc_host_wide_int__;

I am testing following additional patch:

--cut here--
Index: lto.c
===
--- lto.c   (revision 195911)
+++ lto.c   (working copy)
@@ -25,6 +25,7 @@
 #include "toplev.h"
 #include "tree.h"
 #include "tree-flow.h"
+#include "output.h"
 #include "diagnostic-core.h"
 #include "tm.h"
 #include "cgraph.h"
--cut here--

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

[ubizjak at gmail dot com]

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

--- Comment #16 from Uros Bizjak  2013-02-09 08:02:22 
UTC ---
I didn't notice that my backport to 4.7 caused:

../../gcc-svn/branches/gcc-4_7-branch/gcc/lto/lto.c:1060:68: warning: format
‘%wx’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long
unsigned int’ [-Wformat]

However, "%wx" _is_ correct in this case, and it works for 4.8 without
problems. 

Joseph, is there some additional magic that has to be added in lto/lto.c for
%wx to pass the check?