Re: interworking problem

[Nick Clifton]

Hi Aram,
   i have gone through the a.out file after this error. 
> that is producing full of arm instructions other than the main
function(which is compiled for -mthumb). 
where should i change for this corresponding error. 
It is not clear what question you are asking here.
Ian has pointed out that you should be compiling your program with the 
-mthumb-interwork switch specified on the gcc command line.

   i have added one new add instruction in thumb mode. based on that
i have written one sample program to emit the corresponding new 
instruction. gcc works fine. when i assemble the function it emits 
> correct opcode. but when i give the same function to the ld it
> emits full of arm instructions instead of thumb instructions.
> which routine checks for this corresponding change.
Again this is not clear.  Do you mean that when the linker is creating 
the executable that it is inserting some ARM-encoded instructions into 
the output, or that it is somehow magically transforming your 
THUMB-encoded instructions into ARM-encoded instructions ?

Perhaps it would help if you could provide a *small* example program and 
 the command lines you use to compile it, as well as description of 
what is wrong with the resulting executable.

Cheers
  Nick

Re: [RFA:] change back name of initial rtl dump suffix to ".rtl".

[Paolo Bonzini]

Gabriel Dos Reis wrote:
Paolo Bonzini <[EMAIL PROTECTED]> writes:
| > > ISTR the name change was to avoid a switch named -fdump-rtl-rtl.
| > To invent an option name alias and use a minor repetition in it
| > as a reason for changing the old behavior is Bad.
| 
| It is not merely an option name alias.  It came together with a
| redesign of the way RTL dumps work, to integrate their management with
| tree dumps and to allow (in the future) to have various levels of
| detail in the RTL dumps as well.

maybe an option with argument?
-fdump-rtl=detailed
-fdump-rtl=classic  # same as -fdump-rtl
-fdump-rtl-* (where the star is a path name) is the name of options that 
enable RTL dumps, e.g.  -fdump-rtl-lreg or -fdump-rtl-cse2; "expand" is 
just a path name, and since the final part of the dump file name is the 
pass name, the file name gets changed from "foobar.00.rtl" to 
"foobar.00.expand".

Paolo

Re: moving v16sf reg with multiple sub-regs

[Dylan Cuthbert]

Hi there,
The assembler instructions themselves don't allow the target to be the same 
as the source unfortunately so removing the '&' is difficult.  (If I enforce 
the same thing without a '&' in inline asm using builtins and building the 
expression manually to generate a new reg rtx if the dest/source are the 
same do you think it will optimize better?)

However, I don't see why it isn't eliminating the move that is generated 
when it realises that the temporary source is discarded.   It seems to do 
this ok if it is just a define_insn with raw multi-line assembly, but I 
can't use multi-line assembly or it destroys optimizations that occur if 
sub-register access is performed, ie. if I overwrite the second v4sf in a 
v16sf type, gcc nicely gets rid of the move of that particular sub-register 
when it copies the entire v16sf around - something I was quite impressed by.

Regards
Dylan
"James E Wilson" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Dylan Cuthbert wrote:
asm( "some_instruction %0,%1,%2,%3" : "=&j" (blob): "j" (vec1), "j"
(vec2), "j" (frog) );
asm( "some_instruction2 %0,%1" : "=&j" (frog) : "j" (blob) );
It is the goal of the register allocator to use as few registers as
possible,
which means that we will try to use the same register for input and
output here.
Until we get to reload, where we see the early clobber (&), and then are
forced
to add a copy so that the instruction has separate input and output
registers.
Early clobbers are bad.  Don't ever use them unless you have to.  Just
because
the instruction operates on pieces of the input does not mean & is
necessary.
You only add the & if the input and output  operands must be in different
non-overlapping registers.
This is just a guess.  Try compiling with -da and looking at the register
assignments in the .lreg and .greg files, and also at what reload did.
It is
possible that there could be something else going on.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

C++ function pointer weirdness

[Volker Reichelt]

Yesterday the output of the following program changed
(probably due to the fix for PR19076):

==
template  int ref (T&){ return 0; }
template  int ref (const T&)  { return 1; }
template  int ref (const volatile T&) { return 2; }
template  int ref (volatile T&)   { return 4; }

template  int ptr (T*){ return 0; }
template  int ptr (const T*)  { return 8; }
template  int ptr (const volatile T*) { return 16; }
template  int ptr (volatile T*)   { return 32; }

void foo() {}

int main()
{
return ref(foo) + ptr(&foo);
}
==

GCC 2.95.3 - 3.4.0 return 0, GCC 3.4.1 - 3.4.4-20050222 return 2,
and now mainline again returns 0.

So the question is: What is the correct return value?

Btw, we really should have this in the testsuite.

In any case, we have a wrong-code regression here, either on the
3.4 branch or on mainline. But before I open a PR I'd like to sort
out which is the correct behavior.

When the result changed in 3.4.1 I bugged Nathan (who caused this
change) about it, and he claimed that '2' is the correct result.
Intel's compiler indeed returns 2.

Regards,
Volker

Re: Re, interworking problem

[Richard Earnshaw]

