https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup dot
org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63789
--- Comment #6 from Marc Glisse ---
Sorry, by recent I meant at least 6.1, I should have been more specific.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63789
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup dot
org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73714
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51938
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
Component|rtl-optimization|tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53350
--- Comment #5 from Marc Glisse marc.glisse at normalesup dot org 2012-05-15
14:50:42 UTC ---
You may first want to check whether you still get the bug with a more recent
gcc version.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53360
--- Comment #1 from Marc Glisse marc.glisse at normalesup dot org 2012-05-15
15:00:58 UTC ---
clang and gcc reject it, but intel and oracle accept it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53101
--- Comment #4 from Marc Glisse marc.glisse at normalesup dot org 2012-05-03
19:19:00 UTC ---
(define_peephole2
[(set (mem:VI8F_256 (match_operand 2))
(match_operand:VI8F_256 1 register_operand))
(set (match_operand:ssehalfvecmode 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53216
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30318
--- Comment #7 from Marc Glisse marc.glisse at normalesup dot org 2012-05-02
14:33:42 UTC ---
(In reply to comment #6)
On Sat, 28 Apr 2012, marc.glisse at normalesup dot org wrote:
I find it easier to use bignum and wrap at the end, instead
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27139
--- Comment #4 from Marc Glisse marc.glisse at normalesup dot org 2012-05-01
09:32:25 UTC ---
Hello Uros,
is there any other case you think should be handled, or should we close the
bug?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53100
--- Comment #3 from Marc Glisse marc.glisse at normalesup dot org 2012-05-01
12:47:03 UTC ---
(In reply to comment #2)
and not to introduce them just before an optimization that removes them.
Usually, doing (long)num1*(__int128)(long)num2 does
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53101
--- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2012-05-01
15:10:26 UTC ---
(In reply to comment #1)
We get MEM[(T * {ref-all})x] for the casting (not a BIT_FIELD_REF for
example).
This gets expanded to
(insn 6 5 7 (set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53101
--- Comment #3 from Marc Glisse marc.glisse at normalesup dot org 2012-05-01
17:17:42 UTC ---
(In reply to comment #2)
but operands[2] and operands[3] don't compare equal with rtx_equal_p, and
trying a match_dup refuses to compile because
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53177
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53173
--- Comment #1 from Marc Glisse marc.glisse at normalesup dot org 2012-04-30
20:02:59 UTC ---
Uh, where are you reporting a bug in gcc?
(In reply to comment #0)
I am trying to upgrade (GCC) 4.4.0 to (GCC) 4.6.2. I see bunch of
incompatible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53100
--- Comment #1 from Marc Glisse marc.glisse at normalesup dot org 2012-04-29
08:05:59 UTC ---
(In reply to comment #0)
It would be convenient if I
could just write the whole code with __int128 and let the compiler do the
optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53100
--- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2012-04-29
08:42:36 UTC ---
(In reply to comment #1)
On the other hand, tree-vrp does have the information that the
differences are in [-4294967295, 4294967295], which
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48891
--- Comment #6 from Marc Glisse marc.glisse at normalesup dot org 2012-04-29
13:15:40 UTC ---
I don't think it matters that much whether the return type is int or bool,
compared to the inconvenience of having 2 functions that conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53159
Bug #: 53159
Summary: Missing narrowing check
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51312
--- Comment #5 from Marc Glisse marc.glisse at normalesup dot org 2012-04-29
14:12:12 UTC ---
Created attachment 27261
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27261
build_enumerator patch
Changes the behavior on g++.dg/cpp0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53153
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53131
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #11 from Marc Glisse marc.glisse at normalesup dot org 2012-04-28
12:33:26 UTC ---
(In reply to comment #9)
It forgets to check first whether the first 2 ranges are trivial.
Or easier, instead of checking:
if (TREE_CODE (tem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #13 from Marc Glisse marc.glisse at normalesup dot org 2012-04-28
12:40:14 UTC ---
(In reply to comment #10)
But there is something strange, because it is warning it is always false,
which is obviously not true. So I think at some
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53131
--- Comment #6 from Marc Glisse marc.glisse at normalesup dot org 2012-04-28
12:45:19 UTC ---
(In reply to comment #5)
It seems a pretty small warning, but I guess #1 and #2 could
be split up, if that helps get #2 in.
I think
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #15 from Marc Glisse marc.glisse at normalesup dot org 2012-04-28
12:55:28 UTC ---
(In reply to comment #14)
(In reply to comment #13)
Except that this version would warn for xINT_MIN xINT_MAX, whereas this
belongs to other
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30318
--- Comment #5 from Marc Glisse marc.glisse at normalesup dot org 2012-04-28
13:18:25 UTC ---
Created attachment 27260
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27260
Wrap using gmp
I find it easier to use bignum and wrap at the end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #17 from Marc Glisse marc.glisse at normalesup dot org 2012-04-28
18:49:49 UTC ---
(In reply to comment #16)
I understand now, and I think you are right. We don't have a warning for
((int)x) INT_MIN or ((int)x) INT_MAX but I think
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53155
Bug #: 53155
Summary: Not parallel: test for -j fails
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53155
--- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2012-04-28
21:49:43 UTC ---
laptop-mg /tmp/m $ cat Makefile
all:
$(MAKE) plouf
plouf:
echo $(MFLAGS) $(filter -j, $(MFLAGS))
laptop-mg /tmp/m $ make -j
make plouf
make[1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #19 from Marc Glisse marc.glisse at normalesup dot org 2012-04-28
22:16:55 UTC ---
(In reply to comment #18)
I'm afraid that false positives would still be likely.
For example, suppose we're on a platform where
INT_MAX = LONG_MAX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53139
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29131
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53121
Bug #: 53121
Summary: Allow static_cast from pointer-to-vector to
pointer-to-object
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27139
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53100
Bug #: 53100
Summary: Optimize __int128 with range information
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53101
Bug #: 53101
Summary: Recognize casts to sub-vectors
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #23 from Marc Glisse marc.glisse at normalesup dot org 2012-04-24
11:57:22 UTC ---
(In reply to comment #21)
What does it mean exercise the backend a lot? Do you mean it takes a lot of
time?
I think so.
I haven't looked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53000
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53000
--- Comment #5 from Marc Glisse marc.glisse at normalesup dot org 2012-04-24
22:35:31 UTC ---
(In reply to comment #4)
it's not obvious to me what the right fix is
either so I'm not in a rush to change anything.
Actually, I now believe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53000
--- Comment #7 from Marc Glisse marc.glisse at normalesup dot org 2012-04-24
23:23:09 UTC ---
(In reply to comment #6)
which way is the standards committee leaning?
The DR is young, there hasn't been a meeting since. There weren't many
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53094
Bug #: 53094
Summary: vector literal
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53082
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #19 from Marc Glisse marc.glisse at normalesup dot org 2012-04-22
10:31:33 UTC ---
Created attachment 27217
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27217
shuffle
With this patch, g++ passes the few __builtin_shuffle tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #20 from Marc Glisse marc.glisse at normalesup dot org 2012-04-22
13:21:14 UTC ---
(In reply to comment #19)
Created attachment 27217 [details]
shuffle
Doesn't work with -std=c++11, which requires:
--- semantics.c(revision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #22 from Marc Glisse marc.glisse at normalesup dot org 2012-04-22
15:09:23 UTC ---
(In reply to comment #20)
And then I still need to write a cxx_eval_vec_perm function so the result of
__builtin_shuffle can be constexpr. I haven't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53025
--- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2012-04-21
07:45:57 UTC ---
Created attachment 27210
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27210
patch
Bootstrapped and regression tested.
Not posting it to gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53057
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53060
Bug #: 53060
Summary: Typo in build_binary_op for scalar-vector ops
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53060
--- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2012-04-21
14:59:54 UTC ---
(In reply to comment #1)
* gcc.dg/scal-to-vec2.c: New test.
This one runs the problematic code, but since this is a compile-only test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53055
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53036
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53036
--- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2012-04-19
12:14:04 UTC ---
Created attachment 27189
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27189
basic patch
The patch detects D as trivial.
Sadly, on this case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51314
--- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2012-04-19
21:19:23 UTC ---
Created attachment 27200
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27200
patch
s.cc: In function 'void f(U ...)':
s.cc:3:18: error: 'sizeof
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53025
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #10 from Marc Glisse marc.glisse at normalesup dot org 2012-04-17
10:22:07 UTC ---
Created attachment 27176
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27176
subscript
This patch (a simple copy of a paragraph from the C front
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53017
Bug #: 53017
Summary: Integer constant not constant enough for vector_size
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #12 from Marc Glisse marc.glisse at normalesup dot org 2012-04-17
11:59:12 UTC ---
(In reply to comment #11)
If it is indeed a copy, you should move the code c-common.c and share it. The
C-family FEs should share as much code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #14 from Marc Glisse marc.glisse at normalesup dot org 2012-04-17
13:06:40 UTC ---
Created attachment 27178
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27178
subscript 2 (Manuel-compliant)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #16 from Marc Glisse marc.glisse at normalesup dot org 2012-04-17
13:57:05 UTC ---
(In reply to comment #15)
Are you planning to send it to gcc-patches for approval or are you not happy
with it yet?
There is the problem of moving
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #18 from Marc Glisse marc.glisse at normalesup dot org 2012-04-17
16:41:58 UTC ---
(In reply to comment #17)
And now I should actually bootstrap and run the testsuite ;-)
Good luck!
It worked fine, same failures as I got the other
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53024
Bug #: 53024
Summary: Power of 2 requirement on vector_size not documented
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52931
Bug #: 52931
Summary: std::hash shouldn't be defined for unknown types
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
--- Comment #28 from Marc Glisse marc.glisse at normalesup dot org 2012-04-11
16:48:47 UTC ---
A difficulty I hadn't foreseen is that the code that canonicalizes permutations
(and in particular checks if one of the operands is unused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
--- Comment #29 from Marc Glisse marc.glisse at normalesup dot org 2012-04-11
20:35:00 UTC ---
Created attachment 27136
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27136
V4DF generic shuffle
A patch (independent from the others
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
--- Comment #27 from Marc Glisse marc.glisse at normalesup dot org 2012-04-09
16:50:47 UTC ---
Notes to self (or other):
- Intel's SDE makes it possible to test without appropriate hardware;
- for V4DF shuffles, there seems to be a very simple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52901
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
--- Comment #25 from Marc Glisse marc.glisse at normalesup dot org 2012-03-31
09:37:51 UTC ---
The test for AVX2 in expand_vec_perm_interleave2 might be too strict. For the
V4DF shuffle 4,0,2,6, removing that check lets the compiler generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
Attachment #26979|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52654
--- Comment #7 from Marc Glisse marc.glisse at normalesup dot org 2012-03-31
17:18:37 UTC ---
(In reply to comment #6)
Also, what about this:
-3_w;
What about it? IIUC, it is just -(3_w), I don't think it requires a particular
treatment.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
--- Comment #24 from Marc Glisse marc.glisse at normalesup dot org 2012-03-29
14:19:11 UTC ---
(In reply to comment #23)
(In reply to comment #18)
+ if (!d-testing_p)
+dsecond.target = gen_reg_rtx (dsecond.vmode);
+ dfirst.op1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
--- Comment #21 from Marc Glisse marc.glisse at normalesup dot org 2012-03-27
18:21:39 UTC ---
(In reply to comment #20)
I don't like much the calls to ix86_expand_vec_perm_const_1, if you are
looking
for exactly two insn permutations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
--- Comment #22 from Marc Glisse marc.glisse at normalesup dot org 2012-03-27
20:57:16 UTC ---
(In reply to comment #20)
Lastly for each routine it is desirable to think whether it might be useful
for
other vector modes (likely 32-byte only
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
Attachment #26938|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52521
--- Comment #12 from Marc Glisse marc.glisse at normalesup dot org 2012-03-22
09:42:43 UTC ---
(In reply to comment #11)
GCC 4.7.0 is being released, adjusting target milestone.
I think it is already fixed, actually.
(not closing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52654
Bug #: 52654
Summary: [C++11] Warn on overflow in user-defined literals
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
--- Comment #15 from Marc Glisse marc.glisse at normalesup dot org 2012-03-20
19:00:32 UTC ---
If I am not mistaken, the V8SF shuffle 22022246 is doable by a vperm2f128 that
takes 01234567 to 01230123, followed by a vshufps (mask 138 maybe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
--- Comment #16 from Marc Glisse marc.glisse at normalesup dot org 2012-03-20
19:05:22 UTC ---
(In reply to comment #15)
If I am not mistaken, the V8SF shuffle 22022246 is doable by a vperm2f128 that
takes 01234567 to 01230123, followed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
Attachment #26912|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
--- Comment #9 from Marc Glisse marc.glisse at normalesup dot org 2012-03-19
18:29:50 UTC ---
(In reply to comment #8)
I'm not very keen on having too many different routines, the more generic they
are, the better.
Agreed, that was one of my
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
Attachment #26909|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
--- Comment #6 from Marc Glisse marc.glisse at normalesup dot org 2012-03-18
18:58:44 UTC ---
Created attachment 26912
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26912
generic shuffle of a single v8sf
An additional function (I should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
--- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2012-03-17
19:20:36 UTC ---
Created attachment 26908
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26908
copy-paste patch for 0213 and 1302
This seems to handle 0213 and 1302
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
--- Comment #3 from Marc Glisse marc.glisse at normalesup dot org 2012-03-17
19:55:18 UTC ---
Uh. I feel silly, but it looks like vshufpd could replace vpermilpd+vblendpd in
many cases, including the original 1230 from PR52568...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
Attachment #26908|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52521
--- Comment #7 from Marc Glisse marc.glisse at normalesup dot org 2012-03-16
19:39:14 UTC ---
(In reply to comment #6)
constexpr long double operator _degrees(long double d)
{
return d * 0.0175;
}
int main()
{
long double pi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
Bug #: 52607
Summary: v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
--- Comment #1 from Marc Glisse marc.glisse at normalesup dot org 2012-03-17
01:05:57 UTC ---
Note that {1,2,0,3} seems harder, I need one extra vpermilpd. Actually, it
looks like every v4df shuffle can be realized as a vblendpd of a vpermilpd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52572
--- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2012-03-13
08:16:58 UTC ---
(In reply to comment #1)
Have you actually tried that?
Ah, no, sorry, I only have occasional access to such a machine to benchmark the
code. From
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52572
--- Comment #3 from Marc Glisse marc.glisse at normalesup dot org 2012-03-13
17:57:58 UTC ---
Or for this variant:
__m256d f(__m256d *y){
__m256d x=*y;
x[0]=0; // or x[3]
return x;
}
it looks like vmaskmovpd could replace:
vmovapd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52567
--- Comment #1 from Marc Glisse marc.glisse at normalesup dot org 2012-03-12
18:10:16 UTC ---
131 overflows and is thus not a constant. Try maybe 1LL31 ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52568
Bug #: 52568
Summary: suboptimal __builtin_shuffle on cycles with AVX
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52572
Bug #: 52572
Summary: suboptimal assignment to avx element
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52521
Bug #: 52521
Summary: [C++11] user defined literals and order of declaration
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785
--- Comment #12 from Marc Glisse marc.glisse at normalesup dot org 2012-02-28
15:47:04 UTC ---
(In reply to comment #10)
If the libstdc++ people are going to do something for 4.7, it really needs
to be done very soon.
The question is: what do
1 - 100 of 308 matches
Mail list logo
