[Bug bootstrap/56258] Please upgrade doc/*.texi to the latest texinfo package(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56258 --- Comment #11 from Denis Excoffier 2013-03-10 08:06:54 UTC --- Please to find someone able to apply the above patches on branches 4.6 and 4.7?
[Bug target/56561] Miscompilation with -Os -arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56561 Mike Hommey changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #5 from Mike Hommey 2013-03-10 09:20:05 UTC --- Thanks for tracking it down. *** This bug has been marked as a duplicate of bug 48308 ***
[Bug target/48308] [4.6/4.7/4.8 Regression] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 Mike Hommey changed: What|Removed |Added CC||mh+gcc at glandium dot org --- Comment #24 from Mike Hommey 2013-03-10 09:20:05 UTC --- *** Bug 56561 has been marked as a duplicate of this bug. ***
[Bug libstdc++/56587] New: [4.8 regression] libstdc++-abi/abi_check fails for powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56587 Bug #: 56587 Summary: [4.8 regression] libstdc++-abi/abi_check fails for powerpc Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: sch...@linux-m68k.org Target: powerpc*-*-* For -m32: 3 added symbols 0 _ZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEj std::__detail::_Prime_rehash_policy::_M_next_bkt(unsigned int) const version status: compatible GLIBCXX_3.4.18 type: function status: added 1 _ZNKSt8__detail20_Prime_rehash_policy14_M_need_rehashEjjj std::__detail::_Prime_rehash_policy::_M_need_rehash(unsigned int, unsigned int, unsigned int) const version status: compatible GLIBCXX_3.4.18 type: function status: added 2 _ZNSt11this_thread11__sleep_forENSt6chrono8durationIxSt5ratioILx1ELx1NS1_IxS2_ILx1ELx10 std::this_thread::__sleep_for(std::chrono::duration >, std::chrono::duration >) version status: compatible GLIBCXX_3.4.18 type: function status: added 3 missing symbols 0 _ZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEm std::__detail::_Prime_rehash_policy::_M_next_bkt(unsigned long) const version status: unversioned type: function status: subtracted 1 _ZNSt11this_thread11__sleep_forENSt6chrono8durationIlSt5ratioILl1ELl1NS1_IlS2_ILl1ELl10 std::this_thread::__sleep_for(std::chrono::duration >, std::chrono::duration >) version status: unversioned type: function status: subtracted 2 _ZNKSt8__detail20_Prime_rehash_policy14_M_need_rehashEmmm std::__detail::_Prime_rehash_policy::_M_need_rehash(unsigned long, unsigned long, unsigned long) const version status: unversioned type: function status: subtracted 2 undesignated symbols 0 _ZSt11__once_call std::__once_call version status: compatible GLIBCXX_3.4.11 type: tls type size: 4 status: undesignated 1 _ZSt15__once_callable std::__once_callable version status: compatible GLIBCXX_3.4.11 type: tls type size: 4 status: undesignated 3 incompatible symbols 0 _ZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEm std::__detail::_Prime_rehash_policy::_M_next_bkt(unsigned long) const version status: unversioned type: function status: subtracted 1 _ZNSt11this_thread11__sleep_forENSt6chrono8durationIlSt5ratioILl1ELl1NS1_IlS2_ILl1ELl10 std::this_thread::__sleep_for(std::chrono::duration >, std::chrono::duration >) version status: unversioned type: function status: subtracted 2 _ZNKSt8__detail20_Prime_rehash_policy14_M_need_rehashEmmm std::__detail::_Prime_rehash_policy::_M_need_rehash(unsigned long, unsigned long, unsigned long) const version status: unversioned type: function status: subtracted For -m64: 3 added symbols 0 _ZNSt11this_thread11__sleep_forENSt6chrono8durationIlSt5ratioILl1ELl1NS1_IlS2_ILl1ELl10 std::this_thread::__sleep_for(std::chrono::duration >, std::chrono::duration >) version status: compatible GLIBCXX_3.4.18 type: function status: added 1 _ZNKSt8__detail20_Prime_rehash_policy14_M_need_rehashEmmm std::__detail::_Prime_rehash_policy::_M_need_rehash(unsigned long, unsigned long, unsigned long) const version status: compatible GLIBCXX_3.4.18 type: function status: added 2 _ZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEm std::__detail::_Prime_rehash_policy::_M_next_bkt(unsigned long) const version status: compatible GLIBCXX_3.4.18 type: function status: added 3 missing symbols 0 _ZNKSt8__detail20_Prime_rehash_policy14_M_need_rehashEjjj std::__detail::_Prime_rehash_policy::_M_need_rehash(unsigned int, unsigned int, unsigned int) const version status: unversioned type: function status: subtracted 1 _ZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEj std::__detail::_Prime_rehash_policy::_M_next_bkt(unsigned int) const version status: unversioned type: function status: subtracted 2 _ZNSt11this_thread11__sleep_forENSt6chrono8durationIxSt5ratioILx1ELx1NS1_IxS2_ILx1ELx10 std::this_thread::__sleep_for(std::chrono::duration >, std::chrono::duration >) version status: unversioned type: function status: subtracted 2 undesignated symbols 0 _ZSt11__once_call std::__once_call version status: compatible GLIBCXX_3.4.11 type: tls type size: 8 status: undesignated 1 _ZSt15__once_callable std::__once_callable version status: compatible GLIBCXX_3.4.11 type: tls type size: 8 status: undesignated 3 incompatible symbols 0 _ZNKSt8__detail20_Prime_rehash_policy14_M_need_rehashEjjj std::__detail::_Prime_rehash_policy::_M_need_rehash(unsigned int, unsigned int, unsigned int) const version status: unversioned type: function status: subtracted 1 _ZNKSt8__de
[Bug c/56584] _int_free assertion failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56584 --- Comment #1 from Mikael Pettersson 2013-03-10 10:14:46 UTC --- I can't reproduce the error with vanilla gcc-4.7.2 running on Fedora 17/x86_64, either natively or in a cross to ARM Cortex-M3.
[Bug libstdc++/56587] [4.8 regression] libstdc++-abi/abi_check fails for powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56587 --- Comment #1 from Paolo Carlini 2013-03-10 10:15:41 UTC --- This is before / after / irrespective of this change: http://gcc.gnu.org/ml/libstdc++/2013-03/msg00033.html ?
[Bug c++/56585] Cannot introduce a qualified type - Elaborated type specifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56585 --- Comment #1 from Paolo Carlini 2013-03-10 10:25:27 UTC --- For the record, likewise current ICC. (by the way, you don't need a main in such a testcase, it's a dg-do compile anyway)
[Bug c++/56585] Cannot introduce a qualified type - Elaborated type specifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56585 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic --- Comment #2 from Jonathan Wakely 2013-03-10 10:33:45 UTC --- The standard says nothing about errors, it only requires a diagnostic, and a warning is a diagnostic. Maybe it could be an error with -pedantic-errors though.
[Bug c++/56585] Cannot introduce a qualified type - Elaborated type specifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56585
--- Comment #3 from Fernando Pelliccioni
2013-03-10 11:21:59 UTC ---
I don't see anything about "diagnostic", I only see that the Standard says
"error"
I quote a relevant excerpt from the example.
[ Example:
/* ... */
struct Data {
/* ... */
};
/* ... */
struct Data; // OK: Redeclares Data at global scope
struct ::Data; // error: cannot introduce a qualified type (7.1.6.3)
/* ... */
—end example ]
If I'm wrong, please point me to the standard.
[Bug target/56508] [SH] Add support for rtv/n instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56508
--- Comment #1 from Oleg Endo 2013-03-10 12:08:24
UTC ---
I've only looked briefly how this could be implemented.
As far as I can see, there are two basic cases:
1)
int test0 (int a, int b)
{
return a;
}
currently compiles to:
rts
mov r4,r0
In this case there is a reg copy of the return value to 'r0' before the return
insn. Such patterns usually show RTL that goes something like (after prologue
and epilogue pass):
(insn 13 20 16 2 (set (reg/i:SI 0 r0)
(reg/v:SI 4 r4 [orig:161 a ] [161])) sh_tmp.cpp:10 244 {movsi_ie}
(expr_list:REG_DEAD (reg/v:SI 4 r4 [orig:161 a ] [161])
(nil)))
(insn 16 13 25 2 (use (reg/i:SI 0 r0)) sh_tmp.cpp:10 -1
(nil))
(note 25 16 26 2 NOTE_INSN_EPILOGUE_BEG)
(jump_insn 26 25 27 2 (return) sh_tmp.cpp:10 372 {*return_i}
(nil)
-> return)
(barrier 27 26 23)
(note 23 27 0 NOTE_INSN_DELETED)
This would be the easiest to convert to rtv/n. E.g. In the split4 pass (after
register allocation, pro and epilogues, etc, but before delayed branch
scheduling), the return insn (*return_i above) could be converted into rtv/n by
walking up the insn list starting from the return insn and looking for the reg
copy insn that sets r0. If the source of the reg copy is a GP reg, it can be
combined with the return insn as rtv/n.
2)
int test1 (int a, int b)
{
return a + b;
}
currently compiles to:
mov r4,r0
rts
add r5,r0
In this case register allocation already prepares the return value in r0. This
is a simplified case, so there can be more preceeding insns working on the
return value that is allocated to 'r0' early on. In such cases there will not
be a reg copy to 'r0' before the return insn, so the 'combine approach' from
case 1 won't work here -- it would require additional register use analysis and
register renaming.
The obstacle for this case is that the reg copy and use insns for the return
value are generated during initial RTL expantion based on what the
TARGET_FUNCTION_VALUE hook says, but return insns are expanded after register
allocation. Thus register allocation can't be influenced.
An option would be to return a pseudo reg in TARGET_FUNCTION_VALUE (for
outgoing == true) instead of a hard reg and adding the reg copy during return
insn expansion. However, register allocation will then try to avoid using 'r0'
(because of allocation order). Such cases would then result in:
int test3 (char* a)
{
return a[0];
}
mov.b@r4,r1
rts
mov r1,r0
or with rtv/n applied:
mov.b @r4,r1
rtv/n r1
although the better way would be to utilize the delay slot of rts:
rts
mov.b @r4,r0
I guess to support this in a generic way (which could also be used by other
targets) the register for the return value should be initially left open (by
returning a pseudo in TARGET_FUNCTION_VALUE) and the register allocator should
be told a preferred register for the return value. If the return value then
does not end up in the required register, the epilogue expansion would emit the
reg copy insn or 'rtv/n' in the SH2A.
[Bug fortran/56575] [4.6/4.7/4.8 Regression] An invalid OO code causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56575 --- Comment #4 from Thomas Koenig 2013-03-10 12:09:27 UTC --- > I will apply this patch tomorrow, as "obvious" if nobody objects. The patch is also approved, with a test case. > An annoying feature is that the error is repeated. I do not immediately see > an > easy way of preventing this but think that that the result is better than a > seg-fault. Agreed. We could keep this bug open (without the regression marker) as a reminder.
[Bug fortran/56581] seg fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #1 from Thomas Koenig 2013-03-10 12:22:54 UTC --- Unfortunately, I cannot reproduct this on Linux (also not with valgrind). > The code is in error as the statement function > is commented out, but seg error . . . > Windows 7 running under cygwin, bash. The code, as attached, has C MCL23200 AKF(A,B,E,X)=A*EXP(-B*E)*X MCL23210 which I presume is the statement function. It is not commented out, as far as I can see. Is it possible for you to run f951.exe under gdb? This might give us some more information to work on.
[Bug c++/56585] Cannot introduce a qualified type - Elaborated type specifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56585 --- Comment #4 from Jonathan Wakely 2013-03-10 12:41:42 UTC --- 1.3.6 [defns.diagnostic] and 1.4 [intro.compliance] p2
[Bug fortran/56575] [4.6/4.7/4.8 Regression] An invalid OO code causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56575 --- Comment #5 from Paul Thomas 2013-03-10 13:24:10 UTC --- Author: pault Date: Sun Mar 10 13:23:58 2013 New Revision: 196580 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196580 Log: 2013-03-10 Paul Thomas PR fortran/56575 * expr.c (gfc_default_initializer): Check that a class declared type has any components. * resolve.c (resolve_fl_derived0): On failing the test for C437 set the type to BT_UNKNOWN to prevent repeat error messages. 2013-03-10 Paul Thomas PR fortran/56575 * gfortran.dg/class_56.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/class_56.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/56575] [4.6/4.7 Regression] An invalid OO code causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56575 Paul Thomas changed: What|Removed |Added Summary|[4.6/4.7/4.8 Regression] An |[4.6/4.7 Regression] An |invalid OO code causes ICE |invalid OO code causes ICE --- Comment #6 from Paul Thomas 2013-03-10 13:26:53 UTC --- Dear Thomas, Thanks for the review. I found a perfectly viable way to prevent the repeated error messages - change the component type to BT_UNKNOWN. One down, two to go. Cheers Paul
[Bug debug/55794] FAIL: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++98 and -std=gnu++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55794 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2013-03-09 00:00:00 |2013-03-10 Ever Confirmed|0 |1
[Bug fortran/56293] Segfault when trying to access pass-by-reference value of a not-word-aligned REAL(16) / -fno-align-commons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56293 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #6 from Thomas Koenig 2013-03-10 15:32:14 UTC --- > The question is also whether one can construct a fully standard-conform > example > which fails without -fno-align-commons – and whether some real-world code uses > COMMON in a way that would fails with alignments/padding. program main real a,f1,f2,d common /foo/ a,f1,f2,d a = 1.0 d = 1.0 call s1 end subroutine s1 real a,b double precision d common /foo/ a,d,b print *,a print *,b end
[Bug c/56572] GCC generates non-optimal transactional code when inlining nested transaction.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56572 Patrick Marlier changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||patrick.marlier at gmail ||dot com --- Comment #1 from Patrick Marlier 2013-03-10 15:35:43 UTC --- Please close http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56573 which is a duplicated bug report of this one.
[Bug target/56560] [4.6/4.7 regression] vzeroupper clobbers argument with AVX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56560
--- Comment #5 from Eric Botcazou 2013-03-10
15:51:03 UTC ---
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index c1f6c88..8005207 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -5562,7 +5562,7 @@ init_cumulative_args (CUMULATIVE_ARGS *cum, /* Argument
> info to initialize */
>memset (cum, 0, sizeof (*cum));
>
>/* Initialize for the current callee. */
> - if (caller)
> + if (caller && fndecl)
> {
>cfun->machine->callee_pass_avx256_p = false;
>cfun->machine->callee_return_avx256_p = false;
>
> fixes it.
I don't think it's correct, fndecl is NULL_TREE for indirect calls as well.
[Bug ada/56588] New: gnatmake crash with incorrect SAL GPR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56588 Bug #: 56588 Summary: gnatmake crash with incorrect SAL GPR Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: si...@pushface.org Created attachment 29634 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29634 Demonstrator If a SAL GPR mistakenly includes the name of a separate body in the Library_Interface, gnatmake crashes with a SEGV. This problem is present in at least GNAT GPL 2012, GCC 4.7.0, and GCC 4.8.0 20130309 (experimental) [trunk revision 196573]. Using the attached demonstrator (source.tar.gz), $ gnatmake -f -p -P source gcc -c -fPIC -I- -gnatA /Users/simon/tmp/gnatmake-bug/source.adb gnatbind -n -o b~source.adb -Lsource -a ... gcc -c -gnatws b~source.adb -fPIC building dynamic library for project source gcc -dynamiclib -o /Users/simon/tmp/gnatmake-bug/lib//libsource.dylib ... /Users/simon/tmp/gnatmake-bug/.build/b~source.o ... Segmentation fault: 11 I've attached a patch, but you may not like the reporting style. With the patch, the result is $ gnatmake -f -p -P source gcc -c -fPIC -I- -gnatA /Users/simon/tmp/gnatmake-bug/source.adb gnatbind -n -o b~source.adb -Lsource -a ... gcc -c -gnatws b~source.adb -fPIC building dynamic library for project source gcc -dynamiclib -o /Users/simon/tmp/gnatmake-bug/lib//libsource.dylib ... /Users/simon/tmp/gnatmake-bug/.build/b~source.o ... gnatmake: source-proc.ali not found (source may be subunit?)
[Bug ada/56588] gnatmake crash with incorrect SAL GPR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56588 --- Comment #1 from simon at pushface dot org 2013-03-10 16:03:19 UTC --- Created attachment 29635 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29635 Patch to fail build if the error is encountered
[Bug fortran/56581] seg fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581 --- Comment #2 from Walt Brainerd 2013-03-10 16:03:37 UTC --- Sorry, I was trying lots of different experiments and apparently removed the ! before attaching the file. I put it back in and now cannot reproduce the error. Ignore this for now and I will let you know if I come up with something again that is more useful to you. After sending the bug report, I discovered another strange thing. The first 24? bits of the file are junk that does not show up in any editor. "cat" shows a little open rectangle and "od" shows it. (These files were sent to me by somebody else.) Sorry to trouble you and thanks for the work you guys do on gfortran. On Sun, Mar 10, 2013 at 5:22 AM, tkoenig at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581 > > Thomas Koenig changed: > >What|Removed |Added > > > CC||tkoenig at gcc dot > gnu.org > > --- Comment #1 from Thomas Koenig 2013-03-10 > 12:22:54 UTC --- > Unfortunately, I cannot reproduct this on Linux (also not > with valgrind). > > > The code is in error as the statement function > > is commented out, but seg error . . . > > > Windows 7 running under cygwin, bash. > > The code, as attached, has > > C > MCL23200 > AKF(A,B,E,X)=A*EXP(-B*E)*X > MCL23210 > > which I presume is the statement function. It is not commented out, > as far as I can see. > > Is it possible for you to run f951.exe under gdb? This might > give us some more information to work on. > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You reported the bug. >
[Bug c/56589] New: [4.8 regression] Array bounds violation is very end-user unfriendly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56589
Bug #: 56589
Summary: [4.8 regression] Array bounds violation is very
end-user unfriendly
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Consider this program with undefined behavior:
#include
typedef int Array[3][2];
void bar (Array a)
{
int i, j;
for (i = 0; i < 3; ++i)
for (j = 0; j < 2; ++j)
printf (" %d", a[i][j]);
puts("");
}
void foo ()
{
Array a;
int j;
for (j = 0; j < 6; ++j) {
a[0][j] = 1; // User hand-optimized two loops into one :-(
}
bar (a);
}
int main ()
{
foo ();
return 0;
}
With gcc-4.7, this produces:
gcc overflow.c && ./a.out
1 1 1 1 1 1
gcc overflow.c -O2 && ./a.out
1 1 1 1 1 1
With gcc-4.8 (r196557):
gcc overflow.c && ./a.out
1 1 1 1 1 1
gcc overflow.c -O2 && ./a.out
1 1 4195396 0 -263006800 32767
No warnings are emitted with -Wall and -Wextra.
The disassembly for foo() shows that only the first two elements of the array
are initialized:
subq$40, %rsp
movq%rsp, %rdi
movl$1, (%rsp)
movl$1, 4(%rsp)
callbar
addq$40, %rsp
ret
I've now seen 3 instances of similar buggy code in our code base, and the loop
there was transformed into an infinite loop instead.
This way of signaling the problem to end-user is *exceedingly* unfriendly.
[Bug fortran/56581] seg fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-03-10 Ever Confirmed|0 |1 --- Comment #3 from Thomas Koenig 2013-03-10 16:29:19 UTC --- No problem :-) Changing the bug status to WAITING, then.
[Bug libstdc++/56587] [4.8 regression] libstdc++-abi/abi_check fails for powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56587 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek 2013-03-10 16:40:45 UTC --- The ABI files look correct to me, powerpc-linux-gnu/baseline_symbols.txt (== powerpc64-linux-gnu/32/baseline_symbols.txt ) are -m32 files, _M_next_bkt takes std::size_t argument and the baseline_symbols.txt files for that use j letter (i.e. unsigned int), while for 64-bit powerpc64-linux-gnu/baseline_symbols.txt _M_next_bkt uses m letter (i.e. unsigned long). find config/abi/post/powerpc* -name \*.txt | xargs grep _M_next_bkt config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt:FUNC:_ZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEm@@GLIBCXX_3.4.18 config/abi/post/powerpc64-linux-gnu/32/baseline_symbols.txt:FUNC:_ZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEj@@GLIBCXX_3.4.18 config/abi/post/powerpc-linux-gnu/baseline_symbols.txt:FUNC:_ZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEj@@GLIBCXX_3.4.18 If you are building powerpc64-linux --with-cpu=default32, you need to shuffle the baseline_symbols.txt around (64-bit move into 64/ subdirectory, 32/ subdirectory contents up), but that is not in any way a regression, and if you haven't done this shuffle you'd get hundreds of other failures, not just these.
[Bug libstdc++/56587] [4.8 regression] libstdc++-abi/abi_check fails for powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56587 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Andreas Schwab 2013-03-10 16:54:15 UTC --- A patch that swapped the 32/64 baseline symbols wasn't correctly carried forward. After fixing that only the two undesignated symbols remain. Nevertheless the abi check should really be fixed to make the shuffling unnecessary.
[Bug rtl-optimization/56590] New: Replace auto-inc-dec pass with generic address mode selection pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56590 Bug #: 56590 Summary: Replace auto-inc-dec pass with generic address mode selection pass Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: olege...@gcc.gnu.org Target: sh*-*-* At least on SH there are several address mode selection issues which I'd like to group in this PR. PR 54065 [SH] Prefer @(R0,Rn) addressing for floating-point load/store PR 53911 [SH] Improve displacement addressing PR 50749 Auto-inc-dec does not find subsequent contiguous mem accesses PR 39423 [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn) PR 52049 SH Target: Inefficient constant address access Based on my observations so far, I think the right thing to do is to replace the current auto-inc-dec pass with a pass that optimizes address mode selection in a more generic way, instead of just trying to find auto inc/dec opportunities. The basic idea is to look at all memory accesses in a function (or basic block as a start) that share a base address and then try to select the cheapest addressing modes for each memory access. The current address cost target hook can be used to determine the costs of a memory access with a particular address. I have already started working on such a replacement pass a while ago and would like to first do a trial with the SH target. Other targets might then also pick it up if it seems beneficial to do so.
[Bug c++/56585] Cannot introduce a qualified type - Elaborated type specifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56585 --- Comment #5 from Fernando Pelliccioni 2013-03-10 17:17:58 UTC --- Maybe GCC behavior is correct. I thought, mistakenly, that the examples of the C++ Standard have normative meaning.
[Bug target/56546] Using the divide operator on unsigned int produces incorrect code on AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56546 --- Comment #2 from kpet at free dot fr 2013-03-10 17:23:18 UTC --- (In reply to comment #1) > AVR has no divide instruction and / 60 is performed by a multiplication and > some adjustment. Thank you for this explanation. > > gcc-4.7.2, binutils 2.23.1 and avr-libc 1.8.0 give the same result. > > Is this an unpatched avr-gcc? In fact I discovered the issue on a toolchain built with Gentoo's crossdev tool. They are using a good number of patches but these are not the source of the problem. After digging a little deeper I discovered that the problem comes from the build options they use. After a good number of builds on an unpatched gcc-4.7.2 I've been able to determine that the --disable-multilib option they use is the source of the issue. Building with ../configure --prefix=/mnt/work/avr-gentoo-p14-nopie/ --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --with-dwarf2 gives a toolchain that does not have the issue reported, whereas building with ../configure --prefix=/mnt/work/avr-gentoo-p14-nopie/ --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --with-dwarf2 --disable-multilib allows to reproduce the issue. I don't know if building with --disable-multilib is correct and am not sure anymore this is an upstream bug...
[Bug target/54255] FAIL: gcc.target/i386/asm-dialect-1.c (test for excess errors) fails on x86_64/i686 darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54255 Dominique d'Humieres changed: What|Removed |Added CC||dominiq at lps dot ens.fr --- Comment #6 from Dominique d'Humieres 2013-03-10 17:30:44 UTC --- *** Bug 54105 has been marked as a duplicate of this bug. ***
[Bug testsuite/54105] FAIL: gcc.target/i386/asm-dialect-1.c (test for excess errors) on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54105 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Dominique d'Humieres 2013-03-10 17:30:44 UTC --- Fixed at r193127. *** This bug has been marked as a duplicate of bug 54255 ***
[Bug target/54407] FAIL: 30_threads/condition_variable/54185.cc execution test program timed out on powerpc-apple-darwin9 and x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54407 --- Comment #17 from Dominique d'Humieres 2013-03-10 17:58:17 UTC --- Jack, I see at http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00331.html that you have tested a fix for this PR. I have tested that it skips the test on powerpc-apple-darwin9 and x86_64-apple-darwin10. Have you submitted it?
[Bug translation/56591] New: Missing space
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56591 Bug #: 56591 Summary: Missing space Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation AssignedTo: unassig...@gcc.gnu.org ReportedBy: sti...@antcom.de gcc/config/avr/avr.c:2234:"Unsupported code '%c'for fixed-point:"
[Bug fortran/55362] [4.6/4.7 Regression] ICE with size() on character pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55362 --- Comment #8 from Paul Thomas 2013-03-10 18:34:35 UTC --- Author: pault Date: Sun Mar 10 18:34:24 2013 New Revision: 196582 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196582 Log: 2013-03-10 Paul Thomas PR fortran/55362 * check.c (array_check): It is an error if a procedure is passed. 2013-03-10 Paul Thomas PR fortran/55362 * gfortran.dg/intrinsic_size_4.f90 : New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/intrinsic_size_4.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/check.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug fortran/56581] seg fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus 2013-03-10 19:24:31 UTC --- (In reply to comment #2) > After sending the bug report, I discovered another strange thing. > The first 24? bits of the file are junk that does not show up in any > editor. "cat" shows a little open rectangle and "od" shows it. > (These files were sent to me by somebody else.) The extra bytes could be a Unicode byte-order marker? Especially under Windows, some editors like to insert them: https://en.wikipedia.org/wiki/UTF-8#Byte_order_mark
[Bug fortran/56581] seg fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581 --- Comment #5 from Walt Brainerd 2013-03-10 19:39:42 UTC --- I think that is exactly what they were (wrote a little program to get rid of them). The files were produced by OCR and then edited (not by me), so that is all possible. Thanks for pointing this out to me. The Intel compiler seemed to completely ignore them, but gfortran sometimes bombed and sometimes didn't with f951.exe: out of memory . . . gfortran compiles all the files in the set without a problem now. It is possible that also caused the internal compiler error, but who knows. On Sun, Mar 10, 2013 at 12:24 PM, burnus at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581 > > Tobias Burnus changed: > >What|Removed |Added > > > CC||burnus at gcc dot gnu.org > > --- Comment #4 from Tobias Burnus 2013-03-10 > 19:24:31 UTC --- > (In reply to comment #2) > > After sending the bug report, I discovered another strange thing. > > The first 24? bits of the file are junk that does not show up in any > > editor. "cat" shows a little open rectangle and "od" shows it. > > (These files were sent to me by somebody else.) > > The extra bytes could be a Unicode byte-order marker? Especially under > Windows, > some editors like to insert them: > https://en.wikipedia.org/wiki/UTF-8#Byte_order_mark > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You reported the bug. >
[Bug target/53513] SH Target: Add support for fschg and fpchg insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #1 from Oleg Endo 2013-03-10 19:53:56 UTC --- Some related notes: According to the public documentation, the 'fschg' insn is only valid when FPSCR.PR = 0 on all FPU enabled cores (SH2A, SH4, SH4A). On SH4 and SH4A the 'frchg' insn is only valid when FPSCR.PR = 0. The setting FPSCR.PR = 1, FPSCR.SZ = 1 is only valid for SH4A and SH2A, but not SH4.
[Bug fortran/55362] [4.6/4.7 Regression] ICE with size() on character pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55362 --- Comment #9 from Paul Thomas 2013-03-10 20:14:57 UTC --- Author: pault Date: Sun Mar 10 20:14:48 2013 New Revision: 196583 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196583 Log: 2013-03-10 Paul Thomas PR fortran/55362 * check.c (array_check): It is an error if a procedure is passed. 2013-03-10 Paul Thomas PR fortran/55362 * gfortran.dg/intrinsic_size_4.f90 : New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/intrinsic_size_4.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/check.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug middle-end/56589] Array bounds violation is very end-user unfriendly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56589 Andrew Pinski changed: What|Removed |Added Component|c |middle-end Summary|[4.8 regression] Array |Array bounds violation is |bounds violation is very|very end-user unfriendly |end-user unfriendly | --- Comment #1 from Andrew Pinski 2013-03-10 20:31:49 UTC --- >From the changes page: GCC now uses a more aggressive analysis to derive an upper bound for the number of iterations of loops using constraints imposed by language standards. This may cause non-conforming programs to no longer work as expected, such as SPEC CPU 2006 464.h264ref and 416.gamess. A new option, -fno-aggressive-loop-optimizations, was added to disable this aggressive analysis. --- CUT -- There is another bug opened about adding a warning already but I don't remember the number.
[Bug fortran/55362] [4.6/4.7 Regression] ICE with size() on character pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55362 --- Comment #10 from Paul Thomas 2013-03-10 21:02:52 UTC --- Author: pault Date: Sun Mar 10 21:02:44 2013 New Revision: 196584 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196584 Log: 2013-03-10 Paul Thomas PR fortran/55362 * check.c (array_check): It is an error if a procedure is passed. 2013-03-10 Paul Thomas PR fortran/55362 * gfortran.dg/intrinsic_size_4.f90 : New test. Modified: branches/gcc-4_6-branch/gcc/fortran/check.c
[Bug tree-optimization/56576] wrong code for aliased union at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56576 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Andrew Pinski 2013-03-10 21:17:29 UTC --- You cannot use union to avoid aliasing rules for normal accesses.
[Bug tree-optimization/56577] wrong code for aliased union on gcc 4.7 only
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56577 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Andrew Pinski 2013-03-10 21:18:19 UTC --- You cannot use union to avoid aliasing rules for normal accesses.
[Bug target/56592] New: [SH] Add vector ABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56592 Bug #: 56592 Summary: [SH] Add vector ABI Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: olege...@gcc.gnu.org CC: kkoj...@gcc.gnu.org Target: sh*-*-* On SH there are a couple of ABI related issues which unfortunately can't be all fixed without breaking binary compatibility. Thus the idea to add a new ABI which can be selected by a target -mabi=vector option. Already existing ABIs could also be selected based on this option: -mrenesas -> -mabi=renesas -mnorenesas -> -mabi=gnu Some of the primary issues that the vector ABI is supposed to improve are: -- PR 13423 sh-elf: V4SFmode passed in integer registers float vectors, float arrays (of fixed size) or structs of floats when passed by value should be passed in FP regs entirely. The current ABI allows passing of up to 8 FP regs (FR4..FR11), so there would be space to pass two 4D float vectors. It should also be possible to return a 4D float vectors in registers. Since FR0..FR11 are call clobbered, they can as well be used to return multiple vectors. -- PR 53513 SH Target: Add support for fschg and fpchg insns Although this PR could be solved without breaking the ABI too much, there are some issues which could be fixed in a new ABI. The current approach is to use two global variables (__fpscr_values) in order to perform FPU single/double mode switching. The default FPU precision setting is defined by an -m option. Currently there are three such FPU default modes: - double mode default - single mode default - single mode only When changing the FPU mode the current FPSCR setting is overwritten with one of the global values from __fpscr_values. This is the fastest way (on non-SH4A) to perform a mode switch, but it has some disadvantages. One of them is PR 6526. In general all information in FPSCR is lost after performing a mode switch this way, e.g. it is not possible to read FPU exception causes after a series of operations. Moreover, in multi-threaded environments it is not possible to set the default FPSCR setting (e.g. rounding mode or denormal handling) for threads independently. In order to minimize mode switches the function signature can be taken into account when deciding the default FPU precision for a particular function. E.g. when a function has any double precision arguments, it can be assumed that the function will use the double values in some way. Thus the default entry mode for such a function should be 'double'. Similarly, for functions that return double values it can be better to leave the function with 'double' mode. Because of this, '-m4 -mvabi' and '-m4-single -mvabi' would actually result in the same ABI. It should also be possible to override the FPSCR.PR settings for function entry and function leave via function attributes. This can be useful e.g. in cases where hand written asm FPU routines are invoked from C/C++ code that expect certain settings. E.g. code that uses the 'frchg' insn to flip FPSCR.FR bit on SH4 must be executed with FPSCR.PR = 0. -- PR 52441 Target: Double sign/zero extensions for function arguments Values that are passed in registers that are < 32 bit in size have usually undefined high bits. The standard GNU calling convention thus performs sign/zero extension of such values before the function call and inside the function itself. The Renesas calling convention (-mrenesas) however only extends values inside the function. Whether an extension is actually required at all depends on how the value is used. This is known only inside of a function. Thus adopting the Renesas calling convention in this case is more efficient. -- Register ordering for arguments. I don't remember in which PR this was mentioned but the current GNU calling convention allocates FR registers on big endian like: FR4 = arg0 FR5 = arg1 FR6 = arg2 FR7 = arg3 ... and on little endian: FR4 = arg1 FR5 = arg0 FR6 = arg3 FR7 = arg2 ... This can make writing endian neutral asm code more complicated. The ordering for little endian should be the same as for big endian (which is also equivalent to the -mrenesas ABI). -- Alignment of double precision FP values. Currently the default alignment for those is 32 bit and can be changed to 64 bit by the option -mdalign. In order to be able to maximize the utilization of 64 bit fmov insns, 64 bit double alignment should be the default. -- Boolean function return values A boolean return value of a function tends to be produce
[Bug fortran/56293] Segfault when trying to access pass-by-reference value of a not-word-aligned REAL(16) / -fno-align-commons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56293 --- Comment #7 from Tobias Schlüter 2013-03-11 00:15:43 UTC --- (In reply to comment #6) > > The question is also whether one can construct a fully standard-conform > > example > > which fails without -fno-align-commons – and whether some real-world code > > uses > > COMMON in a way that would fails with alignments/padding. > > program main > real a,f1,f2,d > common /foo/ a,f1,f2,d > a = 1.0 > d = 1.0 > call s1 > end > subroutine s1 > real a,b > double precision d > common /foo/ a,d,b > print *,a > print *,b > end That's not valid. I'm looking at the F95 working draft: according to note 5.33 """Association in different scoping units between objects of default type, objects of double precision real type, and sequence structures is permitted according to the rules for equivalence objects (5.5.1).""" and in 5.5.1. we have """If an equivalence-object is of type default integer, default real, double precision real, default complex, default logical, or numeric sequence type, all of the objects in the equivalence set shall be of these types."""
[Bug target/56347] [4.8 Regression] FAIL: gfortran.dg/integer_exponentiation_2.f90 -O2 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56347 --- Comment #10 from John David Anglin 2013-03-11 00:44:33 UTC --- Author: danglin Date: Mon Mar 11 00:44:28 2013 New Revision: 196588 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196588 Log: PR target/56347 * config/pa/pa.md (call_value): Check for calls to powf and direct to new call patterns that clobber %fr12. (call_val_powf, call_val_powf_pic, call_val_powf_64bit): New insn, split and postreload patterns. * config/pa/pa.c (pa_conditional_register_usage): Revert marking registers %fr12 and %fr12R as call used. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.c trunk/gcc/config/pa/pa.md
[Bug target/40797] [4.6/4.7/4.8 Regression] ICE in df_refs_verify, at df-scan.c:4361
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40797 --- Comment #14 from Oleg Endo 2013-03-11 01:04:17 UTC --- Author: olegendo Date: Mon Mar 11 01:04:13 2013 New Revision: 196590 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196590 Log: PR target/40797 * gcc.c-torture/compile/pr40797.c: New. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr40797.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug debug/56307] FAIL: gcc.dg/tree-ssa/pr55579.c scan-tree-dump esra "Created a debug-only replacement for s"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56307 --- Comment #4 from John David Anglin 2013-03-11 01:10:43 UTC --- Author: danglin Date: Mon Mar 11 01:10:38 2013 New Revision: 196591 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196591 Log: PR debug/56307 * gcc.dg/tree-ssa/pr55579.c: xfail 32-bit hppa*-*-hpux*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr55579.c
[Bug testsuite/54119] FAIL: gcc.dg/tree-ssa/vector-4.c scan-tree-dump-times gimple "VEC_PERM_EXPR ;" 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54119 --- Comment #4 from John David Anglin 2013-03-11 01:18:22 UTC --- Author: danglin Date: Mon Mar 11 01:18:18 2013 New Revision: 196592 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196592 Log: PR testsuite/54119 * gcc.dg/tree-ssa/vector-4.c: xfail on 32-bit hppa*-*-*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/vector-4.c
[Bug testsuite/54119] FAIL: gcc.dg/tree-ssa/vector-4.c scan-tree-dump-times gimple "VEC_PERM_EXPR ;" 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54119 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from John David Anglin 2013-03-11 01:28:34 UTC --- Fixed.
[Bug c++/54359] [C++0x] decltype in member function's trailing return type when defined outside of class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54359 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-03-11 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/56567] [4.8 Regression] ICE with lambda return type deduction and braced-init-list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56567
--- Comment #5 from Jason Merrill 2013-03-11
03:21:52 UTC ---
(In reply to comment #4)
> It's certainly legal to compile a function returning an std::initializer list,
> which is never called. So this fix is problematic. For example
>
> []{ return std::initializer_list< int >{ 1, 2 }; }();
That's a good point, though returning an initializer_list value is completely
useless; since the underlying array is local to the returning function, any use
of the returned value would cause undefined behavior, just like returning a
reference to a local variable.
[Bug debug/56502] entry-value: Missing DW_AT_linkage_name for C<->C++ calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56502 Jan Kratochvil changed: What|Removed |Added Attachment #29564|0 |1 is obsolete|| --- Comment #2 from Jan Kratochvil 2013-03-11 06:17:06 UTC --- Comment on attachment 29564 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29564 FSF GDB HEAD patch before it is upstreamed. Patch is now upstreamed (differently).
[Bug fortran/55362] [4.6/4.7 Regression] ICE with size() on character pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55362 Igor Zamyatin changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #11 from Igor Zamyatin 2013-03-11 06:20:02 UTC --- r196583 seems to break 4_6 branch bootstrap with /export/gnu/import/git/gcc-test/bld/./prev-gcc/xgcc -B/export/gnu/import/git/gcc-test/bld/./prev-gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include-c -DIN_GCC_FRONTEND -g -O2 -fomit-frame-pointer -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -Ifortran -I../../src-4.6/gcc -I../../src-4.6/gcc/fortran -I../../src-4.6/gcc/../include -I../../src-4.6/gcc/../libcpp/include -I../../src-4.6/gcc/../libdecnumber -I../../src-4.6/gcc/../libdecnumber/bid -I../libdecnumber ../../src-4.6/gcc/fortran/check.c -o fortran/check.o ../../src-4.6/gcc/fortran/check.c: In function 'array_check': ../../src-4.6/gcc/fortran/check.c:268:50: error: expected statement before ')' token make[6]: *** [fortran/check.o] Error 1
