http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51938
--- Comment #6 from Marc Glisse 2012-06-08 19:49:07
UTC ---
Created attachment 27590
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27590
incomplete patch
I wonder if this is the right direction. At least it passes the testsuite and
optimiz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51938
Marc Glisse changed:
What|Removed |Added
Attachment #27590|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51938
Marc Glisse changed:
What|Removed |Added
Attachment #27591|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30318
--- Comment #19 from Marc Glisse 2012-06-20
19:12:22 UTC ---
(In reply to comment #18)
> I have now pushed all my refactorings into VRP,
Thanks.
> Can you adjust your patch with the double-double_int arithmetic stuff
> to that fact?
I'll look
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53805
Bug #: 53805
Summary: combine_comparisons changes trapping behavior
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53805
--- Comment #2 from Marc Glisse 2012-06-29 12:19:07
UTC ---
(In reply to comment #1)
> We do not try to preserve traps instead we only try to not produce new ones.
That would make a lot of sense, and assuming it is the official policy I am
happy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53806
Bug #: 53806
Summary: Missed optimization (a<=b)&&(a>=b) with trapping
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52589
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53822
Bug #: 53822
Summary: Diagnostic: spell out type in ambiguous call
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Prior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53822
--- Comment #1 from Marc Glisse 2012-06-30 16:59:13
UTC ---
Hmm, the true message from 4.8, not 4.7 this time:
mp.cc: In function 'int main()':
mp.cc:6:6: error: call of overloaded 'f(NT&)' is ambiguous
f(i);
^
mp.cc:6:6: note: candidat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53805
--- Comment #9 from Marc Glisse 2012-07-06 21:53:32
UTC ---
Suspicious code:
combine_comparisons has special code that depends on which comparison comes
first, but maybe_fold_and_comparisons calls and_comparisons_1 (and thus
combine_comparisons)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30318
--- Comment #20 from Marc Glisse 2012-07-25
18:26:18 UTC ---
Author: glisse
Date: Wed Jul 25 18:26:12 2012
New Revision: 189861
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189861
Log:
2012-07-25 Marc Glisse
PR tree-optimization/3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54101
--- Comment #1 from Marc Glisse 2012-07-27 06:04:09
UTC ---
I don't think the issue is with declval, this is probably a dup of the PR
saying that ?: has a wrong return type with g++ (can't find the number right
now).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54078
--- Comment #3 from Marc Glisse 2012-07-28 06:47:49
UTC ---
(In reply to comment #0)
> without -flto 106856 bytes
> with -flto 156312 bytes
But is it faster?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54112
Bug #: 54112
Summary: including complex.h and complex fails in C++03
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54112
--- Comment #2 from Marc Glisse 2012-07-28 10:26:42
UTC ---
(In reply to comment #1)
> Why it happens only in C++03 mode?
Because the complex.h wrapper distributed with libstdc++ does:
#ifdef __GXX_EXPERIMENTAL_CXX0X__
# include
#else
# if _GL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30318
Marc Glisse changed:
What|Removed |Added
Attachment #27317|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54130
Bug #: 54130
Summary: Recognize builtins with bool return type
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54130
--- Comment #2 from Marc Glisse 2012-07-31 09:38:38
UTC ---
(In reply to comment #1)
> I think your non-matching prototype disables builtin recognition.
Yes.
> The C standard specifies isnan as returning int, so I think GCC is correct
> here.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
Bug #: 54146
Summary: Very slow compile at -O1 (expand vars)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #2 from Marc Glisse 2012-07-31 18:47:48
UTC ---
(In reply to comment #1)
> Are you compiling GCC with --enable-checking=release to do the timings?
I first noticed the issue with the compiler provided by debian (4.7.1), which
has --en
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54130
--- Comment #4 from Marc Glisse 2012-07-31 19:20:09
UTC ---
Joseph,
I understand your comments, but I don't know what conclusion to take from them
about whether gcc should recognize int/bool isnan(double) as a builtin...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54130
--- Comment #6 from Marc Glisse 2012-07-31 20:13:38
UTC ---
(In reply to comment #5)
> If your system headers declare isnan with bool return type I advise making
> fixincludes fix them.
But the C++ standard requires a bool return type, using fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54130
--- Comment #8 from Marc Glisse 2012-08-01 05:51:26
UTC ---
(In reply to comment #7)
> C++ may also require functions rather than macros in various cases. It's
> the job of the libstdc++ headers, provided by GCC, to provide a (probably
> inlin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54130
--- Comment #9 from Marc Glisse 2012-08-01 09:22:37
UTC ---
I realize that several (not all) of the things discussed here assume that
functions returning bool and int are binary compatible, which is likely true on
most platforms but there might b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54130
--- Comment #12 from Marc Glisse 2012-08-01
09:49:12 UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> > I realize that several (not all) of the things discussed here assume that
> > functions returning bool and int are binary compat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54130
--- Comment #13 from Marc Glisse 2012-08-01
09:52:19 UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> > I realize that several (not all) of the things discussed here assume that
> > functions returning bool and int are binary compat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #11 from Marc Glisse 2012-08-01
15:59:43 UTC ---
(In reply to comment #9)
> I'm beginning to think this is one of those cases of "Doctor it hurts if I
> ..."
> that should be closed as WONTFIX.
Indeed, might even call it INVALID. Th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53805
--- Comment #10 from Marc Glisse 2012-08-02
19:54:47 UTC ---
Author: glisse
Date: Thu Aug 2 19:54:43 2012
New Revision: 190100
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190100
Log:
2012-08-02 Marc Glisse
PR tree-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30318
--- Comment #22 from Marc Glisse 2012-08-03
12:21:25 UTC ---
Author: glisse
Date: Fri Aug 3 12:21:14 2012
New Revision: 190125
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190125
Log:
gcc/
2012-08-03 Marc Glisse
PR tree-optimizat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30318
--- Comment #23 from Marc Glisse 2012-08-03
12:35:40 UTC ---
I think that's it for me. Should we close the bug, or is there still something
missing?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54165
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51938
--- Comment #9 from Marc Glisse 2012-08-06 16:38:52
UTC ---
Author: glisse
Date: Mon Aug 6 16:38:48 2012
New Revision: 190184
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190184
Log:
2012-08-06 Marc Glisse
gcc/
PR tree-optimizati
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52005
--- Comment #3 from Marc Glisse 2012-08-06 16:38:52
UTC ---
Author: glisse
Date: Mon Aug 6 16:38:48 2012
New Revision: 190184
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190184
Log:
2012-08-06 Marc Glisse
gcc/
PR tree-optimizati
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51938
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
||glisse at gcc dot gnu.org
Resolution||FIXED
--- Comment #4 from Marc Glisse 2012-08-06 16:58:16
UTC ---
All the above testcases are now optimized (at least at -O2).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192
Bug #: 54192
Summary: -fno-trapping-math by default?
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192
--- Comment #2 from Marc Glisse 2012-08-07 13:13:46
UTC ---
Don't you need to tell the compiler (with the FENV_ACCESS pragma) that you are
going to look at flags, just like you tell it that you are going to use
non-default rounding modes?
"In ge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54193
Bug #: 54193
Summary: dump_gimple_assign raw can't handle 4 operands
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: minor
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58524
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58521
Marc Glisse changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58527
--- Comment #1 from Marc Glisse ---
The parameter pack can only be deduced if it is in last position (that's an
arbitrary restriction, but it is in C++11). However, you can still do:
weeble(123,456,789,3.1416);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58527
--- Comment #3 from Marc Glisse ---
(In reply to Nick Maclaren from comment #2)
> I would be interested in a reference to the wording in the standard,
> if you know it offhand. I failed to find it.
[temp.deduct.call]
For a function parameter pa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58529
--- Comment #3 from Marc Glisse ---
Does it help if you pass the_bins_size as int*restrict (and adapt the uses)? Or
use a local variable instead that you write at the end? Gcc has a notoriously
restricted view of what restrict means, compared to m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58529
--- Comment #5 from Marc Glisse ---
I actually see gcc 4 times (not just 30%) slower than icpc here using the same
command lines. The asm produced by gcc contains tons of mov insn.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58529
--- Comment #6 from Marc Glisse ---
Please ignore my last comment, I now see the same 30% difference, the rest must
have been a user error on my part.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338
--- Comment #9 from Marc Glisse ---
Author: glisse
Date: Wed Sep 25 20:28:12 2013
New Revision: 202924
URL: http://gcc.gnu.org/viewcvs?rev=202924&root=gcc&view=rev
Log:
2013-09-25 Marc Glisse
PR libstdc++/58338
* include/bits/forward_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57223
--- Comment #5 from Marc Glisse ---
(In reply to Usishchev Yury from comment #3)
> I'm testing it on current trunk, and second loop is not vectorized both with
> floating point and integer types.
> For floating point types it is not vectorized due
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
--- Comment #17 from Marc Glisse ---
Author: glisse
Date: Thu Oct 3 16:13:54 2013
New Revision: 203163
URL: http://gcc.gnu.org/viewcvs?rev=203163&root=gcc&view=rev
Log:
2013-10-03 Marc Glisse
PR c++/19476
gcc/c-family/
* c.opt (fchec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
--- Comment #18 from Marc Glisse ---
Author: glisse
Date: Thu Oct 3 23:48:18 2013
New Revision: 203194
URL: http://gcc.gnu.org/viewcvs?rev=203194&root=gcc&view=rev
Log:
2013-10-04 Marc Glisse
PR c++/19476
gcc/cp/
* decl.c (cxx_init_d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58483
Bug 58483 depends on bug 19476, which changed state.
Bug 19476 Summary: Missed null checking elimination with new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
What|Removed |Added
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24242
Bug 24242 depends on bug 19476, which changed state.
Bug 19476 Summary: Missed null checking elimination with new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
What|Removed |Added
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088
Marc Glisse changed:
What|Removed |Added
CC||heiko.abraham@hella-gutmann
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58617
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58480
--- Comment #1 from Marc Glisse ---
Author: glisse
Date: Tue Oct 8 10:39:49 2013
New Revision: 203271
URL: http://gcc.gnu.org/viewcvs?rev=203271&root=gcc&view=rev
Log:
2013-10-08 Marc Glisse
PR tree-optimization/58480
gcc/
* tree-vrp
|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |glisse at gcc dot
gnu.org
--- Comment #2 from Marc Glisse ---
Done for 4.9.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58483
Bug 58483 depends on bug 58480, which changed state.
Bug 58480 Summary: Use attribute((nonnull)) to optimize callers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58480
What|Removed |Added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20318
--- Comment #10 from Marc Glisse ---
Author: glisse
Date: Wed Oct 9 13:03:13 2013
New Revision: 203316
URL: http://gcc.gnu.org/viewcvs?rev=203316&root=gcc&view=rev
Log:
2013-10-09 Marc Glisse
PR tree-optimization/20318
gcc/c-family/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19831
--- Comment #15 from Marc Glisse ---
See the discussion that starts at:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130923/188747.html
(it continues in the following weeks) for optimization 2 of comment #14 in
clang. The key ide
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24825
Bug 24825 depends on bug 20318, which changed state.
Bug 20318 Summary: RFE: add attribute to specify that a function never returns
NULL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20318
What|Removed |Added
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21856
Bug 21856 depends on bug 20318, which changed state.
Bug 20318 Summary: RFE: add attribute to specify that a function never returns
NULL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20318
What|Removed |Added
---
||glisse at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #11 from Marc Glisse ---
Marking svn_fs_fs__id_parse and svn_error_create with the new
__attribute__((__returns_nonnull__)) makes the warning about root_id disappear
at -O3, so I am going to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
Bug 19476 depends on bug 20318, which changed state.
Bug 20318 Summary: RFE: add attribute to specify that a function never returns
NULL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20318
What|Removed |Added
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24242
Bug 24242 depends on bug 20318, which changed state.
Bug 20318 Summary: RFE: add attribute to specify that a function never returns
NULL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20318
What|Removed |Added
---
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Depends on: 21856, 24825
For PR 20318, we added an attribute "returns_nonnull". For now, it is quite
basic and only used by fold-const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58689
--- Comment #1 from Marc Glisse ---
5) A warning that suggests adding the attribute to a function, when gcc can
detect that the return value is != 0.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
--- Comment #1 from Marc Glisse ---
Created attachment 30981
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30981&action=edit
basic patch
This is a very limited version of this optimization. It is in
simplify_builtin_call, so only triggers i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58689
--- Comment #3 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #2)
> Well, guess the warning could have many false positives.
Not more than the other -Wsuggest-attribute= warnings, no? I don't see how it
could be wrong. Sure you may
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055
--- Comment #4 from Marc Glisse ---
(In reply to Eric Botcazou from comment #3)
> You can go farther if the return operation overwrites entirely the anonymous
> return object and for example allow returning literals, but I don't know if
> this is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55912
--- Comment #3 from Marc Glisse ---
(In reply to Richard Biener from comment #2)
> Most of the math builtin folding needs to be re-done at GIMPLE level based
> on SSA form. Convenient places are either tree-ssa-forwprop.c or
> tree-ssa-math-opts.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57605
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57572
--- Comment #1 from Marc Glisse ---
Created attachment 30992
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30992&action=edit
vector-only patch
I have had this lying around for a while. IIRC it seemed to work, but it
doesn't handle the mixed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46507
Marc Glisse changed:
What|Removed |Added
Summary|std::tuple missed |std::get and
|optimizatio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338
--- Comment #11 from Marc Glisse ---
(In reply to bredelin from comment #10)
> Was this change intentional?
See:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01101.html
and Paolo's reply.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338
--- Comment #12 from Marc Glisse ---
(In reply to bredelin from comment #10)
> http://cplusplus.github.io/LWG/lwg-active.html#2193
I suggest you open a separate bugzilla PR for this. Before my patch we were
already inconsistent about it.
||2013-10-13
CC||glisse at gcc dot gnu.org
Resolution|DUPLICATE |---
Ever confirmed|0 |1
--- Comment #3 from Marc Glisse ---
The quoted paragraph is implemented in gcc-4.9. However, this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58713
--- Comment #4 from Marc Glisse ---
If I try to sfinae-out this function based on os<
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
--- Comment #4 from Marc Glisse ---
(In reply to Richard Biener from comment #2)
> (In reply to Marc Glisse from comment #1)
> > This is a very limited version of this optimization. It is in
> > simplify_builtin_call, so only triggers if malloc/ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
--- Comment #6 from Marc Glisse ---
(In reply to Richard Biener from comment #5)
> We have walk_aliased_vdefs for this. Basically the first callback
> you receive has to be the malloc, otherwise there is an aliasing
> stmt inbetween.
Cool! Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
--- Comment #7 from Marc Glisse ---
(In reply to Richard Biener from comment #5)
> We have walk_aliased_vdefs for this. Basically the first callback
> you receive has to be the malloc, otherwise there is an aliasing
> stmt inbetween. Initialize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
--- Comment #8 from Marc Glisse ---
Created attachment 31003
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31003&action=edit
walk_aliased_vdefs experiment
Incomplete patch I used for my previous comment.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58714
Marc Glisse changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #4 from Marc Glisse
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Hello,
I thought gcc already had this optimization but apparently not. We don't
produce the same code with alloca and with arrays:
void f(int*);
v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58806
--- Comment #1 from Marc Glisse ---
struct A { int i; double d; };
void g(double*);
void f(){
A a;
a.i=1;
g(&a.d);
if(a.i != 1) __builtin_abort();
}
Here, I guess g is allowed to take its argument, cast it to char*, subtract
offsetof(str
||glisse at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #2 from Marc Glisse ---
We currently produce this .optimized:
foo (int i)
{
void * saved_stack.2;
:
saved_stack.2_3 = 0B;
GIMPLE_NOP
return;
}
(and RTL finishes the cleanup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58742
--- Comment #6 from Marc Glisse ---
Thanks. For reference, as noted by Jakub and confirmed by Richard, we will also
need at some point a gimple version for:
int *
fx (int *b, int *e)
{
ptrdiff_t p = e - b;
return b + p;
}
(or s/ptrdiff_t/lon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58817
--- Comment #3 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #1)
> Transforming VLAs that way isn't a good idea, at least if the size isn't
> really small, at least when the VLA isn't in a scope that dies at the
> function's end (or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58834
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58772
--- Comment #8 from Marc Glisse ---
(In reply to Richard Biener from comment #3)
> Paolo, does libstdc++ provide a custom allocator for aligned memory?
PR 55727
> Is this issue going to be resolved with C++1y?
There is a NB comment requesting t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58806
--- Comment #3 from Marc Glisse ---
(In reply to Richard Biener from comment #2)
> You cannot find the PR because it's already implemented via the "fn spec"
> attribute (conveniently not user-accessible because bike-shedding about
> whether separa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58806
--- Comment #4 from Marc Glisse ---
(In reply to Marc Glisse from comment #3)
> I should look at where exactly the difference between memcpy and init plays a
> role.
It is in call_may_clobber_ref_p_1 that memcpy takes a shortcut: it only checks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58806
--- Comment #5 from Marc Glisse ---
Created attachment 31074
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31074&action=edit
experimental patch
This optimizes the testcase in comment #0 if I mark g with the attribute
"no_global_write" and u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58359
--- Comment #7 from Marc Glisse ---
(In reply to Anatoly Sinyavin from comment #3)
> So I suggest processing __builtin_unreachable immediately after "cfg" pass
> (cfg buiding).
That seems awfully early. Don't we want to at least wait until after
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58859
--- Comment #2 from Marc Glisse ---
Try adding noexcept(false) on the destructor?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58359
--- Comment #11 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #10)
> That is still wrong, __builtin_unreachable is still very much useful even at
> the RTL level (where we expand it as basic blocks without successors).
> Perhaps if-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58872
--- Comment #1 from Marc Glisse ---
What do the arguments of brev mean?
Related to PR 50481.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19831
--- Comment #17 from Marc Glisse ---
void f (double * __restrict a) {
int * __restrict p = (int*) __builtin_malloc (sizeof (int));
*p = 42;
__builtin_free (p);
++*a; // Breaks the optimization!
}
Normally, gcc now manages to remove unused
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target: x86_64-linux-gnu
typedef unsigned __int128 ui;
ui f(ui a, unsigned long b){
return a/b;
}
is compiled to a library call to __udivti3, which is
601 - 700 of 2562 matches
Mail list logo
