[Bug middle-end/55750] [4.8 Regression] :-( in expand_expr_addr_expr_1, at expr.c:7646
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55750 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-20 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org 2012-12-20 08:08:12 UTC --- Reproduced even on x86_64-unknown-linux-gnu, confirmed.
[Bug fortran/54818] [4.7/4.8 Regression] error: type mismatch in binary expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54818 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-20 08:13:29 UTC --- Author: burnus Date: Thu Dec 20 08:13:21 2012 New Revision: 194628 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194628 Log: 2012-12-20 Tobias Burnus bur...@net-b.de PR fortran/54818 * trans-intrinsic.c (gfc_conv_intrinsic_transfer): Ensure that the string length is of type gfc_charlen_type_node. 2012-12-20 Tobias Burnus bur...@net-b.de PR fortran/54818 * gfortran.dg/transfer_intrinsic_4.f: New. Added: trunk/gcc/testsuite/gfortran.dg/transfer_intrinsic_4.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/55745] [4.8 regression] FAIL: gfortran.dg/pr26246_2.f90 -O scan-tree-dump-times original static int 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55745 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-20 08:15:52 UTC --- CLOSE AS FIXED. (In reply to comment #1) Confirmed, cris-elf too. Authors in ChangeLog entry CC:ed. The bug fix is older than the bug report ;-) I believe it has been fixed by the following commit. Sorry for the breakage. Date: Wed Dec 19 23:05:49 2012 New Revision: 194621 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194621 Log: 2012-12-19 Tobias Burnus bur...@net-b.de PR fortran/55733 * trans-decl.c (gfc_create_string_length): Avoid setting TREE_STATIC for automatic variables with -fno-automatic. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c
[Bug c++/55032] [4.7/4.8 Regression] Internal compiler error: in strip_typedefs, at cp/tree.c:1199
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55032
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC||ppluzhnikov at google dot
||com
--- Comment #6 from Paul Pluzhnikov ppluzhnikov at google dot com 2012-12-20
08:18:27 UTC ---
FYI, when we picked up r194286 into google/gcc-4_7 branch, and ran our 500,000
validation tests, we discovered two instances of mis-compilation.
This code:
typedef vectorvoid* T[13];
void foo() {
T x;
...
}
is mis-compiled to omit 13 calls to vector::vector, and x[0], x[1], etc. all
contain uninitialized stack garbage data members.
I've confirmed that trunk compiler is similarly broken.
Unfortunately I haven't been able to reduce the test case that exposes the
problem yet.
[Bug libstdc++/55741] [4.8 Regression] bootstrap fails in libstdc++-v3/src/c++11/thread.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55741 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-20 08:33:06 UTC --- Well, this is caused by the issue that configure doesn't detect nanosleep/sleep without using libwinthread.a library. To solve this issue please use option '--enable-libstdcxx-time=yes', that should solve your issue. As this option is only valid for mingw-targets, if threading-model is 'posix', the check in aclocal.m4 needs some extensions.
[Bug fortran/55729] Problem with sum intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55729 --- Comment #4 from pmarguinaud at hotmail dot com 2012-12-20 08:45:09 UTC --- I tried 4.7.2 as suggested and it works.
[Bug middle-end/55750] [4.8 Regression] :-( in expand_expr_addr_expr_1, at expr.c:7646
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55750 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-20 08:49:08 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=193882
[Bug middle-end/55750] [4.8 Regression] :-( in expand_expr_addr_expr_1, at expr.c:7646
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55750
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-20
08:51:38 UTC ---
Invalid already at gimple dump:
foo (unsigned int i)
{
unnamed-unsigned:7 * D.1723;
unnamed-unsigned:7 D.1724;
unnamed-unsigned:7 D.1725;
unnamed-unsigned:7 D.1726;
D.1723 = arr[i].n;
D.1724 = arr[i].n;
D.1725 = D.1724;
D.1726 = D.1725 + 1;
*D.1723 = D.1726;
}
Obviously, taking address of a bitfield is wrong.
[Bug fortran/55745] [4.8 regression] FAIL: gfortran.dg/pr26246_2.f90 -O scan-tree-dump-times original static int 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55745 --- Comment #3 from Andreas Schwab sch...@linux-m68k.org 2012-12-20 09:04:27 UTC --- The bug fix is older than the bug report ;-) No, it isn't. I was able to file it 18 minutes before your commit. :-)
[Bug regression/55486] FAIL: gcc.dg/sms-7.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55486 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution||FIXED --- Comment #5 from ktkachov at gcc dot gnu.org 2012-12-20 10:07:02 UTC --- Tests now pass. No ICEs. Thanks, Kyrill
[Bug c/39464] [4.6/4.7/4.8 Regression] Attribute may_alias causes invalid warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39464 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-20 10:40:33 UTC --- Author: jakub Date: Thu Dec 20 10:40:26 2012 New Revision: 194630 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194630 Log: PR c/39464 * c-typeck.c (convert_for_assignment): For -Wpointer-sign warning require that both c_common_unsigned_type as well as c_common_signed_type is the same for both mvl and mvr types. * gcc.dg/pr39464.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr39464.c
[Bug c++/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55619 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-20 10:41:51 UTC --- Author: jakub Date: Thu Dec 20 10:41:47 2012 New Revision: 194631 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194631 Log: PR c++/55619 * c-parser.c (c_parser_asm_operands): Remove CONVERT_P argument, don't call default_function_array_conversion nor c_fully_fold here. (c_parser_asm_statement): Adjust callers. * c-typeck.c (build_asm_expr): Call c_fully_fold on inputs and outputs here, and call default_function_array_conversion on inputs that don't need to be addressable. * c-c++-common/pr55619.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr55619.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54818] [4.7/4.8 Regression] error: type mismatch in binary expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54818 --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-20 10:48:15 UTC --- Author: burnus Date: Thu Dec 20 10:48:11 2012 New Revision: 194632 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194632 Log: 2012-12-20 Tobias Burnus bur...@net-b.de PR fortran/54818 * trans-intrinsic.c (gfc_conv_intrinsic_transfer): Ensure that the string length is of type gfc_charlen_type_node. 2012-12-20 Tobias Burnus bur...@net-b.de PR fortran/54818 * gfortran.dg/transfer_intrinsic_4.f: New. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/transfer_intrinsic_4.f Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug fortran/54818] [4.7/4.8 Regression] error: type mismatch in binary expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54818 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-20 10:50:47 UTC --- FIXED on the 4.8 trunk and the 4.7 branch. (4.6 does not seem to be affected and 4.5/4.6 aren't maintained anymore.) Thanks for the bug report!
[Bug libstdc++/55741] [4.8 Regression] bootstrap fails in libstdc++-v3/src/c++11/thread.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55741 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-12-20 11:45:56 UTC --- The point of http://gcc.gnu.org/viewcvs?view=revisionrevision=193769 was that std::this_thread::sleep_for() is always available, even without --enable-libstdcxx-time=yes, so the default configuration needs to bootstrap.
[Bug libstdc++/55741] [4.8 Regression] bootstrap fails in libstdc++-v3/src/c++11/thread.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55741 --- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-20 12:11:43 UTC --- (In reply to comment #4) The point of http://gcc.gnu.org/viewcvs?view=revisionrevision=193769 was that std::this_thread::sleep_for() is always available, even without --enable-libstdcxx-time=yes, so the default configuration needs to bootstrap. Well, patch has one issue about used type. Sleep expects 'unsigned long' as argument. Rest of suggested patch works. The reason I mentioned --enable option is that nanosleep isn't detected proper by configure test in case that nanosleep is a function provided by POSIX-library pthread. Nevertheless the hole thread-layer of cxx is one mingw just available together with POSIX-library - and libwinpthread provides a cancel-able variant of nanosleep.
[Bug target/55752] New: __builtin_ia32_ldmxcsr / __builtin_ia32_stmxcsr are not scheduling barriers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55752
Bug #: 55752
Summary: __builtin_ia32_ldmxcsr / __builtin_ia32_stmxcsr are
not scheduling barriers
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
Target: x86_64-*-*
float foo (float x, float f32)
{
unsigned int mxscr_stat;
mxscr_stat = __builtin_ia32_stmxcsr ();
__builtin_ia32_ldmxcsr (mxscr_stat | 0x0800);
f32 = (x + f32) - f32;
mxscr_stat = mxscr_stat 0xffc0;
__builtin_ia32_ldmxcsr (mxscr_stat);
return f32;
}
Compiled at O2 yields:
foo:
.LFB0:
.cfi_startproc
stmxcsr -4(%rsp)
movl-4(%rsp), %eax
movl%eax, %edx
orb $8, %dh
movl%edx, -4(%rsp)
ldmxcsr -4(%rsp)
addss %xmm1, %xmm0
andl$-64, %eax
movl%eax, -4(%rsp)
ldmxcsr -4(%rsp)
subss %xmm1, %xmm0
ret
note how the subss is scheduled after the ldmxcsr call.
It's ok (by pure luck of course) at the GIMPLE level.
[Bug tree-optimization/55748] compile eror when -fprefetch-loop-arrays is added , while everything goes well without the option.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55748 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-12-20 Ever Confirmed|0 |1 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org 2012-12-20 12:41:27 UTC --- Note that GCC 4.4.0 is no longer maintained, please update to at least GCC 4.6.3.
[Bug rtl-optimization/55740] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1582, error: loop 2's header does not belong directly to it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55740 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2012-12-20 12:45:53 UTC --- Author: rguenth Date: Thu Dec 20 12:45:48 2012 New Revision: 194633 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194633 Log: 2012-12-20 Richard Biener rguent...@suse.de PR middle-end/55740 * cfghooks.c (merge_blocks): Properly handle merging of two loop headers. * g++.dg/torture/pr55740.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr55740.C Modified: trunk/gcc/ChangeLog trunk/gcc/cfghooks.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/55740] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1582, error: loop 2's header does not belong directly to it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55740 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2012-12-20 12:46:11 UTC --- Fixed.
[Bug libstdc++/55741] [4.8 Regression] bootstrap fails in libstdc++-v3/src/c++11/thread.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55741 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2012-12-20 12:59:08 UTC --- (In reply to comment #5) (In reply to comment #4) The point of http://gcc.gnu.org/viewcvs?view=revisionrevision=193769 was that std::this_thread::sleep_for() is always available, even without --enable-libstdcxx-time=yes, so the default configuration needs to bootstrap. Well, patch has one issue about used type. Sleep expects 'unsigned long' as argument. Ah thanks, I didn't know what type DWORD is. Rest of suggested patch works. Great, thanks. So if I change the type to unsigned long and commit it, can I say you tested it? I don't like committing changes I can't test myself! Or if you want to commit it then it's pre-approved by me. The reason I mentioned --enable option is that nanosleep isn't detected proper by configure test in case that nanosleep is a function provided by POSIX-library pthread. This is the same on all platforms. I would like to revisit that for GCC 4.9 but for 4.8 I just want std::this_thread::sleep_for() to work, even if it uses a low resolution sleep function. The __sleep_for function is in the .so and takes units of seconds and nanoseconds, so if we enable nanosleep automatically in 4.9 then code compiled with 4.8 and linked to libstdc++.so from 4.9 will get the nanosleep-capable version of __sleep_for() without needing to be recompiled.
[Bug target/55752] __builtin_ia32_ldmxcsr / __builtin_ia32_stmxcsr are not scheduling barriers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55752 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2012-12-20 12:59:40 UTC --- The RTXes that corresponds to builtins are all declared unspec_volatile. According to the comment in sched-deps.c, around line 2723, it is assumed that unspec_volatile clobbers all registers.
[Bug libstdc++/55741] [4.8 Regression] bootstrap fails in libstdc++-v3/src/c++11/thread.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55741 --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-20 13:05:35 UTC --- (In reply to comment #6) (In reply to comment #5) (In reply to comment #4) The point of http://gcc.gnu.org/viewcvs?view=revisionrevision=193769 was that std::this_thread::sleep_for() is always available, even without --enable-libstdcxx-time=yes, so the default configuration needs to bootstrap. Well, patch has one issue about used type. Sleep expects 'unsigned long' as argument. Ah thanks, I didn't know what type DWORD is. Rest of suggested patch works. Great, thanks. So if I change the type to unsigned long and commit it, can I say you tested it? I don't like committing changes I can't test myself! Or if you want to commit it then it's pre-approved by me. It is tested by me, if you change Sleep's argument to 'unsigned long' type. It is approved by me. Thanks. The reason I mentioned --enable option is that nanosleep isn't detected proper by configure test in case that nanosleep is a function provided by POSIX-library pthread. This is the same on all platforms. I would like to revisit that for GCC 4.9 but for 4.8 I just want std::this_thread::sleep_for() to work, even if it uses a low resolution sleep function. The __sleep_for function is in the .so and takes units of seconds and nanoseconds, so if we enable nanosleep automatically in 4.9 then code compiled with 4.8 and linked to libstdc++.so from 4.9 will get the nanosleep-capable version of __sleep_for() without needing to be recompiled. Ok, looking forward to 4.9
[Bug c++/55753] New: [C++11][4.8 Regression] ICE constexpr ctor, tsubst_copy_and_build, at cp/pt.c:14336
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55753
Bug #: 55753
Summary: [C++11][4.8 Regression] ICE constexpr ctor,
tsubst_copy_and_build, at cp/pt.c:14336
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: david.abdurachma...@gmail.com
Created attachment 29011
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29011
Testcase used.
Hi all,
Here is another C++11 regression in 4.8, I believe. Tested with GNU GCC 4.8.0
(r194629). Compiles fine if constexpr is removed from struct C ctor. Also
compiles fine on 4.7.2.
In addition tested with -Wall -Wextra and -fno-strict-aliasing -fwrapv, which
yielded the same results.
Originally noticed in code using std::complex, i.e., C could be replaced with
std::complex. E.g.,
std::complexdouble cpl = std::complexdouble((true ? 1.0 :
std::complexdouble()));
I am attaching *.ii test case.
Cheers,
david
### TESTCASE ###
template typename Tp
struct C {
constexpr C(const Tp r) { }
};
template typename Tp
struct B {
B() {
Cdouble cpl = Cdouble((true ? 1.0 : Cdouble()));
}
};
### COMPILATION LINE ###
g++ -m64 -O2 -std=c++11 -c testcase.cpp -fPIC -g -o ./testcase.o
### ICE ###
testcase.cpp: In constructor 'BTp::B()':
testcase.cpp:9:55: internal compiler error: in tsubst_copy_and_build, at
cp/pt.c:14336
Cdouble cpl = Cdouble((true ? 1.0 : Cdouble()));
^
### VERBOSE OUTPUT ###
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-unknown-linux-gnu
Configured with: ../configure
--prefix=/build/davidlt/gcc480/b/tmp/BUILDROOT/b0fc97fddd2f40bb6a475bc4cb2eec22/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0
--disable-multilib --disable-nls --enable-languages=c,c++,fortran
--enable-gold=yes --enable-lto
--with-gmp=/build/davidlt/gcc480/b/tmp/BUILDROOT/b0fc97fddd2f40bb6a475bc4cb2eec22/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0
--with-mpfr=/build/davidlt/gcc480/b/tmp/BUILDROOT/b0fc97fddd2f40bb6a475bc4cb2eec22/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0
--with-mpc=/build/davidlt/gcc480/b/tmp/BUILDROOT/b0fc97fddd2f40bb6a475bc4cb2eec22/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0
--with-isl=/build/davidlt/gcc480/b/tmp/BUILDROOT/b0fc97fddd2f40bb6a475bc4cb2eec22/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0
--with-cloog=/build/davidlt/gcc480/b/tmp/BUILDROOT/b0fc97fddd2f40bb6a475bc4cb2eec22/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0
--disable-isl-version-check --enable-shared CC='gcc -fPIC' CXX='c++ -fPIC'
CPP=cpp CXXCPP='c++ -E'
Thread model: posix
gcc version 4.8.0 20121220 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-m64' '-O2' '-std=c++11' '-c' '-fPIC'
'-o' './testcase.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1plus
-E -quiet -v -iprefix
/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/
-D_GNU_SOURCE testcase.cpp -m64 -mtune=generic -march=x86-64 -std=c++11 -fPIC
-O2 -fpch-preprocess -o testcase.ii
ignoring nonexistent directory
/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include
ignoring duplicate directory
/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0
ignoring duplicate directory
/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-linux-gnu
ignoring duplicate directory
/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/backward
ignoring duplicate directory
/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include
ignoring duplicate directory
/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed
ignoring nonexistent directory
/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0
/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown
[Bug target/55752] __builtin_ia32_ldmxcsr / __builtin_ia32_stmxcsr are not scheduling barriers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55752 --- Comment #2 from rguenther at suse dot de rguenther at suse dot de 2012-12-20 13:07:20 UTC --- On Thu, 20 Dec 2012, ubizjak at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55752 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2012-12-20 12:59:40 UTC --- The RTXes that corresponds to builtins are all declared unspec_volatile. According to the comment in sched-deps.c, around line 2723, it is assumed that unspec_volatile clobbers all registers. Ok, it seems it's TER that moves the subtraction. Richard.
[Bug middle-end/55750] [4.8 Regression] :-( in expand_expr_addr_expr_1, at expr.c:7646
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55750 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-20 13:28:57 UTC --- Created attachment 29012 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29012 gcc48-pr55750.patch Untested fix.
[Bug target/55752] __builtin_ia32_ldmxcsr / __builtin_ia32_stmxcsr are not scheduling barriers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55752 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-12-20 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2012-12-20 13:32:02 UTC --- TER already avoids moving things across calls but: /* Increment counter if this is a non BUILT_IN call. We allow replacement over BUILT_IN calls since many will expand to inline insns instead of a true call. */ if (is_gimple_call (stmt) !((fndecl = gimple_call_fndecl (stmt)) DECL_BUILT_IN (fndecl))) cur_call_cnt++; so it special-cases all builtins (I can see __builtin_sqrt as a good example where this is a good idea). OTOH __builtin_ia32_stmxcsr/ __builtin_ia32_ldmxcsr are neither const nor pure, so maybe restricting this further, like /* Increment counter if this is not a BUILT_IN call without side-effects. We allow replacement over BUILT_IN calls since many will expand to inline insns instead of a true call. */ if (is_gimple_call (stmt) (!((fndecl = gimple_call_fndecl (stmt)) DECL_BUILT_IN (fndecl)) || gimple_has_side_effects (stmt))) cur_call_cnt++;
[Bug middle-end/52996] [4.8 Regression] ice in verify_loop_structure, at cfgloop.c:1567
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52996 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org 2012-12-20 13:37:47 UTC --- The issue here is that when unswitching, we create this new bb: ;; basic block 19, loop depth 0, count 0, freq 14, maybe hot ;; prev block 20, next block 1, flags: (NEW, RTL, MODIFIED) ;; pred: 18 [2.2%] ;; succ: 8 [100.0%] (FALLTHRU) its loop depth should be 1, not 0.
[Bug c++/55753] [C++11][4.8 Regression] ICE constexpr ctor, tsubst_copy_and_build, at cp/pt.c:14336
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55753 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug regression/55754] New: FAIL: gcc.target/arm/unsigned-extend-2.c scan-assembler ands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55754 Bug #: 55754 Summary: FAIL: gcc.target/arm/unsigned-extend-2.c scan-assembler ands Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: ktkac...@gcc.gnu.org CC: ramana.radhakrish...@arm.com, richard.earns...@arm.com Target: arm-none-eabi FAIL: gcc.target/arm/unsigned-extend-2.c scan-assembler ands FAIL: gcc.target/arm/unsigned-extend-2.c scan-assembler-not uxtb FAIL: gcc.target/arm/unsigned-extend-2.c scan-assembler-not cmp Bisection shows r194608 introduces the FAILs. In particular the following snippet causes the test FAIL: /* If *op0 is (zero_extend:SI (subreg:QI (reg:SI) 0)) and comparing with const0_rtx, change it to (and:SI (reg:SI) (const_int 255)), to facilitate possible combining with a cmp into 'ands'. */ - if (mode == SImode + if (!op0_preserve_value + mode == SImode GET_CODE (*op0) == ZERO_EXTEND GET_CODE (XEXP (*op0, 0)) == SUBREG GET_MODE (XEXP (*op0, 0)) == QImode This change disables the transformation that the testcase is looking for. Thanks, Kyrill
[Bug libstdc++/55741] [4.8 Regression] bootstrap fails in libstdc++-v3/src/c++11/thread.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55741 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0
[Bug tree-optimization/55755] New: Invalid VIEW_CONVERT_EXPR produced by SRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55755
Bug #: 55755
Summary: Invalid VIEW_CONVERT_EXPR produced by SRA
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jamb...@gcc.gnu.org
Sigh. Even after all those years I can still occasionally come up with
an ICEing SRA testcase (it's basically a slightly modified
/home/mjambor/gcc/mine/src/gcc/testsuite/gcc.dg/torture/pr47228.c).
To be run with -O only, fails on x86_64-linux trunk, 4.7, and 4.6
(when checking is enabled):
/* { dg-do run } */
/* { dg-require-effective-target int32plus } */
struct S4
{
unsigned f0:24;
} __attribute__((__packed__));
struct S4 g_10 = {
6210831
};
struct S5
{
int i;
struct S4 l_8[2];
} __attribute__((__packed__));
int a, b;
struct S4 func_2 (int x)
{
struct S5 l = {
0,
{{0}, {0}}
};
l.i = a;
g_10 = l.l_8[1];
for (; x2; x++) {
struct S4 tmp = {
11936567
};
l.l_8[x] = tmp;
}
b = l.i;
return g_10;
}
int main (void)
{
func_2 (0);
return 0;
}
[Bug tree-optimization/55755] Invalid VIEW_CONVERT_EXPR produced by SRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55755 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-12-20 AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Martin Jambor jamborm at gcc dot gnu.org 2012-12-20 14:28:07 UTC --- Obviously mine. The fix for release branches is probably going to be add !access-grp_unscalarizable_region test to most to a few access_has_children_p tests. The proper fix is to re-work access_has_children_p to a predicate returning true if there are any replacements in any of its children. But let me audit the access_has_children_p tests first.
[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55734 --- Comment #22 from tejohnson at gcc dot gnu.org 2012-12-20 14:31:18 UTC --- Author: tejohnson Date: Thu Dec 20 14:31:09 2012 New Revision: 194634 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194634 Log: Fix PR gcov-profile/55734 by using methods from hwint.c instead of builtins, to handle non-GCC and older versions of GCC. When building libgcov.a, however, hwint.c is not available, but we are always using the bootstrapped compiler and can therefore use the builtins. Use __builtin_popcount instead of __builtin_popcountll, since we are operating on an int. Use floor_log2 directly, instead of clz_hwi for the non-libgcov case, and handle situations where the size of the gcov_type is bigger than HOST_WIDE_INT. Verified that the various cases compiled by forcing different HOST_BITS_PER_WIDE_INT values. 2012-12-20 Teresa Johnson tejohn...@google.com Jakub Jelinek ja...@redhat.com PR gcov-profile/55734 * gcov-io.c (gcov_read_summary): Use __builtin_popcount instead of __builtin_popcountll when building libgcov.a, otherwise use popcount_hwi. (gcov_histo_index): When not building libgcov.a, use floor_log2 instead of __builtin_clzll. Modified: trunk/gcc/ChangeLog trunk/gcc/gcov-io.c
[Bug libstdc++/55741] [4.8 Regression] bootstrap fails in libstdc++-v3/src/c++11/thread.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55741 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2012-12-20 14:37:03 UTC --- Author: redi Date: Thu Dec 20 14:36:56 2012 New Revision: 194635 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194635 Log: PR libstdc++/55741 * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Check for Sleep. * config.h.in: Regenerate. * configure: Regenerate. * src/c++11/thread.cc (__sleep_for): Use Sleep if available. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/config.h.in trunk/libstdc++-v3/configure trunk/libstdc++-v3/src/c++11/thread.cc
[Bug fortran/55756] New: [4.8 regression] FAIL: gfortran.dg/same_type_as_1.f03 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55756
Bug #: 55756
Summary: [4.8 regression] FAIL: gfortran.dg/same_type_as_1.f03
-O (test for excess errors)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sch...@linux-m68k.org
spawn
/daten/aranym/gcc/gcc-20121220/Build/gcc/testsuite/gfortran/../../gfortran
-B/daten/aranym/gcc/gcc-20121220/Build/gcc/testsuite/gfortran/../../
-B/daten/aranym/gcc/gcc-20121220/Build/m68k-linux/./libgfortran/
/daten/aranym/gcc/gcc-20121220/gcc/testsuite/gfortran.dg/same_type_as_1.f03
-fno-diagnostics-show-caret -O -pedantic-errors -S -o same_type_as_1.s
output is:
/daten/aranym/gcc/gcc-20121220/gcc/testsuite/gfortran.dg/same_type_as_1.f03:21.24:
print *, SAME_TYPE_AS (i,x1) ! { dg-error must be of a derived type }
1
Error: 'a' argument of 'same_type_as' intrinsic at (1) cannot be of type
INTEGER(4)
/daten/aranym/gcc/gcc-20121220/gcc/testsuite/gfortran.dg/same_type_as_1.f03:22.27:
print *, SAME_TYPE_AS (x1,x2) ! { dg-error must be of an extensible type }
1
Error: 'b' argument of 'same_type_as' intrinsic at (1) must be of an extensible
type
/daten/aranym/gcc/gcc-20121220/gcc/testsuite/gfortran.dg/same_type_as_1.f03:24.27:
print *, EXTENDS_TYPE_OF (i,x1) ! { dg-error must be of a derived type }
1
Error: 'a' argument of 'extends_type_of' intrinsic at (1) cannot be of type
INTEGER(4)
/daten/aranym/gcc/gcc-20121220/gcc/testsuite/gfortran.dg/same_type_as_1.f03:25.30:
print *, EXTENDS_TYPE_OF (x1,x2) ! { dg-error must be of an extensible type
1
Error: 'mold' argument of 'extends_type_of' intrinsic at (1) must be of an
extensible type
FAIL: gfortran.dg/same_type_as_1.f03 -O (test for errors, line 21)
PASS: gfortran.dg/same_type_as_1.f03 -O (test for errors, line 22)
FAIL: gfortran.dg/same_type_as_1.f03 -O (test for errors, line 24)
PASS: gfortran.dg/same_type_as_1.f03 -O (test for errors, line 25)
FAIL: gfortran.dg/same_type_as_1.f03 -O (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20121220/gcc/testsuite/gfortran.dg/same_type_as_1.f03:21:24:
Error: 'a' argument of 'same_type_as' intrinsic at (1) cannot be of type
INTEGER(4)
/daten/aranym/gcc/gcc-20121220/gcc/testsuite/gfortran.dg/same_type_as_1.f03:24:27:
Error: 'a' argument of 'extends_type_of' intrinsic at (1) cannot be of type
INTEGER(4)
[Bug libstdc++/55741] [4.8 Regression] bootstrap fails in libstdc++-v3/src/c++11/thread.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55741 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2012-12-20 14:37:49 UTC --- should be fixed
[Bug fortran/55756] [4.8 regression] FAIL: gfortran.dg/same_type_as_1.f03 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55756 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug c++/55753] [C++11][4.7/4.8 Regression] ICE constexpr ctor, tsubst_copy_and_build, at cp/pt.c:14336
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55753 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-20 CC||jakub at gcc dot gnu.org Summary|[C++11][4.8 Regression] ICE |[C++11][4.7/4.8 Regression] |constexpr ctor, |ICE constexpr ctor, |tsubst_copy_and_build, at |tsubst_copy_and_build, at |cp/pt.c:14336 |cp/pt.c:14336 Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-20 14:50:31 UTC --- Started to ICE with: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173680 or http://gcc.gnu.org/viewcvs?root=gccview=revrev=173679 or http://gcc.gnu.org/viewcvs?root=gccview=revrev=173678
[Bug c++/55753] [C++11][4.7/4.8 Regression] ICE constexpr ctor, tsubst_copy_and_build, at cp/pt.c:14336
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55753 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-20 14:52:19 UTC --- Probably just ice-checking in 4.7.x though, so with release checking doesn't complain, in 4.8.0 ICEs on gcc_assert (TREE_CONSTANT (...));
[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55734 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-20 14:56:27 UTC --- Fixed.
[Bug rtl-optimization/55757] New: Suboptimal interrupt prologue/epilogue for ARMv7-M (Cortex-M3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55757
Bug #: 55757
Summary: Suboptimal interrupt prologue/epilogue for ARMv7-M
(Cortex-M3)
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: freddie_cho...@op.pl
With a Cortex-M3 microcontroller (ARMv7-M) and an empty interrupt handler
function:
void DMA_IRQHandler(void) __attribute((interrupt));
void DMA_IRQHandler(void)
{
}
Results in suboptimal prologue/epilogue:
23b4 DMA_IRQHandler:
void DMA_IRQHandler(void) __attribute((interrupt));
void DMA_IRQHandler(void)
{
23b4:4668 movr0, sp
23b6:f020 0107 bic.wr1, r0, #7
23ba:468d movsp, r1
23bc:b501 push{r0, lr}
}
23be:e8bd 4001 ldmia.wsp!, {r0, lr}
23c2:4685 movsp, r0
23c4:4770 bxlr
...
Without the __attribute__ the function is fine, just a single bx lr.
This behavior is incorrect not only because r0 and lr are unused, but also
because on ARMv7-M these registers (r0-r3, lr, ip, sp, pc, psr) are saved by
hardware, so there's no point in saving them again.
[Bug fortran/55758] New: LOGICAL and BIND(C): Reject kind=2/4/8/16 with -std=f2008, improve warning, switch to nonBOOLEAN_TYPE for those
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55758 Bug #: 55758 Summary: LOGICAL and BIND(C): Reject kind=2/4/8/16 with -std=f2008, improve warning, switch to nonBOOLEAN_TYPE for those Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: accepts-invalid, diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org See http://gcc.gnu.org/ml/fortran/2012-12/threads.html#00135 In the Fortran standard, only LOGICALs of kind C_BOOL interoperate with C; namely, with C99's _Bool/bool. In C, also integers - in particular int - are used in Boolean expressions, allows for the whole range of integral values - all are true except for 0 which is false. gcc's _Bool and gfortran's LOGICAL all assume a binary state (BOOLEAN_TYPE) which is either 0 or 1 such that .NOT. can be implemented by flipping a single bit. Hence, regarding an int as BOOLEAN_TYPE leads to .NOT.(-1) = -2. Currently, LOGICAL(kind=C_INT) (c_int == 4) is accepted by gfortran and C binding, but it might lead to wrong results with .NOT. Expected: * With -std=f95/f2003/f2008/f2008tr, only LOGICAL with kind=C_BOOL (C_BOOL == 1) is accepted * With -std=gnu, also the others (2,4,8,16) are accepted but a warning is printed for them. * Consider replacing internally BOOLEAN_TYPE by a signed-integer type LOGICAL with kind /= C_BOOL in procedures with C binding
[Bug regression/55754] FAIL: gcc.target/arm/unsigned-extend-2.c scan-assembler ands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55754 --- Comment #2 from Andreas Krebbel krebbel at gcc dot gnu.org 2012-12-20 15:20:17 UTC --- Author: krebbel Date: Thu Dec 20 15:20:06 2012 New Revision: 194636 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194636 Log: 2012-12-20 Andreas Krebbel andreas.kreb...@de.ibm.com PR target/55754 * config/arm/arm.c (arm_canonicalize_comparison): Remove op0_preserve_value check for zero_extend to and transformation. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c
[Bug rtl-optimization/55757] Suboptimal interrupt prologue/epilogue for ARMv7-M (Cortex-M3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55757
--- Comment #1 from Freddie Chopin freddie_chopin at op dot pl 2012-12-20
15:23:25 UTC ---
BTW - it seems that optimization settings don't make any difference here - the
code below was compiled with -Os, on all other levels (1,2,3) the assembly
looks like this:
2e90 DMA_IRQHandler:
void DMA_IRQHandler(void) __attribute((interrupt));
void DMA_IRQHandler(void)
{
2e90:4668 movr0, sp
2e92:f020 0107 bic.wr1, r0, #7
2e96:468d movsp, r1
2e98:b401 push{r0}
}
2e9a:bc01 pop{r0}
2e9c:4685 movsp, r0
2e9e:4770 bxlr
So it just saves r0 only, without saving lr. It's actually 2 bytes smaller than
the assembly done for size optimizations (;
Without optimization (-O0) I get:
473c DMA_IRQHandler:
void DMA_IRQHandler(void) __attribute((interrupt));
void DMA_IRQHandler(void)
{
473c:4668 movr0, sp
473e:f020 0107 bic.wr1, r0, #7
4742:468d movsp, r1
4744:b481 push{r0, r7}
4746:af00 addr7, sp, #0
}
4748:46bd movsp, r7
474a:bc81 pop{r0, r7}
474c:4685 movsp, r0
474e:4770 bxlr
The commandline options used to compile:
arm-none-eabi-gcc -c -mcpu=cortex-m3 -mthumb -O0 -ffunction-sections
-fdata-sections -Wall -Wstrict-prototypes -Wextra -std=gnu99 -g -ggdb3
-fverbose-asm -Wa,-ahlms=out/uart.lst -MD -MP -MF out/uart.d some include
dirs input file output file
[Bug c++/52343] [C++11] alias-definition dont work in `templateclass` params type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52343 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org |
[Bug fortran/55756] [4.8 regression] FAIL: gfortran.dg/same_type_as_1.f03 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55756 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-12-20 CC||burnus at gcc dot gnu.org AssignedTo|unassigned at gcc dot |pault at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-20 15:28:54 UTC --- Side effect of the patch http://gcc.gnu.org/ml/fortran/2012-12/msg00115.html - hence assigned to Paul. The dg-error string hadn't been updated after the message has been improved. Sorry for the breakage.
[Bug regression/55759] New: bogus warning when building drivers/ata/libata-core.c in v3.7 of the linux kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55759 Bug #: 55759 Summary: bogus warning when building drivers/ata/libata-core.c in v3.7 of the linux kernel Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: b...@alien8.de Hi, when building kernel v3.7 with Debian's gcc: (Debian 4.7.2-4) 4.7.2, I get the following warning: $ make CC=gcc-4.7 drivers/ata/libata-core.o make[1]: Nothing to be done for `all'. make[1]: Nothing to be done for `relocs'. CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CC kernel/bounds.s GEN include/generated/bounds.h CC arch/x86/kernel/asm-offsets.s GEN include/generated/asm-offsets.h CALLscripts/checksyscalls.sh CC scripts/mod/empty.o MKELF scripts/mod/elfconfig.h HOSTCC scripts/mod/file2alias.o HOSTCC scripts/mod/modpost.o HOSTCC scripts/mod/sumversion.o HOSTLD scripts/mod/modpost CC drivers/ata/libata-core.o drivers/ata/libata-core.c: In function ‘ata_hpa_resize’: drivers/ata/libata-core.c:1397:3: warning: ‘native_sectors’ may be used uninitialized in this function [-Wmaybe-uninitialized] $ it falsely complains that native_sectors might be used unitialized. The variable's value is assigned-to in an auxiliary function and passed to it as a pointer. The auxiliary function returns negative value on error and 0 on success and its caller uses the native_sectors value returned over the pointer only in the success case and in that case, native_sectors is always properly initialized. Also, gcc-4.6 (gcc-4.6 (Debian 4.6.3-14) 4.6.3) doesn't trigger that same warning: $ make CC=gcc-4.6 drivers/ata/libata-core.o make[1]: Nothing to be done for `all'. make[1]: Nothing to be done for `relocs'. CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CALLscripts/checksyscalls.sh CC drivers/ata/libata-core.o $ Thanks.
[Bug tree-optimization/55723] loop vectorization inefficient in presence of multiple identical conditions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55723
vincenzo Innocente vincenzo.innocente at cern dot ch changed:
What|Removed |Added
Summary|SLP vectorization vs loop: |loop vectorization
|SLP more efficient: loop|inefficient in presence of
|vectorization inefficient |multiple identical
|in presence of multiple |conditions
|blends|
--- Comment #2 from vincenzo Innocente vincenzo.innocente at cern dot ch
2012-12-20 15:39:13 UTC ---
It seems that in presence of identical conditions the vectorizer prefers to
compute two full branches
and do just one blend.
This is not always the most efficient choice as the benchmark in comment 1
demonstrates.
Another simple example:
for bar two rsqrtps and one blend
for foo one rsqrtps and two blends
#includecmath
float a[1024];
float b[1024];
void bar(){
for (int i=0;i!=1024;++i) {
auto z = a[i];
if (a[i] 3.14f) z-=1.f;
b[i] = 1.f/std::sqrt(z);
if (a[i] 3.14f) b[i]-=1.f;
}
}
void foo(){
for (int i=0;i!=1024;++i) {
auto z = a[i];
if (a[i] 3.14f) z-=1.f;
b[i] = 1.f/std::sqrt(z);
if (a[i] 1.f) b[i]-=1.f;
}
}
c++ -std=c++11 -Ofast -march=corei7 -S twoif.cc -ftree-vectorizer-verbose=1
-ftree-loop-if-convert-stores; cat twoif.s | c++filt
bar():
LFB221:
movapsLC0(%rip), %xmm6
leaqsigned char(%rip), %rax
movapsLC1(%rip), %xmm5
leaqbool(%rip), %rdx
movapsLC2(%rip), %xmm4
leaq4096+signed char(%rip), %rcx
movapsLC3(%rip), %xmm7
.align 4,0x90
L3:
movaps(%rax), %xmm0
addq$16, %rax
addq$16, %rdx
rsqrtps%xmm0, %xmm3
movaps%xmm0, %xmm2
subps%xmm6, %xmm2
rsqrtps%xmm2, %xmm1
mulps%xmm1, %xmm2
mulps%xmm1, %xmm2
mulps%xmm4, %xmm1
addps%xmm5, %xmm2
mulps%xmm1, %xmm2
movaps%xmm3, %xmm1
mulps%xmm0, %xmm1
subps%xmm6, %xmm2
mulps%xmm3, %xmm1
mulps%xmm4, %xmm3
addps%xmm5, %xmm1
mulps%xmm3, %xmm1
movaps%xmm7, %xmm3
cmpltps%xmm0, %xmm3
movaps%xmm3, %xmm0
blendvps%xmm0, %xmm2, %xmm1
movaps%xmm1, -16(%rdx)
cmpq%rcx, %rax
jneL3
rep; ret
LFE221:
.align 4,0x90
.globl foo()
foo():
LFB222:
movapsLC3(%rip), %xmm7
leaqsigned char(%rip), %rax
movapsLC0(%rip), %xmm3
leaqbool(%rip), %rdx
movapsLC1(%rip), %xmm6
leaq4096+signed char(%rip), %rcx
movapsLC2(%rip), %xmm5
.align 4,0x90
L7:
movaps(%rax), %xmm2
movaps%xmm7, %xmm0
addq$16, %rax
addq$16, %rdx
movaps%xmm2, %xmm1
cmpltps%xmm2, %xmm0
movaps%xmm2, %xmm4
subps%xmm3, %xmm1
blendvps%xmm0, %xmm1, %xmm4
rsqrtps%xmm4, %xmm0
movaps%xmm4, %xmm1
mulps%xmm0, %xmm1
mulps%xmm0, %xmm1
mulps%xmm5, %xmm0
addps%xmm6, %xmm1
mulps%xmm0, %xmm1
movaps%xmm3, %xmm0
cmpltps%xmm2, %xmm0
movaps%xmm1, %xmm4
subps%xmm3, %xmm4
blendvps%xmm0, %xmm4, %xmm1
movaps%xmm1, -16(%rdx)
cmpq%rcx, %rax
jneL7
rep; ret
[Bug regression/55759] bogus warning when building drivers/ata/libata-core.c in v3.7 of the linux kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55759 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-12-20 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2012-12-20 15:43:24 UTC --- Please provide preprocessed source.
[Bug regression/55754] FAIL: gcc.target/arm/unsigned-extend-2.c scan-assembler ands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55754 --- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-12-20 15:44:23 UTC --- (In reply to comment #1) This hunk needs to be reverted. op0 is modified but it is set to an equivalent value. Perhaps you could update the documentation to make that clearer. Eg, by adding to the example a safe transformation (like this one).
[Bug tree-optimization/55760] New: scalar code non using rsqrtss and rcpss
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55760
Bug #: 55760
Summary: scalar code non using rsqrtss and rcpss
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
is there any reason why rsqrtss and rcpss are not used for scalar code while
rsqrtps and rcpps are used for loops?
cat scalar.cc
#includecmath
void scalar(float a, float b) {
a = std::sqrt(a);
b = 1.f/b;
}
float v[1024];
float w[1024];
void vector() {
for(int i=0;i!=1024;++i) {
v[i] = std::sqrt(v[i]);
w[i] = 1.f/w[i];
}
}
c++ -std=c++11 -Ofast -march=corei7 -S scalar.cc -ftree-vectorizer-verbose=1
-ftree-loop-if-convert-stores; cat scalar.s | c++filt
scalar(float, float):
LFB221:
sqrtss(%rdi), %xmm0
movss%xmm0, (%rdi)
movssLC0(%rip), %xmm0
divss(%rsi), %xmm0
movss%xmm0, (%rsi)
ret
LFE221:
.align 4,0x90
.globl vector()
vector():
LFB222:
movapsLC1(%rip), %xmm5
leaqvoid(%rip), %rax
xorps%xmm3, %xmm3
movapsLC2(%rip), %xmm4
leaqwchar_t(%rip), %rdx
leaq4096+void(%rip), %rcx
.align 4,0x90
L4:
movaps(%rax), %xmm1
movaps%xmm3, %xmm2
addq$16, %rax
addq$16, %rdx
rsqrtps%xmm1, %xmm0
cmpneqps%xmm1, %xmm2
andps%xmm2, %xmm0
mulps%xmm0, %xmm1
mulps%xmm1, %xmm0
mulps%xmm4, %xmm1
addps%xmm5, %xmm0
mulps%xmm1, %xmm0
movaps%xmm0, -16(%rax)
movaps-16(%rdx), %xmm1
rcpps%xmm1, %xmm0
mulps%xmm0, %xmm1
mulps%xmm0, %xmm1
addps%xmm0, %xmm0
subps%xmm1, %xmm0
movaps%xmm0, -16(%rdx)
cmpq%rcx, %rax
jneL4
rep; ret
[Bug tree-optimization/55761] New: process_assignment assumes -1 can be created
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
Bug #: 55761
Summary: process_assignment assumes -1 can be created
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pa...@matos-sorge.com
Created attachment 29013
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29013
breaks GCC4.7.2 x86_64
Hello,
process_assignment in tree-tailcall.c assumes constant -1 can be created in any
mode (that matches all the conditions up until this point) in the line:
*m = build_int_cst (TREE_TYPE (non_ass_var), -1);
If, however, TREE_TYPE of non_ass_var of vector type for example, an ICE
occurs.
The following example breaks my port, x86_64 and probably more:
typedef short V4H __attribute__ ((vector_size (8)));
extern V4H __fp_rep_h (unsigned short B);
V4H
fn1 ()
{
V4H vuq = __fp_rep_h (0);
vuq -= __fp_rep_h (1);
return vuq;
}
In processing assignment vuq = vuq - vuq0; (where vuq0 = __fp_rep_h (1)), we
try to create multiplier -1 with type V4H and that fails in build_int_cst_wide.
We need to check if it's of integral type and only ten apply build_int_cst.
Otherwise we should use fold_build1.
I tested GCC 4.7.2:
$ gcc -O2 baaclc_block.i
baaclc_block.i: In function 'fn1':
baaclc_block.i:10:1: internal compiler error: in build_int_cst_wide, at
tree.c:1222
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
$ $ gcc -v
Using built-in specs.
COLLECT_GCC=/tools/oss/packages/x86_64-rhel5/gcc/4.7.2/bin/gcc
COLLECT_LTO_WRAPPER=/tools/oss/packages/x86_64-rhel5/gcc/4.7.2/libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc-4.7.2/configure
--prefix=/tools/oss/packages/x86_64-rhel5/gcc/4.7.2 --with-gnu-as
--with-as=/tools/oss/packages/x86_64-rhel5/binutils/default/bin/as
--with-gnu-ld
--with-ld=/tools/oss/packages/x86_64-rhel5/binutils/default/bin/ld
--with-mpc=/tools/oss/packages/x86_64-rhel5/mpc/0.8.1
--with-mpfr=/tools/oss/packages/x86_64-rhel5/mpfr/2.4.2
--with-gmp=/tools/oss/packages/x86_64-rhel5/gmp/4.3.2
--enable-languages=c,c++,objc,fortran --enable-symvers=gnu
Thread model: posix
gcc version 4.7.2 (GCC)
[Bug tree-optimization/55760] scalar code non using rsqrtss and rcpss
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55760 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2012-12-20 15:52:31 UTC --- Use -mrecip. It's otherwise not safe for SPEC CPU 2006 which is why it is not enabled by default for -ffast-math.
[Bug tree-optimization/55761] process_assignment assumes -1 can be created
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761 --- Comment #1 from Paulo J. Matos pa...@matos-sorge.com 2012-12-20 15:53:48 UTC --- This happens for the negate_expr case too in the same switch. I have a patch to fix this that I will upload momentarily.
[Bug tree-optimization/55760] scalar code non using rsqrtss and rcpss
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55760 --- Comment #2 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-12-20 15:55:03 UTC --- Thanks. not safe meaning producing incorrect results? Is it documented?
[Bug tree-optimization/55761] process_assignment assumes -1 can be created
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-20 Ever Confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2012-12-20 15:55:22 UTC --- Confirmed. It already handles floats. Easiest would be to add a build_minus_one_cst helper in tree.c alongside build_one_cst.
[Bug driver/55202] Building a combined tree is broken for LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55202 --- Comment #7 from Thomas Schwinge tschwinge at gcc dot gnu.org 2012-12-20 15:57:21 UTC --- Author: tschwinge Date: Thu Dec 20 15:57:18 2012 New Revision: 194637 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194637 Log: PR bootstrap/55202 * configure.ac PLUGIN_LD_SUFFIX: Use POSIX shell syntax. * configure: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac
[Bug tree-optimization/55760] scalar code non using rsqrtss and rcpss
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55760 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2012-12-20 15:58:55 UTC --- (In reply to comment #2) Thanks. not safe meaning producing incorrect results? Yes. Is it documented? See the documentation for -mrecip: ... Note that while the throughput of the sequence is higher than the throughput of the non-reciprocal instruction, the precision of the sequence can be decreased by up to 2 ulp (i.e. the inverse of 1.0 equals 0.9994). ...
[Bug tree-optimization/55761] process_assignment assumes -1 can be created
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761 --- Comment #3 from Paulo J. Matos pa...@matos-sorge.com 2012-12-20 16:01:23 UTC --- Created attachment 29014 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29014 Use built_int_cst only for integral types, otherwise use fold_build1
[Bug fortran/55762] New: Diagnostic: Passing a procedure to LEN should tell that one has passed a procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55762 Bug #: 55762 Summary: Diagnostic: Passing a procedure to LEN should tell that one has passed a procedure Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Reported at http://gcc.gnu.org/ml/fortran/2012-12/msg00145.html s is declared as CHARACTER, but it is also used as s(i), hence, it is marked as function. That leads to the error message: n = len(s) 1 Error: 'string' argument of 'len' intrinsic at (1) must be CHARACTER It would be more helpful to state that S is a function (procedure) in this case - as NAG or g95 do: Error: Argument STRING to the LEN intrinsic is a procedure Type of argument 'string' in call to 'len' at (1) should be CHARACTER(1), not PROCEDURE
[Bug tree-optimization/55760] scalar code non using rsqrtss and rcpss
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55760 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-12-20 16:07:11 UTC --- is there any reason why rsqrtss and rcpss are not used for scalar code while rsqrtps and rcpps are used for loops? Yep! I don't have the patience to dig the bugzilla archive right now, but the main reason is related to a loss of accuracy (especially 1/2.0 != 0.5) leading to problems in some codes (see gas_dyn.f90 in the polyhedron tests). You can pass options to force the use of rsqrtss and rcpss for scalars: -mrecip This option enables use of RCPSS and RSQRTSS instructions (and their vectorized variants RCPPS and RSQRTPS) with an additional Newton-Raphson step to increase precision instead of DIVSS and SQRTSS (and their vectorized variants) for single-precision floating-point arguments. These instructions are generated only when -funsafe-math-optimizations is enabled together with -finite-math-only and -fno-trapping-math. Note that while the throughput of the sequence is higher than the throughput of the non-reciprocal instruction, the precision of the sequence can be decreased by up to 2 ulp (i.e. the inverse of 1.0 equals 0.9994). Note that GCC implements 1.0f/sqrtf(x) in terms of RSQRTSS (or RSQRTPS) already with -ffast-math (or the above option combination), and doesn't need -mrecip. Also note that GCC emits the above sequence with additional Newton-Raphson step for vectorized single-float division and vectorized sqrtf(x) already with -ffast-math (or the above option combination), and doesn't need -mrecip. -mrecip=opt This option controls which reciprocal estimate instructions may be used. opt is a comma-separated list of options, which may be preceded by a `!' to invert the option: `all' Enable all estimate instructions. `default' Enable the default instructions, equivalent to -mrecip. `none' Disable all estimate instructions, equivalent to -mno-recip. `div' Enable the approximation for scalar division. `vec-div' Enable the approximation for vectorized division. `sqrt' Enable the approximation for scalar square root. `vec-sqrt' Enable the approximation for vectorized square root. So, for example, -mrecip=all,!sqrt enables all of the reciprocal approximations, except for square root.
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 --- Comment #34 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-12-20 16:14:46 UTC --- (In reply to comment #33) Using--with-build-config=bootstrap-asan should do that for you. Seems like I'm doing something wrong, this fails for me after configuring with: ../gcc/configure --prefix=/data/vjoost/gnu/gcc_trunk/install --enable-languages=c,c++,fortran --disable-multilib --enable-plugins --disable-werror --with-build-config=bootstrap-asan /data/vjoost/gnu/binutils-2.23.1/install/bin/ld: error: /data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/libasan.a(asan_new_delete.o): multiple definition of 'operator new(unsigned long)' /data/vjoost/gnu/binutils-2.23.1/install/bin/ld: /data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(new_op.o): previous definition here /data/vjoost/gnu/binutils-2.23.1/install/bin/ld: error: /data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/libasan.a(asan_new_delete.o): multiple definition of 'operator delete(void*)' /data/vjoost/gnu/binutils-2.23.1/install/bin/ld: /data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(del_op.o): previous definition here collect2: error: ld returned 1 exit status make[3]: *** [xgcc] Error 1 make[3]: *** Waiting for unfinished jobs /data/vjoost/gnu/binutils-2.23.1/install/bin/ld: error: /data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/libasan.a(asan_new_delete.o): multiple definition of 'operator new(unsigned long)' /data/vjoost/gnu/binutils-2.23.1/install/bin/ld: /data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(new_op.o): previous definition here /data/vjoost/gnu/binutils-2.23.1/install/bin/ld: error: /data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/libasan.a(asan_new_delete.o): multiple definition of 'operator delete(void*)' /data/vjoost/gnu/binutils-2.23.1/install/bin/ld: /data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(del_op.o): previous definition here collect2: error: ld returned 1 exit status make[3]: *** [xg++] Error 1
[Bug c/55749] gcc 4.7.1 removes labels mistakenly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55749 --- Comment #2 from blue_3too at hotmail dot com 2012-12-20 16:17:20 UTC --- Thanks for the comments. I checked the document @ gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html . But find no description hat label-as-a-value should be used with computed goto. Can you be more specific about where is the decription from? But back to my problem: my_labe is a resuming point for a thread to acquire a lock after being blocked on the lock and slept. When it is waken, it should resume execution from my_label. So I guess it conradicts with following description in the doc: You may not use this mechanism to jump to code in a different function. If you do that, totally unpredictable things happen. The best way to avoid this is to store the label address only in automatic variables and never pass it as an argument. Because the label is passed out of the function, it is used to jump back the function when the sleeping thread is awaken. Now
[Bug fortran/55763] New: Issues with some simpler CLASS(*) programs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55763 Bug #: 55763 Summary: Issues with some simpler CLASS(*) programs Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: pa...@gcc.gnu.org There are some known bigger issues of CLASS(*) which are tracked elsewhere. This is about simpler issues. The following program by Reinhold Bader fails with a bogus: type is (integer) 1 alloc_scalar_01_pos.f90:27.15: class default 2 Error: The DEFAULT CASE at (1) cannot be followed by a second DEFAULT CASE at (2) ! module mod_alloc_scalar_01 contains subroutine construct(this) class(*), allocatable, intent(out) :: this integer :: this_i this_i = 4 allocate(this, source=this_i) end subroutine end module program alloc_scalar_01 use mod_alloc_scalar_01 implicit none class(*), allocatable :: mystuff call construct(mystuff) call construct(mystuff) select type(mystuff) type is (integer) if (mystuff == 4) then write(*,*) 'OK' else write(*,*) 'FAIL 1' end if class default write(*,*) 'FAIL 2' end select end program ! While the following program by the same author causes an ICE (segmentation fault) at 0x5573ac get_unique_type_string ../../gcc/fortran/class.c:447 0x557ef8 get_unique_hashed_string ../../gcc/fortran/class.c:470 0x558087 gfc_find_derived_vtab(gfc_symbol*) ../../gcc/fortran/class.c:1833 0x625d18 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vectree_node*, va_gc, vl_embed*) ../../gcc/fortran/trans-expr.c:4308 ! module mod_alloc_scalar_02 contains subroutine construct(this) class(*), allocatable, intent(out) :: this integer :: this_i this_i = 4 allocate(this, source=this_i) end subroutine subroutine out(this) class(*) :: this select type(this) type is (integer) if (this == 4) then write(*,*) 'OK' else write(*,*) 'FAIL 1' end if class default write(*,*) 'FAIL 2' end select end subroutine end module program alloc_scalar_02 use mod_alloc_scalar_02 implicit none class(*), allocatable :: mystuff call construct(mystuff) call out(mystuff) end program ! And the following MOVE_ALLOC code, which moves TYPE(integer) to CLASS(*) fails with: call move_alloc(i2, i1) 1 Error: The FROM and TO arguments of the MOVE_ALLOC intrinsic at (1) must be of the same kind 4/0 ! program mvall_03 implicit none integer, parameter :: n1 = 100, n2 = 200 class(*), allocatable :: i1(:) integer, allocatable :: i2(:) allocate(real :: i1(n1)) allocate(i2(n2)) i2 = 2 call move_alloc(i2, i1) if (size(i1) /= n2 .or. allocated(i2)) then write(*,*) 'FAIL' else write(*,*) 'OK' end if end program ! And finally, the following program - again by Reinhold Bader - gives an ICE (segfault) at vector_comp = field 0x62d477 gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*) ../../gcc/fortran/trans-expr.c:6523 ! program change_field_type use, intrinsic :: iso_c_binding implicit none TYPE, BIND(C) :: scalar_vector REAL(kind=c_float) :: scalar REAL(kind=c_float) :: vec(3) END TYPE TYPE, BIND(C) :: scalar_vector_matrix REAL(kind=c_float) :: scalar REAL(kind=c_float) :: vec(3) REAL(kind=c_float) :: mat(3,3) END TYPE CLASS(*), ALLOCATABLE, TARGET :: one_d_field(:) real, pointer :: v1(:) allocate(one_d_field(3), source = (/ scalar_vector( 1.0, (/ -1.0, 0.0, 1.0 /) ), scalar_vector( 1.1, (/ -1.2, 0.2, 0.9 /) ), scalar_vector( 1.2, (/ -1.4, 0.4, 0.8 /) ) /) ) call extract_vec(one_d_field, 1, v1, 2) print *, v1 deallocate(one_d_field) ! v1 becomes undefined allocate(one_d_field(1), source = (/ scalar_vector_matrix( 1.0, (/ -1.0, 0.0, 1.0 /), reshape( (/ 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0 /), (/3, 3/) ) ) /) ) call extract_vec(one_d_field, 2, v1, 1) print *, v1 deallocate(one_d_field) ! v1 becomes undefined contains subroutine extract_vec(field, tag, vector_comp, ic) use, intrinsic :: iso_c_binding
[Bug c/55749] gcc 4.7.1 removes labels mistakenly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55749 --- Comment #3 from blue_3too at hotmail dot com 2012-12-20 16:18:23 UTC --- Thanks for the comments. I checked the document @ gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html . But find no description hat label-as-a-value should be used with computed goto. Can you be more specific about where is the description from? But back to my problem: my_labe is a resuming point for a thread to acquire a lock after being blocked on the lock and slept. When it is waken, it should resume execution from my_label. So I guess it contradicts with following description in the doc: You may not use this mechanism to jump to code in a different function. If you do that, totally unpredictable things happen. The best way to avoid this is to store the label address only in automatic variables and never pass it as an argument. Because the label is passed out of the function, it is used to jump back the function when the sleeping thread is awaken. Not sure how to implement this properly.
[Bug regression/55759] bogus warning when building drivers/ata/libata-core.c in v3.7 of the linux kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55759 --- Comment #2 from Boris bp at alien8 dot de 2012-12-20 16:20:34 UTC --- Created attachment 29015 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29015 gzipped preprocessed source of drivers/ata/libata-core.c
[Bug fortran/55763] Issues with some simpler CLASS(*) programs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55763 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-20 16:30:23 UTC --- Another follow up: The following code causes an ICE (segfault): 0x5989bc select_type_set_tmp ../../gcc/fortran/match.c:5299 0x5a0015 gfc_match_type_is() ../../gcc/fortran/match.c:5556 If one changes the commented lines, one gets the bogus error message: type is (integer) 1 Error: Assumed shape array at (1) must be a dummy argument ! module mpi_f08_f implicit none abstract interface subroutine user_function( inoutvec ) class(*), dimension(:), intent(inout) :: inoutvec end subroutine user_function end interface end module module mod_test use mpi_f08_f implicit none contains subroutine my_function( invec ) ! ICE ! subroutine my_function( inoutvec ) ! BOGUS ERROR class(*), dimension(:), intent(inout) :: inoutvec select type (inoutvec) type is (integer) inoutvec = 2*inoutvec end select end subroutine my_function end module !
[Bug regression/55759] bogus warning when building drivers/ata/libata-core.c in v3.7 of the linux kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55759 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-12-20 16:38:04 UTC --- It only happens with -Os, -O2 is fine. gcc-4.8 is also affected. I'm reducing this testcase right now.
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 --- Comment #35 from Jack Howarth howarth at nitro dot med.uc.edu 2012-12-20 16:41:58 UTC --- (In reply to comment #34) You might try https://github.com/mirrors/gcc/tree/hjl/asan. Perhaps H.J. still has some patches from his branch that are not committed into gcc trunk.
[Bug rtl-optimization/55757] Suboptimal interrupt prologue/epilogue for ARMv7-M (Cortex-M3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55757 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-20 Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-12-20 16:52:05 UTC --- The code is there to re-align the stack to 64-bit alignment as required by the ABI (early versions of the M3 did not have the ability to do this in HW). The reason two registers are pushed, rather than one is that this is also needed to keep the stack aligned and pushing two registers uses less code than adjusting the stack in a separate insn. Of course, in this trivial case, the stack realignment isn't necessary as the compiler should be able to tell that nothing requires re-alignment of the stack. But it's a corner case and it's much more common for this to be needed. If you really know that you don't need stack-alignment on an M3, then just remove the interrupt attribute. It really doesn't serve any other purpose on M-profile cores other than to cause the stack realignment. Marking as an enhancement. The code generated today is correct, but sub-optimal.
[Bug java/55764] New: [4.8 Regression] ICE when building frysk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55764 Bug #: 55764 Summary: [4.8 Regression] ICE when building frysk Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: error-recovery Severity: normal Priority: P3 Component: java AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: a...@gcc.gnu.org ./jc1 jdom.jar -fhash-synchronization -fno-use-divide-subroutine \ -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions -quiet -g -O \ -o /tmp/jdom.s -fbootclasspath=../i686-pc-linux-gnu/libjava/libgcj-4.8.0.jar gives: In file included from org/jdom/transform/XSLTransformer.java:289:0, from org/jdom/transform/XSLTransformException.java:81, ... from org/jdom/Attribute.java:728, from built-in:5: org/jdom/xpath/JaxenXPath.java:0:0: error: cannot find file for class org.jaxen.SimpleNamespaceContext org/jdom/xpath/JaxenXPath.java:0:0: error: cannot find file for class org.jaxen.SimpleNamespaceContext org/jdom/xpath/JaxenXPath.java: In class 'org.jdom.xpath.JaxenXPath$NSContext': org/jdom/xpath/JaxenXPath.java: In constructor '(org.jdom.xpath.JaxenXPath)': In file included from org/jdom/transform/XSLTransformer.java:289:0, from org/jdom/transform/XSLTransformException.java:81, ... from org/jdom/Attribute.java:728, from built-in:5: org/jdom/xpath/JaxenXPath.java:309:0: internal compiler error: in operator[], at vec.h:816 0x81b0d7c vectree_node*, va_gc, vl_embed::operator[](unsigned int) ../../gcc/vec.h:816 0x81b0d7c class_depth(tree_node*) ../../gcc/java/class.c:577 0x81d435d can_widen_reference_to(tree_node*, tree_node*) ../../gcc/java/expr.c:546 0x81e9f93 vfy_is_assignable_from(tree_node*, tree_node*) ../../gcc/java/verify-glue.c:227 0x81ebd2b ref_compatible ../../gcc/java/verify-impl.c:376 0x81ebd2b types_compatible ../../gcc/java/verify-impl.c:686 0x81ed1e1 verify_instructions_0 ... Frysk probably doesn't build even with older gcj and dunno why we still have it in the distro at all, so the errors aren't a big deal, but the ICE shouldn't happen.
[Bug c/55749] gcc 4.7.1 removes labels mistakenly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55749 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2012-12-20 16:54:53 UTC --- To use these values, you need to be able to jump to one. This is done with the computed goto statement1, goto *exp;. Not sure how to implement this properly. Use either setjmp/longjmp or getcontext/setcontext/makecontext instead.
[Bug tree-optimization/55761] process_assignment assumes -1 can be created
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
--- Comment #4 from Paulo J. Matos pa...@matos-sorge.com 2012-12-20 16:58:08
UTC ---
I created a new patch from your comment to gcc-patches:
diff --git a/gcc/tree-tailcall.c b/gcc/tree-tailcall.c
index 5b1fd2b..8c7d142 100644
--- a/gcc/tree-tailcall.c
+++ b/gcc/tree-tailcall.c
@@ -326,26 +326,14 @@ process_assignment (gimple stmt, gimple_stmt_iterator
call
return true;
case NEGATE_EXPR:
- if (FLOAT_TYPE_P (TREE_TYPE (op0)))
-*m = build_real (TREE_TYPE (op0), dconstm1);
- else
-*m = build_int_cst (TREE_TYPE (op0), -1);
-
+ *m = fold_unary (NEGATE_EXPR, TREE_TYPE (op0), op0);
*ass_var = dest;
return true;
case MINUS_EXPR:
- if (*ass_var == op0)
-*a = fold_build1 (NEGATE_EXPR, TREE_TYPE (non_ass_var), non_ass_var);
- else
-{
- if (FLOAT_TYPE_P (TREE_TYPE (non_ass_var)))
-*m = build_real (TREE_TYPE (non_ass_var), dconstm1);
- else
-*m = build_int_cst (TREE_TYPE (non_ass_var), -1);
-
- *a = fold_build1 (NEGATE_EXPR, TREE_TYPE (non_ass_var),
non_ass_var);
-}
+*a = fold_unary (NEGATE_EXPR, TREE_TYPE (non_ass_var), non_ass_var);
+ if (*ass_var == op1)
+*m = fold_unary (NEGATE_EXPR, TREE_TYPE (non_ass_var), non_ass_var);
*ass_var = dest;
return true;
However, I am less confident that it works now. Mainly because of the *m in
MINUS_EXPR. It seems from the comments in tailcall structure that m should be
-1, not (NEGATE non_ass_var). However, we cannot really create a -1 for vectors
straightforwardly.
I guess that, as per your comment below, we would need a build_minus_one_cst
that handles not only scalar types but also vector types.
[Bug tree-optimization/55761] process_assignment assumes -1 can be created
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
--- Comment #5 from Paulo J. Matos pa...@matos-sorge.com 2012-12-20 17:06:04
UTC ---
As per previous comments, I looks at build_one_cst and implemented
build_minus_one_cst:
tree
build_minus_one_cst (tree type)
{
switch (TREE_CODE (type))
{
case INTEGER_TYPE: case ENUMERAL_TYPE: case BOOLEAN_TYPE:
case POINTER_TYPE: case REFERENCE_TYPE:
case OFFSET_TYPE:
return build_int_cst (type, -1);
case REAL_TYPE:
return build_real (type, dconstm1);
case VECTOR_TYPE:
{
tree scalar = build_minus_one_cst (TREE_TYPE (type));
return build_vector_from_val (type, scalar);
}
case COMPLEX_TYPE:
return build_complex (type,
build_minus_one_cst (TREE_TYPE (type)),
build_zero_cst (TREE_TYPE (type)));
case FIXED_POINT_TYPE:
default:
gcc_unreachable ();
}
}
However, I am unsure on how to best model the FIXED_POINT_TYPE case, if at all
possible.
[Bug rtl-optimization/55757] Suboptimal interrupt prologue/epilogue for ARMv7-M (Cortex-M3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55757
--- Comment #3 from Freddie Chopin freddie_chopin at op dot pl 2012-12-20
17:07:47 UTC ---
Indeed that's a trivial case, but other - useful - cases also show strange
behavior which I cannot clearly explain, so while we're at it I'd be grateful
for some explanation...
An interrupt handler function (void something(void)), but without attribute,
doing something inside (posts a FreeRTOS semaphore, calls vPortYieldFromISR()
if it's needed) actually saves a lot of registers on entry:
23b4:b507 push{r0, r1, r2, lr}
From what I know r0-r3 as scratch registers don't need to be saved on entry, as
it's the callers duty. There are also no parameters to be saved, as it's a void
function...
I observed the same behavior with some non-trivial functions from the lwIP
TCP/IP stack - they are also save scratch registers on entry, even when they
are void ...(void):
5d00 dns_init:
void
dns_init()
{
5d00:b537 push{r0, r1, r2, r4, r5, lr}
Is that a bug or maybe I don't understand the calling conventions? ;
BTW:
The reason two registers are pushed, rather than one is that this is also
needed to
keep the stack aligned and pushing two registers uses less code than
adjusting the stack in a separate insn.
But for optimization level 1, 2 and 3 only one reg is pushed...
Thx in advance!
[Bug fortran/55765] New: Remaining issues with unlimited polymorphic (CLASS(*))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55765
Bug #: 55765
Summary: Remaining issues with unlimited polymorphic (CLASS(*))
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: pa...@gcc.gnu.org
Depends on: 55763
Issues related to CLASS(*)
- Smaller bugs, cf. PR 55763
- As mentioned in the submittal email,
http://gcc.gnu.org/ml/fortran/2012-12/msg00090.html
Some parts of the code, relating to the handling of intrinsic
expressions, are near duplicates of exiting code for derived types;
for example class.c( gfc_find_intrinsic_vtab). I did this in order to
maximise the separation of the treatment of unlimited polymorphism
from existing code in the compiler in order that the risk of
regression be minimised. This new code can be absorbed later on; eg.
gfc_find_intrinsic_vtab into gfc_find_derived_vtab.
- CLASS(*) currently doesn't handle nonconstant strings. Currently, for each
string a new __vtab is generated which encodes the string length. The proper
way is to store the information in the variable itself. There are two
possibilities: (a) Either extend the class container to store this information
(b) Use an array descriptor or similar to store this information
(b) requires the new array descriptor and is in line of TR 29113:2012, where at
least for strings the full array descriptor is passed (with BIND(C)), cf.
ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1942.pdf See 8.7, (6) (b) and (c) and
8.3 - in particular size_t elem_len which together with the type (char(kind=1
or 4)) can be used to determine the length.
(a) requires an additional field in the class container. In principle, it could
come last, but that will prevent the extension of the rank. Currently, one has
{ _data, _vtpr } and for assumed-rank, one passes a max-rank (rank-7) array to
make sure the offset to _vptr is correct. With {_vptr, _data}, the last item
could remain the actual size; but with {_vptr, _data, int string_len } that
won't work. Cf. PR 53971.
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 --- Comment #36 from H.J. Lu hjl.tools at gmail dot com 2012-12-20 17:31:04 UTC --- (In reply to comment #34) (In reply to comment #33) Using--with-build-config=bootstrap-asan should do that for you. Seems like I'm doing something wrong, this fails for me after configuring with: ../gcc/configure --prefix=/data/vjoost/gnu/gcc_trunk/install --enable-languages=c,c++,fortran --disable-multilib --enable-plugins --disable-werror --with-build-config=bootstrap-asan /data/vjoost/gnu/binutils-2.23.1/install/bin/ld: error: /data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/libasan.a(asan_new_delete.o): multiple definition of 'operator new(unsigned long)' /data/vjoost/gnu/binutils-2.23.1/install/bin/ld: /data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(new_op.o): This is PR 55374.
[Bug debug/49532] Dwarf Error: wrong version in compilation unit header (is 1024, should be 2, 3, or 4) [in module D:\mingw.tests\l.dll]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49532 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-20 17:38:15 UTC --- This issue was in fact a binutils problem. This issue is fixed. Therefore I close this bug as invalid.
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 --- Comment #37 from Jack Howarth howarth at nitro dot med.uc.edu 2012-12-20 17:42:04 UTC --- H.J., How are you working around PR55371 in your --with-build-config=bootstrap-asan builds?
[Bug target/46308] fedora 14 mingw compiled app crashes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46308 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||INVALID --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-20 17:45:11 UTC --- The issue was actual caused by old binutils version. With mingw32-binutils-2.20.1-2.fc14, which enables ld's auto-import option by default, issue is fixed. So closed as invalid.
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 --- Comment #38 from H.J. Lu hjl.tools at gmail dot com 2012-12-20 17:49:44 UTC --- (In reply to comment #37) H.J., How are you working around PR55371 in your --with-build-config=bootstrap-asan builds? I configure GCC with --disable-werror.
[Bug c++/55742] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 Diego Novillo dnovillo at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Diego Novillo dnovillo at gcc dot gnu.org 2012-12-20 17:59:47 UTC --- After thinking about this more, I think the problem here is that the attributes specified in the declaration of the function are not being used in the function definition. Jason, shouldn't the attributes specified in the function declaration be sufficient? Or does the user really need to apply attributes to both the declaration and the definition? Thanks.
[Bug testsuite/55756] [4.8 regression] FAIL: gfortran.dg/same_type_as_1.f03 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55756 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Paul Thomas pault at gcc dot gnu.org 2012-12-20 18:07:39 UTC --- Profuse apologies - I forgot to add the change to this testcase to the commit. To add to the confusion, I did not add this PR number to the ChangeLog. Committed as revision 194639 Cheers Paul
[Bug middle-end/55750] [4.8 Regression] :-( in expand_expr_addr_expr_1, at expr.c:7646
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55750 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-20 18:14:01 UTC --- Author: jakub Date: Thu Dec 20 18:13:56 2012 New Revision: 194647 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194647 Log: PR middle-end/55750 * gimplify.c (gimplify_self_mod_expr): Don't force lvalue to pass is_gimple_min_lval. * gcc.c-torture/execute/pr55750.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr55750.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug libfortran/36044] user-requested backtrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044 --- Comment #9 from janus at gcc dot gnu.org 2012-12-20 18:15:19 UTC --- Author: janus Date: Thu Dec 20 18:15:13 2012 New Revision: 194648 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194648 Log: 2012-12-20 Janus Weil ja...@gcc.gnu.org PR fortran/36044 * gfortran.h (gfc_isym_id): Add GFC_ISYM_BACKTRACE. * intrinsic.c (add_subroutines): Add backtrace. * intrinsic.texi (BACKTRACE): Document BACKTRACE intrinsic. 2012-12-20 Janus Weil ja...@gcc.gnu.org PR fortran/36044 * gfortran.map: Add _gfortran_backtrace. * libgfortran.h: Rename 'show_backtrace' and export. * runtime/backtrace.c (show_backtrace): Rename to 'backtrace'. Don't show message. Close file descriptor. Export. * runtime/compile_options.c (backtrace_handler): Renamed 'show_backtrace'. Move message outside. * runtime/error.c (sys_abort): Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.texi trunk/libgfortran/ChangeLog trunk/libgfortran/gfortran.map trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/backtrace.c trunk/libgfortran/runtime/compile_options.c trunk/libgfortran/runtime/error.c
[Bug sanitizer/55371] [asan] False -Werror=uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55371 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-20 CC||Joost.VandeVondele at mat ||dot ethz.ch Ever Confirmed|0 |1 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-12-20 18:18:56 UTC --- seen as well, workaround: configure with --disable-werror
[Bug c++/55742] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #3 from Sriraman Tallam tmsriram at google dot com 2012-12-20 18:21:26 UTC --- (In reply to comment #2) After thinking about this more, I think the problem here is that the attributes specified in the declaration of the function are not being used in the function definition. Jason, shouldn't the attributes specified in the function declaration be sufficient? Or does the user really need to apply attributes to both the declaration and the definition? This can be done during decl merging, by adding the DECL_TARGET_SPECIFIC tree of the declaration decl to the definition decl. However, with function multiversioning, this will become a problem as multiversioning does not treat two decls with different target attributes as identical. Since we are enabling multiversioning by default, atleast in C++ front-end for now, IMO, it is better to insist that the definition and declaration contain identical target attributes. Thanks.
[Bug c++/55742] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #4 from dnovillo at google dot com dnovillo at google dot com 2012-12-20 18:23:55 UTC --- On Thu, Dec 20, 2012 at 1:21 PM, tmsriram at google dot com gcc-bugzi...@gcc.gnu.org wrote: However, with function multiversioning, this will become a problem as multiversioning does not treat two decls with different target attributes as identical. Since we are enabling multiversioning by default, atleast in C++ front-end for now, IMO, it is better to insist that the definition and declaration contain identical target attributes. Unfortunately, we cannot do that. A lot of existing code relies on this attribute merging. The cleanest approach here is probably to add an additional 'mv' attribute to explicitly enable multiversioning. Breaking the existing semantics is going to break a lot of code. Diego.
[Bug regression/55759] bogus warning when building drivers/ata/libata-core.c in v3.7 of the linux kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55759
--- Comment #4 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-12-20 18:34:19 UTC ---
This is what creduce came up with:
markus@x4 /tmp % cat test.i
struct ata_taskfile
{
int feature;
};
struct ata_eh_info
{
int flags;
};
struct ata_eh_context
{
struct ata_eh_info i;
};
struct
{
struct ata_eh_context eh_context;
}
g, n;
int a, c, e, f, m, o;
void fn1 (char *, ...);
int fn2 ();
int fn3 ();
static int
fn4 (long long *p1)
{
struct ata_taskfile b;
if (a b.feature)
return 1;
*p1 = fn3 ();
return 0;
}
static int
fn5 ()
{
struct ata_taskfile d;
if (c d.feature)
return -13;
return 0;
}
static int
fn6 ()
{
struct ata_eh_context h = g.eh_context;
int i = h.i.flags, l;
_Bool j = f;
long long k;
l = fn4 (k);
if (l)
return 0;
if (e || j)
return 0;
l = fn5 ();
if (l == -13)
return 0;
if (l)
return 1;
l = fn2 ();
if (l)
if (i)
fn1 (HPA %llu\n, k);
return 0;
}
int
fn7 ()
{
struct ata_eh_context p = n.eh_context;
int q = p.i.flags;
o = 0;
m = fn6 ();
goto err_out_nosup;
if (q)
err_out_nosup:
return 0;
}
markus@x4 /tmp % gcc -c -Wall -Os test.i
test.i: In function ‘fn7’:
test.i:61:17: warning: ‘k’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
fn1 (HPA %llu\n, k);
^
test.i:47:15: note: ‘k’ was declared here
long long k;
^
markus@x4 /tmp % gcc -c -Wall test.i
markus@x4 /tmp % gcc -c -Wall -O2 test.i
markus@x4 /tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3/gcc -c -Wall -Os test.i
markus@x4 /tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/4.7.2/gcc -c -Wall -Os test.i
test.i: In function ‘fn7’:
test.i:61:17: warning: ‘k’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
test.i:47:15: note: ‘k’ was declared here
markus@x4 /tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/4.7.2/gcc -c -Wall -O2 test.i
markus@x4 /tmp %
[Bug c++/55766] New: temlate alias is not equivalent (const-ness is not recognized)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55766 Bug #: 55766 Summary: temlate alias is not equivalent (const-ness is not recognized) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: leo...@volnitsky.com Created attachment 29016 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29016 goog.ii I have following alias in my code: templatebool Cnd, class T=void using eIF = typename std::enable_if Cnd,T::type; I encountered code where alias is not equivalent to direct use of enable_if. Attached are good.ii (with enable_if) which both GCC480-20121220 and CLANG32 can compile, and bad.ii (with alias eIF), which only CLANG can compile. diff good.ii bad.ii 80517c80517 typename std::enable_if(sizeof(Arg1),N==1), Arg1::type --- eIF(sizeof(Arg1),N==1), Arg1 80522c80522 typename std::enable_if(sizeof(Arg1),N==2), Arg2::type --- eIF(sizeof(Arg1), N==2), Arg2 Comma op in expression (sizeof(Arg1),N==1) used to makes templated member function depend on Arg1 template argument (to trigger SFINAE). Error message: lambda.h:45:2: error: integral expression ‘(0, false)’ is not constant
[Bug c++/55766] temlate alias is not equivalent (const-ness is not recognized)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55766 --- Comment #1 from Leonid Volnitsky leonid at volnitsky dot com 2012-12-20 18:37:19 UTC --- Created attachment 29017 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29017 bad.ii
[Bug c++/55766] temlate alias is not equivalent (const-ness is not recognized)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55766 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||dodji at gcc dot gnu.org --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-12-20 18:58:11 UTC --- Dodji, can you have a look to this? For the future, Leonid, please do your best to minimize the testcase (in 99.99% of the cases, 10-20 lines are enough to show the problem)
[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-12-20 19:11:01 UTC --- After applying your patch, I now get to the errors below any known workaround ? ../../gcc/libiberty/regex.c:4497: error: undefined reference to '__asan_report_store1' ../../gcc/libiberty/regex.c:4497: error: undefined reference to '__asan_report_load1' ../../gcc/libiberty/regex.c:4497: error: undefined reference to '__asan_report_load1' ../../gcc/libiberty/regex.c:4497: error: undefined reference to '__asan_report_load1' ../../gcc/libiberty/regex.c:4493: error: undefined reference to '__asan_report_load1' ../../gcc/libiberty/regex.c:4447: error: undefined reference to '__asan_report_load8' ../../gcc/libiberty/regex.c:7682: error: undefined reference to '__asan_report_store1' ../../gcc/libiberty/regex.c:7653: error: undefined reference to '__asan_report_load8' ../../gcc/libiberty/regex.c:7725: error: undefined reference to '__asan_report_store8' ../../gcc/libiberty/regex.c:7592: error: undefined reference to '__asan_report_store8' ../../gcc/libiberty/regex.c:7505: error: undefined reference to '__asan_report_load8' ../../gcc/libiberty/regex.c:4835: error: undefined reference to '__asan_handle_no_return' ../../gcc/libiberty/regex.c:4688: error: undefined reference to '__asan_report_store1' ../../gcc/libiberty/regex.c:4678: error: undefined reference to '__asan_report_store1' ../../gcc/libiberty/regex.c:4598: error: undefined reference to '__asan_report_load8' ../../gcc/libiberty/regex.c:4790: error: undefined reference to '__asan_report_store8' ../../gcc/libiberty/regex.c:7424: error: undefined reference to '__asan_handle_no_return' ../../gcc/libiberty/regex.c:6004: error: undefined reference to '__asan_report_load4' ../../gcc/libiberty/regex.c:6745: error: undefined reference to '__asan_report_store8' ../../gcc/libiberty/regex.c:6750: error: undefined reference to '__asan_report_store4' ../../gcc/libiberty/regex.c:6750: error: undefined reference to '__asan_report_store4' ../../gcc/libiberty/regex.c:6048: error: undefined reference to '__asan_report_store4' ../../gcc/libiberty/regex.c:5985: error: undefined reference to '__asan_report_store4' ../../gcc/libiberty/regex.c:7434: error: undefined reference to '__asan_report_load4' ../../gcc/libiberty/regex.c:7434: error: undefined reference to '__asan_report_load4' ../../gcc/libiberty/regex.c:7147: error: undefined reference to '__asan_report_load4' ../../gcc/libiberty/regex.c:287: error: undefined reference to '__asan_report_load2' ../../gcc/libiberty/regex.c:3292: error: undefined reference to '__asan_report_load2' ../../gcc/libiberty/regex.c:3279: error: undefined reference to '__asan_report_load2' ../../gcc/libiberty/regex.c:3295: error: undefined reference to '__asan_report_load2' ../../gcc/libiberty/regex.c:8081: error: undefined reference to '__asan_handle_no_return' ../../gcc/libiberty/regex.c:8126: error: undefined reference to '__asan_unregister_globals' ../../gcc/libiberty/regex.c:8126: error: undefined reference to '__asan_init' ../../gcc/libiberty/regex.c:8126: error: undefined reference to '__asan_register_globals' ../../gcc/libiberty/fopen_unlocked.c:129: error: undefined reference to '__asan_init' ../../gcc/libiberty/safe-ctype.c:247: error: undefined reference to '__asan_unregister_globals' ../../gcc/libiberty/safe-ctype.c:247: error: undefined reference to '__asan_init' ../../gcc/libiberty/safe-ctype.c:247: error: undefined reference to '__asan_register_globals' ../../gcc/libiberty/xmalloc.c:137: error: undefined reference to '__asan_handle_no_return' ../../gcc/libiberty/xmalloc.c:184: error: undefined reference to '__asan_unregister_globals' ../../gcc/libiberty/xmalloc.c:184: error: undefined reference to '__asan_init' ../../gcc/libiberty/xmalloc.c:184: error: undefined reference to '__asan_register_globals' ../../gcc/libiberty/xstrerror.c:79: error: undefined reference to '__asan_unregister_globals' ../../gcc/libiberty/xstrerror.c:79: error: undefined reference to '__asan_register_globals' collect2: error: ld returned 1 exit status make[2]: *** [full-stamp] Error 1 make[2]: Leaving directory `/data/vjoost/gnu/gcc_trunk/obj/fixincludes' make[1]: *** [all-fixincludes] Error 2 make[1]: *** Waiting for unfinished jobs
[Bug c++/55767] New: flowing off end of function which returns a value isn't treated as an error by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55767
Bug #: 55767
Summary: flowing off end of function which returns a value
isn't treated as an error by default
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rui.mac...@gmail.com
Consider the following code:
code
#include iostream
int foo() {}
int main(void)
{
foo() = 1 + 1;
std::cout foo() std::endl;
return 0;
}
/code
Function foo() returns a value, which is a reference to an int, and in spite of
no return statement being provided, g++ compiles the above code without
throwing any error. It does throw a warning when compiling with -Wall.
In the C++ standard, in section 6.6.3, it is stated that A return statement
without an expression can be used only in functions that do not return a
value. It is also stated that Flowing off the end of a function is
equivalent to a return with no value, following that this results in
undefined behavior in a value-returning function.
In spite of this behavior being explicitly left in the standard as undefined
behavior, this loophole contradicts other behavior specifications made by the
standard. Even then, its definition of permissible undefined behavior the
standard also includes terminating a translation or execution (with the
issuance of a diagnostic message).
As the example above shows, by ignoring the situation completely without even
issuing any diagnostic message, g++ is opening the doors to results which
aren't easily explained or expected, which constitutes a problem.
I've noticed that clang++ throws a warning by default for this particular
example, and I've read reports that MSVC++ 2010 actually throws a compiler
error, which is the best possible result for this kind of problem.
It would be nice if g++ handled functions that flowed off the end as errors
instead of silently accepting them by default.
[Bug other/55165] Build failure for x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55165 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-20 19:23:29 UTC --- Fixed for 4.7 and trunk. *** This bug has been marked as a duplicate of bug 53912 ***
[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2012-12-20 19:24:49 UTC --- (In reply to comment #5) After applying your patch, I now get to the errors below any known workaround ? ../../gcc/libiberty/regex.c:4497: error: undefined reference to '__asan_report_store1' ../../gcc/libiberty/regex.c:4497: error: undefined reference to You need http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00810.html http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00809.html
[Bug c++/55767] flowing off end of function which returns a value isn't treated as an error by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55767
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-12-20
19:34:55 UTC ---
It's not always possible to make it a hard error and refuse to compile the
code. The function might call a function that never returns (but isn't marked
with a noreturn attribute) or might be of the form:
int f(bool b) {
if (b) {
static int i;
return i;
}
}
If this is never called with a false argument there's no problem. If it's never
called at all there's no problem.
Unless GCC's flow analysis is improved I think the most you can hope for is
enabling -Wreturn-type by default.
I use -Werror=return-type, the warning's there already, use it if you want it.
[Bug libfortran/36044] user-requested backtrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from janus at gcc dot gnu.org 2012-12-20 19:35:54 UTC --- r194648 implements an intrinsic BACKTRACE routine. Closing as fixed.
[Bug rtl-optimization/55106] ice: Maximum number of LRA constraint passes is achieved (15)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55106 Ruben Van Boxem vanboxem.ruben at gmail dot com changed: What|Removed |Added CC||vanboxem.ruben at gmail dot ||com --- Comment #5 from Ruben Van Boxem vanboxem.ruben at gmail dot com 2012-12-20 19:36:08 UTC --- I'm still hitting this failure when building GMP 5.1.0 for i686-w64-mingw32: libtool: compile: i686-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../../../src/gmp/mpn -I.. -D__GMP_WITHIN_GMP -I../../../../src/gmp -DOPERATION_sbpi1_div_qr -O2 -march=nocona -mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer -c sbpi1_div_qr.c -o sbpi1_div_qr.o div_qr_2u_pi1.c: In function '__gmpn_div_qr_2u_pi1': div_qr_2u_pi1.c:67:1: internal compiler error: Maximum number of LRA constraint passes is achieved (30) } ^ Please submit a full bug report, with preprocessed source if appropriate. The build for x86_64-w64-mingw32 did not encounter this problem. I'm building on 64-bit Debian using a self-built linux to Windows cross-compilers.
