https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96804
--- Comment #2 from Marc Glisse ---
(In reply to Paweł Bylica from comment #0)
> This is a problem because when both arguments are NaNs, the result may be
> different than the one predicted by IEEE 754.
Could you quote the sentence in IEEE 754
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96528
--- Comment #2 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> I think that eventually vector lowering should lower
>
> _1 = a == 5;
> _2 = b == 7;
> _3 = _1 | _2;
> _4 = _3 ? -1 : 0;
>
> to
>
> _31 = _1 ? -1 : 0;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96565
--- Comment #4 from Marc Glisse ---
(In reply to Richard Biener from comment #3)
> I guess the "usual" way of dealing with this would be to have
> CLOBBERs for all VLAs before the __builtin_stack_restore.
That looks like a good idea.
I didn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96750
--- Comment #2 from Marc Glisse ---
(In reply to Martin Liška from comment #1)
> after:
> 1794240.0
>
> before:
> 1802710.0
That's less than 1% of difference (with "after" better than "before"), not the
10% regression claimed, maybe there is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96753
--- Comment #2 from Marc Glisse ---
Maybe using vrp_evaluate_conditional (or some other similar helper) instead of
manually comparing ranges in simplify_div_or_mod_using_ranges would help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96753
Marc Glisse changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96654
--- Comment #2 from Marc Glisse ---
gcc doesn't seem very fond of using 2 different vector bitsizes at the same
time, so VEC_PACK_FIX_TRUNC_EXPR takes 2 vectors of 2 double and gives one
vector of 4 int. At the RTL level, we have a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96586
--- Comment #1 from Marc Glisse ---
Probably a DUP of several issues about the lack of flow-sensitivity of our
analysis. Int_1_Loc escapes (we don't pay attention that it only escapes late),
so we don't realize that Proc_7 cannot modify it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96513
Marc Glisse changed:
What|Removed |Added
Known to fail||10.1.0, 9.3.0
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96565
--- Comment #2 from Marc Glisse ---
Actually, it isn't so much the alloca call itself, it seems to be
__builtin_stack_save / __builtin_stack_restore that prevent DSE from removing
arr[0] = 0 (without that write, DCE can remove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96565
Marc Glisse changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96564
--- Comment #1 from Marc Glisse ---
I think there are duplicates about the fact that while gcc knows that a and x
cannot alias (if you read *x, write to *a, then read from *x again, gcc reuses
the first value), it does not use that information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96563
Marc Glisse changed:
What|Removed |Added
Last reconfirmed||2020-08-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48037
--- Comment #10 from Marc Glisse ---
We now generate just
sqrtpd %xmm0, %xmm0
for 2 and 4,
sqrtpd (%rdi), %xmm0
for 3, and
movupd (%rdi), %xmm0
sqrtpd %xmm0, %xmm0
for 1 (for alignment reasons I guess, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50829
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
--- Comment #1 from Marc Glisse ---
Does -fno-delete-null-pointer-checks help?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96542
--- Comment #2 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #1)
> In bar, this is optimized, because fold_binary_op_with_conditional_arg
> optimizes
> 255 >> (x ? 1 : 0) into x ? 127 : 255 and when multiplied by two in unsigned
>
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: arm-none-linux-gnueabihf
(see the discussion after
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551468
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96513
--- Comment #1 from Marc Glisse ---
What you could do, even if it is private code, is reduce it
(https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction) until it is very small
and doesn't give away any IP, and then post it. Otherwise, there is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70314
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88670
Bug 88670 depends on bug 70314, which changed state.
Bug 70314 Summary: AVX512 not using kandw to combine comparison results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70314
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95906
--- Comment #3 from Marc Glisse ---
With the patch (which only affects vectors), f becomes (a>b)?a:b. It should be
easy to add the corresponding transform to MAX_EXPR in match.pd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70314
--- Comment #4 from Marc Glisse ---
We now generate for the original testcase
vpcmpd $1, %zmm3, %zmm2, %k1
vpcmpd $1, %zmm1, %zmm0, %k0{%k1}
vpmovm2d%k0, %zmm0
which looks great.
However, using | instead of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96433
Marc Glisse changed:
What|Removed |Added
Component|c |tree-optimization
Last reconfirmed|
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
typedef long long veci __attribute__((vector_size(16)));
typedef double vecf __attribute__((vector_size(16)));
void f(veci v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95433
--- Comment #5 from Marc Glisse ---
Patch posted at
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551154.html for the
original testcase.
Note that solving univariate polynomial equations *in the integers* (the
rationals are not much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96392
Marc Glisse changed:
What|Removed |Added
Last reconfirmed||2020-07-30
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96327
--- Comment #5 from Marc Glisse ---
I don't think bug 3506 has been fixed (its status seems wrong to me). But don't
worry, there are several other duplicates that still have status NEW (bug 50677
for instance).
This is a sensible enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96369
Marc Glisse changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96088
--- Comment #3 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #2)
> Or use unordered_map, equal_to<>> which
> should perform better.
Good idea.
> We haven't implemented http://wg21.link/p0919r3 and http://wg21.link/p1690r1
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96121
--- Comment #5 from Marc Glisse ---
Yes, then we are back to the fact that it works for A=int but not for A a class
containing an int.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96121
--- Comment #3 from Marc Glisse ---
And this translation unit doesn't actually generate any code at all, so the way
the warning is currently implemented has no chance of even looking at it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96121
--- Comment #2 from Marc Glisse ---
gcc warns for this at the level of actual instructions, not user code. Since A
is empty, nothing uninitialized is getting copied.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96108
--- Comment #4 from Marc Glisse ---
During optimization, we often have branches with dead code that would exhibit
UB if it was ever executed. Cleaning up those branches as much as possible
helps reduce code size, show that some variables (in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96065
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51571
Marc Glisse changed:
What|Removed |Added
CC||b7.10110111 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96009
--- Comment #2 from Marc Glisse ---
Note that we don't do the optimization if you replace double with long either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95971
--- Comment #11 from Marc Glisse ---
while(!a.isZero());
that doesn't look like something you would find in real code. Are you waiting
for a different thread to modify a? Then you should use an atomic operation.
Are you waiting for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95923
--- Comment #1 from Marc Glisse ---
(With one variant I ended up with (a|b)&(a==b), which we don't optimize to a)
We don't optimize !(!a && !b) && !(!a && b) && !(a && !b) (we keep several
branches), but we do optimize if I manually replace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95929
--- Comment #1 from Marc Glisse ---
Here gcc does optimize the first f to (a != 0) ^ (b != 0). However, for the
second f, it does indeed generate something that looks like the first f before
optimization... The optimization for the first f is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95924
--- Comment #1 from Marc Glisse ---
* If I replace ~a with !a, we manage to do everything with type bool. With ~a,
we don't, we stick to int.
* We don't handle a?b:false the same as a&
* Even for (a | !b) && (!(!a & b) && a) we don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95926
--- Comment #1 from Marc Glisse ---
It is different to gcc because in the first case, tmp is used twice, while in
the second case, each a is only used once, and gcc only transforms (a)^b to
b&~a if this is the only use of a Yes, this heuristic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #12 from Marc Glisse ---
(In reply to Jeffrey A. Law from comment #10)
> __builtin_trap emits an actual trap into the instruction stream which halts
> the process immediately which is *much* better from a security standpoint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95906
--- Comment #1 from Marc Glisse ---
I'd say generate a (vec_)cond_expr, not directly a max. That is, replace the
comparison with any truth_valued_p (hmm, that function probably stopped working
for vectors when all comparisons were wrapped in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95818
--- Comment #3 from Marc Glisse ---
Richard said "complete", that is the whole .i file, not just one random
function. If we cannot reproduce the issue by copying your code and compiling
it, we can't do anything about your report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95801
--- Comment #1 from Marc Glisse ---
Except when dereferencing a pointer (?), gcc seldom uses an operation to derive
properties on the operands, it mostly derives properties on the result. That's
in large part because the information you are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90436
--- Comment #4 from Marc Glisse ---
(side note not related to the redundant size checking)
It is surprising how, in the code from comment 2, adding v.reserve(1000) does
not help, it even slows the program down slightly here (yes, that's rather
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90436
--- Comment #3 from Marc Glisse ---
// possibly assumes that ptrdiff_t and size_t have the same size
size_type
_M_check_len_one(const char* __str) const
{
ptrdiff_t __n = sizeof(_Tp);
ptrdiff_t __ms =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90436
--- Comment #2 from Marc Glisse ---
(writing down some notes)
Calling
size_type
_M_check_len_one(const char* __s) const
{
if (max_size() - size() < 1)
__throw_length_error(__N(__s));
const size_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95643
--- Comment #1 from Marc Glisse ---
After FRE1 we have
_2 = x_9(D) == 0;
if (_2 != 0)
so we assert things for _2 and not x_9, and we lose the __builtin_unreachable
information in CCP2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95561
--- Comment #1 from Marc Glisse ---
Are you using -std=gnu++17 or -std=c++17 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
--- Comment #43 from Marc Glisse ---
(In reply to Niels Möller from comment #42)
> And what's the easiest way to run the the right compiler process (I guess
> that's cc1) under gdb?
gcc -c t.c -wrapper gdb,--args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95384
--- Comment #2 from Marc Glisse ---
Or with less templates:
struct A {
A() = default;
union S {
constexpr S() noexcept : e() { }
struct {} e;
int i;
} s;
bool b = false;
};
struct B : A {
B() = default;
using A::A;
};
B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95489
--- Comment #2 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> (bit_and (ne (bit_and x_3 y_4) 0) (ne x_3 0))
This could be simplified
> where I'd say we miss
>
> (bit_and (ne @0 integer_zerop) (ne @1 integer_zerop))
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435
Marc Glisse changed:
What|Removed |Added
Target||x86-*-*
--- Comment #3 from Marc Glisse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95433
Marc Glisse changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95423
--- Comment #3 from Marc Glisse ---
We manage it with -fwrapv. This should happen late when we don't care about
overflow anymore, or it needs to introduce casts to an unsigned type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95393
--- Comment #1 from Marc Glisse ---
It does optimize for me with -O2 or -O3. It could optimize earlier though, by
the end of gimple, we are still trying to return max(s,0).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95353
--- Comment #3 from Marc Glisse ---
Do you need fr_literal to have size at least 1 (say, when creating an object on
the stack), or can you use the official flexible array member (drop the 1, just
[] in the declaration)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95351
--- Comment #2 from Marc Glisse ---
It might not be the issue, but merge_truthop_with_opposite_arm has a suspicious
HONOR_NANS (type) where type is bool: the result of the comparison instead of
one of the arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279
--- Comment #12 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #10)
> 1 + (size_t) -1 give 0
It wasn't obvious to me that the operation was supposed to happen in some C/C++
type (they don't say which one) or in a mathematical,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279
--- Comment #8 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #4)
> There is nothing wrong on addition of -1, whether signed or cast to
> size_t/uintptr_t, to a pointer,
Looking at the standard (I am not a pro at that), one could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94141
Marc Glisse changed:
What|Removed |Added
Last reconfirmed||2020-05-21
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95246
--- Comment #1 from Marc Glisse ---
On which version of LLVM did you see that? For me, gcc produces
movzbl %dil, %edi
movsbl %sil, %esi
cmpl%esi, %edi
setg%al
while clang skips the first 2 lines (but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115
--- Comment #4 from Marc Glisse ---
(In reply to Jim Wilson from comment #3)
> The assumption here seems to be that if the user is
> dividing constants, then we don't need to worry about setting exception
> bits. If I write (4.0 / 3.0) for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115
--- Comment #2 from Marc Glisse ---
Or during CCP with the simpler
double f(){
double d=__builtin_inf();
return d/d;
}
and all the -frounding-math -ftrapping-math -fsignaling-nans don't seem to
help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115
--- Comment #1 from Marc Glisse ---
I am seeing the same thing on x86_64, happens during FRE1, so it looks like
tree-optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91383
Marc Glisse changed:
What|Removed |Added
CC||gcc at linkmauve dot fr
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95065
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95044
--- Comment #1 from Marc Glisse ---
I think there is another very similar bug report.
# buf_1 = PHI <_buf(2), buf_15(6)>
[...]
if (_buf != buf_1)
in each branch, we thus know what buf_1 is, so we could replace it with buf_15
in
# _3 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95001
--- Comment #3 from Marc Glisse ---
Simpler example:
[[noreturn]] void theend();
int f(int x){
if(x&7)theend();
return x&3;
}
(or replace "theend()" with "throw 42")
We shouldn't compute x&3, it is always 0 in the branch where it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94914
--- Comment #4 from Marc Glisse ---
I thought we might already simplify (u >> 32) != 0 to u >= cst (other possible
forms are u != (uint64_t)(uint32_t)u, u & cst != 0, etc, I am trying to think
which one looks most canonical).
I expect in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94930
--- Comment #1 from Marc Glisse ---
AFAIK -ftrapv doesn't work very well and is kind of abandoned, in favor of
-fsanitize=signed-integer-overflow (possibly with
-fsanitize-undefined-trap-on-error), which does generate the code you expect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94921
--- Comment #1 from Marc Glisse ---
x + y ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94919
--- Comment #1 from Marc Glisse ---
This seems related to another one you reported, in the category: i&-b == b?i:0
(for b∈{0,1}). The first form has the advantage of no branch, while the second
is less obfuscated and simplifies more naturally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94905
--- Comment #1 from Marc Glisse ---
Several of us asked, and it was rejected. Your next step is to provide a
self-contained testcase (preprocessed sources?). You may also want to check if
it still warns in gcc-10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94911
--- Comment #3 from Marc Glisse ---
Since VLA is an extension for compatibility with C, it is strange that it
behaves differently (does one use the value of n at the time of the typedef and
the other at the time of the declaration?). This bug is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94911
--- Comment #1 from Marc Glisse ---
gcc computes sizeof(a) as 4ul*(size_t)n, and unsigned types don't provide nice
overflow guarantees, so that complicates things.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94908
--- Comment #1 from Marc Glisse ---
Even if we write __builtin_shuffle, the vector lowering pass turns it into the
same code (constructor of BIT_FIELD_REFs), which seems to indicate that the
target does not handle this pattern.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94804
--- Comment #4 from Marc Glisse ---
(In reply to Gabriel Ravier from comment #3)
> Having similar problems with useless movs is from the same non
> well-optimized register allocation on function boundaries ?
I don't know, but possibly not. I'll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94804
Marc Glisse changed:
What|Removed |Added
Keywords||ra
--- Comment #2 from Marc Glisse ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94811
Marc Glisse changed:
What|Removed |Added
Component|c++ |libstdc++
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94801
--- Comment #2 from Marc Glisse ---
if(a==0)__builtin_unreachable();
lets gcc optimize the code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94801
--- Comment #1 from Marc Glisse ---
Gcc considers that clz might return 32 on some platforms, it does not currently
use target-specific information to restrict the range of clz output.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94798
--- Comment #1 from Marc Glisse ---
(In reply to Gabriel Ravier from comment #0)
> Comparison here : https://godbolt.org/z/LZ8dBy
In your future bug reports, could you please copy all relevant information
instead of (or in addition to) linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94566
--- Comment #3 from Marc Glisse ---
I thought we had code to recognize a switch that represents a linear function,
I was hoping that it would kick in with your hoisting patch...
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
g++-10 -std=gu++2a -O3
#include
bool k(int i){
auto c=i<=>0;
return c>0;
}
[local count: 1073741824]:
if (
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
#include
int conv1(std::strong_ordering s){
if(s==std::strong_ordering::less) return -1;
if(s==std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94314
--- Comment #10 from Marc Glisse ---
I am still getting -1 at -O2 for
#include
#include
int count = 0;
__attribute__((malloc,noinline))
void* operator new[](unsigned long sz){++count;return ::operator new(sz);}
void operator delete[](void*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62080
Marc Glisse changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94141
--- Comment #2 from Marc Glisse ---
Ah, maybe the friend function is not quite a template, so the generated swapped
function is not a template either, and thus it has priority over a template if
both are exact matches?
This is going to break a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94141
--- Comment #1 from Marc Glisse ---
It looks like clang-10+ also generates an infinite loop on this code. Does the
standard really give priority to some implicit function over a user-defined one
that is an exact match?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94412
Marc Glisse changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51965
--- Comment #19 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #16)
> (In reply to Marc Glisse from comment #5)
> > (The split into push_heap and __push_heap is just so the first part can be
> > inlined without the second,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63706
Marc Glisse changed:
What|Removed |Added
Last reconfirmed||2020-03-29
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94356
--- Comment #3 from Marc Glisse ---
I tried https://gcc.gnu.org/pipermail/gcc-patches/2017-May/475037.html some
time ago. Having a different type for the multiplication and the offsetting
introduced a lot of NOPs and caused a few regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94356
--- Comment #1 from Marc Glisse ---
That's because internally we use an unsigned type for offsets (including for
the multiplication). There have been tries to change that...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94295
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94314
--- Comment #5 from Marc Glisse ---
I don't think we need heavy machinery linking new and delete (and if we did I'd
be tempted to store it in some global table rather than in the nodes). The most
important case is the global replacable
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
(originally posted at
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-08/msg00276.html , I don't know
if we will do something about
101 - 200 of 2560 matches
Mail list logo
