On Wed, 13 May 2015, Thomas Schwinge wrote:
> * config/nvptx/nvptx.opt (ptx_isa, sm_30, sm_35): New enum and its
> values.
> (misa=): New option.
New options do of course need documenting in invoke.texi.
--
Joseph S. Myers
jos...@codesourcery.com
Snapshot gcc-4.9-20150513 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20150513/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hi!
On Sat, 9 May 2015 10:26:22 -0700, Satoshi_OHSHIMA
wrote:
> I'm trying to use and evaluate gcc with OpenACC on some NVIDIA GPUs.
> I succeeded to build gcc with OpenACC by using
> http://scelementary.com/2015/04/25/openacc-in-gcc.html as a reference.
Heh, their build instructions very much
On 04/10/2015 06:38 AM, Max Filippov wrote:
> OTOH calling helper function to do multiplication by a constant 8 looks
> rather stupid. I guess we're not going to have non-8-bit bytes on xtensa
> anytime soon, maybe this multiplication can be replaced with shift?
Yes, that's what I'd do.
r~
Ah. I realize it's most likely for testing sibcall_[value]_pop_memory
peepholes, right? In which case the testcase might look like this:
/* { dg-do compile } */
/* { dg-options "-O2" } */
void foo (int a, void (**doo1) (void), void (**doo2) (void))
{
char s[16] = {0};
do s[a] =
Hello,
Last year's x86 sibcall improvements added a currently xfailed test:
/* { dg-do compile { target ia32 } } */
/* { dg-options "-O2" } */
extern int doo1 (int);
extern int doo2 (int);
extern void bar (char *);
int foo (int a)
{
char s[256];
bar (s);
return (a < 0
Hi all,
Are target attributes supposed to redefine the preprocessor macros available?
For example, on aarch64 if the file is compiled with floating point support
the __ARM_FEATURE_FMA predefine is available. If the user adds to a function
a target attribute disabling floating point, then is __ARM
On Wed, May 13, 2015 at 08:41:39AM -0600, Martin Sebor wrote:
> On 05/12/2015 07:40 PM, Andrew Pinski wrote:
> >On Tue, May 12, 2015 at 6:36 PM, Fei Ding wrote:
> >>I think Thiago and Eric just want to know which code-gen is better and
> >>why...
> >
> >
> >You need to understand for a complex pr
On 05/12/2015 07:40 PM, Andrew Pinski wrote:
On Tue, May 12, 2015 at 6:36 PM, Fei Ding wrote:
I think Thiago and Eric just want to know which code-gen is better and why...
You need to understand for a complex process (CISC ISAs) like x86,
there is no one right answer sometimes. You need to
Am 05/12/2015 um 05:13 PM schrieb Jeff Law:
On 05/12/2015 08:58 AM, Georg-Johann Lay wrote:
Ah, yes. The ICE is actually in verify_flow_info: "wrong number of
branch edges after unconditional jump in bb 4".
It starts with an almost trivial jump table:
(jump_insn 82 81 83 19 (parallel [
On Tue, May 12, 2015 at 11:22 PM, Jan Beulich wrote:
On 12.05.15 at 20:42, wrote:
>> Here is the updated proposal. I changed nop prefix from 0x48
>> to 0x67 and clarified how foo@GOTPCREL(%rip) should be
>> resolved.
>
> Mind clarifying how 67 is better than 48?
0x67 works for both x86-64
11 matches
Mail list logo
