/gcc-trunk
--with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk
--with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20131107 (experimental) [trunk revision 204540] (GCC)
$
$ gcc-trunk -O2 small.c; a.out
1
$ gcc-4.8.2 -O3 small.c; a.out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019
--- Comment #5 from Jeffrey A. Law ---
Always considering trap-if as ending a BB appears to be a bit of a rathole.
Every time I squash one issue, another raises its head.
I did find that combine.c already has some bits to recognize when it does
case…
/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131107/gcc/testsuite/c-c++-common/asan/global-overflow-1.c
-B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48110
Mingjie Xing changed:
What|Removed |Added
CC||mingjie.xing at gmail dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18969
--- Comment #4 from Manuel López-Ibáñez ---
Breakpoint 5, check_return_expr (retval=,
no_warning=0x7fffdf2f) at /home/manuel/test1/src/gcc/cp/typeck.c:8311
B =>if (processing_template_decl)
{
current_function_returns_value = 1;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18969
--- Comment #3 from Manuel López-Ibáñez ---
It works in clang:
test.cc:3:16: error: void function 'foo' should not return a value
[-Wreturn-type]
void foo() { return 0; }
^ ~
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56764
--- Comment #4 from congh at gcc dot gnu.org ---
Author: congh
Date: Fri Nov 8 02:08:05 2013
New Revision: 204557
URL: http://gcc.gnu.org/viewcvs?rev=204557&root=gcc&view=rev
Log:
2013-11-07 Cong Hou
Backport from mainline
2013-11-07
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59044
Bug ID: 59044
Summary: Internal compiler error triggers when accessing a
typedef in a specialized member class
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #15 from H.J. Lu ---
(In reply to Eric Botcazou from comment #14)
> > This is good to hear. What is each field? I assume that
> > the first 3 fields are frame address, resume address and
> > stack address. Are the same for all targe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #14 from Eric Botcazou ---
> This is good to hear. What is each field? I assume that
> the first 3 fields are frame address, resume address and
> stack address. Are the same for all targets? What are
> the maximum number of fields?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58471
--- Comment #6 from janus at gcc dot gnu.org ---
Author: janus
Date: Thu Nov 7 22:39:15 2013
New Revision: 204547
URL: http://gcc.gnu.org/viewcvs?rev=204547&root=gcc&view=rev
Log:
2013-11-07 Janus Weil
PR fortran/58471
* primary.c (gf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58471
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|una
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59043
Bug ID: 59043
Summary: [4.9 Regression] FAIL: (gcc|++).dg/pubtypes*
scan-assembler long.*Length of Public Type Names Info
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #2 from Dominique d'Humieres ---
Note that the tests pass on x86_64-apple-darwin10 for both -m32 and -m64.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58984
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59037
--- Comment #3 from Marc Glisse ---
(In reply to Matthew Leach from comment #1)
> Having a quick dig around the code, I think fold-const.c:16718 looks
> suspicious:
>
> if (offset/part_widthi <= TYPE_VECTOR_SUBPARTS (op00type))
>
> Likewise in c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56764
--- Comment #3 from congh at gcc dot gnu.org ---
Author: congh
Date: Thu Nov 7 19:29:45 2013
New Revision: 204538
URL: http://gcc.gnu.org/viewcvs?rev=204538&root=gcc&view=rev
Log:
2013-11-07 Cong Hou
PR tree-optimization/56764
* tree-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59042
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59042
--- Comment #2 from Jonathan Wakely ---
Your code is not valid, you should be using typename
iterator_traits::value_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56764
Cong Hou changed:
What|Removed |Added
CC||congh at google dot com
--- Comment #2 from Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59042
--- Comment #3 from Jonathan Wakely ---
And in [back.insert.iterator] the standard explicitly requires this:
template
class back_insert_iterator :
public iterator{
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59027
--- Comment #6 from Jonathan Wakely ---
(In reply to Marc Mutz from comment #0)
> According to N3797 Table 49, both is_signed and is_unsigned should evaluate
> to true_type only if the argument is_arithmetic, too. is_unsigned honours
> this, but i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59042
--- Comment #1 from Chris Dodd ---
The other type traits of back_insert_iterator should probably not be void, as
well.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59042
Bug ID: 59042
Summary: Declaration of back_insert_iterator::value_type is
incorrect
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59027
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #13 from H.J. Lu ---
(In reply to Eric Botcazou from comment #12)
> No, __builtin_longjmp doesn't touch %rdi at all. Don't worry too much, the
> SJLJ mechanism of the C++ and Ada compilers has been piggybacked on this for
> a couple o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59027
--- Comment #4 from Daniel Krügler ---
(In reply to Marc Mutz from comment #3)
> See code posted in http://llvm.org/bugs/show_bug.cgi?id=17834
> is_unsigned fails, !is_signed succeeds. MouseButton is an enum.
The assertion of the following code i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59041
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59027
Marc Mutz changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019
--- Comment #4 from Eric Botcazou ---
> The problem I see where is we're going to have to run some kind of cleanup
> pass after each RTL pass that might make these transformations (cse, gcse,
> cprop, combine and I'm sure others). That seems quit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #12 from Eric Botcazou ---
> %rdi holds the function parameter 'i'. But when __builtin_longjmp is
> called, %rdi can have some random value. GCC doesn't save %rdi first.
No, __builtin_longjmp doesn't touch %rdi at all. Don't worry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019
--- Comment #3 from Jeffrey A. Law ---
OK, making a conditional no-return call into an unconditional no-return call
would have the same problem. Ugh.
The problem I see where is we're going to have to run some kind of cleanup pass
after each RTL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59041
--- Comment #1 from Uroš Bizjak ---
This one is not unnecessary, it is emitted on purpose from generic
mode-switching code:
-- gcc/mode-switching.c --
/* Pretend the mode is clobbered across abnormal edges. */
{
edge_iterato
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59041
Bug ID: 59041
Summary: [4.8/4.9 Regression] Unnecessary vzeroupper generated
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #11 from Andreas Schwab ---
In the latter testcase foo doesn't call a function so there is never a need to
save anything.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #10 from H.J. Lu ---
(In reply to Eric Botcazou from comment #9)
> > What restrictions do they have? Can they be used within the
> > same function? Can they be used within functions with parameters?
>
> The only restriction I know of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59025
--- Comment #4 from Peter Bergner ---
Pat was working on that. He reported to me that he had gone through compiling
each file with the "bad" options and did not hit the error, so it seems it is
an interaction between multiple files and he was in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #9 from Eric Botcazou ---
> What restrictions do they have? Can they be used within the
> same function? Can they be used within functions with parameters?
The only restriction I know of is that they cannot be in the same function,
it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59036
--- Comment #2 from Vladimir Makarov ---
(In reply to Yuri Rumyantsev from comment #0)
> After patch to improve register preferencing in IRA and to *remove regmove*
> pass we noticed performance degradation on several benchmarks from eembc2.0
> su
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #8 from H.J. Lu ---
(In reply to Eric Botcazou from comment #7)
> > Ah, those are the builtins used for SJLJ and they get lowered to
> > setjmp_setup,dispatcher and longjmp.
>
> Right, they are the efficient version of setjmp/longjmp.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #7 from Eric Botcazou ---
> Ah, those are the builtins used for SJLJ and they get lowered to
> setjmp_setup,dispatcher and longjmp.
Right, they are the efficient version of setjmp/longjmp.
> I suppose these shouldn't have been made c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #6 from H.J. Lu ---
(In reply to Richard Biener from comment #4)
> Ah, those are the builtins used for SJLJ and they get lowered to
> setjmp_setup,dispatcher and longjmp.
>
> Don't use __builtin_setjmp as I said, use setjmp.
>
> I su
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #5 from Richard Biener ---
But it seems cilk depends on implementation details of setjmp/longjmp which
looks bogus anyway.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
Richard Biener changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59037
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #2 from Richard Biener ---
I suppose
// alloca() to force generation of frame pointer. The argument to alloca
// is contrived to prevent the compiler from optimizing it away. This
// code should never actually be execute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #1 from Richard Biener ---
__builtin_longjmp/setjmp are just longjmp(3) setjmp(3) with their constraints.
They should not be used directly but should be.
The file looks scary.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58176
--- Comment #3 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Thu Nov 7 14:26:17 2013
New Revision: 204514
URL: http://gcc.gnu.org/viewcvs?rev=204514&root=gcc&view=rev
Log:
2013-11-07 Paolo Carlini
PR c++/58176
* varasm.c (out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58176
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|jason at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853
--- Comment #6 from H.J. Lu ---
This
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 53e04c4..dd8d943 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -23766,6 +23766,7 @@ ix86_expand_set_or_movmem (rtx dst,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59040
--- Comment #6 from octoploid at yandex dot com ---
(In reply to octoploid from comment #5)
> (In reply to H.J. Lu from comment #2)
> > (In reply to Igor Zamyatin from comment #1)
> > > Dup of 58853
> >
> > There is no PR58853.
>
> Looks like a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59040
octoploid at yandex dot com changed:
What|Removed |Added
CC||octoploid at yandex dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #5 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59040
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59040
--- Comment #3 from Igor Zamyatin ---
Hmm... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59040
--- Comment #2 from H.J. Lu ---
(In reply to Igor Zamyatin from comment #1)
> Dup of 58853
There is no PR58853.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59035
--- Comment #2 from joseph at codesourcery dot com ---
If -ffp-contract=off is set for any object (whether explicitly, or
implicitly by an option such as -std=c99), the safe option for LTO would
be to set -ffp-contract=off at link time as well.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56710
--- Comment #3 from Jonathan Wakely ---
That testcase shows this is an ice-on-valid-code bug. Reduced:
struct Dummy {
void getDummy() const { }
};
template
void eachDummy(F closure) {
Dummy d;
closure(d);
}
template
void iterateD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59040
Igor Zamyatin changed:
What|Removed |Added
CC||izamyatin at gmail dot com
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59040
Bug ID: 59040
Summary: [4.9 Regression] r203937 caused: FAIL:
gcc.dg/torture/memcpy-1.c -O0 (internal compiler
error)
Product: gcc
Version: 4.9.0
Sta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59038
--- Comment #1 from Richard Biener ---
extern void abort (void);
unsigned char first_ones_8bit[256];
unsigned char connected_passed[256];
int
main ()
{
int i, j;
for (i=0;i<256;i++){
connected_passed[i]=0;
first_ones_8bit[i]=0;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59027
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
Bug ID: 59039
Summary: Undocumented __builtin_longjmp/__builtin_setjmp
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58176
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59029
--- Comment #6 from Yury Gribov ---
(In reply to Jakub Jelinek from comment #5)
> Note, patches should still go to gcc-patches, even when you just say in
> subject
> [committed] and in the description that it has been preapproved in the PR.
Got i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59037
jgreenhalgh at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59037
--- Comment #1 from Matthew Leach ---
Having a quick dig around the code, I think fold-const.c:16718 looks
suspicious:
if (offset/part_widthi <= TYPE_VECTOR_SUBPARTS (op00type))
Likewise in cp/semantics.c:9122 and gimple-fold.c:3407.
Should thi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59038
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59038
Bug ID: 59038
Summary: [4.9 Regression] r204398 causes 186.crafty init.c to
be miscompiled
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: wrong-code
d model: posix
gcc version 4.9.0 20131107 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mtune=generic' '-march=x86-64'
/work/gcc-trunk/gcc/install-native/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1
-E -quiet -v -imultilib .
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59030
--- Comment #5 from Volker Reichelt ---
The offending patch got reverted:
http://gcc.gnu.org/ml/gcc-cvs/2013-11/msg00212.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59033
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59029
--- Comment #5 from Jakub Jelinek ---
(In reply to ygribov from comment #4)
> URL: http://gcc.gnu.org/viewcvs?rev=204508&root=gcc&view=rev
> Log:
> Allow integer literals as addresses in instrumented builtins.
Note, patches should still go to gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59029
--- Comment #4 from ygribov at gcc dot gnu.org ---
Author: ygribov
Date: Thu Nov 7 12:04:45 2013
New Revision: 204508
URL: http://gcc.gnu.org/viewcvs?rev=204508&root=gcc&view=rev
Log:
Allow integer literals as addresses in instrumented builtins.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59033
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59027
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59025
--- Comment #3 from Jakub Jelinek ---
Can you please narrow it down to a file and routine? I guess I can look at it
afterwards using cross-compilers, the patch wasn't meant do any code generation
changes, only that sometimes a new stmt is created
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59025
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.0
Summary|Revision 203979
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59014
Marek Polacek changed:
What|Removed |Added
Keywords||wrong-code
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59030
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.8.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59034
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59031
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.8.3
Summary|vtable lookup n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59035
Richard Biener changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
Target Milest
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59036
Richard Biener changed:
What|Removed |Added
Target||i?86-*-*
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|gdr at gcc dot gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16386
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|gcc-bugs at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10619
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12277
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59036
--- Comment #1 from Yuri Rumyantsev ---
Created attachment 31178
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31178&action=edit
test-case to reproduce
test need to be compiled with -m32 option for any x86 targets.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59036
Bug ID: 59036
Summary: [4.9 regression] Performance degradation after r204212
on 32-bit x86 targets.
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59029
--- Comment #3 from Jakub Jelinek ---
(In reply to Yury Gribov from comment #2)
> Created attachment 31177 [details]
> Draft patch
>
> Aha, looks like the ICE is caused by destination address being INTEGER_CST
> instead of ADDR_EXPR. Attached pat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2778
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59034
--- Comment #5 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Thu Nov 7 10:09:49 2013
New Revision: 204503
URL: http://gcc.gnu.org/viewcvs?rev=204503&root=gcc&view=rev
Log:
Use Pmode with stack_pointer_rtx
Backport from mainline
PR t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59029
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59034
--- Comment #4 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Thu Nov 7 10:05:07 2013
New Revision: 204502
URL: http://gcc.gnu.org/viewcvs?rev=204502&root=gcc&view=rev
Log:
Use Pmode with stack_pointer_rtx
gcc/
Backport from mainline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59034
--- Comment #3 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Thu Nov 7 09:58:05 2013
New Revision: 204501
URL: http://gcc.gnu.org/viewcvs?rev=204501&root=gcc&view=rev
Log:
Use Pmode with stack_pointer_rtx
gcc/
PR target/59034
* con
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59035
Bug ID: 59035
Summary: FAIL: gcc.dg/torture/c99-contract-1.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none execution
test
Product: gcc
Version: 4.9.0
1 - 100 of 103 matches
Mail list logo
