[Bug debug/71864] x86_64-w64-mingw32, ICE when '-Og' & '-mssse3' are used simultaneously
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71864 Markus Trippelsdorf changed: What|Removed |Added Target||i686-w64-mingw32 --- Comment #4 from Markus Trippelsdorf --- Please mention the target in future bug reports.
[Bug target/71873] ICE in push_reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71873 Senthil Kumar Selvaraj changed: What|Removed |Added Target||avr Assignee|unassigned at gcc dot gnu.org |saaadhu at gcc dot gnu.org Target Milestone|--- |7.0
[Bug target/71873] New: ICE in push_reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71873
Bug ID: 71873
Summary: ICE in push_reload
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: saaadhu at gcc dot gnu.org
Target Milestone: ---
The following testcase causes an ICE in push_reload when compiled with
$ cat test.c
#include
typedef struct {
uint8_t x;
uint32_t y;
} A;
A a;
extern int bar(int);
extern int foo (char *s, ...);
extern uint8_t param;
extern uint8_t h,m,s,ld,lm;
extern uint16_t d;
void gps_parse_string(int z)
{
while (bar(z))
{
switch (param)
{
case 0: foo("a", &h, &m, &s, &d); break;
case 1: foo("d", &ld, &lm, &a.y); break;
}
}
}
$ avr-gcc -Os -mmcu=atmega8 -S test.c
test.c: In function 'gps_parse_string':
test.c:27:1: internal compiler error: in push_reload, at reload.c:1349
}
^
0xd8feb0 push_reload(rtx_def*, rtx_def*, rtx_def**, rtx_def**, reg_class,
machine_mode, machine_mode, int, int, int, reload_type)
/home/saaadhu/code/work/gcc/gcc/reload.c:1348
0xd8f760 push_reload(rtx_def*, rtx_def*, rtx_def**, rtx_def**, reg_class,
machine_mode, machine_mode, int, int, int, reload_type)
/home/saaadhu/code/work/gcc/gcc/reload.c:1155
0xd97e86 find_reloads(rtx_insn*, int, int, int, short*)
/home/saaadhu/code/work/gcc/gcc/reload.c:4035
0xda58d4 calculate_needs_all_insns
/home/saaadhu/code/work/gcc/gcc/reload1.c:1483
0xda4018 reload(rtx_insn*, int)
/home/saaadhu/code/work/gcc/gcc/reload1.c:995
0xc0865e do_reload
/home/saaadhu/code/work/gcc/gcc/ira.c:5396
0xc08a46 execute
/home/saaadhu/code/work/gcc/gcc/ira.c:5568
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
Might be a duplicate of PR 67031, but the testcases there do not cause an ICE
on trunk (gcc version 7.0.0 20160704), but the above one does.
[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71867 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-07-14 Component|c++ |tree-optimization Ever confirmed|0 |1
[Bug tree-optimization/71872] ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71872
Jakub Jelinek changed:
What|Removed |Added
CC|dodji at gcc dot gnu.org, |
|dvyukov at gcc dot gnu.org,|
|kcc at gcc dot gnu.org |
Component|sanitizer |tree-optimization
--- Comment #2 from Jakub Jelinek ---
This has nothing to do with sanitizers, it seems tree-data-ref.c is buggy and
creates invalid trees (ADDR_EXPR of INTEGER_CST) when processing the rhs of
MEM[(union gasnete_anytype32_t * {ref-all})_dst_11] = VIEW_CONVERT_EXPR(1);
Such VCE obviously is not a DR.
[Bug tree-optimization/71866] [7 Regression] gcc locks up after fix for PR70159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71866 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-07-14 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |7.0 Summary|gcc locks up after fix for |[7 Regression] gcc locks up |PR70159 |after fix for PR70159 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Investigating.
[Bug testsuite/71865] [7 regression] test case gcc.dg/diagnostic-token-ranges.c fails starting with r237714
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71865 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104 --- Comment #14 from Bernd Edlinger --- One question though... This depends on a special knowledge about "vfork", but it seems that gcc does not honor -ffreestanding correctly in this case, because: gcc -ffreestanding pr71104-1.c should not have crashed (before your patch, but it did).
[Bug fortran/70842] [4.9/5/6/7 Regression] internal compiler error with character members within a polymorphic pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70842 --- Comment #6 from nathanael.huebbe at informatik dot uni-hamburg.de --- (In reply to kargl from comment #5) > With the patch I posted earlier today and code in comment #1, I see > > gfc7 -c a.f90 > a.f90:14:30: > > print*, len(me%string) > 1 > Error: Data transfer element at (1) cannot be polymorphic unless it > is processed by a defined input/output procedure > > I don't use CLASS and know little about its expected behavior. > Is the above even remotely right? I don't think so, but I may be wrong since I'm not an expert when it comes to the FORTRAN standard. The error sounds weird to me, because I would not consider `me%string` to be polymorphic to begin with, and because the value that is printed is the result of the `len()` intrinsic, which is just a non-polymorphic `integer`. Even the type of `me` is known precisely at this point since the statement appears within a `type is()` clause. What I would naively expect is that the code * compiles without error or warning (the issue in comment #1), and that it * prints the correct length of the string (the issue in comment #3). (I do hope my expectations are not in conflict with the standard...)
[Bug fortran/70842] [4.9/5/6/7 Regression] internal compiler error with character members within a polymorphic pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70842 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #7 from vehre at gcc dot gnu.org --- Hi Karl, (In reply to kargl from comment #5) > With the patch I posted earlier today and code in comment #1, I see which patch are you referring to? At least upto now I don't see a patch from you on the list or in this PR. > > gfc7 -c a.f90 > a.f90:14:30: > > print*, len(me%string) > 1 > Error: Data transfer element at (1) cannot be polymorphic unless it > is processed by a defined input/output procedure > > I don't use CLASS and know little about its expected behavior. > Is the above even remotely right? Not at all. That call to len() should map to me%.string giving the length of the string. (Note the dot in front of string; gfortran internal convention to store string length).
[Bug c++/71874] New: memmove works wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71874 Bug ID: 71874 Summary: memmove works wrong Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sudakov_ivan at mail dot ru Target Milestone: --- Created attachment 38896 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38896&action=edit Code to reproduce bug Environment: uname -a Linux 4.1.13-100.fc21.x86_64 #1 SMP Tue Nov 10 13:13:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux g++ --version g++ (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6) Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. How to reproduce: 1. Compile code: g++ memmove_bug.cpp (example from here: http://www.cplusplus.com/reference/cstring/memmove/). File in attachment. 2. Run. Expected result: memmove can be very useful.. memmove can be very very useful. actual result: memmove can be very useful.. memmove can be very very usey u.
[Bug c++/71874] memmove works wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71874 --- Comment #1 from Andrew Pinski --- Comment on attachment 38896 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38896 Code to reproduce bug Memmove comes from libc and in this case you got libc from redhat so you should report the bug to redhat.
[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104 --- Comment #15 from rguenther at suse dot de --- On Thu, 14 Jul 2016, bernd.edlinger at hotmail dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104 > > --- Comment #14 from Bernd Edlinger --- > One question though... > > This depends on a special knowledge about "vfork", > but it seems that gcc does not honor -ffreestanding > correctly in this case, because: > > gcc -ffreestanding pr71104-1.c > > should not have crashed (before your patch, but it did). Even with -ffreestanding we handle some functions conservatively. See special_function_p.
[Bug c/71858] Surprising suggestions for misspellings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71858 --- Comment #3 from Jakub Jelinek --- Created attachment 38897 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38897&action=edit gcc7-pr71858-1.patch Untested patch for the first issue.
[Bug c/71858] Surprising suggestions for misspellings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71858 --- Comment #4 from Jakub Jelinek --- Created attachment 38898 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38898&action=edit gcc7-pr71858-2.patch And for the second issue.
[Bug target/71873] ICE in push_reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71873 Senthil Kumar Selvaraj changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-07-14 Ever confirmed|0 |1
[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104
--- Comment #16 from Bernd Edlinger ---
(In reply to rguent...@suse.de from comment #15)
> On Thu, 14 Jul 2016, bernd.edlinger at hotmail dot de wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104
> >
> > --- Comment #14 from Bernd Edlinger ---
> > One question though...
> >
> > This depends on a special knowledge about "vfork",
> > but it seems that gcc does not honor -ffreestanding
> > correctly in this case, because:
> >
> > gcc -ffreestanding pr71104-1.c
> >
> > should not have crashed (before your patch, but it did).
>
> Even with -ffreestanding we handle some functions conservatively.
> See special_function_p.
Oh, I see.
Handling vfork that may be conservative, but longjmp is not conservative.
test.c:
void foo(void);
int longjmp(void);
int *p;
void bar(void)
{
foo();
*p = longjmp();
}
gcc -Wall -S -O3 -ffreestanding test.c
gives zero warning, and invalid code:
bar:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
callfoo
calllongjmp
.cfi_endproc
[Bug testsuite/71489] [7 regression] gcc.dg/tree-ssa/attr-hotcold-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71489 --- Comment #3 from Rainer Orth --- Author: ro Date: Thu Jul 14 09:10:24 2016 New Revision: 238330 URL: https://gcc.gnu.org/viewcvs?rev=238330&root=gcc&view=rev Log: Added forgotten PR testsuite/71489 reference. Modified: trunk/gcc/testsuite/ChangeLog
[Bug testsuite/71865] [7 regression] test case gcc.dg/diagnostic-token-ranges.c fails starting with r237714
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71865 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Can't reproduce this. Where would come bool from? The testcase is not including stdbool.h, and bool is not a C keyword.
[Bug testsuite/71489] [7 regression] gcc.dg/tree-ssa/attr-hotcold-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71489 Rainer Orth changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Rainer Orth --- Indeed, he just forgot to add the PR reference. I've done that now. Fixed for 7.1.
[Bug c++/71875] New: template specialization compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71875
Bug ID: 71875
Summary: template specialization compile error
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: liweifriends at gmail dot com
Target Milestone: ---
Created attachment 38899
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38899&action=edit
the code
The code is as follows:
template
constexpr bool IsMatrix = false;
// matrices
template
class Matrix {};
template
constexpr bool IsMatrix> = true;
// Row-vector expanded matrix
template
class RowVecExpMatrix;
template
constexpr bool IsMatrix> = true;
int main()
{
static_assert(IsMatrix>>, "Matrix check
error");
static_assert(IsMatrix>, "Input type is not a matrix");
}
The Compile command is as follows:
g++ --std=c++14 ./main.cpp
When using gcc 5.4.0 or 6.1.1, the compiler complains as follows:
Error: symbol `_ZL8IsMatrix' is already defined
When using gcc 5.2 or 5.3, the code can be compiled with no error output.
[Bug testsuite/71865] [7 regression] test case gcc.dg/diagnostic-token-ranges.c fails starting with r237714
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71865 --- Comment #2 from Jakub Jelinek --- Ah, the PPC/SPU/s390 builtin conditional macros. For the testcase, the easiest tweak would be to compile with -std=c11, so that this mess isn't defined. Dunno if we should ignore the conditional macros from the suggestions or not.
[Bug fortran/71861] [4.9/5/6/7 Regression] ICE in write_symbol(): bad module symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71861 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/71862] [4.9/5/6/7 Regression] ICE in gfc_add_component_ref, at fortran/class.c:241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71862 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/71860] [4.9/5/6/7 Regression] ICE on pointing to null(mold), verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71860 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c/71858] Surprising suggestions for misspellings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71858 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2016-07-14 Ever confirmed|0 |1
[Bug tree-optimization/71857] [7 Regression] gcc.dg/tree-ssa/ivopt_mult_4.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71857 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-07-14 Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- Confirmed.
[Bug c++/71875] template specialization compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71875 liwei changed: What|Removed |Added Severity|normal |critical
[Bug tree-optimization/71872] ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71872
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-07-14
Ever confirmed|0 |1
--- Comment #3 from Richard Biener ---
(In reply to Jakub Jelinek from comment #2)
> This has nothing to do with sanitizers, it seems tree-data-ref.c is buggy
> and creates invalid trees (ADDR_EXPR of INTEGER_CST) when processing the rhs
> of
> MEM[(union gasnete_anytype32_t * {ref-all})_dst_11] =
> VIEW_CONVERT_EXPR(1);
> Such VCE obviously is not a DR.
I thought I have fixed that (not considering sth like this as DR...).
Ah, I excluded SSA_NAME but not constants... bah. Hmm, somehow I remember
changing this recently but appearantly nothing in the ChangeLog.
See get_references_in_stmt. r133311 - some time ago ;)
Note the whole function should probably be re-written in terms of
walk_stmt_load_store_ops though that doesn't know the IFN handling.
[Bug c++/71871] ICE on mixing templates and vector extensions ternary operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71871 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-07-14 Ever confirmed|0 |1 Known to fail||5.4.0, 7.0 --- Comment #2 from Richard Biener --- I get ./cc1plus -quiet t.ii t.ii: In instantiation of ‘void foo() [with unsigned int N = 0u]’: t.ii:12:10: required from here t.ii:7:5: internal compiler error: in tsubst_copy, at cp/pt.c:13616 x = x ? x : -1; ^ 0x79946e tsubst_copy /space/rguenther/src/svn/gcc-5-branch/gcc/cp/pt.c:13616 0x7a6da8 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /space/rguenther/src/svn/gcc-5-branch/gcc/cp/pt.c:15960 0x7a2446 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) with checking enabled, so your errors are is misleading.
[Bug target/71874] [4.9 Regression] memmove works wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71874 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |NEW Known to work||4.8.5, 5.1.0 Keywords||wrong-code Last reconfirmed||2016-07-14 Component|c++ |target Ever confirmed|0 |1 Summary|memmove works wrong |[4.9 Regression] memmove ||works wrong Target Milestone|--- |4.9.4 Known to fail||4.9.3 --- Comment #2 from Richard Biener --- I can reproduce it with GCC 4.9 but not with GCC 4.8 or GCC 5. The bug happens even at -O0 for me. Branch head fails as well. memmove is inline-expanded to leaq-48(%rbp), %rax movq%rax, %rdi callputs leaq-48(%rbp), %rax addq$20, %rax leaq-48(%rbp), %rdx addq$15, %rdx movq(%rdx), %rcx movq%rcx, (%rax) movzwl 8(%rdx), %ecx movw%cx, 8(%rax) movzbl 10(%rdx), %edx movb%dl, 10(%rax) leaq-48(%rbp), %rax movq%rax, %rdi callputs GCC 5 no longer inline-expands memmove here, not even with optimization.
[Bug c++/71871] ICE on mixing templates and vector extensions ternary operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71871 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I believe the ICE started with r192808, before it has been rejected.
[Bug libstdc++/70716] Doxygen comments on std containers need updating for C++11 allocators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70716 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Thu Jul 14 10:02:10 2016 New Revision: 238332 URL: https://gcc.gnu.org/viewcvs?rev=238332&root=gcc&view=rev Log: Improve doxygen comments for allocators in containers PR libstdc++/70716 * include/bits/forward_list.h (forward_list): Update doxygen comments to reflect allocator propagation semantics. Remove ambiguous statements about data being lost. * include/bits/stl_deque.h (deque): Likewise. * include/bits/stl_list.h (list): Likewise. * include/bits/stl_map.h (map): Likewise. * include/bits/stl_multimap.h (multimap): Likewise. * include/bits/stl_multiset.h (multiset): Likewise. * include/bits/stl_set.h (set): Likewise. * include/bits/stl_vector.h (vector): Likewise. * include/bits/unordered_map.h (unordered_map, unordered_multimap): Likewise. * include/bits/unordered_set.h (unordered_set, unordered_multiset): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/forward_list.h trunk/libstdc++-v3/include/bits/stl_deque.h trunk/libstdc++-v3/include/bits/stl_list.h trunk/libstdc++-v3/include/bits/stl_map.h trunk/libstdc++-v3/include/bits/stl_multimap.h trunk/libstdc++-v3/include/bits/stl_multiset.h trunk/libstdc++-v3/include/bits/stl_set.h trunk/libstdc++-v3/include/bits/stl_vector.h trunk/libstdc++-v3/include/bits/unordered_map.h trunk/libstdc++-v3/include/bits/unordered_set.h
[Bug libstdc++/70716] Doxygen comments on std containers need updating for C++11 allocators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70716 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #3 from Jonathan Wakely --- Done.
[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104
--- Comment #17 from rguenther at suse dot de ---
On Thu, 14 Jul 2016, bernd.edlinger at hotmail dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104
>
> --- Comment #16 from Bernd Edlinger ---
> (In reply to rguent...@suse.de from comment #15)
> > On Thu, 14 Jul 2016, bernd.edlinger at hotmail dot de wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104
> > >
> > > --- Comment #14 from Bernd Edlinger ---
> > > One question though...
> > >
> > > This depends on a special knowledge about "vfork",
> > > but it seems that gcc does not honor -ffreestanding
> > > correctly in this case, because:
> > >
> > > gcc -ffreestanding pr71104-1.c
> > >
> > > should not have crashed (before your patch, but it did).
> >
> > Even with -ffreestanding we handle some functions conservatively.
> > See special_function_p.
>
> Oh, I see.
> Handling vfork that may be conservative, but longjmp is not conservative.
Yeah, returning ECF_NORETURN isn't conservative. OTOH this code
only looking at the name of the function rather than using the
corresponding builtin pre-dates my GCC involvement.
Can you open a separate bug please?
>
> test.c:
>
> void foo(void);
> int longjmp(void);
> int *p;
>
> void bar(void)
> {
> foo();
> *p = longjmp();
> }
>
> gcc -Wall -S -O3 -ffreestanding test.c
> gives zero warning, and invalid code:
>
> bar:
> .LFB0:
> .cfi_startproc
> subq$8, %rsp
> .cfi_def_cfa_offset 16
> callfoo
> calllongjmp
> .cfi_endproc
>
>
[Bug c++/71875] [5/6 Regression] template specialization compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71875 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-07-14 Known to work||5.3.0, 7.0 Summary|template specialization |[5/6 Regression] template |compile error |specialization compile ||error Ever confirmed|0 |1 Known to fail||5.4.0, 6.1.0 Severity|critical|normal
[Bug c++/71875] [5/6 Regression] template specialization compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71875 Martin Liška changed: What|Removed |Added Keywords||rejects-valid CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Confirmed, it was fixed on trunk by r236946: commit 4a2d1b33a26657aeddb839adf306e29123526452 Author: jason Date: Tue May 31 19:49:16 2016 + PR c++/60095 - partial specialization of variable templates PR c++/69515 PR c++/69009 * pt.c (instantiate_template_1): Don't put the partial specialization in DECL_TI_TEMPLATE. (partial_specialization_p, impartial_args): Remove. (regenerate_decl_from_template): Add args parm. (instantiate_decl): Look up the partial specialization again. I'm going to verify the behavior of HEADs of 5 and 6 branches.
[Bug c++/63875] Bogus unused-but-set-parameter warning when expanding a variadic template argument pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63875 Roman Perepelitsa changed: What|Removed |Added CC||roman.perepelitsa at gmail dot com --- Comment #3 from Roman Perepelitsa --- This appears to be fixed in gcc 6.1: the provided snippet compiles cleanly.
[Bug c++/71875] [6 Regression] template specialization compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71875 Martin Liška changed: What|Removed |Added Target Milestone|--- |6.2 Summary|[5/6 Regression] template |[6 Regression] template |specialization compile |specialization compile |error |error --- Comment #2 from Martin Liška --- 5-base (905be4e64f0f9136b06cbfb1e006e8eec1de0b4b): OK 6-base (a050099a416f013bda35832b878d9a57b0cbb231): FAILED /tmp/cci9uL6d.s: Assembler messages: /tmp/cci9uL6d.s:27: Error: symbol `_ZL8IsMatrix' is already defined
[Bug c++/71875] [5 Regression] template specialization compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71875 Martin Liška changed: What|Removed |Added Summary|[6 Regression] template |[5 Regression] template |specialization compile |specialization compile |error |error --- Comment #3 from Martin Liška --- (In reply to Martin Liška from comment #2) > 5-base (905be4e64f0f9136b06cbfb1e006e8eec1de0b4b): OK > 6-base (a050099a416f013bda35832b878d9a57b0cbb231): FAILED > /tmp/cci9uL6d.s: Assembler messages: > /tmp/cci9uL6d.s:27: Error: symbol `_ZL8IsMatrix' is already defined Sorry, there are commits where the branches were branched. 5 (c8db82c76d5f97641bf344c0244323e64b4f5cea): FAILED /tmp/cc4E7vAF.s: Assembler messages: /tmp/cc4E7vAF.s:27: Error: symbol `_ZL8IsMatrix' is already defined 6 (c3f09c3a4a94fd23b245fde516dc5d7188f3a13e): OK
[Bug c++/71871] ICE on mixing templates and vector extensions ternary operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71871 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 38900 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38900&action=edit gcc7-pr71871.patch Untested fix.
[Bug c/71876] New: longjmp is miscompiled with -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876
Bug ID: 71876
Summary: longjmp is miscompiled with -ffreestanding
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Even with -ffreestanding we handle some functions conservatively.
See special_function_p.
However, the function longjmp and siglongjmp are not handled conservatively
as the following test case illustrates:
cat test.c
int longjmp(void);
int bar(void)
{
return longjmp();
}
gcc -Wall -ffreestanding -O3 -S test.c
emits no warning, but resulting code is invalid (no ret):
bar:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
calllongjmp
.cfi_endproc
[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59833 --- Comment #7 from Aurelien Jarno --- (In reply to Ramana Radhakrishnan from comment #6) > (In reply to Aurelien Jarno from comment #5) > > (In reply to Ramana Radhakrishnan from comment #4) > > > Need to apply Aurelien's patch - looks like that's slipped through the > > > cracks. > > > > What was missing to the patch was a testcase which compiles on all platform. > > This has happened recently, as part of the testcase for PR61441. I therefore > > guess this patch can now be applied. > > Do you mind pinging it after another round of testing ? > I have just done a another round on testing on trunk: - The patch is still necessary. - The patch still applies, but with fuzz. I'll resend an update patch. - The patch still works as expected. - The testcase for PR61441 does not seems to work for this bug as it is compiled with -O1. GCC 6 does constant propagation and the resulting binary do not call aeabi_f2d. With GCC 5 or with -O0 the testcase also work for his bug. Is there a way to specify that a test should run with both -O0 and -O1? That would avoid writing an almost identical testcase. Aurelien
[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104 --- Comment #18 from Bernd Edlinger --- (In reply to rguent...@suse.de from comment #17) > Can you open a separate bug please? sure: pr71876
[Bug c/71876] longjmp is miscompiled with -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876 --- Comment #1 from Bernd Edlinger --- I'm unsure, if ECF_LEAF is also unsafe: /* The function does not lead to calls within current function unit. */ #define ECF_LEAF (1 << 10) I couldn't guarantee for that in a freestanding environmnent.
[Bug libgomp/71877] New: -fdump-tree-ompexp is generating incomplete code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71877 Bug ID: 71877 Summary: -fdump-tree-ompexp is generating incomplete code Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: rogerio.rag at gmail dot com CC: jakub at gcc dot gnu.org Target Milestone: --- Created attachment 38901 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38901&action=edit Generate output files. Hello, I have a problem using the gcc + libgomp. I'm trying to get the expanded code format for openmp directives. Specifically for loops with schedule types (unespecified, static, auto, dynamic, guided and runtime). I'm using the options -fdump-tree-ompexp and -fdump-tree-ompexp-graph. gcc-4.8 -fopenmp -fdump-tree-ompexp for-schedule-dynamic-upper-bound-value.c gcc-4.8 -fopenmp -fdump-tree-ompexp-graph for-schedule-dynamic-upper-bound-value.c dot -Tpng for-schedule-dynamic-upper-bound-value.c.015t.ompexp.dot > for-schedule-dynamic-upper-bound-value.c.015t.ompexp.png The generated output files are in attach. I'm testing with gcc-4.9, gcc-5.3 and gcc-6.1. The result likes incomplete. The name of file is modified to *.c.012t.ompexp and it have no complete code according this doc https://gcc.gnu.org/onlinedocs/libgomp/Implementing-FOR-construct.html#Implementing-FOR-construct Something was changed in this option after gcc-4.8?
[Bug libgomp/71877] -fdump-tree-ompexp is generating incomplete code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71877 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-07-14 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- I don't see what you find incomplete on the 6.1 output. In 5.x, you indeed should look at -fdump-tree-ssa dump instead if you want to see the IL for the *.omp_fn* functions, but GCC 6 does dump them even in *.ompexp.
[Bug tree-optimization/71872] ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71872
--- Comment #4 from Jakub Jelinek ---
Reduced testcase:
struct __attribute__((may_alias)) S { int a; };
void
foo (int *x, struct S *y)
{
int i;
for (i = 0; i < 16; i++)
{
int a = 0;
if (*x)
*(struct S *) y = *(struct S *) &a;
}
}
[Bug tree-optimization/71872] [7 Regression] ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71872 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |7.0 Summary|ICE in inchash::add_expr, |[7 Regression] ICE in |at tree.c:7782 -|inchash::add_expr, at |OEP_ADDRESS_OF asserted for |tree.c:7782 - |ADDR_EXPR applied to|OEP_ADDRESS_OF asserted for |constant|ADDR_EXPR applied to ||constant
[Bug rtl-optimization/71878] New: ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71878 Bug ID: 71878 Summary: ICE in Product: gcc Version: 5.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: thopre01 at gcc dot gnu.org Target Milestone: ---
[Bug tree-optimization/71866] [7 Regression] gcc locks up after fix for PR70159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71866 --- Comment #2 from Richard Biener --- Author: rguenth Date: Thu Jul 14 12:15:38 2016 New Revision: 238334 URL: https://gcc.gnu.org/viewcvs?rev=238334&root=gcc&view=rev Log: 2016-07-14 Richard Biener PR tree-optimization/71866 * tree-ssa-pre.c (get_constant_for_value_id): Remove. (do_hoist_insertion): Avoid endless recursion when we didn't insert anything because we managed to simplify things down to a constant or SSA name. (fully_constant_expression): Re-write in terms of ... * tree-ssa-sccvn.h (vn_nary_simplify): ... this. Declare. * tree-ssa-sccvn.c (vn_nary_simplify): New wrapper around vn_nary_build_or_lookup_1. (vn_nary_build_or_lookup_1): Added flag and renamed from ... (vn_nary_build_or_lookup): ... this which now wraps it. * gcc.dg/torture/pr71866.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr71866.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c trunk/gcc/tree-ssa-sccvn.c trunk/gcc/tree-ssa-sccvn.h
[Bug c/71876] longjmp is miscompiled with -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876
--- Comment #2 from Bernd Edlinger ---
test case for the ECF_LEAF:
test.c:
int setjmp(void);
static int x;
void foo(int z)
{
x = z;
}
int bar(void)
{
int z = x;
setjmp();
z += x;
return z;
}
gcc -O3 -S -ffreestanding test.c
bar:
.LFB1:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
movlx(%rip), %eax
movl%eax, 12(%rsp)
callsetjmp
movl12(%rsp), %eax
addq$24, %rsp
.cfi_def_cfa_offset 8
addl%eax, %eax
ret
.cfi_endproc
but the free-standing setjmp function could call back to foo.
[Bug rtl-optimization/71878] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71878 --- Comment #1 from Thomas Preud'homme --- Created attachment 38902 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38902&action=edit Testcase allowing to reproduce ICE in cselib
[Bug rtl-optimization/71878] ICE in cselib_record_set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71878
Thomas Preud'homme changed:
What|Removed |Added
Target||arm-none-eabi
Assignee|unassigned at gcc dot gnu.org |thopre01 at gcc dot
gnu.org
Target Milestone|--- |5.5
Summary|ICE in |ICE in cselib_record_set
Known to fail||5.4.1
--- Comment #2 from Thomas Preud'homme ---
Hi,
The attached testcase (extracted from gcc.dg/vect/slp-perm-5) ICEs on GCC 5 +
backport of r227382 on arm-none-eabi when compiled with -mcpu=cortex-a8 -marm
-mfpu=neon -mfloat-abi=softfp -ftree-vectorize -O2 and gives the following
stacktrace:
/home/thopre01/issues/sjp/slp-perm-5.c: In function ‘foo’:
/home/thopre01/issues/sjp/slp-perm-5.c:44:1: internal compiler error: in
cselib_record_set, at cselib.c:2396
}
^
0x653c37 cselib_record_set
/data/dev/repos/internal/gcc/gcc/cselib.c:2396
0x653c37 cselib_record_sets
/data/dev/repos/internal/gcc/gcc/cselib.c:2613
0x654237 cselib_process_insn(rtx_insn*)
/data/dev/repos/internal/gcc/gcc/cselib.c:2686
0x89e547 reload_cse_regs_1
/data/dev/repos/internal/gcc/gcc/postreload.c:248
0x89fcab reload_cse_regs
/data/dev/repos/internal/gcc/gcc/postreload.c:94
0x89fcab execute
/data/dev/repos/internal/gcc/gcc/postreload.c:2387
This is due to LRA allocating the same hard register to the two destinations
registers of neon_vtrn_insn pattern (in config/arm/neon.md).
GCC was configured with --target=arm-none-eabi only.
LRA produces the following insn:
(insn 77 61 154 2 (parallel [
(set (reg:V4SI 52 d18 [188])
(unspec:V4SI [
(reg:V4SI 52 d18 [188])
(reg:V4SI 52 d18 [188])
] UNSPEC_VTRN1))
(set (reg:V4SI 52 d18 [188])
(unspec:V4SI [
(reg:V4SI 52 d18 [188])
(reg:V4SI 52 d18 [188])
] UNSPEC_VTRN2))
]) pr71878.c:41 1940 {*neon_vtrnv4si_insn}
(nil))
This causes cselib to fail when processing the second SET of that parallel in
cselib_record_set () because of the assert gcc_assert (REG_VALUES (dreg)->elt
== 0) since the field was already set when processing the first SET.
[Bug tree-optimization/71866] [7 Regression] gcc locks up after fix for PR70159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71866 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug middle-end/71876] longjmp is miscompiled with -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-07-14 Component|c |middle-end Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Yes, only ECF_RETURNS_TWICE is conservative.
[Bug target/71652] [4.9/5/6/7 Regression] ICE in in ix86_target_macros_internal, at config/i386/i386-c.c:187
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71652 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #6 from Jan Hubicka --- The patch looks fine to me. i would not drop the gcc_unreachable and instead just arrange the -march to be set to some other reasonable value at the time error is produced. For all the suggestions, i think answer is yes.
[Bug middle-end/71876] longjmp is miscompiled with -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876 --- Comment #4 from Bernd Edlinger --- And, what is "qsetjmp" ? Also "setjmp_syscall", "savectx" are also completely new to me. And why is the prefix "__x" discarded?
[Bug tree-optimization/71872] [7 Regression] ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71872 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 38903 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38903&action=edit gcc7-pr71872.patch Untested fix.
[Bug middle-end/71876] longjmp is miscompiled with -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Perhaps ECF_MAY_BE_ALLOCA too? But ECF_NORETURN and ECF_LEAF are not conservative, sure.
[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71867 --- Comment #2 from Vadim Zeitlin --- I'll try to add the preprocessed code a bit later, but, FWIW, I can already say that there is no macro trickery whatsoever in this code itself.
[Bug bootstrap/66319] [6 Regression] gcov-tool.c:84:65: error: invalid conversion from 'int (*)(const c har*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66319 --- Comment #19 from dave.anglin at bell dot net --- On 2016-07-12 10:38 AM, danglin at gcc dot gnu.org wrote: > Patch looks reasonable but needs to be sent to gcc-patches with cc's. Further, the patch needs to be submitted by someone with a gcc copyright assignment.
[Bug c++/71879] New: Error in unevaluated context breaks SFINAE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71879
Bug ID: 71879
Summary: Error in unevaluated context breaks SFINAE
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manuel.schil...@bmw-carit.de
Target Milestone: ---
Having asked at Stackoverflow I was told the following might be a bug in GCC:
When comparing member function pointers in an SFINAE context, member function
Foo::foo() exists, but its body contains code (x.hello()) which eventually does
not compile.
The following code compiles with clang. GCC however seems to evaluate the
function body of Foo::foo() and exits with an error ('struct Caller' has no
member named 'hello'), despite being in an unevaluated SFINAE context.
///
#include
#include
struct Foo
{
template void foo(T&& x) { x.hello();}
};
struct Caller
{
template
auto call(T&& x, int) -> decltype(
std::enable_if_t<
std::is_same<
decltype(&T::template foo),
void (T::*)(decltype(*this))
>::value
>())
{
//x.foo(*this);
}
template
void call(T&&, char){ std::cout << "hello" << std::endl;}
};
int main()
{
Caller c;
c.call(Foo(), 0);
}
///
Error message:
main.cpp: In instantiation of 'void Foo::foo(T&&) [with T = Caller&]':
main.cpp:14:14: required by substitution of 'template decltype
(std::enable_if_t), void
(T::*)(Caller&)>::value>()) Caller::call(T&&, int) [with T = Foo]'
main.cpp:31:18: required from here
main.cpp:6:47: error: 'struct Caller' has no member named 'hello'
template void foo(T&& x) { x.hello(); }
~~^
--
version: g++ 6.1.0
flags: g++ -std=c++14 -O2 -Wall -pedantic -pthread main.cpp
--
Link to code on coliru: http://coliru.stacked-crooked.com/a/a984ad1ca2edcb0c
Link to stackoverflow: http://stackoverflow.com/q/38371924/678093
[Bug c++/71879] Error in unevaluated context breaks SFINAE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71879 --- Comment #1 from Jonathan Wakely --- Taking the address of Foo::foo instantiates it, which results in an error outside the immediate context, so you get an error not a substitution failure. http://stackoverflow.com/a/15261234/981959
[Bug fortran/71880] New: pointer to allocatable character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71880 Bug ID: 71880 Summary: pointer to allocatable character Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: valeryweber at hotmail dot com Target Milestone: --- Hi All is that a compiler bug? many thanks v cat gcc-6.1.f90 program t character(:), dimension(:), allocatable, target :: c character(:), dimension(:), pointer :: p allocate(c(10),source='X') p=>c write(*,*) 'p=<',p(1),'> c=<',c(1),'>',len(p(1)) end program t gfortran-6.1.0 gcc-6.1.f90 ./a.out p=<> c= 0 gfortran-trunk gcc-6.1.f90 ./a.out p=<> c= 0
[Bug go/71396] "use of undefined type" error in gccgo-6 when go (1.6.1) is perfectly happy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71396 Than McIntosh changed: What|Removed |Added CC||thanm at google dot com --- Comment #1 from Than McIntosh --- Hello, I was unable to access the attachment (just got a single line of text). Could you please repost? Thanks, Than
[Bug fortran/71880] pointer to allocatable character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71880 --- Comment #1 from Valery Weber --- what about this one? cat gcc-6.1b.f90 program t character(:), dimension(:), allocatable, target :: c character(:), dimension(:), pointer :: p allocate(c(10),source='X') p=>c(:) write(*,*) 'p=<',p(1),'> c=<',c(1),'>',len(p(1)) end program t gfortran-6.1.0 gcc-6.1b.f90 ./a.out p= c= 32674
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #12 from Jason Merrill --- (In reply to Jonathan Wakely from comment #4) > However with that patch the caught pointer is not null, so it's not right. For a pointer, you just need to set thrown_ptr to null. For a pointer to member it's trickier, since they are thrown by reference, and we end up returning a pointer to the exception object. I suppose that since nullptr has no actual value we can feel free to clobber the "value" of the exception object before returning. For a pointer to member function that's still problematic because the exception object for 'throw nullptr' is currently one word, and a pointer to member function is two. So I suppose we will need to allocate two words for 'throw nullptr'. But clang doesn't do that; do they actually handle catching nullptr as a pointer to member function?
[Bug middle-end/71876] longjmp is miscompiled with -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876
--- Comment #6 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #5)
> Perhaps ECF_MAY_BE_ALLOCA too? But ECF_NORETURN and ECF_LEAF are not
> conservative, sure.
Yes. That's right.
alloca can not return null.
See tree_expr_nonzero_warnv_p.
Test case:
void *alloca(void);
void bar(void)
{
char * x = alloca();
if (x)
*x = 0;
}
gcc -Wall -O3 -S -ffreestanding test.c
result: if(x) is optimized away:
bar:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
callalloca
movb$0, (%rax)
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 --- Comment #13 from Jonathan Wakely --- (In reply to Jason Merrill from comment #12) > (In reply to Jonathan Wakely from comment #4) > > However with that patch the caught pointer is not null, so it's not right. > > For a pointer, you just need to set thrown_ptr to null. Oh, well that's easier than I thought! > For a pointer to member it's trickier, since they are thrown by reference, > and we end up returning a pointer to the exception object. I suppose that > since nullptr has no actual value we can feel free to clobber the "value" of > the exception object before returning. > > For a pointer to member function that's still problematic because the > exception object for 'throw nullptr' is currently one word, and a pointer to > member function is two. So I suppose we will need to allocate two words for > 'throw nullptr'. But clang doesn't do that; do they actually handle > catching nullptr as a pointer to member function? I don't know, when I test with clang it uses libstdc++.so, so the nullptr doesn't get caught.
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796
--- Comment #14 from Jason Merrill ---
Also note that a null pointer to data member is represented as -1, not 0, so
you'll want
*(ptrdiff_t*)thrown_ptr = -1;
for that case.
A null pointer to member function is { nullptr, 0 }.
You might also handle this in __pbase_type_info::__do_catch rather than
get_adjusted_ptr.
[Bug target/65951] [AArch64] Will not vectorize 64bit integer multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65951 --- Comment #12 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Thu Jul 14 14:32:39 2016 New Revision: 238340 URL: https://gcc.gnu.org/viewcvs?rev=238340&root=gcc&view=rev Log: [vectorizer][2/2] Hook up mult synthesis logic into vectorisation of mult-by-constant PR target/65951 PR tree-optimization/70923 * tree-vect-patterns.c: Include mult-synthesis.h. (target_supports_mult_synth_alg): New function. (synth_lshift_by_additions): Likewise. (apply_binop_and_append_stmt): Likewise. (vect_synth_mult_by_constant): Likewise. (target_has_vecop_for_code): Likewise. (vect_recog_mult_pattern): Use above functions to synthesize vector multiplication by integer constants. * gcc.dg/vect/vect-mult-const-pattern-1.c: New test. * gcc.dg/vect/vect-mult-const-pattern-2.c: Likewise. * gcc.dg/vect/pr65951.c: Likewise. * gcc.dg/vect/vect-iv-9.c: Remove ! vect_int_mult-specific scan. Added: trunk/gcc/testsuite/gcc.dg/vect/pr65951.c trunk/gcc/testsuite/gcc.dg/vect/vect-mult-const-pattern-1.c trunk/gcc/testsuite/gcc.dg/vect/vect-mult-const-pattern-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-iv-9.c trunk/gcc/tree-vect-patterns.c
[Bug tree-optimization/70923] [7 regression] gcc.dg/vect/pr60092.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70923 --- Comment #10 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Thu Jul 14 14:32:39 2016 New Revision: 238340 URL: https://gcc.gnu.org/viewcvs?rev=238340&root=gcc&view=rev Log: [vectorizer][2/2] Hook up mult synthesis logic into vectorisation of mult-by-constant PR target/65951 PR tree-optimization/70923 * tree-vect-patterns.c: Include mult-synthesis.h. (target_supports_mult_synth_alg): New function. (synth_lshift_by_additions): Likewise. (apply_binop_and_append_stmt): Likewise. (vect_synth_mult_by_constant): Likewise. (target_has_vecop_for_code): Likewise. (vect_recog_mult_pattern): Use above functions to synthesize vector multiplication by integer constants. * gcc.dg/vect/vect-mult-const-pattern-1.c: New test. * gcc.dg/vect/vect-mult-const-pattern-2.c: Likewise. * gcc.dg/vect/pr65951.c: Likewise. * gcc.dg/vect/vect-iv-9.c: Remove ! vect_int_mult-specific scan. Added: trunk/gcc/testsuite/gcc.dg/vect/pr65951.c trunk/gcc/testsuite/gcc.dg/vect/vect-mult-const-pattern-1.c trunk/gcc/testsuite/gcc.dg/vect/vect-mult-const-pattern-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-iv-9.c trunk/gcc/tree-vect-patterns.c
[Bug fortran/70842] [4.9/5/6/7 Regression] internal compiler error with character members within a polymorphic pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70842 --- Comment #8 from kargl at gcc dot gnu.org --- (In reply to vehre from comment #7) > Hi Karl, > > (In reply to kargl from comment #5) > > With the patch I posted earlier today and code in comment #1, I see > > which patch are you referring to? At least upto now I don't see a patch from > you on the list or in this PR. > See PR 71862
[Bug tree-optimization/71872] [7 Regression] ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71872 --- Comment #6 from rguenther at suse dot de --- On July 14, 2016 2:33:12 PM GMT+02:00, "jakub at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71872 > >Jakub Jelinek changed: > > What|Removed |Added > > Status|NEW |ASSIGNED > Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org > >--- Comment #5 from Jakub Jelinek --- >Created attachment 38903 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38903&action=edit >gcc7-pr71872.patch > >Untested fix. Is_gimple_min_invariant?
[Bug target/65951] [AArch64] Will not vectorize 64bit integer multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65951 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #13 from ktkachov at gcc dot gnu.org --- Implemented for GCC 7
[Bug tree-optimization/70923] [7 regression] gcc.dg/vect/pr60092.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70923 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |FIXED --- Comment #11 from ktkachov at gcc dot gnu.org --- Should be fixed now.
[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59833 --- Comment #8 from ramana.radhakrishnan at foss dot arm.com --- On 14/07/16 12:15, aurelien at aurel32 dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59833 > > --- Comment #7 from Aurelien Jarno --- > (In reply to Ramana Radhakrishnan from comment #6) >> (In reply to Aurelien Jarno from comment #5) >>> (In reply to Ramana Radhakrishnan from comment #4) Need to apply Aurelien's patch - looks like that's slipped through the cracks. >>> >>> What was missing to the patch was a testcase which compiles on all platform. >>> This has happened recently, as part of the testcase for PR61441. I therefore >>> guess this patch can now be applied. >> >> Do you mind pinging it after another round of testing ? >> > > I have just done a another round on testing on trunk: > - The patch is still necessary. > - The patch still applies, but with fuzz. I'll resend an update patch. > - The patch still works as expected. > - The testcase for PR61441 does not seems to work for this bug as it is > compiled with -O1. GCC 6 does constant propagation and the resulting binary do > not call aeabi_f2d. With GCC 5 or with -O0 the testcase also work for his bug. > Is there a way to specify that a test should run with both -O0 and -O1? That > would avoid writing an almost identical testcase. An option might be to move the test into gcc.c-torture/execute and then it will torture over all optimization levels and add the option needed with dg-additional-options ? Ramana > > Aurelien >
[Bug target/65952] [AArch64] Will not vectorize storing induction of pointer addresses for LP64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65952 Bug 65952 depends on bug 65951, which changed state. Bug 65951 Summary: [AArch64] Will not vectorize 64bit integer multiplication https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65951 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 65951, which changed state. Bug 65951 Summary: [AArch64] Will not vectorize 64bit integer multiplication https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65951 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/71872] [7 Regression] ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71872
--- Comment #7 from Jakub Jelinek ---
Will change.
While:
/* PR tree-optimization/71872 */
struct __attribute__((may_alias)) S { int *a; };
int b;
void
foo (int *x, struct S *y)
{
int i;
for (i = 0; i < 16; i++)
{
int *a = &b;
if (*x)
*(struct S *) y = *(struct S *) &a;
}
}
doesn't ICE, it has:
*y_7(D) = VIEW_CONVERT_EXPR(&b);
in the IL.
[Bug middle-end/50060] intrinsics not folded by the middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50060 Paul A. Bristow changed: What|Removed |Added CC||pbristow at hetp dot u-net.com --- Comment #6 from Paul A. Bristow --- This is a serious 'fault' that prevents making constexpr and functions that use frexp, even though the mantissa and exponent are definitely constant. This prevents using constexpr in Boost.Math functions and distributions, Boost.Multiprecision and Proposed Boost.Fixed-Point. Suggestions on workaround(s)? Two separate constexpr functions for mantissa and exponent? One function that 'returns' both as a tuple/pair? Either are a major nuisance to replace frexp. (Perhaps a single function to 'return' both doesn't such a good idea now?)
[Bug fortran/70842] [4.9/5/6/7 Regression] internal compiler error with character members within a polymorphic pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70842 vehre at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #9 from vehre at gcc dot gnu.org --- Patch available at: https://gcc.gnu.org/ml/fortran/2016-07/msg00063.html Waiting for review.
[Bug c++/63875] Bogus unused-but-set-parameter warning when expanding a variadic template argument pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63875 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Known to work||7.0 Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Confirmed as fixed along with bug 66543 by r235221: commit a4735361ea12ff1c5cac8ac66e08d0e775a7365f Author: jason Date: Tue Apr 19 19:30:22 2016 + PR c++/66543 - -Wunused-but-set* false positives * expr.c (mark_exp_read): Handle NON_DEPENDENT_EXPR. * pt.c (make_pack_expansion): Call mark_exp_read. * semantics.c (finish_id_expression): Call mark_type_use in unevaluated context. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@235221 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug driver/69028] ICE on *any* valid Cilk+ code C/C++: -fcilkplus is incompatible with -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69028 --- Comment #4 from Martin Liška --- Ok, the problem comes from r224161: Author: aldyh Date: Fri Jun 5 18:44:53 2015 + Merge debug-early branch into mainline. where running: ./xg++ -B. ~/Programming/testcases/PR69028/pr69028.ii -fcilkplus -fdump-tree-all -c 0x10da092 crash_signal ../../gcc/toplev.c:375 0x9ecaf5 cp_dump_tree(void*, tree_node*) ../../gcc/cp/dump.c:318 0x114488e dequeue_and_dump ../../gcc/tree-dump.c:427 0x114650e dump_node(tree_node const*, int, _IO_FILE*) ../../gcc/tree-dump.c:774 0x8e2f75 dump_tu ../../gcc/cp/decl2.c:4387 0x8e4024 c_parse_final_cleanups() ../../gcc/cp/decl2.c:4819 0xac0899 c_common_parse_file() ../../gcc/c-family/c-opts.c:1091 it's: ==21456== Invalid read of size 2
[Bug driver/69028] ICE on *any* valid Cilk+ code C/C++: Invalid read of size 2 in cp_dump_tree(void*, tree_node*) (dump.c:318)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69028 --- Comment #5 from Martin Liška --- Created attachment 38904 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38904&action=edit Candidate patch for the profiling issue Following cilk function has no location, if it's a valid that a function does not have a location, then the patch should fix that.
[Bug tree-optimization/71881] New: ICE on valid code at -O3 with -g enabled on x86_64-linux-gnu: cannot update SSA form
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71881
Bug ID: 71881
Summary: ICE on valid code at -O3 with -g enabled on
x86_64-linux-gnu: cannot update SSA form
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The following code causes an ICE when compiled with the current gcc trunk at
-O3 with -g enabled on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It is a regression from 6.1.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160714 (experimental) [trunk revision 238331] (GCC)
$
$ gcc-trunk -O3 -c small.c
$ gcc-trunk -O2 -g -c small.c
$ gcc-6.1 -O3 -g -c small.c
$
$ gcc-trunk -O3 -g -c small.c
small.c: In function ‘fn1’:
small.c:3:5: error: statement uses released SSA name:
int fn1 ()
^~~
# DEBUG i => i_29 + 1
The use of i_29 should have been replaced
small.c:3:5: internal compiler error: cannot update SSA form
0xc6090e update_ssa(unsigned int)
../../gcc-source-trunk/gcc/tree-into-ssa.c:3203
0xd35e5c rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int, loop*)
../../gcc-source-trunk/gcc/tree-ssa-loop-manip.c:623
0xc670ff execute
../../gcc-source-trunk/gcc/tree-loop-distribution.c:1838
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.
$
---
int a, b, c, d, *e, f, g;
int fn1 ()
{
char h[2];
int i = 0;
for (; i < 2; i++)
{
if (c)
for (*e = 0; *e;)
{
int j[f];
i = *e;
}
h[i] = 0;
}
for (; a;)
return h[0];
for (b = 0; b;)
i = g = (1 & i) < d;
return 0;
}
[Bug c++/71882] New: elaborated-type-specifier friend not looked up in unnamed namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882
Bug ID: 71882
Summary: elaborated-type-specifier friend not looked up in
unnamed namespace
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
At least with both GCC 6.1.1 and recent trunk, compiling
namespace { struct S; }
class C {
friend struct S;
static void f();
};
namespace { struct S { void f() { C::f(); } }; }
fails with
> $ g++ -c test.cc
> test.cc: In member function ‘void {anonymous}::S::f()’:
> test.cc:6:42: error: ‘static void C::f()’ is private within this context
>namespace { struct S { void f() { C::f(); } }; }
> ^
> test.cc:4:17: note: declared private here
> static void f();
> ^
[Bug tree-optimization/71881] [4.9/6/7 Regression] ICE on valid code at -O3 with -g enabled on x86_64-linux-gnu: cannot update SSA form
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71881 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-07-14 CC||marxin at gcc dot gnu.org Summary|ICE on valid code at -O3|[4.9/6/7 Regression] ICE on |with -g enabled on |valid code at -O3 with -g |x86_64-linux-gnu: cannot|enabled on |update SSA form |x86_64-linux-gnu: cannot ||update SSA form Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, GCC 5 branch looks fine, however 4.9 doesn't: pr71881.c:4:5: internal compiler error: Segmentation fault int fn1 () ^ 0x9ad80f crash_signal /home/marxin/BIG/Programming/gcc/gcc/toplev.c:337 0xb4d7a3 verify_use /home/marxin/BIG/Programming/gcc/gcc/tree-ssa.c:803 0xb52357 verify_ssa(bool) /home/marxin/BIG/Programming/gcc/gcc/tree-ssa.c:1058 0x900a0c execute_function_todo /home/marxin/BIG/Programming/gcc/gcc/passes.c:1854 0x9012c4 do_per_function /home/marxin/BIG/Programming/gcc/gcc/passes.c:1574 0x9012c4 execute_todo /home/marxin/BIG/Programming/gcc/gcc/passes.c:1887
[Bug target/71869] __builtin_isgreater raises an invalid exception on PPC64 using __float128 inputs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71869 --- Comment #1 from Paul E. Murphy --- __builtin_isfinite also has a similar issue.
[Bug fortran/71807] [5/6/7 Regression] Internal compiler error with NULL() reference in structure constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71807 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org --- Comment #3 from vehre at gcc dot gnu.org --- Patch available at https://gcc.gnu.org/ml/fortran/2016-07/msg00065.html Waiting for review.
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 --- Comment #15 from Jason Merrill --- (In reply to Jason Merrill from comment #12) > For a pointer to member function that's still problematic because the > exception object for 'throw nullptr' is currently one word, and a pointer to > member function is two. So I suppose we will need to allocate two words for > 'throw nullptr'. But clang doesn't do that; do they actually handle > catching nullptr as a pointer to member function? But then again, testing whether a PMF is null only checks the first word on non-ARM targets, so we can probably get away with still only allocating the one word and setting it to NULL. ARM will probably need to allocate two words.
[Bug fortran/71883] New: ICE in identical_array_ref, at fortran/dependency.c:104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71883 Bug ID: 71883 Summary: ICE in identical_array_ref, at fortran/dependency.c:104 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- ICE on rank mismatch or typo with experimental (--enable-checking=yes) versions 7, 6, and maybe older. No ICE for release versions 4.9, 5, 6. $ cat z1.f90 program p character(3), allocatable :: z(:,:) z(1:2,1:2) = 'abc' z(2,1) = z(12) z(21) = z(1,2) end $ gfortran-6 z1.f90# release z1.f90:4:13: z(2,1) = z(12) 1 Error: Rank mismatch in array reference at (1) (1/2) z1.f90:5:4: z(21) = z(1,2) 1 Error: Rank mismatch in array reference at (1) (1/2) $ gfortran-7-20160710 z1.f90 # experimental z1.f90:4:13: z(2,1) = z(12) 1 Error: Rank mismatch in array reference at (1) (1/2) z1.f90:5:4: z(21) = z(1,2) 1 Error: Rank mismatch in array reference at (1) (1/2) f951: internal compiler error: in identical_array_ref, at fortran/dependency.c:104 0x70fdee identical_array_ref ../../gcc/fortran/dependency.c:104 0x70fdee are_identical_variables ../../gcc/fortran/dependency.c:164 0x70fdee gfc_dep_compare_expr(gfc_expr*, gfc_expr*) ../../gcc/fortran/dependency.c:462 0x7ac7a6 realloc_string_callback ../../gcc/fortran/frontend-passes.c:182 0x7af779 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*) ../../gcc/fortran/frontend-passes.c:3376 0x7b08c2 realloc_strings ../../gcc/fortran/frontend-passes.c:1015 0x6eb38a gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:15707 0x6d668a resolve_all_program_units ../../gcc/fortran/parse.c:5853 0x6d668a gfc_parse_file() ../../gcc/fortran/parse.c:6105 0x718d12 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:198
[Bug rtl-optimization/71878] ICE in cselib_record_set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71878 --- Comment #3 from Thomas Preud'homme --- Author: thopre01 Date: Thu Jul 14 16:41:06 2016 New Revision: 238346 URL: https://gcc.gnu.org/viewcvs?rev=238346&root=gcc&view=rev Log: 2016-07-14 Thomas Preud'homme gcc/ PR rtl-optimization/71878 * lra-constraints.c (match_reload): Pass information about other output operands. Create new unique register value if matching input operand shares same register value as output operand being considered. (curr_insn_transform): Record output operands already processed. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c
[Bug c++/70977] [6/7 Regression] Out of memory during compilation of facebook/wangle (flag c++0x works, flag c++14 fails).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70977 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #9 from Romain Geissler --- Note: this affects builds of Facebook's Folly in C++14 with gcc 6 too. See https://github.com/facebook/folly/issues/418
[Bug fortran/71884] New: ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884 Bug ID: 71884 Summary: ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With these snippets : $ cat z1.f90 program p class(*), allocatable :: x allocate (x, source=null()) end $ cat z2.f90 program p class(*), allocatable :: x allocate (x, mold=null()) end $ gfortran-6 z2.f90 z2.f90:3:0: allocate (x, mold=null()) internal compiler error: in gfc_trans_allocate, at fortran/trans-stmt.c:5573 $ gfortran-7-20160710 z2.f90 z2.f90:3:0: allocate (x, mold=null()) internal compiler error: in gfc_trans_allocate, at fortran/trans-stmt.c:5582 0x7a1d26 gfc_trans_allocate(gfc_code*) ../../gcc/fortran/trans-stmt.c:5582 0x71bf87 trans_code ../../gcc/fortran/trans.c:1838 0x74ac88 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6171 0x6d6860 translate_all_program_units ../../gcc/fortran/parse.c:5914 0x6d6860 gfc_parse_file() ../../gcc/fortran/parse.c:6120 0x718d12 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:198
[Bug fortran/71884] ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884 --- Comment #1 from Gerhard Steinmetz --- Another source position with obviously invalid code : $ cat za.f90 program p character(:), allocatable :: z allocate (character(*) :: z) end $ gfortran-7-20160710 za.f90 za.f90:3:0: allocate (character(*) :: z) internal compiler error: in gfc_trans_allocate, at fortran/trans-stmt.c:5698 0x7a17f2 gfc_trans_allocate(gfc_code*) ../../gcc/fortran/trans-stmt.c:5698 0x71bf87 trans_code ../../gcc/fortran/trans.c:1838 0x74ac88 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6171 0x6d6860 translate_all_program_units ../../gcc/fortran/parse.c:5914 0x6d6860 gfc_parse_file() ../../gcc/fortran/parse.c:6120 0x718d12 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:198
[Bug fortran/71883] ICE in identical_array_ref, at fortran/dependency.c:104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71883 --- Comment #2 from Gerhard Steinmetz --- Runtime behavior : $ cat y1.f90 program p character(3), allocatable :: z(:,:) z(1:2,1:2) = 'abc' z(2,1) = z(1,2) z(2,1) = z(1,2) end $ gfortran-6 -g -O0 -Wall -fcheck=all -fno-frontend-optimize y1.f90 $ a.out At line 3 of file y1.f90 Fortran runtime error: Index '1' of dimension 2 of array 'z' outside of expected range (47021301956608:0) Error termination. Backtrace: #...
[Bug fortran/71883] ICE in identical_array_ref, at fortran/dependency.c:104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71883 --- Comment #1 from Gerhard Steinmetz --- Backup tests, analogous backtrace : $ cat z2.f90 program p character(:), allocatable :: z(:,:) z(1:2,1:2) = 'abc' z(2,1) = z(12) z(21) = z(1,2) end $ cat z3.f90 program p character(3), allocatable :: z(:,:) z(1:2,1:2) = 'abc' z(2,1) = z(-1) z(2,1) = z(99) z(2,1) = z(huge(0)) z(2,1) = z(-huge(0)) z(-1) = z(2,1) z(99) = z(2,1) z(huge(0)) = z(2,1) z(-huge(0)) = z(2,1) end $ cat z4.f90 program p character(:), allocatable :: z(:,:) z(1:2,1:2) = 'abc' z(2,1) = z(-1) z(2,1) = z(99) z(2,1) = z(huge(0)) z(2,1) = z(-huge(0)) z(-1) = z(2,1) z(99) = z(2,1) z(huge(0)) = z(2,1) z(-huge(0)) = z(2,1) end
[Bug c++/71885] New: Incorrect code generated with -01, function calls are missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885 Bug ID: 71885 Summary: Incorrect code generated with -01, function calls are missing Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eric at baculasystems dot com Target Milestone: --- Created attachment 38905 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38905&action=edit .ii file generated with -O1 option I overload the new operator in a class (to initialize the memory to 0 and track memory leaks), and after the upgrade from GCC 5.x to 6.1, my program stopped to work correctly. If I tweak a little bit the new operator (I add a printf() inside, or I do all operations in one line memset(malloc()) instead of malloc() ; memset();) the code is generated correctly. I have a small test file, not sure this is the best example. In my little program, I have two set of classes, one that is properly generated, and an other one that is buggy. The only difference between the two is a "printf()" in a function. The good result should be a == 0 # g++ -Wall -00 new.c # ./a.out new is called from new.c:81 and it works! test_ok a == 0 testa == 0 # g++ -Wall -01 new.c # ./a.out test_ok a == 0 testa == 1431655765 I'm running Archlinux. Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc-multilib/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 6.1.1 20160707 (GCC) Thanks
