https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90628
--- Comment #4 from Marc Glisse ---
I wonder if in C it should be controlled by -Wdiscarded-qualifiers. I am happy
with the unconditional error, just asking.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90638
--- Comment #5 from Marc Glisse ---
Igor, there are free websites that let you check it for yourself very easily,
for instance https://wandbox.org/ , you can test many versions of the compiler
online there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90648
--- Comment #3 from Marc Glisse ---
Is there a way we could check the arguments early in a single place, and if
they don't match, create a regular function call instead of a bogus call to a
builtin? This is so we don't have to check the arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90648
--- Comment #6 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #5)
> So perhaps the way forward is just do a better job on the C FE side too, if
> the user provided decl is too different, make sure not to overwrite the old
> anticipa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79716
--- Comment #3 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> Confirmed. The issue is that DSE does not track variable-size stores like
> this
> and thus stmt_kills_ref_p (temp, ref) returns false for memcpy and the ref
> fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90774
--- Comment #4 from Marc Glisse ---
(In reply to Shawn Landden from comment #3)
> -fwrapv is completely legal even if it is not passed, and generally I think
> this optimization (if applicable) would outweigh some UB optimizations.
There was thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62055
--- Comment #2 from Marc Glisse ---
Created attachment 46464
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46464&action=edit
for vectors
A naive try to handle it for vectors (because it seems a bit easier), copying
the existing pattern fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62041
Marc Glisse changed:
What|Removed |Added
Component|rtl-optimization|tree-optimization
--- Comment #5 from Marc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
Marc Glisse changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
--- Comment #2 from Marc Glisse ---
-fdisable-tree-unrolljam helps, which may (or may not) point at a potential
culprit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62055
--- Comment #4 from Marc Glisse ---
(In reply to Uroš Bizjak from comment #3)
> The patch is OK, but please let me cleanup this (and scalar) part a bit
> first.
Of course, thanks. And you are more than welcome to take over if you feel like
it ;-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90810
Marc Glisse changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90810
--- Comment #2 from Marc Glisse ---
Hmm, s/num4/denom4/
(void) (*res = (__v4sf) num4 / { 0.0, 0.0, 0.0, 0.0 })
not sure why denom4 gets replaced but not num4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90737
--- Comment #5 from Marc Glisse ---
I don't understand very well why the cast to an integer before returning is
relevant. What if I return the pointer, and convert it to an integer afterwards
in the caller? Or what if there is no cast, but I test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90830
--- Comment #2 from Marc Glisse ---
ICE is short for "internal compiler error", it means that the compiler crashes.
Please don't use that expression for anything else, in particular not for the
compiler reporting an error in your code (whether it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62041
--- Comment #6 from Marc Glisse ---
Author: glisse
Date: Tue Jun 11 12:48:26 2019
New Revision: 272151
URL: https://gcc.gnu.org/viewcvs?rev=272151&root=gcc&view=rev
Log:
fold_real_zero_addition_p for vectors
2019-06-11 Marc Glisse
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62041
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
--- Comment #2 from Marc Glisse ---
(In reply to Marc Glisse from comment #1)
> I am surprised the C++ FE doesn't do copy elision in either case.
Er, actually, that's obviously because it is a case where the ABI says we
return in registers...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90888
--- Comment #2 from Marc Glisse ---
Dup of PR 80738 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
--- Comment #17 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #12)
> What about -Wxor-used-as-pow ?
-Wxor-power (or -Wpower-xor)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90905
--- Comment #3 from Marc Glisse ---
> compiling both functions in the samne translatin unit suppresses the warning
> for f0.
It is quite common for extra code to change inlining decisions. You still get
the warning at -O3.
> const char *p = "d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70841
--- Comment #5 from Marc Glisse ---
(In reply to Christophe Lyon from comment #4)
> Can this be achieved in match.pd?
A simple case like x*y/x could be done in match.pd (assuming we want to
simplify it to just y under some conditions). To handle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80738
--- Comment #4 from Marc Glisse ---
(In reply to Richard Biener from comment #3)
> Btw, what's a C++ testcase for this?
#include
#include
typedef std::vector V;
V f(V&v){
V r;
r=std::move(v);
return r;
}
Compiled with -O2, the optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90905
--- Comment #5 from Marc Glisse ---
struct A { char*p; char c[13]; };
void f(A&a,bool b){
a.p=b?a.c:(char*)__builtin_malloc(13);
__builtin_memcpy(a.p, "hello world!", 12);
a.p[12]=0;
}
gives
if (b_4(D) != 0)
goto ; [67.00%]
else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90905
--- Comment #7 from Marc Glisse ---
(In reply to Martin Sebor from comment #6)
> With str being a local (non-reference) variable this should be diagnosed
> because of the str.D.28972._M_local_buf(12):
>
> # _47 = PHI <_59(9), &str.D.28972._M_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #42 from Marc Glisse ---
Created attachment 46502
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46502&action=edit
other hack
Another approach.
* lowering in an optimization pass is idiotic, it only works at -O2+, but it
shows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90967
--- Comment #1 from Marc Glisse ---
Try -std=c++2a? The difference is whether the string functions are extern
templates (usual) or not (experimental support for future standards). I would
consider it a DUP of all the PRs that show the bad effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90967
--- Comment #2 from Marc Glisse ---
Even with -std=c++2a to disable extern templates, we only optimize at -Os, both
-O2 and -O3 fail to simplify (bad inlining decisions?).
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
#ifdef M
# define C "m"
#else
# define C "g"
#endif
typedef long double T;
T f(T t){
#ifdef TWO
asm volatile("":"=" C(t):"0&qu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58483
--- Comment #11 from Marc Glisse ---
(In reply to Richard Biener from comment #10)
> Wit GCC 9 and trunk we are left with
>
>[local count: 118111600]:
> MEM[(int *)&D.30957] = 85899345930;
> D.30957[2] = 30;
> _33 = operator new (12);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034
--- Comment #4 from Marc Glisse ---
Does it make a difference if you replace gmp 6.1.2 with a recent snapshot from
https://gmplib.org/download/snapshot/ ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034
--- Comment #15 from Marc Glisse ---
https://gmplib.org/manual/Build-Options.html#index-Generic-C documents
--disable-assembly as the official way to disable asm. But I am surprised that
even with the snapshot you had asm. Looking at the current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91088
--- Comment #1 from Marc Glisse ---
I am surprised we don't have a match.pd transformation for v * 2 < 6 with
undefined overflow. But that's only a side remark, not important for your
report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85746
--- Comment #4 from Marc Glisse ---
Created attachment 46566
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46566&action=edit
untested patch to fold _bcp only when necessary
++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
constexpr double d = 1. / 3.;
currently fails to compile with -frounding-math. This behavior makes sense: we
do not know in what direction to round. However, -frounding-math is about the
dynamic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85746
--- Comment #5 from Marc Glisse ---
The patch breaks 3 tests on a bootstrapped compiler:
c-c++-common/Warray-bounds-2.c
c-c++-common/ubsan/ptr-overflow-sanitization-1.c
gcc.dg/Warray-bounds-30.c
The last one in particular shows that the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85746
--- Comment #6 from Marc Glisse ---
The problematic file seems to be tree-dfa.o, and the only difference I see in
the .original dump is the use of __builtin_constant_p in wi::lshift (3
occurrences because of templates)
- if (precision <
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85746
Marc Glisse changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91158
--- Comment #1 from Marc Glisse ---
Do you know std::is_constant_evaluated (C++20)?
> Although a regular 'if' does what I want, I don't get the assurance that 'if
> contexpr' provides about no branching at runtime. Instead, I need to rely on
> t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91158
--- Comment #6 from Marc Glisse ---
A related common misconception is trying to write
if constexpr (std::is_constant_evaluated())
except that this one is always true instead of always false.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86420
--- Comment #1 from Marc Glisse ---
(In reply to nsz from comment #0)
> gcc has no flag to say 'floating-point exceptions matter' (like
> -frounding-math for non-default rounding mode)
There is -ftrapping-math (on by default), although its exact
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86477
--- Comment #2 from Marc Glisse ---
We don't have attribute ext_vector_type (we have vector_size). Gcc warns about
it.
We don't allow constructing a vector from a scalar (broadcasting).
What Andrew says.
If I fix everything, binding a reference w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471
--- Comment #4 from Marc Glisse ---
There have been questions before about enabling (parts of) ldist at -O2.
(In reply to Matt Bentley from comment #3)
> I thought I should note that there is also a missing optimization
> opportunity in the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471
--- Comment #9 from Marc Glisse ---
(In reply to Andrew Pinski from comment #7)
> This is incorrect for floating point types
Because of negative 0 I assume.
> And it introduces an extra check at runtime if value is not known to compile
> time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86557
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86573
--- Comment #1 from Marc Glisse ---
Try renaming 'main' to any other name and gcc does optimize...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86573
--- Comment #2 from Marc Glisse ---
When passing by copy, gcc seems to manage with default flags, but your
-std=c++2a -fno-exceptions hinder it somehow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86573
--- Comment #7 from Marc Glisse ---
The real difference in -std=c++17 is _GLIBCXX_EXTERN_TEMPLATE. With -std=c++14,
we have many extern templates which the compiler almost never inlines. This
leaves existing inline functions small enough to be in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590
--- Comment #5 from Marc Glisse ---
-finline-limit=80 or higher (or more precisely --param
max-inline-insns-auto=40) lets it optimize.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
--- Comment #3 from Marc Glisse ---
We already simplify some simple cases like x*t/t -> x in match.pd. Larger cases
are for a pass like reassoc. In this particular case, we could also imagine
somehow noticing that (x*y)*z is better reassociated a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
--- Comment #5 from Marc Glisse ---
(In reply to Richard Biener from comment #4)
> Yeah, generally we can't associate because (x*y)*z may not overflow because
> x == 0 but x*(y*z) may because y*z overflows.
We can do it
- in the wrapping case (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86701
--- Comment #1 from Marc Glisse ---
Aren't you allowed to have null characters in the middle of a std::string?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86710
--- Comment #1 from Marc Glisse ---
This kind of transformation needs to be protected by some unsafe math flag, and
by a single_use (aka :s) check on the logs. No :c in the output. The third
transformation has nothing to do with logs, you are jus
rmal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
(could be rtl-optimization or target)
void f(double*d,double*e){
for(;d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86729
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86732
--- Comment #2 from Marc Glisse ---
While I would also like to see this optimized better, ISTR that this was done
on purpose, you may want to look at the old discussions. Some languages may
have things set up to catch null dereferences, but that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86732
--- Comment #4 from Marc Glisse ---
(In reply to Richard Biener from comment #3)
> note how it doesn't eliminate the actual load which probably causes the
> odd code-generation.
The code says:
/* We want the NULL pointer dereference to actua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57112
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86763
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
On a modern x86_64, multiplications are super fast and divisions are much
slower, so as soon as we have 2
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
In decl.c:cxx_init_decl_processing, the C++ front-end predeclares ::operator
new (normal or vector, aligned or not) and marks it with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86819
--- Comment #2 from Marc Glisse ---
There are 2 independent things.
TARGET_MIN_DIVISIONS_FOR_RECIP_MUL controls replacing several divisions with
the same divisor (a/x, b/x, c/x) with one division (y=1/x) and several
multiplications (a*y, b*y, c*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #27 from Marc Glisse ---
(In reply to Andrew Pinski from comment #0)
> the return is not turned into 1
It is now. I didn't check since when.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86819
--- Comment #4 from Marc Glisse ---
(In reply to Alexander Monakov from comment #3)
> I think there may be realistic situations where the change can introduce a
> regression: while a win throughput-wise, it introduces one multiplication
> latency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86819
--- Comment #6 from Marc Glisse ---
(In reply to Alexander Monakov from comment #5)
> Note that your code compares throughput. A microbenchmark for comparing
> latency would chain dependent computations, e.g. like this:
Ok, the 2 divisions manag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86829
--- Comment #1 from Marc Glisse ---
You shouldn't use float_type_node directly, since the operations might be on
double or long double.
Do you have a copyright assignment (https://gcc.gnu.org/contribute.html) ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86835
Marc Glisse changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86732
--- Comment #7 from Marc Glisse ---
(In reply to Jeffrey A. Law from comment #5)
> And FWIW, I think we should be using __builtin_trap rather than
> __builtin_unreachable in many more places because of the security concerns.
It would be better t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86855
--- Comment #2 from Marc Glisse ---
More precisely -ffast-math implies -fno-signed-zeros.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86855
--- Comment #4 from Marc Glisse ---
It happens during inlining.
If I write instead:
const __m128 neg={0.0f,0.0f,-0.0f,-0.0f};
then the front-end already turns it into
const __m128 neg = { 0.0, 0.0, 0.0, 0.0 };
You really need -fsigned-zeros to co
-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Created attachment 44554
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87009
--- Comment #2 from Marc Glisse ---
Yes, there are still some transformations missing to canonicalize all binary
boolean functions. You mention ~(~a | b). We also need (a|~b)&(~a|b) and the
same with ^ in the middle. Possibly others (ideally, thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86999
--- Comment #3 from Marc Glisse ---
(In reply to asd_ from comment #2)
> I hope there will be one more FMA pass in the RTL stages in the future.:)
A new RTL pass is not necessary for this, the GIMPLE pass could be extended to
recognize (x±1)*y a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
--- Comment #8 from Marc Glisse ---
(just to put this somewhere)
We have multiple ways of doing pointer arithmetic in gcc. After the recent
patch, we know that g returns nonnull, but we don't know it for f.
struct A{int a,b;};
int*f(A*p){return&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #19 from Marc Glisse ---
This seems fixed in gcc-8, no?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008
--- Comment #1 from Marc Glisse ---
struct A { double a, b; };
struct B : A {};
templatevoid cp(T&a,T const&b){a=b;}
double f(B x){
B y; cp(y,x);
B z; cp(z,x);
return y.a - z.a;
}
This is not quite equivalent because RTL manages to optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008
--- Comment #2 from Marc Glisse ---
Or just:
struct A { double a, b; };
struct B : A {};
double f(B x){
B y;
A*px=&x;
A*py=&y;
*py=*px;
return y.a;
}
MEM[(struct A *)&y] = MEM[(const struct A &)&x];
y_6 = MEM[(struct A *)&y];
y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87066
--- Comment #2 from Marc Glisse ---
I am not convinced that rejecting new B[1] is a good idea, you could also
change the standard to say that it is ok. The destructor is only useful here
if, for new B[2], the first B is constructed ok but the con
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
#include
int f(unsigned long long x){ return std::bitset<64>(x).count(); }
should be a portable way to call a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86722
--- Comment #2 from Marc Glisse ---
noce_try_cmove has
if ((CONSTANT_P (if_info->a) || register_operand (if_info->a, VOIDmode))
&& (CONSTANT_P (if_info->b) || register_operand (if_info->b, VOIDmode)))
but the first 3 times we go through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82760
Marc Glisse changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80792
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87077
--- Comment #1 from Marc Glisse ---
SLP doesn't like the completely unrolled code. With #pragma GCC unroll 1, we
get at least some kind of vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86822
--- Comment #3 from Marc Glisse ---
Author: glisse
Date: Fri Aug 24 18:24:42 2018
New Revision: 263841
URL: https://gcc.gnu.org/viewcvs?rev=263841&root=gcc&view=rev
Log:
new(nothrow) is malloc-like
2018-08-24 Marc Glisse
PR libstdc+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86822
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87105
--- Comment #3 from Marc Glisse ---
With -ffast-math we (awkwardly) vectorize a couple min/max at the beginning,
but clearly not the whole thing like llvm.
-optimization
Severity: enhancement
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Just a random testcase so I can give numbers, I don't claim this is a good
testca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52034
Marc Glisse changed:
What|Removed |Added
Last reconfirmed|2012-01-29 00:00:00 |2018-8-30
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #1 from Marc Glisse ---
Created attachment 44638
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44638&action=edit
proof of concept patch (diff -w)
Trying to get an idea of how things could look like. I know
is_trivially_move_co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
Marc Glisse changed:
What|Removed |Added
Attachment #44638|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49836
--- Comment #5 from Marc Glisse ---
Hi,
I understand not using assignment when it isn't necessary. But we ended up with
a stricter testcase using CopyConsOnlyType, where the type has a deleted move
constructor which, as far as I understand the st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87186
--- Comment #2 from Marc Glisse ---
How did you check? Looking at the .optimized dump or the asm, it is optimized
to a simple xor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87192
--- Comment #6 from Marc Glisse ---
I think the warning is about *accessing* (read or write) out of bound, not just
creating a pointer. That sounds like a separate warning (clang calls it
-Warray-bounds-pointer-arithmetic).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87186
--- Comment #6 from Marc Glisse ---
In some sense, the bug is that .original is optimized at all, ideally it would
be the "original" unoptimized code. It is convenient to start optimizing single
expressions early, so we do it, but that's it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87203
--- Comment #1 from Marc Glisse ---
Dup of PR 82853 ?
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
int h();
static int f(int j,double*a){
if(j)
{
double t[1024];
for(int i=0;i<1024;++i){
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87254
--- Comment #2 from Marc Glisse ---
(In reply to Alexander Monakov from comment #1)
> I think the "stack growth" aspect of this issue is the same as PR 87094?
It is quite possible that this is a DUP indeed, I'll let someone else decide.
Here, if
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Hello,
I guess nobody will care much since this is vector, but I don't
understand why _M_start is a _Bit_iterator. This means that it inclu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87262
--- Comment #1 from Marc Glisse ---
4.8.2 belongs in a museum. If you want to perform some static analysis on
trunk, you may find someone to look at the output, but with an old version I
think you are wasting your time...
1101 - 1200 of 2562 matches
Mail list logo