On Tue, 2005-02-22 at 10:09, aram bharathi wrote:
> hi,
>  normally in thumb mode add instruction supports immediate
> values in the range of 0-255( same source and destination register)
> . i like to increase the range(for architecture analysis as
> curriculam project). i have added this instruction in gcc.
> 
> i have written a c program as
> 
> main()
> {
> int a;
> a=a+320;
> printf("%d",a);
> }
> 

Your testcase is ill-formed.  If you turn the optimizer on, then you
might not get what you expect (a has an undefined initial value). 
However, that's not important here...

> compiled this with option
> 
> arm-elf-gcc -mthumb new.c
> 
> gcc emits a file with this new add instruction.
> 
>   ..
>   mov r3, r7
>   sub r3, r3, #4
>   ldr r3, [r3]
>   addnew  r3, r3, #320
>   str r3, [r2]
>   mov r2, r7
>   sub r2, r2, #12
>   ..
> 
> after assembling this file with binutils as, it produces a a.out
> file(ELF format) with $t mapping information and producing correct
> header formation.
> 
> when i try to give this a.out file into ld it produces the error
> 
> /home/.../arm-elf-ld : /home/../arm-elf/lib/libc.a(printf.o)(printf):
> warning : interworking not enabled
> first occurance : /tmp/cc00zhyh.o : thumb call to arm
> /tmp//cc00zhyh.o(.text+0x4e>: In function 'main'
> new.c:internal error: dangerous error
> 
> but it produces one a.out file. the resultant a.out file should
> have only thumb instructions(compiled with -mthumb option). but
> only the main function have thumb instructions and thumb specific
> header details. other sections have arm instructions(printf and
> other standard functions).
> 
> the output header information and the output a.out file is attached
> with this email.
> thank you

You are trying to link in the ARM version of the library.  If you are
invoking the linker using gcc, then add -mthumb again.  It will then
select the Thumb libraries for you.

If you are invoking ld by hand, then you will need to adjust your
library specifications to find the Thumb start-up code and libraries. 
Most likely this will mean inserting /thumb/ before each final filename
in the library list:

/home/../arm-elf/lib/thumb/libc.a

R.

Re: How does g++ implement error handling?

[Nix]

On 22 Feb 2005, Aaron W. LaFramboise murmured woefully:
> I'm also interested in any overview-level information about the Dwarf2
> unwinding mechanism.

Aldy Hernandez wrote one: .

-- 
> ...Hires Root Beer...
What we need these days is a stable, fast, anti-aliased root beer
with dynamic shading. Not that you can let just anybody have root.
 --- John M. Ford

Re: C++ function pointer weirdness

[Gabriel Dos Reis]

Volker Reichelt <[EMAIL PROTECTED]> writes:

| Yesterday the output of the following program changed
| (probably due to the fix for PR19076):

Thanks for raising this issue.

| 
| ==
| template  int ref (T&){ return 0; }
| template  int ref (const T&)  { return 1; }
| template  int ref (const volatile T&) { return 2; }
| template  int ref (volatile T&)   { return 4; }
| 
| template  int ptr (T*){ return 0; }
| template  int ptr (const T*)  { return 8; }
| template  int ptr (const volatile T*) { return 16; }
| template  int ptr (volatile T*)   { return 32; }
| 
| void foo() {}
| 
| int main()
| {
| return ref(foo) + ptr(&foo);
| }
| ==
| 
| GCC 2.95.3 - 3.4.0 return 0, GCC 3.4.1 - 3.4.4-20050222 return 2,
| and now mainline again returns 0.

I would say that is the behaviour I would expect.  I don't understand
the answer 2.  I'll check with the C++ Core Working Group.

| So the question is: What is the correct return value?
| 
| Btw, we really should have this in the testsuite.
| 
| In any case, we have a wrong-code regression here, either on the
| 3.4 branch or on mainline. But before I open a PR I'd like to sort
| out which is the correct behavior.
| 
| When the result changed in 3.4.1 I bugged Nathan (who caused this
| change) about it, and he claimed that '2' is the correct result.
| Intel's compiler indeed returns 2.

Well, I definitely needs an answer better than "that is what Intel's
compiler does" :-)

-- Gaby

Default constructor and uninitialized const

[Peter Seiderer]

Hello,

the following short C++ programm does not compile with gcc (but with intel
and windows):

/*
 * Gives error when compiled with gcc (eg. 3.4.2, gcc-4.0-20050123).
 * No error with intel (8.1) or windows compiler.
 */

class A1 {
public:
  A1() {}
};

static const A1 a1;

class A2 {

};

static const A2 a2;

int main(int argc, char *argv[]) {

  return 0;
}


# /opt/gcc-3.4.2/bin/g++ default_constructor.cpp 
default_constructor.cpp:17: error: uninitialized const `a3'

Bug or feature?

Peter Seiderer

-- 
DSL Komplett von GMX +++ Supergünstig und stressfrei einsteigen!
AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl

Re: Default constructor and uninitialized const

[Paolo Carlini]

Peter Seiderer wrote:
/*
* Gives error when compiled with gcc (eg. 3.4.2, gcc-4.0-20050123).
* No error with intel (8.1) or windows compiler.
*/
 

... try what they call "strict-ansi" mode...
Paolo.

Re: Default constructor and uninitialized const

[Peter Seiderer]

> Peter Seiderer wrote:
> 
> >/*
> > * Gives error when compiled with gcc (eg. 3.4.2, gcc-4.0-20050123).
> > * No error with intel (8.1) or windows compiler.
> > */
> >  
> >
> ... try what they call "strict-ansi" mode...
> 
> Paolo.
> 

# /opt/gcc-3.4.2/bin/g++ -Wall -ansi default_constructor.cpp
default_constructor.cpp:17: error: uninitialized const `a2'

