http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58006
Marc Glisse changed:
What|Removed |Added
Status|WAITING |NEW
Summary|ICE regression compi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57945
Marc Glisse changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58006
--- Comment #5 from Marc Glisse ---
extern "C" float sqrtf (float);
extern int a;
extern int b;
struct Vector {
float i;
float j;
float Magnitude() const {
return sqrtf( i*i+j*j );
}
};
void f(){
int i = a;
int end = b;
for (;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58019
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58223
Marc Glisse changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58236
--- Comment #1 from Marc Glisse ---
Note, from the documentation of -Wuninitialized:
"Because these warnings depend on optimization, the exact variables or elements
for which there are warnings depends on the precise optimization options and
vers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53025
--- Comment #4 from Marc Glisse ---
(In reply to Daniel Krügler from comment #3)
> IMO it is important to fix at, because otherwise
> it does have the potential to subtly change overload selection (if noexcept
> is used as part of sfinae) and othe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58240
--- Comment #4 from Marc Glisse ---
-fno-builtin (or some better such option)?
strncmp is a standard function, your code redefining it has undefined behavior.
gcc optimizes based on the standard behavior of the function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58240
--- Comment #11 from Marc Glisse ---
(In reply to shiyan from comment #7)
> Thank you for the suggestion. Yes, I know -fno-builtin can work around it. I
> can think of many possible ways to work around itbut whatever, it is a
> bug.
in your c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58244
--- Comment #3 from Marc Glisse ---
With auxval local, the compiler knows that computing suma, etc is useless and
removes all that code, including the calls to sin. So you would like the
compiler to do the same for a global auxval? That requires t
||glisse at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #2 from Marc Glisse ---
r202021 | glisse | 2013-08-27 14:39:21 +0200 (Tue, 27 Aug 2013) | 7 lines
2013-08-27 Marc Glisse
PR middle-end/57219
* doc/extend.texi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58275
--- Comment #1 from Marc Glisse ---
Where do you see a bug? The test argc!=23 is always true in this branch, so it
*is* a compile-time constant. It is very much on purpose that
__builtin_constant_p returns true.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58210
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54855
--- Comment #8 from Marc Glisse ---
Just adding a link to the latest message of the conversation, for future
reference:
http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00824.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51965
--- Comment #9 from Marc Glisse ---
Most recent discussion about this:
http://gcc.gnu.org/ml/libstdc++/2013-07/msg00105.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
--- Comment #13 from Marc Glisse ---
Without adding an attribute, can we identify those operator new that may not
return 0? Is DECL_IS_OPERATOR_NEW && !TREE_NOTHROW good enough, or completely
wrong? I am basing this on:
"If the request succeeds,
: enhancement
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Hello,
the standard only requires a noexcept specifier on functions with a wide
contract, to allow some debug implementations of functions with a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340
--- Comment #5 from Marc Glisse ---
(In reply to Jeffrey A. Law from comment #3)
> Just to be sure, what version of the trunk are both of you using?
202346 for me. Configured with --prefix=... --with-system-zlib --disable-nls
--enable-libstdcxx-t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58210
--- Comment #4 from Marc Glisse ---
Now that PR 58137 is fixed, can you still reproduce? Note that not everyone has
access to spec benchmarks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58244
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50385
--- Comment #2 from Marc Glisse ---
This seems to work on current trunk. Can you confirm, and if so close the PR?
(well, we may want to add the testcases)
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
void f(int*q){
int*p=(int*)__builtin_assume_aligned(q,32);
for(int i=0;i<(1<<20);++i){
if(p+i==0)__builtin_unreachable();
: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
void f (long s) { }
y.cc:1:6: warning: unused parameter 's' [-Wunused-parameter]
void f (long s) { }
^
Note the column information, which should point to s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58362
--- Comment #2 from Marc Glisse ---
(In reply to Paolo Carlini from comment #1)
> Maybe it's just me, but I don't understand what -ignored- means in this
> context, could you please explain?
It means that the diagnostic machinery takes the column
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
--- Comment #11 from Marc Glisse ---
(In reply to Daniel Krügler from comment #9)
> Shouldn't the library be able to use the new diamond operators
> (specializations in void) that use perfect forwarding for both arguments and
> result? User-code c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58362
--- Comment #6 from Marc Glisse ---
(In reply to Paolo Carlini from comment #4)
> The damage happens at error.c:3435.
Yes, location_of replaces the declaration of the argument with that of the
function :-(
> Should we just use "%qD", no '+' ?
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
--- Comment #12 from Marc Glisse ---
Chris, did you consider applying this optimized code to bidirectional iterators
and not just random access iterators? We may end up doing a few more ++/-- than
necessary, but not by more than a factor 2 I belie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58365
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58364
Marc Glisse changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58385
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58374
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
||glisse at gcc dot gnu.org,
||redi at gcc dot gnu.org
Resolution|DUPLICATE |---
--- Comment #2 from Marc Glisse ---
I am separating this PR from PR 19476 because it really isn't the same at all.
Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
--- Comment #15 from Marc Glisse ---
I posted a patch:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00676.html
However, note that it only optimizes the testcase from this PR if we add
#include at the beginning, otherwise the implicit declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
--- Comment #16 from Marc Glisse ---
(In reply to Marc Glisse from comment #15)
> However, note that it only optimizes the testcase from this PR if we add
> #include at the beginning, otherwise the implicit declaration of
> operator new doesn't h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35878
Marc Glisse changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58412
--- Comment #1 from Marc Glisse ---
It's already the case in recent versions, isn't it?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58412
--- Comment #2 from Marc Glisse ---
I think you forgot () after quiet_NaN and got confused by the error message.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #19 from Marc Glisse ---
(In reply to Jeffrey A. Law from comment #18)
> I'll also note that the plan for the isolated paths that exhibit undefined
> behaviour is to have them trap/abort at the statement which triggers the
> undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #21 from Marc Glisse ---
Thanks Jeff, sounds great :-)
Even if we mark that a statement is not reachable, we probably won't eliminate
many functions with side-effects executed before, since (I guess) we must be
able to prove that they
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58417
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56873
Marc Glisse changed:
What|Removed |Added
Component|tree-optimization |middle-end
--- Comment #1 from Marc Glisse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46507
Marc Glisse changed:
What|Removed |Added
Keywords||missed-optimization
CC|
||glisse at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #2 from Marc Glisse ---
Already implemented in 4.8.
*** This bug has been marked as a duplicate of bug 54427 ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54427
Marc Glisse changed:
What|Removed |Added
CC||gabriel at teuton dot org
--- Comment #14 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58431
--- Comment #3 from Marc Glisse ---
-fdisable-tree-phicprop2 lets it pass (the dumps appear identical before and
after this pass, but with verbose dumps we see some memory PHIs disappear)
-fdisable-tree-cddce2 also lets it pass, with larger differ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437
--- Comment #2 from Marc Glisse ---
Ah forget my last message, I understand now you are really interested in how
long it takes to reverse-sort an already sorted vector. Indeed it does take
much longer with 4.6+ than with 4.4.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437
--- Comment #3 from Marc Glisse ---
Less confusing testcase:
#include
#include
using namespace std;
int main()
{
const int num = 1000;
vector v; v.reserve(num);
for(int i=0;i!=num;++i) v.push_back(-i);
sort(v.begin(), v.end());
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437
--- Comment #1 from Marc Glisse ---
I can't reproduce this. I tried compiling with -O3 (with 4.4, 4.7 and 4.8)
after commenting out either of the 2 sort lines, and I see roughly the same
execution times (maybe a few % difference, but nowhere near
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338
--- Comment #3 from Marc Glisse ---
Author: glisse
Date: Tue Sep 17 12:23:54 2013
New Revision: 202650
URL: http://gcc.gnu.org/viewcvs?rev=202650&root=gcc&view=rev
Log:
2013-09-17 Marc Glisse
PR libstdc++/58338
* include/bits/stl_vect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58359
--- Comment #2 from Marc Glisse ---
Another optimization prevented by __builtin_unreachable:
extern void f();
void g(int i){
if(i>0){
f();
__builtin_unreachable();
}
}
misses that f is a tail call and generates at -O3 on x86_64:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58450
--- Comment #1 from Marc Glisse ---
I do see this time difference with 4.7 and 4.8 (didn't try to analyze), but not
with 4.9 which seems fine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338
--- Comment #4 from Marc Glisse ---
Author: glisse
Date: Wed Sep 18 11:21:51 2013
New Revision: 202699
URL: http://gcc.gnu.org/viewcvs?rev=202699&root=gcc&view=rev
Log:
2013-09-18 Marc Glisse
PR libstdc++/58338
* include/bits/list.tcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338
--- Comment #5 from Marc Glisse ---
Author: glisse
Date: Wed Sep 18 18:31:01 2013
New Revision: 202716
URL: http://gcc.gnu.org/viewcvs?rev=202716&root=gcc&view=rev
Log:
2013-09-18 Marc Glisse
PR libstdc++/58338
* include/bits/stl_iter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437
--- Comment #14 from Marc Glisse ---
Hi Chris,
(detail: could you pass -u10, or at least -p, to diff to make the patches
easier to read? It isn't required so you don't have to)
I don't really understand why the pivot is still considered in lower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437
--- Comment #18 from Marc Glisse ---
[Ugh, bugzilla seems half broken at the moment]
> I would suggest my current patch (which is simpler than it looks from the
> diff) for previous versions, then investigate pivot.
Well, you're the one doing a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338
--- Comment #6 from Marc Glisse ---
Author: glisse
Date: Thu Sep 19 11:40:29 2013
New Revision: 202737
URL: http://gcc.gnu.org/viewcvs?rev=202737&root=gcc&view=rev
Log:
2013-09-19 Marc Glisse
PR libstdc++/58338
* include/bits/stl_tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437
--- Comment #25 from Marc Glisse ---
Note that naively doing what I am proposing in comment #14 (it's just an
iter_swap and a +-1) also makes reverse-sorted arrays a bad case, because of
the way we do partitioning, so it isn't an alternative to Ch
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Hello,
in this first function, gcc knows that p is not zero and removes the test (I
have to make sure q doesn't disappear too early, o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58483
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338
--- Comment #7 from Marc Glisse ---
Author: glisse
Date: Fri Sep 20 15:50:09 2013
New Revision: 202781
URL: http://gcc.gnu.org/viewcvs?rev=202781&root=gcc&view=rev
Log:
2013-09-20 Marc Glisse
PR libstdc++/58338
* include/bits/allocato
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58265
--- Comment #5 from Marc Glisse ---
Author: glisse
Date: Fri Sep 20 15:50:09 2013
New Revision: 202781
URL: http://gcc.gnu.org/viewcvs?rev=202781&root=gcc&view=rev
Log:
2013-09-20 Marc Glisse
PR libstdc++/58338
* include/bits/allocato
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56166
--- Comment #10 from Marc Glisse ---
Author: glisse
Date: Fri Sep 20 15:50:09 2013
New Revision: 202781
URL: http://gcc.gnu.org/viewcvs?rev=202781&root=gcc&view=rev
Log:
2013-09-20 Marc Glisse
PR libstdc++/58338
* include/bits/allocat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58487
Marc Glisse changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 from Mar
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
typedef float float4 __attribute__((vector_size(16)));
float4 g(int x)
{
float4 W;
W[0]=W[1]=W[2]=W[3]=x+1;
return W;
}
is vectorized by SLP to:
vect_cst_.4_11 = {x_1(D), x_1(D), x_1(D
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338
--- Comment #8 from Marc Glisse ---
Author: glisse
Date: Tue Sep 24 10:07:32 2013
New Revision: 202861
URL: http://gcc.gnu.org/viewcvs?rev=202861&root=gcc&view=rev
Log:
2013-09-24 Marc Glisse
PR libstdc++/58338
PR libstdc++/56166
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56166
--- Comment #11 from Marc Glisse ---
Author: glisse
Date: Tue Sep 24 10:07:32 2013
New Revision: 202861
URL: http://gcc.gnu.org/viewcvs?rev=202861&root=gcc&view=rev
Log:
2013-09-24 Marc Glisse
PR libstdc++/58338
PR libstdc++/56166
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58265
--- Comment #6 from Marc Glisse ---
Author: glisse
Date: Tue Sep 24 10:07:32 2013
New Revision: 202861
URL: http://gcc.gnu.org/viewcvs?rev=202861&root=gcc&view=rev
Log:
2013-09-24 Marc Glisse
PR libstdc++/58338
PR libstdc++/56166
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30318
--- Comment #8 from glisse at gcc dot gnu.org 2012-05-04 21:45:49 UTC ---
Created attachment 27311
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27311
Wrap plus/minus
This patch handles combinations of range/anti_range for PLUS_EXPR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27139
glisse at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #43
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53244
--- Comment #2 from Marc Glisse 2012-05-05 08:56:27
UTC ---
Hello,
isn't that the same as PR53209 (and at least 2 other duplicates)? Does this
patch fix it for you?
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00280.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30318
Marc Glisse changed:
What|Removed |Added
Attachment #27311|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30318
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30318
--- Comment #12 from Marc Glisse 2012-05-05
13:43:04 UTC ---
Er, sorry, don't know what key I accidentally pressed but it apparently sent
incomplete messages :-(
(In reply to comment #10)
> Now for the testcases... ;)
Yes, that was also my reac
||glisse at gcc dot gnu.org
Known to work||4.4.7
Resolution||FIXED
Known to fail||4.2.4
--- Comment #3 from Marc Glisse 2012-05-05 20:46:39
UTC ---
Closing, fixed since 4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53101
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30318
--- Comment #16 from Marc Glisse 2012-05-07
14:46:03 UTC ---
(In reply to comment #15)
> Looking at your second patch it looks entirely reasonable, though not
> globbing MULT_EXPR together with PLUS/MINUS might be better for readability
I wonder
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53294
Bug #: 53294
Summary: Optimize out some exception code
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53293
--- Comment #3 from Marc Glisse 2012-05-09 12:06:37
UTC ---
typedef struct {
unsigned Ebits_to_go ;
int C
} * EncodingEnvironmentPtr ;
arienco_done_encoding ( EncodingEnvironmentPtr eep ) {
if ( ( eep -> Ebits_to_go ) ) {
while ( eep
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277
--- Comment #12 from Marc Glisse 2012-05-09
13:11:01 UTC ---
(In reply to comment #10)
> This is PR51294.
Looks different. Here the compiler complains about casting 0 to size_t.
> And there is PR52617.
That one is not a bug, unless you want to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #2 from Marc Glisse 2012-05-12 19:46:08
UTC ---
There is -pedantic-errors if you want an error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #5 from Marc Glisse 2012-05-12 21:57:05
UTC ---
(In reply to comment #4)
> For other features of C++11 don't need -pedantic-errors to emit an error.
[...]
> It doesn't seem consistent.
> What is the criteria?
Allowing {} is a rather
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53055
--- Comment #4 from Marc Glisse 2012-05-12 23:33:16
UTC ---
Created attachment 27390
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27390
patch 1
ice.cc:2:15: error: pointer to member must be on the right side of '->*'
int i = p ->* p ;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009
--- Comment #7 from Marc Glisse 2012-05-13 08:59:25
UTC ---
(In reply to comment #6)
> (If anyone can point me to a fixinclude that does the same
> kind of one-line change elsewhere, I could work with that...)
That's easy, just take a look at th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51829
--- Comment #6 from Marc Glisse 2012-05-13 09:06:42
UTC ---
With boost 1.49, g++-4.7 compiles the code just fine, while g++-4.6 gives:
u.cc: In function ‘void bug() [with = void]’:
u.cc:14:24: instantiated from here
u.cc:11:3: error: cannot c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
--- Comment #30 from Marc Glisse 2012-05-14
20:19:39 UTC ---
Author: glisse
Date: Mon May 14 20:19:30 2012
New Revision: 187479
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187479
Log:
2012-05-14 Marc Glisse
PR target/52607
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53364
--- Comment #4 from Marc Glisse 2012-05-16 07:11:35
UTC ---
Looking at -fdump-tree-all, 081t.phicprop1 is still the same for -O1 and -O2,
but O82t.dse1 is missing the memory writes for -O2.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53350
--- Comment #10 from Marc Glisse 2012-05-17
06:11:43 UTC ---
(In reply to comment #9)
> The main issue is that it doesn't work in 6.4.1, which is the version provided
> in Ubuntu 11.10, which means that anyone running 11.10 won't be able to
> co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53385
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53385
--- Comment #7 from Marc Glisse 2012-05-17 21:34:23
UTC ---
Created attachment 27429
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27429
patch
I believe you need something like this completely untested patch to avoid
undefined behavior wit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #43
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53545
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53545
Marc Glisse changed:
What|Removed |Added
CC|glisse at gcc dot gnu.org |
--- Comment #2 from Marc Glisse 2012-05
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53545
--- Comment #5 from Marc Glisse 2012-06-04 19:54:05
UTC ---
(In reply to comment #4)
> Could this be a similar problem as observed in bug 53498, comment 1?
Indeed, the testcases look similar and the stack traces are both infinite
recursions that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51938
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51938
--- Comment #5 from Marc Glisse 2012-06-08 13:06:52
UTC ---
The main difficulty is trapping math. It isn't hard to add to
tree-ssa-ifcombine an ifcombine_ifnotandif variant, and we could make it call
maybe_fold_and_comparisons (as ifcombine_ifand
501 - 600 of 2562 matches
Mail list logo
