find_modifiable_mems was introduced to gcc 4.8 in september 2012. Is
there any documentation as to how it is supposed to help the haifa
scheduler?
In my private port of gcc it make the following type of transformations
from
a= *(b+20)
b+=30
to
b+=30
a=*
On 06/02/2015 11:23 PM, H.J. Lu wrote:
> Trampling code for nested functions puts code on stack.
This is an issue for the CS ≠ DS case, as opposed to _Bool, I assume.
In other words, we are okay if and only if we can run with an NX stack?
-hpa
On 06/02/2015 06:02 PM, Richard Henderson wrote:
> On 06/02/2015 04:46 PM, H. Peter Anvin wrote:
>> For the x86 backend explicitly, is doing something like:
>>
>> _Bool x;
>>
>> asm("blah ; setc %0" : "=qm" (x));
>>
>> ... guaranteed to be safe for older versions of gcc?
>
> I believe so,
-Original Message-
From: Jeff Law [mailto:l...@redhat.com]
Sent: Tuesday, June 02, 2015 9:19 PM
To: Ajit Kumar Agarwal; Richard Biener; gcc@gcc.gnu.org
Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala
Subject: Re: [RFC] Design and Implementation for Path Split
On 05/31/2015 07:03 PM, Alan Modra wrote:
I agree. Do you intend to get rid of WORD_REGISTER_OPERATIONS,
POINTERS_EXTEND_UNSIGNED, PUSH_ROUNDING, SHORT_IMMEDIATES_SIGN_EXTEND,
and LOAD_EXTEND_OP? ;-)
Oh yes, please. ;-)
Although for the specific case of this thread, W_R_O, S_I_S_E, and L_E_
On 06/02/2015 04:46 PM, H. Peter Anvin wrote:
For the x86 backend explicitly, is doing something like:
_Bool x;
asm("blah ; setc %0" : "=qm" (x));
... guaranteed to be safe for older versions of gcc?
I believe so, for the restricted set of conditions I expect you're asking.
I
On Tue, Jun 02, 2015 at 11:28:09AM -0500, Segher Boessenkool wrote:
> On Tue, Jun 02, 2015 at 08:49:37AM +0930, Alan Modra wrote:
> > but and64_2_operand doesn't include all of and_operand!
>
> Maybe I'm slow today, but I don't see it? Do you have an example?
I need to get new glasses. That's t
For the x86 backend explicitly, is doing something like:
_Bool x;
asm("blah ; setc %0" : "=qm" (x));
... guaranteed to be safe for older versions of gcc?
-hpa
On 06/02/2015 08:32 AM, Andreas Krebbel wrote:
-(define_insn "*3"
+(define_insn "*3_reg"
[(set (match_operand:GPR 0 "register_operand" "=d")
(SHIFT:GPR (match_operand:GPR 1 "register_operand" "")
- (match_operand:SI 2 "shift_count_or_setmem_operand" "Y")))]
+
Snapshot gcc-5-20150602 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150602/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5
On Tue, May 19, 2015 at 03:17:26PM +0100, Kyrill Tkachov wrote:
> Hi all,
Sorry, it took me awhile to comment.
> I'm working on enabling target attributes and pragmas on aarch64 and I'm
> stuck on a particular issue.
> I want to be able to use a target pragma to enable SIMD support in a SIMD
>
On 06/02/2015 09:32 AM, Andreas Krebbel wrote:
Bootstrap failed with:
/home/andreas/clean/../gcc/gcc/dwarf2out.c: In function ‘constant_size’:
/home/andreas/clean/../gcc/gcc/dwarf2out.c:6572: error: insn does not satisfy
its constraints:
(insn 39 38 66 6 /home/andreas/clean/../gcc/gcc/toplev.h:
On 06/02/2015 09:57 AM, Kyrill Tkachov wrote:
I'm stuck on noce_process_if_block (in ifcvt.c) and what I think is a
restriction that the THEN-block contents have to be only a single set
insn. This fails on aarch64 because we get an extra zero_extend.
In particular, the following check in noce_pr
On Tue, Jun 02, 2015 at 08:49:37AM +0930, Alan Modra wrote:
> > > In and3 expander I think you want the following since
> > > and64_2_operand covers the extra double-rotate cases, not all DImode.
> > >
> > > - if ((mode == DImode && !and64_2_operand (operands[2],
> > > mode))
> > > - || (mo
Hi all,
I'm looking at a case on aarch64 that's not if-converted to use conditional
moves:
typedef unsigned char uint8_t;
typedef unsigned int uint16_t;
uint8_t foo(const uint8_t byte, const uint16_t generator)
{
if (byte & 0x80) {
return (byte << 1) ^ (generator & 0xff);
} else {
On 06/02/2015 12:35 AM, Ajit Kumar Agarwal wrote:
I don't offhand know if any of the benchmarks you cite above are free-enough to
derive a testcase from. But one trick many of us use is to instrument the
>>pass and compile some known free software (often gcc
itself) to find triggering code and
On 06/01/2015 05:06 PM, Jeff Law wrote:
> On 06/01/2015 06:23 AM, Andreas Krebbel wrote:
>> On 05/30/2015 02:57 AM, DJ Delorie wrote:
>>> In config/s390/s390.c we accept addresses that are SImode:
>>>
>>>if (!REG_P (base)
>>> || (GET_MODE (base) != SImode
>>> && GET_MODE (ba
I encountered this C++ instantiation problem. (Please guide me, if
this is not the correct list.)
The minimal test case I have is as follows:
#include
template
auto compose(Fn fn)
{
return [fn](auto&&... x) -> decltype(auto)
{
return fn(std::forward(x)...);
};
}
template
On 06/02/2015 05:22 AM, Andrew Bennett wrote:
Hi,
I am debugging a segmentation fault when compiling some code for MIPS. The
segmentation fault occurs in the plus_constant function in explow.c when it
tries to update a constant pool value. The offending code is below:
case MEM:
/* If t
Thanks a lot, Jeff!
I was missing some stuff in TARGET_LEGITIMATE_CONSTANT_P.
Lev.
On Mon, Jun 1, 2015 at 11:35 PM, Jeff Law wrote:
> On 06/01/2015 12:51 PM, Lev Yudalevich wrote:
>>
>> While working on a custom backend for quite a standard RISC-like
>> architecture, I defined 'high'/'lo_sum' pa
Hi,
I am debugging a segmentation fault when compiling some code for MIPS. The
segmentation fault occurs in the plus_constant function in explow.c when it
tries to update a constant pool value. The offending code is below:
case MEM:
/* If this is a reference to the constant pool, try repl
The LOG function returns the principal value of the complex logarithm
whose imaginary part omega must be in the range -pi < omega <= pi.
GFORTRAN does it correctly but the online documentation
https://gcc.gnu.org/onlinedocs/gfortran/LOG.html gives -pi <= omega <=
pi. Perhaps this should be correc
On 2 June 2015 at 06:28, wrote:
> Hi folks,
> the following C++ snippet used to compile, but doesn't anymore with current
> gcc trunk.
Bug reports belong in Bugzilla, not on this mailing list, and this is
already in Bugzilla
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66374)
23 matches
Mail list logo
