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

[Brendon Costa]

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 arguments like:

(Style 1)
-fplugin= -f-[=]

so this might look like:
gcc -fplugin=edoc -fedoc-file=blah.edc -fedoc-embed

The idea was that GCC would then search for the plugin on some defined
search path (that will be specific for the build tuple and GCC
version) OR a user could specify the plugin including path on the
command line directly. So the above COULD look something like:

gcc -fplugin=/usr/local/lib/gcc-4.0.4/i386-unknown-netbsdelf3.0/edoc.so.1.0.0
-fedoc-file=blah.edc -fedoc-embed
gcc -fplugin=/usr/local/lib/gcc-4.0.4/i386-unknown-netbsdelf3.0/edoc.so.1.0.0
-fedoc-file=blah.edc -fedoc-embed

I understand that currently we are looking at a new format like:

(Style 2)
-fplugin=;[=];[=]...

example:
gcc 
-fplugin=/usr/local/lib/gcc-4.0.4/i386-unknown-netbsdelf3.0/edoc.so.1.0.0;file=blah.edc;embed

I personally prefer Style 1 for the plugin framework. My reasons include:

* It looks more like existing options and has a level of familiarity.
* Using ';' to separate args can be confusing to new people especially
if they forget to quote them properly (I can see many questions on
gcc-help arising from this). Also is ';' safe to use on all systems or
can some filesystems include the ';' character in a file/path name?
* I like to have the option for the plugin to be searched for by GCC
on a pre-defined search path. For those that want to specify their
plugins explicitly, they can still do so.
* I know that "automatic loading" of plugins is not going to be in the
plugin framework, but if in the future we DID decide to add it (for
some unknown reason), then the plugin arguments would not need to be
changed. I.e. With the above example if the plugin: edoc was to be
automatically loaded, its arguments could be provided like:

gcc -fedoc-file=blah.edc -fedoc-embed

which is just the same as it was before, but the -fplugin=edoc was omitted.

Brendon.

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

[Daniel Jacobowitz]

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 course, can be something like
> "arg1=value arg2=value") and pass it (unparsed) to the plugin. It is
> plugin's job to parse/process the given arguments (whatever way it
> likes).

Please let GCC do this, so that argument parsing can be (A)
centralized, and (B) standardized.  Otherwise the right way to pass
arguments will end up different for every plugin.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Le-Chun Wu]

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 send out
the patch later for people's reference.) The updated APIs in general
look good to me. I do have some comments based on our experience with
the initial prototyping:

>>
>> void register_callbacks(int nregistrations, struct plugin_registration 
>> *registrations);
>>

Instead of passing in an array of plugin_registration objects with a
single register_callbacks call, it's probably better to have the
plugin call a sequence of register_callback with the necessary
information, as shown in the following example:

void plugin_register_callback (const char *plugin_name, enum
plugin_event event, plugin_callback_func  callback, void *user_data);

/* In plugin code */
void
plugin_init()
{
  ...
  register_callback (plugin_name, PLUGIN_FINISH_STRUCT, handle_struct, NULL);
  register_callback (plugin_name, PLUGIN_FINISH_UNIT,
handle_end_of_compilation_unit, NULL);
  ...
}

In the function body of register_callback, GCC can then create the
plugin_registration objects and chain them together based on the event
type. Because GCC will need to maintain a list of plugin_registration
objects for each event anyway, we might as well let it create (and
destroy if necessary) the objects instead of leaving the task to the
plugins.

Note that in my example an additional parameter, plugin_name, is added
in register_callback. We found it useful to have the name around when
emitting error messages if something goes wrong during the callback
registration process.

>>
>> -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 course, can be something like
"arg1=value arg2=value") and pass it (unparsed) to the plugin. It is
plugin's job to parse/process the given arguments (whatever way it
likes). So the prototype of the plugin_init would look like this:

void plugin_init (const char *plugin_name, const char *plugin_arg);

In our current prototype, we implemented the originally proposed flag
"-fplugin-arg=", which is associated with the plugin specified in the
most recently parsed "-fplugin" flag. If a "-fplugin-arg" flag is used
in the command-line without any preceding "-fplugin", an error message
is emitted. Having the plugin name and its arguments concatenated as
currently proposed is also fine, but I would prefer a simple string
(like below) to a series of key-value pairs.

-fplugin=/path/to/plugin.so;"arguments"

(Note that the double quotes may not needed if the "arguments" doesn't
contain characters such as spaces.)

>>
>> Pass Manager
>>

