[Bug c++/64870] value not set via reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Andrew Pinski --- (In reply to Conrad from comment #4) > (In reply to Marc Glisse from comment #3) > > > > Except when there is an = sign, where you expect the right hand side to be > > evaluated before the left? And maybe a few other cases? > > For iostreams which use the << operator for printing, the expected order is > to print things left-to-right, and hence evaluate left-to-right. No, that is not how C++ defines it. As mentioned before C++ does not define the order of the execution of the operands. > > > > What is the benefit in changing the expected order of evaluation? > > > > Performance. > > Is there a benchmark to support the re-ordering? If we're talking 1%-2% > here and there, is this really worth the "wtf" moments? There is no wtf moments. This is not Java which has well defined behavior :).
[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123 Jan Hubicka changed: What|Removed |Added CC||nathan at codesourcery dot com --- Comment #8 from Jan Hubicka --- The crash happens before gcov_var->file is NULL. Nathan, I would suspect that perhaps one of your visibility changes makes us to use gcov_open from wrong copy of libgcov (there are multiple shared libraries linked with it) that in turn initializes wong copy of gcov_var->file?
[Bug target/64871] inline assembly neon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64871 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |target Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- You don't record that you write memory. Also you don't record that you touch %0. You should be using the neon intrinsics instead really.
[Bug c++/64870] value not set via reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870 --- Comment #4 from Conrad --- (In reply to Marc Glisse from comment #3) > > Except when there is an = sign, where you expect the right hand side to be > evaluated before the left? And maybe a few other cases? For iostreams which use the << operator for printing, the expected order is to print things left-to-right, and hence evaluate left-to-right. > > What is the benefit in changing the expected order of evaluation? > > Performance. Is there a benchmark to support the re-ordering? If we're talking 1%-2% here and there, is this really worth the "wtf" moments?
[Bug c++/64870] value not set via reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870 --- Comment #3 from Marc Glisse --- (In reply to Conrad from comment #2) > Notwithstanding loopholes in C++ legalese, No loopholes, this was a deliberate choice in C. > the expected result is to > evaluate things left to right, just like reading words and sentences. Except when there is an = sign, where you expect the right hand side to be evaluated before the left? And maybe a few other cases? > clang produces the least surprising result. With gcc we end up with "wtf?" C/C++ programmers learn about that soon enough. > What is the benefit in changing the expected order of evaluation? Performance.
[Bug ipa/64858] [5 Regression] Libreoffice build failure caused by ICF crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64858 Markus Trippelsdorf changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P1
[Bug c++/64870] value not set via reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870 --- Comment #2 from Conrad --- Notwithstanding loopholes in C++ legalese, the expected result is to evaluate things left to right, just like reading words and sentences. clang produces the least surprising result. With gcc we end up with "wtf?" What is the benefit in changing the expected order of evaluation? Not trying to pick a fight here -- I genuinely want to know whether there is a good reason to change the order.
[Bug c/64871] New: inline assembly neon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64871
Bug ID: 64871
Summary: inline assembly neon
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: x8zmac at hotmail dot com
Hi
I add a piece of code in multimedia.
It makes data in array reverse.
It works, but when I add -O2 or -O3 the result is error and vmov with -O2 ,-O3
create illegal instruction.
asm volatile
(
"pld [%0, #0xFFF];\n\t\
vldm %0!,{d0-d3};\n\t\
vswp.32 d0,d3;\n\t\
vswp.32 d1,d2;\n\t\
VREV64.32 q0, q0;\n\t\
VREV64.32 q1, q1;\n\t\
vstm %1!,{d0-d3};"
:
:"r"(data),"r"(coeff),"r"(tmp),"r"(sum),"r"(ptr)
:"d0", "d1","d2","d3","d4","d5","d6","d7"
);
asm volatile
(
"pld [%0, #0xFFF];\n\t\
vldm %0!,{d0-d3};\n\t\
vldm %1!,{d4-d7};\n\t\
VMUL.I32 d0,d0,d4;\n\t\
VMUL.I32 d1,d1,d5;\n\t\
VMUL.I32 d2,d2,d6;\n\t\
VMUL.I32 d3,d3,d7;\n\t\
VADD.I32 d0,d0,d1;\n\t\
VADD.I32 d2,d2,d3;\n\t\
VADD.I32 d0,d0,d2;\n\t\
VMOV %2,%3,d0;\n\t\
add %3,%3,%2;\n\t\
str %3,[%4]"
:
:"r"(data),"r"(coeff),"r"(tmp),"r"(sum),"r"(ptr)
:"d0", "d1","d2","d3","d4","d5","d6","d7"
);
[Bug tree-optimization/62173] [5.0 regression] 64bit Arch can't ivopt while 32bit Arch can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 --- Comment #31 from amker at gcc dot gnu.org --- So cand_value_at (loop, cand, use->stmt, desc->niter, &bnd) with arguments as below: cand->iv->base: (unsigned long) ((char *) &A + (sizetype) i_6(D)) cand->iv->step: 0x desc->niter: (unsigned int)(i_6(D) + -1) use->stmt: is after increment The result calculated should like below: iv->base + iv->step * (unsigned long)niter + step <=> (unsigned long) ((char *) &A + (sizetype) i_6(D)) + 0x * ((unsigned long)(unsigned int)(i_6(D) + -1)) + 0x Even with range information [1, 10] for i_6(D), and we can prove that niter's range is [0, 9]. We can't prove it equals to: (unsigned long)((char *) &A) This is because we use unsigned type for step and lose the sign information? And this can't be fixed even with the proper range information. Is this understanding correct? Or anything I should do to achieve that? Thanks very much.
[Bug target/64580] very high rs6000_stack_info() usage during LTO Firefox build on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64580 --- Comment #12 from Markus Trippelsdorf --- Fixed for gcc-5. Many thanks. I'll leave this bug open for possible backports.
[Bug c++/64870] value not set via reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870 Marc Glisse changed: What|Removed |Added Severity|major |normal --- Comment #1 from Marc Glisse --- -Wsequence-point fails to warn, but that's still a bug in your program, there is no reason to evaluate setval before reading val and not after. Split your cout lines in two.
[Bug c++/64870] New: value not set via reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870
Bug ID: 64870
Summary: value not set via reference
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: conradsand.arma at gmail dot com
Created attachment 34624
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34624&action=edit
rebug.cpp
gcc 4.9.2 fails to set a value through a reference.
Consider the following code:
#include
struct blah {
inline double setval(unsigned int& x) const
{
x = 123;
return 456.0;
}
};
int
main(int argc, char** argv) {
blah blah_instance;
unsigned int val = ;
std::cout << blah_instance.setval(val) << " val: " << val << std::endl;
std::cout << blah_instance.setval(val) << " val: " << val << std::endl;
return 0;
}
when compiled with gcc 4.9.2, the above program produces the following output:
456 val:
456 val: 123
when compiled with clang 3.5:
456 val: 123
456 val: 123
[Bug target/64580] very high rs6000_stack_info() usage during LTO Firefox build on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64580 --- Comment #11 from Segher Boessenkool --- Author: segher Date: Fri Jan 30 05:35:52 2015 New Revision: 220272 URL: https://gcc.gnu.org/viewcvs?rev=220272&root=gcc&view=rev Log: PR target/64580 * config.rs6000/rs6000.c (compute_vrsave_mask): Reverse loop order. (rs6000_stack_info): Add assert. (rs6000_output_savres_externs): New function, split off from... (rs6000_output_function_prologue): ... here. Do not call it for thunks. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123 Jan Hubicka changed: What|Removed |Added CC||xur at google dot com --- Comment #7 from Jan Hubicka --- Rong, this may be related to gcov reorg.
[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123 --- Comment #6 from Jan Hubicka --- Note that -fno-ipa-icf does not seem to solve the crash for me.
[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123 --- Comment #5 from Jan Hubicka --- OK, I get: (gdb) bt #0 _IO_fread (buf=0x77fe6740 <__gcov_var+32>, size=size@entry=1, count=count@entry=4096, fp=0x0) at iofread.c:43 #1 0x77fe1719 in gcov_read_words (words=words@entry=2) at ../../../libgcc/../gcc/gcov-io.c:518 #2 0x77fe1d1e in __gcov_read_counter () at ../../../libgcc/../gcc/gcov-io.c:555 #3 0x77fe144d in gcov_get_counter () at ../../../libgcc/libgcov.h:316 #4 __gcov_merge_add (counters=0x77fe66f8 <__gcov0._Z30mozalloc_set_oom_abort_handlerPFvmE>, n_counters=) at ../../../libgcc/libgcov-merge.c:56 #5 0x70758f28 in merge_one_data (crc32=3347144653, eof_pos_p=, summary_pos_p=, this_prg=0x7fff8d60, prg_p=0x7fffa530, gi_ptr=0x77fe6340, filename=0x76f41920 "/aux/hubicka/firefox6-50-lto-fdo3/memory/mozalloc/Unified_cpp_memory_mozalloc0.gcda") at ../../../libgcc/libgcov-driver.c:472 #6 dump_one_gcov (all_prg=, this_prg=0x7fff8d60, crc32=3347144653, run_counted=0, gf=, gi_ptr=0x77fe6340) at ../../../libgcc/libgcov-driver.c:787 #7 gcov_do_dump (list=, run_counted=0) at ../../../libgcc/libgcov-driver.c:846 #8 0x70759242 in __gcov_dump_one (root=root@entry=0x77fe7760 <__gcov_root>) at ../../../libgcc/libgcov-driver.c:858 #9 0x70714fe8 in __gcov_dump_int () at ../../../libgcc/libgcov-interface.c:164 #10 0x70714e8f in __gcov_flush () at ../../../libgcc/libgcov-interface.c:88 #11 0x70714ca6 in __gcov_fork () at ../../../libgcc/libgcov-interface.c:179 #12 0x7fffeb6bff8e in fire_glxtest_process() () from /aux/hubicka/firefox6-50-lto-fdo3/dist/bin/libxul.so #13 0x7fffeb842a61 in XREMain::XRE_mainInit(bool*) () from /aux/hubicka/firefox6-50-lto-fdo3/dist/bin/libxul.so #14 0x7fffeb84f339 in XREMain::XRE_main(int, char**, nsXREAppData const*) () from /aux/hubicka/firefox6-50-lto-fdo3/dist/bin/libxul.so #15 0x7fffeb84f998 in XRE_main () from /aux/hubicka/firefox6-50-lto-fdo3/dist/bin/libxul.so #16 0x0042ce70 in do_main(int, char**, nsIFile*) [clone .constprop.24] () #17 0x00409725 in main () What is however interesting is: #4 __gcov_merge_add (counters=0x77fe66f8 <__gcov0._Z30mozalloc_set_oom_abort_handlerPFvmE>, n_counters=) at ../../../libgcc/libgcov-merge.c:56 Profiling part of runtime library that is used to implement gcov is not really intended to work. Perhaps we somehow broke profiling of Mozilla's malloc?
[Bug tree-optimization/64365] [4.9 Regression] Predictive commoning after loop vectorization produces incorrect code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365 --- Comment #13 from Brooks Moses --- FWIW, if you haven't done the 4.9 backport yet, this is what I ended up with. I'm not sure it's optimal, but it seems to work. Index: gcc/tree-data-ref.c === --- gcc/tree-data-ref.c (revision 220259) +++ gcc/tree-data-ref.c (working copy) @@ -973,6 +973,24 @@ fold_convert (ssizetype, memoff)); memoff = build_int_cst (TREE_TYPE (memoff), 0); } + /* Adjust the offset so it is a multiple of the access type +size and thus we separate bases that can possibly be used +to produce partial overlaps (which the access_fn machinery +cannot handle). */ + double_int rem; + if (TYPE_SIZE_UNIT (TREE_TYPE (ref)) + && TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (ref))) == INTEGER_CST + && !integer_zerop (TYPE_SIZE_UNIT (TREE_TYPE (ref + rem = tree_to_double_int (off).mod +(tree_to_double_int (TYPE_SIZE_UNIT (TREE_TYPE (ref))), false, + TRUNC_MOD_EXPR); + else + /* If we can't compute the remainder simply force the initial + condition to zero. */ + rem = tree_to_double_int (off); + off = double_int_to_tree (ssizetype, tree_to_double_int (off) - rem); + memoff = double_int_to_tree (TREE_TYPE (memoff), rem); + /* And finally replace the initial condition. */ access_fn = chrec_replace_initial_condition (access_fn, fold_convert (orig_type, off)); /* ??? This is still not a suitable base object for
[Bug c++/63386] Release version of CB wont compile Bullet (-o2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63386 Damiano changed: What|Removed |Added CC||dmonax at hotmail dot com --- Comment #8 from Damiano --- Created attachment 34623 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34623&action=edit preprocessed source file
[Bug ada/64869] New: "use all type" clause is ineffective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64869 Bug ID: 64869 Summary: "use all type" clause is ineffective Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: demoonlit at panathenaia dot halfmoon.jp "use all type" clauses for nested packages from an outer subprogram are ineffective. procedure case1 is package P is type T is (X, Y, Z); procedure Proc (Obj : T) is null; end P; -- procedure Nested is --use all type P.T; -- effective in nested subprogram --Obj : P.T := X; -- begin --Proc (Obj); -- visible -- end Nested; use all type P.T; Obj : P.T := X; -- invisible begin Proc (Obj); -- invisible end case1; % gcc -c case1.adb case1.adb:2:09: missing body for "P" case1.adb:13:22: "X" is not visible case1.adb:13:22: non-visible declaration at line 3 case1.adb:15:09: "Proc" is not visible case1.adb:15:09: non-visible declaration at line 4 with Ada.Containers.Vectors; procedure case2 is package Vectors is new Ada.Containers.Vectors (Positive, Character); -- procedure Nested is --use all type Vectors.Vector; -- effective in nested subprogram --X : Vectors.Vector := To_Vector (0); -- visible -- begin --Append (X, 'A'); -- visible -- end Nested; use all type Vectors.Vector; X : Vectors.Vector := To_Vector (0); -- visible begin Append (X, 'A'); -- invisible end case2; % gcc -c case2.adb case2.adb:13:09: "Append" is not visible case2.adb:13:09: non-visible declaration at a-convec.ads:243, instance at line 3 case2.adb:13:09: non-visible declaration at a-convec.ads:239, instance at line 3 Note, "use all type" clauses from nested sibling subprograms (commented out subprograms "Nested" in above examples) are effective, and, strangely, above examples will become to be compiled with the subprograms "Nested" (??)
[Bug go/61880] Linking with external functions in C does not work in GO when using gccgo, while it works in gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880 --- Comment #7 from ian at gcc dot gnu.org --- Author: ian Date: Fri Jan 30 00:36:14 2015 New Revision: 220269 URL: https://gcc.gnu.org/viewcvs?rev=220269&root=gcc&view=rev Log: compiler: Fix -fgo-prefix handling. There was bug in the fix for PR 61880: it only worked fully correctly for code compiled with -fgo-pkgpath. For code that used -fgo-prefix, or that used neither option, the '.' separating the prefix and the package name was converted to an underscore, which did not happen before. This broke SWIG and any other code that expected specific symbol names. Fortunately all code compiled in libgo and all code compiled by the go tool uses -fgo-pkgpath, so this probably did not affect very many people. This is an incomplete fix that does not modify the package file format, for use on both mainline and the GCC 4.9 branch. A follow on patch will fully fix the problem. Modified: branches/gcc-4_9-branch/gcc/go/gofrontend/export.cc branches/gcc-4_9-branch/gcc/go/gofrontend/export.h branches/gcc-4_9-branch/gcc/go/gofrontend/gogo.cc branches/gcc-4_9-branch/gcc/go/gofrontend/gogo.h branches/gcc-4_9-branch/gcc/go/gofrontend/import.cc branches/gcc-4_9-branch/gcc/go/gofrontend/unsafe.cc
[Bug go/61880] Linking with external functions in C does not work in GO when using gccgo, while it works in gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880 --- Comment #6 from ian at gcc dot gnu.org --- Author: ian Date: Fri Jan 30 00:35:44 2015 New Revision: 220268 URL: https://gcc.gnu.org/viewcvs?rev=220268&root=gcc&view=rev Log: compiler: Fix -fgo-prefix handling. There was bug in the fix for PR 61880: it only worked fully correctly for code compiled with -fgo-pkgpath. For code that used -fgo-prefix, or that used neither option, the '.' separating the prefix and the package name was converted to an underscore, which did not happen before. This broke SWIG and any other code that expected specific symbol names. Fortunately all code compiled in libgo and all code compiled by the go tool uses -fgo-pkgpath, so this probably did not affect very many people. This is an incomplete fix that does not modify the package file format, for use on both mainline and the GCC 4.9 branch. A follow on patch will fully fix the problem. Modified: trunk/gcc/go/gofrontend/export.cc trunk/gcc/go/gofrontend/export.h trunk/gcc/go/gofrontend/gogo.cc trunk/gcc/go/gofrontend/gogo.h trunk/gcc/go/gofrontend/import.cc trunk/gcc/go/gofrontend/unsafe.cc
[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123 Jan Hubicka changed: What|Removed |Added Last reconfirmed|2014-12-02 00:00:00 |2015-1-29 CC||hubicka at gcc dot gnu.org --- Comment #4 from Jan Hubicka --- Still reproduces...
[Bug preprocessor/64803] [5 Regression] __LINE__ inside macro is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64803 --- Comment #6 from Dodji Seketeli --- Created attachment 34622 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34622&action=edit Refined candidate fix patch with regression test and cover letter I have successfully tested this refined patch locally and I am currently bootstrapping it. I'll submit it right away if it passes bootstrap. Thanks for testing the previous one!
[Bug fortran/64854] No bound check for explicit-shape arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854 --- Comment #6 from Harald Anlauf --- (In reply to Lorenz Hüdepohl from comment #4) > > The right way to fix the problem is to fix the program > > by using an appropriate programming style. Writing > > > > real:: a(n1:) ! not: real :: a(n1:n2) > > > > one gets the expected check > > I realize that, and when I write my own code I would never > use such a construction. However, sometimes one is burdened > with existing code in which small treasures such as this kind > of bug are hidden. > > I was hoping that with -fcheck=bounds I could find this. As Dominique pointed out, this is not the way bounds checking is usually implemented. Checks are local. Fortran allows you to intentionally bypass all checks by using explicit size specifications. You can even use different ranks of the array in the caller and the callee. If you lie to the compiler in that situation about proper sizes, then you lose. > If the code was correct already there would be no need for > any kind of runtime checks, right? Right. But IMHO bounds check are not applicable here. Try other compilers. I'd expect them to behave similarly. Use valgrind or -fsanitize=address to detect this kind of memory problems. (I solved my linking problem by updating to current trunk).
[Bug fortran/64854] No bound check for explicit-shape arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854 --- Comment #5 from Dominique d'Humieres --- Note that the error is detected if the code is compiled with -fsanitize=address. And IMO the right way to use the array in a 'contains' is a(:) (for which -fcheck=bounds works).
[Bug libffi/64855] FAIL: libffi.call/* -W -Wall -Wno-psabi -O0 -DABI_NUM=* -DABI_ATTR=* execution test on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855 mrs at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mrs at gcc dot gnu.org Known to work||5.0 Resolution|--- |FIXED --- Comment #8 from mrs at gcc dot gnu.org --- Fixed.
[Bug libffi/64855] FAIL: libffi.call/* -W -Wall -Wno-psabi -O0 -DABI_NUM=* -DABI_ATTR=* execution test on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855 --- Comment #7 from mrs at gcc dot gnu.org --- Author: mrs Date: Thu Jan 29 22:09:16 2015 New Revision: 220264 URL: https://gcc.gnu.org/viewcvs?rev=220264&root=gcc&view=rev Log: 2015-01-29 Jack Howarth PR libffi/64855 * testsuite/lib/libffi.exp: Don't set targetabis on darwin. Modified: trunk/libffi/ChangeLog trunk/libffi/testsuite/lib/libffi.exp
[Bug c/64862] printf attribute should accept other string types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862 --- Comment #4 from joseph at codesourcery dot com --- Note also that gcc.dg/format tests are run both with and without -DWIDE - the intent there is that wide string formats should be tested, when supported, with essentially the same tests as narrow string formats (via appropriate macros to make the tests generic, e.g. wrapping format strings in a macro L()). That could be applied to other string types as well by running the tests more than twice.
[Bug c/47781] warnings from custom printf format specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 --- Comment #12 from joseph at codesourcery dot com --- On Thu, 29 Jan 2015, tromey at gcc dot gnu.org wrote: > E.g., firefox has a logging printf that accepts "%hs" to print char16_t* > strings. This extension means that printf checking can't be used here. > Requiring a plugin to deal with this situation would also be difficult. > However letting one write __attribute__((printf, 1, 2, "hs", char16_t*)) > would solve this nicely. Do you then take this as being length modifier 'h' followed by format specifier 's', or is it a complete specifier on its own with everything that would otherwise be length and specifier being reparsed as an extension if it can't be parsed as a standard format? Do the flags "-wp" and "cR" for %s formats apply to this format?
[Bug libffi/64855] FAIL: libffi.call/* -W -Wall -Wno-psabi -O0 -DABI_NUM=* -DABI_ATTR=* execution test on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855 --- Comment #6 from howarth at bromo dot med.uc.edu --- Patch posted at https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02664.html.
[Bug target/49551] tentative declaration after definition and -fdata-sections cause ICE in C front-end.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49551 Prathamesh changed: What|Removed |Added CC||bilbotheelffriend at gmail dot com --- Comment #3 from Prathamesh --- It appears the issue is still present on trunk for arm-none-linux-gnueabihf. Compiling the above code gives following ICE: (arm-none-linux-gnueabihf-gcc -O -fdata-sections): fo.c:2:1: internal compiler error: in get_variable_section, at varasm.c:1151 int x; ^ 0xd1b9ab get_variable_section(tree_node*, bool) /home/prathamesh.kulkarni/arm-gnu-toolchain/src/gcc.git~master/gcc/varasm.c:1150 0xd1ca81 get_block_for_decl /home/prathamesh.kulkarni/arm-gnu-toolchain/src/gcc.git~master/gcc/varasm.c:1216 0xd1e50f make_decl_rtl(tree_node*) /home/prathamesh.kulkarni/arm-gnu-toolchain/src/gcc.git~master/gcc/varasm.c:1346 0x5301fc duplicate_decls /home/prathamesh.kulkarni/arm-gnu-toolchain/src/gcc.git~master/gcc/c/c-decl.c:2732 0x533400 pushdecl(tree_node*) /home/prathamesh.kulkarni/arm-gnu-toolchain/src/gcc.git~master/gcc/c/c-decl.c:2888 0x5457d6 start_decl(c_declarator*, c_declspecs*, bool, tree_node*) /home/prathamesh.kulkarni/arm-gnu-toolchain/src/gcc.git~master/gcc/c/c-decl.c:4626 0x595d7e c_parser_declaration_or_fndef /home/prathamesh.kulkarni/arm-gnu-toolchain/src/gcc.git~master/gcc/c/c-parser.c:1846 0x5a07b8 c_parser_external_declaration /home/prathamesh.kulkarni/arm-gnu-toolchain/src/gcc.git~master/gcc/c/c-parser.c:1452 0x5a1215 c_parser_translation_unit /home/prathamesh.kulkarni/arm-gnu-toolchain/src/gcc.git~master/gcc/c/c-parser.c:1339 0x5a1215 c_parse_file() /home/prathamesh.kulkarni/arm-gnu-toolchain/src/gcc.git~master/gcc/c/c-parser.c:15416 0x5fd622 c_common_parse_file() /home/prathamesh.kulkarni/arm-gnu-toolchain/src/gcc.git~master/gcc/c-family/c-opts.c:1052 Thanks, Prathamesh
[Bug libffi/64855] FAIL: libffi.call/* -W -Wall -Wno-psabi -O0 -DABI_NUM=* -DABI_ATTR=* execution test on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855
--- Comment #5 from howarth at bromo dot med.uc.edu ---
Confirmed on x86_64-apple-darwin14 that...
Index: libffi/testsuite/lib/libffi.exp
===
--- libffi/testsuite/lib/libffi.exp(revision 220263)
+++ libffi/testsuite/lib/libffi.exp(working copy)
@@ -310,7 +310,7 @@ proc run-many-tests { testcases extra_fl
set targetabis { "" }
if [string match $compiler_vendor "gnu"] {
if { ([istarget "i?86-*-*"] || [istarget "x86_64-*-*"])
- && [is-effective-target ia32] } {
+ && [is-effective-target ia32] && ![istarget "*-*-darwin*"] } {
set targetabis {
""
"-DABI_NUM=FFI_STDCALL -DABI_ATTR=__STDCALL__"
eliminates all regressions in the libffi test suite.
=== libffi Summary ===
# of expected passes3828
# of unsupported tests60
[Bug libstdc++/64814] std::copy_n advances InputIterator one *less* time than necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64814
--- Comment #9 from Anquietas ---
(In reply to Jonathan Wakely from comment #8)
> N.B. libc++ changed its copy_n with
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20110221/039404.
> html and then libstdc++ did the same in PR 50119
I linked that bug report in the OP, but as it happens the behaviour is quite
interesting with std::istream_iterator using an adaptation of the code I
pasted in OP:
int main() {
std::istringstream ss("1 2 3 4 5 6 7 8 9 0 1 2 ");
std::vector output;
auto readIter = std::istream_iterator(ss);
for (int i = 0; i < 3; ++i) {
output.clear();
auto inserter = std::back_inserter(output);
// Doesn't work - outputs 123415671890
std::copy_n(readIter, 4, inserter);
for (auto n : output)
std::cout << n;
}
}
However, in this case moving readIter's declaration inside the loop fixes it.
If we go back to the code in OP and do the same, it *doesn't* fix it and still
produces the same output in either case. At the very least, the current
implementation of copy_n appears to be inconsistent, depending on the type of
iterator used. The implementation I provided for copy_n in OP doesn't work for
the istream_iterator case though, and neither does the direct for loop
approach.
[Bug sanitizer/64717] -fsanitize=vptr leads to warning: ‘’ may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64717 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug c/64709] [5 Regression] Bogus -Wmissing-field-initializers warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64709 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Fixed.
[Bug c/64709] [5 Regression] Bogus -Wmissing-field-initializers warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64709 --- Comment #6 from Marek Polacek --- Author: mpolacek Date: Thu Jan 29 21:02:21 2015 New Revision: 220263 URL: https://gcc.gnu.org/viewcvs?rev=220263&root=gcc&view=rev Log: PR c/64709 * c-typeck.c (pop_init_level): If constructor_elements has exactly one element with integer_zerop value, set constructor_zeroinit to 1. Remove braces around warning_init call. * gcc.dg/pr64709.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr64709.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/64351] std::uniform_real_distribution(0, 1) returns 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64351 emsr at gcc dot gnu.org changed: What|Removed |Added CC||emsr at gcc dot gnu.org --- Comment #1 from emsr at gcc dot gnu.org --- Created attachment 34621 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34621&action=edit Just keep trying in generate_canonical... I'm going to test this... Just keep looping until you get less that one in generate_canonical.
[Bug fortran/64854] No bound check for explicit-shape arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854 --- Comment #4 from Lorenz Hüdepohl --- > The right way to fix the problem is to fix the program > by using an appropriate programming style. Writing > > real:: a(n1:) ! not: real :: a(n1:n2) > > one gets the expected check I realize that, and when I write my own code I would never use such a construction. However, sometimes one is burdened with existing code in which small treasures such as this kind of bug are hidden. I was hoping that with -fcheck=bounds I could find this. If the code was correct already there would be no need for any kind of runtime checks, right?
[Bug c++/64867] warning for passing non-POD to varargs function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #4 from Tom Tromey ---
Thanks, I'll give it a try.
Here's my test case FWIW and a short demo showing what clang does:
pokyo. cat q.cc
#include
class ConstUTF8CharsZ
{
const char *mData;
public:
ConstUTF8CharsZ() : mData(0)
{
}
explicit ConstUTF8CharsZ(const char *aBytes)
: mData(aBytes)
{
}
const void *get() const { return mData; }
const char *c_str() const { return mData; }
operator bool() const { return mData != 0; }
};
void zzz(const char *x, ...) {
}
void m(const char *m) {
ConstUTF8CharsZ cu(m);
zzz(m, cu);
}
pokyo. clang++ q.cc
q.cc:30:10: error: cannot pass object of non-POD type 'ConstUTF8CharsZ' through
variadic function; call will abort at runtime [-Wnon-pod-varargs]
zzz(m, cu);
^
1 error generated.
[Bug sanitizer/64717] -fsanitize=vptr leads to warning: ‘’ may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64717 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Thu Jan 29 20:40:07 2015 New Revision: 220262 URL: https://gcc.gnu.org/viewcvs?rev=220262&root=gcc&view=rev Log: PR c++/64717 * cp-ubsan.c (cp_ubsan_instrument_vptr): Don't wrap vptr into SAVE_EXPR. * g++.dg/ubsan/pr64717-1.C: New test. * g++.dg/ubsan/pr64717-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/ubsan/pr64717-1.C trunk/gcc/testsuite/g++.dg/ubsan/pr64717-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-ubsan.c trunk/gcc/testsuite/ChangeLog
[Bug c/64868] New: C front-end rejects valid syntax.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64868 Bug ID: 64868 Summary: C front-end rejects valid syntax. Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: u17263 at att dot net Created attachment 34620 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34620&action=edit test case gcc version: 5.0.0 / svn: r220249 gcc -Wall -fopenmp -c bug-9.c bug-9.c: In function ‘foo’: bug-9.c:12:22: error: invalid form of ‘#pragma omp atomic’ before ‘;’ token fgot = 1.0 / fgot;
[Bug fortran/64854] No bound check for explicit-shape arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #3 from Harald Anlauf --- (In reply to Dominique d'Humieres from comment #1) > Well, you give wrong information to the compiler. How do expect it to handle > your mistake: in testsub -fcheck=bounds checks that n1<=i<=n2 which is the > case. What you ask for is a check that a(n1:n2) is inside a(1:10), AFAIK > such check is not implemented and I don't have any idea about how difficult > it is to implement it. valgrind detects this issue. I was expected that the address sanitizer is able to handle it, but I am getting linking errors on my system. > I am inclined to close tis PR as INVALID or WONTFIX. The right way to fix the problem is to fix the program by using an appropriate programming style. Writing real:: a(n1:) ! not: real :: a(n1:n2) one gets the expected check: At line 22 of file pr64854.f90 Fortran runtime error: Index '1048586' of dimension 1 of array 'a' above upper bound of 1048585 Backtrace for this error: + function testsub.3321 (0x80486A4) from file pr64854.f90 + in the main program from file pr64854.f90 + /lib/libc.so.6(__libc_start_main+0xf3) [0xb7424003] I also suggest to close the PR.
[Bug tree-optimization/64365] [4.9 Regression] Predictive commoning after loop vectorization produces incorrect code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365 --- Comment #12 from Brooks Moses --- Thanks, Richard! It looks like I'll need to backport this to our google/gcc-4_9 branch before that happens; any chance you already have a version of this patch that works with 4.9? The wide_int pieces don't exist in 4.9 AFAICT.
[Bug target/64047] [5 Regression] ICE: Segmentation fault when compiling gcc.dg/torture/pr52429.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64047 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-29 CC||dje at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from David Edelsohn --- Confirmed.
[Bug target/64159] [5 Regression] FAIL: gcc.dg/tree-ssa/ssa-dom-cse-2.c scan-tree-dump optimized "return 28;"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64159 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-29 CC||dje at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from David Edelsohn --- This is confirmed. Do we have agreement to XFAIL the testcase on powerpc and sparc?
[Bug c++/64867] warning for passing non-POD to varargs function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867 --- Comment #3 from Jason Merrill --- Passing a non-POD to a varargs function is conditionally-supported, with implementation-defined semantics. In GCC 5 it's supported and treated like normal pass-by-value. You can get a diagnostic about it with -Wconditionally-supported.
[Bug c++/64867] warning for passing non-POD to varargs function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867 --- Comment #2 from Jonathan Wakely --- Jason informs me it's now a warning enabled by -Wconditionally-supported
[Bug c++/64867] warning for passing non-POD to varargs function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867 --- Comment #1 from Andrew Pinski --- >From https://gcc.gnu.org/gcc-4.5/changes.html: Diagnostics that used to complain about passing non-POD types to ... or jumping past the declaration of a non-POD variable now check for triviality rather than PODness, as per C++0x. See PR 37907. And having an example would be useful too. Because of the change between C++98 and C++11.
[Bug c/64862] printf attribute should accept other string types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862 Andrew Pinski changed: What|Removed |Added Depends on||38308 --- Comment #3 from Andrew Pinski --- wchar_t part was filed as bug 38308 a long time ago.
[Bug c/64862] printf attribute should accept other string types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862
--- Comment #2 from Tom Tromey ---
Naturally my example was wrong.
Sorry about that. But gcc still doesn't handle it:
#include
#include
extern void p (const char16_t *fmt, ...)
__attribute__((format (__printf__, 1, 2)));
void f()
{
p (u"%s %d", 23, "hi");
}
... with gcc saying:
r.cc:5:44: error: format string argument is not a string type
__attribute__((format (__printf__, 1, 2)));
^
[Bug c/64862] printf attribute should accept other string types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862 --- Comment #1 from Andreas Schwab --- glibc has this in : extern int wprintf (const wchar_t *__restrict __format, ...) /* __attribute__ ((__format__ (__wprintf__, 1, 2))) */;
[Bug preprocessor/64864] [5 Regression] preprocessor linemarkers break configure checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek --- More info here https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723#c13 I'm going to prepare the porting_to bit, then I think we should close this bug.
[Bug c++/64867] New: warning for passing non-POD to varargs function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867 Bug ID: 64867 Summary: warning for passing non-POD to varargs function Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Currently gcc does not warn if I pass a non-POD to a varargs function. It would have been useful recently if there was an option to make gcc warn about this.
[Bug preprocessor/64864] [5 Regression] preprocessor linemarkers break configure checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864 --- Comment #4 from Jakub Jelinek --- The line markers allows the compiler to properly distinguish between what tokens come from where, e.g. system headers vs. normal headers (should we warn about issues in there if -Wsystem-headers is not used and it is some warning not enabled by default in system headers), or e.g. for #pragma GCC diagnostics tracking.
[Bug sanitizer/64717] -fsanitize=vptr leads to warning: ‘’ may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64717 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-01-29 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jakub Jelinek --- Created attachment 34619 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34619&action=edit gcc5-pr64717.patch Untested fix. The SAVE_EXPR in there was needed in earlier versions of =vptr support, where it emitted the __ubsan_* calls early, but right now it is used just once, and the SAVE_EXPR causes problems when the same dtor call is used shared in multiple locations (finally and cleanup). There is still a possible SAVE_EXPR if the address of the object has side-effects, but I hope dtors are never called that way if they'd could appear in cleanups.
[Bug preprocessor/64864] [5 Regression] preprocessor linemarkers break configure checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864 --- Comment #3 from Markus Trippelsdorf --- (In reply to Jakub Jelinek from comment #2) > I really think this is porting_to.html material, rather than a bug report. I agree that the issue is borderline. Feel free to close this bug. What is gained by these new linemarkers?
[Bug ada/64866] New: Lost visibility of package Interfaces after task or PO declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64866 Bug ID: 64866 Summary: Lost visibility of package Interfaces after task or PO declaration Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Created attachment 34618 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34618&action=edit Demonstrator While developing an Ada RTS, I found that code like with Interfaces; package body Foo is task T is end T; U : Interfaces.Unsigned_32 := 0; task body T is begin null; end T; end Foo; would fail with foo.adb:7:08: "Interfaces" is not visible (more references follow) foo.adb:7:08: non-visible declaration at interfac.ads:38 (and similar problems with a PO). I’m fairly confident that this is caused by having System.Tasking ‘with’ an unexpected package, in this case package FreeRTOS (it wasn’t just the name, I changed it to package Whatever, same result). I also tried making the child packages of FreeRTOS into nested packages, and then making that a child of System (in s-freert.ads); no joy. In the attachment, I’ve included the relevant RTS specs, which are all that is needed to show the problem when unpacked into the same directory as foo.ad?. The same problem occurs if the RTS code is in a proper RTS’s adainclude/.
[Bug libstdc++/64865] New: std::allocator::construct/destroy not called for specialization of std::allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64865
Bug ID: 64865
Summary: std::allocator::construct/destroy not called for
specialization of std::allocator
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Per N4296 [container.requirements.general]/3:
For the components affected by this subclause that declare an allocator_type,
objects stored in these components shall be constructed using the
allocator_traits::construct function and destroyed using the
allocator_traits::destroy function (20.7.8.2).
libstdc++ optimizes out calls to `construct` and `destroy` for types with
trivial construction/destruction when the allocator type is a specialization of
std::allocator: see implementation of __uninitialized_copy_a(InputIterator,
InputIterator, ForwardIterator, allocator<>&) in bits/stl_uninitialized.h, and
_Destroy(ForwardIterator, ForwardIterator, allocator<>&) in
bits/stl_construct.h. However, not every instance of std::allocator necessarily
has side-effect free implementation of construct/destruct, since
[namespace.std]/1 allows users to specialize templates in the standard
namespace if the declaration depends on a user-defined type. For example, this
program:
#include
#include
#include
struct mytype {
int value;
mytype(int v) : value{v} {}
operator int() const { return value; }
};
int constructions = 0, destructions = 0;
namespace std {
template <>
struct allocator<::mytype> {
using value_type = mytype;
allocator() = default;
template
allocator(const allocator&) {}
mytype* allocate(std::size_t n) {
return static_cast(::operator new(n * sizeof(mytype)));
}
void deallocate(mytype* ptr, std::size_t) noexcept {
::operator delete(ptr);
}
template
void construct(U* ptr, Args&&...args) {
::new ((void*)ptr) U(std::forward(args)...);
++::constructions;
}
template
void destroy(U* ptr) noexcept {
++::destructions;
ptr->~U();
}
friend constexpr bool operator == (const allocator&, const allocator&)
noexcept {
return true;
}
friend constexpr bool operator != (const allocator&, const allocator&)
noexcept {
return false;
}
};
} // namespace std
int main() {
{
std::vector{1,2,3};
// assert(constructions == 3); // assert would fire
}
// assert(destructions == 3); // assert would fire
return constructions != 3 || destructions != 3;
}
always returns non-zero, and either of the asserts will fire if uncommented.
Some possible solutions:
* Change all such optimizations in the library to presume that specializations
of std::allocator are the "default allocator" only if they are derived from
__allocator_base. This is the case for the base template definition as
implemented in bits/allocator.h.
* Remove all such optimizations from the library, and let the compiler optimize
away trivial construction and destruction. This has the unfortunate side effect
of slowing down debug builds of user programs.
* Close this bug report as WONTFIX since it is horrible design to specialize
std::allocator instead of declaring a new allocator type; given that container
implementations are free to rebind to a different specialization, there is no
guarantee that functionality added to a user-defined specialization will even
be used.
[Bug preprocessor/64864] [5 Regression] preprocessor linemarkers break configure checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864 --- Comment #2 from Jakub Jelinek --- I really think this is porting_to.html material, rather than a bug report.
[Bug preprocessor/64864] [5 Regression] preprocessor linemarkers break configure checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- But they should. Though, it is true that it affects quite a lot of packages, e.g. cclive emacs ember gnote ksh libcmis libgpg-error libixion liborcus ncurses openldap to name a few. As before, the change was introduced with PR60723.
[Bug preprocessor/64864] New: [5 Regression] preprocessor linemarkers break configure checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864 Bug ID: 64864 Summary: [5 Regression] preprocessor linemarkers break configure checks Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: dodji at gcc dot gnu.org For example (this happens for many projects that check for the boost version): ... checking for working strtod... yes checking for gettimeofday... yes checking for Boost headers version >= 1.36.0... yes checking for Boost's header version... configure: error: invalid value: boost_major_version= markus@x4 core % cat test.cpp #include boost-lib-version = BOOST_LIB_VERSION markus@x4 core % g++ -E test.cpp # 1 "test.cpp" # 1 "" # 1 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "" 2 # 1 "test.cpp" # 1 "/usr/include/boost/version.hpp" 1 3 4 # 2 "test.cpp" 2 boost-lib-version = # 2 "test.cpp" 3 4 "1_56" markus@x4 core % /usr/x86_64-pc-linux-gnu/gcc-bin/4.9.2/g++ -E test.cpp # 1 "test.cpp" # 1 "" # 1 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "" 2 # 1 "test.cpp" # 1 "/usr/include/boost/version.hpp" 1 3 4 # 2 "test.cpp" 2 boost-lib-version = "1_56" I know that these linemarkers are valid. But is it really necessary that they appear in the middle of statements? Using -P is a workaround, that apparently nobody uses in configure scripts. See also PR64604.
[Bug libffi/64855] FAIL: libffi.call/* -W -Wall -Wno-psabi -O0 -DABI_NUM=* -DABI_ATTR=* execution test on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855 --- Comment #4 from Iain Sandoe --- (In reply to Richard Henderson from comment #2) > I apologize for my mis-diagnosis earlier. These tests are not > expected to pass on Darwin at present. Disabling them in the > testsuite is the best thing to do for now. adding: && ![istarget "*-*-darwin*"] should be enough - the targetabis list is initialised to "" before that test.
[Bug c++/64521] [4.9/5 Regression] ICE with -frepo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64521 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #4 from Jason Merrill --- Fixed.
[Bug target/64844] [5 Regression] Vectorization inhibited in gcc5 when loop starts with elem[1], aarch64 perf regression from 4.9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64844 --- Comment #7 from Chris Jones --- Confirmed fixed at TOT. Thank you!
[Bug c++/64863] New: error for use of members of a forward declared enum is poor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64863
Bug ID: 64863
Summary: error for use of members of a forward declared enum is
poor
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tbsaunde at gcc dot gnu.org
consider this test case
enum class foo;
int bar();
int main()
{
if (bar() < foo::baz)
return 0;
return 1;
}
produces
test.cpp: In function ‘int main()’:
test.cpp:7:14: error: ‘baz’ is not a member of ‘foo’
if (bar() < foo::baz)
^
which while true isn't terrible helpful. I'd think it would be better to say
only a forward declaration of foo has been seen, and to use members you need
the full definition.
[Bug c/64862] New: printf attribute should accept other string types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862
Bug ID: 64862
Summary: printf attribute should accept other string types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Consider this source:
#include
#include
extern void p (const char16_t *fmt, ...)
__attribute__((__printf__ (1, 2)));
void f()
{
p(u"%d\n", 23);
}
Currently gcc rejects this attribute:
pokyo. gcc --syntax-only -std=c11 -Wall r.c
r.c:5:3: warning: ‘__printf__’ attribute directive ignored [-Wattributes]
__attribute__((__printf__ (1, 2)));
^
I don't see why it should, though.
It seems to me that it could accept wchar_t, char16_t, or char32_t
strings as the format argument.
[Bug c++/64521] [4.9/5 Regression] ICE with -frepo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64521 --- Comment #5 from Jason Merrill --- Author: jason Date: Thu Jan 29 16:47:32 2015 New Revision: 220255 URL: https://gcc.gnu.org/viewcvs?rev=220255&root=gcc&view=rev Log: PR c++/64521 * repo.c (repo_emit_p): It's OK for a clone to be extern at this point. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/template/repo11.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/repo.c
[Bug c/47781] warnings from custom printf format specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #11 from Tom Tromey --- (In reply to jos...@codesourcery.com from comment #4) > For the general issue, my inclination is that we should add plugin hooks > into the format checking machinery that allow plugins to define formats > with the full flexibility of all the format checking datastructures in > GCC. I agree this makes sense for the general case, but I wanted to point out that requiring a plugin for the simple cases is significantly harder for users than some in-source extension mechanism. E.g., firefox has a logging printf that accepts "%hs" to print char16_t* strings. This extension means that printf checking can't be used here. Requiring a plugin to deal with this situation would also be difficult. However letting one write __attribute__((printf, 1, 2, "hs", char16_t*)) would solve this nicely. I suppose I think that a format-for-a-specific-type is the most common kind of extension and so may deserve special treatment.
[Bug libffi/64855] FAIL: libffi.call/* -W -Wall -Wno-psabi -O0 -DABI_NUM=* -DABI_ATTR=* execution test on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855 --- Comment #3 from howarth at bromo dot med.uc.edu --- FYI, I reported struct5.exe execution failures upstream earlier in the thread... https://sourceware.org/ml/libffi-discuss/2015/msg00019.html https://sourceware.org/ml/libffi-discuss/2015/msg00020.html https://sourceware.org/ml/libffi-discuss/2015/msg00021.html
[Bug libffi/64855] FAIL: libffi.call/* -W -Wall -Wno-psabi -O0 -DABI_NUM=* -DABI_ATTR=* execution test on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855 --- Comment #2 from Richard Henderson --- I apologize for my mis-diagnosis earlier. These tests are not expected to pass on Darwin at present. Disabling them in the testsuite is the best thing to do for now. Long term, someone needs to figure out the problems with Darwin in the upstream libffi respository, so we can move Darwin onto the shared code base with the rest of the x86 ports.
[Bug jit/64780] toplevel configure should reject jit as a language if --enable-host-shared is not supplied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64780 --- Comment #3 from David Malcolm --- Author: dmalcolm Date: Thu Jan 29 16:25:14 2015 New Revision: 220253 URL: https://gcc.gnu.org/viewcvs?rev=220253&root=gcc&view=rev Log: PR jit/64780: configure: --enable-host-shared and the jit ChangeLog: PR jit/64780 * configure.ac: Require the user to explicitly specify --enable-host-shared if the jit is enabled. * configure: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac
[Bug fortran/64861] New: Possible wrong code with BIND(C) and PRIVATE + slightly bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64861
Bug ID: 64861
Summary: Possible wrong code with BIND(C) and PRIVATE +
slightly bogus warning
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: diagnostic, wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Blocks: 49111
This PR is partially identical to PR49111 / See also
https://groups.google.com/forum/#!topic/comp.lang.fortran/RedeUCqh12c ("Private
interfaces with iso_c_binding")
In modules, gfortran warns for module procedures - and for interface procedures
with BIND(C) attribute, which are marked as PRIVATE:
Warning: Symbol 'my_c_routine' at (1) is marked PRIVATE but has been given
the binding label 'my_c_routine'
This warning seems to be on by default (not checked) and is slightly bogus.
There are two meanings of PRIVATE: (a) avoid cluttering the name space when
USE-ing a module. (b) To hide a symbol from the rest of the world.
Fortran's meaning is (a), although some users think of (b) - seemingly also the
warning writer.
Additionally, there might be a wrong-code issue: gfortran marks PRIVATE module
procedures (and variables) which are not otherwise used as being only used in
that file - based on the knowledge that it cannot be used (without knowledge of
the name mangling of gfortran).
I think it currently misses the check for BIND(C). (BTW: A BIND(C) function
without a name (i.e. name="" or an internal procedure) can continue to be
marked as static.)
THUS:
* Check whether the TREE_PUBLIC handling is correctly done for BIND(C)+PRIVATE
(honoring additionally whether it has a binding name or not.)
The following items are the same/similar to PR49111
* Check whether the warning message makes really sense - and if so, improve the
wording and consider not to enable it by default.
* If continuing to warn: Consider not to warn at all for INTERFACE and only for
module procedures.
[Bug c++/49508] [4.8/4.9/5 regression] Bogus "control reaches end of non-void function" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49508 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #9 from Jason Merrill --- Fixed for GCC 5.
[Bug c++/49508] [4.8/4.9/5 regression] Bogus "control reaches end of non-void function" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49508 --- Comment #8 from Jason Merrill --- Author: jason Date: Thu Jan 29 16:10:08 2015 New Revision: 220252 URL: https://gcc.gnu.org/viewcvs?rev=220252&root=gcc&view=rev Log: PR c++/49508 * semantics.c (finish_return_stmt): Suppress -Wreturn-type on erroneous return statement. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/g++.old-deja/g++.jason/report.C
[Bug c++/64521] [4.9/5 Regression] ICE with -frepo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64521 --- Comment #3 from Jason Merrill --- Author: jason Date: Thu Jan 29 16:09:56 2015 New Revision: 220251 URL: https://gcc.gnu.org/viewcvs?rev=220251&root=gcc&view=rev Log: PR c++/64521 * repo.c (repo_emit_p): It's OK for a clone to be extern at this point. Added: trunk/gcc/testsuite/g++.dg/template/repo11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/repo.c
[Bug jit/64810] jit not working on armv7hl ("ld: error: /tmp/libgccjit-ZGemdr/fake.so uses VFP register arguments, /tmp/ccJFCBsE.o does not")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810 --- Comment #19 from David Malcolm --- (In reply to ramana.radhakrish...@arm.com from comment #18) [...snip...] > Yes this value is bogus as are the other .cpu values - the assembler > output suggests to me that the configure time options aren't being > passed at all from the driver down when used as a jit. Given the > configure options I would expect > > .arch armv7-a > .fpu vfpv3-d16 > > and an EABI attribute tag to indicate the PCS. > > I think you've worked this out reading down-thread. Thanks for the confirmation. I'm testing a patch for this now.
[Bug sanitizer/64670] -fsanitize=vptr leads to "undefined reference to `typeinfo for class'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64670 --- Comment #4 from Jason Merrill --- This seems like a bug in the user's code, not the compiler. If the class is defined in a header with #pragma interface, there needs to be a matching #pragma implementation somewhere to cause the typeinfo and such to be emitted. clang doesn't run into this because it just ignores #pragma interface.
[Bug middle-end/64394] ICE: in build_linearized_memory_access, at graphite-interchange.c:121 (isl_constraint.c:558: expecting integer value) with -floop-interchange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64394 Jana Saout changed: What|Removed |Added CC||jana at saout dot de --- Comment #1 from Jana Saout --- I'm presumably seeing this bug being hit when trying to build gcc 5 with lto-bootstrapping. My backtrace is garbled, but the "isl_constraint.cc": "expecting integer value" is also at the core of the ICE.
[Bug c++/49508] [4.8/4.9/5 regression] Bogus "control reaches end of non-void function" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49508 Jason Merrill changed: What|Removed |Added Status|REOPENED|ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Summary|Bogus "control reaches end |[4.8/4.9/5 regression] |of non-void function" |Bogus "control reaches end |warning |of non-void function" ||warning --- Comment #7 from Jason Merrill --- 4.4 didn't warn, so it seems reasonable to call it a regression.
[Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860 Richard Biener changed: What|Removed |Added Keywords||lto, wrong-code Known to work||4.9.2 Target Milestone|--- |5.0 Summary|multiple definition of |[5 Regression] multiple |typeinfo in 5.0 (4.9.2 |definition of typeinfo in |works) |5.0 (4.9.2 works)
[Bug lto/64860] multiple definition of typeinfo in 5.0 (4.9.2 works)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Richard Biener --- Honza?
[Bug lto/64860] New: multiple definition of typeinfo in 5.0 (4.9.2 works)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860 Bug ID: 64860 Summary: multiple definition of typeinfo in 5.0 (4.9.2 works) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: sirl at gcc dot gnu.org Created attachment 34617 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34617&action=edit Simple testcase. Use "make" to reproduce. While trying to construct a testcase for a 4.8 to 4.9 change of LTO linking behaviour, I stumbled over this (just re-tested with r220248): g++-5 -flto -fuse-linker-plugin -O2 -Wall -Wextra -c file1.cpp g++-5 -flto -fuse-linker-plugin -O2 -Wall -Wextra -c file2.cpp gcc-5 -flto -fuse-linker-plugin -Wl,-r -nostdlib -o lib1.lib file1.o gcc-5 -flto -fuse-linker-plugin -Wl,-r -nostdlib -o lib2.lib file2.o g++-5 -flto -fuse-linker-plugin -O2 -o testexe lib1.lib lib2.lib lib2.lib:(.rodata+0x0): multiple definition of `typeinfo name for CDialogBase' lib1.lib:(.rodata+0x0): first defined here collect2: error: ld returned 1 exit status # g++-5 -v Using built-in specs. COLLECT_GCC=g++-5 COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/5/lto-wrapper Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,fortran --with-gxx-include-dir=/usr/include/c++/5 --enable-ssp --disable-libssp --disable-libvtv --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --with-default-libstdcxx-abi=c++98 --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-5 --without-system-libunwind --enable-multilib --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux Thread model: posix gcc version 5.0.0 20150129 (experimental) (SUSE Linux) gcc-4.8.3 and 4.9.2 compile and link the same code just fine.
[Bug sanitizer/64717] -fsanitize=vptr leads to warning: ‘’ may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64717 --- Comment #2 from Gert-jan Los --- Created attachment 34616 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34616&action=edit test case with virtual base class version: gcc version 5.0.0 20150128 (experimental) (GCC) options: -O -fsanitize=vptr -Werror=uninitialized gap_widths.C.i: In function ‘void fn1()’: gap_widths.C.i:13:41: error: ‘’ is used uninitialized in this function [-Werror=uninitialized]
[Bug sanitizer/64717] -fsanitize=vptr leads to warning: ‘’ may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64717 Gert-jan Los changed: What|Removed |Added CC||gerrit.los at gmail dot com --- Comment #1 from Gert-jan Los --- Created attachment 34615 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34615&action=edit test case with virtual destructor version: gcc version 5.0.0 20150128 (experimental) (GCC) options: -O -fsanitize=vptr -Werror=uninitialized PostScript_Back_End.C.i: In function ‘void fn1()’: PostScript_Back_End.C.i:8:34: error: ‘’ is used uninitialized in this function [-Werror=uninitialized]
[Bug c++/49508] Bogus "control reaches end of non-void function" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49508
Jonathan Wakely changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #6 from Jonathan Wakely ---
I'm seeing this frequently too, I was about to create a new PR as follows:
struct Y { };
struct X {
X(short*);
};
X f() { int i; return &i; }
w.cc: In function ‘X f()’:
w.cc:5:24: error: could not convert ‘& i’ from ‘int*’ to ‘X’
X f() { int i; return &i; }
^
w.cc:5:27: warning: control reaches end of non-void function [-Wreturn-type]
X f() { int i; return &i; }
^
The warning is useless, because as soon as the error is fixed the warning will
go away, so it adds nothing but noise to the output.
And it's also confusing because there's a return statement *right* *there*! I
can see it and GCC even printed it out! :-) It only reaches the end because GCC
decides to ignore the return statement that fails in order to continue
compiling the rest of the function.
This doesn't happen in all cases where the return statement has an error, e.g.
if the example above does return i; instead of return &i; there's no warning.
[Bug c++/64859] New: -Wabi-tag is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64859 Bug ID: 64859 Summary: -Wabi-tag is not documented Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org The -Wabi-tag warning is not documented, it only shows up in gcc --help=warnings -Wabi-tag Warn if a subobject has an abi_tag attribute that the complete object type does not have
[Bug ipa/64858] [5 Regression] Libreoffice build failure caused by ICF crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64858 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.0
[Bug sanitizer/64839] libsanitizer shouldn't require
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64839 --- Comment #1 from Harald van Dijk --- FWIW, libsanitizer builds just fine if the rpc references are forcibly removed, like so: --- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc +++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc @@ -131,7 +131,6 @@ #include #include #include -#include #include #include #include @@ -1148,19 +1147,6 @@ CHECK_SIZE_AND_OFFSET(group, gr_gid); CHECK_SIZE_AND_OFFSET(group, gr_mem); #if SANITIZER_LINUX && !SANITIZER_ANDROID -CHECK_TYPE_SIZE(XDR); -CHECK_SIZE_AND_OFFSET(XDR, x_op); -CHECK_SIZE_AND_OFFSET(XDR, x_ops); -CHECK_SIZE_AND_OFFSET(XDR, x_public); -CHECK_SIZE_AND_OFFSET(XDR, x_private); -CHECK_SIZE_AND_OFFSET(XDR, x_base); -CHECK_SIZE_AND_OFFSET(XDR, x_handy); -COMPILER_CHECK(__sanitizer_XDR_ENCODE == XDR_ENCODE); -COMPILER_CHECK(__sanitizer_XDR_DECODE == XDR_DECODE); -COMPILER_CHECK(__sanitizer_XDR_FREE == XDR_FREE); -#endif - -#if SANITIZER_LINUX && !SANITIZER_ANDROID COMPILER_CHECK(sizeof(__sanitizer_FILE) <= sizeof(FILE)); CHECK_SIZE_AND_OFFSET(FILE, _flags); CHECK_SIZE_AND_OFFSET(FILE, _IO_read_ptr); But that's clearly not acceptable :)
[Bug libgomp/61798] OpenMP exit code 155, profiling related?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61798 --- Comment #3 from Manuel Kessler --- Thank you both for trying to help. @Andrew: This is on x86_64, running kernel 3.1.0 on an (admittedly old) openSUSE 11.4. @Jakub: You are probably right, but the question remains, how a SIGPROF (probably from the profiling machinery added with -pg) can escape up to the user level instead of being catched by said machinery - and what to do against it, of course. Ciao, Manuel
[Bug target/60925] [4.9/5 Regression] hppa: can't find a register in class 'R1_REGS' while reloading 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #12 from Jeffrey A. Law --- See c#11.
[Bug target/15184] [4.8/4.9 Regression] Direct access to byte inside word not working with -march=pentiumpro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|4.8.5 |5.0 Summary|[4.8/4.9/5 Regression] |[4.8/4.9 Regression] Direct |Direct access to byte |access to byte inside word |inside word not working |not working with |with -march=pentiumpro |-march=pentiumpro --- Comment #33 from Jeffrey A. Law --- Fixed on trunk. Not planning to backport to release branches (requires 4 insn combine code).
[Bug target/15184] [4.8/4.9/5 Regression] Direct access to byte inside word not working with -march=pentiumpro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184 --- Comment #32 from Jeffrey A. Law --- Author: law Date: Thu Jan 29 14:30:45 2015 New Revision: 220249 URL: https://gcc.gnu.org/viewcvs?rev=220249&root=gcc&view=rev Log: PR target/15184 * combine.c (try_combine): If I0 is a memory load and I3 a store to a related address, increase the "goodness" of doing a 4-insn combination with I0-I3. (make_field_assignment): Handle SUBREGs in the ior+and case. PR target/15184 * gcc.target/i386/pr15184-1.c: New test. * gcc.target/i386/pr15184-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr15184-1.c trunk/gcc/testsuite/gcc.target/i386/pr15184-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
[Bug other/51153] OpenACC implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51153 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus --- The basic implementation is now (= GCC 5) in: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01258.html See also https://gcc.gnu.org/wiki/OpenACC Even though, it is not fully working, yet. I think this PR can now be closed and instead one could concentrate on the remaining issues elsewhere (PRs with 'openacc' keyword, pending patches).
[Bug ipa/64858] New: [5 Regression] Libreoffice build failure caused by ICF crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64858
Bug ID: 64858
Summary: [5 Regression] Libreoffice build failure caused by ICF
crash
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
trippels@gcc2-power8 ~ % cat xpathobject.ii
template class A
{
reference_type *m_pBody;
public:
A (const A &) { m_pBody->acquire (); }
};
class B;
class C
{
protected:
B *_pInterface;
};
template class I : C
{
public:
I (interface_type *);
};
class B
{
public:
virtual void acquire ();
};
class D
{
protected:
void acquire ();
};
template class J : D, public Ifc1
{
void
acquire ()
{
D::acquire ();
}
};
class K : B
{
};
class L;
class F
{
A m_pDocument;
F (A const &, int &&);
};
class XUnoTunnel;
class XEventTarget;
template class WeakImplHelper3 : D, B
{
void
acquire ()
{
D::acquire ();
}
};
template class G
{
public:
void
acquire ()
{
WeakImplHelper3 ();
}
};
struct H
{
H ()
: mxAttribList (new J), mxCurrentHandler (0), mxDocHandler (0),
mxTokenHandler (0)
{
}
I > mxAttribList;
I mxCurrentHandler;
I mxDocHandler;
I mxTokenHandler;
};
class L : public G
{
};
class M : public J
{
public:
M ();
};
template I::I (interface_type *p1)
{
B *a = static_cast (static_cast (p1));
_pInterface = a;
_pInterface->acquire ();
}
F::F (A const &p1, int &&) : m_pDocument (p1) { I (new M); }
trippels@gcc2-power8 ~ % g++ -O2 -std=gnu++11 -c xpathobject.ii
xpathobject.ii:90:66: internal compiler error: Segmentation fault
F::F (A const &p1, int &&) : m_pDocument (p1) { I (new M); }
^
0x10a141eb crash_signal
../../gcc/gcc/toplev.c:383
0x11070c88 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:2845
0x11070c88 ipa_icf::sem_function::init()
../../gcc/gcc/ipa-icf.c:786
0x11074923 ipa_icf::sem_item_optimizer::parse_nonsingleton_classes()
../../gcc/gcc/ipa-icf.c:1865
0x1107c353 ipa_icf::sem_item_optimizer::execute()
../../gcc/gcc/ipa-icf.c:1721
0x1107d173 ipa_icf_driver
../../gcc/gcc/ipa-icf.c:2461
0x1107d173 ipa_icf::pass_ipa_icf::execute(function*)
../../gcc/gcc/ipa-icf.c:2509
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug tree-optimization/64746] Loop with nested load/stores is not vectorized using aggressive if-conversion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64746 --- Comment #3 from ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Thu Jan 29 13:52:28 2015 New Revision: 220248 URL: https://gcc.gnu.org/viewcvs?rev=220248&root=gcc&view=rev Log: gcc/ PR tree-optimization/64746 * tree-if-conv.c (mask_exists): New function. (predicate_mem_writes): Save created mask with given size for further use. (stmt_is_root_of_bool_pattern): Remove argument VAR and store to it. (ifcvt_repair_bool_pattern): Collect all statements that are root of bool pattern and use iterative algorithm to remove multiple uses of predicates, display number of required iterations. gcc/testsuite/ PR tree-optimization/64746 * gcc.target/i386/avx2-vect-aggressive-1.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/avx2-vect-aggressive-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c
[Bug tree-optimization/64853] [5 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853 --- Comment #9 from Richard Biener --- Author: rguenth Date: Thu Jan 29 13:50:37 2015 New Revision: 220247 URL: https://gcc.gnu.org/viewcvs?rev=220247&root=gcc&view=rev Log: 2015-01-29 Richard Biener PR tree-optimization/64853 * tree-vrp.c (vrp_valueize_1): Do not return anything if the stmt will get simulated again. * tree-ssa-ccp.c (valueize_op_1): Likewise. * gcc.dg/torture/pr64853.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr64853.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c trunk/gcc/tree-vrp.c
[Bug tree-optimization/64853] [5 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Fixed.
[Bug target/64844] [5 Regression] Vectorization inhibited in gcc5 when loop starts with elem[1], aarch64 perf regression from 4.9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64844 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug target/64844] [5 Regression] Vectorization inhibited in gcc5 when loop starts with elem[1], aarch64 perf regression from 4.9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64844 --- Comment #5 from Richard Biener --- Author: rguenth Date: Thu Jan 29 12:53:39 2015 New Revision: 220244 URL: https://gcc.gnu.org/viewcvs?rev=220244&root=gcc&view=rev Log: 2015-01-29 Richard Biener PR tree-optimization/64844 * tree-vect-loop.c (vect_estimate_min_profitable_iters): Always dump cost model analysis. * tree-vect-data-refs.c (vect_enhance_data_refs_alignment): Do not register adjusted load/store costs here. * gcc.dg/vect/pr64844.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr64844.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-loop.c
[Bug middle-end/64809] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64809 --- Comment #10 from ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Thu Jan 29 12:20:55 2015 New Revision: 220241 URL: https://gcc.gnu.org/viewcvs?rev=220241&root=gcc&view=rev Log: gcc/testsuite/ PR middle-end/64809 * gcc.dg/pr64809.c: Delete. Removed: trunk/gcc/testsuite/gcc.dg/pr64809.c Modified: trunk/gcc/testsuite/ChangeLog
