[Bug c/61240] [4.8/4.9/5 Regression] Incorrect warning integer overflow in expression on pointer-pointer subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61240 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.8.5 |6.0
[Bug c++/65047] [c++17] Add support for nested namespace defintions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65047 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Patches should go to the gcc-patches list not bugzilla (it's not a bug that we have incomplete support for an incomplete draft standard)
[Bug libstdc++/65049] New: Undefined behaviour with std::char_traitschar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65049
Bug ID: 65049
Summary: Undefined behaviour with std::char_traitschar
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
#include string
int main()
{
const char* p = 0;
char* q = 0;
std::char_traitschar::compare(p, q, 0);
std::char_traitschar::find(p, 0, '0');
std::char_traitschar::move(q, p, 0);
std::char_traitschar::copy(q, p, 0);
std::char_traitschar::assign(q, 0, '0');
}
Compiled with ubsan:
/home/jwakely/gcc/5/include/c++/5.0.0/bits/char_traits.h:259:48: runtime error:
null pointer passed as argument 1, which is declared to never be null
/home/jwakely/gcc/5/include/c++/5.0.0/bits/char_traits.h:259:48: runtime error:
null pointer passed as argument 2, which is declared to never be null
/home/jwakely/gcc/5/include/c++/5.0.0/bits/char_traits.h:267:77: runtime error:
null pointer passed as argument 1, which is declared to never be null
/home/jwakely/gcc/5/include/c++/5.0.0/bits/char_traits.h:271:74: runtime error:
null pointer passed as argument 1, which is declared to never be null
/home/jwakely/gcc/5/include/c++/5.0.0/bits/char_traits.h:271:74: runtime error:
null pointer passed as argument 2, which is declared to never be null
/home/jwakely/gcc/5/include/c++/5.0.0/bits/char_traits.h:275:73: runtime error:
null pointer passed as argument 1, which is declared to never be null
/home/jwakely/gcc/5/include/c++/5.0.0/bits/char_traits.h:275:73: runtime error:
null pointer passed as argument 2, which is declared to never be null
/home/jwakely/gcc/5/include/c++/5.0.0/bits/char_traits.h:279:71: runtime error:
null pointer passed as argument 1, which is declared to never be null
We need to check for __n 0 here:
static int
compare(const char_type* __s1, const char_type* __s2, size_t __n)
{ return __builtin_memcmp(__s1, __s2, __n); }
Similarly for find, move, copy, assign.
This is a real problem, GCC 4.9+ will optimize away null checks based on calls
to these functions.
[Bug tree-optimization/62217] [4.9/5 Regression] DOM confuses complete unrolling which in turn causes VRP to warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62217 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #5) Kirill, you are correct WRT propagation of b for i. Prior to DOM1 we have: ;; basic block 3, loop depth 1, count 0, freq 9100, maybe hot ;;prev block 2, next block 4, flags: (NEW, REACHABLE) ;;pred: 7 [91.0%] (TRUE_VALUE,EXECUTABLE) if (i_1 == b_6(D)) goto bb 4; else goto bb 5; ;;succ: 4 [0.0%] (TRUE_VALUE,EXECUTABLE) ;;5 [100.0%] (FALSE_VALUE,EXECUTABLE) ;; basic block 4, loop depth 1, count 0, freq 2, maybe hot ;;prev block 3, next block 5, flags: (NEW, REACHABLE) ;;pred: 3 [0.0%] (TRUE_VALUE,EXECUTABLE) g_x[i_1] = *x1_7(D); goto bb 6; ;;succ: 6 [100.0%] (FALLTHRU,EXECUTABLE) ;; basic block 5, loop depth 1, count 0, freq 9098, maybe hot ;;prev block 4, next block 6, flags: (NEW, REACHABLE) ;;pred: 3 [100.0%] (FALSE_VALUE,EXECUTABLE) g_x[i_1] = *x2_9(D); ;;succ: 6 [100.0%] (FALLTHRU,EXECUTABLE) DOM records that i_1 and b_6 are equivalent on the edge bb3-bb4. So in bb4 it replaces i_1 with b_6. Presumably that's causing problems downstream in the optimization pipeline. The easiest way to think about this is we record that i_1 can be legitimately replaced with b_6 in that context. We could just have easily recorded that b_6 can be replaced with i_1. I don't think we have any heuristics for which of those two equivalences to record, it's strictly based on the order of appearance (which is likely determined elsewhere by canonicalization rules). If you want to propose some heuristics, I'm all ears. One might be to put the object with the least number of references on the lhs. THe idea would be to try and ultimately get that use count to 0/1 which may allow that object to die at the comparison. There may be some reasonable heuristic around loop depth of the names as well.ie, do we want to replace uses of a non-loop object with a loop object or vice versa? Anyway, open to suggestions here... The rule is simple - we should always replace with the more dominating definition because that's what value-numbering would do to be able to make the other defs unused.
[Bug libstdc++/65049] Undefined behaviour with std::char_traitschar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65049 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Yes, unfortunately the C++ standard doesn't define those members in terms of the C library calls they correspond to, and doesn't say anything special about null pointers, so they're required to handle null (I'm considering whether that could be considered a defect, we might want to forbid nulls so I'll raise that with the committee).
[Bug lto/65015] LTO produces randomly ordered debug information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65015 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Feb 13 09:35:57 2015 New Revision: 220678 URL: https://gcc.gnu.org/viewcvs?rev=220678root=gccview=rev Log: 2015-02-13 Richard Biener rguent...@suse.de PR lto/65015 * dwarf2out.c (dwarf2out_finish): Use artificial as DW_AT_name for LTO produced CUs. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug lto/65015] LTO produces randomly ordered debug information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65015 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||5.0 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Fixed for GCC 5 sofar.
[Bug c++/64956] [5 Regression] __GXX_ABI_VERSION needs a proper definition for the 5.x releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64956 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Fixed.
[Bug debug/57664] [4.8/4.9 Regression] ICE: in should_move_die_to_comdat, at dwarf2out.c:6750 with -fdebug-types-section and lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57664 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Summary|[4.8/4.9/5 Regression] ICE: |[4.8/4.9 Regression] ICE: |in |in |should_move_die_to_comdat, |should_move_die_to_comdat, |at dwarf2out.c:6750 with|at dwarf2out.c:6750 with |-fdebug-types-section and |-fdebug-types-section and |lambda |lambda --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed on trunk with r209812.
[Bug c/32643] [4.8/4.9/5 Regression] Wrong error message with unsigned char a = uchar512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32643 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Target Milestone|4.8.5 |6.0
[Bug libstdc++/65049] Undefined behaviour with std::char_traitschar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65049 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-13 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Similarly for char_traitswchar_t
[Bug middle-end/65048] [5 Regression] ICE in add_phi_args_after_copy_edge, at tree-cfg.c on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65048 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Component|target |middle-end Target Milestone|--- |5.0
[Bug libstdc++/65049] Undefined behaviour with std::char_traitschar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65049 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Is it well defined C++? If yes, I'm afraid you need to add if (__n) guard, or test for pointers being non-NULL.
[Bug tree-optimization/65002] [5 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65002 --- Comment #8 from ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Fri Feb 13 09:44:07 2015 New Revision: 220679 URL: https://gcc.gnu.org/viewcvs?rev=220679root=gccview=rev Log: gcc/ PR tree-optimization/65002 * tree-cfg.c (pass_data_fixup_cfg): Don't update SSA on start. * tree-sra.c (some_callers_have_no_vuse_p): New. (ipa_early_sra): Reject functions whose callers assume function is read only. gcc/testsuite/ PR tree-optimization/65002 * gcc.dg/pr65002.C: New. Added: trunk/gcc/testsuite/gcc.dg/pr65002.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-sra.c
[Bug c++/65047] [c++17] Add support for nested namespace defintions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65047 --- Comment #3 from Andrea Azzarone andrea.azzarone at canonical dot com --- (In reply to Jonathan Wakely from comment #2) Patches should go to the gcc-patches list not bugzilla (it's not a bug that we have incomplete support for an incomplete draft standard) Ok, thanks. Actually I already sent the patch to gcc-patches.
[Bug target/58945] Improve atomic_compare_and_swap*_doubleword pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58945 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Uroš Bizjak from comment #6) Register allocators can't allocate reg 97 to b and c constraint: So, a fwprop bug? Adding an expert to CC.
[Bug lto/65015] LTO produces randomly ordered debug information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65015 conchur at web dot de changed: What|Removed |Added Attachment #34724|0 |1 is obsolete|| --- Comment #9 from conchur at web dot de --- Created attachment 34746 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34746action=edit Mini Testcases Thanks a lot. I was playing around with your new patches. And I was looking at the buildid the whole time (assuming that it is the hash over the whole binary). This doesn't seem to be and was therefore a wrong assumption by me. What does it mean: * your patches work fine with -flto -flto-partition=none (which is awesome) * my conclusion that it also works with plain -flto as I said in the Debian bug #53 was wrong The testcases are updated to reflect this. SIMPLE-COMPILE: OK SIMPLE-LINK: OK LTO-LINK: FAIL LTO-OBJDUMP: FAIL LTO-EXTERNAL-DEBUG: FAIL LTO-STRIP-LINK: FAIL LTO-STRIP-EXTERNAL-DEBUG: FAIL LTO-BUILDID-LINK: FAIL LTO-SAVETEMPS-LINK: FAIL LTO-SAVETEMPS-EXTERNAL-DEBUG: FAIL NOPART-LTO-LINK: OK NOPART-LTO-OBJDUMP: OK NOPART-LTO-EXTERNAL-DEBUG: OK NOPART-LTO-STRIP-LINK: OK NOPART-LTO-STRIP-EXTERNAL-DEBUG: OK NOPART-LTO-BUILDID-LINK: OK NOPART-LTO-SAVETEMPS-LINK: OK NOPART-LTO-SAVETEMPS-EXTERNAL-DEBUG: OK
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-13 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Compelling the test with -fsanitize=address leads to an error at run time.
[Bug target/65044] ICE: SIGSEGV in contains_struct_check with -fsanitize=address -fcheck-pointer-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65044 --- Comment #1 from Ilya Enkovich enkovich.gnu at gmail dot com --- ICE occurs due to NULL field attached to a constructor element used for initialization of internal asan structure. Overall I don't think we should allow simultaneous usage of Pointer Bounds Checker and Address Sanitizer. It was never investigated how they may conflict. There should be at least a problem with static objects where each instrumentation creates static objects to describe existing ones, newly created objects are then also described by each other etc. I will prepare a patch to prevent checker usage with sanitizers.
[Bug fortran/65045] [4.8/4.9/5 Regression] ICE when using the same name for a block and a variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65045 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Keywords||error-recovery Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-13 CC||tkoenig at gcc dot gnu.org Summary|ICE |[4.8/4.9/5 Regression] ICE ||when using the same name ||for a block and a variable. Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Revision r195570 (2013-01-30) gives the errors without ICE, r195694 gives the ICE, likely r195684. Note that r220452 (5.0) gives pr65045.f90:3:6: Error: Symbol at (1) is not appropriate for an expression pr65045.f90:5:7: else 1 Error: Unexpected ELSE statement at (1) pr65045.f90:6:6: Error: 'i' at (1) is not a variable pr65045.f90:7:6: end if 1 Error: Expecting END BLOCK statement at (1) (null):0: confused by earlier errors, bailing out The reduced test real :: i = 9.9 i:block if (i7.7) then exit i end if end block i end gives pr65045_db_1.f90:3.6: if (i7.7) then 1 Error: Symbol at (1) is not appropriate for an expression pr65045_db_1.f90:7.6: end if 1 Error: Expecting END BLOCK statement at (1) f951: internal compiler error: Segmentation fault: 11
Segmentation fault with unique_ptr
Hi to everyone, I am using g++-4.9 with -std=c++14 option (no optimization flag). For some reason i have the following singly_linked_list class. The usage is this: 1) Construct a singly linked list 2) push_front() at least 1 values (this is important -- i.e for 1000 values i don't get a segfault) 3) Destroy the singly linked list At step 3 i get a segfault. What is wrong with the code? I would appreciate it if you could take a peek and help. (ps: bardon me if this isn't the right forum for such questions) -- View this message in context: http://gcc.1065356.n5.nabble.com/Segmentation-fault-with-unique-ptr-tp1120921.html Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug tree-optimization/65002] [5 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65002 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 target/64953] Compiling sourcecode for STM32F103 causes USB errors with some optimization settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64953 Mikhail Maltsev maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #18 from Mikhail Maltsev maltsevm at gmail dot com --- Is your firmware (or some similar one, which also has this bug) suitable for STM32F20x MCUs? I have a development board with such controller (specifically, this one: http://www.wvshare.com/product/Open207Z-Standard.htm). Perhaps, I could assist with debugging.
[Bug rtl-optimization/64317] [5 Regression] Ineffective allocation of PIC base register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317 --- Comment #11 from Ilya Enkovich enkovich.gnu at gmail dot com --- (In reply to Vladimir Makarov from comment #10) I guess it is easy to check by preventing pic pseudo generation. i386 back-end doesn't support fixed PIC register any more. This test case demonstrates performance regression in some EEMBC 1.1 tests caused by pseudo PIC register introduction. It is unclear why RA decided to spill PIC register. If we look at loop's code then we see PIC register is used in each line of code and seems to be the most used register. It also seems weird to me that code for the first loop becomes much better (with no PIC reg fills) if we restrict inlining for the other one. How does the second loop affect allocation in the first one?
[Bug fortran/65045] [4.8/4.9/5 Regression] ICE when using the same name for a block and a variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65045 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.5
[Bug fortran/65025] Internal compiler error with preprocessor in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65025 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-13 Ever confirmed|0 |1 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Reduced test #if plet=='s' #define ckind #endif end [Book15] f90/bug% gfc -cpp pr65025_db_1.f90 built-in: internal compiler error: Segmentation fault: 11 I see it with gfortran 4.4.7.
[Bug fortran/64980] [5 Regression] ICE in trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- With this patch all fortran test cases pass on x86_64. And the ICE goes away in the reduced test example. Does it work for you? It works for me for all the tests in this PR, without regression, and without visible problem in my own tests. Thanks.
[Bug lto/65015] LTO produces randomly ordered debug information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65015 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- For reference, the following patch doesn't work: Index: gcc/varasm.c === --- gcc/varasm.c(revision 220677) +++ gcc/varasm.c(working copy) @@ -7042,7 +7042,9 @@ default_file_start (void) !(flag_verbose_asm || flag_debug_asm || flag_dump_rtl_in_asm)) fputs (ASM_APP_OFF, asm_out_file); - if (targetm.asm_file_start_file_directive) + if (targetm.asm_file_start_file_directive + /* LTO produced units have no meaningful main_input_filename. */ + !in_lto_p) output_file_directive (asm_out_file, main_input_filename); } and -g is not necessary to trigger the bogus tempfile name in .symtab
[Bug libstdc++/65042] gcc5 has a template depth problem that was fine in gcc4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65042 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- Trying to use the standard library with such a tiny limit is simply not going to work. If it worked previously you got lucky, but if you need to raise the limit now then that's what you need to do. What's the purpose of enforcing such a tiny limit anyway?
[Bug lto/65015] LTO produces randomly ordered debug information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65015 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hjl.tools at gmail dot com Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Difference in readelf -a is --- x 2015-02-13 12:04:07.526383914 +0100 +++ y 2015-02-13 12:04:10.158414178 +0100 @@ -234,7 +234,7 @@ 42: 00600df8 0 OBJECT LOCAL DEFAULT 19 __do_global_dtors_aux_fin 43: 00400580 0 FUNCLOCAL DEFAULT 13 frame_dummy 44: 00600df0 0 OBJECT LOCAL DEFAULT 18 __frame_dummy_init_array_ -45: 0 FILELOCAL DEFAULT ABS cc5R4C1Y.ltrans0.o +45: 0 FILELOCAL DEFAULT ABS ccqmAj6c.ltrans0.o 46: 004005b111 FUNCLOCAL DEFAULT 13 helper 47: 0 FILELOCAL DEFAULT ABS elf-init.c 48: 0 FILELOCAL DEFAULT ABS crtstuff.c that is, somehow .symtab contains a reference to the ltrans object file name, probably because of .file ccqmAj6c.ltrans0.o we emit via output_file_directive. Unfortunately omitting that doesn't help. It seems that the linker itself adds those symbols!? HJ? Gold doesn't do that (thus, it works with -fuse-ld=gold).
Re: Segmentation fault with unique_ptr
On 13/02/15 11:15, tassos_souris wrote: Hi to everyone, I am using g++-4.9 with -std=c++14 option (no optimization flag). For some reason i have the following singly_linked_list class. The usage is this: 1) Construct a singly linked list 2) push_front() at least 1 values (this is important -- i.e for 1000 values i don't get a segfault) 3) Destroy the singly linked list At step 3 i get a segfault. What is wrong with the code? I would appreciate it if you could take a peek and help. (ps: bardon me if this isn't the right forum for such questions) Your question will probably be lost in the torrent of automated bug tracker emails that go on this list. We'll need more information than that, including source code. Please follow the instructions at https://gcc.gnu.org/bugs/ and submit a bug report if you think it's appropriate. Personally, I think you're just running out of memory (creating too large a list for your system), but I could be wrong. Kyrill -- View this message in context: http://gcc.1065356.n5.nabble.com/Segmentation-fault-with-unique-ptr-tp1120921.html Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug c/65050] New: Show the type for array type has incomplete element type error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65050
Bug ID: 65050
Summary: Show the type for array type has incomplete element
type error
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
In the following test case we have a few invalid decls. It would be nice if
the C FE showed the incomplete element type.
typedef int A[];
struct S { int i; A a[5]; } s;
extern void foo (int p[2][]);
extern void bar (A p[2]);
void
foo (int p[2][])
{
}
void
bar (A p[2])
{
}
struct T;
struct T t[5];
struct U u[] = { { abc } };
typedef struct T TT;
TT tt[5];
[Bug c/65050] Show the type for array type has incomplete element type error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65050 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-02-13 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- I have a patch.
[Bug fortran/64973] Duplicate use-statements could be diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64973 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-13 Ever confirmed|0 |1
[Bug middle-end/65048] [5 Regression] ICE in add_phi_args_after_copy_edge, at tree-cfg.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65048
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Target|arm-linux-gnueabihf |
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-02-13
CC||jakub at gcc dot gnu.org,
||spop at gcc dot gnu.org
Summary|[5 Regression] ICE in |[5 Regression] ICE in
|add_phi_args_after_copy_edg |add_phi_args_after_copy_edg
|e, at tree-cfg.c on |e, at tree-cfg.c
|arm-linux-gnueabihf |
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
Slightly cleaned up testcase (though, it still requires the invalid calls of
function requiring argument without the argument and missing return).
int a, b, c, d;
void fn (void);
int
foo (x)
{
switch (x)
{
case 'A':
return 'T';
case 'U':
return 'A';
}
}
void
bar (int x, int y)
{
switch (c)
{
case 'U':
switch (x)
{
default:
fn ();
case 'G':
switch (y)
{
case 'A':
d = 7;
}
}
}
}
void
baz (void)
{
while (1)
{
a = foo ();
b = foo ();
bar (a, b);
}
}
Started with r218451.
[Bug ipa/65034] [5 Regression] ICE (segfault) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65034 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Feb 13 14:42:30 2015 New Revision: 220683 URL: https://gcc.gnu.org/viewcvs?rev=220683root=gccview=rev Log: PR ipa/65034 * stmt.c (emit_case_nodes): Use void_type_node instead of NULL_TREE as LABEL_DECL type. * decl.c (start_preparsed_function): Use void_type_node instead of NULL_TREE as LABEL_DECL type. * g++.dg/ipa/pr65034.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr65034.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/stmt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/64970] Hard error instead of SFINAE for expression in nested template alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64970 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Fri Feb 13 14:54:48 2015 New Revision: 220684 URL: https://gcc.gnu.org/viewcvs?rev=220684root=gccview=rev Log: /cp 2015-02-13 Paolo Carlini paolo.carl...@oracle.com PR c++/64970 * decl.c (make_typename_type): Pass tsubst_flags_t argument to lookup_template_class. /testsuite 2015-02-13 Paolo Carlini paolo.carl...@oracle.com PR c++/64970 * g++.dg/cpp0x/sfinae55.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/sfinae55.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/64927] [4.8 Regression] Surprising error with -Wsurprising (-Wall) and TRANSFER + C_ASSOCIATED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64927 --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- After Dominique pointed out a range of revisions where the bug disappeared in the 4.9 branch, I browsed through the list of svn log messages. However, all fortran-related commits that looked interesting to me (some of them TRANSFER related) appeared to have backports to the 4.8 branch. Maybe I was not careful enough. AFAICT r198000 (pr56969) has not been back ported. The patch is almost trivial. If you don't beat me, I may find the motivation to do some testing during the weekend. My reasoning is based on the observation that Tobias Burnus just closed PR64474 as WONTFIX for the similar reason: 4.9 and 5 don't have the resp. bug, all 4.8.x have. Well, at the same time Bernd Edlinger closed pr60718 as FIXED while the problem is still present in versions 4.8 and 4.9. The problem is that 'WONTFIX for version m, FIXED for version nm' cannot be encoded in the Status field. My decision rule is the following: WONTFIX: the issue is present in version m and will be present in any version nm. This typically used for extension or diagnostic requests. FIXED: the issue is present in version m, has been fixed in version n, and will be absent in any version p=n (otherwise it will be a regression). This is the default rule when a PR is not a regression.
[Bug fortran/39627] [meta-bug] Fortran 2008 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39627 Bug 39627 depends on bug 39988, which changed state. Bug 39988 Summary: F2008: Default initialization, structure constructors, and allocatable components https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39988 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/64970] Hard error instead of SFINAE for expression in nested template alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64970 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |5.0 Known to fail|5.0 | --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 5.0.
[Bug c++/65046] [5 regression] -Wabi-tag doesn't warn about variables or function return types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65046 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Summary|-Wabi-tag doesn't warn |[5 regression] -Wabi-tag |about variables or function |doesn't warn about |return types|variables or function ||return types --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Marking this as a regression to raise its visibility.
[Bug c++/60211] [4.9/5 Regression] ICE with #pragma GCC ivdep and for-loop on global scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60211 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #1) This is strictly speaking a regression that would be easy to fix in cp_parser_pragma. I wonder, however, if we want to handle the pragma as, eg, PRAGMA_CILK_SIMD, thus explicitly reject the pragma itself when context == pragma_external Sounds good to me.
[Bug lto/65015] LTO produces randomly ordered debug information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65015 --- Comment #13 from H.J. Lu hjl.tools at gmail dot com --- We are generating .filecc8zpoWj.ltrans0.o ^ We shouldn't do it. .text .Ltext0: .typehelper, @function helper: .LFB0: .file 1 dependency.c
[Bug fortran/39988] F2008: Default initialization, structure constructors, and allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39988 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- This PR seems fixed between revisions r219070 (2014-12-26) and r219099 (2014-12-29), likely r219098 (pr60357). Closing as FIXED.
Re: Segmentation fault with unique_ptr
the main function is as simple as this: Compile with: g++-4.9 -std=c++14 -g -o main main.cpp and run with ./main. I get segfault. gdb in bt shows that the segfault happens inside unique_ptr destructor. So it is not a memory issue. Also since the code runs with less size (i.e size=1000 no problem) i assume that something is wrong with unique_ptr and not my code. That's of course only an assumption don't get me wrong :) Thanks for looking at it -- View this message in context: http://gcc.1065356.n5.nabble.com/Segmentation-fault-with-unique-ptr-tp1120921p1120949.html Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug c++/65051] New: [5 Regression] r210436 regression?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65051
Bug ID: 65051
Summary: [5 Regression] r210436 regression?
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
templatetypename T struct wrap { typedef T type; };
template class T class rv: public wrap T::type {};
template class value_type
struct circular_buffer
{
typedef const value_type param_value_type;
typedef rv value_type rvalue_type;
void push_back(param_value_type item) {}
void push_back(rvalue_type item) {}
};
union U { int i; char c; };
void f(circular_bufferU b, const U u) { b.push_back(u); }
used to be accepted until r210435, since r210436 it is rejected. Jon said that
this is accepted by clang and EDG.
[Bug tree-optimization/62209] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62209 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Note, this no longer fails starting with r217827. I'll have a look nevertheless, in case that wasn't a fix but just made a bug latent.
[Bug fortran/64933] ASSOCIATE on a character variable does not allow substring expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64933 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-13 CC||pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Up to revision r219797 (2015-01-17), I get the error pr64933.f90:5:31: ASSOCIATE(should_work=char_var) 1 Error: Associate-name 'should_work' at (1) is used as array Starting at r219823 (2015-01-18) I get the ICE. Likely a fall out of r219814 (pr55901). Please feel free to mark this PR as a 5.0 regression.
[Bug c++/64956] [5 Regression] __GXX_ABI_VERSION needs a proper definition for the 5.x releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64956 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Matthias Klose from comment #3) #if !defined(__GXX_ABI_VERSION) || __GXX_ABI_VERSION != 1002 #error The C++ ABI version of compiler you are using does not match #error that of the compiler used to build the library. The versions #error must match or your program will not work correctly. #error The Xapian library was built with g++ 4.9.1 #endif I would expect that Xapian built with -fabi-version=2 and -fabi-version=8 should be compatible; the only changes to the compiler ABI are mangling, which with a template library probably only leads to a bit of code bloat from duplicated functions with different names. I suppose there could be runtime issues if there are variables mangled differently, but that's less likely.
[Bug c++/65051] [5 Regression] r210436 regression?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65051 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||redi at gcc dot gnu.org Target Milestone|--- |5.0
[Bug c++/65051] [5 Regression] r210436 regression?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65051 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-02-13 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/65052] New: ICE in c6x-uclinux target when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65052
Bug ID: 65052
Summary: ICE in c6x-uclinux target when building libgcc
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
When building libgcc using a c6x-uclinux gcc-5 that I've just built, I see the
following ICE:
/data/fedora/cross-gcc/tmp/build/./gcc/xgcc
-B/data/fedora/cross-gcc/tmp/build/./gcc/ -B/usr/c6x-uclinux/bin/
-B/usr/c6x-uclinux/lib/ -isystem /usr/c6x-uclinux/include -isystem
/usr/c6x-uclinux/sys-include-O2 -g -Wall -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-mbig-endian -O2 -O2 -g -Wall -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include -msdata=none -msdata=none -fPIC -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -msdata=none
-msdata=none -fPIC -I. -I. -I../../.././gcc
-I../../../../gcc-5.0.0-20150210/libgcc
-I../../../../gcc-5.0.0-20150210/libgcc/.
-I../../../../gcc-5.0.0-20150210/libgcc/../gcc
-I../../../../gcc-5.0.0-20150210/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS
-o _lshrdi3.o -MT _lshrdi3.o -MD -MP -MF _lshrdi3.dep -DL_lshrdi3 -c
../../../../gcc-5.0.0-20150210/libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS
../../../../gcc-5.0.0-20150210/libgcc/libgcc2.c: In function '__gnu_lshrdi3':
../../../../gcc-5.0.0-20150210/libgcc/libgcc2.c:426:1: error: insn does not
satisfy its constraints:
}
^
(insn 86 72 8 2 (cond_exec (eq (reg:SI 0 A0)
(const_int 0 [0]))
(unspec [
(label_ref:SI 36)
(const_int 0 [0])
] UNSPEC_REAL_JUMP))
../../../../gcc-5.0.0-20150210/libgcc/libgcc2.c:405 439 {*p real_jump}
(nil))
../../../../gcc-5.0.0-20150210/libgcc/libgcc2.c:426:1: internal compiler error:
in extract_constrain_insn_cached, at recog.c:2258
0x885148 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-5.0.0-20150210/gcc/rtl-error.c:110
0x88516f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-5.0.0-20150210/gcc/rtl-error.c:121
0x85d159 extract_constrain_insn_cached(rtx_insn*)
../../gcc-5.0.0-20150210/gcc/recog.c:2258
0xb0cb77 internal_dfa_insn_code(rtx_insn*)
../../gcc-5.0.0-20150210/gcc/config/c6x/c6x.md:407
0xb0be79 dfa_insn_code
/data/fedora/cross-gcc/tmp/build/gcc/insn-automata.c:735634
0xb0be79 state_transition(void*, rtx_def*)
/data/fedora/cross-gcc/tmp/build/gcc/insn-automata.c:735655
0xbbe910 prune_ready_list
../../gcc-5.0.0-20150210/gcc/haifa-sched.c:6278
0xbbf907 prune_ready_list
../../gcc-5.0.0-20150210/gcc/haifa-sched.c:6193
0xbbf907 schedule_block(basic_block_def**, void*)
../../gcc-5.0.0-20150210/gcc/haifa-sched.c:6604
0xc14e06 schedule_ebb(rtx_insn*, rtx_insn*, bool)
../../gcc-5.0.0-20150210/gcc/sched-ebb.c:557
0xc15516 schedule_ebbs()
../../gcc-5.0.0-20150210/gcc/sched-ebb.c:676
0xb0435b c6x_reorg
../../gcc-5.0.0-20150210/gcc/config/c6x/c6x.c:5998
0x883fb9 execute
../../gcc-5.0.0-20150210/gcc/reorg.c:4064
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://bugzilla.redhat.com/bugzilla/ for instructions.
Makefile:466: recipe for target '_lshrdi3.o' failed
make[3]: *** [_lshrdi3.o] Error 1
make[3]: Leaving directory
'/data/fedora/cross-gcc/tmp/build/c6x-uclinux/be/libgcc'
[Bug c/65052] ICE in c6x-uclinux target when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65052
--- Comment #1 from dhowells at redhat dot com dhowells at redhat dot com ---
This can be produced by the following minimal source:
typedef int DItype __attribute__ ((mode (DI)));
typedef int shift_count_type __attribute__((mode (__libgcc_shift_count__)));
int __gnu_lshrdi3 (DItype u, shift_count_type b)
{
if (b == 0)
return u;
}
[Bug c/65052] ICE in c6x-uclinux target when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65052 --- Comment #3 from dhowells at redhat dot com dhowells at redhat dot com --- The compiler was built as: #!/bin/bash cd /data/fedora/cross-gcc/tmp/ tar xf /tmp/gcc-5.0.0-20150210.tar.bz2 mkdir build cd build CC=gcc \ CXX=g++ \ CFLAGS='-O2 -g -Wall -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic' \ CXXFLAGS=' -O2 -g -Wformat -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic ' \ CFLAGS_FOR_TARGET=' -O2 -g -Wall -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches ' \ AR_FOR_TARGET=/usr/bin/c6x-linux-gnu-ar \ AS_FOR_TARGET=/usr/bin/c6x-linux-gnu-as \ DLLTOOL_FOR_TARGET=/usr/bin/c6x-linux-gnu-dlltool \ LD_FOR_TARGET=/usr/bin/c6x-linux-gnu-ld \ NM_FOR_TARGET=/usr/bin/c6x-linux-gnu-nm \ OBJDUMP_FOR_TARGET=/usr/bin/c6x-linux-gnu-objdump \ RANLIB_FOR_TARGET=/usr/bin/c6x-linux-gnu-ranlib \ READELF_FOR_TARGET=/usr/bin/c6x-linux-gnu-readelf \ STRIP_FOR_TARGET=/usr/bin/c6x-linux-gnu-strip \ WINDRES_FOR_TARGET=/usr/bin/c6x-linux-gnu-windres \ WINDMC_FOR_TARGET=/usr/bin/c6x-linux-gnu-windmc \ LDFLAGS='-Wl,-z,relro ' \ nice -19 ../gcc-5.0.0-20150210/configure \ --bindir=/usr/bin \ --build=x86_64-redhat-linux-gnu \ --datadir=/usr/share \ --disable-decimal-float \ --disable-dependency-tracking \ --disable-gold \ --disable-libgcj \ --disable-libgomp \ --disable-libmudflap \ --disable-libquadmath \ --disable-libssp \ --disable-libunwind-exceptions \ --disable-nls \ --disable-plugin \ --disable-shared \ --disable-silent-rules \ --disable-sjlj-exceptions \ --disable-threads \ --with-ld=/usr/bin/c6x-linux-gnu-ld \ --enable-__cxa_atexit \ --enable-checking=release \ --enable-gnu-indirect-function \ --enable-gnu-unique-object \ --enable-initfini-array \ --enable-languages=c,c++ \ --enable-linker-build-id \ --enable-nls \ --enable-obsolete \ --enable-plugin \ --enable-targets=all \ --exec-prefix=/usr \ --host=x86_64-redhat-linux-gnu \ --includedir=/usr/include \ --infodir=/usr/share/info \ --libexecdir=/usr/libexec \ --localstatedir=/var \ --mandir=/usr/share/man \ --prefix=/usr \ --program-prefix=c6x-linux-gnu- \ --sbindir=/usr/sbin \ --sharedstatedir=/var/lib \ --sysconfdir=/etc \ --target=c6x-uclinux \ --with-bugurl=http://bugzilla.redhat.com/bugzilla/ \ --with-isl \ --with-linker-hash-style=gnu \ --with-newlib \ --with-sysroot=/usr/c6x-linux-gnu/sys-root \ --with-system-libunwind \ --with-system-zlib \ --without-headers echo === BUILDING c6x-linux AR_FOR_TARGET=/usr/bin/c6x-linux-gnu-ar \ AS_FOR_TARGET=/usr/bin/c6x-linux-gnu-as \ DLLTOOL_FOR_TARGET=/usr/bin/c6x-linux-gnu-dlltool \ LD_FOR_TARGET=/usr/bin/c6x-linux-gnu-ld \ NM_FOR_TARGET=/usr/bin/c6x-linux-gnu-nm \ OBJDUMP_FOR_TARGET=/usr/bin/c6x-linux-gnu-objdump \ RANLIB_FOR_TARGET=/usr/bin/c6x-linux-gnu-ranlib \ READELF_FOR_TARGET=/usr/bin/c6x-linux-gnu-readelf \ STRIP_FOR_TARGET=/usr/bin/c6x-linux-gnu-strip \ WINDRES_FOR_TARGET=/usr/bin/c6x-linux-gnu-windres \ WINDMC_FOR_TARGET=/usr/bin/c6x-linux-gnu-windmc \ nice -19 make tooldir=/usr all-gcc echo === BUILDING LIBGCC c6x-linux nice -19 make tooldir=/bin all-target-libgcc --- binutils-2.25 was used for the cross compiler. The compiler was built with: gcc version 4.9.2 20141101 (Red Hat 4.9.2-1) (GCC) binutils-2.24
[Bug c++/65054] [5 Regression] internal compiler error: in maybe_constant_value, at cp/constexpr.c:3646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65054 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-13 CC||mpolacek at gcc dot gnu.org Component|regression |c++ Target Milestone|--- |5.0 Summary|internal compiler error: in |[5 Regression] internal |maybe_constant_value, at|compiler error: in |cp/constexpr.c:3646 |maybe_constant_value, at ||cp/constexpr.c:3646 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug c++/65054] [5 Regression] internal compiler error: in maybe_constant_value, at cp/constexpr.c:3646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65054
--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
That typedef is not really necessary:
const char *
foo (void)
{
return ((char *const) abc + 1);
}
[Bug fortran/64933] ASSOCIATE on a character variable does not allow substring expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64933 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #3 from Paul Thomas pault at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) Up to revision r219797 (2015-01-17), I get the error pr64933.f90:5:31: ASSOCIATE(should_work=char_var) 1 Error: Associate-name 'should_work' at (1) is used as array Starting at r219823 (2015-01-18) I get the ICE. Likely a fall out of r219814 (pr55901). Please feel free to mark this PR as a 5.0 regression. Hmm! I am not sure that it can be regarded as a regression, since the original error was wrong. I agree that an ICE is worse -ish. I'll take it though, regression or not. Paul
[Bug tree-optimization/62209] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62209 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34748 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34748action=edit gcc5-pr62209.patch Untested fix.
[Bug c++/65051] [5 Regression] r210436 regression?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65051 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug testsuite/59971] multilib_flags is placed with the wrong order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59971 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-13 Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- It leads to FAIL: gcc.target/i386/pr32219-1.c scan-assembler movl[ \t]xxx@GOTOFF\\(%[^,]*\\), %eax FAIL: gcc.target/i386/pr32219-1.c scan-assembler-not movl[ \t]xxx@GOT\\(%[^,]*\\), %eax FAIL: gcc.target/i386/pr32219-3.c scan-assembler movl[ \t]xxx@GOTOFF\\(%[^,]*\\), %eax FAIL: gcc.target/i386/pr32219-3.c scan-assembler-not movl[ \t]xxx@GOT\\(%[^,]*\\), %eax FAIL: gcc.target/i386/pr32219-5.c scan-assembler movl[ \t]xxx@GOTOFF\\(%[^,]*\\), %eax FAIL: gcc.target/i386/pr32219-5.c scan-assembler-not movl[ \t]xxx@GOT\\(%[^,]*\\), %eax FAIL: gcc.target/i386/pr32219-7.c scan-assembler movl[ \t]xxx@GOTOFF\\(%[^,]*\\), %eax FAIL: gcc.target/i386/pr32219-7.c scan-assembler-not movl[ \t]xxx@GOT\\(%[^,]*\\), %eax FAIL: gcc.target/i386/pr64317.c scan-assembler movl[ \\t]+c@GOTOFF[(]%ebx[)] in https://gcc.gnu.org/ml/gcc-regression/2015-02/msg00244.html
[Bug target/61397] [4.9/5 regression] FAIL: gcc.target/powerpc/p8vector-ldst.c scan-assembler lxsdx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61397
--- Comment #2 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
Sorry, I have
[vmakarov@gcc2-power8 gcc]$ ./xgcc -B./
../../gcc/gcc/testsuite/gcc.target/powerpc/p8vector-ldst.c -O2 -S -mcpu=power8
-mupper-regs-df -mupper-regs-sf -m32 grep -c lxsdx p8vecto\
r-ldst.s
../../gcc/gcc/testsuite/gcc.target/powerpc/p8vector-ldst.c:1:0: error:
-mupper-regs-sf requires -mpower8-vector
/* { dg-do compile { target { powerpc*-*-* lp64 } } } */
^
I suppose the test should not work with this set of options as
make RUNTESTFLAGS='powerpc.exp=p8vector-ldst.c' check-gcc
gives
Running
/home/vmakarov/build/trunk/gcc/gcc/testsuite/gcc.target/powerpc/powerpc.exp ...
=== gcc Summary ===
# of unsupported tests 1
/home/vmakarov/build/trunk/build/gcc/xgcc version 5.0.0 20150213
(experimental) (GCC)
[Bug fortran/64506] FORMAT Parse Error with Continuation Line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64506 --- Comment #4 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Fri Feb 13 17:09:04 2015 New Revision: 220688 URL: https://gcc.gnu.org/viewcvs?rev=220688root=gccview=rev Log: 2015-02-13 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/64506 * gfortran.dg/continuation_13.f90: New test. * gfortran.dg/continuation_14.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/continuation_13.f90 trunk/gcc/testsuite/gfortran.dg/continuation_14.f Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/65051] [5 Regression] r210436 regression?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65051 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Fri Feb 13 16:02:31 2015 New Revision: 220685 URL: https://gcc.gnu.org/viewcvs?rev=220685root=gccview=rev Log: PR c++/65051 * call.c (reference_binding): Don't look for bad conversion if TO is incomplete. Added: trunk/gcc/testsuite/g++.dg/template/overload14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug ipa/65034] [5 Regression] ICE (segfault) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65034 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/65053] [5 Regression] PostgreSQL miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65053 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-13 Target Milestone|--- |5.0 Ever confirmed|0 |1
[Bug tree-optimization/65053] New: [5 Regression] PostgreSQL miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65053
Bug ID: 65053
Summary: [5 Regression] PostgreSQL miscompilation
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Following testcase is miscompiled at -O2 starting with r220164:
int i;
__attribute__ ((noinline))
unsigned int foo (void)
{
return 0;
}
int
main ()
{
unsigned int u = -1;
if (u == -1)
{
unsigned int n = foo ();
if (n 0)
u = n - 1;
}
while (u != -1)
{
asm ( : +g (u));
u = -1;
i = 1;
}
if (i)
__builtin_abort ();
return 0;
}
[Bug rtl-optimization/63491] Ice in LRA with simple vector test case on power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63491 --- Comment #5 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Sorry, I can not reproduce the bug on the today trunk. Probably it was fixed by numerous changes in LRA since Oct.
[Bug regression/65054] New: internal compiler error: in maybe_constant_value, at cp/constexpr.c:3646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65054
Bug ID: 65054
Summary: internal compiler error: in maybe_constant_value, at
cp/constexpr.c:3646
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: holger.hopp at sap dot com
following code throws an internal compiler error with g++-5.0 (gcc-5.0 works):
typedef char * CP;
const char * foo (void)
{
return ((const CP)abc+1);
}
$ g++ -c tst.c
tst.c: In function ‘const char* foo()’:
tst.c:5:28: internal compiler error: in maybe_constant_value, at
cp/constexpr.c:3646
return ((const CP)abc+1);
^
0x83d85d maybe_constant_value(tree_node*, tree_node*)
../../gcc/gcc/cp/constexpr.c:3642
0x78a0bc cp_convert_and_check(tree_node*, tree_node*, int)
../../gcc/gcc/cp/cvt.c:639
0x636331 convert_like_real
../../gcc/gcc/cp/call.c:6565
0x63721c perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/call.c:9405
0x7779e3 check_return_expr(tree_node*, bool*)
../../gcc/gcc/cp/typeck.c:8713
0x7b217e finish_return_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:887
0x735bc8 cp_parser_jump_statement
../../gcc/gcc/cp/parser.c:11061
0x735bc8 cp_parser_statement
../../gcc/gcc/cp/parser.c:9711
0x736162 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:10099
0x7362bb cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:10053
0x74b03b cp_parser_function_body
../../gcc/gcc/cp/parser.c:19185
0x74b03b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:19221
0x7558ba cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:23464
0x756733 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:23376
0x756733 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:17055
0x757ccc cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11592
0x758023 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11466
0x760599 cp_parser_declaration
../../gcc/gcc/cp/parser.c:11363
0x76081a cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:11249
0x760b2f cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4100
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug tree-optimization/65053] [5 Regression] PostgreSQL miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65053 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- I believe this is a phiopt1 bug. In *.ifcombine we have: bb 2: n_5 = foo (); if (n_5 != 0) goto bb 3; else goto bb 4; bb 3: # RANGE [0, 4294967294] u_6 = n_5 + 4294967295; bb 4: # u_3 = PHI u_6(3), 4294967295(2) goto bb 6; which looks right, for non-zero n_5 u_6 really is != 0xU. But then *.phiopt optimizes this into: bb 2: n_5 = foo (); # RANGE [0, 4294967294] u_6 = n_5 + 4294967295; goto bb 4; which is wrong, either it should have adjusted the value range or drop it when making u_6 unconditional. What r220164 did is just start using the VR information during the next VRP pass, but as the info is bogus due to phiopt, it resulted in wrong optimization later on.
[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org ---
OK, so here are my findings. Switching off IPA-CP helps because the
pass then does not propagate polymorphic context from
_ZN8MySoPlexC2EN6soplex6SoPlex4TypeENS1_14RepresentationE/5887 to
_ZN6soplex9SPxSolverC2ENS_6SoPlex4TypeENS1_14RepresentationE/51162
(both are constructors) for the 0th parameter. This propagation
clears the dynamic flag and speculation from the context on the edge
and the result is stored to a lattice describing the callee.
Later on, inlining comes along and calls ipa_context_from_jfunc which
picks up this value from the lattice and uses it as a base for a jump
function on the edge being inlined. In this process, it also checks
for dynamic type changes in constructors and destructors but
apparently it relies on edge flag in_polymorphic_cdtor being correct.
And that is the problem, apparently it is not. When we are inlining
into a function that has itself already been inlined into the
constructor, the flag is false, although we are basing jump function
calculations on lattices corresponding to the constructor.
Therefore I'd suggest the following fix. (Alternatively we could
easily do this propagation in update_jump_functions_after_inlining,
without introducing another recursion.)
2015-02-13 Martin Jambor mjam...@suse.cz
PR ipa/65028
* ipa-inline-transform.c (mark_all_inlined_calls_cdtor): New function.
(inline_call): Use it.
diff --git a/gcc/ipa-inline-transform.c b/gcc/ipa-inline-transform.c
index 235219d..61229ac 100644
--- a/gcc/ipa-inline-transform.c
+++ b/gcc/ipa-inline-transform.c
@@ -261,6 +261,21 @@ clone_inlined_nodes (struct cgraph_edge *e, bool
duplicate,
}
}
+/* Mark all call graph edges coming out of NODE and all nodes that have been
+ inlined to it as in_polymorphic_cdtor. */
+
+static void
+mark_all_inlined_calls_cdtor (cgraph_node *node)
+{
+ for (cgraph_edge *cs = node-callees; cs; cs = cs-next_callee)
+{
+ cs-in_polymorphic_cdtor = true;
+ if (!cs-inline_failed)
+mark_all_inlined_calls_cdtor (cs-callee);
+}
+ for (cgraph_edge *cs = node-indirect_calls; cs; cs = cs-next_callee)
+cs-in_polymorphic_cdtor = true;
+}
/* Mark edge E as inlined and update callgraph accordingly. UPDATE_ORIGINAL
specify whether profile of original function should be updated. If any new
@@ -332,6 +347,8 @@ inline_call (struct cgraph_edge *e, bool update_original,
old_size = inline_summaries-get (to)-size;
inline_merge_summary (e);
+ if (e-in_polymorphic_cdtor)
+mark_all_inlined_calls_cdtor (e-callee);
if (opt_for_fn (e-caller-decl, optimize))
new_edges_found = ipa_propagate_indirect_call_infos (curr, new_edges);
if (update_overall_summary)
[Bug c/65052] ICE in c6x-uclinux target when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65052 --- Comment #2 from dhowells at redhat dot com dhowells at redhat dot com --- Compiled with: /data/fedora/cross-gcc/tmp/build/./gcc/xgcc -B/data/fedora/cross-gcc/tmp/build/gcc/ -B/usr/c6x-uclinux/bin/ -O2 -c min.i
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 --- Comment #3 from paul.richard.thomas at gmail dot com paul.richard.thomas at gmail dot com --- Dear Uros and Dominique, I'll try to get to this when I can. I have a horrible feeling that it is the old problem of array constructors within array constructors all of which are allocatable components. I have stared and stared at this one and have not found the fault. All the best Paul PS I have marked the message as being 'unread' as a reminder :-) On 13 February 2015 at 11:37, dominiq at lps dot ens.fr gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-13 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Compelling the test with -fsanitize=address leads to an error at run time. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug lto/65015] LTO produces randomly ordered debug information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65015 --- Comment #14 from rguenther at suse dot de rguenther at suse dot de --- On February 13, 2015 2:42:45 PM CET, hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65015 --- Comment #13 from H.J. Lu hjl.tools at gmail dot com --- We are generating .filecc8zpoWj.ltrans0.o ^ We shouldn't do it. Huh, but then my patch should have worked. Maybe I botched testing. .text .Ltext0: .typehelper, @function helper: .LFB0: .file 1 dependency.c
[Bug fortran/64506] FORMAT Parse Error with Continuation Line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64506 --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Fri Feb 13 16:57:28 2015 New Revision: 220687 URL: https://gcc.gnu.org/viewcvs?rev=220687root=gccview=rev Log: 2015-02-13 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/64506 * scanner.c (gfc_next_char_literal): For free form source, check for '!' and if found, clear the comment and go back and get the next character. For fixed form source, skip the rest of the line. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/scanner.c
[Bug c++/65054] [5 Regression] internal compiler error: in maybe_constant_value, at cp/constexpr.c:3646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65054 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r219973.
[Bug target/61397] [4.9/5 regression] FAIL: gcc.target/powerpc/p8vector-ldst.c scan-assembler lxsdx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61397 --- Comment #3 from Andreas Schwab sch...@linux-m68k.org --- c9f03f9b6e7a888a270638c07190513189f8c33d
[Bug c++/65055] New: Types and variables differ in handling of multiple instances of attribute aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65055
Bug ID: 65055
Summary: Types and variables differ in handling of multiple
instances of attribute aligned
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
When multiple instances of the aligned attribute are applied to the same
entity, the handling for types uses the last value whereas the handling for
variables uses the most restrictive value.
Clang uses the most restrictive value (which seems to make sense) for both
cases.
### SOURCE (stdin):
struct __attribute__ ((aligned(32), aligned(16) )) A
{
} __attribute__ ((aligned(32), aligned(16) ));
extern int x __attribute__ ((aligned(32), aligned(16) ));
extern int chk[32];
extern int chk[__alignof__(x)];
extern int chk[__alignof__(struct A)];
### COMPILER INVOCATION:
gcc -c -xc++ -
### ACTUAL OUTPUT:
stdin:9:37: error: conflicting declaration 'int chk [16]'
stdin:8:12: note: previous declaration as 'int chk [32]'
### EXPECTED OUTPUT:
(Clean compile)
### COMPILER VERSION INFO:
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-head/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/heads/gcc/gcc-source/configure
--prefix=/usr/local/gcc-head --enable-languages=c,c++ --enable-lto
--disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release
--disable-nls
Thread model: posix
gcc version 5.0.0 20150212 (experimental) (GCC)
[Bug lto/65015] LTO produces randomly ordered debug information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65015 --- Comment #15 from H.J. Lu hjl.tools at gmail dot com --- I opened: https://sourceware.org/bugzilla/show_bug.cgi?id=17973
[Bug middle-end/65048] [5 Regression] ICE in add_phi_args_after_copy_edge, at tree-cfg.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65048 --- Comment #2 from Sebastian Pop spop at gcc dot gnu.org --- Created attachment 34750 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34750action=edit fix We used to attempt to jump thread this path that is not connex: FSM jump thread: (7, 10) (13, 14) This is because we collect all the jump thread paths before doing code generation, and so once we start code generating the jump threads, the CFG changes. The attached patch checks for valid jump threads before code generating them. I'm testing the patch and if it passes bootstrap I will send it to gcc-patches with an apropriate changelog.
[Bug rtl-optimization/65056] New: Missed optimization (x86): Redundant test/compare after arithmetic operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65056
Bug ID: 65056
Summary: Missed optimization (x86): Redundant test/compare
after arithmetic operations
Product: gcc
Version: 5.0
URL: http://marc.info/?l=linux-kernelm=142373514630907
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at horizon dot com
Host: i586-linux-gnu
Target: x86_64-*-*, i?86-*-*
The following code seems to miss some really obvious optimizations on
x86, both in -m32 and -m64. Gcc is generating separate test compare
instruction for conditions which are available in the condition codes set by
preceding arithmetic operations.
Bugs #30455 and #31799 are similar, but the problems there are caused by a
memory destination, which isn't the case here.
This happens with -O2, -O3 and -Os and with various models specified, so it
doesn't appear to be some obscure model-specific optimization.
Versions tested:
* gcc (Debian 4.9.2-10) 4.9.2
* gcc-5 (Debian 5-20150205-1) 5.0.0 20150205 (experimental) [trunk revision
220455]
* gcc (Debian 20150211-1) 5.0.0 20150211 (experimental) [trunk revision 220605]
#include stddef.h
#define BITS_PER_LONG (8 * sizeof(long))
#define DIV_ROUND_UP(x,n) (((x) + (n) - 1) / (n))
#define LAST_WORD_MASK(x) (~0ull (-(x) BITS_PER_LONG - 1))
/*
* __fls: find last set bit in word
* @word: The word to search
*
* Undefined if no set bit exists, so code should check against 0 first.
*/
static inline unsigned long __fls(unsigned long word)
{
asm(bsr %1,%0
: =r (word)
: rm (word));
return word;
}
size_t find_last_bit(const unsigned long *addr, size_t size)
{
size_t idx = DIV_ROUND_UP(size, BITS_PER_LONG);
unsigned long mask = LAST_WORD_MASK(size);
while (idx--) {
unsigned long val = addr[idx] mask;
if (val)
return idx * BITS_PER_LONG + __fls(val);
mask = ~0ul;
}
return size;
}
The code generated is (-m32 is equivalent):
.fileflb.c
.section.text.unlikely,ax,@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globlfind_last_bit
.typefind_last_bit, @function
find_last_bit:
.LFB1:
.cfi_startproc
movl%esi, %ecx
leaq63(%rsi), %rdx
movq$-1, %r8
negl%ecx
shrq%cl, %r8
shrq$6, %rdx
movq%r8, %rcx
jmp.L2
.p2align 4,,10
.p2align 3
.L4:
andq(%rdi,%rdx,8), %rcx
movq%rcx, %r8
movq$-1, %rcx
testq%r8, %r8
jne.L8
.L2:
subq$1, %rdx
cmpq$-1, %rdx
jne.L4
movq%rsi, %rax
ret
.p2align 4,,10
.p2align 3
.L8:
salq$6, %rdx
#APP
# 15 flb.c 1
bsr %r8,%r8
# 0 2
#NO_APP
leaq(%rdx,%r8), %rax
ret
.cfi_endproc
.LFE1:
.sizefind_last_bit, .-find_last_bit
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.identGCC: (Debian 20150211-1) 5.0.0 20150211 (experimental) [trunk
revision 220605]
.section.note.GNU-stack,,@progbits
In the loop at .L4, there's a completely unnecessary movq %rcx, %r8;
testq %r8, %r8, when the jne could go right after the andq (and the
code at .L8 changed to expect the masked value in %rcx rather than %r8).
At .L2, it's even more ridiculous. The subq generates a borrow if the value
wraps to -1. Why is that not just subq $1, %rdx; jnc .L4?
A smarter compiler would notice that %rdx must have its top 6 bits clear
and thus decq %rdx; jpl .L4 would also be legal. (For non-x86 weenies,
the dec instructions do not modify the carry flag, originally so they
could be used for loop control in multi-word arithmetic. This partial flags
update makes them slower than subq $1 on many processors, so which is used
depends on the model flags.)
I tried reorganizing the source to encourage the first optimization:
size_t find_last_bit2(const unsigned long *addr, size_t size)
{
unsigned long val = LAST_WORD_MASK(size);
size_t idx = DIV_ROUND_UP(size, BITS_PER_LONG);
while (idx--) {
val = addr[idx];
if (val)
return idx * BITS_PER_LONG + __fls(val);
val = ~0ul;
}
return size;
}
... but the generated code is identical.
This version:
size_t find_last_bit3(const unsigned long *addr, size_t size)
{
if (size) {
unsigned long val = LAST_WORD_MASK(size);
size_t idx = (size-1) / BITS_PER_LONG;
do {
val = addr[idx];
if (val)
return idx * BITS_PER_LONG + __fls(val);
val = ~0ul;
} while (idx--);
}
return size;
}
Makes the first optimziation, and is at least clever with the second, but it's
still three instructions rather than two for an absolutely bog-standard
decrement loop:
find_last_bit3:
.LFB3:
.cfi_startproc
[Bug c++/65054] [5 Regression] internal compiler error: in maybe_constant_value, at cp/constexpr.c:3646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65054 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org
[Bug target/61397] [4.9/5 regression] FAIL: gcc.target/powerpc/p8vector-ldst.c scan-assembler lxsdx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61397 --- Comment #4 from Michael Meissner meissner at gcc dot gnu.org --- I put a LP64 on the test, because it was using 64-bit shifts in order to force registers to be allocated from the Altivec register set. If you compile it in 32-bit mode, the emulation of 64-bit shifts/masks can complicate things.
[Bug c++/60211] [4.9 Regression] ICE with #pragma GCC ivdep and for-loop on global scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60211 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|paolo.carlini at oracle dot com| Resolution|--- |FIXED Target Milestone|4.9.3 |5.0 Summary|[4.9/5 Regression] ICE with |[4.9 Regression] ICE with |#pragma GCC ivdep and |#pragma GCC ivdep and |for-loop on global scope|for-loop on global scope --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 5.0. I don't think it's worth fiddling with the release branch at this point. If somebody really cares, the patch can be backported, anyway.
[Bug regression/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812 Anthony G. Basile basile at opensource dot dyc.edu changed: What|Removed |Added CC||basile at opensource dot dyc.edu --- Comment #4 from Anthony G. Basile basile at opensource dot dyc.edu --- (In reply to Luke from comment #0) LibreOffice 4.2 or newer fails to build in a clean build environment on Linux x86-32 with gcc 4.9.0, 4.9.1, and 4.9.2. However, the build succeeds on an otherwise identical x86-64 system, and it also succeeds with gcc 4.8.2 (on x86-32 and x86-64). The build also succeeds with clang 3.4 (on x86-32 and x86-64). We are seeing this in gentoo on x86_64 with gcc-4.9. See https://bugs.gentoo.org/show_bug.cgi?id=538348 (In reply to Timo Teräs from comment #3) As a workaround removing -fvisibility-inlines-hidden from the build flags, makes things work in the libreoffice. What's confusing me is that some of our users are seeing this bug and others are not. This leads me to think maybe its a c++ abi mismatch because we do allow our users to build their systems using any recent version of gcc (and c++ abi emitted by 4.8 is not compatbile with that emitted by 4.9). However, that fact tat removing -fvisibility-inlines-hidden fixes this argues against my suspicion. So why would some of our users it this and others not?
[Bug tree-optimization/65053] [5 Regression] PostgreSQL miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65053 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34749 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34749action=edit gcc5-pr65053.patch Untested fix.
[Bug c++/60211] [4.9/5 Regression] ICE with #pragma GCC ivdep and for-loop on global scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60211 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Fri Feb 13 17:57:13 2015 New Revision: 220689 URL: https://gcc.gnu.org/viewcvs?rev=220689root=gccview=rev Log: /cp 2015-02-13 Paolo Carlini paolo.carl...@oracle.com PR c++/60211 * parser.c (cp_parser_pragma): Diagnose PRAGMA_IVDEP at pragma_external context. /testsuite 2015-02-13 Paolo Carlini paolo.carl...@oracle.com PR c++/60211 * g++.dg/parse/ivdep-2.C: New. * g++.dg/parse/ivdep-3.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/parse/ivdep-2.C trunk/gcc/testsuite/g++.dg/parse/ivdep-3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/65053] [5 Regression] PostgreSQL miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65053 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug fortran/63744] [4.8/4.9/5 Regression] Duplicate use-statement causes error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63744 --- Comment #10 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Fri Feb 13 18:48:35 2015 New Revision: 220690 URL: https://gcc.gnu.org/viewcvs?rev=220690root=gccview=rev Log: Use the local name instead of the original name in the check for name conflicts between a hosting program unit and use-associated symbols in that program unit. fortran/ PR fortran/63744 * module.c (check_for_ambiguous): Change argument type from gfc_symbol to gfc_symtree. Check local (symtree) name instead of original (symbol) name. (read_module): Update caller. testsuite/ PR fortran/63744 gfortran.dg/use_rename_8.f90: New. Added: branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/use_rename_8.f90 Modified: branches/gcc-4_9-branch/gcc/fortran/ChangeLog branches/gcc-4_9-branch/gcc/fortran/module.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug fortran/63744] [4.8/4.9/5 Regression] Duplicate use-statement causes error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63744 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Mikael Morin mikael at gcc dot gnu.org --- Fixed for versions 5.0, 4.9.3, 4.8.5 Closing. Thanks for the report.
[Bug lto/65015] LTO produces randomly ordered debug information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65015
--- Comment #17 from H.J. Lu hjl.tools at gmail dot com ---
This patch works wit the existing linker:
diff --git a/gcc/varasm.c b/gcc/varasm.c
index 0211306..f3241a8 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -7043,7 +7043,12 @@ default_file_start (void)
fputs (ASM_APP_OFF, asm_out_file);
if (targetm.asm_file_start_file_directive)
-output_file_directive (asm_out_file, main_input_filename);
+{
+ if (in_lto_p)
+ output_file_directive (asm_out_file, artificial);
+ else
+ output_file_directive (asm_out_file, main_input_filename);
+}
}
/* This is a generic routine suitable for use as TARGET_ASM_FILE_END
[Bug rtl-optimization/47477] [4.8/4.9 regression] Sub-optimal mov at end of method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com Summary|[4.8/4.9/5 regression] |[4.8/4.9 regression] |Sub-optimal mov at end of |Sub-optimal mov at end of |method |method --- Comment #22 from Jeffrey A. Law law at redhat dot com --- Patch to match.pd fixes the regresssion on the trunk. Will be opening a separate BZ for the missed optimizations. Given the fix depends on the match.pd functionality, I don't see any chance we'll ever backport this to the release branches.
[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org --- Fixed.
[Bug c++/60211] [4.9 Regression] ICE with #pragma GCC ivdep and for-loop on global scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60211 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Agreed, we usually don't backport fixes for invalid-code bugs.
[Bug rtl-optimization/47477] [4.8/4.9/5 regression] Sub-optimal mov at end of method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477 --- Comment #21 from Jeffrey A. Law law at gcc dot gnu.org --- Author: law Date: Fri Feb 13 20:17:55 2015 New Revision: 220695 URL: https://gcc.gnu.org/viewcvs?rev=220695root=gccview=rev Log: PR rtl-optimization/47477 * match.pd (convert (plus/minus (convert @0) (convert @1): New simplifier to narrow arithmetic. PR rtl-optimization/47477 * gcc.dg/tree-ssa/pr47477.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr47477.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug fortran/63744] [4.8/4.9/5 Regression] Duplicate use-statement causes error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63744 --- Comment #11 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Fri Feb 13 19:33:27 2015 New Revision: 220692 URL: https://gcc.gnu.org/viewcvs?rev=220692root=gccview=rev Log: Use the local name instead of the original name in the check for name conflicts between a hosting program unit and use-associated symbols in that program unit. fortran/ PR fortran/63744 * module.c (check_for_ambiguous): Change argument type from gfc_symbol to gfc_symtree. Check local (symtree) name instead of original (symbol) name. (read_module): Update caller. testsuite/ PR fortran/63744 gfortran.dg/use_rename_8.f90: New. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/use_rename_8.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/module.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug fortran/64980] [5 Regression] ICE in trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980 --- Comment #9 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to Bernd Edlinger from comment #8) I will post this new patch, which combines Mikael's patch and fixes class_41.f03 and these test cases, Actually, my patch was not supposed to be a real fix, rather a tip telling where to look at. (In reply to Bernd Edlinger from comment #8) The call of get_d_position is now rewritten as follows: this.22 = VIEW_CONVERT_EXPRstruct __class_muli_trapezium_Muli_trapezium_t_t(node); D.3752 = node._vptr-get_d_position (this.22); this.23 = VIEW_CONVERT_EXPRstruct __class_muli_trapezium_Muli_trapezium_t_t(node); D.3754 = this.23; D.3755 = D.3754-_data-dim; D.3756 = (integer(kind=8)) D.3755 + -1; It seems to me that the second VIEW_CONVERT_EXPR is not necessary. If that's correct, there should be two references, one through VIEW_CONVERT_EXPR for the function call, and one without VIEW_CONVERT_EXPR to use for interface mapping (to get the resulting size).
[Bug fortran/64980] [5 Regression] ICE in trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980 --- Comment #8 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 34751 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34751action=edit Proposed Fix OK, now I see the original test case exposes an aliasing violation when node is passed to node._vptr-get_d_position(node) struct __class_muli_trapezium_Muli_trapezium_node_class_t_p node; but muli_trapezium_get_d_position (struct __class_muli_trapezium_Muli_trapezium_t_t restrict this) So my previous patch is just not aggressive enough. How about the attached patch, which looks like it simplifies the code. I will post this new patch, which combines Mikael's patch and fixes class_41.f03 and these test cases, by rewriting _all_ cases where the class type is different, either because of different attributes, or because of a derived base type even when the other attributes are identical as in class_41.f03. The call of get_d_position is now rewritten as follows: this.22 = VIEW_CONVERT_EXPRstruct __class_muli_trapezium_Muli_trapezium_t_t(node); D.3752 = node._vptr-get_d_position (this.22); this.23 = VIEW_CONVERT_EXPRstruct __class_muli_trapezium_Muli_trapezium_t_t(node); D.3754 = this.23; D.3755 = D.3754-_data-dim; D.3756 = (integer(kind=8)) D.3755 + -1; Given the complexity of the generated code, it would be good to have a positive test, instead of a compile-only test. Could you please propose a positive test case for this? Thanks, Bernd.
[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Fri Feb 13 20:05:39 2015 New Revision: 220694 URL: https://gcc.gnu.org/viewcvs?rev=220694root=gccview=rev Log: PR ipa/65028 * ipa-prop.c (update_indirect_edges_after_inlining): Do not drop polymorphic call info when type is not known to be preserved. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c
[Bug bootstrap/65060] New: [5 Regression] r220696 breaks bootstrap on Linux/x86-32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65060 Bug ID: 65060 Summary: [5 Regression] r220696 breaks bootstrap on Linux/x86-32 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: law at redhat dot com On Linux/x86-32, r220696 gave make[6]: Leaving directory `/export/gnu/import/git/gcc-test-ia32corei7/bld' Comparing stages 2 and 3 warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/gimple-fold.o differs gcc/tree-ssa-pre.o differs gcc/omp-low.o differs gcc/i386.o differs gcc/tree-ssa-sccvn.o differs gcc/tree-ssa-threadupdate.o differs gcc/tree-ssa-uninit.o differs gcc/cfgexpand.o differs gcc/objc/objc-act.o differs gcc/tree-ssa-operands.o differs gcc/sel-sched-ir.o differs gcc/tree-into-ssa.o differs gcc/java/expr.o differs gcc/ree.o differs gcc/sanopt.o differs gcc/sese.o differs gcc/cfgrtl.o differs gcc/reg-stack.o differs gcc/ira-emit.o differs gcc/tree-ssa-loop-im.o differs gcc/tree-emutls.o differs gcc/tree-ssa-reassoc.o differs gcc/c/c-parser.o differs gcc/c/c-typeck.o differs gcc/gimplify.o differs gcc/tree-ssa-loop-ivopts.o differs gcc/tree-if-conv.o differs gcc/lto-cgraph.o differs gcc/cfgloopanal.o differs gcc/tree-cfgcleanup.o differs gcc/tree-outof-ssa.o differs gcc/ipa-cp.o differs gcc/lower-subreg.o differs gcc/tree-ssa-loop-unswitch.o differs gcc/dojump.o differs gcc/ipa-polymorphic-call.o differs gcc/function.o differs gcc/ubsan.o differs gcc/cfganal.o differs gcc/tree-ssa-live.o differs gcc/fwprop.o differs gcc/tree-complex.o differs gcc/tree-vect-stmts.o differs gcc/tree-ssa-structalias.o differs gcc/build/genautomata.o differs gcc/build/genpreds.o differs gcc/build/genmatch.o differs gcc/final.o differs gcc/ipa-utils.o differs gcc/tree-vect-slp.o differs gcc/rtlanal.o differs gcc/lto/lto-partition.o differs gcc/c-family/array-notation-common.o differs gcc/ipa-inline.o differs gcc/tree-loop-distribution.o differs gcc/tree-ssa-ccp.o differs gcc/wide-int.o differs gcc/bb-reorder.o differs gcc/tree-object-size.o differs gcc/tree-ssa-loop-niter.o differs gcc/tree-predcom.o differs gcc/tree-ssa-ter.o differs gcc/cp/init.o differs gcc/cp/decl.o differs gcc/cp/pt.o differs gcc/cp/class.o differs gcc/cp/name-lookup.o differs gcc/cp/error.o differs gcc/cp/vtable-class-hierarchy.o differs gcc/tree-ssa-loop-ch.o differs gcc/tree-ssa-threadedge.o differs gcc/ipa-icf.o differs gcc/tree-inline.o differs libcpp/macro.o differs make[5]: *** [compare] Error 1 when configured with --with-arch=corei7 --with-cpu=corei7 --prefix=/usr/5.0.0 --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld i686-linux --with-fpmath=sse --enable-languages=c,c++,fortran,java,lto,objc
[Bug tree-optimization/65053] [5 Regression] PostgreSQL miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65053 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
