On Thu, May 01, 2014 at 10:54:18PM +, Joseph S. Myers wrote:
> I think the comment on this function should be updated to explain the
> interface contract when an incomplete (or function) type is passed (i.e.
> return size_one_node, caller is responsible for any diagnostics).
Done.
> The te
Ping again.
Kyrill
On 24/04/14 09:20, Kyrill Tkachov wrote:
Hi all,
Pinging this:
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01276.html
Thanks,
Kyrill
On Fri, 2014-05-02 at 00:45 +0200, Samuel Thibault wrote:
> Hello,
>
> Svante Signell, le Thu 24 Apr 2014 10:39:10 +0200, a écrit :
> > - Without split stack enabled around 70 libgo tests pass and 50 fails,
> > most of them with a segfault.
> > - Enabling split stack and using the libc Samuel buil
When I submitted -fsanitize=float-divide-by-zero stuff, I forgot
to document the option in the table of ubsan options.
Ok?
2014-05-02 Marek Polacek
* doc/invoke.texi: Describe -fsanitize=float-divide-by-zero.
diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi
index 0eba1e0..3fe9d5f 1
On Fri, May 02, 2014 at 10:11:05AM +0200, Marek Polacek wrote:
> When I submitted -fsanitize=float-divide-by-zero stuff, I forgot
> to document the option in the table of ubsan options.
>
> Ok?
>
> 2014-05-02 Marek Polacek
>
> * doc/invoke.texi: Describe -fsanitize=float-divide-by-zero.
A recent fix for the LEON3 support added a new option -muser-mode to
select the ASI of the CASA instruction used for atomic operations. Use
the user-mode CASA instruction since this works also in supervisor-mode.
This patch should be applied to GCC 4.8, 4,9 and mainline. I do not
have write acce
Ping.
On 2014-04-18 12:11, Sebastian Huber wrote:
From: Sebastian Huber
The command line to build a GCC for RTEMS contained virtually always a
'--enable-threads'. This patch helps to avoid this extra configuration
command line parameter and makes the GCC build a bit more user friendly
for RTE
Hi,
Unlike the mid-end's concept of an ABS_EXPR, which treats overflow as
undefined/impossible, the neon intrinsics vabs intrinsics should behave as
the hardware. That is to say, the pseudo-code sequence:
a = vabs_s8 (vdup_n_s8 (-128));
assert (a >= 0);
does not hold. As in hardware
abs
Svante Signell, le Fri 02 May 2014 10:18:12 +0200, a écrit :
> Thread 4 (Thread 1205.4):
> #0 0x019977b7 in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:132
> err =
> err =
> user_option = 3
> user_timeout = 48
> m = 0x532370
> msgh_bits = 0
>
On Fri, May 2, 2014 at 1:48 AM, James Greenhalgh
wrote:
>
> Hi,
>
> Unlike the mid-end's concept of an ABS_EXPR, which treats overflow as
> undefined/impossible, the neon intrinsics vabs intrinsics should behave as
> the hardware. That is to say, the pseudo-code sequence:
Only for signed integer
On 02/05/14 10:15, Joseph S. Myers wrote:
> It doesn't seem a good idea to me for a host-side GCC file to use the FE_*
> names for the target's FE_* values; you'd run into problems if that file
> ever ends up including the host's , directly or indirectly, on any
> host. The same comment applies
>
> +2014-04-29 Kugan Vivekanandarajah
> +
> + * config/aarch64/aarch64.c (TARGET_ATOMIC_ASSIGN_EXPAND_FENV): New
> + define.
> + * config/aarch64/aarch64-protos.h (aarch64_atomic_assign_expand_fenv):
> + New function declaration.
> + * config/aarch64/aarch64-builtins.c (aar
On April 30, 2014 11:26:35 PM CEST, Jeff Law wrote:
>On 04/23/14 08:32, Richard Biener wrote:
>
>>> Also I see you introduce a const_FOO class with every FOO one.
>>> I wonder whether, now that we have C++, can address
>const-correctness
>>> in a less awkward way than with a typedef. Can you try
On Fri, May 02, 2014 at 10:00:15AM +0100, Andrew Pinski wrote:
> On Fri, May 2, 2014 at 1:48 AM, James Greenhalgh
> wrote:
> >
> > Hi,
> >
> > Unlike the mid-end's concept of an ABS_EXPR, which treats overflow as
> > undefined/impossible, the neon intrinsics vabs intrinsics should behave as
> > th
> On May 2, 2014, at 2:21 AM, James Greenhalgh wrote:
>
>> On Fri, May 02, 2014 at 10:00:15AM +0100, Andrew Pinski wrote:
>> On Fri, May 2, 2014 at 1:48 AM, James Greenhalgh
>> wrote:
>>>
>>> Hi,
>>>
>>> Unlike the mid-end's concept of an ABS_EXPR, which treats overflow as
>>> undefined/impo
On Thu, May 01, 2014 at 11:20:25PM +, Joseph S. Myers wrote:
> On Wed, 23 Apr 2014, Marek Polacek wrote:
>
> > diff --git gcc/testsuite/c-c++-common/attributes-1.c
> > gcc/testsuite/c-c++-common/attributes-1.c
> > index af4dd12..8458e47 100644
> > --- gcc/testsuite/c-c++-common/attributes-1.c
On 24/03/14 17:21, Kyrill Tkachov wrote:
> Hi all,
>
> I noticed that we don't handle simple reg-to-reg arithmetic operations in the
> arm rtx cost functions. We should be adding the cost of alu.arith to the
> costs
> of the operands. This patch does that. Since we don't have any cost tables
>
Svante Signell, le Fri 02 May 2014 10:03:23 +0200, a écrit :
> On Fri, 2014-05-02 at 00:45 +0200, Samuel Thibault wrote:
> > Hello,
> >
> > Svante Signell, le Thu 24 Apr 2014 10:39:10 +0200, a écrit :
> > > - Without split stack enabled around 70 libgo tests pass and 50 fails,
> > > most of them w
Justus Winter, le Sat 26 Apr 2014 08:53:08 +0200, a écrit :
> task130(pid1182)->vm_map (0 49880 0 1133<--160(pid1182) 0 1 5 7 1) = 0
> 2453504
>
> We map that somewhere.
>
> task130(pid1182)->mach_port_deallocate (pn{ 25}) = 0
>
> Deallocate the port. Again, for some strange reason 133 ==
Svante Signell, le Fri 02 May 2014 10:18:12 +0200, a écrit :
> task130(pid1182)->vm_allocate (33562796 8364 0) = 0x3 ((os/kern) no space
> available)
> task130(pid1182)->vm_allocate (33571160 8364 0) = 0 33570816
While inspecting this, I realized this is from __pthread_stack_alloc,
the only call
Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
> So we just need to fix guardsize in our libpthread.
(And I'll have a look at it).
Samuel
On 29 April 2014 03:37, Kugan wrote:
>
> On 28/04/14 21:01, Ramana Radhakrishnan wrote:
>> On 04/26/14 11:57, Kugan wrote:
>>> Attached patch implements TARGET_ATOMIC_ASSIGN_EXPAND_FENV for AARCH64.
>>> With this, atomic test-case gcc.dg/atomic/c11-atomic-exec-5.c now PASS.
>>>
>>> This implementa
Hi!
On Tue, Apr 29, 2014 at 06:30:32PM -0400, Michael Meissner wrote:
> This patch adds support for a new type (__float128) on the PowerPC to allow
> people to use the 128-bit IEEE floating point format instead of the
> traditional
> IBM double-double that has been used in the Linux compilers. A
On 2 May 2014 11:06, Marcus Shawcroft wrote:
> Kugan, I've not looked at the respin in detail yet, but it has just
> occurred to me that the sequence used here to set FPCR is
> insufficient. The architecture reference manual requires that any
> write to FPCR must be syncrhronized by a context sy
In cases where the compiler has no alignment info, powerpc64le-linux
gcc generates byte at a time copies for -mstrict-align (which is on
for little-endian power7). That's awful code, a problem shared by
other strict-align targets, see pr50417. However, we also have a case
when -mno-strict-align g
On Fri, May 02, 2014 at 10:29:06AM +0100, pins...@gmail.com wrote:
>
>
> > On May 2, 2014, at 2:21 AM, James Greenhalgh
> > wrote:
> >
> >> On Fri, May 02, 2014 at 10:00:15AM +0100, Andrew Pinski wrote:
> >> On Fri, May 2, 2014 at 1:48 AM, James Greenhalgh
> >> wrote:
> >>>
> >>> Hi,
> >>>
Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
> So we just need to fix guardsize in our libpthread.
It was not so difficult actually.
Svante, could you try this libpthread:
http://people.debian.org/~sthibault/tmp/libpthread.so.0.3
Thanks,
Samuel
Hi,
this relatively old bug report is about an ICE during error recovery and
some time ago I figured out that the below simple tweak to grokfndecl
worked for it (we notice that duplicate_decls returned error_mark_node).
Today, however, while formatting the original testcases, I noticed
someth
On 02/05/14 11:28, James Greenhalgh wrote:
> On Fri, May 02, 2014 at 10:29:06AM +0100, pins...@gmail.com wrote:
>>
>>
>>> On May 2, 2014, at 2:21 AM, James Greenhalgh
>>> wrote:
>>>
On Fri, May 02, 2014 at 10:00:15AM +0100, Andrew Pinski wrote:
On Fri, May 2, 2014 at 1:48 AM, James Gree
On Fri, 2014-05-02 at 12:00 +0200, Samuel Thibault wrote:
> Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
> > So we just need to fix guardsize in our libpthread.
>
> (And I'll have a look at it).
Maybe this can fix the around 40 segfaults (of 50 failures) when split
stack is disab
Svante Signell, le Fri 02 May 2014 12:45:56 +0200, a écrit :
> On Fri, 2014-05-02 at 12:00 +0200, Samuel Thibault wrote:
> > Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
> > > So we just need to fix guardsize in our libpthread.
> >
> > (And I'll have a look at it).
>
> Maybe this
On 05/02/14 10:08, Kugan wrote:
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 347a94a..8bd13f3 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -9107,6 +9107,7 @@ to those machines. Generally these generate calls to
specific machine
instructions, but allow the comp
Dominique Dhumieres wrote:
> This causes several failures with -m32 (see
> http://gcc.gnu.org/ml/gcc-regression/2014-05/msg3.html):
Sorry for the breakage - obviously, I forgot to test with -m32.
> Most of the failures are fixed by replacing 'kind=8' with 'kind=.' or
> 'kind=\[48\]'.
Either
On 02/05/14 20:06, Marcus Shawcroft wrote:
> On 29 April 2014 03:37, Kugan wrote:
>>
>> On 28/04/14 21:01, Ramana Radhakrishnan wrote:
>>> On 04/26/14 11:57, Kugan wrote:
Attached patch implements TARGET_ATOMIC_ASSIGN_EXPAND_FENV for AARCH64.
With this, atomic test-case gcc.dg/atomic/c
On Fri, 2014-05-02 at 12:13 +0200, Jakub Jelinek wrote:
> Hi!
>
> On Tue, Apr 29, 2014 at 06:30:32PM -0400, Michael Meissner wrote:
> > This patch adds support for a new type (__float128) on the PowerPC to allow
> > people to use the 128-bit IEEE floating point format instead of the
> > tradition
Wsizeof-pointer-memaccess option is missing a description in
the c.opt file. This patch adds something in there.
Ok?
2014-05-02 Marek Polacek
* c.opt (Wsizeof-pointer-memaccess): Describe option.
diff --git gcc/c-family/c.opt gcc/c-family/c.opt
index 1bbb81c..7aa9e23 100644
--- gcc/
On Fri, May 02, 2014 at 12:11:02AM +, Joseph S. Myers wrote:
> On Sat, 26 Apr 2014, Marek Polacek wrote:
>
> > What is worth mentioning is that the "(near initialization for X)"
> > message seems next to useless to me now with caret diagnostics (?).
>
> The caret diagnostics point to the init
On 30/04/14 03:52, bin.cheng wrote:
> Hi,
> This patch expands small memset calls into direct memory set instructions by
> introducing "setmemsi" pattern. For processors without NEON support, it
> expands memset using general store instruction. For example, strd for
> 4-bytes aligned addresses.
Whilst I agree with Richard H that it is obvious, my feeling is that the
assertion does no harm, so have committed rev 210005 with Richard E's changes.
--Alan
Richard Henderson wrote:
On 04/29/2014 05:42 AM, Richard Earnshaw wrote:
On 23/04/14 16:20, Alan Lawrence wrote:
This patch is a small
I locally tried adding an assertion to the wide-int version of set_bit
to make sure that the bit number was in range. It triggers for this
code in boehm.c:mark_reference_fields (quoting trunk version):
/* First word in object corresponds to most significant byte of
bitmap.
On Fri, May 2, 2014 at 6:20 AM, Alan Modra wrote:
> In cases where the compiler has no alignment info, powerpc64le-linux
> gcc generates byte at a time copies for -mstrict-align (which is on
> for little-endian power7). That's awful code, a problem shared by
> other strict-align targets, see pr50
...well, still HOST_BITS_PER_WIDE_INT-1 officially, until Richard's patches.
Caught by a boostrap-ubsan on wide-int. Tested on x86_64-linux-gnu and
committed as obvious.
Richard
gcc/
* hwint.h (zext_hwi): Fix signed overflow for prec == 63.
Index: gcc/hwint.h
=
This patch updates the default processor tuning to POWER8 for any
PPC64 Linux target, not only little endian (ELFv2).
Any objection?
Thanks, David
* config/rs6000/linux64.h (PROCESSOR_DEFAULT): Change to PROCESSOR_POWER8.
(PROCESSOR_DEFAULT64): Same.
Index: linux64.h
===
On Tue, 29 Apr 2014, Jakub Jelinek wrote:
> To my surprise, the wording in C99 or C++11 make even floating point
> division by zero undefined behavior, but I think generally at least for IEEE
> floating point semantics it is well defined, thus I think we shouldn't
> include it in -fsanitize=undefi
On Fri, 2014-05-02 at 11:50 -0400, David Edelsohn wrote:
> This patch updates the default processor tuning to POWER8 for any
> PPC64 Linux target, not only little endian (ELFv2).
>
> Any objection?
>
> Thanks, David
>
> * config/rs6000/linux64.h (PROCESSOR_DEFAULT): Change to PROCESSOR_POWER8.
>
On 1 May 2014 17:18, Oleg Endo wrote:
> Jonathan,
>
> now that we're in stage 1 again, I'd like to revive the issue below. Do
> you have any particular plans? How should we proceed?
Hi Oleg, sorry for letting the thread die in January.
We will definitely want to deal with the missing constructo
Update the python pretty printers to understand how _Rb_tree_node is
defined in C++11 mode now.
Tested x86_64-linux, committed to trunk and the 4.9 branch.
commit a498be0a723e8c6b60185d5c15081be4650b2644
Author: Jonathan Wakely
Date: Fri May 2 14:02:51 2014 +0100
PR libstdc++/59476
On 05/02/14 03:09, Richard Biener wrote:
Well, I'd like to see both and one affects the other. Doing the const
correctness thing first seems more natural to me.
Of course both need to wait for 4.9.1.
Well, it looks like David is already on that path to some extent with
the proposed gengtype ch
On May 2, 2014, at 8:36 AM, Richard Sandiford
wrote:
> ...well, still HOST_BITS_PER_WIDE_INT-1 officially, until Richard's patches.
>
> Caught by a boostrap-ubsan on wide-int. Tested on x86_64-linux-gnu and
> committed as obvious.
Thanks.
On Fri, 2014-05-02 at 10:02 -0600, Jeff Law wrote:
> On 05/02/14 03:09, Richard Biener wrote:
> >
> > Well, I'd like to see both and one affects the other. Doing the const
> > correctness thing first seems more natural to me.
> > Of course both need to wait for 4.9.1.
> Well, it looks like David i
David Malcolm writes:
> Currently, gengtype does not support template arguments that are
> explicitly pointers, such as:
> static GTY(()) vec test_gimple; giving this
> error:
> ../../src/gcc/gimple-expr.c:902: parse error: expected a string constant or
> ',', have '*' instead
> requiring th
On Tue, 29 Apr 2014, Marek Polacek wrote:
> It's correct to warn about returning an address of a local label,
> but it's clumsy to say it's "local variable. We can easily distinguish
> between a label and a variable.
>
> Regtested/bootstrapped on x86_64-linux, ok for trunk?
You always need to h
On Fri, 2014-05-02 at 17:43 +0100, Richard Sandiford wrote:
> David Malcolm writes:
> > Currently, gengtype does not support template arguments that are
> > explicitly pointers, such as:
> > static GTY(()) vec test_gimple; giving this
> > error:
> > ../../src/gcc/gimple-expr.c:902: parse error
On Tue, 29 Apr 2014, Michael Meissner wrote:
> * soft-fp/quad.h (TFmode): If TFmode is defined, don't use the
> normal TF mode definition.
That does of course need to go to glibc first (and I think it would be
best to do something consistent for all the floating-point formats in
sof
On Fri, May 02, 2014 at 05:01:18PM +, Joseph S. Myers wrote:
> On Tue, 29 Apr 2014, Marek Polacek wrote:
>
> > It's correct to warn about returning an address of a local label,
> > but it's clumsy to say it's "local variable. We can easily distinguish
> > between a label and a variable.
> >
Two MIPS specific tests started failing a few days ago, this patch fixes
them. The tests are trying to check that a performance optimization is
done and that one constant is derived from another and not simply loaded
as a completely new constant.
Post 4.9 changes have affected which constant get
On Thu, 1 May 2014, DJ Delorie wrote:
> Do we have a routine to do that already?
I don't know.
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, 2 May 2014, John Marino wrote:
> So given the track record (building itself, building base, building
> 21,000 software ports) over a couple of years I think any issues this
> could have caused would have been seen and identified by now.
These issues aren't generally obvious (given that th
On Thu, 1 May 2014, Jeff Law wrote:
> On 05/01/14 17:59, Joseph S. Myers wrote:
> > On Thu, 24 Apr 2014, Tobias Burnus wrote:
> >
> > > Jeff, are you sure that this will not be overridden? I think the
> > > translations
> > > are always synced from http://translationproject.org/team/zh_CN.html ?
On Fri, 2 May 2014, Marek Polacek wrote:
> On Thu, May 01, 2014 at 10:54:18PM +, Joseph S. Myers wrote:
> > I think the comment on this function should be updated to explain the
> > interface contract when an incomplete (or function) type is passed (i.e.
> > return size_one_node, caller is r
Hi!
While starting to work on OpenMP 4.0 Fortran stuff, I've noticed
some issues in C/C++ too.
One problem is that when some variable other than the iteration var
is linear on a combined for simd or parallel for simd loop, we weren't
adding a barrier between read of the initial value and store of
On Fri, 2 May 2014, Marek Polacek wrote:
> Ooops. Is it ok to fix it up with this patch then?
>
> 2014-05-02 Marek Polacek
>
> c/
> * c-typeck.c (c_finish_return): Separate warning_at calls.
> cp/
> * typeck.c (maybe_warn_about_returning_address_of_local): Separate
> warnin
I'd tweak instantiate_decl differently; a deleted function is defined,
so pattern_defined should be true.
Jason
On Fri, 2 May 2014, Marek Polacek wrote:
> Wsizeof-pointer-memaccess option is missing a description in
> the c.opt file. This patch adds something in there.
>
> Ok?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
On 5/2/2014 19:49, Joseph S. Myers wrote:
> On Fri, 2 May 2014, John Marino wrote:
>
>> http://grok.dragonflybsd.org/xref/dragonfly/sys/sys/types.h
>
> That's definitely not correct to include in ; it defines lots of
> types outside the ISO C namespace.
Ok.
So I guess there are two problems.
1)
This was a really dumb regression from me :-(
Tested x86_64-linux, committed to trunk and 4.9 branch.
commit 892be9bd861871e39049c78c75807f5680fffb94
Author: Jonathan Wakely
Date: Fri May 2 18:35:41 2014 +0100
PR libstdc++/61036
* include/bits/shared_ptr_base.h (__shared_ptr::__sha
I'd hoped the days of zero-precision INTEGER_CSTs were behind us after
Richard's patch to remove min amd max values from zero-width bitfields,
but a boostrap-ubsan showed otherwise. One source is in:
null_pointer_node = build_int_cst (build_pointer_type (void_type_node), 0);
if no_target, sinc
This patch adds some assertions against sext (.., 0) and zext (..., 0).
The former is undefined at the sext_hwi level and the latter is disallowed
for consistency with the former.
Also, set_bit (rightly IMO) can't handle bit >= precision. For
precision <= HOST_BITS_PER_WIDE_INT it would invoke un
divmod_internal didn't handle unsigned division in which the inputs
have implicit all-one upper bits. There were two problems:
- wi_unpack should extend implicit 1s to index blocks_needed - 1
(possibly with a zext_hwi on the last block for small_prec)
regardless of signedness
- when calculat
Richard Sandiford writes:
> Just a minor tweak to avoid several calculations when one would do.
> Since we have a function for rounded-up division, we might as well
> use it instead of the (X + Y - 1) / Y idiom.
>
> Tested on x86_64-linux-gnu. OK to install?
I ended up reverting this. I'd assum
My change to avoid building a dummy variable in a nested function turns
out to have been too aggressive; in this case, we have a reference to a
local const variable in the type of an array that we're capturing. It
seems safe enough to make dummy copies of const and static variables
when instan
On Fri, 2 May 2014, John Marino wrote:
> 1) I don't know which type definitions are missing (iow, the important
> ones from sys/type.h that are required to build gcc)
The default presumption should be:
* from GCC provides what it needs to provide; nothing extra is
needed and such a #include sh
On 5/2/2014 22:15, Joseph S. Myers wrote:
> On Fri, 2 May 2014, John Marino wrote:
>
>> 1) I don't know which type definitions are missing (iow, the important
>> ones from sys/type.h that are required to build gcc)
>
> The default presumption should be:
>
> * from GCC provides what it needs to
Hi Jonathan
I just wanted to make sure that you are aware that I preferred to
wait for another validation of the small modification I have done.
François
On 28/04/2014 23:07, François Dumont wrote:
On 27/04/2014 15:39, Jonathan Wakely wrote:
On 17/04/14 22:43 +0200, François Dumont wro
While I was looking at something else it occurred to me that
vague_linkage_p ought to return true for local statics in functions with
vague linkage. I don't know that this actually affects anything, but it
seems more correct.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit ee36858346a40
Hi,
On 05/02/2014 08:05 PM, Jason Merrill wrote:
I'd tweak instantiate_decl differently; a deleted function is defined,
so pattern_defined should be true.
I see, thanks. Simply setting pattern_defined and nothing else appears
to work very well. The only minor annoyance is that DECL_STRUCT_FUNCT
This patch series demonstrates a way of reimplementing the 89-patch series:
"[PATCH 00/89] Compile-time gimple-checking"
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01148.html
whilst avoiding introducing a pair of "gimple_foo/const_gimple_foo" typedefs
for each subclass.
It eliminates the
gcc/
* gimple.h (gimple_switch): New subclass of gimple_stmt_with_ops,
adding the invariant that stmt->code == GIMPLE_SWITCH.
(is_a_helper ::test): New.
(is_a_helper ::test): New.
(gimple_try): Likewise.
* coretypes.h (gimple_switch): Add forward dec
Currently, the gcc.target/powerpc/pack0[23].c test cases are failing on trunk
and the 4.9 and 4.8 branches. The problem is we either fail to register the
builtins leading to undefined reference errors to the __builtin_* symbol or
we ICE due to having registered the builtin, but due to compiler opt
On Mon, Apr 28, 2014 at 4:04 AM, Richard Biener wrote:
> On Thu, 24 Apr 2014, Cong Hou wrote:
>
>> Given the following loop:
>>
>> int a[N];
>> short b[N*2];
>>
>> for (int i = 0; i < N; ++i)
>> a[i] = b[i*2];
>>
>>
>> After being vectorized, the access to b[i*2] will be compiled into
>> several
These are fine.
On 05/02/2014 03:20 PM, Richard Sandiford wrote:
This patch adds some assertions against sext (.., 0) and zext (..., 0).
The former is undefined at the sext_hwi level and the latter is disallowed
for consistency with the former.
Also, set_bit (rightly IMO) can't handle bit >= pr
this is fine.
On 05/02/2014 03:22 PM, Richard Sandiford wrote:
divmod_internal didn't handle unsigned division in which the inputs
have implicit all-one upper bits. There were two problems:
- wi_unpack should extend implicit 1s to index blocks_needed - 1
(possibly with a zext_hwi on the las
"Steve Ellcey " writes:
> Two MIPS specific tests started failing a few days ago, this patch fixes
> them. The tests are trying to check that a performance optimization is
> done and that one constant is derived from another and not simply loaded
> as a completely new constant.
>
> Post 4.9 chang
83 matches
Mail list logo
