http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52436
--- Comment #2 from Marc Glisse 2013-04-01 15:14:59
UTC ---
Created attachment 29767
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29767
patch
This patch may be a bit too strong. In particular, it breaks
gcc.dg/vect/nodump-forwpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55611
--- Comment #5 from Marc Glisse 2013-04-02 12:11:12
UTC ---
See the discussion at:
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00692.html
which continues at:
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00049.html
for why we won
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52436
--- Comment #4 from Marc Glisse 2013-04-02 14:08:57
UTC ---
(In reply to comment #3)
> I'd re-organize it like
Ok, I'll try something like that.
> it avoids building a tree just to feed it into get_addr_base_and_unit_offset
The ide
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52436
--- Comment #6 from Marc Glisse 2013-04-02 14:36:59
UTC ---
(In reply to comment #5)
> No, get_addr_base_and_unit_offset_1 only is supposed to return the
> addressable offset into an object - it doesn't care about access sizes.
It is al
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52436
--- Comment #7 from Marc Glisse 2013-04-04 12:07:53
UTC ---
For the rest of the discussion, see the thread starting here:
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00169.html
In particular, the folding should be done in gimple only (m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56855
Bug #: 56855
Summary: optab_handler (op=vashr_optab, mode=V4DImode) finds
nothing
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56863
Bug #: 56863
Summary: cmpnltpd recognition
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56855
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56855
--- Comment #2 from Marc Glisse 2013-04-07 21:18:28
UTC ---
There is still something suboptimal in that with -mxop, vashrv2di3 works fine,
but tree-vect-generic lowers vashrv4di3 to scalars instead of v2di. But that
doesn't look like a tar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56873
Bug #: 56873
Summary: vector shift lowered to scalars
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56876
Bug #: 56876
Summary: Combine does not invent new moves
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
||2013-04-10
CC||glisse at gcc dot gnu.org
Resolution|INVALID |
Ever Confirmed|0 |1
--- Comment #2 from Marc Glisse 2013-04-10 07:42:51
UTC ---
Andrew, he isn&#
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56899
--- Comment #4 from Marc Glisse 2013-04-10 07:49:24
UTC ---
(In reply to comment #3)
> What's the target? I can't reproduce on x86_64, armv5tel, or m68k.
I've reproduced it with -O2 on x86_64-linux-gnu using trunk.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56932
--- Comment #2 from Marc Glisse 2013-04-12 11:50:23
UTC ---
The testcase in gcc.c-torture/execute/pr55875.c does seem off by 1. For i==250,
i+5 is 255 and we don't exit yet (that happens for 251) but we do write to the
array. Increasing th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56934
Bug #: 56934
Summary: ICE folding a COND_EXPR involving vectors
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54427
--- Comment #12 from Marc Glisse 2013-04-12
13:59:33 UTC ---
Another piece that would be nice:
scalar1 ? vector : scalar2
(we already perform the conversion from scalar2 to vector when the condition is
a vector)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56790
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56932
--- Comment #6 from Marc Glisse 2013-04-12 20:02:01
UTC ---
(In reply to comment #4)
> Well, indeed increasing the array-size helps to avoid this issue.
> Nevertheless
> I don't get why it produces wrong code for argument of call of func
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56944
Bug #: 56944
Summary: Better isfinite in some cases?
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56944
--- Comment #1 from Marc Glisse 2013-04-14 10:21:53
UTC ---
Maybe in C terms:
isnan(x) -> x!=x
isinf(x) -> fabs(x)>DBL_MAX
isfinite(x) -> fabs(x)<=DBL_MAX
what I am suggesting (with -fno-trapping-math, and maybe -Os) is:
isfinite(x) -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866
--- Comment #12 from Marc Glisse 2013-04-17
21:49:15 UTC ---
(In reply to comment #11)
> If fixing broken gcc's XOP/FMA/FMA4-extensions on AMD-CPUs depends on my
> ability to extract a stand-alone-test from glibc-testsuite then I'm
> real
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56944
--- Comment #3 from Marc Glisse 2013-04-18 22:47:55
UTC ---
Created attachment 29900
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29900
(x & inf) < inf
I only vaguely checked that the resulting asm was what I expected.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56944
Marc Glisse changed:
What|Removed |Added
Attachment #29900|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56944
--- Comment #6 from Marc Glisse 2013-04-19 15:11:58
UTC ---
(In reply to comment #5)
> For the vectorization, vectorizable_call should handle DF -> SI builtin
> vectorization, see e.g. how on i?86/x86_64 BUILT_IN_IFLOOR is vectorized.
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57009
Bug #: 57009
Summary: Select best typed instruction for scalar bitwise
operations
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57010
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57010
Marc Glisse changed:
What|Removed |Added
CC|glisse at gcc dot gnu.org |
--- Comment #4 from Marc Glisse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57010
--- Comment #7 from Marc Glisse 2013-04-20 11:17:27
UTC ---
(In reply to comment #6)
> By the way, traditionally, for *library* patches we never used -p + I'm
> traveling sorry (C++ in Bristol), I barely installed some stuff on this tiny
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57010
--- Comment #8 from Marc Glisse 2013-04-20 11:25:30
UTC ---
(In reply to comment #6)
> More to the point, I'm under the impression that preliminarily checking
> (__last
> - __first > 1) is more user friendly as undefined behavior in case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57009
--- Comment #1 from Marc Glisse 2013-04-20 13:00:48
UTC ---
At least in the case where a constant is involved, it would probably be
necessary to look at how the result is used (makes it much harder). If it is
used in a floating point opera
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57024
Bug #: 57024
Summary: gcc too eager splitting cvtss2sd into unpcklps +
cvtps2pd
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57024
--- Comment #1 from Marc Glisse 2013-04-21 17:33:46
UTC ---
Maybe the processor is just badly detected or modeled? I noticed on the same
machine another surprising tuning issue. Adding -march=native changes for some
other code:
.cf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57029
--- Comment #2 from Marc Glisse 2013-04-22 13:07:07
UTC ---
There is -ftrapping-math, which I think is supposed to have an effect here. And
if this was implemented properly, I hope it would be turned off by default.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57056
--- Comment #1 from Marc Glisse 2013-04-24 18:43:08
UTC ---
Some relevant links:
PR 56944
http://sourceware.org/bugzilla/show_bug.cgi?id=15384
http://sourceware.org/ml/libc-alpha/2013-04/msg00568.html
Note that on my core2 laptop, it i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #4 from Marc Glisse 2013-04-25 06:19:35
UTC ---
(In reply to comment #0)
> Now suppose the following function:
>
> void g(A &&a)
> {
> a.p();
> }
>
> Which overload should GCC call? This is my request for clarificat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #5 from Marc Glisse 2013-04-25 06:34:03
UTC ---
(In reply to comment #4)
> (In reply to comment #0)
> > Making it:
> >
> > std::move(a).p();
> >
> > Does not help.
>
> It does for me...
Note that I only tested 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #7 from Marc Glisse 2013-04-25 07:08:07
UTC ---
(In reply to comment #6)
> void f(A &&a)
> {
> std::move(a).p();
> }
>
> _Z1fO1A:
> .cfi_startproc
> jmp _ZNR1A1pEv@PLT #
> .cfi_endproc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #9 from Marc Glisse 2013-04-25 07:28:01
UTC ---
(In reply to comment #8)
> Is this second call supposed to be to R? If it's to O, it's exactly what I
> need
> to make the feature useful.
It is O.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #13 from Marc Glisse 2013-04-26
05:05:48 UTC ---
Note for Thiago: please be aware of the risks of returning an rvalue reference,
as opposed to just a value. The following codes will fail at runtime:
Qstring const& a=QString("
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57112
Bug #: 57112
Summary: -march=x86-64 not documented
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: documentation
Sev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57111
--- Comment #4 from Marc Glisse 2013-04-30 18:37:41
UTC ---
gcc has -Wfree-nonheap-object, which works for free but not for delete or
delete[]. Extending it to these functions seems like a reasonable RFE.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57111
--- Comment #6 from Marc Glisse 2013-04-30 22:07:02
UTC ---
(In reply to comment #5)
> It seems to me that the option "free-nonheap-object" does not work in gcc.
You need to add -O2 (maybe -O1 is enough, sometimes you need -O3), otherwis
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57111
Marc Glisse changed:
What|Removed |Added
Keywords||diagnostic
Status|VERI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57172
--- Comment #1 from Marc Glisse 2013-05-04 21:27:02
UTC ---
Created attachment 30031
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30031
rough untested patch
This patch (missing at least testing and an update of the comments) seem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157
--- Comment #2 from Marc Glisse 2013-05-05 07:19:07
UTC ---
Created attachment 30033
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30033
fold_binary patch
A forwprop patch would be better, but this seems to work.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57175
Bug #: 57175
Summary: NRVO and alignment
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57176
Bug #: 57176
Summary: copy elision with function arguments passed by value
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: miss
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57176
--- Comment #2 from Marc Glisse 2013-05-06 12:52:41
UTC ---
(In reply to comment #1)
> Unless I'm misunderstanding your suggestion I think that a compiler is not
> allowed to apply copy-elision here, because that case was explicitly exclud
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57176
--- Comment #4 from Marc Glisse 2013-05-06 13:44:51
UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > Do you have a link to the discussion, or happen to remember the arguments?
> > I can see that there are more possible iss
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57198
Bug #: 57198
Summary: ICE in warn_logical_operator for vectors
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54427
--- Comment #13 from Marc Glisse 2013-05-07
21:59:08 UTC ---
(In reply to comment #11)
> - support &&, ||, !
A patch was posted at:
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00783.html
but the only answer was against supporting th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278
--- Comment #7 from Marc Glisse 2013-05-07 22:48:40
UTC ---
(In reply to comment #6)
> I'm surprised that
> the 16-bit rotations aren't detected/folded into rotations (or rotate_left
> (u16, 8) into a bswap16).
See also PR 45216 for ro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202
--- Comment #3 from Marc Glisse 2013-05-08 08:02:23
UTC ---
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00740.html
that patch (or maybe a later iteration) is waiting for reviews but I think it
is what this PR is asking for.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57219
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57224
Bug #: 57224
Summary: Remove __builtin_ia32_cmpngtss and
__builtin_ia32_cmpngess
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56766
--- Comment #2 from Marc Glisse ---
Created attachment 30073
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30073&action=edit
patch to recognize vec_merge
This passes bootstrap+testsuite. I had to swap tem1 and tem2 in the example,
which I t
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Hello,
the vector lowering pass, when it sees a rotate on a vector that is not a
supported operation, lowers it to scalar rotates. However, from a quick look at
the RTL expanders
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Hello,
this code is a variant of the code at
http://stackoverflow.com/questions/16493290/why-is-inlined-function-slower-than-function-pointer
typedef void (*Fn)();
long sum = 0;
inline void accu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52239
--- Comment #17 from Marc Glisse ---
Hello,
the "Keywords" field auto-completes when editing an existing bug, but not in
the form to create a new bug. I seem to remember that it used to work...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57266
--- Comment #1 from Marc Glisse ---
Ah, sorry. I already had to play a bit with types to avoid similar painful
warnings on x86_64 and didn't check on other platforms. I think making "low" an
unsigned int would be fine (we have just checked that it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57266
--- Comment #2 from Marc Glisse ---
Created attachment 30108
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30108&action=edit
patch
This passed bootstrap+testsuite on x86_64-linux-gnu. Is it enough to fix
bootstrap for you?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
--- Comment #10 from Marc Glisse ---
Oups, I didn't notice you had already worked on this. Please don't hesitate to
post (and ping) your patch to gcc-patches next time. Also, I didn't touch
tree-tailcall.c, that might still be needed...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57286
--- Comment #3 from Marc Glisse ---
Intuitively, I'd say:
@@ -10041,7 +10041,7 @@
if (TREE_CODE (arg1) == COND_EXPR
|| TREE_CODE (arg1) == VEC_COND_EXPR
- || COMPARISON_CLASS_P (arg1))
+ || (COMPARISON_CLASS_P (arg1) && !
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54219
Bug #: 54219
Summary: __builtin_shuffle mask reversed
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
||glisse at gcc dot gnu.org
Resolution||FIXED
--- Comment #29 from Marc Glisse 2012-08-11
11:26:40 UTC ---
I guess both subscript and shuffle are in, so I can close. There is already PR
53094 to track the constexpr issues.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54193
--- Comment #2 from Marc Glisse 2012-08-12 16:20:45
UTC ---
Author: glisse
Date: Sun Aug 12 16:20:41 2012
New Revision: 190328
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190328
Log:
2012-08-12 Marc Glisse
PR middle-end/54193
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54193
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50167
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54112
--- Comment #4 from Marc Glisse 2012-08-13 11:55:04
UTC ---
Author: glisse
Date: Mon Aug 13 11:55:00 2012
New Revision: 190340
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190340
Log:
2012-08-13 Marc Glisse
PR libstdc++/54112
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54112
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
--- Comment #4 from Marc Glisse 2012-08-14 10:35:56
UTC ---
(In reply to comment #3)
> I don't want to start a lengthy discussion here about the C++ Standard Library
> specification, but it must be clear that removing above paragraph would have
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
--- Comment #6 from Marc Glisse 2012-08-14 10:48:48
UTC ---
(In reply to comment #5)
> It's true however, that, as I mentioned already somewhere, in general our
> implementation doesn't have control over the underlying *.h headers.
Although it d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50800
--- Comment #8 from Marc Glisse 2012-08-14 11:03:31
UTC ---
Although if you have a testcase without may_alias, you should attach it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #45 from Marc Glisse 2012-08-14
13:20:55 UTC ---
(In reply to comment #11)
> > Marc, do you know where the use of the
> > flatten attribute comes from in your code?
> Comes from the Eigen library, I'll talk to them about it and see if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54304
--- Comment #3 from Marc Glisse 2012-08-17 19:27:08
UTC ---
When you say: "the system libraries", where are they? /opt/local/lib?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54304
--- Comment #9 from Marc Glisse 2012-08-17 19:40:19
UTC ---
Well, there is the usual problem that if you use external libraries A and B
that are both installed in both path1 and path2 and you want A from path1 and B
from path2, that's not possibl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54304
--- Comment #11 from Marc Glisse 2012-08-17
21:21:57 UTC ---
(In reply to comment #10)
> You don't need the -L flags for the in-tree libraries at all as you could just
> put, say, "path_to_mpfr/libmpfr.a" on the command line. I understand that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54304
--- Comment #13 from Marc Glisse 2012-08-17
22:06:07 UTC ---
(In reply to comment #12)
> Well, directories given by -I are searched before system directories,
Yes (system directories are those given by -isystem or hardcoded in the
compiler).
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54317
--- Comment #1 from Marc Glisse 2012-08-20 15:46:58
UTC ---
Wow, I didn't expect that patch to break a multiplication test...
It sounds like you have before and after compilers. Do you have tree-vrp dumps
from both? (I would ask if a stage1 compi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54346
Bug #: 54346
Summary: combine permutations
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54317
--- Comment #3 from Marc Glisse 2012-08-22 06:19:17
UTC ---
Actually, I reviewed my patch and I just found a bug, which can be seen on
x86_64 with:
extern void g();
void f(unsigned __int128 x){
unsigned __int128 n2 = 1; n2 <<= 127;
if(x>n2)re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54317
--- Comment #4 from Marc Glisse 2012-08-22 12:29:34
UTC ---
Author: glisse
Date: Wed Aug 22 12:29:23 2012
New Revision: 190591
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190591
Log:
2012-08-22 Marc Glisse
PR tree-optimization/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54317
--- Comment #5 from Marc Glisse 2012-08-22 12:38:36
UTC ---
Hello,
I have no idea if the last commit helped, feel free to reconfirm the bug.
||glisse at gcc dot gnu.org
--- Comment #12 from Marc Glisse 2012-08-22
20:00:11 UTC ---
Adding keyword ABI following Paolo's comment.
(not a bug, according to Daniel, but that's orthogonal to being ABI-related)
||glisse at gcc dot gnu.org
--- Comment #3 from Marc Glisse 2012-08-22 20:23:46
UTC ---
The suggestion in this PR is quite wild, but the fact that
sizeof(tuple>>>>)==20 is a real issue that could
probably be solved with less trouble (still ABI-breaking). Maybe I should have
split the PR...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54376
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54376
--- Comment #11 from Marc Glisse 2012-08-26
07:54:41 UTC ---
Created attachment 28087
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28087
Alternate solution
What about this (completely untested) other solution? (reindentation is needed
aft
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54400
Bug #: 54400
Summary: recognize haddpd
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54408
Bug #: 54408
Summary: sqrt for vector types
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54422
Bug #: 54422
Summary: Merge adjacent stores of elements of a vector (or
loads)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54427
Bug #: 54427
Summary: Expose more vector extensions
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54442
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54400
--- Comment #1 from Marc Glisse 2012-09-01 09:40:14
UTC ---
The code below seems to optimize v[0]-v[1] and v[1]+v[0]. It doesn't recognize
v[0]+v[1], but that would not be too hard to add I guess. Compared to the true
hadd insn, I removed the set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54459
--- Comment #1 from Marc Glisse 2012-09-02 18:08:16
UTC ---
Likely a dup of PR 54453.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419
--- Comment #17 from Marc Glisse 2012-09-03
09:43:13 UTC ---
(In reply to comment #16)
> So, I think this is something that should be tested for in libstdc++-v3
> configure and enabled in the headers only if _GLIBCXX_HAVE_* macro is defined.
One
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #19
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54400
--- Comment #3 from Marc Glisse 2012-09-03 10:21:48
UTC ---
(In reply to comment #2)
> The basic-block vectorizer does not handle reductions and it would be another
> natural place to perform this optimization.
I thought about turning a PLUS_EXP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419
--- Comment #29 from Marc Glisse 2012-09-04
18:24:05 UTC ---
(In reply to comment #26)
> The Apple clang 4.0 compiler defaults to its integrated
> assembler
> such that the simple test case...
>
>
> int
> main ()
> {
> asm("rdrand %eax");
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54484
--- Comment #4 from Marc Glisse 2012-09-05 06:12:20
UTC ---
Diego,
did you also take a look at the warning about lessthan_ in the clang messages?
201 - 300 of 2561 matches
Mail list logo
