[Bug target/60653] [4.9 Regression] gfortran: ICE (segmentation fault) in lra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60653 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- I'll close this as a dup. If we want the testcase, we can add it afterwards. *** This bug has been marked as a duplicate of bug 60697 ***
[Bug target/60697] [aarch64] LRA ICE (Segfault) while building 435.gromacs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60697 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- *** Bug 60653 has been marked as a duplicate of this bug. ***
[Bug ada/60411] ADA bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 --- Comment #13 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Wed Apr 9 07:57:48 2014 New Revision: 209237 URL: http://gcc.gnu.org/viewcvs?rev=209237root=gccview=rev Log: PR ada/60411 * s-osinte-android.ads: Adjust. Modified: trunk/gcc/ada/s-osinte-android.ads
[Bug ada/60411] ADA bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 --- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Sorry about the mess, can you try after the latest change?
[Bug ada/60411] Ada bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 Summary|ADA bootstrap failure on|Ada bootstrap failure on |ARM |ARM
[Bug fortran/60780] Equivalence statements in nested modules results in fast growing duplicate statements in module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-09 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- May be related to pr 38171. Rather related to pr40958 comment 13.
[Bug fortran/40958] module files too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |NEW --- Comment #17 from Dominique d'Humieres dominiq at lps dot ens.fr --- However, the fundamental(?) issue of module sizes growing exponentially with deep module hierarchies still remains. The solution to that is to not include transitive dependencies, which in turn would require a module cache for good performance. Whether that is worth doing, and who is willing and able to do it, is unclear. See pr60780 for an example.
[Bug fortran/60781] cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60781 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-04-09 Ever confirmed|0 |1 --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- I think this PR should be closed as INVALID.
[Bug fortran/50535] transformational intrinsic functions not allowed in statement functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50535 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-09 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at r209236.
[Bug fortran/60777] Fortran 2003: RECURSIVE function rejected in specification expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60777 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-09 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed.
[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- I've bisected it (with hacked ld wrapper script that reported a 2010-ish GNU ld in --version) down to r207489. As Honza's 2014-02-04 change looked just like an optimization, I wonder whether we couldn't perhaps just conditionalize those changes (the ipa.c and/or the lto-partition.c change) on whether linker plugin is used or not (at least temporarily for 4.9). Honza, ping, all the other 3 pending P1s have patches floating around or in the works, it would be nice to get rc1 out this week.
[Bug fortran/60774] f951: internal compiler error: Segmentation fault: 11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60774 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Reduced test giving an ICE with a clean trunk (r209224) program energy implicit none ! all dble integer(kind=4)::ns ! size of spatial lattice integer(kind=4)::nt ! size of temporal lattice; nt = ns integer(kind=4)::i,j,k,l!,iu,id,ju,jd,ku,kd,lu,ld integer(kind=4),allocatable::back(:,:) ! works up to 20,10 integer(kind=4)::di doubleprecision,allocatable::sumffi(:) doubleprecision,allocatable::f(:,:,:,:) ! the dimensionless field ! potential energy; first something I did in an earlier paper nt = 10 ns = 2 allocate( f(nt,ns,ns,ns), back(ns,0:10) ) allocate( sumffi(0:nt/2)) go to 123 do di = 0, ns/2 sumffi(di) = sumffi(di) + f(i,j,k,l)*f(back(i,di),j,k,l) end do 123 contains function T(i,j,k,l,iu,ju,ku,lu,id,jd,kd,ld) ! only what depends on ijkl doubleprecision::T integer(kind=4)::i,j,k,l,iu,id,ju,jd,ku,kd,lu,ld T = f(i,j,k,l)*( f(i,j,k,l) - f(iu,j,k,l) - f(id,j,k,l) ) end function T end program energy The backtrace is * frame #0: 0x7fff91e76866 libsystem_kernel.dylib`__pthread_kill + 10 frame #1: 0x7fff989c935c libsystem_pthread.dylib`pthread_kill + 92 frame #2: 0x7fff98740b1a libsystem_c.dylib`abort + 125 frame #3: 0x000100bd7978 f951`linemap_lookup(set=0x000141d49000, line=unavailable) + 456 at line-map.c:709 frame #4: 0x000100bd79dc f951`linemap_macro_loc_to_exp_point(set=0x000141d49000, location=33570, original_map=0x7fff5fbfedf8) + 76 at line-map.c:1181 frame #5: 0x000100bbf59e f951`expand_location_1(loc=33570, expansion_point_p=unavailable) + 126 at input.c:164 frame #6: 0x000100bc039e f951`expand_location(loc=unavailable) + 14 at input.c:724 frame #7: 0x00010002e188 f951`show_locus(c1=-1350314028, c2=-1, loc=unavailable) + 88 at error.c:355 frame #8: 0x00010002ed3e f951`error_print(type=0x000100cd1751, format0=0x000100ce34a8, argp=unavailable) + 2286 at error.c:476 frame #9: 0x00010002f90e f951`gfc_error(gmsgid=unavailable) + 446 at error.c:1003 frame #10: 0x00010008e4c9 f951`resolve_code(code=0x000141f08e40, ns=0x000143023c00) + 9241 at resolve.c:9828 frame #11: 0x00010008f8a4 f951`resolve_codes(ns=unavailable) + 308 at resolve.c:14610 frame #12: 0x00010008f99d f951`gfc_resolve(ns=0x000143023c00) + 61 at resolve.c:14638 frame #13: 0x000100079fab f951`gfc_parse_file() [inlined] resolve_all_program_units(gfc_global_ns_list=0x000143023c00) + 71 at parse.c:4468 frame #14: 0x000100079f64 f951`gfc_parse_file() + 1364 frame #15: 0x0001000bc276 f951`gfc_be_parse_file + 38 at f95-lang.c:188 frame #16: 0x00010086a287 f951`compile_file + 39 at toplev.c:548 frame #17: 0x00010086c7a4 f951`toplev_main(argc=2, argv=0x7fff5fbff4a0) + 3284 at toplev.c:1914
[Bug fortran/60781] cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60781 --- Comment #11 from Laura C lauraelcomeau at yahoo dot co.uk --- Thank you very much for your help - I will fix the curly quotes and hopefully run the executable successfully when I get home from work later. Apologies that it was my mistake. Your help is much appreciated! Laura
[Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Mike, what do you think is the best solution here? We could use Dominique's patch with a comment to the effect that New-ABI symbols are always emitted on Linux, but only with -fabi-version=4 or later on Darwin. We could revert my change and hardcode -fabi-version=2 for all targets. Or we could take the suggestion from your original review email and duplicate the test into new-ABI and old-ABI versions, and do both of those. I am in favor of the duplicated test. (If we duplicate the test, is altivec-7a.C a reasonable name for the duplicate-with-different-ABI, or does it need to be altivec-18.C or whatever the next available number is?) I prefer altivec-7a.C. It would be nice to have this done for 4.9.0.
[Bug c/60791] New: missing warning about uninitialized local variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60791
Bug ID: 60791
Summary: missing warning about uninitialized local variable
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dominik.muth at gmx dot de
// When compiling this file with
//
// -O3 -Wall -c
//
// There is no warning about the uninitialized use of r.
int f(int i) {
int r;
while (r != 0) {
r = 0;
i++;
}
return i;
}
// This is true for 4.6.3 and 4.8.2. However 2.95.2 does issue the warning.
//
// Leaving out optimization none of the above mentioned versions produces the
// warning (similar to 54554).
[Bug ada/60411] Ada bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 --- Comment #15 from John Marino gnugcc at marino dot st --- Hi Eric, The compiler builds happily now. It started right into ACATS testing and has passed the first 3 chapters flawlessly (with the current setup ACATS takes hours because each test is SCP'd/SSH'd to the device, but I'm going to improve the remote testing soon). Thanks, John
[Bug target/60459] Crash seen in _Unwind_VRS_Pop() for ARM platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60459 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #6 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- This particular __longjump.S is not available in toolchain 4.2.1. I searched for relevant code and couldnt find it. That appears to be in the glibc sources not in the GCC sources assuming that is the problem. It does look suspicious but doesn't guarantee that to be the issue unless you know longjmp is being called in the testcase you have. Work out if the test case shown in the link fails identically to yours and work out if it fails in the same manner with the same root cause. If so, that's your issue and it is nothing to do with the compiler or libgcc's unwind routines. Use git blame or any other revision control tools on the glibc sources that you have to work out where that comes from and port the solution there not in the gcc sources. Despite repeated requests to produce a testcase that shows this on currently maintained compilers that shows this to be a GCC problem, there have been none. Given this situation, I'm going to reject this issue as INVALID - if you have an issue, either reopen the issue or create a new one with the exact information we require. regards Ramana
[Bug c++/60792] New: bogus buffer overflow warning and abort on static flexible array member in a child object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60792
Bug ID: 60792
Summary: bogus buffer overflow warning and abort on static
flexible array member in a child object
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: abalint21 at gmail dot com
g++ emits a bogus warning on the program below which then aborts at runtime.
The strange thing is that if I get the reference of the child object and then
get the address of the str field then everything is OK. It seems that g++
cannot handle the inner child object's str if it is accessed via
parent-child.str but it is ok when a reference is taken from the child and
then accessed via child.str.
$ cat main.cpp g++ -D_FORTIFY_SOURCE=2 -O2 main.cpp ./a.out
#include cstdlib
#include cstring
#include iostream
struct Parent
{
struct Child
{
int a;
char b;
char str[0]; /// ASCIIZ
} child;
};
//#define DONT_CRASH
int main(int argc, char** argv)
{
char* buffer = new char[32768];
Parent* parent = (Parent*) buffer;
parent-child.a = 1;
parent-child.b = 'a';
#ifdef DONT_CRASH
Parent::Child child = parent-child;
char* childStr = child.str;
#else
char* childStr = parent-child.str;
#endif
std::cout __USE_FORTIFY_LEVEL std::endl;
std::cout __bos(childStr) std::endl;
size_t strLen = 4;
std::strncpy(childStr, test, strLen);
if (childStr[strLen] not_eq '\0')
{
childStr[strLen] = '\0';
}
return 0;
}
In file included from /usr/include/string.h:640:0,
from /usr/include/c++/4.8.2/cstring:42,
from main.cpp:2:
In function ‘char* strncpy(char*, const char*, size_t)’,
inlined from ‘int main(int, char**)’ at main.cpp:38:43:
/usr/include/bits/string3.h:120:71: warning: call to char*
__builtin___strncpy_chk(char*, const char*, long unsigned int, long unsigned
int) will always overflow destination buffer [enabled by default]
return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
^
2
0
*** buffer overflow detected ***: ./a.out terminated
...
Aborted
[Bug ada/60730] 'Round of a fixed point type incorrectly truncates its operand instead of rounding it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60730 John Marino gnugcc at marino dot st changed: What|Removed |Added CC||gnugcc at marino dot st --- Comment #2 from John Marino gnugcc at marino dot st --- what platform is this program being run on? what is output of uname -a ?
[Bug c/60791] missing warning about uninitialized local variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60791 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- I think dupe then. *** This bug has been marked as a duplicate of bug 54554 ***
[Bug c/54554] Undetected use of uninitialized variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54554 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||dominik.muth at gmx dot de --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- *** Bug 60791 has been marked as a duplicate of this bug. ***
[Bug c/54554] Undetected use of uninitialized variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54554 --- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Dimitris Papavasiliou from comment #6) I don't mean to dictate the coding-style others should use of course but still it seems to me like a small price to pay for avoiding obscure stochastic bugs that can take hours of debugging to locate (especially given the fact that there's good reason to disable optimizations when debugging code). It should be possible to run the pass that triggers -Wmaybe-uninitialized warning without optimization, but it will be very noisy. You could explore the option of keeping it disabled at -O0 unless the user requests it by an explicit -Wmaybe-uninitialized. But you should run some tests to see how noisy/useful that would be. My guess is that a lot more noisy than useful.
[Bug ada/60411] Ada bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 --- Comment #16 from Eric Botcazou ebotcazou at gcc dot gnu.org --- The compiler builds happily now. Great, thanks for the quick feedback. It started right into ACATS testing and has passed the first 3 chapters flawlessly (with the current setup ACATS takes hours because each test is SCP'd/SSH'd to the device, but I'm going to improve the remote testing soon). Please post the definitive results here when you have them, TIA.
[Bug c++/60792] bogus buffer overflow warning and abort on flexible array member in a child object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60792 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Zero length array inside of another string is not a flexible array member, nor anything close to that, and with -D_FORTIFY_SOURCE=2 is not even supposed to be handled like flexible array member alternative. Thus, I don't see why you think this is a bug. Simply don't do it, use -D_FORTIFY_SOURCE=1 instead, or use e.g. memcpy instead of strncpy which is allowed even in -D_FORTIFY_SOURCE=2 mode (which is stricter than what C/C++ allows) to cross field boundaries.
[Bug testsuite/60773] [4.9 Regression] FAIL: gcc.dg/vect/pr60656.c -flto -ffat-lto-objects scan-tree-dump-times vect vectorized 1 loops 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60773 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Apr 9 11:37:14 2014 New Revision: 209241 URL: http://gcc.gnu.org/viewcvs?rev=209241root=gccview=rev Log: 2014-04-09 Cong Hou co...@google.com PR testsuite/60773 * doc/sourcebuild.texi (vect_widen_mult_si_to_di_pattern): Add documentation. * lib/target-supports.exp: (check_effective_target_vect_widen_si_to_di_pattern): New. * gcc.dg/vect/pr60656.c: Require vect_long effective target. Use scan-tree-dump-times for vect_widen_mult_si_to_di_pattern targets only. (foo): Fix up formatting. (main): Call check_vect. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/sourcebuild.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr60656.c trunk/gcc/testsuite/lib/target-supports.exp
[Bug testsuite/60773] [4.9 Regression] FAIL: gcc.dg/vect/pr60656.c -flto -ffat-lto-objects scan-tree-dump-times vect vectorized 1 loops 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60773 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- I went ahead and committed the fix.
[Bug target/60459] Crash seen in _Unwind_VRS_Pop() for ARM platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60459 --- Comment #7 from Murali murali.marimekala at gmail dot com --- Hi Ramana, Thanks for your response and inputs. We will try working out a testcase to reproduce this issue. Murali
[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Attachment #32564|0 |1 is obsolete|| --- Comment #14 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Created attachment 32571 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32571action=edit Reworked patch Reworked patch currently testing.
[Bug tree-optimization/60656] [4.8/4.9 regression] x86 vectorization produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60656 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/60656] [4.8 regression] x86 vectorization produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60656 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- Summary|[4.8/4.9 regression] x86|[4.8 regression] x86 |vectorization produces |vectorization produces |wrong code |wrong code --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Actually, still not fixed on the 4.8 branch, only on the trunk.
[Bug target/60609] [4.8 Regression] Error: value of 256 too large for field of 1 bytes at 68242
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60609 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Known to work||4.9.0 Summary|[4.8/4.9 Regression] Error: |[4.8 Regression] Error: |value of 256 too large for |value of 256 too large for |field of 1 bytes at 68242 |field of 1 bytes at 68242 Known to fail|4.9.0 | --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed on the trunk, but not on the 4.8 branch yet.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #209 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #208) Both issues from Comment 201 were fixed by: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00338.html No, only the first issue is fixed. The second one (LTO/PGO build) still happens unfortunately.
[Bug tree-optimization/60505] [4.8 Regression] Warning caused by GCC vectorizer.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60505 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Summary|[4.8/4.9 Regression]|[4.8 Regression] Warning |Warning caused by GCC |caused by GCC vectorizer. |vectorizer. | Known to fail||4.8.2 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed on the trunk.
[Bug ada/60411] Ada bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 --- Comment #17 from John Marino gnugcc at marino dot st --- Hi Eric, In the end, there were 6 failures. It appears that the ARM unwinder isn't quite right yet. After 2314 passes, the six ACATS failures were: C52103x C52104x C52104y c74004a (hung) cb1010c cb1010d John
[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655 --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org --- Looks good to me, thanks.
[Bug ada/60411] Ada bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 --- Comment #18 from Eric Botcazou ebotcazou at gcc dot gnu.org --- In the end, there were 6 failures. It appears that the ARM unwinder isn't quite right yet. After 2314 passes, the six ACATS failures were: C52103x C52104x C52104y c74004a (hung) cb1010c cb1010d It's not the ARM unwinder, it's the stack checking, see: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01421.html
[Bug testsuite/60793] New: Add target *-*-dragonfly* to dg-options on 172 libstdc++ tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60793 Bug ID: 60793 Summary: Add target *-*-dragonfly* to dg-options on 172 libstdc++ tests Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: gnugcc at marino dot st Created attachment 32572 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32572action=edit List of 172 libstdc++ tests that should target *-*-dragonfly* The attached file is a list of 172 libstdc++ tests that have dg-options target of *-*-freebsd*. They should also list *-*-dragonfly* It should be a simply matter of substituting enmass *-*-freebsd* with *-*-freebsd* *-*-dragonfly* using perl -pi -e or similar technique. A giant patchset could be provided upon request if perl -pie isn't good enough.
[Bug testsuite/60794] New: 25 libstdc++ tests are missing '{ dg-require-debug-mode }'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60794
Bug ID: 60794
Summary: 25 libstdc++ tests are missing '{
dg-require-debug-mode }'
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: gnugcc at marino dot st
Created attachment 32573
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32573action=edit
Patch to add debug-mode requirement to 25 libstdc++ tests
Twenty-five (25) libstdc++ tests require the debug-mode option but this is not
specified. I've carried the attached patch for years, time to try to get it
properly into the gcc testsuite base.
The tests are:
23_containers/deque/debug/assign4_neg.cc
23_containers/deque/debug/construct4_neg.cc
23_containers/deque/debug/insert4_neg.cc
23_containers/list/debug/assign4_neg.cc
23_containers/list/debug/construct4_neg.cc
23_containers/list/debug/insert4_neg.cc
23_containers/map/debug/construct4_neg.cc
23_containers/map/debug/insert4_neg.cc
23_containers/multimap/debug/construct4_neg.cc
23_containers/multimap/debug/insert4_neg.cc
23_containers/multiset/debug/construct4_neg.cc
23_containers/multiset/debug/insert4_neg.cc
23_containers/set/debug/construct4_neg.cc
23_containers/set/debug/insert4_neg.cc
23_containers/unordered_map/debug/construct4_neg.cc
23_containers/unordered_map/debug/insert4_neg.cc
23_containers/unordered_multimap/debug/construct4_neg.cc
23_containers/unordered_multimap/debug/insert4_neg.cc
23_containers/unordered_multiset/debug/construct4_neg.cc
23_containers/unordered_multiset/debug/insert4_neg.cc
23_containers/unordered_set/debug/construct4_neg.cc
23_containers/unordered_set/debug/insert4_neg.cc
23_containers/vector/debug/assign4_neg.cc
23_containers/vector/debug/construct4_neg.cc
23_containers/vector/debug/insert4_neg.cc
[Bug ada/60411] Ada bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 --- Comment #19 from John Marino gnugcc at marino dot st --- ah sorry, I always seem to conclude wrongly that stack checking requires unwind support. I'm not sure why I always conflate those two things. So this patch was proposed 9 months ago but never got committed? Or was it only partially committed? Will stack-check support get added soon? Thanks, John
[Bug libgcc/60790] libatomic convenience library selects IFUNC implementation before obtaining cpu info.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60790 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2014-04-09 CC||ian at airs dot com Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #3 from Ian Lance Taylor ian at airs dot com --- Andrew, you are closing this way too fast. This same problem is going to arise whenever libatomic is statically linked. The library assumes that global constructors are run before IFUNC selectors, but that is not the case in a static link. IFUNC selectors are run first.
[Bug libgcc/60790] libatomic convenience library selects IFUNC implementation before obtaining cpu info.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60790 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- That is not guaranteed for shared libs either actually in some more complex cases of shared library dependencies.
[Bug ada/60411] Ada bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 --- Comment #20 from Eric Botcazou ebotcazou at gcc dot gnu.org --- ah sorry, I always seem to conclude wrongly that stack checking requires unwind support. I'm not sure why I always conflate those two things. Yes, it does, but it first needs to be fully functional. So this patch was proposed 9 months ago but never got committed? Or was it only partially committed? Never reviewed and therefore not installed, I'll resubmit it at some point.
[Bug c++/60792] bogus buffer overflow warning and abort on flexible array member in a child object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60792 Attila Balint abalint21 at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Attila Balint abalint21 at gmail dot com --- (In reply to Jakub Jelinek from comment #1) Zero length array inside of another string is not a flexible array member, nor anything close to that, and with -D_FORTIFY_SOURCE=2 is not even supposed to be handled like flexible array member alternative. Thus, I don't see why you think this is a bug. Simply don't do it, use -D_FORTIFY_SOURCE=1 instead, or use e.g. memcpy instead of strncpy which is allowed even in -D_FORTIFY_SOURCE=2 mode (which is stricter than what C/C++ allows) to cross field boundaries. Clear. Thank you for the clarification. It is not a bug
[Bug ada/54040] [x32] Incorrect timeval and timespec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54040 --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Wed Apr 9 14:54:29 2014 New Revision: 209244 URL: http://gcc.gnu.org/viewcvs?rev=209244root=gccview=rev Log: PR ada/54040 PR ada/59346 * s-osinte-x32.adb: New file. * s-linux.ads (Time): New section. * s-linux-alpha.ads (Time): Likewise. * s-linux-android.ads (Time: Likewise. * s-linux-hppa.ads (Time): Likewise. * s-linux-mipsel.ads (Time): Likewise. * s-linux-sparc.ads (Time): Likewise. * s-linux-x32.ads (Time): Likewise. * s-osprim-x32.ads (timespec): Adjust. * s-osinte-linux.ads (Time): Define local subtypes for those defined in System.Linux. * s-taprop-linux.adb (Monotonic_Clock): Do not define timeval. * s-osinte-hpux.ads (timespec): Revert POSIX breakage. * s-osinte-kfreebsd-gnu.ads (timespec): Likewise. * s-osinte-solaris-posix.ads (timespec): Likewise. * s-osinte-posix.adb (To_Timespec): Likewise. * gcc-interface/Makefile.in (x32/Linux): Use s-osinte-x32.adb. Added: trunk/gcc/ada/s-osinte-x32.adb Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Makefile.in trunk/gcc/ada/s-linux-alpha.ads trunk/gcc/ada/s-linux-android.ads trunk/gcc/ada/s-linux-hppa.ads trunk/gcc/ada/s-linux-mipsel.ads trunk/gcc/ada/s-linux-sparc.ads trunk/gcc/ada/s-linux-x32.ads trunk/gcc/ada/s-linux.ads trunk/gcc/ada/s-osinte-hpux.ads trunk/gcc/ada/s-osinte-kfreebsd-gnu.ads trunk/gcc/ada/s-osinte-linux.ads trunk/gcc/ada/s-osinte-posix.adb trunk/gcc/ada/s-osinte-solaris-posix.ads trunk/gcc/ada/s-osprim-x32.adb trunk/gcc/ada/s-taprop-linux.adb
[Bug ada/59346] [4.9 Regression] s-osinte.adb:107:35: expected type Interfaces.C.long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59346 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Wed Apr 9 14:54:29 2014 New Revision: 209244 URL: http://gcc.gnu.org/viewcvs?rev=209244root=gccview=rev Log: PR ada/54040 PR ada/59346 * s-osinte-x32.adb: New file. * s-linux.ads (Time): New section. * s-linux-alpha.ads (Time): Likewise. * s-linux-android.ads (Time: Likewise. * s-linux-hppa.ads (Time): Likewise. * s-linux-mipsel.ads (Time): Likewise. * s-linux-sparc.ads (Time): Likewise. * s-linux-x32.ads (Time): Likewise. * s-osprim-x32.ads (timespec): Adjust. * s-osinte-linux.ads (Time): Define local subtypes for those defined in System.Linux. * s-taprop-linux.adb (Monotonic_Clock): Do not define timeval. * s-osinte-hpux.ads (timespec): Revert POSIX breakage. * s-osinte-kfreebsd-gnu.ads (timespec): Likewise. * s-osinte-solaris-posix.ads (timespec): Likewise. * s-osinte-posix.adb (To_Timespec): Likewise. * gcc-interface/Makefile.in (x32/Linux): Use s-osinte-x32.adb. Added: trunk/gcc/ada/s-osinte-x32.adb Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Makefile.in trunk/gcc/ada/s-linux-alpha.ads trunk/gcc/ada/s-linux-android.ads trunk/gcc/ada/s-linux-hppa.ads trunk/gcc/ada/s-linux-mipsel.ads trunk/gcc/ada/s-linux-sparc.ads trunk/gcc/ada/s-linux-x32.ads trunk/gcc/ada/s-linux.ads trunk/gcc/ada/s-osinte-hpux.ads trunk/gcc/ada/s-osinte-kfreebsd-gnu.ads trunk/gcc/ada/s-osinte-linux.ads trunk/gcc/ada/s-osinte-posix.adb trunk/gcc/ada/s-osinte-solaris-posix.ads trunk/gcc/ada/s-osprim-x32.adb trunk/gcc/ada/s-taprop-linux.adb
[Bug fortran/60795] New: Wrong length when allocating character array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60795 Bug ID: 60795 Summary: Wrong length when allocating character array Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kergonath at me dot com In the following program: program stringtest character(:), dimension(:), allocatable :: s allocate(character(1) :: s(10)) write(*,*) size(s) write(*,*) len(s) end program the elements of the array s end up with the wrong length, the output is: 10 0 Tested with latest version available with macports: Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin13/4.9.0/lto-wrapper Target: x86_64-apple-darwin13 Configured with: /opt/local/var/macports/build/_opt_mports_dports_lang_gcc49/gcc49/work/gcc-4.9-20140406/configure --prefix=/opt/local --build=x86_64-apple-darwin13 --enable-languages=c,c++,objc,obj-c++,fortran,java --libdir=/opt/local/lib/gcc49 --includedir=/opt/local/include/gcc49 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.9 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.9 --with-gxx-include-dir=/opt/local/include/gcc49/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-cloog=/opt/local --enable-cloog-backend=isl --disable-cloog-version-check --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts gcc49 4.9-20140406_0' Thread model: posix gcc version 4.9.0 20140406 (experimental) (MacPorts gcc49 4.9-20140406_0)
[Bug testsuite/60794] 25 libstdc++ tests are missing '{ dg-require-debug-mode }'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60794 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Why do you think they require debug mode? Those tests are supposed to run in normal mode, that's why they explicitly use debug/vector and __gnu_debug::vector (which is how to use the debug containers in normal mode)
[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- --- gcc/symtab.c.jj2014-03-21 22:23:43.0 +0100 +++ gcc/symtab.c2014-04-09 17:37:40.709523997 +0200 @@ -1312,9 +1312,13 @@ symtab_get_symbol_partitioning_class (sy /* Linker discardable symbols are duplicated to every use unless they are keyed. Keyed symbols or those. */ - if (DECL_ONE_ONLY (node-decl) + if ((HAVE_LTO_PLUGIN +(flag_use_linker_plugin + || (HAVE_LTO_PLUGIN == 2 +!global_options_set.x_flag_use_linker_plugin)) + ? (DECL_ONE_ONLY (node-decl) !node-forced_by_abi) + : DECL_COMDAT (node-decl)) !node-force_output - !node-forced_by_abi !symtab_used_from_object_file_p (node)) return SYMBOL_DUPLICATE; seems to make the ICE go away with -fno-use-linker-plugin or when the linker doesn't support the plugin at all, didn't have to change ipa.c similarly. But why is this happening and why this helps needs analyzing.
[Bug libstdc++/60793] Add target *-*-dragonfly* to dg-options on 172 libstdc++ tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60793 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Component|testsuite |libstdc++ --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- (Changing component to libstdc++ so it's on my radar) Could we get some testresults posted to the gcc-testresults list? Preferably both with and without this change. I'd prefer not to add it to the target selector if we aren't getting fairly regular test results, so we can see if the tests are actually passing.
[Bug libstdc++/60793] Add target *-*-dragonfly* to dg-options on 172 libstdc++ tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60793 --- Comment #2 from John Marino gnugcc at marino dot st --- hmmm, that would imply that all the dragonfly patches that we've been carrying for years (including ada patches) would need to go in first. DragonFly does not, and has never, built out of the box. It's not possible to have an automated test robot until support is added. I could have a before -and- after run, but that's a one off comparison. I've been carrying these patches since 4.6 (actually a lot more, this is only a small subset).
[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567 --- Comment #14 from Jan Hubicka hubicka at gcc dot gnu.org --- OK, the problem is that one comdat group has two functions: _ZNK19MutableIntegerValue18isValidNativeValueEi/0 (isValidNativeValue) @0x76adfe18 Type: function definition analyzed Visibility: forced_by_abi externally_visible public weak comdat_group:_ZNK19MutableIntegerValue18isValidNativeValueEi one_only section_name:.text._ZNK19MutableIntegerValue18isValidNativeValueEi virtual Same comdat group as: _ZThn8_NK19MutableIntegerValue18isValidNativeValueEi/2 Address is taken. Aux: @0x1 References: Referring: *.LTHUNK0/1 (alias)_ZTV19MutableIntegerValue/3 (addr) Read from file: t.o Availability: available First run: 0 Function flags: Called by: Calls: and _ZThn8_NK19MutableIntegerValue18isValidNativeValueEi/2 (_ZThn8_NK19MutableIntegerValue18isValidNativeValueEi) @0x76c64148 Type: function definition analyzed Visibility: externally_visible public weak comdat_group:_ZNK19MutableIntegerValue18isValidNativeValueEi one_only section_name:.text._ZNK19MutableIntegerValue18isValidNativeValueEi virtual artificial Same comdat group as: _ZNK19MutableIntegerValue18isValidNativeValueEi/0 Address is taken. Aux: @0x1 References: Referring: _ZTV19MutableIntegerValue/3 (addr) Read from file: t.o Availability: overwritable First run: 0 Function flags: Thunk fixed offset -8 virtual value 0 has virtual offset 0) Called by: Calls: *.LTHUNK0/1 (1.00 per call) Thunk doesn't have forced_by_abi. This makes the partitinoning code to deal with the comdat in two ways - duplicating into every partion that use it as well as keying it to one partition. This looks to me as C++ FE bug: When function is forced (keyed), its thunk should also be forced IMO. It doesn't seem to make sense to keep function but optimize out the thunk as we would do now (even w/o LTO)
[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are built-in, in both warnings and dumps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761
--- Comment #10 from Martin Jambor jamborm at gcc dot gnu.org ---
Created attachment 32574
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32574action=edit
WIP patch displaying IPA-CP information aout clones
This is an untested and very much WIP patch that shows how we can
print additional information about clones, at least about those
created by IPA-CP. Of course eventually it should not be in the
front-end. It also retains more information in memory, although not
that much.
For the source below, it produces the following output:
mjambor@virgil:~/gcc/mine/tests/pr60761-clonenames$ ~/gcc/mine/inst/bin/g++ -O3
-S -Wall aa.C -fno-inline
aa.C: In function ‘void foo(int, A*) clone with 4 for s, 10 for data pointed
to by a at offset 32’:
aa.C:19:20: warning: iteration 3u invokes undefined behavior
[-Waggressive-loop-optimizations]
z[i] = i + a-j;
^
aa.C:18:3: note: containing loop
for (int i = 0; i s; i++)
^
aa.C:19:8: warning: array subscript is above array bounds [-Warray-bounds]
z[i] = i + a-j;
the source code is:
extern int sum;
void do_sum (char *p)
{
for (int i = 0; i 2; i++)
sum += p[i];
}
struct A
{
int i, j, k;
};
void
foo (int s, struct A *a)
{
char z[3];
for (int i = 0; i s; i++)
z[i] = i + a-j;
do_sum (z);
}
int
bar (int i)
{
struct A a;
a.j = 10;
foo (4, a);
return 0;
}
[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||jason at redhat dot com --- Comment #15 from Jan Hubicka hubicka at gcc dot gnu.org --- This patch fixes the ICE by copying forced_by_abi as part of cgraph fixup in ipa visibility. I would like Jason to comment on this. I think fix at C++ FE side would be more appropriate if the thunk is indeed keyed. If not, I will update partitinoning predicate to always iterate the whole group and see if any of symbols is keyed. Index: ipa.c === --- ipa.c (revision 209170) +++ ipa.c (working copy) @@ -1032,6 +1032,7 @@ function_and_variable_visibility (bool w == DECL_COMDAT_GROUP (decl_node-decl)); gcc_checking_assert (node-same_comdat_group); } + decl_node-forced_by_abi = node-forced_by_abi; if (DECL_EXTERNAL (decl_node-decl)) DECL_EXTERNAL (node-decl) = 1; }
[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are built-in, in both warnings and dumps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org ---
Won't that break say -g -O2 -Wall reporting with say:
static inline void
foo (char *p)
{
__builtin___memcpy_chk (p, abc, 3, __builtin_object_size (p, 0));
}
static inline void
bar (char *p)
{
foo (p);
}
void
baz (void)
{
char buf[2];
bar (buf);
}
I mean, DECL_ABSTRACT_ORIGIN is set also for inlines, fnsplit created functions
and many other cases, printing clone after the function name in all those
cases might not be appropriate.
[Bug testsuite/60794] 25 libstdc++ tests are missing '{ dg-require-debug-mode }'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60794 --- Comment #2 from John Marino gnugcc at marino dot st --- Hmmm, only 3 of the 25 files use debug/vector and __gnu_debug::vector 23_containers/vector/debug/assign4_neg.cc 23_containers/vector/debug/construct4_neg.cc 23_containers/vector/debug/insert4_neg.cc That said, all 25 have some form of #include debug/X and __gnu_debug::X so likely you were only applying an example for one subset. I honestly can't remember the exact failure that this solved at the time (gcc 4.6 timeframe). I want to say the first file I fixed back then was deque/debug/assign4_neg.cc It's possible that that I saw debug-mode used in the 1,2,3 versions and thought it was oversight with the 4 versions, but I would have only looked at it upon a failure. All that said, if all 25 look right to you then I'll humbly accept it and a closed/invalid bug status.
[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are built-in, in both warnings and dumps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- Also, perhaps to make the change conservative enough for 4.9, might be best to not append anything now, and only look at DECL_ABSTRACT_ORIGIN (recurse on it) if !DECL_LANG_SPECIFIC. More verbose printing can be perhaps deferred for stage1.
[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are built-in, in both warnings and dumps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761 --- Comment #13 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #11) I mean, DECL_ABSTRACT_ORIGIN is set also for inlines, fnsplit created functions and many other cases, printing clone after the function name in all those cases might not be appropriate. It is not clear to me why you want to print clone at all. It is an internal detail.
[Bug c++/60796] New: Default move constructor not generated by explicit template instantiaion (C++11)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60796
Bug ID: 60796
Summary: Default move constructor not generated by explicit
template instantiaion (C++11)
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: brian.freyburger at blandertechnologies dot com
When you use explicit template instantiation in separate compilation units, and
disable implicit instantiation, a move constructor and move assignment operator
defined as =default is not generated.
See example here:
A.H:
#include memory
template typename T
struct A
{
A (T*a) : a(a) {}
A(A) = default;
A operator =(const A) = default;
std::shared_ptrT a;
};
extern template class Aint;
A.C:
#include A.H
template class Aint;
main.C:
#include A.H
template class Aint;
int main()
{
Aint a = new int(19);
Aint b = std::move(a);
}
results:
g++ -std=c++11 A.C main.C
/tmp/ccvE1IqS.o: In function `main':
main.C:(.text+0xdc): undefined reference to `Aint::A(Aint)'
collect2: error: ld returned 1 exit status
[Bug middle-end/60469] simple cilk plus program ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60469 --- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org --- I've tried a couple of things to fix this: - Fill in DECL_CONTEXT to current_fn_decl in cilk - Fill in DECL_CONTEXT for VAR_DECLs when creating the nested wrapper No banana so far. The first causes other errors and the second still has the same segfault
[Bug fortran/60795] [4.7/4.8/4.9 Regression] Wrong length when allocating character array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60795 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.6.0 Keywords||wrong-code Last reconfirmed||2014-04-09 CC||jb at gcc dot gnu.org Ever confirmed|0 |1 Summary|Wrong length when |[4.7/4.8/4.9 Regression] |allocating character array |Wrong length when ||allocating character array Known to fail||4.7.4, 4.8.3, 4.9.0 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed, up to revision r173749 I get 10 1 from r173750 to r174379 I get 10 2 and from r174433 up to r209236 I get 10 0 What is surprising is that r173750, r174030, and r174415 are related to backtrace handling, so they probably only expose a latent problem(?).
[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567 --- Comment #16 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #14) It doesn't seem to make sense to keep function but optimize out the thunk as we would do now (even w/o LTO) Right. When we emit a function, we need to also emit any associated thunks.
[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are built-in, in both warnings and dumps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761 --- Comment #14 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #13) It is not clear to me why you want to print clone at all. It is an internal detail. Imagine a function void f(unsigned a, unsigned b) where gcc makes a clone specializing a=0. If the function contains a comparison a=b, you might get a warning because the comparison is always true. As a user, I would be quite confused... Ok, this particular example won't happen, but I think it is still a reason why writing clone and maybe some more details can be useful.
[Bug middle-end/60469] simple cilk plus program ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60469
--- Comment #4 from Igor Zamyatin izamyatin at gmail dot com ---
Following works for me and shows no new errors in regtesting. Not sure it is a
good idea though...
diff --git a/gcc/c/c-array-notation.c b/gcc/c/c-array-notation.c
index 6a5631c..d7c6772 100644
--- a/gcc/c/c-array-notation.c
+++ b/gcc/c/c-array-notation.c
@@ -284,6 +284,7 @@ fix_builtin_array_notation_fn (tree an_builtin_fn, tree
*new_var)
{
an_loop_info[ii].var = build_decl (location, VAR_DECL, NULL_TREE,
integer_type_node);
+ DECL_CONTEXT (an_loop_info[ii].var) = current_function_decl;
an_loop_info[ii].ind_init =
build_modify_expr (location, an_loop_info[ii].var,
TREE_TYPE (an_loop_info[ii].var), NOP_EXPR,
@@ -783,6 +784,7 @@ build_array_notation_expr (location_t location, tree lhs,
tree lhs_origtype,
{
lhs_an_loop_info[ii].var = build_decl (location, VAR_DECL, NULL_TREE,
integer_type_node);
+DECL_CONTEXT (lhs_an_loop_info[ii].var) = current_function_decl;
lhs_an_loop_info[ii].ind_init = build_modify_expr
(location, lhs_an_loop_info[ii].var,
TREE_TYPE (lhs_an_loop_info[ii].var), NOP_EXPR,
@@ -795,6 +797,7 @@ build_array_notation_expr (location_t location, tree lhs,
tree lhs_origtype,
integer. */
rhs_an_loop_info[ii].var = build_decl (location, VAR_DECL, NULL_TREE,
integer_type_node);
+ DECL_CONTEXT (rhs_an_loop_info[ii].var) = current_function_decl;
rhs_an_loop_info[ii].ind_init = build_modify_expr
(location, rhs_an_loop_info[ii].var,
TREE_TYPE (rhs_an_loop_info[ii].var), NOP_EXPR,
@@ -972,6 +975,7 @@ fix_conditional_array_notations_1 (tree stmt)
{
an_loop_info[ii].var = build_decl (location, VAR_DECL, NULL_TREE,
integer_type_node);
+ DECL_CONTEXT (an_loop_info[ii].var) = current_function_decl;
an_loop_info[ii].ind_init =
build_modify_expr (location, an_loop_info[ii].var,
TREE_TYPE (an_loop_info[ii].var), NOP_EXPR,
@@ -1069,6 +1073,7 @@ fix_array_notation_expr (location_t location, enum
tree_code code,
{
an_loop_info[ii].var = build_decl (location, VAR_DECL, NULL_TREE,
integer_type_node);
+ DECL_CONTEXT (an_loop_info[ii].var) = current_function_decl;
an_loop_info[ii].ind_init =
build_modify_expr (location, an_loop_info[ii].var,
TREE_TYPE (an_loop_info[ii].var), NOP_EXPR,
@@ -1165,6 +1170,7 @@ fix_array_notation_call_expr (tree arg)
{
an_loop_info[ii].var = build_decl (location, VAR_DECL, NULL_TREE,
integer_type_node);
+ DECL_CONTEXT (an_loop_info[ii].var) = current_function_decl;
an_loop_info[ii].ind_init =
build_modify_expr (location, an_loop_info[ii].var,
TREE_TYPE (an_loop_info[ii].var), NOP_EXPR, location,
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 7441784..b61a995 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -1732,6 +1732,7 @@ gimplify_var_or_parm_decl (tree *expr_p)
be really nice if the front end wouldn't leak these at all.
Currently the only known culprit is C++ destructors, as seen
in g++.old-deja/g++.jason/binding.C. */
+#if 0
if (TREE_CODE (decl) == VAR_DECL
!DECL_SEEN_IN_BIND_EXPR_P (decl)
!TREE_STATIC (decl) !DECL_EXTERNAL (decl)
@@ -1740,6 +1741,7 @@ gimplify_var_or_parm_decl (tree *expr_p)
gcc_assert (seen_error ());
return GS_ERROR;
}
+#endif
/* When within an OpenMP context, notice uses of variables. */
if (gimplify_omp_ctxp omp_notice_variable (gimplify_omp_ctxp, decl,
true))
[Bug middle-end/60469] simple cilk plus program ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60469 --- Comment #5 from Andi Kleen andi-gcc at firstfloor dot org --- You're right. It works in C++. That's similar to my earlier patch, but I didn't comment out the other check like you did. If commenting out the check work it would seem right to me. Can you post it as a RFC?
[Bug testsuite/60773] [4.9 Regression] FAIL: gcc.dg/vect/pr60656.c -flto -ffat-lto-objects scan-tree-dump-times vect vectorized 1 loops 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60773 --- Comment #5 from Cong Hou congh at google dot com --- Hi Jakub Thank you very much for the commit! thanks, Cong On Wed, Apr 9, 2014 at 4:39 AM, jakub at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60773 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- I went ahead and committed the fix. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug c++/57926] Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926 --- Comment #13 from Jason Merrill jason at gcc dot gnu.org --- Created attachment 32575 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32575action=edit patch This patch forces the decay for C++. We don't need to do anything for C, since arrays decay immediately when named in the C front end. I think I'm inclined to wait until after 4.9 to check this in.
[Bug middle-end/60469] simple cilk plus program ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60469 --- Comment #6 from Igor Zamyatin izamyatin at gmail dot com --- Yes, I was going to post it after complete testing
[Bug c++/60796] Default move constructor not generated by explicit template instantiaion (C++11)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60796
--- Comment #1 from Brian Freyburger brian.freyburger at blandertechnologies
dot com ---
Sorry, see code change below. (if you explicitly instantiate in the
compilation unit which uses the move construction, the compilation sucec
(In reply to Brian Freyburger from comment #0)
When you use explicit template instantiation in separate compilation units,
and disable implicit instantiation, a move constructor and move assignment
operator defined as =default is not generated.
See example here:
A.H:
#include memory
template typename T
struct A
{
A (T*a) : a(a) {}
A(A) = default;
A operator =(const A) = default;
std::shared_ptrT a;
};
extern template class Aint;
A.C:
#include A.H
template class Aint;
main.C:
#include A.H
// template class Aint; REMOVE THIS LINE
int main()
{
Aint a = new int(19);
Aint b = std::move(a);
}
results:
g++ -std=c++11 A.C main.C
/tmp/ccvE1IqS.o: In function `main':
main.C:(.text+0xdc): undefined reference to `Aint::A(Aint)'
collect2: error: ld returned 1 exit status
[Bug fortran/60795] [4.7/4.8/4.9 Regression] Wrong length when allocating character array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60795 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) What is surprising is that r173750, r174030, and r174415 are related to backtrace handling, so they probably only expose a latent problem(?). I think it is a lot worse than it appears. call s1 call s2 call s3 end subroutine s1 character(:), dimension(:), allocatable :: s allocate(character(10) :: s(2)) s(1) = 'r' s(2) = 's' print *, 's1: ', size(s), len(s) end subroutine s1 ! ! A variation on a theme? ! subroutine s2 ! This causes an ICE in gfortran ! character(:), dimension(:), allocatable :: s ! allocate(s(2), source='abc') ! s(1) = 'r' ! s(2) = 's' ! print *, 's2:', size(s), len(s) end subroutine s2 ! ! A variation on a theme? ! subroutine s3 ! This causes an ICE in gfortran ! character(:), dimension(:), allocatable :: s ! allocate(s(2), source=['abc','def']) ! allocate(s, source=['abc','def']) ! s(1) = 'r' ! s(2) = 's' ! print *, 's3:', size(s), len(s) end subroutine s3 subroutine y3 ! This causes gfortran to issue an error. Incorrect! ! character(:), dimension(:), allocatable :: s ! allocate(s, source=['abc','def']) ! s(1) = 'r' ! s(2) = 's' ! print *, 's3:', size(s), len(s) end subroutine y3 subroutine t3 ! This causes gfortran to issue an error. Incorrect! ! real, dimension(:), allocatable :: s ! allocate(s, source=[1., 2.]) end subroutine t3 subroutine s4 ! This causes an ICE in gfortran ! character(3), dimension(:), allocatable :: s ! allocate(s(2), source=['abc','def']) ! s(1) = 'r' ! s(2) = 's' ! print *, 's3:', size(s), len(s) end subroutine s4
[Bug libstdc++/60789] [4.9 Regression] Missing -lm while checking for math functions (e.g., atan2f)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60789 --- Comment #1 from David Abdurachmanov david.abdurachmanov at gmail dot com --- Found the culprit. I had CFLAGS/CXXFLAGS/LDFLAGS for gcc ./configure. Thus probably setting CFLAGS causes `-lm` to vanish in libstdc++v3 math conftests.
[Bug middle-end/60469] simple cilk plus program ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60469 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Igor Zamyatin from comment #6) Yes, I was going to post it after complete testing You should set DECL_SEEN_IN_BIND_EXPR_P when setting DECL_CONTEXT, similar to gimple_add_tmp_var.
[Bug middle-end/60469] simple cilk plus program ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60469 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com --- (In reply to H.J. Lu from comment #7) (In reply to Igor Zamyatin from comment #6) Yes, I was going to post it after complete testing You should set DECL_SEEN_IN_BIND_EXPR_P when setting DECL_CONTEXT, similar to gimple_add_tmp_var. Or we can use create_tmp_var.
[Bug c/60797] New: gcc hangs with error: only weak aliases are supported in this configuration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60797
Bug ID: 60797
Summary: gcc hangs with error: only weak aliases are supported
in this configuration
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: junchao.zhang at gmail dot com
On my Mac OS X 10.9.2, when I use gcc to compile this program, test.c,
#include stdio.h
extern int foo __attribute__((alias(bar)));
int main()
{
return 0;
}
gcc hangs with countless
test.c:3:12: error: only weak aliases are supported in this configuration
test.c:3:12: error: only weak aliases are supported in this configuration
test.c:3:12: error: only weak aliases are supported in this configuration
...
[Bug target/57589] Linux powerpc -mcpu=native returns pointer to variable on stack in driver-rs6000.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57589 --- Comment #6 from Bill Schmidt wschmidt at gcc dot gnu.org --- Author: wschmidt Date: Wed Apr 9 19:42:14 2014 New Revision: 209250 URL: http://gcc.gnu.org/viewcvs?rev=209250root=gccview=rev Log: 2014-04-09 Bill Schmidt wschm...@linux.vnet.ibm.com Backport from mainline r202642 2013-09-17 Alan Modra amo...@gmail.com PR target/57589 * config/rs6000/driver-rs6000.c (elf_platform): Revert 2013-06-11 patch (r199972). Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/rs6000/driver-rs6000.c
[Bug c/60797] gcc hangs with error: only weak aliases are supported in this configuration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60797 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-09 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- r206658 gives pr60797.c:3:12: error: only weak aliases are supported in this configuration extern int foo __attribute__((alias(bar))); ^ pr60797.c:3:12: error: only weak aliases are supported in this configuration while r206880 gives the infinite errors.
[Bug c++/60798] New: Access checking of template alias not done at the point of use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60798
Bug ID: 60798
Summary: Access checking of template alias not done at the
point of use
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
The following compiles with clang, but not with gcc-4.8.2
templatetypename Derived
using base_t = typename Derived::base_t;
templatetypename Derived
struct base
{
private:
friend Derived;
using base_t = base;
base() {}
};
templatetypename T
struct derived : basederivedT
{
using base_tderived::base_t;
};
int main()
{
derivedint d;
}
/
Result:
test.cpp: In substitution of ‘templateclass Derived using base_t = typename
Derived::base_t [with Derived = derivedint]’:
test.cpp:16:26: required from ‘struct derivedint’
test.cpp:21:16: required from here
test.cpp:9:22: error: ‘using base_t = struct basederivedint ’ is private
using base_t = base;
^
test.cpp:2:40: error: within this context
using base_t = typename Derived::base_t;
[Bug c/60784] Spurious -Wmissing-field-initializers warning for anonymous structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60784
--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
It looks like this isn't about whether the struct is anonymous, we warn even on
say:
struct A { int a, b; };
struct B { struct A a; } b = { .a.a = 1, .a.b = 1 };
c.c:2:19: warning: missing initializer for field ‘b’ of ‘struct A’
[-Wmissing-field-initializers]
struct B { struct A a; } b = { .a.a = 1, .a.b = 1 };
^
c.c:1:19: note: ‘b’ declared here
struct A { int a, b; };
^
[Bug middle-end/60467] ICE with -fcilkplus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60467 --- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org --- We could add this patch to avoid the original problem: diff --git a/gcc/c-family/cilk.c b/gcc/c-family/cilk.c index f2179dfc..a535948 100644 --- a/gcc/c-family/cilk.c +++ b/gcc/c-family/cilk.c @@ -712,8 +712,9 @@ create_cilk_wrapper (tree exp, tree *args_out) else extract_free_variables (exp, wd, ADD_READ); pointer_map_traverse (wd.decl_map, declare_one_free_variable, wd); - wd.block = TREE_BLOCK (exp); - if (!wd.block) + if (IS_EXPR_CODE_CLASS (TREE_CODE_CLASS (TREE_CODE (exp +wd.block = TREE_BLOCK (exp); + else wd.block = DECL_INITIAL (current_function_decl); However this just causes the next ICE later #1 0x008a8e20 in gimplify_expr (expr_p=0x76d58bf8, pre_p=0x7fffd5f8, post_p=0x7fffd130, gimple_test_f=0x8957a2 is_gimple_addressable(tree), fallback=3) at ../../gcc/gcc/gimplify.c:8359 8359 gcc_assert (fallback fb_mayfail); (gdb) p fallback $1 = 3 (gdb) p/d fb_mayfail $2 = 4
[Bug c++/60799] New: access checking within injected friend functions does not happen in the context of the enclosing class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60799
Bug ID: 60799
Summary: access checking within injected friend functions does
not happen in the context of the enclosing class
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
The following compiles with clang, but not with gcc-4.8.2
/
templatetypename T
struct foo;
templatetypename T
struct bar
{
private:
templatetypename U
friend struct foo;
int x_;
public:
bar() : x_(0) {}
};
templatetypename T
struct foo
{
private:
int x_;
public:
foo() : x_(0) {}
friend bool operator==(fooT f, barT b)
{
return f.x_ == b.x_;
}
};
int main()
{
fooint f;
barint b;
bool i = (f == b);
}
Result:
test.cpp: In instantiation of ‘bool operator==(fooint, barint)’:
test.cpp:32:18: required from here
test.cpp:10:7: error: ‘int barint::x_’ is private
int x_;
^
test.cpp:24:19: error: within this context
return f.x_ == b.x_;
^
[Bug middle-end/60467] ICE with -fcilkplus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60467 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #2 from Igor Zamyatin izamyatin at gmail dot com --- I've also looked at this. I think this one should go diff --git a/gcc/c-family/cilk.c b/gcc/c-family/cilk.c index 6a7bf4f..bf549ad 100644 --- a/gcc/c-family/cilk.c +++ b/gcc/c-family/cilk.c @@ -99,7 +99,6 @@ cilk_set_spawn_marker (location_t loc, tree fcall) it. */ return false; else if (TREE_CODE (fcall) != CALL_EXPR - TREE_CODE (fcall) != FUNCTION_DECL /* In C++, TARGET_EXPR is generated when we have an overloaded '=' operator. */ TREE_CODE (fcall) != TARGET_EXPR)
[Bug c++/60798] Access checking of template alias not done at the point of use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60798 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- Access checking within alias templates is handled by an existing core language issue. At the moment I have no online access to the active issue list, but I believe that was http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1554
[Bug target/60800] New: -Ofast -ffast-math -march=corei7 -mtune=generic miscompiles 178.galgel in SPEC CPU 2K
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60800 Bug ID: 60800 Summary: -Ofast -ffast-math -march=corei7 -mtune=generic miscompiles 178.galgel in SPEC CPU 2K Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: areg.melikadamyan at gmail dot com On Linux/x86-64, revision 209068 miscompiles 178.galgel in SPEC CPU 2K with -Ofast -ffast-math -march=corei7 -mtune=generic 9639 segmentation fault ./galgel_peak.tunegeneric ../../data/ref/input/galgel.in
[Bug target/60800] -Ofast -ffast-math miscompiles 178.galgel in SPEC CPU 2K
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60800 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Summary|-Ofast -ffast-math |-Ofast -ffast-math |-march=corei7 |miscompiles 178.galgel in |-mtune=generic miscompiles |SPEC CPU 2K |178.galgel in SPEC CPU 2K | --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- Just -Ofast -ffast-math will miscompile 178.galgel.
[Bug libstdc++/60789] [4.9 Regression] Missing -lm while checking for math functions (e.g., atan2f)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60789 David Abdurachmanov david.abdurachmanov at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from David Abdurachmanov david.abdurachmanov at gmail dot com --- I am marking it as RESOLVED INVALID. After looking more closely, I found a typo in CXXFLAGS. It caused the following test to fail in the first place: From libstdc++-v3/linkage.m4 in GLIBCXX_CHECK_MATH_SUPPORT: 361 dnl Check libm 362 AC_CHECK_LIB(m, sin, libm=-lm) 363 ac_save_LIBS=$LIBS 364 LIBS=$LIBS $libm Thus `-lm` was not added for the rest of the tests.
[Bug ada/59346] [4.9 Regression] s-osinte.adb:107:35: expected type Interfaces.C.long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59346 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Wed Apr 9 23:18:28 2014 New Revision: 209257 URL: http://gcc.gnu.org/viewcvs?rev=209257root=gccview=rev Log: PR ada/54040 PR ada/59346 * s-osinte-x32.adb (To_Timespec): Add use directive. * s-osprim-x32.ads (Clock): Adjust. (To_Timespec): Likewise. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/s-osinte-x32.adb trunk/gcc/ada/s-osprim-x32.adb
[Bug ada/54040] [x32] Incorrect timeval and timespec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54040 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Wed Apr 9 23:18:28 2014 New Revision: 209257 URL: http://gcc.gnu.org/viewcvs?rev=209257root=gccview=rev Log: PR ada/54040 PR ada/59346 * s-osinte-x32.adb (To_Timespec): Add use directive. * s-osprim-x32.ads (Clock): Adjust. (To_Timespec): Likewise. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/s-osinte-x32.adb trunk/gcc/ada/s-osprim-x32.adb
[Bug c++/57926] Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926 --- Comment #14 from lailavrazda1979 at gmail dot com --- Why wait? I'm not hugely opposed, but bugfixes are bugfixes, and one more fixed bug makes a better 4.9 release, right?
[Bug libgomp/60801] In gfortran, certain array sizes lead to SEGV within OpenMP PARALLEL DO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60801 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This sounds like you are running out of stack space. a 515x515 array of 4 byte wide is over a meg of data which is too big for the stack.
[Bug fortran/60795] [4.7/4.8/4.9 Regression] Wrong length when allocating character array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60795 Sean Santos quantheory at gmail dot com changed: What|Removed |Added CC||quantheory at gmail dot com --- Comment #3 from Sean Santos quantheory at gmail dot com --- In comment 2, y3, t3, and the second allocation of s3 are all cases of PR44672; this is an unsupported feature of F2008. The original case (comment 0, s1) may be a duplicate of PR57456. The case s2 looks like a duplicate of PR58754, and s3 and s4 may be the same issue. Or they may be related to PR50221. So there are clearly some issues here, but I think that they are mostly old issues, i.e. arrays of deferred-length strings have always been somewhat broken. I remember something about some intention to address this when implementing the new array descriptor, though?
[Bug middle-end/60802] New: jump2 pass fails to do cfgcleanup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60802
Bug ID: 60802
Summary: jump2 pass fails to do cfgcleanup
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: manjian2006 at gmail dot com
problem source:
int foo (int *a, int s, int predicate)
{
if (predicate 0)
{
for (int i = 0; i s; ++i)
{
a[i] = 0xfafafafa;
}
}
else if (predicate == 0)
{
for (int i = 0; i s; ++i)
{
a[i] = 0xfcfcfcfc;
}
}
else
{
for (int i = 0; i s; ++i)
{
a[i] = 0xf2f2f2f2;
}
}
return predicate;
}
compiles with -O3 -S
output assembly:
.L2:
.cfi_restore_state
jne.L10
testl%esi, %esi
jle.L7
subl$1, %esi
leaq4(,%rsi,4), %rdx
movl$252, %esi
=callmemset
movl%ebx, %eax
popq%rbx
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.p2align 4,,10
.p2align 3
.L10:
.cfi_restore_state
testl%esi, %esi
jle.L7
subl$1, %esi
leaq4(,%rsi,4), %rdx
movl$242, %esi
=callmemset
movl%ebx, %eax
popq%rbx
.cfi_def_cfa_offset 8
as we can see duplicate call memset and return assembly has been generated.
And I take a look at the output from jump2 pass,and examine the call site of
memset:
(call_insn 30 28 85 4 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:DI (memset) [flags 0x41] function_decl
0x7fd0daa91d00 __builtin_memset) [0 memsetD.998 S1 A8])
(const_int 0 [0]))) 649 {*call_value}
(expr_list:REG_DEAD (reg:DI 5 di)
(expr_list:REG_DEAD (reg:SI 4 si)
(expr_list:REG_DEAD (reg:DI 1 dx)
(expr_list:REG_UNUSED (reg:DI 0 ax)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil))
(expr_list:DI (set (reg:DI 0 ax)
(reg:DI 5 di))
(expr_list:DI (use (reg:DI 5 di))
(expr_list:SI (use (reg:SI 4 si))
(expr_list:DI (use (reg:DI 1 dx))
(nil))
(jump_insn 85 30 86 4 (set (pc)
(label_ref 84)) 636 {jump}
(nil)
- 84)
(call_insn 60 58 90 9 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:DI (memset) [flags 0x41] function_decl
0x7fd0daa91d00 __builtin_memset) [0 memsetD.998 S1 A8])
(const_int 0 [0]))) 649 {*call_value}
(expr_list:REG_DEAD (reg:DI 5 di)
(expr_list:REG_DEAD (reg:SI 4 si)
(expr_list:REG_DEAD (reg:DI 1 dx)
(expr_list:REG_UNUSED (reg:DI 0 ax)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil))
(expr_list:DI (set (reg:DI 0 ax)
(reg:DI 5 di))
(expr_list:DI (use (reg:DI 5 di))
(expr_list:SI (use (reg:SI 4 si))
(expr_list:DI (use (reg:DI 1 dx))
(nil))
(jump_insn 90 60 91 9 (set (pc)
(label_ref 84)) 636 {jump}
(nil)
- 84)
(call_insn 76 74 84 10 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:DI (memset) [flags 0x41] function_decl
0x7fd0daa91d00 __builtin_memset) [0 memsetD.998 S1 A8])
(const_int 0 [0]))) 649 {*call_value}
(expr_list:REG_DEAD (reg:DI 5 di)
(expr_list:REG_DEAD (reg:SI 4 si)
(expr_list:REG_DEAD (reg:DI 1 dx)
(expr_list:REG_UNUSED (reg:DI 0 ax)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil))
(expr_list:DI (set (reg:DI 0 ax)
(reg:DI 5 di))
(expr_list:DI (use (reg:DI 5 di))
(expr_list:SI (use (reg:SI 4 si))
(expr_list:DI (use (reg:DI 1 dx))
(nil))
three call sites have the identical content,and jump to the same basic block
after calls.So it may be combine as one.
[Bug middle-end/60802] jump2 pass fails to do cfgcleanup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60802 linzj manjian2006 at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from linzj manjian2006 at gmail dot com --- after added a option --param min-crossjump-insns=1,the expecting assembly is generated.
[Bug c++/60803] New: Trivial example of overloading in the presence of inheritance fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60803
Bug ID: 60803
Summary: Trivial example of overloading in the presence of
inheritance fails
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
The following very simple code fails to compile:
///
templatetypename Ts
struct refines
: Ts
{};
struct A
{};
struct B
: refinesA
{};
struct C
: refinesB
{};
void fun(void *)
{}
templatetypename T
int fun(refinesT *)
{
return 0;
}
int main()
{
C *p = 0;
int i = fun(p);
}
[Bug libgomp/60801] In gfortran, certain array sizes lead to SEGV within OpenMP PARALLEL DO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60801 Ryan genflot at yahoo dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Ryan genflot at yahoo dot com --- (In reply to Andrew Pinski from comment #1) This sounds like you are running out of stack space. a 515x515 array of 4 byte wide is over a meg of data which is too big for the stack. Andrew, You are correct: that was my problem. It had occurred to me that this could be a stack space issue, so I (uselessly) tried ulimit -s unlimited before posting my original message. After reading your comment, I did export OMP_STACKSIZE=1G, which solved my problem. Thank you for your help, --Ryan
[Bug c/60804] New: Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804 Bug ID: 60804 Summary: Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: andi-gcc at firstfloor dot org Created attachment 32577 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32577action=edit test case from csmith I hacked csmith to add some _Cilk_spawn keywords and let it run for a bit. The only new ICE that turned up was this (in various incarnations) Here's the unreduced file from csmith. x.c:178:35: internal compiler error: in gimplify_expr, at gimplify.c:8335 if ((safe_div_func_uint8_t_u_u(_Cilk_spawn func_4(((--(*l_9)) , g_10), void*)0 != g_13) , (g_14[1][0] == ((safe_add_func_uint32_t_u_u(g_14[1][0], (g_1 9 || (((*l_2079) = _Cilk_spawn func_20(((safe_rshift_func_uint16_t_u_s((~((*l_39 ) = ((safe_rshift_func_int16_t_s_u(((*l_37) = (safe_add_func_int8_t_s_s((_Cilk_s pawn func_28(g_31, g_32) = g_19), 0x5FL))), 11)) , 0xC254L))), 5)) g_19))) != (void*)0 , g_33))) | l_2080), g_420[4][0][1], g_847), l_2080))) ^ 0x79bad0 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_ba se**, bool (*)(tree_node*), int) ../../gcc/gcc/gimplify.c:8335 0x799d38 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_ba se**, bool (*)(tree_node*), int) ../../gcc/gcc/gimplify.c:7715 0x7a0ed3 gimplify_call_expr ../../gcc/gcc/gimplify.c:2354 0x79b1fc gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_ba se**, bool (*)(tree_node*), int) ../../gcc/gcc/gimplify.c:7402 0x79aacc gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_ba ...
[Bug c++/60803] Trivial example of overloading in the presence of inheritance fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60803 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- Also fails for the 4.9.0 trunk, the relevant part of the error message being quote main.cpp: In function 'int main()': main.cpp:29:16: error: void value not ignored as it ought to be int i = fun(p); ^ /quote