Any hints to relevant g++ and/or C++ documentation?

Peter

-- 
DSL Komplett von GMX +++ Supergünstig und stressfrei einsteigen!
AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl

Re: Default constructor and uninitialized const

[Paolo Carlini]

Peter Seiderer wrote:
# /opt/gcc-3.4.2/bin/g++ -Wall -ansi default_constructor.cpp
default_constructor.cpp:17: error: uninitialized const `a2'
 

:) :) what *intel* calls "-strict_ansi", of course.
Paolo.

Re: Default constructor and uninitialized const

[Peter Seiderer]

> Peter Seiderer wrote:
> 
> ># /opt/gcc-3.4.2/bin/g++ -Wall -ansi default_constructor.cpp
> >default_constructor.cpp:17: error: uninitialized const `a2'
> >  
> >
> :) :) what *intel* calls "-strict_ansi", of course.
> 
> Paolo.
> 

Thanks, reproducable with intel:

# icc -strict_ansi default_constructor.cpp
default_constructor.cpp(17): warning #854: const variable "a2" requires an
initializer -- class "A2" has no explicitly declared default constructor
  static const A2 a2;
^

Any hints to relevant documentation?

Peter

-- 
Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS
GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail

Re: Default constructor and uninitialized const

[Paolo Carlini]

Peter Seiderer wrote:
Any hints to relevant documentation?
 

8.5/9.
Paolo.

Re: moving v16sf reg with multiple sub-regs

[Dylan Cuthbert]

One reason that occurred to me is that I am issueing the v16sf move as four 
subreg v4sf moves.

One thing I get are "variable may not be initialised" warnings:
v16sf   test;
test = _builtin_matrix_mul( left, right );
return test;
Is there someway I can flag the moves to say that is moving the v16sf 
"whole" so it doesn't need to be initialised and hence avoid the warning?

Dylan
"James E Wilson" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Dylan Cuthbert wrote:
asm( "some_instruction %0,%1,%2,%3" : "=&j" (blob): "j" (vec1), "j"
(vec2), "j" (frog) );
asm( "some_instruction2 %0,%1" : "=&j" (frog) : "j" (blob) );
It is the goal of the register allocator to use as few registers as
possible,
which means that we will try to use the same register for input and
output here.
Until we get to reload, where we see the early clobber (&), and then are
forced
to add a copy so that the instruction has separate input and output
registers.
Early clobbers are bad.  Don't ever use them unless you have to.  Just
because
the instruction operates on pieces of the input does not mean & is
necessary.
You only add the & if the input and output  operands must be in different
non-overlapping registers.
This is just a guess.  Try compiling with -da and looking at the register
assignments in the .lreg and .greg files, and also at what reload did.
It is
possible that there could be something else going on.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Default constructor and uninitialized const

[Peter Seiderer]

> Peter Seiderer wrote:
> 
> >Any hints to relevant documentation?
> >  
> >
> 8.5/9.
> 
> Paolo.
> 
Thank you for the quick answers.
Peter

-- 
Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS
GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail

Re: Default constructor and uninitialized const

[Jonathan Wakely]

On Tue, Feb 22, 2005 at 04:32:33PM +0100, Peter Seiderer wrote:

> Thanks, reproducable with intel:
> 
> # icc -strict_ansi default_constructor.cpp
> default_constructor.cpp(17): warning #854: const variable "a2" requires an
> initializer -- class "A2" has no explicitly declared default constructor
>   static const A2 a2;
> ^
> 
> Any hints to relevant documentation?

It's equivalent to this:

const int i;

which is pretty much certain to be an error and the compiler is doing
you a favour if it rejects it.

The ISO standard says (in 8.5 [dcl.init] paragraph 9):

If no initializer is specified for an object, and the object is of
(possibly cv-qualified) non-POD class type (or array thereof), the
object shall be default-initialized; if the object is of
const-qualified type, the underlying class type shall have a
user-declared default constructor.

The second half of that paragraph applies to A2.

jon

-- 
"A thing is not necessarily true because a man dies for it."
- Oscar Wilde

Re: RFC -- CSE compile-time stupidity

[Jeffrey A Law]