We think it would be quite daunting (and probably open up a can of
worms) to allow plugins to re-order passes. So to get things moving
quickly, in our initial prototype we only support insertion of a new
pass and replacing an existing pass. When registering a new pass with
GCC, the plugin uses the normal register_callback call with the
PLUGIN_PASS_MANAGER_SETUP event. However, instead of registering a
callback function, it passes in a plugin_pass object (see below) that
specifies the opt_pass object of the new pass, the name of the
reference pass, the static instance number of the reference pass, and
whether to insert before/after or replacing the reference pass.

enum pass_positioning_ops
{
  PASS_POS_INSERT_AFTER,
  PASS_POS_INSERT_BEFORE,
  PASS_POS_REPLACE
};

struct plugin_pass
{
  struct opt_pass *pass;
  const char *reference_pass_name;
  /* Insert the pass at the specified instance of the reference pass.
 If it's 0, do that for every instance.  */
  int ref_pass_instance_number;
  enum pass_positioning_ops pos_op;
};

/* In plugin code */
void
plugin_init()
{
  ...
  register_callback (plugin_name, PLUGIN_PASS_MANAGER_SETUP, NULL, &pass_info);
  ...
}

When registering and positioning a new pass, GCC will search the
passes chained up in all_lowering_passes, all_ipa_passes, and
all_passes (similar to Mozilla dehydra's implementation) to find the
reference pass(es) with the matching name and instance number, and
then either insert the new pass or replace the reference pass.

One caveat with our current implementation is that because the
registration of new plugin passes happens after the command-line
options are parsed, we cannot specify single pass dumping for plugin
passes (e.g. -fdump-tree-newpass).  IR dumping of plugin passes is
enabled only when the dump-all flags (e.g. -fdump-tree-all) are
specified.

What do people think about this pass registration/positioning
interface that I described? (Again, I will send out our patch later so
that people can get a better idea if my description is not clear
enough.)

Le-chun W

ARM compiler generating never-used constant data structures

[Zoltán Kócsi]

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 (which is important because I have a lot of them and
code space is at premium).

Now these things are very closely related, so it would make the program
much clearer is they could be collected in a structure. That is:

struct things { int a; int b; }; 

and then I could define a global structure

const struct things my_things = { 3, 12345 };

so that I can refer them as my_things.a or my_things.b;

The problem is that I do not want to instantiate the actual "things"
structure, for the same reason I did not want to instantiate the
individual const int definitions. So, I tried the GCC extension of
"compound literals" like this:

#define my_things ((struct things) { 3, 12345 })

int func( int x )
{
   if ( x )
  return my_things.a;
   else
  return my_things.b;
}

If I compile the above with -O2 or -Os, then if the target is AVR or
x86_64 then the result is what I expected, func() just loads 3 or 12345
then returns and that's all. There is no .rodata generated.

However, compiling for the ARM generates the same function code, but it
also generates the image of "things" in the .rodata segment. Twice. Even
when it stores 12345 separatelly. The code never actually references
any of them and they are not global thus it is just wasted memory:

.section.rodata
.align  2
.type   C.1.1095, %object
.size   C.1.1095, 8
C.1.1095:
.word   3
.word   12345
.align  2
.type   C.0.1094, %object
.size   C.0.1094, 8
C.0.1094:
.word   3
.word   12345
.text
.align  2
.global func2
.type   func2, %function
func2:
ldr r3, .L6
cmp r0, #0
moveq   r0, r3
movne   r0, #3
bx  lr
.L7:
.align  2
.L6:
.word   12345
 
Is there a reason why GCC generates the unused .rodata for the ARM
while for the other two it does not?

I guess I'm doing something fundamentally wrong, as usual...

Thanks,

Zoltan

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

[H.J. Lu]

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.
>> Here is what I got.  Any comments?
>>
>
> Here is the revised proposal. Any comments. I will post a gcc
> patch soon.
>

Here is the gcc patch with testcases. OK for trunk?

Thanks.

-- 
H.J.
gcc/

2009-02-03  H.J. Lu  

* config/i386/i386.c (x86_64_reg_class): Remove X86_64_AVX_CLASS.
(x86_64_reg_class_name): Removed.
(classify_argument): Return 0 if bytes > 32.  Return 0 if the
first one isn't X86_64_SSE_CLASS or any other ones aren't
X86_64_SSEUP_CLASS when size > 16bytes.  Don't turn
X86_64_SSEUP_CLASS into X86_64_SSE_CLASS if the preceded one
is X86_64_SSEUP_CLASS.  Set AVX modes to 1 X86_64_SSE_CLASS
and 3 X86_64_SSEUP_CLASS.
(construct_container): Remove X86_64_AVX_CLASS.  Handle 4
registers with 1 X86_64_SSE_CLASS and 3 X86_64_SSEUP_CLASS.

gcc/testsuite/

2009-02-04  H.J. Lu  

* gcc.target/x86_64/abi/avx/abi-avx.exp: New.
* gcc.target/x86_64/abi/avx/args.h: Likewise.
* gcc.target/x86_64/abi/avx/asm-support.S: Likewise.
* gcc.target/x86_64/abi/avx/avx-check.h: Likewise.
* gcc.target/x86_64/abi/avx/test_m256_returning.c: Likewise.
* gcc.target/x86_64/abi/avx/test_passing_m256.c: Likewise.
* gcc.target/x86_64/abi/avx/test_passing_structs.c: Likewise.
* gcc.target/x86_64/abi/avx/test_passing_unions.c: Likewise.

Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c  (revision 5119)
+++ gcc/config/i386/i386.c  (revision 5120)
@@ -1773,7 +1773,6 @@ enum x86_64_reg_class
 X86_64_NO_CLASS,
 X86_64_INTEGER_CLASS,
 X86_64_INTEGERSI_CLASS,
-X86_64_AVX_CLASS,
 X86_64_SSE_CLASS,
 X86_64_SSESF_CLASS,
 X86_64_SSEDF_CLASS,
@@ -1783,11 +1782,6 @@ enum x86_64_reg_class
 X86_64_COMPLEX_X87_CLASS,
 X86_64_MEMORY_CLASS
   };
