Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)

2009/2/1 Sean Callanan : > > (3) The -fplugin-arg argument is one way to do arguments. We do it as > > -ftree-plugin=/path/to/plugin.so:arg=value:arg=value:... > In the previous discussions we had on this whole thing (http://gcc.gnu.org/ml/gcc/2008-09/msg00292.html), we were aiming towards argum

Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)

On Wed, Feb 04, 2009 at 05:04:10PM -0800, Le-Chun Wu wrote: > >> -fplugin=/path/to/plugin.so;arg1=value;arg2=value;... > >> > > I am not sure if it is GCC's responsibility to understand key-value > (or any other types of) arguments to plugins. I think GCC should > simply take a string (which, of c

Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)

Hi Sean, It's great that you updated the wiki page with the latest and more detailed API design. We (at Google) also started to look at the GCC plugin support a couple of weeks ago. We had a quick prototype implemented based on the original APIs that Taras put together in the old wiki. (I can sen

ARM compiler generating never-used constant data structures

I have various constants. If I define them in a header file like this: static const int my_thing_a = 3; static const int my_thing_b = 12345; then everything is nice, if I use them the compiler knows their value and uses them as literals and it doesn't actually put them into the .rodata section (w

PATCH: Update classification of aggregates with __m256 ([AVX]: Update x86-64 psABI for aggregates with __m256)

On Tue, Feb 3, 2009 at 8:41 AM, H.J. Lu wrote: > On Sun, Feb 1, 2009 at 11:44 AM, H.J. Lu wrote: >> Hi, >> >> We like to update x86-64 psABI to pass aggregates of 32 bytes with >> single __m256 field >> in AVX registers, instead of memory. However, finding the proper >> wording seems tricky. >> H

gcc-4.2-20090204 is now available

Snapshot gcc-4.2-20090204 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20090204/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: invalid "may be used uninitialized" warning with g++ current

Thanks, Sorry, but I don't understood - is it impossible to fix, so there are no needs in bug report? Or PR about this issue already exists? Or it's not a bug? Dmitry 2009/2/5 Andrew Pinski : > On Wed, Feb 4, 2009 at 1:18 PM, Дмитрий Дьяченко wrote: >> The following code >> >> int bar(int *gl

Re: invalid "may be used uninitialized" warning with g++ current

On Wed, Feb 4, 2009 at 1:18 PM, Дмитрий Дьяченко wrote: > The following code > > int bar(int *global) > { >int local; >if(&local != global) >return 0; >return local; > } The issue is that GCC does not figure that global cannot point to local so it does not optimize away the if

Re: Creating imaginary inf/nan in GCC

From: "Richard Guenther" Thanks, I do want to test the middle-end. However I need to do more than just create the complex expression. I also have to pass it to a builtin that evaluates using MPC like __builtin_csin(). The fortran frontend evaluates complex transcendentals in fortran/simplify

invalid "may be used uninitialized" warning with g++ current

The following code int bar(int *global) { int local; if(&local != global) return 0; return local; } compiled with gcc/x86/Linux version 4.4.0 20090204 (experimental) [trunk revision 143938] trigger warning: # g++ -Wall -O2 -c test4.cpp test4.cpp: In function 'in

Re: Closing 4.2 branch

Joseph S. Myers wrote: > As no volunteers to produce a further 4.2 release or releases have come > forward since the last status report > , I propose to close the > 4.2 branch after 4.4 is branched and all the steps in the branching > checklist <

The Linux binutils 2.19.51.0.2 is released

This is the beta release of binutils 2.19.51.0.2 for Linux, which is based on binutils 2009 0204 in CVS on sourceware.org plus various changes. It is purely for Linux. All relevant patches in patches have been applied to the source tree. You can take a look at patches/README to see what have been

Re: New Failure in GCC testsuite from PR35318

Hi Jakub, The test needs double, otherwise it wouldn't fail with a buggy cc1 on i?86. I've been initially contemplating putting the testcase into gcc.target/i386/, but then thought it would be good to test this on a couple of other arches too. Guess it can be limited to a couple of targets whic

Re: New Failure in GCC testsuite from PR35318

On Wed, Feb 04, 2009 at 01:49:54PM +, Nick Clifton wrote: > You recently added gcc.c-torture/compile/pr35318.c to the gcc > testsuite. This has introduced a new group of failures for the m32c > port because of this error message: > > pr35318.c: In function 'foo': > pr35318.c:7:

New Failure in GCC testsuite from PR35318

Hi Jakub, You recently added gcc.c-torture/compile/pr35318.c to the gcc testsuite. This has introduced a new group of failures for the m32c port because of this error message: pr35318.c: In function 'foo': pr35318.c:7: error: can't find a register in class 'GENERAL_REGS' while rel

Re: GCC & OpenCL ?

"Joseph S. Myers" writes: > > The AMD instruction sets now have public documentation. Other > manufacturers may well follow suit, especially if enough people caring > about free software and open documentation choose which GPU to buy on such > a basis (which is obviously a personal choice for