On Mon, 2005-02-21 at 16:36 -0800, Mark Mitchell wrote:
> Jeffrey A Law wrote:
> > Sigh.  I can't wait for this code to become less critical, both in terms
> > of runtime and compile time performance.  There are so many things in 
> > cse.c that are just plain bad
> > 
> > cse.c has a fair amount of complexity in its hash table management
> > code to avoid spending too much time invalidating/removing items
> > in the hash table when a value of an expression changes.
> > 
> > Specifically we have REG_TICK, REG_IN_TABLE and other fields to track 
> > when entries are valid.  It's fairly common to have code which looks
> > something like this (from mention_regs):
> > 
> > 
> > /* Get the number of times this register has been updated in this
> >basic block.  */
> > 
> > #define REG_TICK(N) (get_cse_reg_info (N)->reg_tick)
> > 
> > /* Get the point at which REG was recorded in the table.  */
> > 
> > #define REG_IN_TABLE(N) (get_cse_reg_info (N)->reg_in_table)
> > 
> > /* Get the SUBREG set at the last increment to REG_TICK (-1 if not a
> >SUBREG).  */
> > 
> > #define SUBREG_TICKED(N) (get_cse_reg_info (N)->subreg_ticked)
> 
> I don't see anything wrong with getting rid of these macros, and having 
> the callers do:
> 
>info = get_cse_reg_info (N);
>info->tick ... info->reg_in_table ...
That's roughly what I was doing.  The only downside is we'd have to do
a fair amount of code reorganization since we like to use those macros
in nontrivial conditionals.

But I'm having trouble reproducing the speedups now.  Which makes me
wonder if I goof'd the initial conversion or was testing the wrong
binary or something way stupid like that.


Jeff

Re: Propagation of "pointer" attribute on registers

[Jeffrey A Law]

