https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94295
--- Comment #5 from Marc Glisse ---
(In reply to Richard Smith from comment #2)
> (In reply to Marc Glisse from comment #1)
> > (In reply to Richard Smith from comment #0)
> > > The C++ language rules do not permit optimization (eg, deletion) of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94294
--- Comment #4 from Marc Glisse ---
I don't believe there is a "new/delete" issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94295
--- Comment #1 from Marc Glisse ---
(In reply to Richard Smith from comment #0)
> The C++ language rules do not permit optimization (eg, deletion) of direct
> calls to 'operator new' and 'operator delete'.
I thought that was considered a bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94293
--- Comment #4 from Marc Glisse ---
Or just
void f(){
int*p=new int[1];
*p=42;
delete[] p;
}
while it does optimize for
void f(){
int*p=new int;
*p=42;
delete p;
}
because the front-end gives us a clobber before operator delete.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94294
--- Comment #2 from Marc Glisse ---
(In reply to Eyal Rozenberg from comment #0)
> Note: I suppose it's theoretically possible that this bug only manifests
> because bug 94293 prevents the allocated space from being recognized as
> unused; but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94293
--- Comment #1 from Marc Glisse ---
Adding
inline void* operator new(std::size_t n){return __builtin_malloc(n);}
inline void operator delete(void*p)noexcept{__builtin_free(p);}
inline void operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94274
--- Comment #1 from Marc Glisse ---
Detecting common beginnings / endings in branches is something gcc does very
seldom. Even at -Os, for if(cond)f(b);else f(c); we need to wait until
rtl-optimizations to get a single call to f. (of course the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94234
--- Comment #2 from Marc Glisse ---
The closest we have is
/* (A * C) +- (B * C) -> (A+-B) * C and (A * C) +- A -> A * (C+-1).
which does not handle conversions, although it should be possible to add them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94194
--- Comment #1 from Marc Glisse ---
Is there a convenient way for gcc to know the value of FE_DIVBYZERO, etc on the
target? Do we need to hardcode it? Can we rely on different libc on the same
processor to use the same value?
What happens if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61338
--- Comment #3 from Marc Glisse ---
Possibly easier is the case of a reduction, where permutations are clearly
irrelevant.
int f(int*arr,int size){
int sum=0;
for(int i = 0; i < size; i++){
sum += arr[size-1-i];
}
return sum;
}
We
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
(reduced from a user of boost/operators.hpp)
template class A;
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092
--- Comment #3 from Marc Glisse ---
Does profile feedback (so we have an idea on the loop count) make any
difference? It seems clear that for a loop that in practice just copies one
long, having to arrange the arguments, make a function call,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93971
--- Comment #7 from Marc Glisse ---
(In reply to Martin Sebor from comment #6)
> (1) one that would make "std::string::ptr" on par with
> that of any other pointer other than char (i.e., a char that's not allowed
> to be used to access anything
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93971
--- Comment #5 from Marc Glisse ---
It has never been very clear to me what restrict means on a struct member, but
I believe adding it to the pointer in vector means that in a function:
void f(vector*a, vector*b)
the compiler could assume that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93971
--- Comment #1 from Marc Glisse ---
If x is NaN, you cannot simplify x!=x to false.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93939
--- Comment #1 from Marc Glisse ---
typedef long T;
also generates a comparison with 24.
The main issue is that b is used outside of the branch controlled by if(b==8),
so a naive substitution misses it. Repeating 3*b in the branch is useless,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
--- Comment #23 from Marc Glisse ---
(In reply to Richard B. Kreckel from comment #22)
> I can't reproduce this bug any more,
I think you are just lucky, I am sure it hasn't been fixed and gcc will still
happily swap FP operations with function
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
First a case that works:
void f(int n){
if(n<0)__builtin_unreachable();
}
EVRP assigns a range to n, and VRP1 fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93902
--- Comment #1 from Marc Glisse ---
The current optimization in match.pd is an equivalence, it replaces
(double)i==(double)j with i==j when the conversion is always exact. Here, what
we would want is that inside the a==b branch, the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93896
--- Comment #1 from Marc Glisse ---
Without the constructor, we get plain
*this_2(D).a = {};
which is expanded as an __int128 store. With the constructor, we get
MEM[(struct M *)this_2(D)].p = 0B;
MEM[(struct M *)this_2(D)].sz = 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93891
--- Comment #1 from Marc Glisse ---
On the original code (I can attach it if needed, but it is large, it is
resizing a std::vector with reference-counted elements) FRE3 fails to simplify
MEM[(struct Handle_for *)__cur_16] ={v} {CLOBBER};
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
void f(int**p,int**q){
++**p;
*q=*p;
--**p;
}
produces
_1 = *p_8(D);
_2 = *_1;
_3 = _2 + 1;
*_1 = _3;
*q_10(D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93745
--- Comment #8 from Marc Glisse ---
(In reply to Martin Sebor from comment #7)
> But regardless of what language might have even looser rules than C/C++ in
> this area, it would seem like a rather unfortunate design limitation for GCC
> not to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93745
--- Comment #2 from Marc Glisse ---
Ah, right :-(
I thought the example rang a bell, but before your explanation I couldn't
connect it, thanks.
-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
double d;
void f(long*p){
long i=*p;
d=3.;
*p=i;
}
I would like *p=i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60181
--- Comment #10 from Marc Glisse ---
Flags like -ftrapping-math can prevent gcc from folding at compile-time when
the result is infinite (or maybe it always refuses to fold in that case). In
your example, gcc generates a runtime call to __muldc3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644
--- Comment #2 from Marc Glisse ---
# buffer_2 = PHI <_bufD.1939(3), buffer_7(D)(9)>
buffer_18 = ASSERT_EXPR ;
Can't we deduce from this
buffer_18 = buffer_7(D)
? Of course that's not a general solution, but it looks like a sensible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93594
--- Comment #9 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #6)
> if we change the cast patterns so that they are a
> vec_concat of the operand and UNSPEC_CAST that then represents just the
> uninitialized higher part,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93594
--- Comment #4 from Marc Glisse ---
The versions involving _mm256_cast* may be related to PR50829 and others
(UNSPEC hiding the semantics of the operation).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90977
--- Comment #3 from Marc Glisse ---
(In reply to Segher Boessenkool from comment #2)
> Please open a separate bug for the powerpc ICE?
I just tried and couldn't reproduce the ICE with the gcc-9 ppc64el
cross-compiler I have now. Maybe that ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93535
--- Comment #1 from Marc Glisse ---
(testing clang++ -O2 -ffast-math is useful as well)
It would be more helpful if you could isolate some specific transformations
that gcc is missing, instead of one big benchmark.
For instance:
double f(int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93504
--- Comment #4 from Marc Glisse ---
/* (x & ~m) | (y & m) -> ((x ^ y) & m) ^ x */
I guess several transformations like this one which match (unary m) could do
with a second version for the case where m is constant (and thus (unary m) is
already
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93459
--- Comment #2 from Marc Glisse ---
For __builtin_ia32_vec_ext_v4si, shouldn't we lower it to an array access in
gimple, when the second argument is constant? I assume we don't want to do it
directly in smmintrin.h for diagnostic purposes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26724
--- Comment #4 from Marc Glisse ---
(In reply to pskocik from comment #3)
> I don't know if this is related,
It isn't, please file a separate bug report. memcmp is optimized to an integer
comparison in strlen, much later than the lowering of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91333
--- Comment #5 from Marc Glisse ---
With trunk (master?), compiling with -O3, h gives
movapd %xmm1, %xmm3
addsd %xmm3, %xmm1
movapd %xmm0, %xmm2
addsd %xmm2, %xmm0
addsd %xmm1, %xmm0
which looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #29 from Marc Glisse ---
Note that __is_bitwise_relocatable is specialized to true for deque, so we are
not super consistent here ;-)
The original patch used is_trivially_move_constructible, IIRC I changed it to
is_trivial so the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #24 from Marc Glisse ---
Something like that, yes. Essentially, I used trivial because I was convinced
it was safe in that case, not because it looked like the perfect condition. If
someone can convincingly argue for a weaker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93151
--- Comment #2 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #1)
> I don't know what the advantage of testing for them at configure time is.
Strange systems that define them as enum values and not macros?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93147
--- Comment #3 from Marc Glisse ---
(In reply to Alexander Kondratskiy from comment #0)
> My suspicion is that tuple indirectly inherits the types `A` and `B`, and
> even though it may be private inheritance, the compiler still finds both
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #17 from Marc Glisse ---
(In reply to fdlbxtqi from comment #15)
> What I am worried about is that whether revamping these functions would be a
> new wave of ABI breaking.
I don't foresee any ABI issue here. Do make sure your code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #13 from Marc Glisse ---
(In reply to fdlbxtqi from comment #11)
> TBH. I would rather see the library does the optimization instead of the
> compiler. I do not trust the compiler can always optimize this stuff.
If we have both,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93063
--- Comment #1 from Marc Glisse ---
Created attachment 47549
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47549=edit
Untested patch
Not ready, at the very least it misses a comment and a test, but it shows where
the test needs relaxing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #8 from Marc Glisse ---
(In reply to fdlbxtqi from comment #6)
> void copy_char_vector_with_iter(std::vector::iterator
> out,std::vector const& bits)
> {
> std::copy_n(bits.begin(),bits.size(),out);
> }
>
>
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
This comes from PR 93059.
void f(signed short*__restrict p,unsigned short*__restrict q,int n){
for(int i=0;i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #7 from Marc Glisse ---
(In reply to fdlbxtqi from comment #6)
> > > clearly incorrect
> >
> > Please distinguish between what is wrong (generated code crashes, or returns
> > 3 instead of 2), and what is suboptimal.
>
> Suppose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #5 from Marc Glisse ---
We could indeed relax a bit the "same type" condition. We could also make sure
that __restrict appears somewhere in the call chain when using copy or
uninitialized_*, which lets the compiler merge the 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93044
--- Comment #2 from Marc Glisse ---
In match.pd
&& ((inter_unsignedp && inter_prec > inside_prec)
== (final_unsignedp && final_prec > inter_prec))
looks suspicious.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93039
Marc Glisse changed:
What|Removed |Added
Target||x86_64-*-*
--- Comment #1 from Marc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93005
Marc Glisse changed:
What|Removed |Added
Target||arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92826
--- Comment #2 from Marc Glisse ---
I thought the name "pedantic" made it clear that it is going to warn about
things that are just fine, and you shouldn't use it...
You can disable the warning by inserting __extension__ in your code. It might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65656
--- Comment #11 from Marc Glisse ---
Comment #6 looks like it was probably fixed with bug 85746.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #20 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #19)
> Created attachment 47398 [details]
> gcc10-pr92712.patch
>
> Full untested patch.
The patch looks very good to me :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #16 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #15)
> I guess we could handle those cases by using something like
> check_for_binary_op_overflow, except that for the case where A might be -1
> and plusminus equal to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
--- Comment #11 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #10)
> The bug in this example is that the push_back call needs to make a copy and
> the type is not copyable. It's not a bug that the copy constructor is
> implictly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
--- Comment #9 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #7)
> I disagree. The static assert contains all you need to know, expert or not.
> The benefit of seeing all the gory details is to figure out why something
> didn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #11 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #10)
> I know, it will be a small complication, sure, but it can be handled.
Ah, I think I understand now. But still
x=-1
a=INT_MAX
a*x+x gives INT_MIN without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #8 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #6)
> The suggestion I'll try to work on is to check if C isn't a plus/minus expr
> with constant second operand that doesn't go in the other direction and thus
> where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #7 from Marc Glisse ---
The first question could be why SCCP produces
(const int) ((unsigned int) t_2(D) + 4294967295) * v_3(D) + v_3(D)
and not directly t*v. Several loop passes do have this tendency to split out
the last (or first)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #5 from Marc Glisse ---
a*x+x -> (a+1)*x is unsafe (a=INT_MAX, x=0), but there are cases where we could
prove that it is safe, in particular when a is actually b-1 (more generally for
a*x+b*x when we can prove (with VRP?) that a+b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92716
--- Comment #4 from Marc Glisse ---
Yes, the pass that recognizes bswap (unsurprisingly called bswap) happens much
later than inlining in the pipeline. This kind of thing is unavoidable since
cycling through optimization passes is considered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92592
--- Comment #3 from Marc Glisse ---
IFN_SUB_OVERFLOW recognition?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91333
--- Comment #3 from Marc Glisse ---
gcc version 9.2.1 20191109 (Debian 9.2.1-19)
(current debian testing/unstable)
gives me the 3 movapd, whether I use -O1, -O2 or -O3, and -Os gives 2 movapd. I
didn't try with a vanilla gcc, not sure which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71761
--- Comment #5 from Marc Glisse ---
The case "struct token { int i; };" was fixed in gcc-7.
>= f (); [return slot optimization] [tail call]
That's all you should see at this point, it is later that it gives up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92233
--- Comment #1 from Marc Glisse ---
(llvm doesn't do it either)
Would some kind of threading be the most natural way to handle this? If the
compiler duplicates the code as
if (a==0) return a*b;
else if (b==0) return a*b;
then it becomes easy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92194
--- Comment #2 from Marc Glisse ---
With -Wsystem-headers you also get the warning in C++17 (and it is actually a
bit more informative, at least it says where it is used).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85746
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85746
--- Comment #9 from Marc Glisse ---
Author: glisse
Date: Tue Oct 22 14:42:38 2019
New Revision: 277292
URL: https://gcc.gnu.org/viewcvs?rev=277292=gcc=rev
Log:
PR c++/85746: Don't fold __builtin_constant_p prematurely
2019-10-22 Marc Glisse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92077
--- Comment #2 from Marc Glisse ---
It is quite natural for the compiler to inline functions that are only called
once (it won't take more space) (although the compiler doesn't actually know
that the function isn't also called in another TU)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91428
--- Comment #5 from Marc Glisse ---
Would it make sense to add a fixit hint that removes "constexpr"? I think that
might make the warning a bit clearer for some users.
On the other hand, if is_constant_evaluated gets removed by P1938, there is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91796
--- Comment #7 from Marc Glisse ---
(In reply to Maxim Egorushkin from comment #3)
> It seems to me that register allocation has been a weak spot in gcc for
> years.
Most such testcases show issues with arguments/return in very small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91965
--- Comment #2 from Marc Glisse ---
(In reply to Alexander Monakov from comment #0)
> Do we want to handle this early on via match.pd? Perhaps also applies to
> simplifying (a +- C) << N.
What exact transformation do you want? Canonicalize the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91940
--- Comment #7 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #1)
> The loop with the rotate is vectorized, while the one with __builtin_bswap16
> is not.
It is a bit surprising that we do not canonicalize one to the other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91958
--- Comment #1 from Marc Glisse ---
PR 83534 ? (it could also be related to bug 67772, but it is a bit further)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86173
--- Comment #5 from Marc Glisse ---
A similar example was reported on https://stackoverflow.com/q/57964217/1918193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91889
--- Comment #8 from Marc Glisse ---
int i;
void f(int* const&) { }
void f(const int* const &) { }
void g(int* p) { f(p); }
void h() { f(); }
I find it painful that g is ambiguous, and confusing that h remains ok. It
needs confirmation that CWG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91878
--- Comment #3 from Marc Glisse ---
-D_GLIBCXX_DEBUG is the current way to add many checks to libstdc++, and it
detects this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91866
--- Comment #1 from Marc Glisse ---
See https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00821.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91788
--- Comment #3 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #2)
> I think we can do that more generically. Does this look right?
lgtm
> (The downside would be that many more functions might need to be
> friends to access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91789
--- Comment #2 from Marc Glisse ---
We do manage if you swap the order of the first 2 comparisons, because this way
we don't need to remember symbolic ranges: a<0 yields a range [0,inf] for a,
b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91788
--- Comment #1 from Marc Glisse ---
Internally, it may also be possible to avoid calling index() so often and work
with the raw _M_index more often.
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
(this is a detail, it probably has a negligible impact)
constexpr size_t index() const noexcept
{ return size_t(typename _Base::__index_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78113
--- Comment #6 from Marc Glisse ---
(looking at the first testcase)
There are 2 things. One is the implementation strategy in libstdc++ vs boost vs
others (I don't know what is best, it probably depends on the application). The
other one is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90387
--- Comment #8 from Marc Glisse ---
(In reply to Bernd Buschinski from comment #6)
> From the comments I assumed that the fix is kind of trivial
There is a simple change that gives the behavior you want on one example, but
it is far from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91725
--- Comment #2 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #1)
> gcc10-pr91725.patch
An alternative (I don't claim it is better) would be to make get_nonzero_bits
conservatively return -1 on unknown input, like the comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91645
--- Comment #3 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> for y >= 0.0 the result is unspecified?
NaN >= 0.0 is false, but even if it was unspecified, the implication would
still be true.
(In reply to Nikita Lisitsa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91623
--- Comment #6 from Marc Glisse ---
For the missed constant folding, it seems that we end up in fold_vec_perm, with
type a vector of "long long", while arg0 and arg1 are vectors of "long", and we
give up because of the early check "TREE_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91623
Marc Glisse changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91435
--- Comment #1 from Marc Glisse ---
(In reply to Marc Glisse from comment #0)
> If we are only ever going to use x+2, why not use that instead, initialize
> with {2,3,4,...}, and skip the +2 at every iteration?
Or since we have another variable
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
(from https://stackoverflow.com/q/57465290/1918193)
long RegularTest(int n) {
long sum = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
--- Comment #1 from Marc Glisse ---
The warning basically says "you may have forgotten 'break;'". If it falls
through to break anyway, what difference does it make if I add a redundant
break?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
--- Comment #7 from Marc Glisse ---
(In reply to Segher Boessenkool from comment #6)
> Maybe we should make "is this an ordered comparison" separate from the
> actual comparison code.
I was considering having a single .IFN_FENV_CMP (a, b, opts)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
--- Comment #2 from Marc Glisse ---
I think part of the problem with the current or_comparison optimization is that
it relies on invert_tree_comparison in many cases, and that doesn't really work
for floating point (and we handle the unsafe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397
--- Comment #7 from Marc Glisse ---
(In reply to Steinar H. Gunderson from comment #6)
> So basically GCC is worried that I might be calling allocate() with -1
> bytes, and gives a warning?
Yes, although it might not always give the warning,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397
--- Comment #5 from Marc Glisse ---
mem_strdupl calls allocate(len+1). If len+1 is 0, you proceed to write to
s[len] i.e. 0[-1]. I think gcc would be happier if you handled this special
case explicitly (you could error, trap, just assume it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397
--- Comment #4 from Marc Glisse ---
I guess it happens in some dead path that gcc doesn't know is dead. At some
point, you look at last_slash-path+1. Here there is a branch on whether this
number is 0, and if it is 0, nonsense happens (writing 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397
--- Comment #2 from Marc Glisse ---
if (g == 0) return (char *)malloc(0);
for (;;)
;
so the only way this can return is if g is 0. This means that in j, k is -1,
and you are calling memcpy with a huge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91382
--- Comment #2 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #1)
> Aren't unknown attributes supposed to be ignored?
Bug 86368 is related to that point.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91358
--- Comment #5 from Marc Glisse ---
(In reply to Richard Biener from comment #4)
> I guess valgrind could be improved to check
> only at uses of the uninit value?
It is used. In the easy case it would be used in "undef & 0", so the result
does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91383
--- Comment #1 from Marc Glisse ---
> "may fail to compile"
we don't have to remove them, keeping them is actually on purpose so it is
easier for users to have access to new features without breaking the old ones.
What we could do is use the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356
--- Comment #9 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #8)
> you'd still need a change to the Itanium ABI.
Or an attribute like [[clang::trivial_abi]], or the one that p1029 is trying to
standardize. But since we would
201 - 300 of 2560 matches
Mail list logo
