https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899
--- Comment #16 from Marc Glisse ---
(patch should use 'fn && DECL_CONSTRUCTOR_P (fn)' since fn can be NULL)
As I was half expecting, messing with the types that directly doesn't work. It
means 'this' has type T*restrict, and if I try for instan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899
Marc Glisse changed:
What|Removed |Added
Attachment #44112|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85757
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899
--- Comment #19 from Marc Glisse ---
(In reply to rguent...@suse.de from comment #18)
> I suppose this changes debug information?
Yes. Probably not so bad, but indeed better if we can avoid it.
> I think adjusting the only user in tree-ssa-stru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899
--- Comment #20 from Marc Glisse ---
Created attachment 44122
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44122&action=edit
untested middle-end patch
This works on the testcase, I need to add a comment and run it through the
testsuite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85758
--- Comment #1 from Marc Glisse ---
Direct translation would be (from clang):
andl%ecx, %edx
addl%edx, %edi
xorl%ecx, %edx
addl%edx, %esi
With -mbmi, I get
andn%ecx, %edx, %eax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899
--- Comment #22 from Marc Glisse ---
(In reply to rguent...@suse.de from comment #21)
> Note that in the strict C semantic thing __restrict on
> this isn't valid as the following is valid C++:
>
> Foo() __restrict
> {
> Foo *x = this;
> x->a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85791
--- Comment #4 from Marc Glisse ---
(In reply to Ruslan Nikolaev from comment #0)
> 2. unsigned long long func(unsigned long long a, unsigned long long b)
> {
> __uint128_t c = (__uint128_t) a * b;
> if (c > (unsigned long long) -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85811
--- Comment #1 from Marc Glisse ---
tree_binary_nonnegative_warnv_p for RDIV_EXPR does RECURSE (op0) && RECURSE
(op1), but that doesn't work so well when the denominator can be 0. I guess it
is still ok when finite-math-only (or no-nans and no-si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85811
--- Comment #6 from Marc Glisse ---
What does tree_expr_nonnegative_p call non-negative? A natural definition would
exclude NaN, but for REAL_CST we just return ! REAL_VALUE_NEGATIVE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #7 from Marc Glisse ---
This PR is messy. To sum up, comment #0 was recently fixed, comment #5 is not
(not noticing that the writes in the loop are dead), and comment #6 asks for
increasing the alignment of VLAs the same way we someti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85822
--- Comment #1 from Marc Glisse ---
_2 = x.0_1 & -281474976710656;
if (_2 == -281474976710656)
goto ; [20.24%]
[...]
x.0_11 = ASSERT_EXPR ;
x.0_12 = ASSERT_EXPR ;
x.0_13 = ASSERT_EXPR = -1>;
y_7 = (unsigned intD.9) x.0_13;
Thos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #12 from Marc Glisse ---
(In reply to Richard Biener from comment #11)
> I guess you meant (notice the bogus memset size above):
True. And while it shouldn't make a difference in checking if the stores to c
are dead, it could (but do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85827
--- Comment #2 from Marc Glisse ---
I think that's going to be hard. The same issue always existed with macros. The
whole point of "if constexpr" is not to look at the other branches, as they may
not even compile. Sure, some minimal "safe" attemp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899
--- Comment #24 from Marc Glisse ---
Author: glisse
Date: Fri May 18 22:21:20 2018
New Revision: 260383
URL: https://gcc.gnu.org/viewcvs?rev=260383&root=gcc&view=rev
Log:
Aliasing 'this' in a C++ constructor
2018-05-18 Marc Glisse
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85850
--- Comment #1 from Marc Glisse ---
In libcpp/system.h, is included too late, after messing with macros, it
should move earlier with the other includes. We could probably also avoid
#defining true/false in C++ (just a warning).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85929
--- Comment #1 from Marc Glisse ---
With size_type = unsigned long, the bounds check turns out to be exactly the
same test as the loop exit check, and FRE3 gets rid of it.
With size_type = unsigned int, it is harder. We have roughly
long int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85929
--- Comment #4 from Marc Glisse ---
(In reply to Richard Biener from comment #2)
> So somehow we need to enhance the code in VRP that registers additional
> asserts to also handle symbolic ranges and thus register not only
> i_4 < count_8 but als
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85974
--- Comment #1 from Marc Glisse ---
In match.pd
(simplify
- (pointer_diff (convert?@2 @0) (convert?@3 ADDR_EXPR@1))
+ (pointer_diff (convert?@2 @0) (convert1?@3 ADDR_EXPR@1))
(that is, we can have only one cast, not just 0 or 2)
and similarly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85992
--- Comment #3 from Marc Glisse ---
(In reply to Matt Peddie from comment #2)
> Is there a way to disable this behavior?
-fno-builtin (or a more specific -fno-builtin-atanf) tells gcc to handle atanf
as a regular function call, not as a standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86013
--- Comment #5 from Marc Glisse ---
(In reply to Jan Kratochvil from comment #0)
> Maybe it could even always call realloc() for size reduction of any type of
> objects and just assert the returned pointer did not change.
I can't find anywhere a
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
While we cannot make std::pair or std::tuple trivial for now for ABI reasons,
it should still be safe to use memcpy-type
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
typedef struct A { int a, b; } A;
void*f(A*restrict p){
A*q=__builtin_malloc(1024*sizeof(A));
for(int i=0;i<1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86050
Marc Glisse changed:
What|Removed |Added
Keywords||missed-optimization
Component|mid
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
#include
struct I { double i,s; I(double d):i(d),s(d){} };
typedef std::array P;
typedef std::array AP;
static AP c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86062
--- Comment #4 from Marc Glisse ---
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86024
--- Comment #2 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> Or we may want to un-"SRA" such patterns, generating aggregate copies.
I notice that store-merging does not merge these stores, I didn't check why.
SLP can do it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86092
--- Comment #4 from Marc Glisse ---
(In reply to Srinivas Achary from comment #2)
> Is there any possibility to make this code work,
Remove the 'const', or add 'volatile'.
> without changing the variable attribute.
-O0
> GCC-4 has no issue wi
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
extern char*volatile i;
int f(){return i-i;}
gets simplified in C as 1 load and return 0. In C++ or if i has a non-pointer
type (say int), we do have 2 loads and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86122
--- Comment #5 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #2)
> if we want unsigned_type_for to support complex integer types or not.
I think we do (seems super easy). Testing utype can't hurt indeed.
(In reply to Jakub Jeline
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Default construction of std::optional always starts with a memset of the
whole optional to 0, while it doesn't with clang usin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80335
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86173
--- Comment #1 from Marc Glisse ---
Note that constructing optional from std::nullopt does avoid the memset.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85867
Marc Glisse changed:
What|Removed |Added
CC||zhonghao at pku dot org.cn
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86187
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86173
--- Comment #4 from Marc Glisse ---
Recent related commits: r261758 r261735 (they don't fix the issue).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86270
--- Comment #2 from Marc Glisse ---
:-(
So many transforms seem to have this kind of drawback...
We could always add a pair of single_use checks, but we are going to miss some
optimizations if we do that. Maybe it is slightly relevant that one +1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86284
--- Comment #1 from Marc Glisse ---
-fsanitize=return ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #15 from Marc Glisse ---
(In reply to Martin Sebor from comment #14)
> > You say that
> >
> > struct { int a; int b; } s, s2;
> > memcpy (&s2.a, &s.a, sizeof (s));
> >
> > is invalid, aka not copying the whole structure since you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86347
Marc Glisse changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201
--- Comment #1 from Marc Glisse ---
We unroll the loop (-fdisable-tree-cunrolli) and SLP does not handle
reductions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91217
Marc Glisse changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #2 from Ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #1 from Marc Glisse ---
> if (p >= a || p <= a + 3)
I think you mean &&.
I believe we could fold it to true or false as we wish: false because the
preexisting pointer cannot point to a local object, true because you are only
allowe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #6 from Marc Glisse ---
When we compare p>=a where a is an array (char a[3];), we can assume that p
points somewhere into the array and fold it to true (unless we decide that it
is too risky, and that for instance since we allow point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #9 from Marc Glisse ---
(In reply to Martin Sebor from comment #8)
> I also agree that diagnosing all these unspecified (or undefined in C) cases
> would be helpful as they (at least in the straightforward instances) are
> most likely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #12 from Marc Glisse ---
(In reply to Florian Weimer from comment #11)
> GCC on ELF provides defined address ordering for separate objects via linker
> ordering and section attributes. I think part of these extensions is that
> it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91270
Marc Glisse changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #1 from Marc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91271
--- Comment #1 from Marc Glisse ---
std::array uses size_t, not int, as second parameter. I didn't check what the
standard says about this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78713
Marc Glisse changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
std::optional::operator* has a precondition _M_engaged, but it is not checked,
even in debug mode. It seems like a cheap and easy test to add.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #14 from Marc Glisse ---
(In reply to Florian Weimer from comment #13)
> I don't see why I cast should magically fix this issue,
In libstdc++, std::less does such a cast, there were discussions about it
at that time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201
--- Comment #5 from Marc Glisse ---
It looks like a convoluted way to write:
unsigned char sum()
{
unsigned char res=0;
unsigned char*p=(unsigned char*)bytes;
for(int n=0;n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201
--- Comment #9 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #7)
> Untested patch to add the reduc_plus_scal_v{16,32,64}qi expanders.
> Wonder if we don't need also reduc_plus_scal_v8qi expander for
> TARGET_MMX_WITH_SSE.
I was ev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201
--- Comment #10 from Marc Glisse ---
For AVX512, I wonder if we could use vpsadbw to compute the sums for each
64-bit part, then vcompressb to collect them in the lower 64 bits, then vpsadbw
to conclude. Or whatever other faster variant (is Peter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201
--- Comment #12 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #11)
> I'm not aware of vcompressb insn, only vcompressps and vcompresspd.
Intel lists it under VBMI2, so icelake+.
> Sure,
> one could just emit whatever we emit for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91317
--- Comment #1 from Marc Glisse ---
Did you consider exceptions? a() could throw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91326
--- Comment #1 from Marc Glisse ---
For bar, we don't take advantage of the uninitialized variable enough, we still
have "a_3(D) == 0" at expansion time (RTL gets rid of it, but too
conservatively).
For foo, indeed computing the min and max valu
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
static double g(double x){
asm volatile("":"+x&q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91348
--- Comment #1 from Marc Glisse ---
NRVO happens in the C++ front-end, but not the C one, and the general
tree-nrv.c is rather limited.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91351
Marc Glisse changed:
What|Removed |Added
CC|glisse at gcc dot gnu.org |
--- Comment #3 from Marc Glisse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91312
--- Comment #8 from Marc Glisse ---
We know that the warning is not so useful as is, that's why it isn't part of
Wall or Wextra, see the other bugs on the topic. It needs people with time and
motivation to work on it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91373
--- Comment #5 from Marc Glisse ---
Note that gcc (like clang) provides a tool to help you detect this kind of
issue. If you compile with -fsanitize=undefined, then at runtime you will see:
main.c:7:20: runtime error: signed integer overflow: 631
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356
--- Comment #3 from Marc Glisse ---
(In reply to Niels Möller from comment #2)
> (In reply to Jonathan Wakely from comment #1)
> > The ABI dictates the calling conventions and there's certainly nothing that
> > libstdc++ can do about it.
>
> My
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91351
--- Comment #8 from Marc Glisse ---
(In reply to Martin Liška from comment #7)
> --- a/gcc/tree.c
> +++ b/gcc/tree.c
> @@ -11926,7 +11926,7 @@ int_cst_value (const_tree x)
> tree
> signed_or_unsigned_type_for (int unsignedp, tree type)
> {
> -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91281
Marc Glisse changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #2 from Marc Glisse -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91281
Marc Glisse changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356
--- Comment #7 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #6)
> libstdc++ would not take
> advantage of it because it would break the library's stable ABI.
There is always this mode (is it _GLIBCXX_INLINE_VERSION? I thought I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91351
--- Comment #10 from Marc Glisse ---
(In reply to Martin Liška from comment #9)
> So the integer_type of the enumeral_type hash precision:5 and:
> min
>
> and
>
> max
>
> which is what one would expect from -fstrict-enums.
But the enum type
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 nee
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 dep
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 n
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=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 argu
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 #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 canno
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, dep
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 flags
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=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?
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91623
Marc Glisse changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCON
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 (TRE
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 fro
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 befor
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 trivial
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
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=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.
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 #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 _M_in
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=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=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); }
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=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=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=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 somewher
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 c
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 functions,
901 - 1000 of 2561 matches
Mail list logo
