[Bug fortran/54597] New: Function can't return string without trailing spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54597 Bug #: 54597 Summary: Function can't return string without trailing spaces Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: don...@lasg.iap.ac.cn I would like to write a function that will return string without trailing spaces, the prototype of the function is as following: module mod contains function foo() character(*), allocatable :: foo character(1000) bar bar = "abc" foo = bar end function foo end module mod program main use mod write(*, *) , foo(), end program main The result of "gfortran" still contains trailing spaces, but "ifort" works as expected.
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 --- Comment #23 from David Edelsohn 2012-09-16 02:36:27 UTC --- I do not see the extraneous symbols using the example in comment #22 when compiling with trunk. Also, the example G++ invocation does not enable any optimizations.
[Bug c++/54596] New: seg fault building Eigen stuff with cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54596 Bug #: 54596 Summary: seg fault building Eigen stuff with cygwin Classification: Unclassified Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dou...@sprynet.com In cygwin, running: /bin/c++.exe -Dtypes_sba_EXPORTS -DCYGWIN -v -save-temps -Wall -W -O3 -DNDEBUG -O3 -msse4 -I/cygdrive/c/Users/Doug/Desktop/gitg2o/g2o -I/cygdrive/c/Users/Doug/Desktop/gitg2o/g2o/build-o CMakeFiles/types_sba.dir/types_sba.cpp.o -c /cygdrive/c/Users/Doug/Desktop/gitg2o/g2o/g2o/types/sba/types_sba.cpp Gives: Using built-in specs. COLLECT_GCC=/bin/c++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.5.3/lto-wrapper.exe Target: i686-pc-cygwin Configured with: /gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3/configure --srcdir=/gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --datarootdir=/usr/share --docdir=/usr/share/doc/gcc4 -C --datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap --enable-version-specific-runtime-libs --libexecdir=/usr/lib --enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite --enable-lto --enable-java-awt=gtk --disable-symvers --enable-libjava --program-suffix=-4 --enable-libgomp --enable-libssp --enable-libada --enable-threads=posix --with-arch=i686 --with-tune=generic --enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake GNATBIND_FOR_TARGET=gnatbind --with-ecj-jar=/usr/share/java/ecj.jar Thread model: posix gcc version 4.5.3 (GCC) COLLECT_GCC_OPTIONS='-Dtypes_sba_EXPORTS' '-DCYGWIN' '-v' '-save-temps' '-Wall' '-W' '-O3' '-DNDEBUG' '-O3' '-msse4' '-I/cygdrive/c/Users/Doug/Desktop/gitg2o/g2o' '-I/cygdrive/c/Users/Doug/Desktop/gitg2o/g2o/build' '-o' 'CMakeFiles/types_sba.dir/types_sba.cpp.o' '-c' '-shared-libgcc' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1plus.exe -E -quiet -v -I/cygdrive/c/Users/Doug/Desktop/gitg2o/g2o -I/cygdrive/c/Users/Doug/Desktop/gitg2o/g2o/build -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/lib/../../include/w32api -Dtypes_sba_EXPORTS -DCYGWIN -DNDEBUG /cygdrive/c/Users/Doug/Desktop/gitg2o/g2o/g2o/types/sba/types_sba.cpp -msse4 -mtune=generic -march=i686 -Wall -W -O3 -O3 -fpch-preprocess -o types_sba.ii ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/include" ignoring duplicate directory "/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/lib/../../include/w32api" #include "..." search starts here: #include <...> search starts here: /cygdrive/c/Users/Doug/Desktop/gitg2o/g2o /cygdrive/c/Users/Doug/Desktop/gitg2o/g2o/build /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++ /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/backward /usr/lib/gcc/i686-pc-cygwin/4.5.3/include /usr/lib/gcc/i686-pc-cygwin/4.5.3/include-fixed /usr/include /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api End of search list. COLLECT_GCC_OPTIONS='-Dtypes_sba_EXPORTS' '-DCYGWIN' '-v' '-save-temps' '-Wall' '-W' '-O3' '-DNDEBUG' '-O3' '-msse4' '-I/cygdrive/c/Users/Doug/Desktop/gitg2o/g2o' '-I/cygdrive/c/Users/Doug/Desktop/gitg2o/g2o/build' '-o' 'CMakeFiles/types_sba.dir/types_sba.cpp.o' '-c' '-shared-libgcc' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1plus.exe -fpreprocessed types_sba.ii -quiet -dumpbase types_sba.cpp -msse4 -mtune=generic -march=i686 -auxbase-strip CMakeFiles/types_sba.dir/types_sba.cpp.o -O3 -O3 -Wall -W -version -o types_sba.s GNU C++ (GCC) version 4.5.3 (i686-pc-cygwin) compiled by GNU C version 4.5.3, GMP version 4.3.2, MPFR version 3.0.1-p4, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (GCC) version 4.5.3 (i686-pc-cygwin) compiled by GNU C version 4.5.3, GMP version 4.3.2, MPFR version 3.0.1-p4, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 2eb50487139b9f2ceb9af473175cad84 In file included from /cygdrive/c/Users/Doug/Desktop/gitg2o/g2o/build/Eigen/Core:306:0, from /cygdrive/c/Users/Doug/Desktop/gitg2o/g2o/g2o/core/jacobian_workspace.h:30,
[Bug debug/54595] New: [4.8 Regression] symbol causes a section type conflict with itself with -O -g -fdata-section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54595 Bug #: 54595 Summary: [4.8 Regression] symbol causes a section type conflict with itself with -O -g -fdata-section Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: bernhard.rosenkran...@linaro.org Created attachment 28198 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28198 Preprocessed source, gzipped because it's huge Compiling llvm with -O -g -fdata-section results in $ /opt/android-toolchain-trunk/bin/arm-linux-androideabi-g++ -O -g -fdata-sections -c FunctionAttrs.i -o out/target/product/maguro/obj/STATIC_LIBRARIES/libLLVMipo_intermediates/FunctionAttrs.o In file included from external/llvm/include/llvm/Argument.h:18:0, from external/llvm/include/llvm/Function.h:24, from external/llvm/include/llvm/Analysis/CallGraph.h:54, from external/llvm/include/llvm/CallGraphSCCPass.h:25, from external/llvm/lib/Transforms/IPO/FunctionAttrs.cpp:23: external/llvm/include/llvm/Attributes.h:113:52: error: llvm::Attribute::ReadOnly causes a section type conflict with llvm::Attribute::ReadOnly DECLARE_LLVM_ATTRIBUTE(ReadOnly,1<<10) ///< Function only reads from memory ^ I haven't tried to isolate the cause/reduce the test case yet; this might be a dupe of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53475
[Bug fortran/54594] [OOP] Type-bound ASSIGNMENTs (elemental + array version) rejected as ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54594 --- Comment #5 from janus at gcc dot gnu.org 2012-09-15 21:53:49 UTC --- (In reply to comment #4) > Regtesting now ... ... finished without failures.
[Bug fortran/54594] [OOP] Type-bound ASSIGNMENTs (elemental + array version) rejected as ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54594
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 #4 from janus at gcc dot gnu.org 2012-09-15 21:02:17 UTC ---
Apparently the problem is that gfc_compare_types does not handle CLASS arrays
properly. The following patch should fix it (it makes gfortran accept the test
case):
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c(revision 191303)
+++ gcc/fortran/interface.c(working copy)
@@ -507,14 +507,18 @@ gfc_compare_types (gfc_typespec *ts1, gfc_typespec
static int
compare_type_rank (gfc_symbol *s1, gfc_symbol *s2)
{
+ gfc_array_spec *as1, *as2;
int r1, r2;
- r1 = (s1->as != NULL) ? s1->as->rank : 0;
- r2 = (s2->as != NULL) ? s2->as->rank : 0;
+ as1 = (s1->ts.type == BT_CLASS) ? CLASS_DATA (s1)->as : s1->as;
+ as2 = (s2->ts.type == BT_CLASS) ? CLASS_DATA (s2)->as : s2->as;
+ r1 = as1 ? as1->rank : 0;
+ r2 = as2 ? as2->rank : 0;
+
if (r1 != r2
- && (!s1->as || s1->as->type != AS_ASSUMED_RANK)
- && (!s2->as || s2->as->type != AS_ASSUMED_RANK))
+ && (!as1 || as1->type != AS_ASSUMED_RANK)
+ && (!as2 || as2->type != AS_ASSUMED_RANK))
return 0;/* Ranks differ. */
return gfc_compare_types (&s1->ts, &s2->ts)
Regtesting now ...
[Bug target/54593] [missed-optimization] Move from SSE to integer register goes through the stack without -march=native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54593 --- Comment #6 from sgunderson at bigfoot dot com 2012-09-15 20:28:02 UTC --- Ah. So basically it hurts AMD enough (the opposite doesn't hit Intel enough) that the choice was made to make it that way generic too. Well, as long as it's a deliberate choice, I assume it's a reasonable tradeoff, so thanks for the enlightenment. :-)
[Bug target/54593] [missed-optimization] Move from SSE to integer register goes through the stack without -march=native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54593 --- Comment #5 from H.J. Lu 2012-09-15 20:17:24 UTC --- (In reply to comment #4) > I'm not sure if I understand the comment very well; it talks about Pentium 4, > but none of them run 64-bit code, do they? Wrong quote. It should be /* X86_TUNE_INTER_UNIT_MOVES */ ~(m_AMD_MULTIPLE | m_GENERIC),
[Bug fortran/54594] [OOP] Type-bound ASSIGNMENTs (elemental + array version) rejected as ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54594 --- Comment #3 from janus at gcc dot gnu.org 2012-09-15 20:05:53 UTC --- (In reply to comment #2) > Note: The same error appears also for a non-typebound generic interface: ... also if the second argument 'in' is removed from both procedures. However, the test case is accepted if the CLASS declarations are changed to TYPE: module a_mod type :: a end type interface ass procedure :: a_ass, a_ass_sv end interface contains impure elemental subroutine a_ass (out) type(a), intent(out) :: out end subroutine subroutine a_ass_sv (out) type(a), intent(out) :: out(:) end subroutine end module
[Bug libstdc++/54591] sscanf format no more working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54591 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Andreas Schwab 2012-09-15 19:03:44 UTC --- libstdc++ is not glibc.
[Bug libstdc++/54591] sscanf format no more working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54591 Uenal Mutlu changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Component|c++ |libstdc++ Resolution|INVALID | Severity|normal |critical --- Comment #2 from Uenal Mutlu 2012-09-15 18:58:25 UTC --- moving the bugreport to libstdc++.
[Bug fortran/54594] [OOP] Type-bound ASSIGNMENTs (elemental + array version) rejected as ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54594 --- Comment #2 from janus at gcc dot gnu.org 2012-09-15 18:46:06 UTC --- Note: The same error appears also for a non-typebound generic interface: module a_mod type :: a end type interface ass procedure :: a_ass, a_ass_sv end interface contains impure elemental subroutine a_ass (out, in) class(a), intent(out) :: out type(a), intent(in) :: in end subroutine subroutine a_ass_sv (out, in) class(a), intent(out) :: out(:) type(a), intent(in) :: in end subroutine end module
[Bug fortran/54594] [OOP] Type-bound ASSIGNMENTs (elemental + array version) rejected as ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54594 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-15 Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2012-09-15 18:39:40 UTC --- Here is a reduced version of the test case: module a_mod type :: a contains procedure, NOPASS :: a_ass, a_ass_sv generic :: assignment(=) => a_ass, a_ass_sv end type contains impure elemental subroutine a_ass (out, in) class(a), intent(out) :: out type(a), intent(in) :: in end subroutine subroutine a_ass_sv (out, in) class(a), intent(out) :: out(:) type(a), intent(in) :: in end subroutine end module
[Bug fortran/54224] [4.8 Regression] Bogus -Wunused-function warning with static function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54224 --- Comment #10 from janus at gcc dot gnu.org 2012-09-15 18:26:27 UTC --- (In reply to comment #8) > > Here is a patch which should set TREE_USED for all procedure calls: > > Does it still allow to optimize unused PRIVATE module procedures away? I think so. conv_function_val is only called by gfc_conv_procedure_call. If the procedure is really not used, then gfc_conv_procedure_call will not be called, and thus also TREE_USED will not be set. Moreover, the patchlet in comment 7 seems to be free of testsuite regressions.
[Bug fortran/54594] New: [OOP] Type-bound ASSIGNMENTs (elemental + array version) rejected as ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54594 Bug #: 54594 Summary: [OOP] Type-bound ASSIGNMENTs (elemental + array version) rejected as ambiguous 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 CC: ja...@gcc.gnu.org Created attachment 28197 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28197 generic_defined_assignment.f90 (Note, I haven't checked whether the following bug report is valid.= The following program by James Van Buskirk compiles with Cray ftn and prints: Explicit calls: Overloaded Overloaded Overloaded Implicit calls: Overloaded array->array Overloaded scalar->array Overloaded However, it fails with gfortran with the error: generic :: assignment(=) => a_ass 1 Error: 'a_ass' and 'a_ass_sv' for GENERIC '=' at (1) are ambiguous Note for the defined assignment, you need the patch for PR46897, cf. http://gcc.gnu.org/ml/fortran/2012-09/msg00034.html See also discussion at https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/5eAz5ns6AG0
[Bug c++/54580] 64-bit pointer to int cast fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54580 --- Comment #3 from Jonathan Wakely 2012-09-15 17:57:52 UTC --- Or strictly, should be rejected by any 64-bit compiler with 32-bit int (which is practically all of them) and any 32-bit compiler with 16-bit short. Certainly invalid for g++ on LP64 platforms.
[Bug c++/54580] 64-bit pointer to int cast fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54580
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #2 from Jonathan Wakely 2012-09-15
17:52:43 UTC ---
That explicit type conversion (i.e. cast) is equivalent to
reinterpret_cast("") and the standard says reinterpret_cast can be used to
convert a pointer to an integer type large enough to hold it. The code is
invalid and should be rejected by any 64-bit C++ compiler, just as (short)""
should be by 32-bit compilers.
[Bug fortran/54224] [4.8 Regression] Bogus -Wunused-function warning with static function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54224 --- Comment #8 from Tobias Burnus 2012-09-15 17:47:37 UTC --- (In reply to comment #7) > Here is a patch which should set TREE_USED for all procedure calls: Does it still allow to optimize unused PRIVATE module procedures away?
[Bug fortran/54224] [4.8 Regression] Bogus -Wunused-function warning with static function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54224 janus at gcc dot gnu.org changed: What|Removed |Added Component|middle-end |fortran --- Comment #7 from janus at gcc dot gnu.org 2012-09-15 17:41:29 UTC --- (In reply to comment #6) > * It seems as if the TREE_USED part should be handled on the Fortran FE side > for both (PRIVATE) module variables and module procedures Here is a patch which should set TREE_USED for all procedure calls: Index: gcc/fortran/trans-expr.c === --- gcc/fortran/trans-expr.c(revision 191303) +++ gcc/fortran/trans-expr.c(working copy) @@ -2455,6 +2455,8 @@ conv_function_val (gfc_se * se, gfc_symbol * sym, if (!sym->backend_decl) sym->backend_decl = gfc_get_extern_function_decl (sym); + TREE_USED (sym->backend_decl) = 1; + tmp = sym->backend_decl; if (sym->attr.cray_pointee) It makes the bogus warning on comment 0 go away.
[Bug target/54593] [missed-optimization] Move from SSE to integer register goes through the stack without -march=native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54593 --- Comment #4 from sgunderson at bigfoot dot com 2012-09-15 16:54:28 UTC --- I'm not sure if I understand the comment very well; it talks about Pentium 4, but none of them run 64-bit code, do they?
[Bug target/54593] [missed-optimization] Move from SSE to integer register goes through the stack without -march=native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54593 --- Comment #3 from Andrew Pinski 2012-09-15 16:50:31 UTC --- (In reply to comment #2) > Interesting. So it's a conscious choice that “generic” does this? Yes: /* X86_TUNE_SSE_PARTIAL_REG_DEPENDENCY: In the Generic model we have a conflict here in between PPro/Pentium4 based chips that thread 128bit SSE registers as single units versus K8 based chips that divide SSE registers to two 64bit halves. This knob promotes all store destinations to be 128bit to allow register renaming on 128bit SSE units, but usually results in one extra microop on 64bit SSE units. Experimental results shows that disabling this option on P4 brings over 20% SPECfp regression, while enabling it on K8 brings roughly 2.4% regression that can be partly masked by careful scheduling of moves. */ m_PPRO | m_P4_NOCONA | m_CORE2I7 | m_ATOM | m_AMDFAM10 | m_BDVER | m_GENERIC,
[Bug c++/54588] Improved error messages by dropping out types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54588 --- Comment #1 from Andrew Pinski 2012-09-15 16:46:55 UTC --- We just were adding the types lately.
[Bug c++/54591] sscanf format no more working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54591 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Severity|critical|normal --- Comment #1 from Andrew Pinski 2012-09-15 16:45:56 UTC --- GCC is not involved here but rather the library glibc is what is different. Make sure you are doing something which is valid C/C++ before submitting it to glibc.
[Bug target/54593] [missed-optimization] Move from SSE to integer register goes through the stack without -march=native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54593 --- Comment #2 from sgunderson at bigfoot dot com 2012-09-15 16:38:34 UTC --- Interesting. So it's a conscious choice that “generic” does this?
[Bug target/54593] [missed-optimization] Move from SSE to integer register goes through the stack without -march=native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54593 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski 2012-09-15 16:35:43 UTC --- This depends on the actually x86 processor. On AMD processors, it is better to go through memory than going direct.
[Bug target/54593] New: [missed-optimization] Move from SSE to integer register goes through the stack without -march=native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54593
Bug #: 54593
Summary: [missed-optimization] Move from SSE to integer
register goes through the stack without -march=native
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sgunder...@bigfoot.com
Hi,
I have reproduced this on 4.4, 4.6, 4.7 and 4.8 (Debian 20120820-1, trunk
version 190537). Given the following code:
#include
int test1(__m128i v) {
return _mm_cvtsi128_si32(v);
}
GCC generates
0:66 0f 7e 44 24 f4movd %xmm0,-0xc(%rsp)
6:8b 44 24 f4 mov-0xc(%rsp),%eax
a:c3 retq
Shouldn't it go directly to %eax instead of through the stack? Granted, on
Netburst this takes ten cycles or so, but this is x86-64. It appears to be some
sort of tuning issue, since if I use -mtune=native (I am on an Atom) I get:
0:66 0f 7e c0 movd %xmm0,%eax
4:90 nop
5:90 nop
6:90 nop
7:90 nop
8:90 nop
9:90 nop
a:c3 retq
which is sort-of what I expect. Well, the NOPs are a bit weird, but... :-)
[Bug target/42778] Superfluous stack management code is generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42778 sgunderson at bigfoot dot com changed: What|Removed |Added CC||sgunderson at bigfoot dot ||com --- Comment #3 from sgunderson at bigfoot dot com 2012-09-15 16:02:37 UTC --- This seems to be no longer wrong in 4.8.
[Bug target/54222] [avr] Implement fixed-point support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54222 --- Comment #6 from Georg-Johann Lay 2012-09-15 15:52:35 UTC --- Author: gjl Date: Sat Sep 15 15:52:28 2012 New Revision: 191345 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191345 Log: gcc/ PR target/54222 * config/avr/avr-fixed.md (ALL2S, ALL4S, ALL24S, ALL124S, ALL124U): New mode iterators. (3): New insns for SS_PLUS, SS_MINUS. (3): New insns for US_PLUS, US_MINUS. (usneg2): New insns. (2): New expanders for SS_NEG, SS_ABS. (*2): New insns for SS_NEG, SS_ABS. * config/avr/avr-dimode.md (ALL8U, ALL8S): New mode iterators. (avr_out_plus64, avr_out_minus64): Use avr_out_plus instead. (3): New expanders for SS_PLUS, SS_MINUS. (3): New expanders for US_PLUS, US_MINUS. (3_insn): New insns. (3_const_insn): New insns. * config/avr/avr.md (cc): Add: plus. Remove: out_plus, out_plus_noclobber, minus. (length): Add: plus. Remove: out_plus, out_plus_noclobber, plus64, minus, minus64. (abelian): New code_attr. (code_stdname): Handle: ss_plus, ss_minus, ss_neg, ss_abs, us_plus, us_minus, us_neg. (*add3, add3_clobber, add3, addpsi3, sub3): Use avr_out_plus to output. * config/avr/avr-protos.h (avr_out_plus): Change prototype. (avr_out_plus_noclobber, avr_out_minus): Remove. (avr_out_plus64, avr_out_minus64): Remove. * config/avr/avr.c (avr_out_plus_1): Add new default arguments code_sat, sign. Saturate after operation if code_sat != UNKNOWN. (avr_out_plus_symbol): New static function. (avr_out_plus): Rewrite. (adjust_insn_length): Handle: ADJUST_LEN_PLUS. Remove handling of: ADJUST_LEN_OUT_PLUS, ADJUST_LEN_PLUS64, ADJUST_LEN_MINUS, ADJUST_LEN_MINUS64, ADJUST_LEN_OUT_PLUS_NOCLOBBER. (notice_update_cc): Handle: CC_PLUS. Remove handling of: CC_MINUS, CC_OUT_PLUS, CC_OUT_PLUS_NOCLOBBER (avr_out_plus_noclobber, avr_out_minus): Remove. (avr_out_plus64, avr_out_minus64): Remove. (avr_print_operand): Print raw REGNO if 'r' is used with REG. libgcc/ PR target/54222 * config/avr/lib1funcs-fixed.S (__ssneg_2, __ssabs_2, __ssneg_4, __ssabs_4, __clr_8, __ssneg_8, __ssabs_8, __usadd_8, __ussub_8, __ssadd_8, __sssub_8): New functions. (__divsa3): Use __negsi2 to negate r_quoL. * config/avr/lib1funcs.S (FALIAS): New macro. (__divmodsi4): Break out and use __divmodsi4_neg1 as... (__negsi2): ...this new function. * config/avr/t-avr (LIB1ASMFUNCS): Add _negsi2, _clr_8, _ssneg_2, _ssneg_4, _ssneg_8, _ssabs_2, _ssabs_4, _ssabs_8, _ssadd_8, _sssub_8, _usadd_8, _ussub_8. (LIB2FUNCS_EXCLUDE): Fix typo for _add _sub. Add: _ssadd*, _sssub*, _ssneg*, _ssabs* for signed fixed modes. Add: _usadd*, _ussub*, _usneg* for unsigned fixed modes. gcc/testsuite/ PR target/54222 * gcc.target/avr/torture/fix-types.h: New. * gcc.target/avr/torture/vals-hr.def: New. * gcc.target/avr/torture/vals-r.def: New. * gcc.target/avr/torture/vals-k.def: New. * gcc.target/avr/torture/vals-ur.def: New. * gcc.target/avr/torture/vals-uk.def: New. * gcc.target/avr/torture/vals-uhr.def: New. * gcc.target/avr/torture/vals-llk.def: New. * gcc.target/avr/torture/vals-ullk.def: New. * gcc.target/avr/torture/sat-hr-plus-minus.c: New. * gcc.target/avr/torture/sat-r-plus-minus.c: New. * gcc.target/avr/torture/sat-k-plus-minus.c: New. * gcc.target/avr/torture/sat-ur-plus-minus.c: New. * gcc.target/avr/torture/sat-uk-plus-minus.c: New. * gcc.target/avr/torture/sat-uhr-plus-minus.c: New. * gcc.target/avr/torture/sat-llk-plus-minus.c: New. * gcc.target/avr/torture/sat-ullk-plus-minus.c: New. Added: trunk/gcc/testsuite/gcc.target/avr/torture/fix-types.h trunk/gcc/testsuite/gcc.target/avr/torture/sat-hr-plus-minus.c trunk/gcc/testsuite/gcc.target/avr/torture/sat-k-plus-minus.c trunk/gcc/testsuite/gcc.target/avr/torture/sat-llk-plus-minus.c trunk/gcc/testsuite/gcc.target/avr/torture/sat-r-plus-minus.c trunk/gcc/testsuite/gcc.target/avr/torture/sat-uhr-plus-minus.c trunk/gcc/testsuite/gcc.target/avr/torture/sat-uk-plus-minus.c trunk/gcc/testsuite/gcc.target/avr/torture/sat-ullk-plus-minus.c trunk/gcc/testsuite/gcc.target/avr/torture/sat-ur-plus-minus.c trunk/gcc/testsuite/gcc.target/avr/torture/vals-hr.def trunk/gcc/testsuite/gcc.target/avr/torture/vals-k.def trunk/gcc/testsuite/gcc.target/avr/torture/vals-llk.def trunk/gcc/testsuite/gcc.target/avr/torture/vals-r.def trunk/gcc/testsuite/gcc.target/avr/torture/vals-uhr.def trunk/gcc/testsuite/gcc.target/avr/torture/vals-uk.def trunk/gcc/testsuite/gcc.target/avr/torture/vals-ullk.def trunk/gcc/testsuite/gcc.target/avr/torture/vals-ur.def Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-dimode.md trunk/gcc/config/avr/avr-fixed.md trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/
[Bug tree-optimization/54592] New: [4.8 Regression] [missed-optimization] Cannot fuse SSE move and add together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54592
Bug #: 54592
Summary: [4.8 Regression] [missed-optimization] Cannot fuse SSE
move and add together
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sgunder...@bigfoot.com
Hi,
I have, on x86-64,
gcc version 4.7.1 (Debian 4.7.1-9)
gcc version 4.8.0 20120820 (experimental) [trunk revision 190537] (Debian
20120820-1)
Given the following test program:
#include
void func(__m128i *foo, size_t a, size_t b, int *dst)
{
__m128i x = foo[a];
__m128i y = foo[b];
__m128i sum = _mm_add_epi32(x, y);
*dst = _mm_cvtsi128_si32(sum);
}
GCC 4.8 with -O2 compiles it to
0:48 c1 e6 04 shl$0x4,%rsi
4:48 c1 e2 04 shl$0x4,%rdx
8:66 0f 6f 0c 17 movdqa (%rdi,%rdx,1),%xmm1
d:66 0f 6f 04 37 movdqa (%rdi,%rsi,1),%xmm0
12:66 0f fe c1 paddd %xmm1,%xmm0
16:66 0f 7e 01 movd %xmm0,(%rcx)
1a:c3 retq
The mov into %xmm1 here doesn't seem to make sense; it should rather be
paddd-ed in directly. And indeed, GCC 4.7 with -O2 gets this right:
0:48 c1 e6 04 shl$0x4,%rsi
4:48 c1 e2 04 shl$0x4,%rdx
8:66 0f 6f 04 37 movdqa (%rdi,%rsi,1),%xmm0
d:66 0f fe 04 17 paddd (%rdi,%rdx,1),%xmm0
12:66 0f 7e 01 movd %xmm0,(%rcx)
16:c3 retq
This would seem like a regression to me.
[Bug c++/54590] Incorrect multi-inheritence bases layout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54590 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andreas Schwab 2012-09-15 15:02:12 UTC --- The first word contains a pointer to the vtable for X.
[Bug c++/54591] New: sscanf format no more working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54591
Bug #: 54591
Summary: sscanf format no more working
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: temp78...@mutluit.com
sscanf no more working, it was ok in prev. versions:
#include
#include
int main()
{
const char*psz = " PROTO=TCP SPT=6004 DPT=26532 ";
char szProto[256] = "";
unsigned short usSrcPort = 0, usDstPort = 0;
const int c = sscanf(psz, " PROTO=%255[^ \t\n]s SPT=%hu DPT=%hu", szProto,
&usSrcPort, &usDstPort);
printf("%s\n", c == 3 ? "OK" : "ERROR");
//...
return 0;
}
It fills only the first field --> c=1 --> ERROR
This code was working fine in prev. compiler versions.
# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.1-2'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.1 (Debian 4.7.1-2)
[Bug c++/54590] New: Incorrect multi-inheritence bases layout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54590
Bug #: 54590
Summary: Incorrect multi-inheritence bases layout
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wingf...@gmail.com
the code:
#include
struct A{ virtual void foo() {} };
struct B { void * data; };
struct X : public B, A { };
int main(){
X x;
if((void*)&x == (void*)(&x.data))
std::cout << "correct\n";
else
std::cout << "oops...\n";
return 0;
}
Expect:
print "correct"
Result:
print "oops..."
Notes:
if A::foo is not virtual, the result is correct.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #141 from Markus Trippelsdorf 2012-09-15 14:05:38 UTC --- After the new IonMonkey JIT went in (http://blog.mozilla.org/javascript/2012/09/12/ionmonkey-in-firefox-18/) peak memory use went up. It is now 6.8GB (gcc-4.7 roughly the same: 6.5GB). So we're approaching the point where a 8GB machine isn't enough to build Firefox with LTO...
[Bug tree-optimization/54589] New: [missed-optimization] struct offset add should be folded into address calculation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589
Bug #: 54589
Summary: [missed-optimization] struct offset add should be
folded into address calculation
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sgunder...@bigfoot.com
Hi,
I found this in 4.4 (Ubuntu 10.04), and have confirmed it's still there in
gcc (Debian 20120820-1) 4.8.0 20120820 (experimental) [trunk revision 190537]
This code:
#include
struct param {
int a, b, c, d;
__m128i array[256];
};
void func(struct param *p, unsigned char *src, int *dst)
{
__m128i x = p->array[*src];
*dst = _mm_cvtsi128_si32(x);
}
compiles with -O2 on x86-64 to this assembler:
:
0:0f b6 06 movzbl (%rsi),%eax
3:48 83 c0 01 add$0x1,%rax
7:48 c1 e0 04 shl$0x4,%rax
b:8b 04 07 mov(%rdi,%rax,1),%eax
e:89 02mov%eax,(%rdx)
10:c3 retq
The add should be folded into the address calculation here. (The shl can't,
because it's too big.) Curiously enough, if I misalign the struct element by
removing c and d, and declaring the struct __attribute__((packed)), GCC will do
that; the mov will then be from $8(%rdi,%rax,1),%eax and there is no redundant
add.
[Bug fortran/36825] [F2008] Rank > 7 arrays [will break library ABI] libgfortran I/O+intrinsics:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36825
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #12 from Tobias Burnus 2012-09-15
13:09:15 UTC ---
We also need to update dwarf2out.h, which has:
266struct array_descr_info
267{
268 int ndimensions;
269 tree element_type;
270 tree base_decl;
271 tree data_location;
272 tree allocated;
273 tree associated;
274 struct array_descr_dimen
275{
276 tree lower_bound;
277 tree upper_bound;
278 tree stride;
279} dimen[10];
280};
Thus, GCC limits the maximal rank to 10.
[Bug c++/54588] New: Improved error messages by dropping out types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54588 Bug #: 54588 Summary: Improved error messages by dropping out types Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: kalle_ruta...@hotmail.com Hi, This is a suggestion for a new kind of error reporting in g++, to improve the usability of g++ with template-heavy programming. The idea is summarized as Do not report any type information; report in terms of objects. Motivation -- The currently emitted error-messages are unacceptable because * a single error, such as a missing conversion between types, may result in hundreds of lines of error message, and * it is hard to sift out the error-type and error-location from that message (the main content of the error-message). Experience in template programming shows that the specific root of the problem lies in the abundance of reported type-information. Paradoxically, that type-information normally has a very low information-density for the programmer. While sometimes that information is needed, most of the time it isn't. Example --- A a; int b = a; Current: test.cpp:9:10: error: cannot convert 'A' to 'int' in initialization. Suggested: test.cpp:9:10: error: cannot convert 'a' to 'b' in initialization. Here one should imagine, for the readability of this post, some 500+ character-type in place of the VeryComplicatedType, and possibly additional such template parameters for A. Note that no type-information is reported, and that errors are reported in terms of objects. Conclusion -- Currently, the emitted error-messages report a maximal amount of information. This post suggests to make available a new option to report a minimal amount of information by not reporting type-information, and to report in terms of objects instead. Kalle
[Bug c/51840] asm goto enhancement request
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51840
--- Comment #4 from Timo Kreuzer 2012-09-15
12:16:38 UTC ---
Update: I fought a bit with GCC and made clear that my Kung Fu is better than
GCC's ;-)
I solved this issue with a workaround. I forced a number of constraints upon
GCC, that made it cry and stop shuffling the code around. These constraints
will make certain optimizations by moving code around useless, so assuming that
gcc will do the right thing, it won't move code onto pathes between the asm
goto and the actual label address.
So here's my code:
int
example1(int param)
{
int value = 0;
if (param > 2)
{
label1:
asm goto ("movl %0, %%ecx\n\tjmp %l[label3]\n" : : "i"(&&label3) :
"ecx" : label3, labelx);
}
value = 1;
if (param > 1)
{
label2:
asm goto ("movl %0, %%ecx\n\tjmp %l[label3]\n" : : "i"(&&label3) :
"ecx" : label3, labelx);
}
value = 2;
label3:
return value;
labelx:(void)0;
void *plabel;
asm volatile ("#" : "=a"(plabel) : "p"(&&label1), "p"(&&label2),
"p"(&&label3), "p"(&&labelx) : "memory");
goto *plabel;
}
Almost the same as before, with exception to the additional labelx construct.
First the asm instruction makes GCC think the addresses of all the labels might
be used here and after it we have plabel being eax containing something that
GCC doesn't know anything about.
The goto basically tells GCC that there are pathes between these labels.
GCC won't insert any "lazy" evaluation of constants into a codepath between
label1 and the static label3 address, because due to the additional asm goto
reference to labelx, it would need to add this code in the path between label1
and labelx as well. But since there is a virtual goto from labelx back to
label1, it would put the code into the inner of a loop, which it will try to
avoid.
Anyway this is a huge hack and works rather on the principle of good faith,
than on hard specifications.
Maybe someone finds an approach that is proovable to result in the right thing.
Or some gcc dev does the right thing and fixes asm goto.
[Bug c/3885] Incorrect "invalid suffix on integer constant" error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3885 Andreas Schwab changed: What|Removed |Added CC||bratsinot at gmail dot com --- Comment #11 from Andreas Schwab 2012-09-15 12:02:04 UTC --- *** Bug 54587 has been marked as a duplicate of this bug. ***
[Bug c/54587] Error with constant in arithmetic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54587 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Andreas Schwab 2012-09-15 12:02:04 UTC --- . *** This bug has been marked as a duplicate of bug 3885 ***
[Bug c/54587] New: Error with constant in arithmetic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54587
Bug #: 54587
Summary: Error with constant in arithmetic
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bratsi...@gmail.com
If i enter:
> printf("%x", 0x404e-0x4043);
GCC give me error:
> test.c: In function ‘main’:
> test.c:164:15: error: invalid suffix "-0x4043" on integer constant
If write:
> printf("%x", 0x404e - 0x4043);
everything all right.
[Bug fortran/54572] Use libbacktrace library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #1 from Hans-Peter Nilsson 2012-09-15 11:25:35 UTC --- You need unwind frames present for this to work, i.e. the space (and to some extent optimization-reducing - yes I'm sure) overhead of -funwind-tables. (Only x86_64 has this on, effectively.)
[Bug rtl-optimization/54540] [4.8 regression] postreload incorrectly simplifies stack adjustment into constant load into SP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54540 --- Comment #4 from Richard Earnshaw 2012-09-15 09:57:34 UTC --- (In reply to comment #3) > Author: rearnsha > Date: Fri Sep 14 17:10:45 2012 > New Revision: 191307 > Has probably made the post-reload issues go latent again.
[Bug target/54516] [4.8 regression] ICE in reload_cse_simplify_operands, at postreload.c:403 with -O1 -march=armv7-a -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54516 Richard Earnshaw changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Richard Earnshaw 2012-09-15 09:55:12 UTC --- Fixed
[Bug target/50256] AVR GCC - several unnecessary register moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50256 Georg-Johann Lay changed: What|Removed |Added Status|WAITING |RESOLVED Last reconfirmed|2011-09-01 00:00:00 | Resolution||INVALID --- Comment #7 from Georg-Johann Lay 2012-09-15 09:29:46 UTC --- Closed. There is still no test case for over one year now.
[Bug other/54500] While(TRUE) loop optimization of global struct variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54500 Georg-Johann Lay changed: What|Removed |Added Target|avr-* |avr Last reconfirmed|2012-09-06 00:00:00 | Component|c |other Build|WinAVR 20081205 | Severity|major |normal
[Bug c++/54575] [4.8 Regression] ICE with std::vector::insert and -std=c++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54575 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug tree-optimization/54525] Recognize (vec_)cond_expr in mask operation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54525 --- Comment #1 from Marc Glisse 2012-09-15 08:28:08 UTC --- (In reply to comment #0) > vpcmpgtq%xmm2, %xmm3, %xmm2 > vpcmpeqd%xmm3, %xmm3, %xmm3 [...] > (also notice that for some reason all comparisons (I tried < <= > >= and even > with a ~ in front) generate a combination of gt and eq, never just gt) Hmm, that remark was nonsense, the eq has nothing to do with the gt, it is just the way the compiler generates a constant -1 vector so it can then xor with it to compute a ~.
[Bug middle-end/54315] Unnecessary copy of return value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54315 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #4 from Eric Botcazou 2012-09-15 08:23:41 UTC --- I'll try to improve things on x86-64 at least.
[Bug testsuite/53739] FAIL: g++.dg/init/null1.C -std=c++11 happens even though it should not be tested
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53739 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski 2012-09-15 07:16:54 UTC --- This was due to my board not doing: process_multilib_options ""
[Bug driver/53002] Request new specs string token for multilib_os_dir
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53002 --- Comment #4 from Steven Drake 2012-09-15 07:13:36 UTC --- (In reply to comment #3) > Patch commited in svn id 87775. Correction that should be svn id 187775