On Fri, 2005-02-18 at 13:28 -0600, Pat Haugen wrote:
> 
> 
> 
> Is there a reason REG_POINTER isn't propagated to the target register for
> rtl insns of the form "reg_x = regP_y + reg_z", where regP_y is a reg
> marked as REG_POINTER?  It seems the attribute is only propagated when we
> have "reg_x = regP_y + CONST", at least in the couple instances I saw
> (regclass.c:reg_scan_mark_refs() and explow.c:memory_address()).  I've run
> across a case where lack of the REG_POINTER attribute is causing global PRE
> to miss a hoisting opportunity since a memory reference no longer looks
> available (memory disambiguation fails in alias.c:base_alias_check() since
> we can't determine the base address of the memory reference).
It could well be an oversight.  Though as I believe Jim mentioned, you
have to be careful due to architectures like the PA and mn103 where
it's critical to be able to distinguish between a pointer into an
object, a pointer outside of an object and an index.

Consider for example

char a[10];

x1 = &a[0];
x2 = x1 - 10;
y1 = 11;
*(x2 + y) = 20;


x1 is a pointer into an object
x2 is a pointer outside the object
y1 is an index

The problems arise when we try to use unscaled indexed addressing modes;
on some architectures (PA, mn103) memory references implicitly select a
memory segment based on the index register _NOT_ the effective address.

So if "a" in the example above was at the start of the segment boundary
and we used an unscaled indexed address for *(x2 + y), then we would
access the wrong segment and segfault.


ie, setting REG_POINTER needs to be conservatively correct for the
destination of arithmetic insns.

Note there's a number of improvements that could be made to how we
generate and propagate REG_POINTER.

jef

DWARF Website

[Michael Eager]

The DWARF Workgroup of the Free Standards Group (http://www.freestandards.org)
is pleased to announce the creation of a website for the DWARF debugging format
(http://dwarf.freestandards.org).
The DWARF debugging format is used by compilers and debuggers to convey
a description of the source code and how it is translated into machine code.
This permits accurate and efficient debugging of programs.  DWARF is used
with a number of different toolchains such as the GNU Compiler Collection (GCC).
There are three versions of the DWARF standard:  DWARF 1.0 was originally used 
with
System V and several toolchains.  DWARF 2.0 added compression and support for 
C++,
among other enhancements.  DWARF 3.0 is an extension to the DWARF 2.0 format and
adds support for new languages and improved debugging.
We are also pleased to announce the public review of the Draft Standard for 
DWARF
Version 3 which is available from the website.  Following public review and 
resolution
of comments on the Draft Standard, the DWARF Version 3 Standard will be 
released.
There is also a mailing list for discussion of issues related to DWARF.  Please
register at 
http://mail.freestandards.org/cgi-bin/mailman/listinfo/dwarf-discuss.
For additional information, please contact Michael Eager (mailto:[EMAIL 
PROTECTED]).
--
Michael Eager, Chair, DWARF Workgroup[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: moving v16sf reg with multiple sub-regs

[James E Wilson]

Dylan Cuthbert wrote:
Is there someway I can flag the moves to say that is moving the v16sf 
"whole" so it doesn't need to be initialised and hence avoid the warning?
See emit_no_conflict_block in optabs.c.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: moving v16sf reg with multiple sub-regs

[James E Wilson]

Dylan Cuthbert wrote:
The assembler instructions themselves don't allow the target to be the 
same as the source unfortunately so removing the '&' is difficult.  (If 
I enforce the same thing without a '&' in inline asm using builtins and 
building the expression manually to generate a new reg rtx if the 
dest/source are the same do you think it will optimize better?)
If the register allocator doesn't know about the restrictions, then it 
will probably continue to do things that require reloads, which means 
you will still have the extra move instructions.  So I don't think 
generating RTL differently will help.

Just making the dest/src different regs at RTL generation time won't 
work incidentally, as the optimizer will make them the same reg again. 
So the early clobber constraints are the only way to make this work with 
one register class.

You could try defining multiple register classes and using different 
subsets for the source and dest registers, but that might just lead to 
more of a mess.

Otherwise, try looking at the register allocators to see if they can do 
a better job handling the early clobber constraints.

However, I don't see why it isn't eliminating the move that is generated 
when it realises that the temporary source is discarded.
This doesn't make any sense to me in the context of the previous 
example.  We can't eliminate the move just because the source operand 
dies in the instruction.  This is irrelevant.  The move was emitted 
because of the early clobber constraint (presumably) which forces the 
source and dest regs to be different non-overlapping registers.

It seems to 
do this ok if it is just a define_insn with raw multi-line assembly, but 
I don't understand this either.  Examples please.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: RFC: objc_msgSend efficiency patch

[Kai Henningsen]

[EMAIL PROTECTED] (Dale Johannesen)  wrote on 21.02.05 in <[EMAIL PROTECTED]>:

> Simple Objective C programs such as
>
> #include 
> void foo(void) {
>Object *o;
>[o++ free];
> }
>
> result in calling objc_msgSend indirectly through a pointer, instead
> of directly as they did in 3.3.  This seems to happen only at low
> optimization
> levels; still, it's a performance regression.  The reason is that the
> gimplifier
> puts the result of the OBJ_TYPE_REF into a temp due to the
> postincrement.

I thought current tree optimizers should be able to figure this out?

MfG Kai

Re: MMX built-ins performance oddities

[Richard Henderson]

On Mon, Feb 21, 2005 at 05:13:14PM +0100, Prakash Punnoor wrote:
> ... but gcc 3.4.3 has serious issues. It even miscompiles SSE code.
> Are plans to fix this ...

No.


r~

Re: moving v16sf reg with multiple sub-regs

[Dylan Cuthbert]

Brilliant!
This got rid of the warnings, *and* got rid of the spurious move I was 
getting.  Thanks for the advice!

The problem with the spurious move was with the move from memory to the 
v16sf register, because it was doing it with subregs it thought it still had 
to preserve the previous (uninitialised) value and so couldn't optimize the 
move out completely because of the parameter aliasing on those asm 
instructions.

For the last parameter (equiv) of emit_no_conflict_block I am putting in 
"gen_rtx_SET ( V16SFmode, op0, op1 )", does this seem correct to you?

Much thanks
Dylan
"James E Wilson" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Dylan Cuthbert wrote:
Is there someway I can flag the moves to say that is moving the v16sf 
"whole" so it doesn't need to be initialised and hence avoid the warning?
See emit_no_conflict_block in optabs.c.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: RFC: objc_msgSend efficiency patch

[Dale Johannesen]

On Feb 21, 2005, at 10:59 PM, Kai Henningsen wrote:
[EMAIL PROTECTED] (Dale Johannesen)  wrote on 21.02.05 in 
<[EMAIL PROTECTED]>:

Simple Objective C programs such as
#include 
void foo(void) {
   Object *o;
   [o++ free];
}
result in calling objc_msgSend indirectly through a pointer, instead
of directly as they did in 3.3.  This seems to happen only at low
optimization
levels; still, it's a performance regression.  The reason is that the
gimplifier
puts the result of the OBJ_TYPE_REF into a temp due to the
postincrement.
I thought current tree optimizers should be able to figure this out?
They do, as I said, this happens only at low optimization levels.

Re: Does backend need to worry about overlap?

[James E Wilson]

Andy Hutchinson wrote:
do I need to guard against the possibility that the two operands 
overlap?
Generally, overlapping operands won't happen because of the language 
rules, except in special cases.

If you are defining builtins for string/memory operations, like strcpy 
or memmove, then you have to handle overlapping operands if and only if 
the equivalent C language function does.

If you are composing operations, e.g. combining two word sized moves 
into a double-word move, and you don't require double-word alignment for 
double-word moves, then you could accidentally create overlapping 
operands.  In this case, you either need to try to prevent creating 
them, or modify the patterns to handle them.

There are probably some other cases.  Whether this is a problem for you 
really depends on what you are trying to do.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Problem in GCC porting...

[James E Wilson]

[EMAIL PROTECTED] wrote:
We are trying to fix the already ported GCC 2.95 on the ABACUS processor.
ABACUS processor is very much similar to SPARC from SUN.
We don't maintain gcc-2.95 anymore, and we don't have a copy of the 
ABACUS port.  Probably not much that volunteers can do to help you.

1. Variable initialization within block: If we declare and initialize a
variable within a block in the function, initialization happens only at
the first time, not every time, if code enters that block again.
Curious.  Are auto variables being allocated to the stack?  I don't see 
how this could happen if they are on the stack.  This could happen if 
they are allocated to the data section, but that really shouldn't be 
happening.  I don't know offhand where to point you on this one.

2. Function  pointer returning some value:
In case of function pointers returning something we are not able to
collect the same in the return register or variable.
Probably a bug in the call_value pattern in the abacus.md file.  Look at 
what happens when it is passed a (MEM (REG)) for an indirect call.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: moving v16sf reg with multiple sub-regs

[James E Wilson]

Dylan Cuthbert wrote:
For the last parameter (equiv) of emit_no_conflict_block I am putting in 
"gen_rtx_SET ( V16SFmode, op0, op1 )", does this seem correct to you?
This is supposed to be the value of op0 after the no conflict block.  So 
it should just be op1.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: moving v16sf reg with multiple sub-regs

[Dylan Cuthbert]

Ah, ok, sorry about that, I read it as being the equivalent of the whole 
operation.

I'll throw op1 in there, thanks again.
Dylan
"James E Wilson" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Dylan Cuthbert wrote:
For the last parameter (equiv) of emit_no_conflict_block I am putting in 
"gen_rtx_SET ( V16SFmode, op0, op1 )", does this seem correct to you?
This is supposed to be the value of op0 after the no conflict block.  So 
it should just be op1.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Question about GCC 3.4.1 -O2 Optimization bug (i386 and rs6000)

[Vasanth]

Hi,

I am sure this bug has been reported before, but I am
not able to track it down in bugzilla. Someone kindly
refer me to the relevant bug report.

-- Bug in -O2 level with following code construct,

#define FTYPE float 

FTYPE fir_basic (FTYPE input, int ntaps, FTYPE h[],
FTYPE z[]);

for (ii = 0; ii < IMP_SIZE; ii++) {
 outputi = fir_basic(input[ii], NTAPS, h, z); 
 printf ("%08x, ",*((int *)(&outputi)));  
}

The floating point store to outputi occurs AFTER the
push of the arguments onto the stack for printf
occurs. Hence the printfs are shifted by one sample.
The bug goes away when I compile at -O1.

I can reproduce this error on gcc version 3.2.3
20030502 (Red Hat Linux 3.2.3-20) and powerpc-eabi-gcc
3.4.1. 

Any info will be appreciated, so that I can track this
bug.

thanks,
Vasanth




=
"..When all are one and one is all,
   To be a ROCK and not to Roll.."



__ 
Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250

Re: Question about GCC 3.4.1 -O2 Optimization bug (i386 and rs6000)

[Andrew Pinski]

On Feb 22, 2005, at 4:29 PM, Vasanth wrote:
Hi,
I am sure this bug has been reported before, but I am
not able to track it down in bugzilla. Someone kindly
refer me to the relevant bug report.
You are violating C90/C99 aliasing rules.
--Pinski

Re: Question about GCC 3.4.1 -O2 Optimization bug (i386 and rs6000)

[Vasanth]

Thanks for clearing up my mis-understanding !


--- Andrew Pinski <[EMAIL PROTECTED]> wrote:

> 
> On Feb 22, 2005, at 4:29 PM, Vasanth wrote:
> 
> > Hi,
> >
> > I am sure this bug has been reported before, but I
> am
> > not able to track it down in bugzilla. Someone
> kindly
> > refer me to the relevant bug report.
> 
> You are violating C90/C99 aliasing rules.
> 
> --Pinski
> 
> 


=
"..When all are one and one is all,
   To be a ROCK and not to Roll.."



__ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250

Re: MIPS code generation bug...

[David Daney]

Richard Sandiford wrote:
David Daney <[EMAIL PROTECTED]> writes:
I know you are a busy guy, but if you have a chance could you look at this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19683

'Fraid my spare-time MIPS stuff doesn't really extend to java.
Any chance of a C testcase?
Ask any you shall receive...
I present to you the MIPS-64bit-multiply-bug testcase written in C 
(attached to the PR).

The C test case only fails on 4.0.0.
As I said in the PR, I think the bug has been around at least since 3.3.1.
David Daney

Re: MIPS code generation bug...

[Richard Sandiford]

David Daney <[EMAIL PROTECTED]> writes:
> Richard Sandiford wrote:
>> David Daney <[EMAIL PROTECTED]> writes:
>>
>>>I know you are a busy guy, but if you have a chance could you look at this:
>>>
>>>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19683
>> 'Fraid my spare-time MIPS stuff doesn't really extend to java.
>> Any chance of a C testcase?
>
> Ask any you shall receive...
>
> I present to you the MIPS-64bit-multiply-bug testcase written in C
> (attached to the PR).

Great, thanks ;)  And sorry for dawdling so long on this issue.
I've been meaning to try the java testcase for the last few weeks
or so but just haven't found the time.  Hopefully I'll get to it
in the next week...

Richard

Re: MIPS code generation bug...

[Eric Christopher]

On Tue, 2005-02-22 at 14:25 -0800, David Daney wrote:
> Richard Sandiford wrote:
> > David Daney <[EMAIL PROTECTED]> writes:
> > 
> >>I know you are a busy guy, but if you have a chance could you look at this:
> >>
> >>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19683
> > 
> > 
> > 'Fraid my spare-time MIPS stuff doesn't really extend to java.
> > Any chance of a C testcase?
> 
> Ask any you shall receive...
> 
> I present to you the MIPS-64bit-multiply-bug testcase written in C 
> (attached to the PR).
> 
> The C test case only fails on 4.0.0.

Man that's ugly.

Richard, were you going to look into this?

-eric

Re: Can gfortran compile fftw3?

[Andrew Pinski]

Redirecting it gcc@ since that is where this part should be taken.
On Feb 22, 2005, at 5:32 PM, Steven G. Johnson wrote:
PS. A separate question, of course, is whether gcc 4.0's C compiler 
works with FFTW.  The answer, at the moment, is "no" if you try to use 
SSE/SSE2, thanks to the usual gcc bugs.  I'm trying to isolate and 
file bug reports for the problems, so hopefully the official release 
will work.
There has been rewrite of the SSE/SSE2 support.  Depending on how you 
write the
code, if you wrote it using the intrinsics then the bug is in GCC.

-- Pinski 

Re: RFC: objc_msgSend efficiency patch

[Richard Henderson]

On Mon, Feb 21, 2005 at 05:07:30PM -0800, Dale Johannesen wrote:
> -   r0 = gimplify_expr (&OBJ_TYPE_REF_OBJECT (*expr_p), pre_p, 
> post_p,
> +   /* Postincrements in OBJ_TYPE_REF_OBJECT don't affect the
> +  value of the OBJ_TYPE_REF, so force them to be emitted
> +  during subexpression evaluation rather than after the
> +  OBJ_TYPE_REF. This permits objc_msgSend calls in 
> Objective
> +  C to use direct rather than indirect calls when the
> +  object expression has a postincrement.  */
> +   r0 = gimplify_expr (&OBJ_TYPE_REF_OBJECT (*expr_p), pre_p, 
> NULL,
> is_gimple_val, fb_rvalue);
> r1 = gimplify_expr (&OBJ_TYPE_REF_EXPR (*expr_p), pre_p, 
> post_p,

It is not sufficient to change just the one expression and not the other.

> However, I'm not sure whether the comment is accurate for C++.   Can 
> somebody rule on that?  Thanks.

Eh.  Making the change *does* put the OBJ_TYPE_REF in the right
position for the call in c++, but that's irrelevant for -O0.
C++ only makes real use of OBJ_TYPE_REF with optimization on.

Indeed, this problem is unique to objc with -fnext-runtime.

I do think that it's safe to change, since we're talking about
rvalues in both cases.

I also think that it's a performance neutral change for C++,
since OBJ_TYPE_REF is mainly used for vtables, and calls force
the queue to be flushed beforehand.  Thus while processing the
OBJ_TYPE_REF, the incoming post_p should always be null, and
thus pushing the null down into the subexpressions results in
nearly the same code.  In the couple of examples that I tried,
we wound up with the same number of temporaries, for instance.


r~

Successful build of 3.4.3

[Stephen F. Booth]

I successfully built gcc-3.4.3 on SuSE Linux 9.2:

Here is the relevant information:

config.guess:
i686-pc-linux-gnu

gcc -v:
Reading specs from /opt/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/opt/gcc-3.4.3
Thread model: posix
gcc version 3.4.3

I enabled all the languages.

My distro is SuSE 9.2.

Kernel version:
Linux sbooth 2.6.8-24.11-smp #1 SMP Fri Jan 14 13:01:26 UTC 2005 i686 i686 
i386 GNU/Linux

rpm -q glibc:
glibc-2.3.3-118

Thanks for the outstanding compiler!

Stephen





pgpIPs9zFkWg0.pgp
Description: PGP signature

Re: warning: conflicting types for built-in function %qD

[Devang Patel]

Would it be OK, if this warnings are disabled for system headers ?
Thanks,
-
Devang
--- c-decl.c.~1~2005-01-06 19:26:09.0 -0800
+++ c-decl.c2005-02-15 11:59:48.0 -0800
@@ -1169,11 +1169,15 @@ diagnose_mismatched_decls (tree newdecl,
*oldtypep = oldtype = trytype;
  else
{
- /* If types don't match for a built-in, throw away the
-built-in.  No point in calling locate_old_decl here, it
-won't print anything.  */
- warning ("%Jconflicting types for built-in function %qD",
-  newdecl, newdecl);
+ if (!DECL_IN_SYSTEM_HEADER (newdecl))
+   {
+ /* If types don't match for a built-in, throw away
+the built-in.  No point in calling
+locate_old_decl here, it won't print
+anything.  */
+ warning ("%Jconflicting types for built-in function 
%qD",
+  newdecl, newdecl);
+   }
  return false;
}
}

Re: warning: conflicting types for built-in function %qD

[Joseph S. Myers]

On Tue, 22 Feb 2005, Devang Patel wrote:

> Would it be OK, if this warnings are disabled for system headers ?

What is the built-in function involved and what (and why) is the different 
system header type?  Is this a case where a system reuses a nonstandard 
name GCC has built in for an entirely different purpose?

We already are meant to have some laxity in matching the types of built-in 
functions to those of system header declarations (to allow both for 
pre-ISO-C systems and for not knowing within GCC what type FILE is).

Disabling this warning for system headers may well make sense - but it 
would lead to users getting / not getting the built-in according to 
whether the particular translation unit happened to include that header, 
so I'd like to understand the actual problem.

I think the fact that a warning is disabled in a system header is testable 
in the gcc.dg testsuite: have a .c file include a .h file, the .h file 
containing the offending declaration after #pragma GCC system_header.  
This test should fail before your patch and pass afterwards.  What you 
can't so readily test in such testcases is for diagnostics that are 
*meant* to appear in the system header, as DejaGnu seems only to look at 
dg-error/dg-warning annotations in the main file and interprets all line 
numbers in diagnostics as referring to the main file without regard to the 
file named in the diagnostic.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Problem in X Windows programming

[bedabrata.chatterjee]

 
HI All,

I am new to X-Windows programming and can't get my program to
work. The program compiles successfully but there is problem in the
linking part. Do we do it like other C Prog ie, gcc -o myprog myprog.c
or do we have to use some other options.

Can someone guide me with a demo prog and the way how I should compile
and link my file and which compiler option should I use.

Thanks in advance.

BBC

a mudflap experiment on freebsd

[James E Wilson]

A customer expressed interest in mudflap, so I tried to see if I could
use it compile something large.  I used gcc itself for this test.  I've
attached my notes, and the patches I wrote as part of this.  I will
probably be able to generate a couple of bug reports and/or patches out
of this.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

On an x86 FreeBSD 4.7 system, I built and installed mainline gcc, and then
tried to use this compiler to configure with a CFLAGS of "-O2 -g -fmudflap" and
then bootstrap.  What follows is a list of issues I ran into while trying to
get this to work.

Configure dies with the complaint that the C compiler doesn't work.  The
problem here is that -fmudflap does not imply -lmudflap.  This is different
from how other profiling options like -pg work.  Unfortunately, there are
so many different places that link in so many different ways that there is no
way to make this work unless gcc supplies the -lmudflap itself.  I modified
MFLIB_SPEC in gcc.c to include -lmudflap.  I think the decision to force the
user to specify -lmudflap should be revisited.  If the user needs to specify
-lmudflap manually, then there are multiple ways to disable default linker
options.  But if the user needs gcc to do this automatically, there is no way
to work around this if gcc does not.

The fixincludes build failed with link errors for undefined mudflap
functions.  The fixincludes Makefile.in does not use CFLAGS when linking.  I
added $(CFLAGS) to the 3 rules that contain a link command.

I now get a configure failure in the intl directory.  configure is unable
to run programs compiled by $CC.  I gets an error from the dynamic linker
complaining that libgcc.so can't be found.  The problem here is that the
toplevel Makefile support for LD_LIBRARY_PATH is confused.  See the
SET_GCC_LIB_PATH support.  We set LD_LIBRARY_PATH to point to the gcc we are
building, to ensure that we use the new libgcc.so library.  Unfortunately, we
do this before gcc has been built, and use it for host tools built by $CC.  It
should only be used for target libraries built by $CC_FOR_TARGET.  Since I
have a $CC that requires my own LD_LIBRARY_PATH setting, this breaks anything
built by $CC.  There are also redundancies in the code.  We are setting
LD_LIBRARY_PATH to the same value multiple times.  I hacked HOST_EXPORTS to
include both the $CC and $CC_FOR_TARGET library directories.

I had modify the gcc Makefile to include -fmudflap in BOOT_CFLAGS.  Hmm,
maybe putting -fmudflap in CFLAGS was the wrong approach.  Maybe I should
have put it in CC.  Oh well, I don't feel like restarting.

gengtype generates many fopen/fread/fwrite/fclose violations.  The problem
here is that mudflap isn't registering the memory allocated by fopen.  I didn't
check the FreeBSD libraries to see why.  I just hacked mf-hooks2.c in
libmudflap to define MF_REGISTER_fopen to __MF_TYPE_STATIC.  It is nice that
mudflap has a define for this, though it would be even nicer if there was
configure support to enable it conditionally for targets that need it.

A real bug.  In gengtype.c, we have
note_flds->opt->info = note_insn_name[c];
where c ranges from 0 to NOTE_INSN_MAX, but the array note_insn_name has only
NOTE_INSN_MAX elements.  We must make the array one element larger.

Looking at this mudflap error report, I noticed that the PC values printed
are all inside the libmudflap library, which makes them fairly useless.  It
should be the PC in the program where the error occured.  Looking at the
mf-runtime.c file, I see that mfu_check uses builtin_return_address to get
the address of the caller.  However, it is always called from mf_check, and
thus the address reported is always an address inside the libmudflap library.
Similarly for mfu_register and mf_register.  It looks like someone added an
additional level of function calls for thread support, without realizing that
this broke the PC error message reporting.

gengtype now dies with a recursive call in malloc.  The problem here is
that we call the mudflap malloc, which calls the real malloc, which calls the
mudflap mmap which then calls malloc to register the new pages.  And now we
have a recursive malloc call.  This does not appear to happen on linux.  The
real malloc apparently calls the real mmap instead of the mudflap mmap.
Perhaps due to a difference in shared library construction.  I haven't checked.
Even if the system malloc wasn't complaining here, we would also have the
problem that we are registering the same bit of memory twice, once in the
malloc call and once in the mmap call.  I hacked around this by adding a static
variable in_malloc, which is set to true when calling the real malloc/realloc
routine.  Then, when in mmap, I don't register the pages if in_malloc is true.
Also, there is the same issue for free and munmap when unregistering the
pages.

Now the build gets all of the way to genattrtab, which dies with an out
of memory error after generating 4753 mudflap v

Re: Problem in X Windows programming

[Joe Buck]

On Wed, Feb 23, 2005 at 09:45:52AM +0530, [EMAIL PROTECTED] wrote:
>   I am new to X-Windows programming and can't get my program to
> work.

You are on the wrong list.  This is the developer's list for the compiler
itself; it is not a place for beginning programmers to ask for help.