https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63472
--- Comment #4 from ak at gcc dot gnu.org ---
Reduced test cases for all three crashes. I suspect multiple have a similar
root cause (except perhaps for the expand_expr_addr_expr_1 one)
It looks like the transaction code messes up cfgloops.
copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #22 from Ville Voutilainen ---
Created attachment 33664
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33664&action=edit
Preprocessed source for is_trivially_copy_constructible tests
This test fails the static_assert for TType
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #21 from Uroš Bizjak ---
(In reply to boger from comment #20)
> The latest patch worked on ppc64 for LE & BE. That is, the testcase
> recover.go now works and no new regressions were introduced.
Also works on alpha [1] without new r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63472
--- Comment #3 from ak at gcc dot gnu.org ---
Another one:
0x8e23b7 crash_signal
../../gcc/gcc/toplev.c:340
0x61be46 copy_bbs(basic_block_def**, unsigned int, basic_block_def**,
edge_def**, unsigned int, edge_def**, loop*, basic_block_def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63472
--- Comment #2 from ak at gcc dot gnu.org ---
Looks like there are more problems with -fgnu-tm
I hacked csmith to generate random __transaction_atomic blocks and I got a lot
of crashes immediately. All I looked at were variants of these two:
0x8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63472
ak at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404
Andrew Pinski changed:
What|Removed |Added
CC||sasha.levin at oracle dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63481
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63481
Bug ID: 63481
Summary: "Improve prepare_shrink_wrap to sink more
instructions" causes linux kernel failure
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63480
Bug ID: 63480
Summary: -Wmissing-field-initializers should not warn about
intentionally empty initializers (or that should be a
separate option)
Product: gcc
Vers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63479
Bug ID: 63479
Summary: Compiler flag to zero structure padding
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56580
ak at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63478
Andrew Pinski changed:
What|Removed |Added
Target||Sparc
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63478
--- Comment #2 from Dennis Clarke ---
Also, this may be a simple RESOLVED WONT FIX because :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34191
Sorry, the option -mptr64 looks to be undocumented and therefore a no no.
Dennis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63478
--- Comment #1 from Dennis Clarke ---
The option "-mptr64" seems to be the issue here because :
$ /opt/intermediate/gcc4/bin/gcc -v -save-temps -mcpu=v8 -mno-app-regs -m32
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -S -o
hello
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63478
Bug ID: 63478
Summary: internal compiler error: in sparc_emit_set_const64, at
config/sparc/sparc.c:2061
Product: gcc
Version: 4.7.4
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
Kazumoto Kojima changed:
What|Removed |Added
Attachment #33657|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780
--- Comment #4 from russelldub at gmail dot com ---
Any hope for movement on this? I've made some attempts at diagnosing the
issue, but not sure why equivalences behave differently than other statements
in the modules.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780
--- Comment #3 from russelldub at gmail dot com ---
Any hope for movement on this? I've made some attempts at diagnosing the
issue, but not sure why equivalences behave differently than other statements
in the modules.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #9 from Andi Kleen ---
Patch fixes the test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #21 from Jason Merrill ---
(In reply to Ville Voutilainen from comment #20)
> template struct bool_
> {
> };
>
> template
> struct mytrait : bool_<__is_trivially_constructible(T, Args...)>
> {
> };
>
> template
> struct mytrait2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63477
Bug ID: 63477
Summary: Bogus warning with -O3 -Warray-bounds: array subscript
is above array bounds
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #20 from boger at us dot ibm.com ---
The latest patch worked on ppc64 for LE & BE. That is, the testcase recover.go
now works and no new regressions were introduced.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63476
Bug ID: 63476
Summary: [5 Regression] ICE: tree check: expected ssa_name,
have var_decl in walk_aliased_vdefs_1, at
tree-ssa-alias.c:2689
Product: gcc
Version: 5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464
--- Comment #7 from Marc Glisse ---
The SLP version is slightly slower than the bit test in this case (at least on
my old desktop), but it can more easily handle testing for characters that are
not within 64 of each other.
__m128i b=_mm_set1_e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464
--- Comment #6 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #1)
> We have this optimization implemented for switches,
Thanks, that's indeed the most natural place for it, although I hadn't thought
of testing that...
Glibc's strs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #22 from Jan Hubicka ---
Concerning Richard's comment, it is true that we will produce more warings then
before in case function is optimized out. But we always did produce extra
warnings
when the function call is optimized out (as d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63434
--- Comment #2 from steve at hearnden dot org.uk ---
(In reply to Richard Biener from comment #1)
> Patches should be sent to gcc-patches@
I was trying to be sure that my understanding was correct before posting my
fix. I have since found in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61387
--- Comment #17 from Francois-Xavier Coudert ---
> Fixed.
Thanks Mike!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61387
mrs at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61387
--- Comment #15 from mrs at gcc dot gnu.org ---
Author: mrs
Date: Tue Oct 7 18:59:24 2014
New Revision: 215983
URL: https://gcc.gnu.org/viewcvs?rev=215983&root=gcc&view=rev
Log:
2014-10-07 Iain Sandoe
PR target/61387
* confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--- Comment #21 from Teresa Johnson ---
On Tue, Oct 7, 2014 at 11:08 AM, Jeff Law wrote:
> On 10/04/14 13:29, Teresa Johnson wrote:
>>>
>>> Jeff, what is intended here - should we not be threading both of these
>>> paths?
>>
>>
>> I have a patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63403
--- Comment #4 from dave.anglin at bell dot net ---
On 10/7/2014 2:48 PM, rsandifo at gcc dot gnu.org wrote:
> Can you try the patches I posted here:
>
> https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02636.html
> https://gcc.gnu.org/ml/gcc-patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63403
--- Comment #3 from rsandifo at gcc dot gnu.org
---
Can you try the patches I posted here:
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02636.html
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02637.html
? They're conceptually a single chang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352
--- Comment #15 from Richard PALO ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #14)
> > --- Comment #13 from Richard PALO ---
> [...]
> > otherwise, I'll have to port a more recent gdb because 7.6.1 balks under gcc
> > 4.9.1
> > m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63475
Bug ID: 63475
Summary: Postreload CSE propagates aliased memory operand
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63474
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473
Bug ID: 63473
Summary: Memory leak with ALLOCATABLE, INTENT(OUT) dummy
arguments.
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: major
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
Ian Lance Taylor changed:
What|Removed |Added
Attachment #33644|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63474
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63474
Bug ID: 63474
Summary: Optimizer bug causes crash on unaligned integer writes
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--- Comment #20 from Jeffrey A. Law ---
On 10/04/14 13:29, Teresa Johnson wrote:
>> Jeff, what is intended here - should we not be threading both of these paths?
>
> I have a patch to make the mark_threaded_blocks checking of paths work
> regardl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--- Comment #19 from Jeffrey A. Law ---
On 10/04/14 09:34, Teresa Johnson wrote:
>
> Looking at the code, I think it attempts to check for this case and
> prevent it but that code does not work in this case because of the
> order the paths are id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #20 from Ville Voutilainen ---
(In reply to Jason Merrill from comment #19)
> (In reply to Ville Voutilainen from comment #18)
> > to work just fine. Yet this particular test will not work with my
> > modifications, but works without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #8 from andi at firstfloor dot org ---
> only automatic vars may have a VALUE_EXPR, certainly not 'extern const' stuff.
It's an initializer for an automatic var in the source
func_52() {
struct S0 foo = { ... }
...
}
>
> W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #19 from Jason Merrill ---
(In reply to Ville Voutilainen from comment #18)
> to work just fine. Yet this particular test will not work with my
> modifications, but works without them (I just tested that).
Attach a preprocessed file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59717
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59717
--- Comment #3 from Marek Polacek ---
Author: mpolacek
Date: Tue Oct 7 17:49:46 2014
New Revision: 215979
URL: https://gcc.gnu.org/viewcvs?rev=215979&root=gcc&view=rev
Log:
PR c/59717
* c-decl.c (header_for_builtin_fn): New function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #18 from Ville Voutilainen ---
(In reply to Jason Merrill from comment #17)
> (In reply to Ville Voutilainen from comment #16)
> > > This one:
> > >
> > > #include
> > >
> > > template
> > > struct mytrait : public std::__and_,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759
--- Comment #5 from Douglas Mencken ---
Now I know it's question about non-well-supported NeXT Objective C ABIs.
Will try -fgnu-runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52278
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
Bug 56183 depends on bug 52278, which changed state.
Bug 52278 Summary: [4.8/4.9/5 Regression] [avr] inefficient register allocation
for SUBREGs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52278
What|Removed |
th any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
GCC Information:
gcc (GCC) 5.0.0 20141007 (experimental)
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@215970
138bc75d-0d04-0410-961f-82ee72b054a4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #17 from Jason Merrill ---
(In reply to Ville Voutilainen from comment #16)
> > This one:
> >
> > #include
> >
> > template
> > struct mytrait : public std::__and_,
> > std::integral_constant > __is_trivially_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #16 from Ville Voutilainen ---
(In reply to Ville Voutilainen from comment #15)
> (In reply to Jason Merrill from comment #14)
> > (In reply to Ville Voutilainen from comment #13)
> > > Hmm. The first of the two ICE tests still ICEs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #15 from Ville Voutilainen ---
(In reply to Jason Merrill from comment #14)
> (In reply to Ville Voutilainen from comment #13)
> > Hmm. The first of the two ICE tests still ICEs.
>
> Which test? None of the tests are ICEing for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63445
--- Comment #6 from Eric Botcazou ---
> Found new range for j_9: [i_15 + 1, +INF]
>
> Visiting statement:
> _6 = j_9 - i_15;
> Found new range for _6: [1, +INF(OVF)]
>
> i_15 could be negative and thus j_9 - i_15 could well overflow the input
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #14 from Jason Merrill ---
(In reply to Ville Voutilainen from comment #13)
> Hmm. The first of the two ICE tests still ICEs.
Which test? None of the tests are ICEing for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471
Bug ID: 63471
Summary: [5.0 Regression] unix.c:1906:10: error: implicit
declaration of function 'ttyname_r'
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61981
Daisuke Oka changed:
What|Removed |Added
CC||daisuke_oka at nanosoftware
dot bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61565
--- Comment #6 from Yvan Roux ---
Author: yroux
Date: Tue Oct 7 16:17:57 2014
New Revision: 215975
URL: https://gcc.gnu.org/viewcvs?rev=215975&root=gcc&view=rev
Log:
2014-10-07 Venkataramanan Kumar
Backport from trunk r209643, r211881.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54687
--- Comment #3 from Manuel López-Ibáñez ---
Author: manu
Date: Tue Oct 7 16:13:22 2014
New Revision: 215974
URL: https://gcc.gnu.org/viewcvs?rev=215974&root=gcc&view=rev
Log:
gcc/fortran/ChangeLog:
2014-10-06 Manuel López-Ibáñez
PR for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054
--- Comment #16 from Manuel López-Ibáñez ---
Author: manu
Date: Tue Oct 7 16:13:22 2014
New Revision: 215974
URL: https://gcc.gnu.org/viewcvs?rev=215974&root=gcc&view=rev
Log:
gcc/fortran/ChangeLog:
2014-10-06 Manuel López-Ibáñez
PR fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--- Comment #18 from Teresa Johnson ---
On Mon, Oct 6, 2014 at 10:15 PM, Teresa Johnson wrote:
> I'm going to finish testing my patch, which passes regular
> x86_64-unknown-linux-gnu bootstrap + regression tests. I am still
> trying to get the l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63470
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #7 from Richard Biener ---
(In reply to Andi Kleen from comment #6)
> I looked at this a bit more. It's definitely the nrv pass that causes the
> problem.
>
> When I disable it in the source code the 32bit version compiles correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #6 from Andi Kleen ---
I looked at this a bit more. It's definitely the nrv pass that causes the
problem.
When I disable it in the source code the 32bit version compiles correctly.
I also tried disabling the next pass (cfgcleanup), b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63470
Bug ID: 63470
Summary: [5 Regression] lto1: internal compiler error: in
estimate_edge_growth, at ipa-inline.h:308
Product: gcc
Version: 5.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63445
--- Comment #5 from rguenther at suse dot de ---
On Tue, 7 Oct 2014, manu at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63445
>
> --- Comment #4 from Manuel López-Ibáñez ---
> > i_15 could be negative and thus j_9 -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #18 from Ian Lance Taylor ---
> Well, maybe it was only a problem with tail recursion,
Note that because Go programs expect predictable results from runtime.Callers
and other stack backtracing functions, the Go frontend disables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59441
--- Comment #5 from Ilya Palachev ---
Suggested a patch that fixes this.
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00546.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63445
--- Comment #4 from Manuel López-Ibáñez ---
> i_15 could be negative and thus j_9 - i_15 could well overflow the input
> range at the +INF side. (i_15 is [-INF, j_5(D) + -1])
Actually, this is a very good point. There is indeed a potential inte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #13 from Ville Voutilainen ---
Hmm. The first of the two ICE tests still ICEs. It no longer stops my build,
though - and I don't quite understand why, because previously the build
ICEd when building the library pre-compiled headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63403
John David Anglin changed:
What|Removed |Added
Target Milestone|5.0 |---
--- Comment #2 from John David A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #13 from Richard PALO ---
[...]
> otherwise, I'll have to port a more recent gdb because 7.6.1 balks under gcc
> 4.9.1
> may be awhile before I have the time...
What port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56383
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056
--- Comment #16 from Jonathan Wakely ---
(In reply to Agustín Bergé from comment #15)
> (In reply to Jonathan Wakely from comment #14)
> > Agustin, do you have a copyright assignment?
>
> I do not have one. The attached is derived from libstdc+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63445
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464
--- Comment #5 from rguenther at suse dot de ---
On Tue, 7 Oct 2014, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464
>
> --- Comment #4 from Jakub Jelinek ---
> Created attachment 33658
> --> https://gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464
--- Comment #4 from Jakub Jelinek ---
Created attachment 33658
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33658&action=edit
gcc5-pr63464.patch
Updated patch for the switchconv, this time checking rtx costs.
As for reassoc, the problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352
--- Comment #13 from Richard PALO ---
Since this regresses on the same omnios (illumos) platform between gcc 4.7.3
and 4.8.1 are there some pointers on how to identify the issue in illumos?
(the fact the 4.8.1 tested is native omnios (R151012) el
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63466
--- Comment #4 from Jonathan Wakely ---
The calls you see to getc are nothing to do with , they're from the
std::getline call reading from stdin, and are required because you didn't tell
the C++ runtime that you don't need it to be synchronised w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62308
--- Comment #5 from Venkataramanan ---
Not able to reproduce with latest trunk r215964. Bisecting to find a revision
from which bug disappears.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63466
--- Comment #3 from Jonathan Wakely ---
You're comparing apples and oranges.
This function forces you to do additional allocations for the arguments, which
has nothing to do with iostream performance:
void __attribute__((noinline, noclone)) f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #20 from Jakub Jelinek ---
The builtin-types.def part is unnecessary, I don't see internal-fn.def part.
Also, we might need to tune optimizations across the two internal calls (from
aliasing POV at least), we certainly want them to ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #17 from Dominik Vogt ---
>> * Wouldn't the new patch re-introduce the bug that
>>
>> func foo(n int) {
>> if (n == 0) { recover(); } else { foo(0); }
>> }
>> func main() {
>> defer foo(1)
>> panic("...")
>> }
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61643
Ai Azuma changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61643
Ai Azuma changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #2 from Ai Azuma ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62258
--- Comment #5 from Ai Azuma ---
*** Bug 61643 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62258
Ai Azuma changed:
What|Removed |Added
CC||ai.azuma at gmail dot com
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409
--- Comment #10 from Martin Liška ---
Fixed in r215967.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63467
--- Comment #7 from Richard Biener ---
Why not use a label?
#define N 100
int a[N], b[N], c[N];
main()
{
static void *x __attribute__((used)) = &&bar;
int i;
for (i = 0; i < N; i++) {
bar:
a[i] = b[i] + c[i];
}
}
will get you
.L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #19 from rguenther at suse dot de ---
On Mon, 6 Oct 2014, hubicka at ucw dot cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
>
> --- Comment #11 from Jan Hubicka ---
> Hi,
> this patch implements the lowring. Each c
95 matches
Mail list logo