-static const char * const x86_64_reg_class_name[] =
-{
-  "no", "integer", "integerSI", "sse", "sseSF", "sseDF",
-  "sseup", "x87", "x87up", "cplx87", "no"
-};
 
 #define MAX_CLASSES 4
 
@@ -4863,8 +4857,8 @@ classify_argument (enum machine_mode mod
   tree field;
   enum x86_64_reg_class subclasses[MAX_CLASSES];
 
-  /* On x86-64 we pass structures larger than 16 bytes on the stack.  */
-  if (bytes > 16)
+  /* On x86-64 we pass structures larger than 32 bytes on the stack.  */
+  if (bytes > 32)
return 0;
 
   for (i = 0; i < words; i++)
@@ -4974,6 +4968,20 @@ classify_argument (enum machine_mode mod
  gcc_unreachable ();
}
 
+  if (words > 2)
+   {
+ /* When size > 16 bytes, if the first one isn't
+X86_64_SSE_CLASS or any other ones aren't
+X86_64_SSEUP_CLASS, everything should be passed in
+memory.  */
+ if (classes[0] != X86_64_SSE_CLASS)
+ return 0;
+
+ for (i = 1; i < words; i++)
+   if (classes[i] != X86_64_SSEUP_CLASS)
+ return 0;
+   }
+
   /* Final merger cleanup.  */
   for (i = 0; i < words; i++)
{
@@ -4983,10 +4991,15 @@ classify_argument (enum machine_mode mod
return 0;
 
  /* The X86_64_SSEUP_CLASS should be always preceded by
-X86_64_SSE_CLASS.  */
+X86_64_SSE_CLASS or X86_64_SSEUP_CLASS.  */
  if (classes[i] == X86_64_SSEUP_CLASS
- && (i == 0 || classes[i - 1] != X86_64_SSE_CLASS))
-   classes[i] = X86_64_SSE_CLASS;
+ && classes[i - 1] != X86_64_SSE_CLASS
+ && classes[i - 1] != X86_64_SSEUP_CLASS)
+   {
+ /* The first one should never be X86_64_SSEUP_CLASS.  */
+ gcc_assert (i != 0);
+ classes[i] = X86_64_SSE_CLASS;
+   }
 
  /*  X86_64_X87UP_CLASS should be preceded by X86_64_X87_CLASS.  */
  if (classes[i] == X86_64_X87UP_CLASS
@@ -5107,8 +5120,11 @@ classify_argument (enum machine_mode mod
 case V16HImode:
 case V4DFmode:
 case V4DImode:
-  classes[0] = X86_64_AVX_CLASS;
-  return 1;
+  classes[0] = X86_64_SSE_CLASS;
+  classes[1] = X86_64_SSEUP_CLASS;
+  classes[2] = X86_64_SSEUP_CLASS;
+  classes[3] = X86_64_SSEUP_CLASS;
+  return 4;
 case V4SFmode:
 case V4SImode:
 case V16QImode:
@@ -5165,7 +5181,6 @@ examine_argument (enum machine_mode mode
   case X86_64_INTEGERSI_CLASS:
(*int_nregs)++;
break;
-  case X86_64_AVX_CLASS:
   case X86_64_SSE_CLASS:
   case X86_64_SSESF_CLASS:
   case X86_64_SSEDF_CLASS:
@@ -5264,7 +5279,6 @@ construct_container (enum machine_mode m
   case X86_64_INTEGER_CLASS:
   case 

gcc-4.2-20090204 is now available

[gccadmin]

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/gcc-4_2-branch 
revision 143942

You'll find:

gcc-4.2-20090204.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.2-20090204.tar.bz2 C front end and core compiler

gcc-ada-4.2-20090204.tar.bz2  Ada front end and runtime

gcc-fortran-4.2-20090204.tar.bz2  Fortran front end and runtime

gcc-g++-4.2-20090204.tar.bz2  C++ front end and runtime

gcc-java-4.2-20090204.tar.bz2 Java front end and runtime

gcc-objc-4.2-20090204.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.2-20090204.tar.bz2The GCC testsuite

Diffs from 4.2-20090128 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.2
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

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 *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 statement.
>
> Thanks,
> Andrew Pinski
>

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

[Andrew Pinski]

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 statement.

Thanks,
Andrew Pinski

Re: Creating imaginary inf/nan in GCC

[Kaveh R. Ghazi]

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.c, not in the
middle-end.  So it wouldn't test what I want AFAICT.  It's not a big 
deal,

the nan cases are error paths that should *avoid* folding via MPC.


If you go through memory the compiler should promote that to a register
and constant propagate the result, isn't that enough?


All the previous tests of this nature were in 
gcc.dg/torture/builtin-math-*.c and are done at all opt levels 
including -O0.  I think your suggestion works, but only when optimizing. 
Also, I think it doesn't work with -fdump-tree-original, I'd have to inspect 
a different dump file.  (Any thoughts on which one?)


The obsessive part of my brain wants to keep everything the same as the 
other tests. :-)   But I suppose it would work, I just have to tweek it with 
these things in mind.


   --Kaveh

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 'int bar(int*)':
test4.cpp:6: warning: 'local' may be used uninitialized in this function

gcc-3.4.6/FreeBSD/x86 and gcc-4.1.2/FedoraCore8/x86 does not warning.

I was tried to find anything similar in bugzilla (including #24639), but fail.

I miss something or I need to file bug report?

Dmitry

Re: Closing 4.2 branch

[Mark Mitchell]

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  have been completed for 4.4.  

I think that's appropriate.

> This means disabling snapshots and nightly DATESTAMP updates for the 
> branch, closing bugs that are open as 4.2 regressions but fixed in 4.3, 
> 4.4 and 4.5, and removing "4.2/" from the summaries of 4.2 regression bugs 
> that remain open as also being regressions in future releases. 

Let's add a checklist for that as well; it's a mechanical process that
we may as well document.

Thanks,

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

The Linux binutils 2.19.51.0.2 is released

[H.J. Lu]

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 applied and
in what order they have been applied.

Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts

fnstsw %eax

fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use

fnstsw %ax

Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.

For

.data.init_task : { *(.data.init_task) }

LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use

.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }

to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior.  You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.

The new x86_64 assembler no longer accepts

monitor %eax,%ecx,%edx

You should use

monitor %rax,%ecx,%edx

or
monitor

which works with both old and new x86_64 assemblers. They should
generate the same opcode.

The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,

movl (%eax),%ds
movl %ds,(%eax)

To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,

mov (%eax),%ds
mov %ds,(%eax)

should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support

movw (%eax),%ds
movw %ds,(%eax)

without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at

http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch

The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add

ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif

to arch/ia64/Makefile in your kernel source tree.

Please report any bugs related to binutils 2.19.51.0.2 to
hjl.to...@gmail.com

and

http://www.sourceware.org/bugzilla/

Changes from binutils 2.19.51.0.1:

1. Update from binutils 2009 0204.
2. Support AVX Programming Reference (January, 2009)
3. Improve .s suffix support in x86 disassembler.
4. Add --prefix/--prefix-strip for objdump -S.  PR 9784.
5. Change "ld --as-needed" to resolve undefined references in DSO.
6. Add -Ttext-segment to ld to set address of text segment.
7. Fix "ld -r --gc-sections --entry" crash with COMDAT group.  PR 9727.
8. Improve linker compatibility for g++ 3.4 `.gnu.linkonce.r.*.
9. Add VMS/ia64 support.
10. Improve arm support.
11. Improve cris support.
12. Improve m68k support.
13. Improve mips support.
14. Improve spu support.

Changes from binutils 2.19.50.0.1:

1. Update from binutils 2009 0106.
2. Support AVX Programming Reference (December, 2008)
2. Encode AVX insns with 2byte VEX prefix if possible.
4. Add .s suffix support to swap register operands to x86 assembler.
5. Properly select NOP insns for code alignment in x86 assembler.
6. Fix 2 symbol visibility linker bugs.  PRs 9676/9679.
7. Fix an ia64 linker relaxation bug.  PR 7036.
8. Fix a symbol versioning bug. PR 7047.
9. Fix unitialized data in linker.  PR 7028.
10. Avoid a linker crash on bad input.  PR 7023.
11. Fix a linker memory leak.  PR 7012.
12. Fix strip/objcopy crash on PT_GNU_RELRO.  PR 7011.
13. Improve MacOS support.
14. Fix a COFF linker bug.  PR 6945.
15. Add LM32 support.
16. Fix various arm bugs.
17. Fix various avr bugs.
18. Fix various CR16  bugs.
19. Fix various cris bugs.
20. Fix various m32c bugs.
21. Fix various m68k bugs.
22. Fix various mips bugs.
23. Fix various ppc bugs.
24. Fix various s390 bugs.
25. Fix various sparc bugs.
26. Fix various spu bugs.
27. Fix various xtensa bugs.

The file list:

1. binutils-2.19.51.0.2.tar.bz2. Source code.
2. binutils-2.19.50.1.1-2.19.51.0.2.diff.bz2. Patch against the
   previous beta source code.
3. binutils-2.19.51.0.2.i686.tar.bz2. IA-32 binary tar ball for RedHat
   EL 4.
4. binutils-2.19.51.0.2.ia64.tar.bz2. IA-64 binary tar ball for RedHat
   EL 4.
5. binutils-2.19.51.0.2.x86_64.tar.bz2. X64_64 binary tar ball for RedHat
   EL 4.

The primary sites for th

Re: New Failure in GCC testsuite from PR35318

[Nick Clifton]

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 which
are supposed to handle this, or it can have a list of targets which aren't
supposed to compile this.


Well my tests show that it fails on:

 am33-*-*
 arc-*-*
 avr-*-*
 h8300-*-*
 frv-*-*
 hppa64-*-*
 m32c-*-*
 m32r-*-*
 m68hc1*-*-*
 mmix-*-*
 mn10300-*-*
 powerpc*-*-*
 sh-*-*
 vax-*-*

I have a patch to add a "dg-skip-if" line to the pr35318.c file for 
these targets.  Shall I submit it officially ?


Cheers
  Nick

Re: New Failure in GCC testsuite from PR35318

[Jakub Jelinek]

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: error: can't find a register in class 'GENERAL_REGS' while 
> reloading 'asm'
> pr35318.c:7: error: 'asm' operand has impossible constraints
> 
>   Looking at the test it appears to assume that a double can be put
>   into register class "r", but this is not true for the m32c (and
>   probably other 16-bit ports as well), since doubles occupy two
>   registers.
> 
>   I can add an xfail for the m32c, but I was wondering if it would
>   break the importance of the test if the "double" type was changed to
>   "float" ?  This would allow the test to pass for the m32c as well.

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 which
are supposed to handle this, or it can have a list of targets which aren't
supposed to compile this.

Jakub

New Failure in GCC testsuite from PR35318

[Nick Clifton]

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 
reloading 'asm'
pr35318.c:7: error: 'asm' operand has impossible constraints

  Looking at the test it appears to assume that a double can be put
  into register class "r", but this is not true for the m32c (and
  probably other 16-bit ports as well), since doubles occupy two
  registers.

  I can add an xfail for the m32c, but I was wondering if it would
  break the importance of the test if the "double" type was changed to
  "float" ?  This would allow the test to pass for the m32c as well.

Cheers
  Nick

Re: GCC & OpenCL ?

[Andi Kleen]

"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 them).

Intel current generation GPU documentation is available at 
http://intellinuxgraphics.org/documentation.html

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.