[Bug target/57202] Please make the intrinsics headers like immintrin.h be usable without compiler flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202 Thiago Macieira changed: What|Removed |Added Target|x86_64-*-* i?86-*-* |x86_64-*-* i?86-*-* arm-*-* --- Comment #1 from Thiago Macieira 2013-05-08 07:03:26 UTC --- This also applies to arm_neon.h.
[Bug preprocessor/41590] No __STDC__ definition in -g3 -E output on STDC_0_IN_SYSTEM_HEADERS systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41590 Shakthi Kannan changed: What|Removed |Added CC||skannan at redhat dot com --- Comment #1 from Shakthi Kannan 2013-05-08 07:05:37 UTC --- Which version of GCC are you using? $ cat head.h #define HEAD 1 $ cat stdc0.c #include #define STDC0 $ gcc -I. -g3 -save-temps -c stdc0.c $ grep __STDC__ stdc0.i #define __STDC__ 1 $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) The above also works with gcc version 4.9.0 20130507 (experimental) (GCC).
[Bug fortran/57094] [Fortran-Dev] ICE: in lhd_incomplete_type_error, at langhooks.c:203
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57094 --- Comment #6 from Tobias Burnus 2013-05-08 07:22:05 UTC --- (In reply to comment #5) > For the record, the first test in comment #1 is invalid as n is not > initialized. Now I see something I don't expect for both trunk and > fortran-dev: > if I set n to 7, then printing tmp gives 'aa'. Is this expected? Yes, it is: str_vs(qname(1:n-1)) returns the string "abcdef" which is then assigned to the len=1 array "tmp": tmp = "abcdef" as tmp is only len=1, only "a" is assigned - to all elements of the size=6 array: character :: tmp(6) I assume you misread it as: character :: tmp*6 or as character(len=6) :: tmp
[Bug target/57202] Please make the intrinsics headers like immintrin.h be usable without compiler flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202 Andrew Pinski changed: What|Removed |Added Target|x86_64-*-* i?86-*-* arm-*-* |x86_64-*-* i?86-*-* --- Comment #2 from Andrew Pinski 2013-05-08 07:35:52 UTC --- (In reply to comment #1) > This also applies to arm_neon.h. Please file a bug separate for arm.
[Bug fortran/57094] [Fortran-Dev] ICE: in lhd_incomplete_type_error, at langhooks.c:203
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57094 --- Comment #7 from Dominique d'Humieres 2013-05-08 07:52:22 UTC --- > as tmp is only len=1, only "a" is assigned Thanks for the explanation. I missed the fact that len=1 for tmp(i).
[Bug c/57201] Using --save-temps affects whether warning is printed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57201 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez 2013-05-08 07:58:54 UTC --- (In reply to comment #2) > I should have clarified that the warning is correct with --save-temps. When > --save-temps is omitted, the warning is missing. That is wrong. There should > be a warning in this case. The presence of "#define stdout stdout" should not > inhibit a warning. Does the same happen with -ftrack-macro-expansions=0 ? And with g++? There are some open bugs about macro locations and about differences between C and C++ FEs, but no one has found the time to investigate further.
[Bug target/57202] Please make the intrinsics headers like immintrin.h be usable without compiler flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202 --- Comment #3 from Marc Glisse 2013-05-08 08:02:23 UTC --- http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00740.html that patch (or maybe a later iteration) is waiting for reviews but I think it is what this PR is asking for.
[Bug c++/53050] ssa_forward_propagate_and_combine: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53050 David Binderman changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #6 from David Binderman 2013-05-08 08:27:18 UTC --- I tried the same C++ source code on trunk from 20130508 and I got /home/dcb/rpmbuild/BUILD/OpenCV-2.3.1/modules/imgproc/src/smooth.cpp: In function ‘void cv::medianBlur_SortNet(const cv::Mat&, cv::Mat&, int) [with Op = cv::MinMax16u; VecOp = cv::MinMaxVec16u]’: /home/dcb/rpmbuild/BUILD/OpenCV-2.3.1/modules/imgproc/src/smooth.cpp:1010:1: error: invalid (pointer) operands to plus/minus slsr_7121 = _4220 + iftmp.108_26; /home/dcb/rpmbuild/BUILD/OpenCV-2.3.1/modules/imgproc/src/smooth.cpp:1010:1: error: invalid (pointer) operands to plus/minus slsr_7133 = _4187 + iftmp.111_27; /home/dcb/rpmbuild/BUILD/OpenCV-2.3.1/modules/imgproc/src/smooth.cpp:1010:1: error: invalid (pointer) operands to plus/minus slsr_7111 = _50 + iftmp.108_26; /home/dcb/rpmbuild/BUILD/OpenCV-2.3.1/modules/imgproc/src/smooth.cpp:1010:1: error: invalid (pointer) operands to plus/minus slsr_7123 = _782 + iftmp.111_27; /home/dcb/rpmbuild/BUILD/OpenCV-2.3.1/modules/imgproc/src/smooth.cpp:1010:1: error: invalid (pointer) operands to plus/minus slsr_7113 = _3912 + iftmp.108_26; /home/dcb/rpmbuild/BUILD/OpenCV-2.3.1/modules/imgproc/src/smooth.cpp:1010:1: error: invalid (pointer) operands to plus/minus slsr_7125 = _3745 + iftmp.111_27; /home/dcb/rpmbuild/BUILD/OpenCV-2.3.1/modules/imgproc/src/smooth.cpp:1010:1: error: invalid (pointer) operands to plus/minus slsr_7115 = _2356 + iftmp.108_26; /home/dcb/rpmbuild/BUILD/OpenCV-2.3.1/modules/imgproc/src/smooth.cpp:1010:1: error: invalid (pointer) operands to plus/minus slsr_7127 = _2274 + iftmp.111_27; /home/dcb/rpmbuild/BUILD/OpenCV-2.3.1/modules/imgproc/src/smooth.cpp:1010:1: error: invalid (pointer) operands to plus/minus slsr_7117 = _3261 + iftmp.108_26; /home/dcb/rpmbuild/BUILD/OpenCV-2.3.1/modules/imgproc/src/smooth.cpp:1010:1: error: invalid (pointer) operands to plus/minus slsr_7129 = _4117 + iftmp.111_27; /home/dcb/rpmbuild/BUILD/OpenCV-2.3.1/modules/imgproc/src/smooth.cpp:1010:1: error: invalid (pointer) operands to plus/minus slsr_7119 = _761 + iftmp.108_26; /home/dcb/rpmbuild/BUILD/OpenCV-2.3.1/modules/imgproc/src/smooth.cpp:1010:1: error: invalid (pointer) operands to plus/minus slsr_7131 = _256 + iftmp.111_27; /home/dcb/rpmbuild/BUILD/OpenCV-2.3.1/modules/imgproc/src/smooth.cpp:1010:1: internal compiler error: verify_gimple failed 0xacc9b9 verify_gimple_in_cfg(function*) ../../src/trunk/gcc/tree-cfg.c:4792 0xa018f7 execute_function_todo ../../src/trunk/gcc/passes.c:1969 0xa022c7 execute_todo ../../src/trunk/gcc/passes.c:2002 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. This compiled ok on 20130505, so something has gone wrong in the last few days.
[Bug tree-optimization/57203] New: [4.9 Regression] verify_gimple failed after SLSR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57203 Bug #: 57203 Summary: [4.9 Regression] verify_gimple failed after SLSR Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org CC: wschm...@gcc.gnu.org The testcase from PR53050 now causes /home/dcb/rpmbuild/BUILD/OpenCV-2.3.1/modules/imgproc/src/smooth.cpp:1010:1: error: invalid (pointer) operands to plus/minus slsr_7941 = _4111 + iftmp.164_27; Breakpoint 2, internal_error (gmsgid=0x16626d0 "verify_gimple failed") at /space/rguenther/src/svn/trunk/gcc/diagnostic.c:1124
[Bug tree-optimization/57203] [4.9 Regression] verify_gimple failed after SLSR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57203 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug c++/53050] ssa_forward_propagate_and_combine: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53050 Richard Biener changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #7 from Richard Biener 2013-05-08 08:42:53 UTC --- Confirmed - but this is a different bug in SLSR -> PR57203.
[Bug c/57201] Using --save-temps affects whether warning is printed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57201 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-08 Ever Confirmed|0 |1 --- Comment #4 from Richard Biener 2013-05-08 08:44:12 UTC --- I suppose somehow the replaced token has the system_header flag set. Does it warn with -Wsystem-headers?
[Bug tree-optimization/57200] [4.8/4.9 Regression] aggressive-loop-optimizations notes appear even when warning itself is suppressed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57200 --- Comment #2 from Richard Biener 2013-05-08 08:44:56 UTC --- (In reply to comment #1) > This issue is easy, isn't it? Something like: > > Index: tree-ssa-loop-niter.c > === > --- tree-ssa-loop-niter.c(revision 198676) > +++ tree-ssa-loop-niter.c(working copy) > @@ -2553,10 +2553,11 @@ do_warn_aggressive_loop_optimizations (struct loop > return; > >gimple estmt = last_stmt (e->src); > - warning_at (gimple_location (stmt), OPT_Waggressive_loop_optimizations, > - "iteration %E invokes undefined behavior", > - double_int_to_tree (TREE_TYPE (loop->nb_iterations), i_bound)); > - inform (gimple_location (estmt), "containing loop"); > + if (warning_at (gimple_location (stmt), OPT_Waggressive_loop_optimizations, > + "iteration %E invokes undefined behavior", > + double_int_to_tree (TREE_TYPE (loop->nb_iterations), > + i_bound))) > +inform (gimple_location (estmt), "containing loop"); >loop->warned_aggressive_loop_optimizations = true; > } Yes, approved.
[Bug tree-optimization/57199] [4.8/4.9 Regression] Bogus warning: iteration NNNN invokes undefined behavior -Waggressive-loop-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57199
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
--- Comment #1 from Richard Biener 2013-05-08
08:57:45 UTC ---
Note that there seems to be an error in the source:
void resize(size_t n) {
size_t s = size();
DestroyElements(mutable_array() + n, s - n);
for the call with n == size () + 1 the function calls DestroyElements
with -1U elements which we figure out and optimize the caller to
:
_13 = i_12 * 80;
_14 = _11 + _13;
Foo::~Foo (_14);
i_15 = i_12 + 1;
:
# i_12 = PHI <0(2), i_15(3)>
if (i_12 != 18446744073709551615)
goto ;
else
goto ;
which then causes the addition to overflow and invoke undefined behavior
and we warn.
Thus, the warning, while not 100% helpful, points at a real problem.
[Bug other/50345] Incomplete GCC Internals sentence on LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50345 --- Comment #1 from Paulo J. Matos 2013-05-08 08:58:54 UTC --- I am revisiting this bug and it seems that there's just an extra work, nothing specially unexplained and the correct URL for the problem is: http://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html#LTO-Overview I will submit a patch to fix this.
[Bug rtl-optimization/57193] [4.7/4.8/4.9 Regression] suboptimal register allocation for SSE registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57193 Richard Biener changed: What|Removed |Added Known to work||4.4.6 Target Milestone|--- |4.7.4 Summary|[4.5/4.6/4.7/4.8/4.9|[4.7/4.8/4.9 Regression] |Regression] suboptimal |suboptimal register |register allocation for SSE |allocation for SSE |registers |registers Known to fail||4.5.3, 4.6.4
[Bug tree-optimization/57200] [4.8/4.9 Regression] aggressive-loop-optimizations notes appear even when warning itself is suppressed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57200 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com
[Bug tree-optimization/57204] New: Auto-vectorization in nested loops with non-varying indexed array access results in very poor performance (worse than no auto-vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57204
Bug #: 57204
Summary: Auto-vectorization in nested loops with non-varying
indexed array access results in very poor performance
(worse than no auto-vectorization)
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: snagaval...@outlook.com
In the good case below, auto-vectorization improves performance by a factor of
3. In the bad case, it actually decreases performance compared to no
auto-vectorization.
Good:
void foo(float * d, int n)
{
int i, j, k;
for (k=0; k
[Bug other/50345] Incomplete GCC Internals sentence on LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50345 --- Comment #2 from Paulo J. Matos 2013-05-08 09:09:30 UTC --- Created attachment 30050 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30050 Patch with typo fix.
[Bug tree-optimization/57200] [4.8/4.9 Regression] aggressive-loop-optimizations notes appear even when warning itself is suppressed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57200 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Version|unknown |4.9.0 Resolution||FIXED Target Milestone|4.9.0 |4.8.1 --- Comment #3 from Paolo Carlini 2013-05-08 09:10:55 UTC --- Done, mainline and 4.8.1.
[Bug tree-optimization/57204] Auto-vectorization in nested loops with non-varying indexed array access results in very poor performance (worse than no auto-vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57204 --- Comment #1 from Sasanka Nagavalli 2013-05-08 09:16:02 UTC --- Created attachment 30051 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30051 Test case for issue 57204 Attached a small test case to demonstrate the issue.
[Bug preprocessor/41590] No __STDC__ definition in -g3 -E output on STDC_0_IN_SYSTEM_HEADERS systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41590 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE 2013-05-08 09:17:11 UTC --- > --- Comment #1 from Shakthi Kannan 2013-05-08 > 07:05:37 UTC --- > Which version of GCC are you using? This even affects current mainline. > The above also works with gcc version 4.9.0 20130507 (experimental) (GCC). As the PR summary states, this only affects STDC_0_IN_SYSTEM_HEADERS targets: ro@apoc 54 > grep -r STDC_0_IN_SYSTEM_HEADERS gcc/config gcc/config/sol2.h:#define STDC_0_IN_SYSTEM_HEADERS 1 gcc/config/sparc/netbsd-elf.h:#undef STDC_0_IN_SYSTEM_HEADERS I've just verified it again on i386-pc-solaris2.11. Rainer
[Bug ada/57188] [4.9 regression] Ada bootstrap broken on Solaris/x64: No_Implicit_Dynamic_Code violation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57188 Rainer Orth changed: What|Removed |Added Status|NEW |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-05/msg00394.htm ||l AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | --- Comment #6 from Rainer Orth 2013-05-08 09:29:11 UTC --- Mine, patch posted.
[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659 --- Comment #27 from rguenther at suse dot de 2013-05-08 10:06:30 UTC --- On Tue, 7 May 2013, Diego Novillo wrote: > On 2013-05-07 13:06 , roland at gnu dot org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659 > > > > --- Comment #25 from roland at gnu dot org 2013-05-07 17:06:56 UTC --- > > I have been using a straightforward revert of r190487 to build on mingw with > > --disable-nls. It works. > > > > > Thanks. Then I just need to confirm that this doesn't re-introduce > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54281. Richi, could you check > that? Do you still have access to 4.1 host compilers? I've verified that reverting r190487 on the 4.8 branch does not re-introduce the issue on the originally affected host system. Richard.
[Bug c/57205] New: unfinished function declaration and inclusion of assert.h causes compiler errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57205 Bug #: 57205 Summary: unfinished function declaration and inclusion of assert.h causes compiler errors Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: rui.mac...@gmail.com If gcc is used to compile a source file which includes assert.h and contains an incomplete function declaration, the compiler throws errors blamed on assert.h. Here's an example which is able to reproduce this bug: #include int foo(FILE *file, #include "test.h" #include rui@kubuntu:tmp$ gcc test.c In file included from test.c:3:0: /usr/include/assert.h:71:13: error: storage class specified for parameter ‘__assert_fail’ /usr/include/assert.h:76:13: error: storage class specified for parameter ‘__assert_perror_fail’ /usr/include/assert.h:84:13: error: storage class specified for parameter ‘__assert’ test.c:3:0: error: expected declaration specifiers or ‘...’ at end of input This is a small reproducible example, but in real world code the string of error messages attributed to assert.h is even longer and more egregious.
[Bug c++/57206] New: Auto-vectorization fails when array index is an unsigned int expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57206
Bug #: 57206
Summary: Auto-vectorization fails when array index is an
unsigned int expression
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: snagaval...@outlook.com
Basic examples given below. Please see attachment for more examples.
Auto-vectorize fails:
void bad0(float * d, unsigned int n)
{
unsigned int i;
for (i=n; i>0; --i)
d[n-i] = 0.0;
}
Auto-vectorize succeeds:
void good0(float * d, int n)
{
int i;
for (i=0; i0; --i)
d[n-i] = 0.0;
}
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --enable-objc-gc --with-cloog --enable-cloog-backend=ppl
--disable-cloog-version-check --disable-ppl-version-check --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
$ gcc -march=native -Q --help=target
The following options are target specific:
-m128bit-long-double[disabled]
-m32[disabled]
-m3dnow [disabled]
-m3dnowa[disabled]
-m64[enabled]
-m80387 [enabled]
-m8bit-idiv [disabled]
-m96bit-long-double [enabled]
-mabi= sysv
-mabm [disabled]
-maccumulate-outgoing-args [disabled]
-maddress-mode= short
-maes [disabled]
-malign-double [disabled]
-malign-functions= 0
-malign-jumps= 0
-malign-loops= 0
-malign-stringops [enabled]
-mandroid [disabled]
-march= corei7
-masm= att
-mavx [disabled]
-mavx2 [disabled]
-mavx256-split-unaligned-load [disabled]
-mavx256-split-unaligned-store [disabled]
-mbionic[disabled]
-mbmi [disabled]
-mbmi2 [disabled]
-mbranch-cost= 0
-mcld [disabled]
-mcmodel= 32
-mcpu=
-mcrc32 [disabled]
-mcx16 [enabled]
-mdispatch-scheduler[disabled]
-mf16c [disabled]
-mfancy-math-387[enabled]
-mfentry[enabled]
-mfma [disabled]
-mfma4 [disabled]
-mforce-drap[disabled]
-mfp-ret-in-387 [enabled]
-mfpmath= 387
-mfsgsbase [disabled]
-mfused-madd
-mglibc [enabled]
-mhard-float[enabled]
-mieee-fp [enabled]
-mincoming-stack-boundary= 0
-minline-all-stringops [disabled]
-minline-stringops-dynamically [disabled]
-mintel-syntax
-mlarge-data-threshold= 0x1
-mlwp [disabled]
-mlzcnt [disabled]
-mmmx [disabled]
-mmovbe [disabled]
-mms-bitfields [disabled]
-mno-align-stringops[disabled]
-mno-fancy-math-387 [disabled]
-mno-push-args [disabled]
-mno-red-zone [disabled]
[Bug c++/57206] Auto-vectorization fails when array index is an unsigned int expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57206 --- Comment #1 from Sasanka Nagavalli 2013-05-08 10:51:24 UTC --- Created attachment 30052 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30052 Test case for issue 57206
[Bug c++/57207] New: Incorrect lifetime of const references bound to temporary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57207
Bug #: 57207
Summary: Incorrect lifetime of const references bound to
temporary
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dima...@ya.ru
Created attachment 30053
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30053
main.ii generated via --save-temps
Here the programme:
#include
struct TMyStruct
{ };
struct TByteArrayList
{
TByteArrayList(const TByteArrayList &)
{ i = 12; std::cout << "copy ctor " << this << std::endl; }
TByteArrayList &operator=(const TByteArrayList &)
{ std::cout << "operator = " << this << std::endl; return *this; }
TByteArrayList()
{ i = 12; std::cout << "ctor " << this << std::endl; }
~TByteArrayList()
{ std::cout << "dtor " << this << std::endl; }
TByteArrayList &operator<<(const TMyStruct &)
{ std::cout << "<< " << this << std::endl; return *this; }
int i;
};
int main()
{
const TByteArrayList &List = TByteArrayList() << TMyStruct();
std::cout << "Here some use of List: " << List.i << " address " << &List
<< std::endl;
return 0;
}
And here its output:
ctor 0x7fff22f27350
<< 0x7fff22f27350
dtor 0x7fff22f27350
Here some use of List: 12 address 0x7fff22f27350
Why dtor of List called right after List is created in this line
const TByteArrayList &List = TByteArrayList() << TMyStruct();
Why const reference to temporary object (List) does not prolong life time of
temporary object (TByteArrayList() << TMyStruct())?
Seems it is a bug.
//===
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --enable-objc-gc --with-cloog --enable-cloog-backend=ppl
--disable-cloog-version-check --disable-ppl-version-check --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
[Bug c++/57206] Auto-vectorization fails when array index is an unsigned int expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57206
Sasanka Nagavalli changed:
What|Removed |Added
See Also||http://gcc.gnu.org/bugzilla
||/show_bug.cgi?id=48052
--- Comment #2 from Sasanka Nagavalli
2013-05-08 10:55:18 UTC ---
Sorry, in the original description, good1() should have been written as follows
to avoid the warning:
void good1(float * d, unsigned int n)
{
unsigned int i;
for (i=0; i
[Bug c/57205] for unfinished function declaration, recover by skipping until matched parenthesis and report non-matched parenthesis
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57205
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-05-08
CC||manu at gcc dot gnu.org
Summary|unfinished function |for unfinished function
|declaration and inclusion |declaration, recover by
|of assert.h causes compiler |skipping until matched
|errors |parenthesis and report
||non-matched parenthesis
Ever Confirmed|0 |1
--- Comment #1 from Manuel López-Ibáñez 2013-05-08
11:15:00 UTC ---
I don't think GCC can do much better, since when reading a header file, the
function declaration does not need to be complete, so:
int foo(int *file,
#include "something.h"
);
can be correct depending on the contents of something.h.
Clang shows:
/usr/include/assert.h:71:1: error: invalid storage class specifier in function
declarator
extern void __assert_fail (__const char *__assertion, __const char *__file,
^
/usr/include/assert.h:73:44: error: expected ')'
__THROW __attribute__ ((__noreturn__));
^
/home/manuel/test.c:1:8: note: to match this '('
int foo(int *file,
^
which is very similar to GCC.
GCC could recover better by skipping everything up to the first non-matched
parenthesis, and then report the location of the non-matched parenthesis when
not found, like Clang does.
I am not sure what heuristics Clang uses to decide when to skip, but being in a
different file or finding something like "extern" is definitely a good moment
to think that something went terribly wrong and skip the whole function.
[Bug c++/57207] Incorrect lifetime of const references bound to temporary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57207 vlukas at gmx dot de changed: What|Removed |Added CC||vlukas at gmx dot de --- Comment #1 from vlukas at gmx dot de 2013-05-08 11:15:48 UTC --- I think GCC is correct. In the C++-draft N3290, this is prescribed by 12.2, paragraph 5, the second item: A temporary which is bound to a reference parameter of a function is destroyed at the end of the full expression.
[Bug sanitizer/56628] "bootstrap-lto bootstrap-asan" / profiledbootstrap fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56628 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #3 from Markus Trippelsdorf 2013-05-08 11:19:06 UTC --- No reaction, closing.
[Bug sanitizer/56630] gcc's address-sanitizer uses 75% more memory than clang's on simple testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56630 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #3 from Markus Trippelsdorf 2013-05-08 11:18:45 UTC --- No reaction, closing.
[Bug c++/57207] Incorrect lifetime of const references bound to temporary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57207 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely 2013-05-08 11:30:43 UTC --- (In reply to comment #0) > Why const reference to temporary object (List) does not prolong life time of > temporary object (TByteArrayList() << TMyStruct())? Because (TByteArrayList() << TMyStruct()) is not a temporary object, it's a reference returned by operator<< The temporary object is TByteArrayList() and that is bound to the reference parameter of operator<< not to List, so as comment 1 says, the temporary does not have its lifetime extended. G++ is correct.
[Bug web/52239] Upgrade GCC Bugzilla to 4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52239 --- Comment #6 from Frédéric Buclin 2013-05-08 11:43:08 UTC --- I plan to upgrade GCC Bugzilla to 4.4 this week. Is there any objection or anything else that I should be aware of before doing the upgrade?
[Bug c++/57207] Incorrect lifetime of const references bound to temporary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57207 --- Comment #3 from DimanNe 2013-05-08 11:44:17 UTC --- Ok, thanks for clarification.
[Bug c++/57206] Auto-vectorization fails when array index is an unsigned int expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57206 --- Comment #3 from Paolo Carlini 2013-05-08 11:49:11 UTC --- I don't think this is a C++ front-end issue.
[Bug c/57201] Using --save-temps affects whether warning is printed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57201 --- Comment #5 from Ian Lance Taylor 2013-05-08 12:30:02 UTC --- Yes, it does issue a warning as expected with -Wsystem-headers.
[Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 Bug #: 57208 Summary: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] Classification: Unclassified Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: marxin.li...@gmail.com Chromium git repository: May 4, 2013 gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/marxin/gcc48/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --enable-languages=c,c++,java --enable-bootstrap --disable-libsanitizer --prefix=/home/marxin/gcc48 Thread model: posix gcc version 4.8.1 20130505 (prerelease) (GCC) failure: g++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -Wl,-uIsHeapProfilerRunning,-uProfilerStart -Wl,-u_Z21InitialMallocHook_NewPKvj,-u_Z22InitialMallocHook_MMapPKvS0_jiiix,-u_Z22InitialMallocHook_SbrkPKvi -Wl,-u_Z21InitialMallocHook_NewPKvm,-u_Z22InitialMallocHook_MMapPKvS0_miiil,-u_Z22InitialMallocHook_SbrkPKvl -Wl,-u_ZN15HeapLeakChecker12IgnoreObjectEPKv,-u_ZN15HeapLeakChecker14UnIgnoreObjectEPKv -Wl,-O1 -Wl,--as-needed -flto=9 -fno-fat-lto-objects -Wl,--gc-sections -o out/Release/base_unittests -Wl,--start-group out/Release/obj.target/base_unittests/base/at_exit_unittest.o out/Release/obj.target/base_unittests/base/atomicops_unittest.o out/Release/obj.target/base_unittests/base/base64_unittest.o out/Release/obj.target/base_unittests/base/bind_helpers_unittest.o out/Release/obj.target/base_unittests/base/bind_unittest.o out/Release/obj.target/base_unittests/base/bits_unittest.o out/Release/obj.target/base_unittests/base/build_time_unittest.o out/Release/obj.target/base_unittests/base/callback_unittest.o out/Release/obj.target/base_unittests/base/cancelable_callback_unittest.o out/Release/obj.target/base_unittests/base/command_line_unittest.o out/Release/obj.target/base_unittests/base/containers/linked_list_unittest.o out/Release/obj.target/base_unittests/base/containers/mru_cache_unittest.o out/Release/obj.target/base_unittests/base/containers/small_map_unittest.o out/Release/obj.target/base_unittests/base/containers/stack_container_unittest.o out/Release/obj.target/base_unittests/base/cpu_unittest.o out/Release/obj.target/base_unittests/base/debug/crash_logging_unittest.o out/Release/obj.target/base_unittests/base/debug/leak_tracker_unittest.o out/Release/obj.target/base_unittests/base/debug/stack_trace_unittest.o out/Release/obj.target/base_unittests/base/debug/trace_event_unittest.o out/Release/obj.target/base_unittests/base/deferred_sequenced_task_runner_unittest.o out/Release/obj.target/base_unittests/base/environment_unittest.o out/Release/obj.target/base_unittests/base/file_util_unittest.o out/Release/obj.target/base_unittests/base/files/dir_reader_posix_unittest.o out/Release/obj.target/base_unittests/base/files/file_path_unittest.o out/Release/obj.target/base_unittests/base/files/file_util_proxy_unittest.o out/Release/obj.target/base_unittests/base/files/important_file_writer_unittest.o out/Release/obj.target/base_unittests/base/files/scoped_temp_dir_unittest.o out/Release/obj.target/base_unittests/base/gmock_unittest.o out/Release/obj.target/base_unittests/base/guid_unittest.o out/Release/obj.target/base_unittests/base/hi_res_timer_manager_unittest.o out/Release/obj.target/base_unittests/base/id_map_unittest.o out/Release/obj.target/base_unittests/base/i18n/break_iterator_unittest.o out/Release/obj.target/base_unittests/base/i18n/char_iterator_unittest.o out/Release/obj.target/base_unittests/base/i18n/case_conversion_unittest.o out/Release/obj.target/base_unittests/base/i18n/file_util_icu_unittest.o out/Release/obj.target/base_unittests/base/i18n/icu_string_conversions_unittest.o out/Release/obj.target/base_unittests/base/i18n/number_formatting_unittest.o out/Release/obj.target/base_unittests/base/i18n/rtl_unittest.o out/Release/obj.target/base_unittests/base/i18n/string_search_unittest.o out/Release/obj.target/base_unittests/base/i18n/time_formatting_unittest.o out/Release/obj.target/base_unittests/base/json/json_parser_unittest.o out/Release/obj.target/base_unittests/base/json/json_reader_unittest.o out/Release/obj.target/base_unittests/base/json/json_value_converter_unittest.o out/Release/obj.target/base_unittests/base/json/json_value_serializer_unittest.o out/Release/obj.target/base_unittests/base/json/json_writer_unittest.o out/Release/obj.target/base_unittests/base/json/string_escape_unittest.o out/Release/obj.target/base_unittests/base/lazy_instance_unittest.o out/Release/obj.target/base_unittests/base/logging_unittest.o out/Release/obj.target/base_unittests/base/md5_unittest.o out/Release/obj.target/base_unittests/base/memory/alig
[Bug c++/57208] Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 --- Comment #1 from Martin Liška 2013-05-08 12:32:24 UTC --- Created attachment 30054 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30054 Savetemps dump
[Bug c++/57208] Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 --- Comment #2 from Martin Liška 2013-05-08 12:32:51 UTC --- Created attachment 30055 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30055 common.gypi - build configuration
[Bug c/57209] New: Wrong code of print statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57209
Bug #: 57209
Summary: Wrong code of print statement
Classification: Unclassified
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ishiura-compi...@ml.kwansei.ac.jp
The following code is miscompiled by GCC 4.8.1 20130508 (prerelease)
for x86_64 (as well as for i686). The option in question is
"-funsafe-math-optimizations."
$ cat error.c
volatile char buff = 0;
void PRINTF(const char* s)
{
while(*s++) buff = *s;
}
int main (void)
{
int k = -1;
int t = 1 % (int)(( 942.0 + k ) / -941.0F );
if (t == 0) { PRINTF("OK"); }
return 0;
}
$ x86_64-unknown-linux-gnu-gcc-4.8.1 error.c -O1 -funsafe-math-optimizations
$ ./a.out
Floating point exception (core dumped)
-
$ x86_64-unknown-linux-gnu-gcc-4.8.1 -v
Using built-in specs.
COLLECT_GCC=x86_64-unknown-linux-gnu-gcc-4.8.1
COLLECT_LTO_WRAPPER=/usr/local/x86_64-tools/gcc-4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/hassy/gcc/configure
--prefix=/usr/local/x86_64-tools/gcc-4.8.1/
--with-gmp=/usr/local/gmp-5.1.1/ --with-mpfr=/usr/local/mpfr-3.1.2/
--with-mpc=/usr/local/mpc-1.0.1/ --disable-multilib --disable-nls
--enable-languages=c
Thread model: posix
gcc version 4.8.1 20130508 (prerelease) (GCC)
[Bug web/52239] Upgrade GCC Bugzilla to 4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52239 --- Comment #7 from Paolo Carlini 2013-05-08 12:42:47 UTC --- Any chance we can take the occasion to restore the svn -> Bugzilla link, where the former automatically sends the commit ChangeLogs to the audit trails?
[Bug web/52239] Upgrade GCC Bugzilla to 4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52239 --- Comment #8 from Frédéric Buclin 2013-05-08 12:49:05 UTC --- (In reply to comment #7) > Any chance we can take the occasion to restore the svn -> Bugzilla link, where > the former automatically sends the commit ChangeLogs to the audit trails? That's out of my control. This must be fixed on the SVN side, not the Bugzilla one.
[Bug c++/57210] New: Using alignas with an union does not compile.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57210
Bug #: 57210
Summary: Using alignas with an union does not compile.
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: damien.le...@gmail.com
I have a construct of the form:
template
class foo {
/* ... */
private:
alignas(ALIGNMENT) union bar_ { /* ... */ } bar;
};
which does not compile with the following errors:
error: 'ALIGNMENT' is not a type
error: ISO C++ forbids declaration of 'alignas' with no type [-fpermissive]
error: expected ';' at end of member declaration
The following alternatives have been tried without success:
/* ... */
union alignas(ALIGNMENT) bar_ { /* ... */ } bar;
union bar_ { alignas(ALIGNMENT) int foo; /* ... */ } bar;
/* ... */
With different but equivalent error messages.
[Bug tree-optimization/57199] [4.8/4.9 Regression] Bogus warning: iteration NNNN invokes undefined behavior -Waggressive-loop-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57199
Paul Pluzhnikov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |
--- Comment #2 from Paul Pluzhnikov 2013-05-08
12:55:31 UTC ---
> Thus, the warning, while not 100% helpful, points at a real problem.
There is no real problem in the original source, which reads:
size_t s = size();
if (n < s)
DestroyElements(mutable_array() + n, s - n);
else ...
and produces the same warning.
Here is updated test with above condition; confirmed to still show the warning
with trunk @r198709.
typedef decltype(sizeof(0)) size_t;
struct Foo {
~Foo(); // comment out -> problem disappears
int x[20];
};
template
struct InlinedVector {
inline InlinedVector() : size_(0) { }
inline size_t size() const {
return size_;
}
T* mutable_array();
void resize(size_t n) {
size_t s = size();
if (n < s)
DestroyElements(mutable_array() + n, s - n);
}
static void DestroyElements(T* ptr, size_t num) {
for (size_t i = 0; i < num; i++) {
ptr[i].~T();
}
}
size_t size_;
};
struct CP {
void Add();
InlinedVector foo_;
};
void CP::Add() {
foo_.resize(foo_.size() + 1);
}
[Bug web/52239] Upgrade GCC Bugzilla to 4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52239 --- Comment #9 from Paolo Carlini 2013-05-08 12:57:04 UTC --- Maybe you could refuse to do the update if nobody helps about that. Kidding ;)
[Bug c++/57210] Using alignas with an union does not compile.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57210 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Paolo Carlini 2013-05-08 13:00:37 UTC --- Dup. Already fixed for 4.8.1. *** This bug has been marked as a duplicate of bug 56859 ***
[Bug c++/56859] alignas() fails in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56859 Paolo Carlini changed: What|Removed |Added CC||damien.levac at gmail dot ||com --- Comment #5 from Paolo Carlini 2013-05-08 13:00:37 UTC --- *** Bug 57210 has been marked as a duplicate of this bug. ***
[Bug middle-end/57192] [4.9 Regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57192 --- Comment #12 from Joost VandeVondele 2013-05-08 13:03:59 UTC --- Reduced testcase that still triggers the valgrind warning during compilation: MODULE orbital_pointers INTEGER, DIMENSION(:,:), ALLOCATABLE :: soset CONTAINS SUBROUTINE create_orbital_pointers(maxl) soset(:,:) = 0 END SUBROUTINE create_orbital_pointers END MODULE orbital_pointers gfortran -O3 ==81795== Conditional jump or move depends on uninitialised value(s) ==81795==at 0xDF5DAB: register_active_defs(df_ref_d**) (sparseset.h:147) ==81795==by 0xDF5E52: update_df_init(rtx_def*, rtx_def*) [clone .isra.11] (fwprop.c:894) ==81795==by 0xDF65F1: try_fwprop_subst(df_ref_d*, rtx_def**, rtx_def*, rtx_def*, bool) (fwprop.c:962) ==81795==by 0xDF6A91: forward_propagate_into(df_ref_d*) (fwprop.c:1342) ==81795==by 0xDF7B27: fwprop() (fwprop.c:1479) ==81795==by 0x9021DF: execute_one_pass(opt_pass*) (passes.c:2337) ==81795==by 0x902644: execute_pass_list(opt_pass*) (passes.c:2389) ==81795==by 0x902656: execute_pass_list(opt_pass*) (passes.c:2390) ==81795==by 0x6CC857: expand_function(cgraph_node*) (cgraphunit.c:1640) ==81795==by 0x6CE5FC: compile() (cgraphunit.c:1744) ==81795==by 0x6CEC94: finalize_compilation_unit() (cgraphunit.c:2119) ==81795==by 0x8992FA: write_global_declarations() (langhooks.c:322)
[Bug c++/57211] New: wrong line indicated in warning for synthesized method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57211
Bug #: 57211
Summary: wrong line indicated in warning for synthesized method
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@gcc.gnu.org
seen at least in 4.6, 4.7, 4.8 and trunk:
$ g++-4.8 -c -std=c++11 -Wunused-parameter test.cpp
test.cpp:3:8: warning: unused parameter 'p' [-Wunused-parameter]
struct A // line pointed-to by warning
^
test.cpp: In function 'int main()':
test.cpp:21:11: note: synthesized method 'A& A::operator=(A&&)' first required
here
b = std::move(a);
^
$ cat test.cpp
#include
struct A // line pointed-to by warning
{
struct B
{
B& operator=(B&&) { return *this; }
};
B f;
A() = default;
A& operator=(A&& p) = default; // where the method is declared
};
int main()
{
A a;
A b;
b = std::move(a);
}
[Bug c/57209] Wrong code of print statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57209 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Richard Biener 2013-05-08 13:15:02 UTC --- Rounding issues, well documented side-effect of -funsafe-math-optimizations
[Bug c/57201] Using --save-temps affects whether warning is printed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57201
minux changed:
What|Removed |Added
CC||minux.ma at gmail dot com
--- Comment #6 from minux 2013-05-08 13:21:15 UTC
---
A small standalone test case:
$ cat stdio.c
#include
void f(void) {
stdout;
}
$ cat test.h
int *stdout;
#define stdout stdout
$ gcc -Wall -Werror -c stdio.c -I .
In file included from stdio.c:1:0:
stdio.c: In function ‘f’:
./test.h:2:16: error: statement with no effect [-Werror=unused-value]
#define stdout stdout
^
stdio.c:4:2: note: in expansion of macro ‘stdout’
stdout;
^
cc1: all warnings being treated as errors
$ gcc -Wall -Werror -c stdio.c -isystem .
$ gcc -Wall -Werror -c stdio.c -isystem . -ftrack-macro-expansions=0
In file included from stdio.c:1:0:
stdio.c: In function ‘f’:
./test.h:2:16: error: statement with no effect [-Werror=unused-value]
#define stdout stdout
^
stdio.c:4:2: note: in expansion of macro ‘stdout’
stdout;
^
cc1: all warnings being treated as errors
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8.0/configure --enable-languages=c,c++,go,lto
Thread model: posix
gcc version 4.8.0 (GCC)
[Bug tree-optimization/57206] Auto-vectorization fails when array index is an unsigned int expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57206
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-05-08
Blocks||53947
Ever Confirmed|0 |1
--- Comment #4 from Richard Biener 2013-05-08
13:22:27 UTC ---
That's because we cannot compute the evolution of _7
:
# n_14 = PHI
_5 = n_3(D) - n_14;
_6 = (long unsigned int) _5;
_7 = _6 * 4;
_9 = d_8(D) + _7;
*_9 = 0.0;
(set_scalar_evolution
instantiated_below = 3
(scalar = _6)
(scalar_evolution = (long unsigned int) {0, +, 1}_1))
)
because 4 * (long unsigned int) {0, +, 1}_1 is not affine and we
fail to prove that _5 = n_3(D) - n_14; does not wrap.
All kind-of side-effects of us forcing the offset operand of POINTER_PLUS_EXPR
to be sizetype and to perform the array index * array element size computation
in that type.
[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659 --- Comment #28 from dnovillo at google dot com 2013-05-08 13:23:22 UTC --- On 2013-05-08 06:05 , Richard Biener wrote: > On Tue, 7 May 2013, Diego Novillo wrote: > >> On 2013-05-07 13:06 , roland at gnu dot org wrote: >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659 >>> >>> --- Comment #25 from roland at gnu dot org 2013-05-07 17:06:56 UTC --- >>> I have been using a straightforward revert of r190487 to build on mingw with >>> --disable-nls. It works. >>> >> >> Thanks. Then I just need to confirm that this doesn't re-introduce >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54281. Richi, could you check >> that? Do you still have access to 4.1 host compilers? > I've verified that reverting r190487 on the 4.8 branch does not > re-introduce the issue on the originally affected host system. > > Richard. Thanks, folks. I've applied the patch to trunk and gcc-4_8-branch. Diego.
[Bug c/57201] Using --save-temps affects whether warning is printed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57201 --- Comment #7 from minux 2013-05-08 13:24:20 UTC --- the comment for function linemap_location_in_system_header_p in libcpp/line-map.c says: /* // snip Note that this function returns 1 if LOCATION belongs to a token that is part of a macro replacement-list defined in a system header, but expanded in a non-system file. */ so this behavior is intentional?
[Bug libstdc++/57212] New: Don't use pe-coff weak support with mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57212 Bug #: 57212 Summary: Don't use pe-coff weak support with mingw Classification: Unclassified Product: gcc Version: 4.7.4 Status: UNCONFIRMED Severity: major Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ylat...@gmail.com The issue was addressed in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52300, but it's missing a replacement in the generated header in libstdc++. The generated gthr.h checks for _GLIBCXX___MINGW32_GLIBCXX___ instead of __MINGW32__ #if __GXX_WEAK__ /* The pe-coff weak support isn't fully compatible to ELF's weak. For static libraries it might would work, but as we need to deal with shared versions too, we disable it for mingw-targets. */ #ifdef _GLIBCXX___MINGW32_GLIBCXX___ #undef _GLIBCXX_GTHREAD_USE_WEAK #define _GLIBCXX_GTHREAD_USE_WEAK 0 #endif
[Bug libstdc++/57212] Don't use pe-coff weak support with mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57212 --- Comment #1 from Andoni 2013-05-08 13:40:46 UTC --- Created attachment 30056 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30056 Fix libstdc threads for mingw
[Bug libstdc++/57212] Don't use pe-coff weak support with mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57212 Andoni changed: What|Removed |Added Attachment #30056|0 |1 is obsolete|| --- Comment #2 from Andoni 2013-05-08 13:42:11 UTC --- Created attachment 30057 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30057 Fix define for mingw Sorry, I uploaded the wrong patch :)
[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659 Diego Novillo changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #29 from Diego Novillo 2013-05-08 13:42:49 UTC --- Fixed in gcc-4_8-branch at rev 198708 and trunk at rev 198711.
[Bug libstdc++/57212] Don't use pe-coff weak support with mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57212 Paolo Carlini changed: What|Removed |Added CC||ktietz at gcc dot gnu.org Severity|major |normal --- Comment #3 from Paolo Carlini 2013-05-08 14:04:47 UTC --- CC-ing Kai.
[Bug c/57201] Using --save-temps affects whether warning is printed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57201 --- Comment #8 from Manuel López-Ibáñez 2013-05-08 14:23:07 UTC --- (In reply to comment #7) > the comment for function linemap_location_in_system_header_p > in libcpp/line-map.c says: > /* // snip >Note that this function returns 1 if LOCATION belongs to a token >that is part of a macro replacement-list defined in a system >header, but expanded in a non-system file. */ > > so this behavior is intentional? Yes. The idea is that if some piece of code gives a warning inside a macro in a system-header, we should not warn. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263#c8 I don't see how to reconcile this with --save-temps, unless we mark in the preprocessed code what was expanded from a system header. Interestingly, clang behaves the same, I guess following the same reasoning.
[Bug rtl-optimization/52235] rtlanal: commutative_operand_precedence should prioritize regs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52235 --- Comment #4 from Paulo J. Matos 2013-05-08 14:24:08 UTC --- This issue persists in HEAD, the submitted patch seems to have been forgotten. Ping, ping.
[Bug libstdc++/57212] Don't use pe-coff weak support with mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57212 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-08 Ever Confirmed|0 |1 --- Comment #4 from Kai Tietz 2013-05-08 14:26:30 UTC --- (In reply to comment #3) > CC-ing Kai. Yes, patch looks reasonable. Indeed we had here a hick-up of changes and it gets fixed by this. I am ok by this change
[Bug c/57201] Using --save-temps affects whether warning is printed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57201 --- Comment #9 from Ian Lance Taylor 2013-05-08 14:33:58 UTC --- The --save-temps thing is interesting, but I guess I'm more interested in how we can get the warning back. I can open up a different PR if people prefer.
[Bug c/57201] Using --save-temps affects whether warning is printed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57201 Chung-Ju Wu changed: What|Removed |Added CC||jasonwucj at gmail dot com --- Comment #10 from Chung-Ju Wu 2013-05-08 14:36:58 UTC --- (In reply to comment #2) > I should have clarified that the warning is correct with --save-temps. When > --save-temps is omitted, the warning is missing. That is wrong. There should > be a warning in this case. The presence of "#define stdout stdout" should not > inhibit a warning. > > Also, this is a regression, as GCC 4.6 does warn for this case (I didn't test > 4.7). I tried it on 4.7.3, 4.8-branch, and 4.9-trunk (4.9.0 20130502). 4.7.3 does warn for the case as well. There is no warning on both 4.8 and 4.9. Console output $ native-toolchain/bin/gcc --version gcc (20130502) 4.9.0 20130502 (experimental) Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ native-toolchain/bin/gcc -Wall -c ian.c $ native-toolchain/bin/gcc -Wall -c ian.c --save-temps ian.c: In function 'f': ian.c:5:3: warning: statement with no effect [-Wunused-value] stdout; ^ According to comment 8, maybe this is a fix, not a regression?
[Bug c/57201] Using --save-temps affects whether warning is printed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57201 --- Comment #11 from Manuel López-Ibáñez 2013-05-08 14:48:47 UTC --- (In reply to comment #9) > The --save-temps thing is interesting, but I guess I'm more interested in how > we can get the warning back. I can open up a different PR if people prefer. It seems a tricky case, what is the rationale to distinguish between this case and the cases mentioned in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263#c8 ?
[Bug libstdc++/57212] Don't use pe-coff weak support with mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57212 --- Comment #5 from Paolo Carlini 2013-05-08 15:11:53 UTC --- Thanks Kai, please commit the patch with an appropriate ChangeLog entry mainline and 4_8-branch. Please also send it to gcc-patches.
[Bug libstdc++/57212] Don't use pe-coff weak support with mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57212 --- Comment #6 from Paolo Carlini 2013-05-08 15:16:09 UTC --- Remember to regenerate Makefile.in.
[Bug c++/51226] [c++0x] ICE with opaque enum and invalid template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51226 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.9.0 --- Comment #3 from Paolo Carlini 2013-05-08 15:22:56 UTC --- Fixed for 4.9.0.
[Bug libstdc++/57213] New: failed formatted input overwrites output value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57213
Bug #: 57213
Summary: failed formatted input overwrites output value
Classification: Unclassified
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@tbricks.com
Hello!
Here is a small test:
#include
#include
int main()
{
std::istringstream iss("-a");
unsigned i = 12345;
iss >> i;
std::cout << i << std::endl;
return 0;
}
When building it with latest GCC 4.8.1 (svn rev. 198709) on Solaris 10 I got
the following output:
$ /opt/gcc-4.8/bin/g++ -v -std=c++03 a.cpp
Using built-in specs.
COLLECT_GCC=/opt/gcc-4.8/bin/g++
COLLECT_LTO_WRAPPER=/opt/gcc-4.8/libexec/gcc/i386-pc-solaris2.10/4.8.1/lto-wrapper
Target: i386-pc-solaris2.10
Configured with: /export/home/sbn/src/gcc-4.8/configure --prefix=/opt/gcc-4.8
--enable-languages=c,c++ --with-ld=/usr/ccs/bin/ld --without-gnu-ld
--with-gnu-as --with-as=/opt/csw/bin/gas
Thread model: posix
gcc version 4.8.1 20130508 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=c++98' '-shared-libgcc' '-mtune=generic'
'-march=pentium4'
/opt/gcc-4.8/libexec/gcc/i386-pc-solaris2.10/4.8.1/cc1plus -quiet -v a.cpp
-quiet -dumpbase a.cpp -mtune=generic -march=pentium4 -auxbase a -std=c++98
-version -o /var/tmp//ccqRQJAe.s
GNU C++ (GCC) version 4.8.1 20130508 (prerelease) (i386-pc-solaris2.10)
compiled by GNU C version 4.8.1 20130508 (prerelease), GMP version
4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/opt/gcc-4.8/lib/gcc/i386-pc-solaris2.10/4.8.1/../../../../i386-pc-solaris2.10/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/gcc-4.8/lib/gcc/i386-pc-solaris2.10/4.8.1/../../../../include/c++/4.8.1
/opt/gcc-4.8/lib/gcc/i386-pc-solaris2.10/4.8.1/../../../../include/c++/4.8.1/i386-pc-solaris2.10
/opt/gcc-4.8/lib/gcc/i386-pc-solaris2.10/4.8.1/../../../../include/c++/4.8.1/backward
/opt/gcc-4.8/lib/gcc/i386-pc-solaris2.10/4.8.1/include
/opt/gcc-4.8/include
/opt/gcc-4.8/lib/gcc/i386-pc-solaris2.10/4.8.1/include-fixed
/usr/include
End of search list.
GNU C++ (GCC) version 4.8.1 20130508 (prerelease) (i386-pc-solaris2.10)
compiled by GNU C version 4.8.1 20130508 (prerelease), GMP version
4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c518101980ab073fe5c4f884a6f42b1b
COLLECT_GCC_OPTIONS='-v' '-std=c++98' '-shared-libgcc' '-mtune=generic'
'-march=pentium4'
/opt/csw/bin/gas -v -V -Qy -s --32 -o /var/tmp//ccOebkCA.o
/var/tmp//ccqRQJAe.s
GNU assembler version 2.23.1 (i386-pc-solaris2.10) using BFD version (GNU
Binutils) 2.23.1
COMPILER_PATH=/opt/gcc-4.8/libexec/gcc/i386-pc-solaris2.10/4.8.1/:/opt/gcc-4.8/libexec/gcc/i386-pc-solaris2.10/4.8.1/:/opt/gcc-4.8/libexec/gcc/i386-pc-solaris2.10/:/opt/gcc-4.8/lib/gcc/i386-pc-solaris2.10/4.8.1/:/opt/gcc-4.8/lib/gcc/i386-pc-solaris2.10/:/usr/ccs/bin/
LIBRARY_PATH=/opt/gcc-4.8/lib/gcc/i386-pc-solaris2.10/4.8.1/:/opt/gcc-4.8/lib/gcc/i386-pc-solaris2.10/4.8.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-std=c++98' '-shared-libgcc' '-mtune=generic'
'-march=pentium4'
/opt/gcc-4.8/libexec/gcc/i386-pc-solaris2.10/4.8.1/collect2 -V -Y
P,/usr/ccs/lib:/lib:/usr/lib -Qy /usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/values-Xa.o /opt/gcc-4.8/lib/gcc/i386-pc-solaris2.10/4.8.1/crtbegin.o
-L/opt/gcc-4.8/lib/gcc/i386-pc-solaris2.10/4.8.1
-L/opt/gcc-4.8/lib/gcc/i386-pc-solaris2.10/4.8.1/../../.. /var/tmp//ccOebkCA.o
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/opt/gcc-4.8/lib/gcc/i386-pc-solaris2.10/4.8.1/crtend.o /usr/lib/crtn.o
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.1509
$ LD_LIBRARY_PATH=/opt/gcc-4.8/lib ./a.out
0
$ uname -a
SunOS node8 5.10 Generic_147441-16 i86pc i386 i86pc
But I expect it to return 12345 (and it's in fact the case if I use GCC 3.4.3
shipped with Solaris 10 SFW)
In C++ standard (C++03) I can see 22.2.2.1.2p1 [lib.facet.num.get.virtuals]:
"If an error occurs, val is unchanged; otherwise it is set to the resulting
value."
[Bug c/57214] New: ice: tree check: expected ssa_name, have integer_cst in coalesce_partitions, at tree-ssa-coalesce.c:1194
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57214 Bug #: 57214 Summary: ice: tree check: expected ssa_name, have integer_cst in coalesce_partitions, at tree-ssa-coalesce.c:1194 Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 30058 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30058 C source code I just tried to compile the package dvdauthor-0.7.1-3 on gcc-4.9 trunk dated 20130508 on an AMD x86_64 box. The compiler said mpeg2desc.c:335:13: internal compiler error: tree check: expected ssa_name, have integer_cst in coalesce_partitions, at tree-ssa-coalesce.c:1194 static void process_packets ^ 0xae522a tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../src/trunk/gcc/tree.c:8986 0x9c6422 tree_check ../../src/trunk/gcc/tree.h:3690 0x9c6422 coalesce_partitions ../../src/trunk/gcc/tree-ssa-coalesce.c:1194 0x9c6422 coalesce_ssa_name() ../../src/trunk/gcc/tree-ssa-coalesce.c:1337 0x97cea3 remove_ssa_form ../../src/trunk/gcc/tree-outof-ssa.c:900 0x97cea3 rewrite_out_of_ssa(ssaexpand*) ../../src/trunk/gcc/tree-outof-ssa.c:1133 0x5fd984 gimple_expand_cfg ../../src/trunk/gcc/cfgexpand.c:4541 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. Preprocessed source code attached. Flag -O2 required.
[Bug c/57214] ice: tree check: expected ssa_name, have integer_cst in coalesce_partitions, at tree-ssa-coalesce.c:1194
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57214 --- Comment #1 from David Binderman 2013-05-08 15:56:42 UTC --- Created attachment 30059 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30059 C source code
[Bug libstdc++/57213] failed formatted input overwrites output value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57213 --- Comment #1 from Jonathan Wakely 2013-05-08 16:01:01 UTC --- (In reply to comment #0) > In C++ standard (C++03) I can see 22.2.2.1.2p1 [lib.facet.num.get.virtuals]: > "If an error occurs, val is unchanged; otherwise it is set to the resulting > value." That wording was removed by DR 696 http://cplusplus.github.io/LWG/lwg-defects.html#696
[Bug c++/57215] New: cc1plus causes possible glibc free corruption
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57215
Bug #: 57215
Summary: cc1plus causes possible glibc free corruption
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com
Created attachment 30060
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30060
C++ source code
I just tried to compile the package efte-1.1-6
on gcc-4.9 trunk dated 20130508 on an AMD x86_64 box.
The compiler said
/home/dcb/rpmbuild/BUILD/efte-1.1/src/h_c.cpp:32:5: internal compiler error:
Aborted
int Hilit_C(EBuffer *BF, int /*LN*/, PCell B, int Pos, int Width, ELine *Line,
hlState &State, hsState *StateMap, int *ECol) {
^
0xaa373f crash_signal
../../src/trunk/gcc/toplev.c:333
0xeceaf1 analyze_candidates_and_replace
../../src/trunk/gcc/gimple-ssa-strength-reduction.c:3414
0xeceaf1 execute_strength_reduction
../../src/trunk/gcc/gimple-ssa-strength-reduction.c:3463
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
glibc said
*** glibc detected ***
/home/dcb/gcc/results/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1plus:
free(): invalid next size (fast): 0x0346d8d0 ***
It looks to me like some memory allocation goes wrong because
glibc complains.
Preprocessed source code attached. Flag -O2 required.
[Bug c/57216] New: error: definition in block 255 does not dominate use in block 252
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57216 Bug #: 57216 Summary: error: definition in block 255 does not dominate use in block 252 Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 30061 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30061 C source code I just tried to compile the package enigma-1.01-23 on gcc-4.9 trunk dated 20130508 on an AMD x86_64 box. The compiler said SDL_gfxPrimitives.c: In function 'ellipseColor': SDL_gfxPrimitives.c:2317:5: error: definition in block 255 does not dominate use in block 252 int ellipseColor(SDL_Surface * dst, Sint16 x, Sint16 y, Sint16 rx, Sint16 ry, Uint32 color) ^ for SSA_NAME: ypj_393 in statement: slsr_219 = ypj_393 - oi_341; SDL_gfxPrimitives.c:2317:5: internal compiler error: verify_ssa failed 0xa7d781 verify_ssa(bool) ../../src/trunk/gcc/tree-ssa.c:1046 0x859101 execute_function_todo ../../src/trunk/gcc/passes.c:1970 0x859ac7 execute_todo ../../src/trunk/gcc/passes.c:2002 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. Preprocessed source code attached. Flag -O2 required.
[Bug fortran/57217] New: [4.7/4.8/4.9 Regression][OOP] Accepts invalid TBP overriding - lacking arguments check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57217 Bug #: 57217 Summary: [4.7/4.8/4.9 Regression][OOP] Accepts invalid TBP overriding - lacking arguments check Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org, salvatore.filipp...@uniroma2.it Reported by Salvatore; very vaguely related to PR47978. In the following program, "clone" is overridden. The overridden procedure shall use for the dummy arguments "CLASS(base_type)" instead of "CLASS(r_type)" as in the original TBP - except for the PASS argument, which may be different. GCC 4.6 prints: procedure, pass(map) :: clone=> r_clone 1 Error: Types mismatch for dummy argument 'mapout' of 'clone' (1) in respect to the overridden procedure F2008, "4.5.7.3 Type-bound procedure overriding": "The overriding and overridden type-bound procedures shall satisfy the following conditions. [...] * Dummy arguments that correspond by position shall have the same names and characteristics, except for the type of the passed-object dummy arguments." module base_mod type base_type integer :: kind contains procedure, pass(map) :: clone=> base_clone end type base_type contains subroutine base_clone(map,mapout,info) implicit none class(base_type), intent(inout) :: map class(base_type), intent(inout) :: mapout integer :: info end subroutine base_clone end module base_mod module r_mod use base_mod type, extends(base_type) :: r_type real :: dat contains procedure, pass(map) :: clone=> r_clone end type r_type contains subroutine r_clone(map,mapout,info) implicit none class(r_type), intent(inout) :: map class(r_type), intent(inout) :: mapout integer :: info end subroutine r_clone end module r_mod
[Bug tree-optimization/57203] [4.9 Regression] verify_gimple failed after SLSR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57203 --- Comment #1 from Bill Schmidt 2013-05-08 17:52:20 UTC --- I can't reproduce this with an x86_64 cross-compiler today, using r198713. Could you please verify this still fails natively with at least r198709? I hope the main SLSR bug fix has taken care of this. I tried to use the x86_64 compile farm machines, but both of them were nonresponsive.
[Bug tree-optimization/57218] New: Excessive inlining even at -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57218 Bug #: 57218 Summary: Excessive inlining even at -Os Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org Created attachment 30062 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30062 test case (excerpt from newlib/libc/stdio/findfp.c) In the testcase, std is inlined (thrice) into __sinit at the tree level, even at -Os, thus increasing code size. I first noticed this as a regression for arc-elf32 going from 4.4 to 4.8. It used to be only inlined at -O3, not at -Os or -O2. I have since verified that it is also not inlined at -Os / -O2 for i686-pc-linux-gnu 4.7.2 20120921 (Red Hat 4.7.2-2), but it is inlined for i686-pc-linux-gnu GCC 4.8.0 and 4.9.0 20130422 (experimental) Going from 4.7.2 to 4.9.0 (experimental), that causes a size regression of 34.5% on i686-pc-linux-gnu at -Os.
[Bug rtl-optimization/52235] rtlanal: commutative_operand_precedence should prioritize regs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52235 --- Comment #5 from Steven Bosscher 2013-05-08 18:56:35 UTC --- (In reply to comment #4) > This issue persists in HEAD, the submitted patch seems to have been forgotten. > Ping, ping. Ping it on gcc-patches, BZ is *not* the place for that!
[Bug libstdc++/57212] Don't use pe-coff weak support with mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57212 Kai Tietz changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Kai Tietz 2013-05-08 19:20:35 UTC --- Ok, done. Applied to trunk, and 4.8 branch. So I close this bug as fixed.
[Bug other/57219] New: __builtin_isinf_sign source comments more restrictive than documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57219 Bug #: 57219 Summary: __builtin_isinf_sign source comments more restrictive than documentation Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: jtaylor.deb...@gmail.com in glibc bug [0] it is discussed to use __builtin_isinf_sign for C99 isinf. The source code and the patch mail [1] for __builtin_isinf_sign document that it returns -1, 0 or 1 as glibc isinf does. The gcc documentation on the other hand only says it returns the sign of the infinity. To avoid confusion it would be good if the source code comment or the documentation could be matched up to say the exact same thing. Either that the value of the return is undefined (but keeps sign) or that it is strictly define. [0] http://sourceware.org/bugzilla/show_bug.cgi?id=15367 [1] http://gcc.gnu.org/ml/gcc-patches/2008-05/msg01067.html
[Bug libstdc++/57220] New: [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220
Bug #: 57220
Summary: [mingw] Undefined reference to __mingw_strtod
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
Created attachment 30063
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30063
Output of -v -save-temps invokation
The following code when compiled with gcc 4.9.0 20130505 (experimental) using
mingw 64 bit using the compiler flags
-Wall
(with or without -std=c++11 or -pedantic-errors) causes a linker error:
//--
#include
int main() {}
//--
"c:\program
files\develop\gcc\bin\..\lib\gcc\x86_64-w64-mingw32\4.9.0\..\..\..\..\lib\libstdc++.a(c++locale.o)||In
function `strtod':|
\home\gfortran\gcc-home\binary\mingw32\native\x86_64\gcc\4.9-20130505\x86_64-w64-mingw32\include\stdlib.h|392|undefined
reference to `__mingw_strtod'"
[Bug libstdc++/57220] [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220 Daniel Krügler changed: What|Removed |Added Keywords||link-failure --- Comment #1 from Daniel Krügler 2013-05-08 19:33:25 UTC --- I should add that the link error occurs whether or whether not the -m32 flag is provided to the compiler and linker
[Bug libstdc++/57220] [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220 Daniel Krügler changed: What|Removed |Added CC||ktietz70 at googlemail dot ||com --- Comment #2 from Daniel Krügler 2013-05-08 19:35:13 UTC --- Kai, do you have any idea what may go wrong here?
[Bug libstdc++/57220] [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #3 from Kai Tietz 2013-05-08 19:47:20
UTC ---
Well, I see that this symbol is part of our libmingwex.a library on trunk. For
gcc 4.8 and above it is recommented to use 3.0 runtime-version for w64.
I assume you are using 2.x crt version and having 3.x headers.
A simple test for checking what mingw-w64 runtime you are using in fact is by
compiling the following code and execute it:
#include
int main()
{
printf ("%s\n", __mingw_get_crt_info ());
return 0;
}
[Bug middle-end/57219] __builtin_isinf_sign source comments more restrictive than documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57219 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||documentation Last reconfirmed||2013-05-08 Component|other |middle-end Ever Confirmed|0 |1 Severity|trivial |enhancement --- Comment #1 from Marc Glisse 2013-05-08 19:48:33 UTC --- I am in favor of documenting that the return value is always -1/0/+1.
[Bug libstdc++/57220] [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220 Kai Tietz changed: What|Removed |Added CC|ktietz70 at googlemail dot | |com | --- Comment #4 from Kai Tietz 2013-05-08 19:49:53 UTC --- I don't need it twice
[Bug libstdc++/57220] [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220 --- Comment #5 from Daniel Krügler 2013-05-08 19:56:06 UTC --- (In reply to comment #3) Thanks for the litmus test, Kay. The result output I'm getting is: MinGW-W64 Runtime 3.0 (alpha - rev. 0) -00-00 so it seems this is indeed the version 3.0.
[Bug libstdc++/57220] [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220 --- Comment #6 from Kai Tietz 2013-05-08 20:04:56 UTC --- Fine, by which date this version was built? I am pretty curious to see that issue for 4.9 due I don't happen to see it on my box. Could you check, if libmingwex.a contains for you the symbol in question? For me $ x86_64-w64-mingw32-nm.exe /usr/local/x86_64-w64-mingw32/lib/libmingwex.a | grep -e "__mingw_strtod" displays: T __mingw_strtod and shows symbol is present.
[Bug rtl-optimization/52235] rtlanal: commutative_operand_precedence should prioritize regs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52235 --- Comment #6 from Paulo J. Matos 2013-05-08 20:20:00 UTC --- (In reply to comment #5) > (In reply to comment #4) > > This issue persists in HEAD, the submitted patch seems to have been > > forgotten. > > Ping, ping. > > Ping it on gcc-patches, BZ is *not* the place for that! Sorry, ping redirected to gcc-patches.
[Bug libstdc++/57220] [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220 --- Comment #7 from Daniel Krügler 2013-05-08 20:25:44 UTC --- (In reply to comment #6) The attached '-v' '-save-temps' output indicates version 4.9.0 20130505 (experimental) (x86_64-w64-mingw32), but I'm not sure whether this is reliable in this context. The libmingwex.a file contains the string pattern __mingw_strtod twice, here the contexts of the findings: __tinytens_D2A __strtod __mingw_strtod __strtof __mingw_strtof 3 .rdata$zzz __mingw_strtod .rdata$zzz __strtodg /1900 The spaces shown here are actually NUL values. Is this information sufficiently precise?
[Bug libstdc++/57220] [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220 --- Comment #8 from Kai Tietz 2013-05-08 21:02:08 UTC --- Well, you should us the nm tool to check for existance of a symbol. Grepping for strings might lead you to wrong direction. I don't see anything obviously wrong on you temp-file. The only thing I am a bit confused about is that there seems to be a 4.7.2 directory used for crtend object ... so it looks to me that you might be still using two different runtimes and mixing stuff here happily. I just did a rebuild of all required stuff and I can't reproduce this issue. The options you've shown initially have for sure nothing to do with link-order, or about use of libraries.
[Bug libstdc++/57220] [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220 --- Comment #9 from Daniel Krügler 2013-05-08 21:41:40 UTC --- (In reply to comment #8) > Well, you should us the nm tool to check for existance of a symbol. Grepping > for strings might lead you to wrong direction. My apologies, I had seen the "grep" and misinterpreted what you are asking for. I can't find the exact tool named x86_64-w64-mingw32-nm.exe, but nm.exe instead and it gave me also T __mingw_strtod > I don't see anything obviously wrong on you temp-file. The only thing I am a > bit confused about is that there seems to be a 4.7.2 directory used for crtend > object ... so it looks to me that you might be still using two different > runtimes and mixing stuff here happily. Ouch - I didn't notice that! This indeed looks like a potential candidate for the actual root of problem! > I just did a rebuild of all required stuff and I can't reproduce this issue. > The options you've shown initially have for sure nothing to do with > link-order, > or about use of libraries. Thanks very much for all your help. I will proceed tomorrow following the potential "gcc-4.7.2" path problem.
[Bug c/45784] gcc OpenMP - error: invalid controlling predicate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45784 Geir Johansen changed: What|Removed |Added Known to fail||4.7.3 --- Comment #1 from Geir Johansen 2013-05-08 21:54:55 UTC --- Fails in GCC 4.7.3: $ gcc --version gcc (GCC) 4.7.3 20130411 (Cray Inc.) Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -c -fopenmp -std=c99 ISU3417.c ISU3417.c: In function 'vla_test': ISU3417.c:23:25: error: invalid controlling predicate $
[Bug c/42979] OpenMP #pragma omp taskwait after a label is not permitted - should fail at compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42979 Geir Johansen changed: What|Removed |Added Known to fail||4.7.3 --- Comment #1 from Geir Johansen 2013-05-08 21:57:20 UTC --- Problem still fails in 4.7.3: $ gcc --version gcc (GCC) 4.7.3 20130411 (Cray Inc.) Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -fopenmp ISU3243.c ; ./a.out ISU3243.c:14: FAIL - negative test case should not compile $
[Bug libstdc++/57220] [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220 Daniel Krügler changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #10 from Daniel Krügler 2013-05-08 22:09:14 UTC --- I couldn't resist and removed all gcc entries from the env PATH, which solved the problem. I apologize for the unnecessary trouble I have caused - at least I learned several new things about mingw.
[Bug libstdc++/57213] failed formatted input overwrites output value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57213 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Paolo Carlini 2013-05-08 22:17:04 UTC --- Indeed.
[Bug libgcc/57221] New: [4.8/4.9 regression] libgcc symbol visibility changes break Android blobs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57221 Bug #: 57221 Summary: [4.8/4.9 regression] libgcc symbol visibility changes break Android blobs Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc AssignedTo: unassig...@gcc.gnu.org ReportedBy: bernhard.rosenkran...@linaro.org Created attachment 30064 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30064 Proposed fix The changes in libgcc symbol visibilities that got into 4.8 (http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01462.html) break important Android blobs. Bionic (Android's libc) has some rather weird hacks that expose libgcc.a's __aeabi_uidiv and friends to applications linking to Bionic. The changed symbol visibility breaks this, resulting in e.g. a Galaxy Nexus Android build done with gcc 4.8 failing to boot to UI because it can't load its graphics drivers. It may make sense to change symbol visibility back to default if the target is Android. I've attached a patch that does that.
[Bug libgcc/57221] [4.8/4.9 regression] libgcc symbol visibility changes break Android blobs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57221 --- Comment #1 from Andrew Pinski 2013-05-08 23:52:19 UTC --- This sounds more like a bug in Bionic rather than anything else. Why not fix it there?
