differently from regular function calls.
--
Marc Glisse
it.
Bootstrap+testsuite on x86_64-linux-gnu.
2014-06-21 Marc Glisse marc.gli...@inria.fr
PR target/61503
* config/i386/i386.md (x86_64_shrd, x86_shrd): Replace ashiftrt
with lshiftrt.
--
Marc GlisseIndex: gcc/config/i386/i386.md
On Sat, 21 Jun 2014, Uros Bizjak wrote:
On Fri, Jun 20, 2014 at 10:42 PM, Marc Glisse marc.gli...@inria.fr wrote:
as reported in PR 61503, there seems to be a typo in the shrd pattern. I
think it is quite unlikely to cause any problem, because the pattern is 1
instruction too long for combine
))
That seems complicated. You just need to call emit_support_tinfo_1 on
each of the types (see how fundamentals is used at the end of the
function), no need to put everything in the array.
--
Marc Glisse
, as in the
original testcase in the PR, we won't notice that those are the original
vectors. Still, better than nothing...
(we output a vzeroupper for the testcase, that seems unnecessary)
Bootstrap+testsuite on x86_64-linux-gnu.
2014-06-22 Marc Glisse marc.gli...@inria.fr
PR target/44551
Hello,
a trivial patch to remove a duplicated option, you can see the second one
4 lines below in the patch. (the mixed use of single or double spaces in
this list is strange)
This was included in the bootstrap of another patch.
2014-06-23 Marc Glisse marc.gli...@inria.fr
* doc
-unknown-linux-gnu.
(by the way, contrib/compare_tests is confused when I use all languages,
it prints comm: file 1 is not in sorted order and tons of spurious
differences)
2014-06-23 Marc Glisse marc.gli...@inria.fr
PR c++/60517
gcc/c/
* c-typeck.c (c_finish_return): Return 0
))
+ (minus @0 (plus:c @0 @1))
(negate @0))
seems pointless
Why? a-(a+b) and a-(b+a) are both wanted and don't appear elsewhere in the
file, no? Should simplify to (negate @1) though.
--
Marc Glisse
commit
it tomorrow if there aren't any comments on the pass placement.
2014-06-24 Marc Glisse marc.gli...@inria.fr
PR tree-optimization/57742
gcc/
* tree-ssa-strlen.c (get_string_length): Ignore malloc.
(handle_builtin_malloc, handle_builtin_memset): New functions
On Mon, 23 Jun 2014, Richard Biener wrote:
On June 23, 2014 5:51:30 PM CEST, Marc Glisse marc.gli...@inria.fr wrote:
On Mon, 23 Jun 2014, Jakub Jelinek wrote:
Ok for trunk, sorry for the delay.
Thanks. Richard has moved the passes a bit since then, but I still have
exactly one spot where
benchmarks, and their authors would be disappointed if the
compiler didn't mess it up regularly in new and entertaining ways ;-)
--
Marc Glisse
the compiler that we are doing memset(malloc(n),0,n).
--
Marc Glisse
thread is created. I hope that not too many libraries
use threads internally in a way that would break this.
--
Marc Glisse
Hello,
in my calloc patch, I forgot to update the datastructure when replacing
malloc with calloc.
Bootstrap+testsuite on x86_64-linux-gnu.
2014-06-25 Marc Glisse marc.gli...@inria.fr
PR tree-optimization/57742
gcc/
* tree-ssa-strlen.c (handle_builtin_memset): Update
= lshr_optab;
+ opr = optab_for_tree_code (RSHIFT_EXPR, type, optab_scalar);
Looks like there are some typos in there, you are assigning to oprv twice.
--
Marc Glisse
register_builtin_type was called or on float modes that
don't correspond to float/double/long double (depends on how much they
break ARM).
Your choice ;-)
Well, Jason's.
--
Marc Glisse
a good thing), but I hope not too much more...
Thanks for working on this,
--
Marc Glisse
, Marc Glisse wrote:
Ping
On Mon, 28 Apr 2014, Marc Glisse wrote:
Ping
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00590.html
(note that ARM seems to be doing the same thing for their neon intrinsics,
see Ramana's patch series posted today)
On Fri, 11 Apr 2014, Marc Glisse wrote:
Hello
. I think the patch is a good thing (also for
future-proofing) even if one or two extra symbols remain because they are
hard to remove. Also, none of this is urgent, it can all wait several
weeks if you are busy.
--
Marc Glisse
(all,obj-c++,ada,go) on x86_64-unknown-linux-gnu.
2014-06-30 Marc Glisse marc.gli...@inria.fr
PR tree-optimization/60770
gcc/
* tree-ssa.c (execute_update_addresses_taken): Don't drop clobbers.
* tree-into-ssa.c (maybe_register_def): Replace clobbers with a
default
On Sat, 28 Jun 2014, Ulrich Drepper wrote:
On Sat, Jun 28, 2014 at 6:42 AM, Marc Glisse marc.gli...@inria.fr wrote:
Ping,
nobody has an opinion on this? Or some explanation why I am mistaken to
believe that #pragma target makes it safer now?
It would enable a number of optimizations, like
( https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01692.html )
On Sun, 22 Jun 2014, Marc Glisse wrote:
Hello,
I followed the advice in this discussion:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html
and here is a new patch. I made an effort to isolate a path in at least one
subcase
than I am proposing.
--
Marc Glisse
we reach uninit and warn, or the
variable appears in a PHI and CCP optimizes.
Bootstrap+testsuite (all,obj-c++,ada,go) on x86_64-linux-gnu.
2014-07-01 Marc Glisse marc.gli...@inria.fr
PR c++/60517
PR tree-optimization/60770
gcc/
* tree-sra.c (clobber_subtree): New
On Mon, 30 Jun 2014, Jeff Law wrote:
On 06/29/14 03:22, Marc Glisse wrote:
After looking at PR 61597, I updated the 2 conditions to:
+ if ((TREE_CODE (valbase) == VAR_DECL
+!is_global_var (valbase))
+ || TREE_CODE (valbase) == PARM_DECL)
a PARM_DECL
a as an rvalue, so it uses that constructor for Aint, and that uses a
private member of a different specialization of A, which is illegal.
--
Marc Glisse
that conversion from rvalues of different types is supported.
No X in the friend declaration though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12429
--
Marc Glisse
On Wed, 2 Jul 2014, Alan Modra wrote:
On Mon, Jun 30, 2014 at 11:37:50PM +0200, Marc Glisse wrote:
On Mon, 30 Jun 2014, Jeff Law wrote:
On 06/29/14 03:22, Marc Glisse wrote:
After looking at PR 61597, I updated the 2 conditions to:
+ if ((TREE_CODE (valbase) == VAR_DECL
On Thu, 3 Jul 2014, Kirill Yukhin wrote:
Hello Marc,
On 28 Jun 12:42, Marc Glisse wrote:
It would enable a number of optimizations, like constant
propagation, FMA contraction, etc. It would also allow us to remove
several builtins.
This should be main motivation for replacing built-ins
On Mon, 30 Jun 2014, Jeff Law wrote:
On 06/28/14 16:33, Marc Glisse wrote:
In an earlier version of the patch, I was using
get_or_create_ssa_default_def (cfun, sym);
(I was reusing the same variable). This passed bootstrap+testsuite on
all languages except for ada. Indeed, the compiler wanted
On Sun, 6 Jul 2014, pins...@gmail.com wrote:
The below patch won't work for parameters.
Er, that's why I am testing: TREE_CODE (var) == VAR_DECL
(and the patch passed the testsuite with all languages)
Could you be more specific about what won't work?
--
Marc Glisse
On Mon, 7 Jul 2014, Richard Biener wrote:
On Mon, Jun 30, 2014 at 1:38 AM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
with this patch on top of
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02315.html
we finally warn for the testcase of PR 60517.
The new function is copied from
and replacing them with undef
SSA_NAMEs doesn't seem to fit well with how SRA works. It would certainly
be possible, but would require quite a bit of new code. Also, the
domination relation between the clobber and the reads is not always
obvious and may require some PHIs in between.
--
Marc Glisse
On Mon, 7 Jul 2014, Jeff Law wrote:
On 07/06/14 08:23, Marc Glisse wrote:
What is the lifetime of an SSA_NAME with a default definition? The way
we handle it now, we start from the uses and go back to all blocks that
can reach one of the uses, since there is no defining statement where we
be away next week, but I'll re-read all the replies carefully when I
come back.
--
Marc Glisse
On Wed, 16 Jul 2014, Jeff Law wrote:
On 06/22/14 12:20, Marc Glisse wrote:
Hello,
I followed the advice in this discussion:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html
and here is a new patch. I made an effort to isolate a path in at least
one subcase so it doesn't look too
if all values of the normal distribution
happen to be 0?
* should the implementation be specialized for small dimensions to avoid
the normal distributions and instead generate points in a square/cube
until they fall in the disk/ball?
--
Marc Glisse
Hello,
any comment on this patch?
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00769.html
On Tue, 10 Jun 2014, Marc Glisse wrote:
On Tue, 19 Mar 2013, Richard Henderson wrote:
I'm not fond of this, primarily because I believe the pattern should
not exist at all.
One year later, new try
On Tue, 8 Jul 2014, Kirill Yukhin wrote:
Hello Marc.
On 04 Jul 21:11, Marc Glisse wrote:
On Thu, 3 Jul 2014, Kirill Yukhin wrote:
like combining 2 shuffles unless the result is the identity. And
expanding shuffles that can be done in a single instruction works
well.
But I am happy not doing
for the C++ testcase because SRA sets
nowarning_flag (it doesn't if I create a new variable), but I guess we can
see about changing that next.
--
Marc Glisse
hack)
--
Marc Glisse
On Sun, 27 Jul 2014, Richard Sandiford wrote:
Marc Glisse marc.gli...@inria.fr writes:
Hello,
I followed the advice in this discussion:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html
and here is a new patch. I made an effort to isolate a path in at least
one subcase so it doesn't
On Sun, 27 Jul 2014, Andreas Schwab wrote:
Marc Glisse marc.gli...@inria.fr writes:
On Sun, 27 Jul 2014, Richard Sandiford wrote:
Marc Glisse marc.gli...@inria.fr writes:
+ if (always_executed)
+ msg = function returns address of local variable
On Sun, 27 Jul 2014, Richard Sandiford wrote:
Marc Glisse marc.gli...@inria.fr writes:
Hello,
I followed the advice in this discussion:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html
and here is a new patch. I made an effort to isolate a path in at least
one subcase so it doesn't
On Tue, 29 Jul 2014, David Malcolm wrote:
On Tue, 2014-07-29 at 19:36 +0200, Marc Glisse wrote:
On Sun, 27 Jul 2014, Richard Sandiford wrote:
Marc Glisse marc.gli...@inria.fr writes:
Hello,
I followed the advice in this discussion:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html
On Mon, 10 Nov 2014, Richard Biener wrote:
No extra includes required?
utility is already included in wide-int.h and rtl.h, should probably
move those.
--
Marc Glisse
, I don't believe it will be portable everywhere.
Can't you use
INTTYPE_MAXIMUM (int64_t) instead of INT64_MAX? We already use that
in GCC...
We could also start using the standard C++ mechanism (numeric_limits).
(nothing wrong with INTTYPE_MAXIMUM, just an alternative)
--
Marc Glisse
On Tue, 11 Nov 2014, Kirill Yukhin wrote:
Hello Marc, Uroš,
On 10 Nov 21:33, Uros Bizjak wrote:
On Sun, Nov 9, 2014 at 5:26 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
and == for integer vectors of size 128. I was surprised not to find
_mm_cmplt_epi64 anywhere. Note that I can do
need to have
an if here. See the pedwarns at the beginning of finish_struct.
Do keywords like struct/union really require translation?
--
Marc Glisse
)
+++ ChangeLog.x86-intrinsics-ext(working copy)
@@ -1,10 +1,17 @@
+2014-11-11 Marc Glisse marc.gli...@inria.fr
+
+ * config/i386/avx2intrin.h (_mm256_cmpeq_epi8, _mm256_cmpeq_epi16,
+ _mm256_cmpeq_epi32, _mm256_cmpeq_epi64, _mm256_cmpgt_epi8,
+ _mm256_cmpgt_epi16
Hello,
here is the combined patch+ChangeLog. I'll run a last regtest just before
committing. Ok for trunk?
2014-11-12 Marc Glisse marc.gli...@inria.fr
gcc/
* config/i386/xmmintrin.h (_mm_add_ps, _mm_sub_ps, _mm_mul_ps,
_mm_div_ps, _mm_store_ss, _mm_cvtss_f32): Use vector
On Tue, 11 Nov 2014, Jonathan Wakely wrote:
+ templatetypename _Iterator, typename = __void_t
Is there a particular reason not to write void directly?
--
Marc Glisse
On Wed, 12 Nov 2014, Jonathan Wakely wrote:
On 12/11/14 07:13 +0100, Marc Glisse wrote:
On Tue, 11 Nov 2014, Jonathan Wakely wrote:
+ templatetypename _Iterator, typename = __void_t
Is there a particular reason not to write void directly?
I like this form as a hint
Hello,
this patch breaks gcc.dg/torture/pr50396.c, and I believe this is a
symptom of a bigger issue: the HONOR_NANS interface is bad (or at least
the way we are using it is bad). To know if a type honors NaN, we first
get its TYPE_MODE and then call HONOR_NANS on that. But for vectors that
On Sun, 16 Nov 2014, Richard Biener wrote:
I think the element_mode is the way to go.
The following passed bootstrap+testsuite.
2014-11-16 Marc Glisse marc.gli...@inria.fr
* tree.c (element_mode, integer_truep): New functions.
* tree.h (element_mode, integer_truep
On Sun, 16 Nov 2014, Marc Glisse wrote:
On Sun, 16 Nov 2014, Richard Biener wrote:
I think the element_mode is the way to go.
The following passed bootstrap+testsuite.
2014-11-16 Marc Glisse marc.gli...@inria.fr
* tree.c (element_mode, integer_truep): New functions
On Mon, 17 Nov 2014, Richard Biener wrote:
On Sun, Nov 16, 2014 at 6:53 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Sun, 16 Nov 2014, Richard Biener wrote:
I think the element_mode is the way to go.
The following passed bootstrap+testsuite.
2014-11-16 Marc Glisse marc.gli
On Tue, 18 Nov 2014, James Greenhalgh wrote:
On Wed, Nov 05, 2014 at 11:31:24PM +, James Greenhalgh wrote:
On Wed, Nov 05, 2014 at 09:50:52PM +, Marc Glisse wrote:
Thanks. Do you know if anyone is planning to port this patch to the arm
target (which IIRC has the same issue
On Fri, 22 Aug 2014, Marc Glisse wrote:
On Fri, 22 Aug 2014, Jason Merrill wrote:
On 08/22/2014 03:24 PM, Marc Glisse wrote:
Note that there is a patch waiting for a review that makes us accept !v
for vector v:
Ah, indeed. I still think we might as well treat vectors the same as other
as suggested in PR 61347?
--
Marc Glisse
to
change:
- __detail::_List_node_base _M_node;
- size_t _M_size;
+ _List_nodesize_t _M_node;
and store the size in _M_node._M_data. Since I will have to touch it
anyway, don't feel forced to move it to _M_impl.
--
Marc Glisse
On Thu, 2 Oct 2014, Jason Merrill wrote:
OK.
Thanks. While committing, I noticed that I restricted ! to integer
vectors, whereas it seems to work just fine with scalar floats, so it
would make sense to extend it to float vectors. Tested on
x86_64-linux-gnu.
2014-10-04 Marc Glisse
is
implicit in C++11 but not C++14.
2014-10-09 Marc Glisse marc.gli...@inria.fr
gcc/cp/
* decl.c (grokdeclarator): constexpr only implies const in C++11.
gcc/testsuite/
* g++.dg/cpp0x/constexpr-52892-1.C: Error on missing const in C++14.
* g++.dg/cpp0x/constexpr-array-ptr7
for integers:
(__m128d)((__v2df)__A + (__v2df)__B)
--
Marc Glisse
On Thu, 9 Oct 2014, Uros Bizjak wrote:
On Thu, Oct 9, 2014 at 12:33 PM, Marc Glisse marc.gli...@inria.fr wrote:
Ping https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01812.html
(another part of the discussion is around
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02288.html )
Most people who
On Thu, 9 Oct 2014, Olivier Hainque wrote:
On Oct 9, 2014, at 12:33 PM, Marc Glisse wrote:
If this is accepted, I will gladly prepare patches removing the unused builtins
and extending this to a few more operations (integer vectors in particular). If
this is not the direction we want to go
for the conversion. Maybe even ada
can be tested there to not regress with the compatibility stuff.
No problem. We can also wait until next stage1 if you believe the release
of gcc-5 is too close.
--
Marc Glisse
be
fixed. This triggered one of the issues listed in PR 63345 (casting to a
node* even for the sentinel), which I am fixing here.
Bootstrap+testsuite on x86_64-linux-gnu.
2014-10-13 Marc Glisse marc.gli...@inria.fr
PR libstdc++/61347
PR libstdc++/63345
* include/bits
to fma to 'f')
If I omit the avx512fintrin.h part, I think it is very unlikely this can
conflict with Kirill's work in any way (but I can still wait / use a
branch).
Bootstrap+testsuite on x86_64-linux-gnu.
2014-10-13 Marc Glisse marc.gli...@inria.fr
gcc/
* config/i386/xmmintrin.h
On Mon, 13 Oct 2014, Kito Cheng wrote:
- -1 if it is not a cost classe. */
+ -1 if it is not a cost classes. */
a cost class, no plural here.
--
Marc Glisse
Ping https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00361.html
(sorry that my message looked like I had committed as obvious)
On Sat, 4 Oct 2014, Marc Glisse wrote:
On Thu, 2 Oct 2014, Jason Merrill wrote:
OK.
Thanks. While committing, I noticed that I restricted ! to integer vectors
__glibcxx_max_b (TYPE, BITSIZE);; } \
Maybe shorten the double ;; as well?
--
Marc Glisse
On Sun, 7 Sep 2014, Marc Glisse wrote:
On Sun, 27 Jul 2014, Marc Glisse wrote:
On Thu, 10 Jul 2014, Richard Biener wrote:
--- gcc/tree-into-ssa.c (revision 212109)
+++ gcc/tree-into-ssa.c (working copy)
@@ -1831,26 +1831,38 @@ maybe_register_def (def_operand_p def_p,
{
tree def
a
comment in tree-nrv.c), that would be good.
2014-10-16 Marc Glisse marc.gli...@inria.fr
* tree-nrv.c (pass_nrv::execute): Don't disable when address is taken.
--
Marc GlisseIndex: gcc/tree-nrv.c
===
--- gcc/tree-nrv.c
runs quite late
but we do preserve points-to information to RTL (and RTL expansion
handles stack slot sharing fine with points-to sets - but we'd need to
handle NRV the same here).
Ah, ok. It would be great to paste some of this in tree-nrv.c, unless you
think it will be too much.
--
Marc Glisse
On Thu, 16 Oct 2014, Richard Biener wrote:
On Wed, Oct 15, 2014 at 6:08 PM, Jeff Law l...@redhat.com wrote:
On 10/15/14 08:35, Marc Glisse wrote:
Would that extra pass be acceptable?
Ugh, rather not. We have too many passes ;)
I expected you would say that...
Otherwise, what do you
Hello,
this trivial fix was pre-approved by Richard, I regtested and committed
it.
2014-10-17 Marc Glisse marc.gli...@inria.fr
* tree-into-ssa.c (is_old_name): Replace new with old.
--- tree-into-ssa.c (revision 216366)
+++ tree-into-ssa.c (working copy)
@@ -572,23 +572,23
on this. It may be a different
issue from yours with frcz, but I kept the impression from then that
builtins were still the way to go for anything non-trivial.
--
Marc Glisse
On Thu, 16 Oct 2014, Jeff Law wrote:
BTW, I dislike having multiple DCE implementations...
Similarly. The proposal above was just to determine if we should schedule
DCE or not.
Thinking about it some more, I don't think we should need any kind of DCE
here. The rewriting in update_ssa
On Mon, 6 Oct 2014, François Dumont wrote:
* testsuite/25_algorithms/push_heap/complexity.cc: New.
This test is randomly failing in about 1% to 2% of cases.
--
Marc Glisse
On Fri, 17 Oct 2014, Marc Glisse wrote:
Thanks. I am testing the updated patch tonight and I'll commit. I am planning
on making a branch: ^/branches/x86-intrinsics-ext if noone complains about
the name.
Committed patch attached.
--
Marc GlisseIndex: gcc/testsuite/gcc.target/i386
for this one) should be:
- same thing with 256 and 512 bit integer vectors
- | ^ (integer only)
Maybe (or it can wait until the next release):
- == abs min max (integer only)
2014-10-20 Marc Glisse marc.gli...@inria.fr
* config/i386/emmintrin.h (__v2du, __v4su, __v8hu, __v16qu): New
something or not? ;-)
--
Marc Glisse
On Thu, 10 Jul 2014, Richard Biener wrote:
On Sun, Jun 29, 2014 at 12:33 AM, Marc Glisse marc.gli...@inria.fr wrote:
we currently drop clobbers on variables whose address is not taken anymore.
However, rewrite_stmt has code to replace them with an SSA_NAME with a
default definition
function, or a special syntax.
--
Marc Glisse
like long long (HOST_WIDEST_INT?)
make more sense than unsigned?
--
Marc Glisse
in b-a. Richard+GSoC will supposedly soon provide a
function that does that.
--
Marc Glisse
provably instead of probably in the first two?
--
Marc Glisse
fix PR 60517, for that I was thinking of checking
for memory reads if the first stop of walk_aliased_vdefs is a clobber
(could also check __builtin_free), though I don't know in which pass to do
that yet.
2014-04-05 Marc Glisse marc.gli...@inria.fr
PR c++/60517
gcc/c/
* c
(gimple_location (stmt), OPT_Wreturn_local_addr,
+ function returns address of local variable))
That's a front-end option, I should either move it to gcc/common.opt or
use a different option.
--
Marc Glisse
On Mon, 7 Apr 2014, Jeff Law wrote:
On 04/05/14 07:52, Marc Glisse wrote:
Hello,
we have front-end warnings about returning the address of a local
variable. However, quite often in C++, people don't directly return the
address of a temporary, it goes through a few functions which hide
the return value
in those cases, we can warn, but maybe we don't want to introduce a trap?
Replacing the address with a null pointer seemed like a compromise, it
will trap when you try to read it, but not if you ignore it. But if you
think we can trap, ok.
--
Marc Glisse
should be counted from two, not one, when giving
values for string-index and first-to-check.
It would be strange to count arguments differently for different
attributes.
--
Marc Glisse
date)
--
Marc Glisse
On Wed, 5 Mar 2014, Jonathan Wakely wrote:
On 5 March 2014 19:36, Marc Glisse wrote:
Hello,
this issue got delayed in LWG, apparently because of a failed improvement
to the wording along the way (happens, that's ok), but there seems to be a
consensus on the resolution and I don't really see
waiting to see if
this patch is accepted before doing more.
Bootstrap+testsuite on x86_64-linux-gnu.
2014-04-11 Marc Glisse marc.gli...@inria.fr
* config/i386/xmmintrin.h (_mm_add_ps, _mm_sub_ps, _mm_mul_ps,
_mm_div_ps, _mm_store_ss, _mm_cvtss_f32): Use vector extensions
won't do it again in the future :-)
--
Marc Glisse
*
+ V typeinfo for __float128*
+ V typeinfo name for __float128
+ V typeinfo name for __float128 const*
+ V typeinfo name for __float128*
Bootstrap and testsuite on x86_64-linux-gnu (a bit of noise in
tsan/tls_race.c).
2014-04-13 Marc
+testsuite on x86_64-linux-gnu.
2014-04-13 Marc Glisse marc.gli...@inria.fr
PR preprocessor/56540
* config/i386/i386-c.c (ix86_target_macros): Define
__SIZEOF_FLOAT80__ and __SIZEOF_FLOAT128__.
--
Marc GlisseIndex: gcc/config/i386/i386-c.c
On Mon, 3 Mar 2014, Richard Biener wrote:
On Sat, Mar 1, 2014 at 3:33 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
again, a stage 1 patch that I will ping then, but early comments are
welcome.
PR 59100 was asking to transform n?rotate(x,n):x to rotate(x,n) (because it
can be hard
1 - 100 of 1572 matches
Mail list logo
