[Bug fortran/57922] [OOP] Memory leak with allocatable polymorphics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57922 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #2) > (In reply to janus from comment #1) > > On x86_64-unknown-linux-gnu, I can confirm the problem with 4.7 and 4.8. > > However, the leak seems to be gone in the latest trunk version: > > Which is not very surprising as the finalization code should also take care > of this. See PR37336. I believe r199643 was the enabling commit. Right. Although the test case does not actually deal with finalization, but rather involves polymorphic deallocation (i.e. PR 46321). Anyway, closing as fixed.
[Bug fortran/46321] [OOP] Polymorphic deallocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46321 --- Comment #7 from janus at gcc dot gnu.org --- Comment 0 has apparently been fixed by r199643. One should check whether the remaining items are also handled correctly already (in particular comments 1 - 3).
[Bug target/57952] New: AVX/AVX2 no ymm registries used in a trivial reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57952
Bug ID: 57952
Summary: AVX/AVX2 no ymm registries used in a trivial reduction
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
in this quite trivial benchmark
gcc does not generate avx/avx2 instruction using ymm registries
c++ -Ofast -S polyAVX.cpp -march=core-avx2 ; grep -c "ymm" polyAVX.s
0
clang++ -Ofast -S polyAVX.cpp -march=core-avx2 ; grep -c "ymm" polyAVX.s
73
same for -march=corei7-avx
gcc version 4.9.0 20130718 (experimental) [trunk revision 201034] (GCC)
with obvious speed effect…
c++ -Ofast polyAVX.cpp -march=core-avx2 ; time ./a.out
0.508u 0.000s 0:00.50 100.0%0+0k 0+0io 1pf+0w
clang++ -Ofast polyAVX.cpp -march=core-avx2 ; time ./a.out
0.257u 0.000s 0:00.25 100.0%0+0k 0+0io 1pf+0w
cat polyAVX.cpp
//template
typedef float T;
inline T polyHorner(T y) {
return T(0x2.p0) + y * (T(0x2.p0) + y * (T(0x1.p0) + y * (T(0x5.55523p-4) +
y * (T(0x1.5554dcp-4) + y * (T(0x4.48f41p-8) + y * T(0xb.6ad4p-12)) ;
}
int main() {
bool ret=true;
float s =0;
for (int k=0; k!=100; ++k) {
float c = 1.f/100.f;
for (int i=1; i<1001; ++i) s+= polyHorner((float(i)+1.f)*c);
}
ret &= s!=0;
return ret ? 0 : -1;
}
[Bug fortran/56937] Unnecessarily temporary with array-vector assignments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56937 --- Comment #12 from Mikael Morin --- (In reply to Thomas Koenig from comment #11) > A big part is fixed now. > > Do people think that the case of comment#8 is worth fixing? At least it's worth having one PR open for it IMO.
[Bug c++/57880] cp/parser.c: 6 * missing break ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57880 --- Comment #2 from Paolo Carlini --- Ed?
[Bug c++/57888] using non-type template parameter in constexpr function for non static data member intializer segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57888 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Paolo Carlini --- This is a Dup. *** This bug has been marked as a duplicate of bug 57827 ***
[Bug c++/57827] compiler segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57827 Paolo Carlini changed: What|Removed |Added CC||plasmahh at gmx dot net --- Comment #4 from Paolo Carlini --- *** Bug 57888 has been marked as a duplicate of this bug. ***
[Bug c++/57892] g++ internal compiler error: in expand_expr_real_1, at expr.c:9122 while attempting to brace-initialize a dynamically allocated array class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57892 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.8.0, 4.8.1, 4.9.0 Resolution|--- |FIXED --- Comment #3 from Paolo Carlini --- In fact works with 4.8.0 too.
[Bug c++/57897] Target x86_64-w64-mingw32 failed with '-mno-fentry isn't compatible with SEH'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57897 Paolo Carlini changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #2 from Paolo Carlini --- Kai, can you have a look?
[Bug c++/57901] [4.8/4.9 Regression] Cannot call-by-value such that class has non-trivial (constexpr) move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57901 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-22 Known to work||4.7.3 Summary|[C++11][constexpr] Cannot |[4.8/4.9 Regression] Cannot |call-by-value such that |call-by-value such that |class has non-trivial |class has non-trivial |(constexpr) move|(constexpr) move |constructor |constructor Ever confirmed|0 |1 Known to fail||4.8.0, 4.8.1, 4.9.0 --- Comment #1 from Paolo Carlini --- We may have a Dup of this.
[Bug c++/57926] Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926 Paolo Carlini changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #3 from Paolo Carlini --- CC-ing Andrew for the array->pointer issue. Or is this a more general C++ front-end issue?
[Bug c++/57938] Compiler breaks when a lambda expression is used as a default parameter in a constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57938 Paolo Carlini changed: What|Removed |Added Known to work||4.8.0, 4.8.1, 4.9.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC|francesco.nidito at gmail dot com | --- Comment #2 from Paolo Carlini --- Works fine in 4.8.0 too.
[Bug c++/57930] missing destructor call after thrown exception in C++11 list initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57930 Paolo Carlini changed: What|Removed |Added CC||jwakely.gcc at gmail dot com --- Comment #2 from Paolo Carlini --- Maybe we have another one too, but isn't this PR57510?
[Bug lto/57602] [4.9 Regression] Runfails for several C/C++ benchmarks from spec2000 for i686 with -flto after r199422
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57602 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-22 Target Milestone|--- |4.9.0 Summary|Runfails for several C/C++ |[4.9 Regression] Runfails |benchmarks from spec2000|for several C/C++ |for i686 with -flto after |benchmarks from spec2000 |r199422 |for i686 with -flto after ||r199422 Ever confirmed|0 |1 --- Comment #7 from Uroš Bizjak --- Confirmed, a 4.9 regression.
[Bug c++/57948] internal compiler error: in initialize_reference, at cp/call.c:9285
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57948 Paolo Carlini changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-22 Ever confirmed|0 |1
[Bug c++/57946] internal compiler error: Segmentation fault in int_fits_type_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57946 Paolo Carlini changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-22 Ever confirmed|0 |1
[Bug c++/57947] internal compiler error: Segmentation fault using extended initializer lists without -std=c++11 or -std=gnu++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57947 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-07-22 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- I can't reproduce this (with or without the std::) Looks like the error message doesn't match the code (line #8 ?!?)
[Bug c++/57930] missing destructor call after thrown exception in C++11 list initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57930 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely --- Yes, that's probably the one I'm thinking of. *** This bug has been marked as a duplicate of bug 57510 ***
[Bug c++/57510] initializer_list memory leak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57510 Jonathan Wakely changed: What|Removed |Added CC||mmehlich at semanticdesigns dot co ||m --- Comment #3 from Jonathan Wakely --- *** Bug 57930 has been marked as a duplicate of this bug. ***
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 Bug 37336 depends on bug 55207, which changed state. Bug 55207 Summary: Automatic deallocation of variables declared in the main program http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug fortran/55207] Automatic deallocation of variables declared in the main program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from janus at gcc dot gnu.org --- I think this PR has been fixed by r199643.
[Bug fortran/57762] [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57762
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #2)
> > If it makes you happy, the following plugs the memory leak:
> >
> > --- a/gcc/testsuite/gfortran.dg/class_array_7.f03
> > +++ b/gcc/testsuite/gfortran.dg/class_array_7.f03
> > @@ -56,2 +56,3 @@ program main
> >if (trim (print_type ("a", a)) .ne. "a is base_type") call abort
> > + deallocate (a)
> > end program main
> >
> > ...
>
> Well, it makes valgrind happy.
And it certainly does not hurt to fix the test case in this regard.
> Is there any connection with PR55207 -
> Automatic deallocation of variables declared in the main program?
Yes, sure.
However, I don't directly see how the leak is related to r200084 ...
[Bug c++/57793] [4.7/4.8/4.9 Regression] ICE with bitfields in get_bit_range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57793 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED CC|jason at gcc dot gnu.org | Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #6 from Paolo Carlini --- Thus this is fixed for 4.9.0.
[Bug libstdc++/57925] discrete_distribution can be improved to O(1) per sampling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57925 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-07-22 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #3 from Paolo Carlini --- Handling this.
[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #3 from Manuel López-Ibáñez ---
(In reply to Andreas Schwab from comment #2)
> GCC uses the line number of the start of the asm statement, so line 8 is
> correct.
"Correct" as "expected" but not as "desired".
This is what Clang prints by comparison:
asm-line-number.c:3:12: error: invalid instruction mnemonic 'foo'
__asm__ ("foo\nfoo");
^
:1:2: note: instantiated into assembly here
foo
^~~
asm-line-number.c:3:18: error: invalid instruction mnemonic 'foo'
__asm__ ("foo\nfoo");
^
:2:1: note: instantiated into assembly here
foo
^~~
asm-line-number.c:10:7: error: invalid instruction mnemonic 'foo'
"foo"
^
:1:2: note: instantiated into assembly here
foo
^~~
3 errors generated.
It seems difficult to get there without an integrated assembler, but GCC could
at least provide better locations to GAS (and GAS understand and print column
numbers), so we could get:
asm-line-number.c: Assembler messages:
asm-line-number.c:3:12: Error: no such instruction: `foo'
asm-line-number.c:3:18: Error: no such instruction: `foo'
asm-line-number.c:10:7: Error: no such instruction: `foo'
Any editor worth its salt would jump to the correct line and column in the
sources.
[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950
--- Comment #4 from Frank Heckenbach ---
(In reply to Manuel López-Ibáñez from comment #3)
> (In reply to Andreas Schwab from comment #2)
> > GCC uses the line number of the start of the asm statement, so line 8 is
> > correct.
>
> "Correct" as "expected" but not as "desired".
And it would only explain the latter messages, not the former ones
reported as lines 3 and 4.
> This is what Clang prints by comparison:
>
> asm-line-number.c:3:12: error: invalid instruction mnemonic 'foo'
> __asm__ ("foo\nfoo");
>^
> :1:2: note: instantiated into assembly here
> foo
> ^~~
> asm-line-number.c:3:18: error: invalid instruction mnemonic 'foo'
> __asm__ ("foo\nfoo");
> ^
> :2:1: note: instantiated into assembly here
> foo
> ^~~
> asm-line-number.c:10:7: error: invalid instruction mnemonic 'foo'
> "foo"
> ^
> :1:2: note: instantiated into assembly here
> foo
> ^~~
> 3 errors generated.
>
> It seems difficult to get there without an integrated assembler, but GCC
> could at least provide better locations to GAS (and GAS understand and print
> column numbers), so we could get:
>
> asm-line-number.c: Assembler messages:
> asm-line-number.c:3:12: Error: no such instruction: `foo'
> asm-line-number.c:3:18: Error: no such instruction: `foo'
> asm-line-number.c:10:7: Error: no such instruction: `foo'
>
> Any editor worth its salt would jump to the correct line and column in the
> sources.
The clang output is indeed very nice, though to me, the wrong line
numbers (at least in the presence of "\n") are the more serious
problem than the lack of column numbers.
[Bug testsuite/57591] gcc-4.8 libbacktrace btest failure on Linux ppc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57591 --- Comment #4 from acrux --- same failure with gcc-4.8-20130718
[Bug libstdc++/57920] [c++11] Linux: std::random_device reads too much from /dev/urandom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57920 --- Comment #5 from Frank Heckenbach --- (In reply to Paolo Carlini from comment #1) > Note that in 4.8.x and mainline for modern x86 and x86_64 targets we don't > use /dev/urandom at all, we use __x86_rdrand. In general, the idea is that > more targets should use hardware support for random numbers and /dev/urandom > become just a fall back. I'm not sure changing fread to read it's worth the > trouble, and the change, since we are not talking about a regression, would > not go in 4.7.x branch anyway. Are you on x86 / x86_64 or something else? I use an AMD (Thuban) in 32 bit mode. This processor core is ~3 years old and AFAICS it doesn't support rdrand. So even if newer AMDs do supports it (which I don't know), I guess it's fair to say that for some more years there will be processors around which don't, and in this case I assume gcc falls back to /dev/urandom.
[Bug libstdc++/57920] [c++11] Linux: std::random_device reads too much from /dev/urandom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57920 --- Comment #6 from Frank Heckenbach --- (In reply to Paolo Carlini from comment #3) > I'm going to attach a patchlet which does the trick (fread -> read) for me. > Note I'm on purpose disabling the use of __builtin_ia32_rdrand32_step on my > x86_64 machine, the undef would not be in the committed patch of course. > > It would be great if you could test the change on your machines (in 4.7.x > just change random.h, no need to rebuild) and confirm that everything is > fine. I did the equivalent change to /usr/include/c++/4.7/bits/random.h and it works for me, thanks.
[Bug libstdc++/57920] [c++11] Linux: std::random_device reads too much from /dev/urandom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57920 --- Comment #7 from Paolo Carlini --- Agreed, let's just commit the improvement. If/when you become aware of ways to extend the use of builtins to other CPUs / targets, please let me know, thanks.
[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950 --- Comment #6 from Manuel López-Ibáñez --- (In reply to Andreas Schwab from comment #5) > The error messages are all generated by the assembler which knows nothing > about the source file. It knows the locations passed by GCC. (And it could know the column also, if gas supported that). GCC seem to be passing wrong line numbers.
[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950 --- Comment #5 from Andreas Schwab --- The error messages are all generated by the assembler which knows nothing about the source file.
[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950 --- Comment #7 from Andreas Schwab --- There is no way to know how the newline was written.
[Bug libstdc++/57953] no C++11 compliant std::ios_base::failure found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57953 --- Comment #1 from Jonathan Wakely --- (In reply to unixway.drive+gcc from comment #0) > §27.5.3 states that "ios_base defines <...> a class failure derived from > system_error". And http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011 states this isn't implemented yet.
[Bug c++/57892] g++ internal compiler error: in expand_expr_real_1, at expr.c:9122 while attempting to brace-initialize a dynamically allocated array class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57892 --- Comment #4 from morell at cs dot atu.edu --- Thank you! On 07/22/2013 04:55 AM, paolo.carlini at oracle dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57892 > > Paolo Carlini changed: > > What|Removed |Added > > Status|UNCONFIRMED |RESOLVED >Known to work||4.8.0, 4.8.1, 4.9.0 > Resolution|--- |FIXED > > --- Comment #3 from Paolo Carlini --- > In fact works with 4.8.0 too. >
[Bug libstdc++/57953] New: no C++11 compliant std::ios_base::failure found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57953 Bug ID: 57953 Summary: no C++11 compliant std::ios_base::failure found Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unixway.drive+gcc at gmail dot com §27.5.3 states that "ios_base defines <...> a class failure derived from system_error". The only std::ios_base::failure I see in a libstdc++ is a pre-C++11 ones. $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc/src/gcc-4.8.1/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-install-libiberty --disable-multilib --disable-libssp --disable-werror --enable-checking=release Thread model: posix gcc version 4.8.1 (GCC) $ g++ -std=c++11 test.cpp test.cpp: In function ‘int main(int, char**)’: test.cpp:10:18: error: ‘class std::ios_base::failure’ has no member named ‘code’ std::cout << e.code().value() << std::endl;
[Bug c++/57880] cp/parser.c: 6 * missing break ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57880 --- Comment #4 from Paolo Carlini --- Maybe he is simply traveling or unable to read email, don't you think? Still, if you want to send a patch to the mailing list, of course it's fine. For a quicker review, I would recommend CC-ing Jason and adding [C++ Patch] to the subject line. Thanks.
[Bug c++/54853] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54853 --- Comment #4 from Leonid Volnitsky --- I can not reproduce this ICE with 4.8.1. It is ok to close this bug.
[Bug c++/57926] Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926
--- Comment #4 from Andrew Macleod ---
Short answer.. I'm not a sure, but it appears to be a g++ thing.
I looks like g++ is using ARRAY_TYPE instead of POINTER_TYPE. the 4.8 branch
does the same thing, but it does seem odd to me. That means anywhere in the
compiler that uses POINTER_TYPE_P() is not going to trigger true for an array
in c++...
Going back to gcc 4.6 which only had __sync operations, the same issue exists:
cat t.cpp
long int Mutex[1];
int AcquireLogMutex(void)
{
return(__sync_fetch_and_add(Mutex, 1));
}
int main() {}
./cc1plus t.cpp
int AcquireLogMutex()
t.cpp:5:38: error: incompatible type for argument 1 of ‘__sync_fetch_and_add’
Im stunned this has never been tripped over.
I can fix it in the atomic code, but I don't know what that means to other
languages since I've never paid attention to the detailed meaning of ARRAY_TYPE
vs POINTER_TYPE. Just allowing the ARRAY_TYPE objects to pass the existing
atomic tests of POINTER_TYPE_P or POINTER_TYPE appears to generate all the
correct code and errors for atomics, so I guess thats is the way to go...?
there are only a couple of places the check is made.
[Bug c++/57905] braced-init-list allowed in default template-argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57905 Paolo Carlini changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-22 Ever confirmed|0 |1
[Bug middle-end/57811] Wasted work in find_reloads()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57811 --- Comment #4 from Po-Chun Chang --- Patch sent to gcc-patches@ http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00930.html
[Bug rtl-optimization/57812] Wasted work in computed_jump_p()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57812 --- Comment #3 from Po-Chun Chang --- Patch sent to gcc-patches@ http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00931.html
[Bug lto/57602] [4.9 Regression] Runfails for several C/C++ benchmarks from spec2000 for i686 with -flto after r199422
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57602 --- Comment #8 from Dmitry Gorbachev --- And a testcase from PR57879 fails with -O2 / -O1 and -flto, it happens when building GCC itself.
[Bug lto/57879] GCC with -flto generates invalid code for genmddeps program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57879 Dmitry Gorbachev changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Dmitry Gorbachev --- . *** This bug has been marked as a duplicate of bug 57602 ***
[Bug middle-end/57806] Wasted work in propagate_nothrow()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57806 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Fixed on mainline.
[Bug middle-end/57790] Wasted work in can_move_insns_across()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57790 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Fixed on mainline.
[Bug middle-end/57809] Wasted work in omega_eliminate_red()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57809 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #8 from Jeffrey A. Law --- Fixed on mainline.
[Bug fortran/57803] Wasted work in gfc_build_dummy_array_decl()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57803 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Fixed on mainline.
[Bug libstdc++/57920] [c++11] Linux: std::random_device reads too much from /dev/urandom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57920 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #8 from Paolo Carlini --- Done.
[Bug c++/57880] cp/parser.c: 6 * missing break ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57880 --- Comment #3 from David Binderman --- (In reply to Paolo Carlini from comment #2) > Ed? He's had eleven days to think about it and said nothing. I'd be happy to supply the obvious patch.
[Bug target/57949] [powerpc64] Structure parameter alignment issue with vector extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57949 --- Comment #1 from Bill Schmidt --- The front end identifies the structure as having the correct alignment. From the 001t.tu dump: @2846 record_type name: @2857size: @127 algn: 128 tag : struct flds: @2858 @2857 identifier_node strg: slngt: 1 @2858 field_decl name: @2870type: @16 scpe: @2846 srcp: vec-abi.c:3 chain: @2871 size: @22 algn: 64 bpos: @20 @2870 identifier_node strg: mlngt: 1 @2871 field_decl name: @2882type: @2817scpe: @2846 srcp: vec-abi.c:3 size: @19 algn: 128 bpos: @19 @2882 identifier_node strg: vlngt: 1
[Bug target/57954] New: AVX missing vxorps (zeroing) before vcvtsi2s %edx, slow down AVX code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954
Bug ID: 57954
Summary: AVX missing vxorps (zeroing) before vcvtsi2s %edx,
slow down AVX code
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
in the following benchmark performances w/o vectorization are poor wrt to
expectations
I find out this is due to non zeroing a register before using it
c++ -O2 -S polyAVX.cpp -mavx
as -v --64 -o polyAVX.o polyAVX.s
GNU assembler version 2.23.1 (x86_64-redhat-linux-gnu) using BFD version (GNU
Binutils) 2.23.1
c++ -O2 polyAVX.o -march=corei7-avx ; time ./a.out
53896530759
15.418u 0.000s 0:15.43 99.8%0+0k 0+0io 1pf+0w
patch polyAVX.s
49a50
> vxorps %xmm0,%xmm0,%xmm0
patching file polyAVX.s
as -v --64 -o polyAVX.o polyAVX.s
GNU assembler version 2.23.1 (x86_64-redhat-linux-gnu) using BFD version (GNU
Binutils) 2.23.1
c++ -O2 polyAVX.o -march=corei7-avx ; time ./a.out
10340756863
2.958u 0.000s 0:02.96 99.6%0+0k 0+0io 1pf+0w
I am sure there are many other cases like this.
gcc version 4.9.0 20130718 (experimental) [trunk revision 201034] (GCC)
cat polyAVX.cpp
//template
typedef float T;
inline T polyHorner(T y) {
return T(0x2.p0) + y * (T(0x2.p0) + y * (T(0x1.p0) + y * (T(0x5.55523p-4) +
y * (T(0x1.5554dcp-4) + y * (T(0x4.48f41p-8) + y * T(0xb.6ad4p-12)) ;
}
#include
#include
volatile unsigned long long rdtsc() {
unsigned int taux=0;
return __rdtscp(&taux);
}
int main() {
long long t=0;
bool ret=true;
float s =0;
for (int k=0; k!=100; ++k) {
float c = 1.f/1000.f;
t -=rdtsc();
for (int i=1; i<1001; ++i) s+= polyHorner((float(i)+float(k))*c);
t+=rdtsc();
}
ret &= s!=0;
std::cout << t <
[Bug c++/52816] [C++11] Access to private members inside decltype in the signature of a member template causes access control error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52816 --- Comment #4 from Paolo Carlini --- Let's add the testcase and close the issue as fixed for 4.8.0.
[Bug c++/54853] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54853 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-07-22 Ever confirmed|0 |1 --- Comment #3 from Paolo Carlini --- Please provide a reduced testcase, normally ~20 lines are more than enough for C++ front-end issues: http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
[Bug target/57949] [powerpc64] Structure parameter alignment issue with vector extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57949 --- Comment #2 from Bill Schmidt --- The wrong code is introduced during expand. vs.m is computed as mem(plus(virtual-incoming-args, 72)) with the pad at offset 80, v[0..1] at offset 88, and v[2..3] at offset 96. All are shown as having alignment 8. vs.m should have been placed at offset 80. After loading these into virtual regs with DI mode, they are stored at offsets 0, 8, 16, 24 from virtual-stack-vars, which is given an alignment of 128. Later the vector is loaded with V4SF mode.
[Bug lto/57602] [4.9 Regression] Runfails for several C/C++ benchmarks from spec2000 for i686 with -flto after r199422
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57602 Dmitry Gorbachev changed: What|Removed |Added CC||d.g.gorbachev at gmail dot com --- Comment #9 from Dmitry Gorbachev --- *** Bug 57879 has been marked as a duplicate of this bug. ***
[Bug fortran/57762] [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57762 --- Comment #4 from Tobias Burnus --- Author: burnus Date: Mon Jul 22 17:02:26 2013 New Revision: 201137 URL: http://gcc.gnu.org/viewcvs?rev=201137&root=gcc&view=rev Log: 2013-07-22 Tobias Burnus PR fortran/57762 * gfortran.dg/class_array_7.f03: Fix memory leak. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/class_array_7.f03
[Bug fortran/57762] [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57762 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Tobias Burnus --- The memory leak is now plugged - hence, close it as FIXED.
[Bug c++/52816] [C++11] Access to private members inside decltype in the signature of a member template causes access control error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52816 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Paolo Carlini --- Done.
[Bug c++/54853] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54853 Paolo Carlini changed: What|Removed |Added Status|WAITING |RESOLVED Known to work||4.8.1 Resolution|--- |FIXED --- Comment #5 from Paolo Carlini --- Ok, thanks.
[Bug c++/57926] Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926 Paolo Carlini changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Paolo Carlini --- Thanks a lot Andrew. I think it makes sense to CC Jason.
[Bug fortran/57906] Coarray components: Assignment optimized away (gfortran.dg/coarray/lib_realloc_1.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57906 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tobias Burnus --- FIXED on the trunk (4.9)
[Bug fortran/52052] [Coarray] Properly handle coarray components of derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52052 --- Comment #1 from Tobias Burnus --- (In reply to Tobias Burnus from comment #0) > Intrinsic assignment: Contrary to normal allocatable components, > no reallocation is allowed. The programmer guarantees that the shape and > type parameters are suitable. Patches: - http://gcc.gnu.org/ml/fortran/2013-06/msg00137.html (committed) - http://gcc.gnu.org/ml/fortran/2013-07/msg00041.html (committed)
[Bug fortran/52052] [Coarray] Properly handle coarray components of derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52052 --- Comment #2 from Tobias Burnus --- Author: burnus Date: Mon Jul 22 17:28:56 2013 New Revision: 201140 URL: http://gcc.gnu.org/viewcvs?rev=201140&root=gcc&view=rev Log: 2013-07-22 Tobias Burnus PR fortran/57906 PR fortran/52052 * class.c (gfc_build_class_symbol): Set coarray_comp. * trans-array.c (structure_alloc_comps): For coarrays, directly use the data pointer address. 2013-07-22 Tobias Burnus PR fortran/57906 PR fortran/52052 * coarray/lib_realloc_1.f90: Permit optimization. * gfortran.dg/coarray_31.f90: New. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/coarray/lib_realloc_1.f90
[Bug fortran/57906] Coarray components: Assignment optimized away (gfortran.dg/coarray/lib_realloc_1.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57906 --- Comment #1 from Tobias Burnus --- Author: burnus Date: Mon Jul 22 17:28:56 2013 New Revision: 201140 URL: http://gcc.gnu.org/viewcvs?rev=201140&root=gcc&view=rev Log: 2013-07-22 Tobias Burnus PR fortran/57906 PR fortran/52052 * class.c (gfc_build_class_symbol): Set coarray_comp. * trans-array.c (structure_alloc_comps): For coarrays, directly use the data pointer address. 2013-07-22 Tobias Burnus PR fortran/57906 PR fortran/52052 * coarray/lib_realloc_1.f90: Permit optimization. * gfortran.dg/coarray_31.f90: New. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/coarray/lib_realloc_1.f90
[Bug c++/57947] internal compiler error: Segmentation fault using extended initializer lists without -std=c++11 or -std=gnu++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57947
--- Comment #2 from Craig Schroeder ---
Unfortunately that is because I tried cleaning up the test case some more after
reducing it down. How about this:
namespace std
{
template class initializer_list {};
template struct D {D(std::initializer_list) {}};
D<0> d{1, 2, 3};
}
[Bug c++/57947] internal compiler error: Segmentation fault using extended initializer lists without -std=c++11 or -std=gnu++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57947 Paolo Carlini changed: What|Removed |Added Keywords||ice-on-invalid-code Status|WAITING |NEW --- Comment #3 from Paolo Carlini --- Ok, thanks.
[Bug target/57787] Wasted work in ix86_valid_target_attribute_inner_p() and ix86_pad_returns()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57787 --- Comment #2 from Po-Chun Chang --- Patch sent to gcc-patches@ http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00941.html
[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to Andreas Schwab from comment #7)
> There is no way to know how the newline was written.
Sorry I don't get this. Could you elaborate?
There are some technical limitations of GCC:
* string constants don't have their own location:
* asm expressions only have one location (starting at the "asm" keyword)
* GCC currently doesn't look at all into the string constant given to an asm
expression.
First, it is not clear that the location given to asm expressions needs to be
the location of the asm keyword. It could be the location of the string and it
would be already an improvement.
Second, when printing the assembler, GCC can check for newlines and simply
print the line directive after each newline. I see one potential problem:
static void f1 ()
{
__asm__ ("foo\n"
"foo");
}
This works OK now by pure chance but it will be broken by the above trick. To
reliably fix this, GCC must learn to track locations of multi-line strings.
Interestingly, the same problem we face when improving the diagnostics for
-Wformat: PR52952
[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950 --- Comment #9 from Andreas Schwab --- The assembler only sees literal newlines, it does not know how they were written in the source. The compiler cannot put line directives in the middle of an assembler string by itself because it cannot know how the assembler will interpret the text around the newline. This will surely break things.
[Bug c++/57926] Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926 Andrew Macleod changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |amacleod at redhat dot com --- Comment #6 from Andrew Macleod --- Created attachment 30535 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30535&action=edit should fix bug So this would appear to fix the problem by allowing ARRAY_TYPE as well as POINTER_TYPE to appear where the atomic pointer is required. I haven't bootstrapped it or anything yet, but assuming that ARRAY_TYPE from the g++ front-end means the same as POINTER_TYPE in this context, this would be the solution and I'll proceed with a test case and proper bootstrap/submission. You can try it if you want :-) I tried a few different contexts and got the behaviour I expected in each case.
[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950 --- Comment #10 from Manuel López-Ibáñez --- (In reply to Andreas Schwab from comment #9) > The assembler only sees literal newlines, it does not know how they were > written in the source. Is there other way to generate literal newlines apart from printing a literal newline? And why it matters how they were written in the source code? The point is that GCC should see that it is a literal newline and hint GAS that it was actually in the same line (or not) in the original source code. GAS does not need to know anything. > The compiler cannot put line directives in the middle of an assembler string > by itself because it cannot know how the assembler will interpret the text > around the newline. This will surely break things. If there are restrictions on the lines where the location directives can appear in an assembler file, then it is a problem, yes. I wasn't aware of such restrictions, I was assuming that they were basically like preprocessor directives. Oh, well, another reason why an integrated assembler is such a good idea...
[Bug target/57949] [powerpc64] Structure parameter alignment issue with vector extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57949
--- Comment #3 from Bill Schmidt ---
The problem is target-specific, in config/rs6000/rs6000.c:
rs6000_function_arg_boundary().
static unsigned int
rs6000_function_arg_boundary (enum machine_mode mode, const_tree type)
{
if (DEFAULT_ABI == ABI_V4
&& (GET_MODE_SIZE (mode) == 8
|| (TARGET_HARD_FLOAT
&& TARGET_FPRS
&& (mode == TFmode || mode == TDmode
return 64;
else if (SPE_VECTOR_MODE (mode)
|| (type && TREE_CODE (type) == VECTOR_TYPE
&& int_size_in_bytes (type) >= 8
&& int_size_in_bytes (type) < 16))
return 64;
else if (ALTIVEC_OR_VSX_VECTOR_MODE (mode)
|| (type && TREE_CODE (type) == VECTOR_TYPE
&& int_size_in_bytes (type) >= 16))
return 128;
else if (TARGET_MACHO
&& rs6000_darwin64_abi
&& mode == BLKmode
&& type && TYPE_ALIGN (type) > 64)
return 128;
else
return PARM_BOUNDARY;
}
Note that the TARGET_MACHO + Darwin ABI case does what the 64-bit PowerPC ELF
ABI implies should be done. It's not clear to me why that ABI is excluded.
[Bug middle-end/56417] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56417 --- Comment #6 from Jakub Jelinek --- Created attachment 30536 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30536&action=edit gcc49-pr56417.patch Untested fix. Though, strlen on function address? Ugh.
[Bug middle-end/57955] New: Uniquization of constants breaks constant alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57955 Bug ID: 57955 Summary: Uniquization of constants breaks constant alignment Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org A patch to improve uniquization of constants at the tree level broke alignment of constants and vectorized copies. gcc.target/powerpc/ppc-vector-memcpy.c
[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950 --- Comment #11 from Andreas Schwab --- See the example in the original description.
[Bug middle-end/57955] Uniquization of constants breaks constant alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57955 David Edelsohn changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-22 CC||bergner at gcc dot gnu.org, ||ebotcazou at gcc dot gnu.org, ||meissner at gcc dot gnu.org, ||pthaugen at gcc dot gnu.org Known to work||4.3.0, 4.4.0, 4.5.0 Ever confirmed|0 |1 Known to fail||4.6.0, 4.7.0, 4.8.0 --- Comment #1 from David Edelsohn --- Confirmed.
[Bug middle-end/57782] Wasted work in remove_path()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57782 --- Comment #1 from Po-Chun Chang --- Patch sent to gcc-patches@ http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00963.html
[Bug middle-end/57661] [4.9 Regression] ICE: SIGSEGV in verify_ssa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57661 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Yeah, ipa-split.c together with MEM_REF gimple_clobber_p and anonymous SSA_NAME cause this. ipa-split intentionally ignores clobber stmts during analysis, because they aren't real stmts, worst case we just ignore them and/or throw them away. If a clobber has a decl on lhs, then the decl is always present and not a problem. If it is a MEM_REF clobber with non-anonymous SSA_NAME, it is also just fine, ipa-split will during the cloning of the fn to *.part.* turn those SSA_NAMEs into SSA_NAME_IS_DEFAULT_DEF ones, and then tree-ssa-live will throw such clobbers away as useless. But anonymous SSA_NAMEs aren't meant to be ever SSA_NAME_IS_DEFAULT_DEF, which causes this problem. Perhaps ipa-split should just fix such SSA_NAMEs up (look up what anonymous SSA_NAMEs have no SSA_NAME_DEFAULT_STMT and remove all clobbers that depend on those and remove those SSA_NAMEs?
[Bug middle-end/57955] Uniquization of constants breaks constant alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57955 --- Comment #2 from Eric Botcazou --- The subject is very misleading, the alignment of constants is _not_ changed at all, otherwise many things would have been broken. The only change pertains to the internal alignment of initializers and cannot break anything, as it at most trades questionable optimization patterns for a smaller data footprint.
[Bug middle-end/57661] [4.9 Regression] ICE: SIGSEGV in verify_ssa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57661 --- Comment #4 from Jakub Jelinek --- Perhaps if copy_cfg_body saved a pointer to the blocks_to_copy bitmap temporarily into a new field in *id, the copying of clobber stmts could check if for MEM_REF clobbers the SSA_NAME mentioned there has a definition in a block not listed in blocks_to_copy and in that case instead of copying over the clobber stmt just throw it on the floor.
[Bug c++/57942] g++-4.8.1 tries to instantiate wrong constructor (C++11)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57942 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-07-22 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #2 from Paolo Carlini --- Thanks for the analysis. Mine.
[Bug c/57956] New: missing 'msgstr' section errors when building
x -ogengtype-lex.c ../.././gcc/gengtype-lex.l && { \
echo '#include "bconfig.h"' > gengtype-lex.c.tmp; \
cat gengtype-lex.c >> gengtype-lex.c.tmp; \
mv gengtype-lex.c.tmp gengtype-lex.c; \
}
g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -fno-common
-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../.././gcc -I../.././gcc/build
-I../.././gcc/../include -I../.././gcc/../libcpp/include
-I/home/townsend/mesasdk/include -I/home/townsend/mesasdk/include
-I/home/townsend/mesasdk/include -I../.././gcc/../libdecnumber
-I../.././gcc/../libdecnumber/bid -I../libdecnumber
-I../.././gcc/../libbacktrace\
-DBASEVER="\"4.9.0\"" -DDATESTAMP="\" 20130722\"" \
-DREVISION="\"\"" \
-DDEVPHASE="\" (experimental)\"" -DPKGVERSION="\"(GCC) \"" \
-DBUGURL="\"<http://gcc.gnu.org/bugs.html>\"" -o build/version.o
../.././gcc/version.c
7227 translated messages, 1763 fuzzy translations, 657 untranslated messages.
/bin/sh ../.././gcc/../move-if-change tmp-gi.list gtyp-input.list
echo timestamp > s-gtyp-input
echo "#define BUILDING_GCC_MAJOR `echo 4.9.0 | sed -e 's/^\([0-9]*\).*$/\1/'`"
> bversion.h
TARGET_CPU_DEFAULT="" \
HEADERS="config/i386/i386-protos.h config/linux-protos.h tm-preds.h"
DEFINES="" \
/bin/sh ../.././gcc/mkconfig.sh tm_p.h
echo "#define BUILDING_GCC_MINOR `echo 4.9.0 | sed -e
's/^[0-9]*\.\([0-9]*\).*$/\1/'`" >> bversion.h
rm -f tmp-all-tree.def
echo "#define BUILDING_GCC_PATCHLEVEL `echo 4.9.0 | sed -e
's/^[0-9]*\.[0-9]*\.\([0-9]*\)$/\1/'`" >> bversion.h
echo '#include "tree.def"' > tmp-all-tree.def
../.././gcc/po/zh_TW.po:48196:4: parse error
echo "#define BUILDING_GCC_VERSION (BUILDING_GCC_MAJOR * 1000 +
BUILDING_GCC_MINOR)" >> bversion.h
../.././gcc/po/zh_TW.po:48196: missing `msgstr' section
../.././gcc/po/zh_TW.po:48212:4: parse error
../.././gcc/po/zh_TW.po:48212: missing `msgstr' section
../.././gcc/po/zh_TW.po:48217:4: parse error
../.././gcc/po/zh_TW.po:48217: missing `msgstr' section
../.././gcc/po/zh_TW.po:48225:4: parse error
../.././gcc/po/zh_TW.po:48225: missing `msgstr' section
../.././gcc/po/zh_TW.po:48234:4: parse error
../.././gcc/po/zh_TW.po:48234: missing `msgstr' section
../.././gcc/po/zh_TW.po:48239:4: parse error
../.././gcc/po/zh_TW.po:48239: missing `msgstr' section
../.././gcc/po/zh_TW.po:48276:4: parse error
../.././gcc/po/zh_TW.po:48276: missing `msgstr' section
../.././gcc/po/zh_TW.po:48301:4: parse error
../.././gcc/po/zh_TW.po:48301: missing `msgstr' section
../.././gcc/po/zh_TW.po:48310:4: parse error
../.././gcc/po/zh_TW.po:48310: missing `msgstr' section
../.././gcc/po/zh_TW.po:48325:4: parse error
../.././gcc/po/zh_TW.po:48325: missing `msgstr' section
/usr/bin/msgfmt: too many errors, aborting
echo 'END_OF_BASE_TREE_CODES' >> tmp-all-tree.def
make[3]: *** [po/zh_TW.gmo] Error 1
make[3]: *** Waiting for unfinished jobs
echo timestamp > s-bversion
echo '#include "c-family/c-common.def"' >> tmp-all-tree.def
ltf="../.././gcc/ada/gcc-interface/ada-tree.def ../.././gcc/cp/cp-tree.def
../.././gcc/java/java-tree.def ../.././gcc/objc/objc-tree.def"; for f in $ltf;
do \
echo "#include \"$f\""; \
done | sed 's|../.././gcc/||' >> tmp-all-tree.def
/bin/sh ../.././gcc/../move-if-change tmp-all-tree.def all-tree.def
echo timestamp > s-alltree
/bin/sh ../.././gcc/../move-if-change tmp-optionlist optionlist
echo timestamp > s-options
make[3]: Leaving directory
`/home/townsend/mesasdk-src/gcc/host-x86_64-pc-linux-gnu/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/townsend/mesasdk-src/gcc'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/townsend/mesasdk-src/gcc'
make: *** [all] Error 2
Configuration was:
./configure CC=gcc --build=x86_64-pc-linux-gnu --prefix=/home/townsend/mesasdk
--with-gmp=/home/townsend/mesasdk --with-mpfr=/home/townsend/mesasdk
--with-mpc=/home/townsend/mesasdk --enable-languages=c,c++,fortran
--disable-multilib
I was able to build without this issue back in April 2013; I imagine one of the
updates in the interim may have an upgraded toolset prerequisite that FC6
doesn't meet. But what, exactly, is it?
[Bug middle-end/57955] Uniquization of constants breaks constant alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57955 --- Comment #3 from David Edelsohn --- The change caused a testcase failure, which was not investigated. I don't understand the comment "questionable optimization patterns". Optimizing for size should be controlled by -Os.
[Bug middle-end/57661] [4.9 Regression] ICE: SIGSEGV in verify_ssa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57661 --- Comment #5 from Jakub Jelinek --- Created attachment 30537 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30537&action=edit gcc49-pr57661.patch Untested fix.
[Bug fortran/57957] New: Double free or corruption (fasttop)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57957 Bug ID: 57957 Summary: Double free or corruption (fasttop) Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: songtao.thu at gmail dot com A simple test: ! Test program main implicit none type :: type1 real, allocatable :: anum(:) end type type1 type :: type2 type(type1) :: temp end type type2 type(type1) :: uKnot type(type2) :: a uKnot = type1([real :: 0,0,0,1,2,3,4,4,5,5,5]) a = type2(uKnot) end which leads to: *** Error in `./a.out': double free or corruption (fasttop): 0x0184bf90 *** === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x80a46)[0x7fce37214a46] ./a.out[0x400a5a] ./a.out[0x400aa0] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fce371b5ea5] ./a.out[0x400699] === Memory map: 0040-00401000 r-xp 08:06 792386 /home/taosong/Dropbox/[Tao]Codes/MyFortran/Try/a.out 0060-00601000 r--p 08:06 792386 /home/taosong/Dropbox/[Tao]Codes/MyFortran/Try/a.out 00601000-00602000 rw-p 1000 08:06 792386 /home/taosong/Dropbox/[Tao]Codes/MyFortran/Try/a.out 01849000-0186a000 rw-p 00:00 0 [heap] 7fce36a3d000-7fce36a52000 r-xp 08:06 1310725 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fce36a52000-7fce36c51000 ---p 00015000 08:06 1310725 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fce36c51000-7fce36c52000 r--p 00014000 08:06 1310725 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fce36c52000-7fce36c53000 rw-p 00015000 08:06 1310725 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fce36c53000-7fce36d56000 r-xp 08:06 1314626 /lib/x86_64-linux-gnu/libm-2.17.so 7fce36d56000-7fce36f56000 ---p 00103000 08:06 1314626 /lib/x86_64-linux-gnu/libm-2.17.so 7fce36f56000-7fce36f57000 r--p 00103000 08:06 1314626 /lib/x86_64-linux-gnu/libm-2.17.so 7fce36f57000-7fce36f58000 rw-p 00104000 08:06 1314626 /lib/x86_64-linux-gnu/libm-2.17.so 7fce36f58000-7fce36f93000 r-xp 08:06 1057181 /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0 7fce36f93000-7fce37192000 ---p 0003b000 08:06 1057181 /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0 7fce37192000-7fce37193000 r--p 0003a000 08:06 1057181 /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0 7fce37193000-7fce37194000 rw-p 0003b000 08:06 1057181 /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0 7fce37194000-7fce37352000 r-xp 08:06 1314578 /lib/x86_64-linux-gnu/libc-2.17.so 7fce37352000-7fce37551000 ---p 001be000 08:06 1314578 /lib/x86_64-linux-gnu/libc-2.17.so 7fce37551000-7fce37555000 r--p 001bd000 08:06 1314578 /lib/x86_64-linux-gnu/libc-2.17.so 7fce37555000-7fce37557000 rw-p 001c1000 08:06 1314578 /lib/x86_64-linux-gnu/libc-2.17.so 7fce37557000-7fce3755c000 rw-p 00:00 0 7fce3755c000-7fce37671000 r-xp 08:06 1048919 /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0 7fce37671000-7fce37871000 ---p 00115000 08:06 1048919 /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0 7fce37871000-7fce37872000 r--p 00115000 08:06 1048919 /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0 7fce37872000-7fce37874000 rw-p 00116000 08:06 1048919 /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0 7fce37874000-7fce37897000 r-xp 08:06 1314554 /lib/x86_64-linux-gnu/ld-2.17.so 7fce37a77000-7fce37a7b000 rw-p 00:00 0 7fce37a93000-7fce37a96000 rw-p 00:00 0 7fce37a96000-7fce37a97000 r--p 00022000 08:06 1314554 /lib/x86_64-linux-gnu/ld-2.17.so 7fce37a97000-7fce37a99000 rw-p 00023000 08:06 1314554 /lib/x86_64-linux-gnu/ld-2.17.so 7fff3b3ac000-7fff3b3cd000 rw-p 00:00 0 [stack] 7fff3b3fe000-7fff3b40 r-xp 00:00 0 [vdso] ff60-ff601000 r-xp 00:00 0 [vsyscall] Program received signal SIGABRT: Process abort signal. Backtrace for this error: #0 0x7FCE37575577 #1 0x7FCE37575B7E #2 0x7FCE371CB0AF #3 0x7FCE371CB037 #4 0x7FCE371CE697 #5 0x7FCE372085AA #6 0x7FCE37214A45 #7 0x400A59 in MAIN__ at main.f95:? Aborted (core dumped) Anyway, ifort 12.0 works well with it. Hopefully some experts can figure it out.
[Bug middle-end/57780] Wasted work in subst_dup()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57780 --- Comment #1 from Po-Chun Chang --- Patch sent to gcc-patches@ http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00970.html
[Bug c++/57958] New: Incorrect code generation in lambda with argument of type reference to template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57958 Bug ID: 57958 Summary: Incorrect code generation in lambda with argument of type reference to template class Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tudorb at fb dot com Created attachment 30538 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30538&action=edit Source file that exhibits broken behavior gcc (tested in 4.6.2 and 4.7.1) generates incorrect code for the "fn" lambda, resulting in an extraneous destructor call. Compiler with -O0 (this is reduced from a more complex example involving shared_ptr which exhibited the bug with -O3 as well). Source attached. The bug remains without #include and without the call to printf, which are there just for exposition. x86_64 disassembly (from gcc 4.7.1): Dump of assembler code for function operator()(Foo const&) const: 0x004006ec <+0>:push %rbp 0x004006ed <+1>:mov%rsp,%rbp 0x004006f0 <+4>:sub$0x30,%rsp 0x004006f4 <+8>:mov%rdi,-0x18(%rbp) 0x004006f8 <+12>:mov%rsi,-0x20(%rbp) 0x004006fc <+16>:mov%rdx,-0x28(%rbp) => 0x00400700 <+20>:mov-0x28(%rbp),%rdx 0x00400704 <+24>:lea-0x1(%rbp),%rax 0x00400708 <+28>:mov%rdx,%rsi 0x0040070b <+31>:mov%rax,%rdi 0x0040070e <+34>:callq 0x400794 ::Foo(Foo const&)> 0x00400713 <+39>:lea-0x1(%rbp),%rax 0x00400717 <+43>:mov%rax,%rdi 0x0040071a <+46>:callq 0x4007b2 ::~Foo()> 0x0040071f <+51>:leaveq 0x00400720 <+52>:retq End of assembler dump. The bug only happens if Foo is a template. If Foo is not a template, the code is correct: Dump of assembler code for function operator()(Foo const&) const: 0x004006ec <+0>:push %rbp 0x004006ed <+1>:mov%rsp,%rbp 0x004006f0 <+4>:sub$0x20,%rsp 0x004006f4 <+8>:mov%rdi,-0x8(%rbp) 0x004006f8 <+12>:mov%rsi,-0x10(%rbp) 0x004006fc <+16>:mov%rdx,-0x18(%rbp) => 0x00400700 <+20>:mov-0x18(%rbp),%rdx 0x00400704 <+24>:mov-0x8(%rbp),%rax 0x00400708 <+28>:mov%rdx,%rsi 0x0040070b <+31>:mov%rax,%rdi 0x0040070e <+34>:callq 0x4007a6 0x00400713 <+39>:mov-0x8(%rbp),%rax 0x00400717 <+43>:leaveq 0x00400718 <+44>:retq End of assembler dump.
[Bug c++/57958] Incorrect code generation in lambda with argument of type reference to template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57958 --- Comment #1 from Tudor Bosman --- Created attachment 30539 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30539&action=edit Source file that exhibits broken behavior
[Bug c++/57958] Incorrect code generation in lambda with argument of type reference to template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57958 --- Comment #2 from Tudor Bosman --- g++ -v output (ignore the weird paths): Using built-in specs. COLLECT_GCC=l/f/third-party/centos5.2-native/gcc/gcc-4.7.1/cc6c9dc/bin/g++ COLLECT_LTO_WRAPPER=/mnt/gvfs/third-party/1ebd27fa7983fc50f525eb890ae74ebbb9336a72/centos5.2-native/gcc/gcc-4.7.1/cc6c9dc/bin/../libexec/gcc/x86_64-redhat-linux-gnu/4.7.1/lto-wrapper Target: x86_64-redhat-linux-gnu Configured with: /home/engshare/third-party/src/gcc/gcc-4.7.1/gcc-4.7.1/configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu --prefix=/home/engshare/third-party/centos5.2-native/gcc/gcc-4.7.1/cc6c9dc --exec-prefix=/home/engshare/third-party/centos5.2-native/gcc/gcc-4.7.1/cc6c9dc --bindir=/home/engshare/third-party/centos5.2-native/gcc/gcc-4.7.1/cc6c9dc/bin --sbindir=/home/engshare/third-party/centos5.2-native/gcc/gcc-4.7.1/cc6c9dc/sbin --sysconfdir=/home/engshare/third-party/centos5.2-native/gcc/gcc-4.7.1/cc6c9dc/etc --datadir=/home/engshare/third-party/centos5.2-native/gcc/gcc-4.7.1/cc6c9dc/share --includedir=/home/engshare/third-party/centos5.2-native/gcc/gcc-4.7.1/cc6c9dc/include --libdir=/home/engshare/third-party/centos5.2-native/gcc/gcc-4.7.1/cc6c9dc/lib --libexecdir=/home/engshare/third-party/centos5.2-native/gcc/gcc-4.7.1/cc6c9dc/libexec --localstatedir=/home/engshare/third-party/centos5.2-native/gcc/gcc-4.7.1/cc6c9dc/var --sharedstatedir=/home/engshare/third-party/centos5.2-native/gcc/gcc-4.7.1/cc6c9dc/com --mandir=/home/engshare/third-party/centos5.2-native/gcc/gcc-4.7.1/cc6c9dc/share/man --infodir=/home/engshare/third-party/centos5.2-native/gcc/gcc-4.7.1/cc6c9dc/share/info --with-gmp=/home/engshare/third-party/centos5.2-native/gmp/gmp-5.0.1/da39a3e --with-mpfr=/home/engshare/third-party/centos5.2-native/mpfr/mpfr-3.0.0/c68f0aa --with-mpc=/home/engshare/third-party/centos5.2-native/mpc/mpc-0.8.2/18cfc0e --with-ppl=/home/engshare/third-party/centos5.2-native/ppl/ppl-0.10/c68f0aa --with-cloog=/home/engshare/third-party/centos5.2-native/cloog/cloog-0.15.7/ab7be4d --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,fortran --disable-libgcj --enable-linker-build-id --with-gnu-as --with-gnu-ld --with-host-libstdcxx='-L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -lstdc++' --disable-multilib --enable-libstdcxx-time Thread model: posix gcc version 4.7.1 (GCC)
[Bug fortran/57957] Double free or corruption (fasttop)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57957 Tao Song changed: What|Removed |Added Severity|normal |major
[Bug c++/57926] Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926 --- Comment #7 from Andrew Macleod --- btw, that patch passes bootstrap and a new testcase based on a modified version of the bug report test.
