https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #5 from Tom Tromey ---
But, curiously, in this case it points to the RHS of the assignment
(I still tend to think the "=" is the best location):
extern void *alloc (void);
int *f (void) {
int *r = alloc ();
return r;
}
barimba.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #4 from Tom Tromey ---
Note that it is also wrong in the initializer case.
enum e f(void)
{
enum e result = 0;
return result;
}
barimba. gcc --syntax-only -Wc++-compat r.c
r.c: In function ‘f’:
r.c:5:8: warning: enum conversio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60858
--- Comment #2 from SwissP ---
Andrew,
> Also patches go to gcc-patches@ and should include a testcase or two.
Not familiar with the bugzilla interface I could
not find where "gcc-patches@" resides on the site.
Can you give me a link to the r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61165
--- Comment #1 from Tom Tromey ---
Also, note what happens if one changes the body of the function:
extern void *allocate (int);
#define my_alloc(X) allocate (X)
int *alloc_int(void)
{
return my_alloc(sizeof (int));
}
barimba. gcc --syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61165
Bug ID: 61165
Summary: unfriendly diagnostic from macro expansion
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: prep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61035
Janne Blomqvist changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #3 from Marek Polacek ---
I posted a patch, but the location for a return stmt will need more surgery
than that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #2 from Tom Tromey ---
Note that it is also wrong for a conversion diagnosed
in a "return":
enum e { ZERO = 0, ONE };
enum e f(void)
{
return 0;
}
barimba. gcc --syntax-only -Wc++-compat r.c
r.c: In function ‘f’:
r.c:5:3: warnin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61164
Bug ID: 61164
Summary: GCC 4.9.0 fails to build libitm with fortification
enabled
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61163
Bug ID: 61163
Summary: Placement arguments shared between allocation and
deallocation even when copies prohibited
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
Bug ID: 61162
Summary: possibly bad error location with -Wc++-compat
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
--- Comment #15 from Rich Felker ---
Can you clarify? As far as I can tell, the other bug is a missed optimization
and this is an overly-aggressive, incorrect optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10437
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12944
Bug 12944 depends on bug 61161, which changed state.
Bug 61161 Summary: wrong two-stage name lookup for overloaded operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61161
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61161
Richard Smith changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038
emsr at gcc dot gnu.org changed:
What|Removed |Added
Attachment #32783|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54537
--- Comment #4 from Peter Bergner ---
Author: bergner
Date: Mon May 12 23:08:22 2014
New Revision: 210344
URL: http://gcc.gnu.org/viewcvs?rev=210344&root=gcc&view=rev
Log:
Reapply the old IBM 4.8 branch patches that are not upstream.
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60735
--- Comment #15 from Peter Bergner ---
Author: bergner
Date: Mon May 12 23:08:22 2014
New Revision: 210344
URL: http://gcc.gnu.org/viewcvs?rev=210344&root=gcc&view=rev
Log:
Reapply the old IBM 4.8 branch patches that are not upstream.
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60672
--- Comment #7 from Peter Bergner ---
Author: bergner
Date: Mon May 12 23:08:22 2014
New Revision: 210344
URL: http://gcc.gnu.org/viewcvs?rev=210344&root=gcc&view=rev
Log:
Reapply the old IBM 4.8 branch patches that are not upstream.
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60373
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61161
--- Comment #1 from Jonathan Wakely ---
Maybe related to PR51577
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038
--- Comment #9 from Daniel Krügler ---
(In reply to Ben Longbons from comment #8)
> What about multi-char constants, or are they not permitted in C++ UDLs?
> Normally they get converted to int, so they're not *meaningful*, but ...
There exists a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038
--- Comment #8 from Ben Longbons ---
(In reply to Ed Smith-Rowland from comment #7)
> Note to self: you DO need to take care of char...
What about multi-char constants, or are they not permitted in C++ UDLs?
Normally they get converted to int, s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31778
mrs at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31778
--- Comment #4 from mrs at gcc dot gnu.org ---
Author: mrs
Date: Mon May 12 21:22:20 2014
New Revision: 210340
URL: http://gcc.gnu.org/viewcvs?rev=210340&root=gcc&view=rev
Log:
PR other/31778
* genattrtab.c (filename): Add.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038
--- Comment #7 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
Note to self: you DO need to take care of char...
void
operator "" _t(const char)
{
}
#define QUOTE(s) #s
int
main()
{
QUOTE('"'_t);
QUOTE('\''_t);
QUOTE('\\'_t);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61161
Bug ID: 61161
Summary: wrong two-stage name lookup for overloaded operators
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
--- Comment #14 from Marc Glisse ---
This seems related to PR 59948 where Honza says the code is "really broken".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61160
--- Comment #1 from Zdenek Sojka ---
Created attachment 32786
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32786&action=edit
testcase causing ICE
Slightly modified, "struct A" replaced by "void *".
Compiler output:
$ g++ -O3 testcase.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61160
Bug ID: 61160
Summary: [4.9/4.10 Regression] wrong code with -O3 (or ICE:
verify_cgraph_node failed: edge points to wrong
declaration)
Product: gcc
Version: 4.10.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61159
--- Comment #1 from Rich Felker ---
I should amend this report with further info: __builtin_constant_p is giving
different results for dummy and foo depending on whether it's used at file
scope or in a function. I've also observed some other reall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438
--- Comment #9 from D. Hugh Redelmeier ---
Created attachment 32784
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32784&action=edit
minimal C source code that demonstrates the problem
minimal C source code that demonstrates the problem.
Not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61035
--- Comment #3 from Janne Blomqvist ---
Author: jb
Date: Mon May 12 19:23:11 2014
New Revision: 210335
URL: http://gcc.gnu.org/viewcvs?rev=210335&root=gcc&view=rev
Log:
Fix stack overflow crash in getcwd intrinsic.
2014-05-12 Janne Blomqvist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60127
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
--- Comment #13 from Rich Felker ---
I've added the related issue 61159.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60127
--- Comment #4 from Tobias Burnus ---
Author: burnus
Date: Mon May 12 19:00:08 2014
New Revision: 210331
URL: http://gcc.gnu.org/viewcvs?rev=210331&root=gcc&view=rev
Log:
2014-05-12 Tobias Burnus
PR fortran/60127
* openmp.c (r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038
--- Comment #6 from Paolo Carlini ---
Please send your patches, questions, etc, about this and the other bug to the
mailing list, with Jason in CC, otherwise we seriously risk unnecessarily
delaying the resolution of the issues.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60588
Charles Lohr changed:
What|Removed |Added
CC||charles at cnlohr dot com
--- Comment #1 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61159
Bug ID: 61159
Summary: __builtin_constant_p gives incorrect results with
aliases
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61158
Bug ID: 61158
Summary: negative shift at fold-const.c:12095
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
As
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038
--- Comment #5 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
I'm pretty sure I have my arms around this one.
Two questions:
1. Any ideas on how to make testsuite cases? Any examples of looking at
preprocessed files in the testsuite?
2. As
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61157
Bug ID: 61157
Summary: [SH] Implement TARGET_ATOMIC_ASSIGN_EXPAND_FENV
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
--- Comment #12 from Rich Felker ---
Furthermore, __builtin_constant_p(dummy) wrongly returns 1, even though dummy
is modifiable externally via foo (assuming foo is not replaced by a strong
definition elsewhere). Perhaps this should be filed as a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61131
--- Comment #5 from Mikael Pettersson ---
(In reply to Stephen Warren from comment #3)
> Or is the definition of
> undefined such that it propagates through the entire expression irrespective
> of the expression's logic?
It is. Once execution hi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126
--- Comment #17 from Matthias Klose ---
patch posted at
http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00785.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60834
--- Comment #3 from Thomas Koenig ---
Author: tkoenig
Date: Mon May 12 16:17:09 2014
New Revision: 210329
URL: http://gcc.gnu.org/viewcvs?rev=210329&root=gcc&view=rev
Log:
2014-05-12 Thomas Koenig
PR fortran/60834
* frontend-passes.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60991
--- Comment #6 from denisc at gcc dot gnu.org ---
Author: denisc
Date: Mon May 12 16:07:44 2014
New Revision: 210328
URL: http://gcc.gnu.org/viewcvs?rev=210328&root=gcc&view=rev
Log:
Backport from mainline
2014-05-12 Senthil Kumar Selvara
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61154
--- Comment #3 from rsandifo at gcc dot gnu.org
---
This code is doing an OImode ASHIFT and fails the check:
#if TARGET_SUPPORTS_WIDE_INT == 0
/* This assert keeps the simplification from producing a result
that cannot be represented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60991
--- Comment #5 from denisc at gcc dot gnu.org ---
Author: denisc
Date: Mon May 12 15:57:52 2014
New Revision: 210327
URL: http://gcc.gnu.org/viewcvs?rev=210327&root=gcc&view=rev
Log:
Backport from mainline
2014-05-12 Senthil Kumar Selvara
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to D. Hugh Redelmeier from comment #6)
> > If you can produce another similar example that works with printf, that
> > would also help.
>
> I don't think that printf is similar enough. A str
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60300
--- Comment #5 from Matthijs Kooijman ---
Ah, then the comments are a bit misleading, yes. Wouldn't it make sense to put
this decision outside of avr_sp_immediate_operand, in the same area where the
decision between the two options is made? Might
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to D. Hugh Redelmeier from comment #6)
> > The best would be to include only the definitions of the types that you
> > need > and declare as 'extern' library functions that you use to avoid
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60991
--- Comment #4 from denisc at gcc dot gnu.org ---
Author: denisc
Date: Mon May 12 15:33:00 2014
New Revision: 210325
URL: http://gcc.gnu.org/viewcvs?rev=210325&root=gcc&view=rev
Log:
gcc/ChangeLog
PR target/60991
* config/avr/avr.c (avr_o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
--- Comment #11 from Rich Felker ---
Adding __attribute__((__used__)) to the static object suppresses the symptom in
case that helps to isolate what's causing it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438
--- Comment #6 from D. Hugh Redelmeier ---
Responding to Comment 5 by Manuel López-Ibáñez:
Thanks for looking at this.
> Could you produce a complete testcase
===
/* compile with -c -Wformat -Werror=format-nonliteral */
#include
extern void pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038
emsr at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61156
Bug ID: 61156
Summary: Internal compiler error for Fortran files when
specifying a file instead of an include directory with
-I
Product: gcc
Version: 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59537
--- Comment #6 from Lorenz Hüdepohl ---
>> Nonetheless, code that compiles without -finit-real should also compile
>> with -finit-real, right?
>
> I disagree: C506 states that automatic object cannot be initialized. What is
> wrong is that it dep
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6273
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61147
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038
--- Comment #3 from emsr at gcc dot gnu.org ---
Created attachment 32782
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32782&action=edit
g++ -std=c++11 -E pr61038.C > pr61038_cxx11.ii
Get preprocessed output in C++11 mode.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038
--- Comment #2 from emsr at gcc dot gnu.org ---
Created attachment 32781
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32781&action=edit
g++ -E pr61038.C > pr61038_cxx98.ii
Get preprocessed output in C++98 mode.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54108
wbrana changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
--- Comment #10 from James Cloos ---
My tests on debian sid with GCC: (Debian 4.8.2-21) 4.8.2 do not replicate the
bug.
On debian sid, only 4.9 and gcc-snapshot (the 4.10 branch) show the bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60209
emsr at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60209
--- Comment #3 from emsr at gcc dot gnu.org ---
Created attachment 32779
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32779&action=edit
Just parse a whole string instread of consuming one token.
This builds and tests clean on x86_64-linux.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61154
Ramana Radhakrishnan changed:
What|Removed |Added
Keywords||ice-on-valid-code
Targ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61154
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61155
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61155
--- Comment #1 from Ramana Radhakrishnan ---
These also look related to the same
FAIL: gcc.dg/torture/vshuf-v32qi.c -O2 (internal compiler error)
FAIL: gcc.dg/torture/vshuf-v32qi.c -O2 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61155
Bug ID: 61155
Summary: vshuf-v16hi failures for arm-none-linux-gnueabihf
since the wide-int merge.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60300
Senthil Kumar Selvaraj changed:
What|Removed |Added
CC||senthil_kumar.selvaraj@atme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
--- Comment #9 from Jody Lee Bruchon ---
For my gcc versions (x86_64) compiled from release sources, I have the
following for this testcase, with and without static, using -O2:
=== gcc 4.8.2, with and without static ===
$ gcc -v
Using built-in s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153
--- Comment #8 from ramana.radhakrishnan at arm dot com ---
>
> How do we define "cases where we need them"? My concern is that some compiler
> change might cause a suboptimal-yet-functional code to be generated, and we
> wouldn't notice it.
>
We
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153
--- Comment #7 from christophe.lyon at st dot com ---
(In reply to Ramana Radhakrishnan from comment #5)
> > Do we plan to keep these scan-assembler tests? or go with just functional
> > tests?
>
> No, not these scan assembler tests. They serve no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153
--- Comment #6 from christophe.lyon at st dot com ---
(In reply to Ramana Radhakrishnan from comment #4)
> Yes that is expected as per my original patch submission. Patch 1/3 said
> these tests would fail because at O0 combine doesn't run.
Indeed,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153
--- Comment #5 from Ramana Radhakrishnan ---
> Do we plan to keep these scan-assembler tests? or go with just functional
> tests?
No, not these scan assembler tests. They serve no purpose.
I'm expecting them to get replaced by the testsuite yo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153
--- Comment #3 from ktkachov at gcc dot gnu.org ---
> So maybe we should add some optimization level to the existing tests in the
> meantime?
Transforming them into something like
#include "arm_neon.h"
volatile int16x8_t arg0_int16x8_t;
volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153
--- Comment #2 from christophe.lyon at st dot com ---
OK, but my tests currently don't inspect the generated code.
They are execution tests, which means the could be PASS using only core
instructions, and no Neon one.
So maybe we should add some
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61154
Bug ID: 61154
Summary: [ARM] wide-int merge introduced regressions in vshuf
tests
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
--- Comment #8 from Rich Felker ---
Further investigation suggests that the real gcc 4.8.2 is not affected; I was
mislead by the fact that Debian is shipping as "gcc-4.8_4.8.2-21" an svn
snapshot that's actually post-4.8.2. So 4.9.0 seems to be th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Assignee
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153
Bug ID: 61153
Summary: [ARM] vbic vorn tests fail
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assig
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61141
--- Comment #4 from John David Anglin ---
(gdb) p *fn
$5 = {eh = 0xfa483f48, cfg = 0xf7f60a10, gimple_body = 0x0,
gimple_df = 0xf7ba6900, x_current_loops = 0x0, su = 0x0,
value_histograms = 0x0, decl = 0xf8f39100, static_chain_decl = 0x0,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904
--- Comment #3 from christophe.lyon at st dot com ---
Sorry I no longer have the elf file available.
I've just looked at the current trunk status and I have a failure at link time
for these tests:
ld: gcc_tg.o: relocation R_ARM_MOVW_ABS_NC against
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61141
--- Comment #3 from John David Anglin ---
(gdb) p *pass
$4 = { = {type = RTL_PASS, name = 0x1afa7c0 "final",
optinfo_flags = 0, has_execute = true, tv_id = TV_FINAL,
properties_required = 0, properties_provided = 0,
properties_destr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61141
--- Comment #2 from John David Anglin ---
In the Linux case, we also have a note in a NOTE_INSN_DELETED delayed
branch sequence:
(gdb) ignor 1 9396470
Will ignore next 9396470 crossings of breakpoint 1.
(gdb) r
Starting program: /home/dave/gnu/gc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60617
--- Comment #4 from Venkataramanan ---
Reverting this patch in 209897 bug still occurs in trunk with -mno-lra.
SPILL failure occurs for regno 110 ("dst" operand) in below instruction
(insn 634 633 635 27 (parallel [
(set (reg:SI 3 r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61058
--- Comment #7 from Jakub Jelinek ---
On the other side, pass_cleanup_barriers is performed after pass_free_cfg, so
making it unconditionally cfg-aware is not going to work, it is just that i386
(as well as few other targets) calls compute_bb_for_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60617
--- Comment #3 from Venkataramanan ---
The bug is now hidden in trunk by revision 209897
The patch "Remove PUSH_ARGS_REVERSED from the RTL expander"
(reference below) seems to change the way arguments are handled in RTL.
Ref:
http://gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61058
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152
Bug ID: 61152
Summary: Missing GCC Runtime Library Exception in some files
that are included in libgcc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61143
--- Comment #6 from Marc Glisse ---
There was that whole discussion on how much sense it makes to make move
constructors noexcept when default constructors aren't...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6273
--- Comment #17 from Paolo Carlini ---
... of course I meant that dependent_type_p returns true for enum E therein.
1 - 100 of 102 matches
Mail list logo
