The subreg question

[Ling-hua Tseng]

I have a chip which is developed by other lab.
It's VLIW architecture and it contains 2 RISCs and 8 DSPs.
The size of all registers are 32 bits.
There is a special instruction in the RISC which is called `movi' (move 
immediate).
Its syntax and semantic are:
movilr1, #   (moves # to LSB 16-bit, without changes MSB 
16-bit)
movils   r1, #   (moves # to LSB 16-bit, and sets the MSB 16-bit 
to zero)
movim  r1, #   (moves # to MSB 16-bit, without changes LSB 16-bit)
movims r1, #   (moves # to MSB 16-bit, and sets the LSB 16-bit to 
zero)
It's obvious that `movil' and `movim' are only access the partial 16-bit of the 
32-bit register.
How can I use RTL expression to represent the operations?
(I should implement the standard pattern `movsi'  in the machine description,
and I tried to design an define_split to generate a 32-bit immediate value)
It's the define_split RTX in the machine description:
(define_split
 [(set (match_operand:SI 0 "register_operand" "")   
   (match_operand:SI 1 "immediate_operand" ""))]
 "!valid_10bit_immediate(INTVAL(operands[1]))"
 
{
   
})

First, I tried to write the  in the following form:
 [(set (strict_low_part (subreg:HI (match_dup 0) 0)) (match_dup 2))
  (set (subreg:HI (match_dup 0) 2)) (match_dup 3))]   <--- (*1)
And I wrote the  in the following form:
   operands[2] = GEN_INT(INTVAL(operands[1]) & 0x);
   operands[3] = GEN_INT((INTVAL(operands[2]) & 0x) >> 16);  
... (*2)
The expression (*1) is in want of a RTX `(strict_high_part x)' but it's not 
existing.
So I just writing it without `strict' semantic.
But the subreg RTX is not accepted by the gcc.
The emit-rtl.c: validate_subreg( ) will return false at the line 692 (gcc 4.0 
20050416).
(BTW, the gen_highpart( ) is also failed when I trying to generate the MSB 
16-bit operand.)
After some studying, I know that the `subreg' RTX is only able to represent the 
LSB n-bit.
Instead, I wrote the following form to solve it temporarily:
 [(set (match_dup 0)
   (ior:SI (match_dup 0) (match_dup 2)))
  (set (match_dup 0)
   (ior:SI (match_dup 0) (match_dup 3)))]
{
   operands[2] = GEN_INT(INTVAL(operands[1]) & 0x);
   operands[3] = GEN_INT(INTVAL(operands[1]) & 0x);
})
Unfortunately, I need to face this problem eventually.
The DSP function unit provides `packing' and SIMD operations.
We can pack four 8-bit integer values into one 32-bit register,
and then do an arithmetic operation by one instruction.
So I need to treat one 32-bit register as four 8-bit sub-registers.
But I couldn't represent them by:
   (subreg:QI (reg:SI xx) 0), (subreg:QI (reg:SI xx) 1), (subreg:QI (reg:SI xx) 
2), and (subreg:QI (reg:SI xx) 3).
Would anyone teach me how to use RTL expression to represent these 
sub-registers?
Thanks a lot.

Re: Cross Compile PowerPC for ReactOS

[James Tabor]

James Tabor wrote:
Hi!
I started resurrecting PowerPC WinNT GCC support, Ha! I'm running into 
this atm.

/home/gcc-3.4.3-ros/CROSS/gcc/xgcc -B/home/gcc-3.4.3-ros/CROSS/gcc/ 
-B/usr/powerpcle-pe/bin/ -B/usr/powerpcle-pe/lib/ -isystem 
/usr/powerpcle-pe/include -isystem /usr/powerpcle-pe/sys-include -O2  
-DIN_GCC -DCROSS_COMPILE  -D__CYGWIN__ -W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  
-isystem ./include   -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED 
-Dinhibit_libc -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include 
-DFINE_GRAINED_LIBRARIES -fPIC -DL_pack_sf -c fp-bit.c -o 
libgcc/./_pack_sf.o

/home/gcc-3.4.3-ros/CROSS/gcc/xgcc -B/home/gcc-3.4.3-ros/CROSS/gcc/ 
-B/usr/powerpcle-pe/bin/ -B/usr/powerpcle-pe/lib/ -isystem 
/usr/powerpcle-pe/include -isystem /usr/powerpcle-pe/sys-include -O2  
-DIN_GCC -DCROSS_COMPILE  -D__CYGWIN__ -W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  
-isystem ./include   -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED 
-Dinhibit_libc -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include 
-DFINE_GRAINED_LIBRARIES -fPIC -DL_unpack_sf -c fp-bit.c -o 
libgcc/./_unpack_sf.o

/home/gcc-3.4.3-ros/CROSS/gcc/xgcc -B/home/gcc-3.4.3-ros/CROSS/gcc/ 
-B/usr/powerpcle-pe/bin/ -B/usr/powerpcle-pe/lib/ -isystem 
/usr/powerpcle-pe/include -isystem /usr/powerpcle-pe/sys-include -O2  
-DIN_GCC -DCROSS_COMPILE  -D__CYGWIN__ -W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  
-isystem ./include   -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED 
-Dinhibit_libc -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include 
-DFINE_GRAINED_LIBRARIES -fPIC -DL_addsub_sf -c fp-bit.c -o 
libgcc/./_addsub_sf.o
fp-bit.c: In function `__addsf3':
fp-bit.c:744: error: unrecognizable insn:
(call_insn:HI 53 49 59 0 fp-bit.c:743 (parallel [
(set (reg:SF 33 1)
(call (mem:SI (symbol_ref:SI ("__pack_f") [flags 0x41] 
) [0 S4 A32])
(const_int 0 [0x0])))
(use (const_int 0 [0x0]))
(clobber (scratch:SI))
]) -1 (insn_list 46 (nil))
(expr_list:REG_DEAD (reg:SI 3 3 [ res ])
(expr_list:REG_UNUSED (scratch:SI)
(nil)))
(expr_list (use (reg:SI 3 3 [ res ]))
(nil)))
fp-bit.c:744: internal compiler error: in extract_insn, at recog.c:2083

As it looks, I've managed (Hacked) to make it through libgcc2.c and now 
in fp-bit.c. Can anyone
give me a good guess how to fix this.

Thanks,
James

I've managed to get this far, any ideas would help. Also thanks to everyone who emailed me and 
pointing out ideas!

/home/gcc-3.4.3-ros/CROSS/gcc/xgcc -B/home/gcc-3.4.3-ros/CROSS/gcc/ -B/usr/powerpcle-pe/bin/ 
-B/usr/powerpcle-pe/lib/ -isystem /usr/powerpcle-pe/include -isystem /usr/powerpcle-pe/sys-include 
-O2  -DIN_GCC -DCROSS_COMPILE  -D__CYGWIN__ -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g  -DIN_LIBGCC2 
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include 
-DFINE_GRAINED_LIBRARIES -DL_usi_to_sf -c fp-bit.c -o libgcc/./_usi_to_sf.o
/home/gcc-3.4.3-ros/CROSS/gcc/xgcc -B/home/gcc-3.4.3-ros/CROSS/gcc/ -B/usr/powerpcle-pe/bin/ 
-B/usr/powerpcle-pe/lib/ -isystem /usr/powerpcle-pe/include -isystem /usr/powerpcle-pe/sys-include 
-O2  -DIN_GCC -DCROSS_COMPILE  -D__CYGWIN__ -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g  -DIN_LIBGCC2 
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include 
-DFINE_GRAINED_LIBRARIES -DL_pack_df -c dp-bit.c -o libgcc/./_pack_df.o
dp-bit.c: In function `__pack_d':
dp-bit.c:436: error: unrecognizable insn:
(call_insn/u:HI 158 157 159 10 dp-bit.c:265 (parallel [
(set (reg:DI 3 3)
(call (mem:SI (symbol_ref:SI ("__ashldi3") [flags 0x41]) [0 S4 A32])
(const_int 0 [0x0])))
(use (const_int 0 [0x0]))
(clobber (scratch:SI))
]) -1 (insn_list 156 (insn_list 157 (nil)))
(insn_list:REG_RETVAL 156 (expr_list:REG_DEAD (reg:SI 5 5 [ shift ])
(expr_list:REG_UNUSED (scratch:SI)
(expr_list:REG_EH_REGION (const_int -1 [0x])
(nil)
(expr_list (use (reg:SI 5 5 [ shift ]))
(expr_list (use (reg:DI 3 3))
(nil
dp-bit.c:436: internal compiler error: in extract_insn, at recog.c:2083

Thanks,
James
ps.
I'm an ReactOS developer btw, this powerpc port will be part of the project, so 
please help.

Re: Problem with weak_alias and strong_alias in gcc-4.1.0 with MIPS...

[Giovanni Bajo]

Steven J. Hill <[EMAIL PROTECTED]> wrote:

> ../sysdeps/ieee754/dbl-64/s_isinf.c:29: error: 'isinf' aliased to
> undefined symbol '__isinf'
> ../sysdeps/ieee754/dbl-64/s_isinf.c:31: error: '__isinfl' aliased
> to undefined symbol '__isinf'
> ../sysdeps/ieee754/dbl-64/s_isinf.c:32: error: 'isinfl' aliased to
> undefined symbol '__isinf'
>
> I am attempting to try and figure out what changed so drastically to
> cause this. I also looked in GCC and glibc Bugzilla databases, but did
> not find anything addressing this problem. Has anyone seen this
> behavior? Thanks.

http://gcc.gnu.org/gcc-4.0/changes.html

Quote:
Given __attribute__((alias("target"))) it is now an error if target is not a
symbol, defined in the same translation unit. This also applies to aliases
created by #pragma weak alias=target. This is because it's meaningless to
define an alias to an undefined symbol. On Solaris, the native assembler would
have caught this error, but GNU as does not.

Giovanni Bajo

Re: How to -Werror in a fortran testcase?

[Paul Brook]

On Saturday 16 April 2005 19:32, Richard Guenther wrote:
> Hi!
>
> gfortran does not support -Werror it seems.

It should, this is a bug.

> What do I need to put in dg-options to make a testcase fail, if there is
> any warning?

Doesn't dejagnu do this anyway? Ie. any unexpected errors or warnings will 
cause the test to fail.

Paul

Re: The subreg question

[Björn Haase]

Hi,

I have been working on very similar issues for the avr target. You might have 
a look at the patch I have posted today and the corresponding discussion 
thread at the gcc-patches list. 

I have also observed, that gen_highpart and gen_lowpart sometimes causes an 
ICE for reasons. ... did not figure out so far why. I'd like to suggest that 
a pattern that might help you is simply

(set (subreg:HI (match_dup 0) 0) (match_dup 2)
(set (subreg:HI (match_dup 0) 2) (match_dup 3)

with the preparation statements

int full_value = INTVAL( operands[1]);
int lsw_value = full_value & 0x;
if (lsw_value & 0x8000)
  lsw_value -= 0x0001; 
// lsw_value must be in the range of -32768 ... 32767!

int msw_value = (full_value >> 16) & 0x;
if (msw_value & 0x8000)
  msw_value -= 0x0001;
// msw_value must be in the range of -32768 ... 32767!
 
operands[2] = GEN_INT(lsw_value);
operands[3] = GEN_INT(msw_value);

.
Be aware that your immediate operand might be a label reference so that INTVAL 
will fail on it since it is not known at compile time. The only workaround I 
have found so far for treating this case of label reference immediates is: do 
not to split the instruction but to keep the unsplittet insn until 
instruction emission.

You also probably will whish to handle the cases explitly that either 
msw_value or lsw_value happen to be zero so that you will not use the 
standard template but emit the RTL by yourself (for examples you might look 
at my patch for AVR).

Yours,

Björn

Re: My opinions on tree-level and RTL-level optimization

[Björn Haase]

Hi,

while lacking the deep insight into GCC internals most of you have, I'd never 
the less like to ask you to be very prudent concerning the issue of removal 
of seemingly unnecessary RTL optimizations.
In contrast to 32 bit targets, for 8 and 16 bit targets the RTL representation 
possibly might look completely different than the corresponding tree 
representation of the code: 
In my opinion, now that the new tree optimizations exist, it might finally be 
a good approach to let all the optimizations that could be done on original 
DI/SI/HI mode expressions be done on the tree level already. Then one could 
expand the DI/SI/HI mode expressions at RTL generation to only refer to the 
processor's native word length modes. What one would get then is a RTL which 
has about nothing to do with the corresponding tree representation.

For 8/16 bit target and gcc3 it seems that it used to be necessary to do the 
expansion/splitting extremely late since optimizations on SI/HI mode 
expressions required to keep SI/HI mode objects at least until reload. Now 
hopefully one could consider to do the splitting much earlier and with the 
help of the existing RTL optimizers one might be able to find many additional 
optimization possibilities. 

I think that it would be a pity if one could no longer find these 
optimizations because the corresponding RTL optimizers have been removed.

Yours,

Björn

Re: Heads-up: volatile and C++

[Jason Merrill]

On Thu, 14 Apr 2005 23:11:03 -0400, Diego Novillo <[EMAIL PROTECTED]> wrote:

> Again, not always.  Consider chaotic asynchronous algorithms
> (like variations of simulated annealing).  They need no locks nor
> any other kind of synchronization, though sometimes they'll use
> some form of control synchronization to delimit phases.
>
> When implementing them in a shared-memory multithreaded
> environment, they typically mark shared data as 'volatile' to
> prevent the compiler from optimizing those references away.

The properties of asynchronous algorithms are independent of memory model;
even asynchronous algorithms expect to get updates from other threads all
at once.  If one thread writes out a new data set and another thread reads
in an arbitrary subset of it, thinking it is the complete set, the
algorithm will break.  With a weak memory model, some sort of explicit
memory ordering is necessary to ensure that all writes to that area are
visible before reads begin.

I believe that the current standard volatile semantics mean that if you
mark all shared data as volatile, you enforce sequential access to all
shared data, which will accomplish the necessary ordering but is stronger
than you need.  With the proposal only the last write and first read from
the data need to be volatile, and the compiler and machine have more
freedom to reorder the other accesses.

I also believe that current compilers don't actually implement my
interpretation of current semantics on most targets, and as a result
marking the shared data as 'volatile' does not accomplish the necessary
memory ordering, and the algorithm is likely to break without memory
barrier asms.  I think that with most compilers 'volatile' restricts
reordering by the compiler, but not by the hardware, and so code that
relies on 'volatile' alone will break on targets with a weak memory model.

You seem to be conflating synchronization (via locks or otherwise) with
explicit memory ordering; they are not the same.  Synchronization involves
threads waiting for each other to catch up; this proposal just means that
at a release point all pending memory accesses are visible before a
volatile write, and a volatile read happens before all subsequent memory
accesses.  This is strictly a thread-local property, and does not imply any
waiting on another thread.

I suppose using the terms 'acquire' and 'release' mislead people to think
about locks, when no locks or other synchronization are implied.  Some sort
of coherent memory ordering is necessary for synchronization, but it is
also necessary for asynchronous algorithms.

> Right, but it would take away the traditional semantics of volatile.  Why
> not use some new language construct (monitors, set/wait) or even
> templates to implement synchronization?

Yes, actual synchronization is properly implemented by a library.

> That's the only thing that I find disturbing about the proposal.
> Overloading a very well established keyword with a new meaning.
> I don't think it's going to be well received, that's all.

Because it's very close to the current semantics, which IMO already impose
ordering on volatile accesses (though compilers don't enforce that).  The
change is to define how volatile accesses are ordered relative to
non-volatile accesses.

I don't think it's a large conceptual change.  A naive implementation would
result in more overhead, but we should be able to optimize most of it away.

> http://www.cs.ualberta.ca/~jonathan/Grad/Papers/aphidiee.ps
> http://web.nchu.edu.tw/~jlu/research/papers/asynch.ps
>
> Note that the initial motivation for many of these techniques was to
> yield good results on distributed systems.  But if you were to implement
> them in a multithreaded environment with shared data instead of message
> passing, they'd declare the shared data volatile.

Again, I don't think this is enough with current compilers and hardware.
And with the proposal only the flag which indicates that a new data set is
ready would need to be volatile.

Jason

Re: My opinions on tree-level and RTL-level optimization

[Daniel Jacobowitz]

On Sun, Apr 17, 2005 at 03:19:43PM +0200, Björn Haase wrote:
> Hi,
> 
> while lacking the deep insight into GCC internals most of you have, I'd never 
> the less like to ask you to be very prudent concerning the issue of removal 
> of seemingly unnecessary RTL optimizations.
> In contrast to 32 bit targets, for 8 and 16 bit targets the RTL 
> representation 
> possibly might look completely different than the corresponding tree 
> representation of the code: 
> In my opinion, now that the new tree optimizations exist, it might finally be 
> a good approach to let all the optimizations that could be done on original 
> DI/SI/HI mode expressions be done on the tree level already. Then one could 
> expand the DI/SI/HI mode expressions at RTL generation to only refer to the 
> processor's native word length modes. What one would get then is a RTL which 
> has about nothing to do with the corresponding tree representation.
> 
> For 8/16 bit target and gcc3 it seems that it used to be necessary to do the 
> expansion/splitting extremely late since optimizations on SI/HI mode 
> expressions required to keep SI/HI mode objects at least until reload. Now 
> hopefully one could consider to do the splitting much earlier and with the 
> help of the existing RTL optimizers one might be able to find many additional 
> optimization possibilities. 

This does not conflict with removing RTL optimizers.  Right now, the
most natural time to do this sort of lowering is at expand; but there's
no fundamental reason why it could not be done on trees, just before
expand, and rerun relevant tree optimizers after doing so.  Same as the
issues for "long long" splitting that Roger mentioned.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: GCC 4.0 RC2 Status

[Eric Botcazou]

> I'm not going to wait very long even for this bug, though.  Instead, I'm
> going to get 4.0.0 out the door, and move on to 4.0.1, sticking as close
> to the announced schedule as possible.

FWIW the recent Java failures have been fixed (thanks to the Java hackers!) on 
SPARC, so the 4.0.0pre compiler is now regression-free for all languages on 
sparc-sun-solaris2.9 (as well as sparc64-sun-solaris2.9).

-- 
Eric Botcazou

Re: My opinions on tree-level and RTL-level optimization

[Björn Haase]

Am Sonntag, 17. April 2005 16:26 schrieb Daniel Jacobowitz:
> On Sun, Apr 17, 2005 at 03:19:43PM +0200, Björn Haase wrote:
> > Hi,
> >
> > while lacking the deep insight into GCC internals most of you have, I'd
> > never the less like to ask you to be very prudent concerning the issue of
> > removal of seemingly unnecessary RTL optimizations.
> > In contrast to 32 bit targets, for 8 and 16 bit targets the RTL
> > representation possibly might look completely different than the
> > corresponding tree representation of the code:
> > In my opinion, now that the new tree optimizations exist, it might
> > finally be a good approach to let all the optimizations that could be
> > done on original DI/SI/HI mode expressions be done on the tree level
> > already. Then one could expand the DI/SI/HI mode expressions at RTL
> > generation to only refer to the processor's native word length modes.
> > What one would get then is a RTL which has about nothing to do with the
> > corresponding tree representation.
>
> This does not conflict with removing RTL optimizers.  Right now, the
> most natural time to do this sort of lowering is at expand; but there's
> no fundamental reason why it could not be done on trees, just before
> expand, and rerun relevant tree optimizers after doing so.  Same as the
> issues for "long long" splitting that Roger mentioned.
I agree that this would be also a solution and one would probably do it this 
way if one rewrote gcc from scratch. Only drawback that I see is, that this 
way someone who wishes to write a new back-end would then be required to 
learn *two* intermediate representations simultaneously. (As a bloody 
beginner, I'd like to say that even understanding how to work with RTL 
sometimes is not *really* intuitive :-) ...) 

\begin{offtopic}
BTW. You have mentioned the possibility to re-run a couple of optimization 
passes later on. 

I am presently facing a situation (AVR) where condition code issues force us 
to continuing to split a couple of patterns only after reload and I think 
that it would be helpful to re-run some passes after having done the 
splitting. E.g. I am having sequences like

(set (subreg:QI (reg:HI 12) 0) (__some_memory_reference__))
(set (subreg:QI (reg:HI 12) 1) (const_int 0))
(set (subreg:QI (reg:HI 20) 0) (ior:QI (subreg:QI (reg:HI 20) 0) (subreg:QI 
(reg:HI 12) 0)))
(set (subreg:QI (reg:HI 20) 1) (ior:QI (subreg:QI (reg:HI 20) 1) (subreg:QI 
(reg:HI 12) 1)))

steming, e.g., from an ior of a zero-extended QI value in r12:r13 with a HI 
value in r20:r21. While I see that it is hopless to tell GCC after reload 
that it could have avoided allocating r13, I at least have the hope that the 
second or-operation (on r13 and r21) and the storing of 0 into r13 could be 
optimized away if a pass is re-run that is usually executed *before* reload 
only.

I'd appreciate any hint on which place in the mid-end (i.e. which source file) 
I might want to look at ...
\end{offtopic}

Yours,

Björn

re: Problem with weak_alias and strong_alias in gcc-4.1.0 with MIPS...

[Daniel Kegel]

"Steven J. Hill" <[EMAIL PROTECTED]> wrote:
I have a working MIPS cross toolchain with:
   binutils-2.15
   gcc-3.4.2
   glibc-2.3.4
   linux-2.6.12
and then decided to work with gcc-4.1.0 out of the cvs head. I am now
getting build problems with glibc-2.3.4 with the first major snafu
being:
../sysdeps/ieee754/dbl-64/s_isinf.c:29: error: 'isinf' aliased to undefined 
symbol '__isinf'
../sysdeps/ieee754/dbl-64/s_isinf.c:31: error: '__isinfl' aliased to undefined 
symbol '__isinf'
../sysdeps/ieee754/dbl-64/s_isinf.c:32: error: 'isinfl' aliased to undefined 
symbol '__isinf'
I am attempting to try and figure out what changed so drastically to
cause this. I also looked in GCC and glibc Bugzilla databases, but did
not find anything addressing this problem. Has anyone seen this
behavior?
Yes.  As Giovanni pointed out, the move from gcc-3.4 to gcc-4.0
requires some changes.  I have backported the needed changes from cvs
to glibc-2.3.4, more or less, and will release the patches
with crosstool-0.32.  In the meantime, the particular problem
you're facing might be fixed by this patch from cvs:
Revision 1.71, Thu Mar 17 21:06:27 2005 UTC (3 weeks, 5 days ago) by roland
Branch: MAIN
CVS Tags: fedora-glibc-20050405T2114, fedora-glibc-20050401T1444, 
fedora-glibc-20050324T0715, fedora-glibc-20050319T1907, HEAD
Changes since 1.70: +11 -66 lines
Diff to previous 1.70 (colored)
2005-03-16  Richard Henderson  <[EMAIL PROTECTED]>
* include/libc-symbols.h (__hidden_proto): Remove bogus declaration
of internal.
(__hidden_def1, __hidden_dot_def1): Remove.
(__hidden_def2, __hidden_def3): Remove.
(__hidden_ver1): New.
(hidden_ver, hidden_def, hidden_weak): Use it.
(hidden_data_ver, hidden_data_ver, hidden_data_weak): Use non-data
version of the macro.
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/include/libc-symbols.h.diff?r1=1.70&r2=1.71&cvsroot=glibc
- Dan

Re: C++ ABI mismatch crashes

[Mike Hearn]

On Sat, 16 Apr 2005 21:30:55 -0700, Joe Buck wrote:
> Do we really promise somewhere that this will work?  I know that we warn
> in other places that it probably will not.

Yes, see the "Testing Multi-ABI binaries" section here:

http://gcc.gnu.org/onlinedocs/libstdc++/abi.html

> Yes, symbol versioning is present, and will avoid many problems, but there
> were also a couple of layout bugs in gcc 3.3 that were fixed in 3.4.
> These could cause code compiled by 3.3 to assume that fields of classes
> are at different positions than code compiled by 3.4.  Such cases are not
> common, but it is another way to get a crash.

Yes, but the case here is of a g++ 3.3 binary linked against the g++ 3.3
standard library failing to operate because of other C++ binaries linked
into the image elsewhere, even if they only interact via C ABIs.

There is definitely some kind of bug here, I'm sure of it. Question is,
what?

I'll continue investigations in a few days. If anybody can give me the
exact Itanium C++ spec revision numbers gcc 3.3 and 3.4 implement that'd
be handy.

thanks -mike

Re: internal compiler error at dwarf2out.c:8362

[Björn Haase]

James E Wilson wrote

>You shouldn't be trying to build your own types in a machine dependent 
>attribute handler function. The compiler's type system is determined by 
>front-ends mainly, and some middle-end infrastructure, and isn't your domain 
>to mess with. This stuff is subject to change, at which point your code may 
>break.

This seems to be a general issue for embedded targets. It's not only HC05 that 
would benefit of the feature to have different address spaces (e.g. 
eeprom/ram/rom) since these possibly need different asm instructions to be 
accessed. 
In case that one should not use machine specific atttributes, *is* there a 
standard way for GCC how to implement different address spaces?

Yours,

Björn

[RFC] warning: initialization discards qualifiers from pointer target type

[Devang Patel]

warning: initialization discards qualifiers from pointer target  
type

This warning can not be disabled using -Wno-cast-qual
(or any other warning flags). Is it intentional ?
Otherwise I'll prepare patch.
Thanks,
-
Devang
const char *a( void )
{
return "abc";
}
int main( void )
{
char *s = a();
return 0;
}

[RFC] warning: initialization discards qualifiers from pointer target type

[Paul Schlie]

> warning: initialization discards qualifiers from pointer target type
>
> This warning can not be disabled using -Wno-cast-qual
> (or any other warning flags). Is it intentional ?
> Otherwise I'll prepare patch.
>
> const char *a( void )
> {
>return "abc";
> }
>
> int main( void )
> {
>   char *s = a();
>return 0;
> }

Actually I'd like to think this is enforced as an "illegal" assignment.

(as it seem wrong to "discard pointer qualifiers" unless the assignment
 actually "copies" the literal string, which I don't believe it does;
 as any attempt to write to a const string literal should not be valid?)

Re: Vectorizing my loops. Some problems.

[Gerald Pfeifer]

On Sat, 16 Apr 2005, Øystein Johansen wrote:
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> make: *** [neuralnet.o] Error 1
> 
> Should I report this to the bug database or is this a known bug? And
> what is it and what can I do?
> 
> It's still gcc-4.1-20050313

Update to a current version/snapshot, since that one's already a month
old, and there have been many changes since then.

If the problem persists, please file a Bugzilla with detailed information
that will allow a developer to reproduce this (which include preprocessed
sources).

Thanks,
Gerald

gcc-4.1-20050417 is now available

[gccadmin]

Snapshot gcc-4.1-20050417 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050417/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.1 CVS branch
with the following options:  -D2005-04-17 17:43 UTC

You'll find:

gcc-4.1-20050417.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20050417.tar.bz2 C front end and core compiler

gcc-ada-4.1-20050417.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20050417.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20050417.tar.bz2  C++ front end and runtime

gcc-java-4.1-20050417.tar.bz2 Java front end and runtime

gcc-objc-4.1-20050417.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20050417.tar.bz2The GCC testsuite

Diffs from 4.1-20050410 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
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: How to -Werror in a fortran testcase?

[Mike Stump]

On Sunday, April 17, 2005, at 03:54  AM, Paul Brook wrote:
Doesn't dejagnu do this anyway? Ie. any unexpected errors or warnings 
will  cause the test to fail.
Yes, see ``excess''.

Re: Processor-specific code

[FX Coudert]

You'll find that globally changing the rounding mode will screw up
libm functions.  Which is pretty much going to make this useless.
OK. I didn't know that, and it's going to be annoying. So, the GNU libm 
doesn't enable us to call mathematical function with non-default 
rounding mode? IIUC, this is a requirement for the Fortran standard.

Further, when folks need rounding modes other than round-to-nearest,
they tend to need to switch rounding modes during the program too.
Yes. And we will need that too, and once the code for doing such things 
is written, we can employ it whenever we want to.

Thus I think an environment variable to do this is doubly useless.
Your point is good for GFORTRAN_FPU_ROUNDING. There are other variables, 
such as GFORTRAN_FPU_PRECISION, which I do not think is very isefull; 
others (GFORTRAN_FPU_UNDERFLOW, GFORTRAN_FPU_DIVIDE and such) control 
whether a FPE should be raised whenever we encounter an underflow, or a 
division by zero.

I only began to write such code because the current gfortran code 
actually reads those environnement variables, and does not act upon 
them. If we decide that some of those are useless, that's fine with me, 
but we need to remove then from the code. So, here, I'm mainly speaking 
to the gfortran gurus: what do you think of thoses variables (3 types of 
environment variables, for rouding mode, precision and controlling FPE). 
Which do you think we want to implement, and which do we remove?

All that said, C99 has  to control just about anything you
could want about the fpu.
No, you can't control FPEs or precision, for example. AFAIK, those need 
special functions (for i387-linux, e.g.) or assembly code (for ppc-darwin).

FX

Re: C++ ABI mismatch crashes

[Dan Kegel]

Mike Hearn <[EMAIL PROTECTED]> wrote:
I have a copy of Inkscape compiled with GCC 3.3, running on a GCC 3.4
based system. All of the C++ libraries it links directly against, like
GTKmm, are statically linked. In other words, it dynamically links
against no C++ libraries.
Inkscape dlopens libgtkspell, which in turn dlopens libaspell (to add
a spelling checker). libgtkspell is written in C, but libaspell is written
in C++ and exposes a C interface.
This causes a crash ...
Note that on the first line libaspell is being bound to libstdc++.so.6,
which is what I'd expect as libaspell is compiled using gcc 3.4 - and
indeed up until this point it's been linked only against libstdc++.so.6.
Then for some reason it's linked against libstdc++.so.5, for the following
symbol:
_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_S8_
[I'm going to regret posting in a hurry, but here goes:]
Hmm!  Quick question: if you rebuild libaspell (with the same
version of g++ as it was built before) to link in the C++ library statically,
does that fix the crash?
One possible conclusion we could draw might be
"Libraries that export only C APIs but
are written in C++ should be statically linked against
the C++ standard library.
Once the gcc C++ ABI stabilizes,
i.e. once all the remaining C++ ABI compliance bugs have
been flushed out of gcc, this requirement can be relaxed."
But I can't shake the feeling that it's crazy that libaspell
got linked against two different C++ libraries.  Can you
try creating a minimal test case demonstrating this
without involving inkscape?  If so, maybe it's a glibc
shared library loader bug?
- Dan
--
Trying to get a job as a c++ developer?  See 
http://kegel.com/academy/getting-hired.html

function name lookup within templates in gcc 4.1

[Gareth Pearce]

So I just started trying out gcc 4.1 - with a program which compiles and
runs fine on gcc 3.3.

Attached is a reduced testcase which shows runtime segfault due to stack
overflow if compiled with 4.1 but does not with 3.3.  Trivial work around is
to move the specific declaration above the template definition.  Now I see
potential for this to be 'the way the standard wants it to be', but given I
don't have a copy of the standard I am unsure.

Should I report this as a bug or is it a standards compliance improvement?

Regards,
Gareth Pearce
class sstring_t 
{
};

template 
int recurse(T blah)
{
   sstring_t x;
   return recurse(x);
}

int recurse(const sstring_t& blah)
{
}

int main()
{
   return recurse(1);
}

Re: GCC 4.0 Freeze

[Steve Kargl]

On Sat, Apr 16, 2005 at 11:37:14PM -0400, Jack Howarth wrote:
>Even if there were complete g77 compatibility in g95, folks may want
> to stick with the g77 version from gcc 3.4 for awhile purely for
> performance reasons. In doing some test runs of the APBS 
> Adaptive Poisson-Boltzmann Solver program, I discovered that the g95
> built binary runs 60% slower than the g77 built version. This was
> on MacOS X 10.3.8 using the version from Feb 24, 2005.

g95 is a different compiler.  Are you speaking about gfortran?

-- 
Steve

Re: function name lookup within templates in gcc 4.1

[Andrew Pinski]

On Apr 17, 2005, at 10:37 PM, Gareth Pearce wrote:
So I just started trying out gcc 4.1 - with a program which compiles 
and
runs fine on gcc 3.3.

Attached is a reduced testcase which shows runtime segfault due to 
stack
overflow if compiled with 4.1 but does not with 3.3.  Trivial work 
around is
to move the specific declaration above the template definition.  Now I 
see
potential for this to be 'the way the standard wants it to be', but 
given I
don't have a copy of the standard I am unsure.

Should I report this as a bug or is it a standards compliance 
improvement?
This is a standards compliance improvement as x is not dependent so the 
function
call to recurse has to be looked up of the available functions at 
decoration
time of the template function.
The easy way is to fix your code is to add:
int recurse(const sstring_t& blah);
before declaring the template version.

Thanks,
Andrew Pinski

Re: Processor-specific code

[Brooks Moses]

FX Coudert wrote:
[attribution lost]
> > You'll find that globally changing the rounding mode will screw up
> > libm functions.  Which is pretty much going to make this useless.
> 
> OK. I didn't know that, and it's going to be annoying. So, the GNU libm
> doesn't enable us to call mathematical function with non-default
> rounding mode? IIUC, this is a requirement for the Fortran standard.

I believe that you understand incorrectly.

Yes, the standard refers to changing the rounding mode "if the processor
supports [it]" -- but consider what the standard means by "processor":
"The combination of a computing system and the means by which programs
are transformed for use on that computing system is called a processor
in this standard." This very clearly includes the compiler, not just the
hardware.

Thus, the language in section 14.3 of the F2003 standard should be read
as placing requirements on how runtime alterations of the rounding mode
are to be supported _if_ gfortran chooses to support them, but should
not be read as placing requirements on whether gfortran must support
them at all.  It would be perfectly within the standard for gfortran to
leave the rounding mode in the default state, and define the
IEEE_SUPPORT_ROUNDING function to report "FALSE" for anything other than
the default rounding mode.

- Brooks


-- 
The "bmoses-nospam" address is valid; no unmunging needed.

empty switch substituion doesn't erase matching switch?

[Gary Funck]

This usage of a null substitution came up while I was trying to use
this form of spec. for a different switch, but the following illustrates
the problem using the existing gcc compiler as built for Redhat Linux
running on an SGI Altix:


Given a spec of this form,
 %{S:X}   substitutes X, if the -S switch was given to CC.

And a switch definition for -static:

/* %{static:} simply prevents an error message if the target machine
   doesn't handle -static.  */

And the resulting link command spec:

*link_command:
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:%(linker) %l %{pie:-pie} %X %{o*} 
%{A} %{d} %{e*} %{m} %{N} %{n} %{r}%{s} %{t}
%{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}}%{static:} %{L*} 
%(link_libgcc) %o
%{fprofile-arcs|fprofile-generate:-lgcov}
%{!nostdlib:%{!nodefaultlibs:%(link_gcc_c_sequence)}}
%{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}


% gcc --version
gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-34)

then the command "gcc -static t.c" ultimately yields the
following collect2 command:

/usr/lib/gcc-lib/ia64-redhat-linux/3.2.3/collect2 -static 
/usr/lib/gcc-lib/ia64-redhat-linux/3.2.3/../../../crt1.o
/usr/lib/gcc-lib/ia64-redhat-linux/3.2.3/../../../crti.o
/usr/lib/gcc-lib/ia64-redhat-linux/3.2.3/crtbegin.o 
-L/usr/lib/gcc-lib/ia64-redhat-linux/3.2.3 -L/usr/lib/gcc-lib/ia64-redhat-linux/
3.2.3/../../.. /tmp/ccc2ISqV.o --start-group -lgcc -lgcc_eh -lc --end-group 
/usr/lib/gcc-lib/ia64-redhat-linux/3.2.3/crtend.o
/usr/lib/gcc-lib/ia64-redhat-linux/3.2.3/../../../crtn.o

I haven't followed the logic in detail, but should the spec.
%{static:} above erase the explicit -static switch that was
passed to gcc?

RE: function name lookup within templates in gcc 4.1

[Gareth Pearce]

Thanks for the verification!

Regards,
Gareth Pearce

> 
> 
> On Apr 17, 2005, at 10:37 PM, Gareth Pearce wrote:
> 
> > So I just started trying out gcc 4.1 - with a program which compiles
> > and
> > runs fine on gcc 3.3.
> >
> > Attached is a reduced testcase which shows runtime segfault due to
> > stack
> > overflow if compiled with 4.1 but does not with 3.3.  Trivial work
> > around is
> > to move the specific declaration above the template definition.  Now I
> > see
> > potential for this to be 'the way the standard wants it to be', but
> > given I
> > don't have a copy of the standard I am unsure.
> >
> > Should I report this as a bug or is it a standards compliance
> > improvement?
> 
> This is a standards compliance improvement as x is not dependent so the
> function
> call to recurse has to be looked up of the available functions at
> decoration
> time of the template function.
> The easy way is to fix your code is to add:
> int recurse(const sstring_t& blah);
> before declaring the template version.
> 
> Thanks,
> Andrew Pinski

Re: empty switch substituion doesn't erase matching switch?

[Daniel Jacobowitz]

On Sun, Apr 17, 2005 at 07:48:53PM -0700, Gary Funck wrote:
> This usage of a null substitution came up while I was trying to use
> this form of spec. for a different switch, but the following illustrates
> the problem using the existing gcc compiler as built for Redhat Linux
> running on an SGI Altix:
> 
> 
> Given a spec of this form,
>  %{S:X}   substitutes X, if the -S switch was given to CC.
> 
> And a switch definition for -static:
> 
> /* %{static:} simply prevents an error message if the target machine
>doesn't handle -static.  */
> 
> And the resulting link command spec:
> 
> *link_command:
> %{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:%(linker) %l %{pie:-pie} %X 
> %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r}%{s} %{t}
> %{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}}%{static:} 
> %{L*} %(link_libgcc) %o
> %{fprofile-arcs|fprofile-generate:-lgcov}
> %{!nostdlib:%{!nodefaultlibs:%(link_gcc_c_sequence)}}
> %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}

Take a look at your %(link) in the same file.

> I haven't followed the logic in detail, but should the spec.
> %{static:} above erase the explicit -static switch that was
> passed to gcc?

No.  See the documentation in gcc/gcc.c for what you want:

 %

Re: GCC 4.0 RC1 Available

[Geoffrey Keating]

Andrew Haley <[EMAIL PROTECTED]> writes:

> Ranjit Mathew writes:
>  > Geoffrey Keating wrote:
>  > [...]
>  > > which I see you've already committed a patch for, and a large number
>  > > of Java failures.
>  > > 
>  > > You can see full test results at
>  > [...]
>  > > 
>  > > 
>  > > 
>  > > for 4.0.0-20050410.
>  > 
>  > It might be helpful to put your "libjava.log" somewhere
>  > or if all the Java failures seem similar, to post
>  > the error messages around the "FAIL" lines from your
>  > libjava.log.

> # of unexpected failures5

> powerpc-apple-darwin7.8.0
> dejagnu HEAD
> 
> So, this is unrepro, as far as I can see.

It seems like this could be the CLASSPATH issue; did you have gcj
installed on your system?  I didn't.

Re: Heads-up: volatile and C++

[Geoffrey Keating]

Jason Merrill <[EMAIL PROTECTED]> writes:

> On Thu, 14 Apr 2005 10:12:37 -0400, "Michael N. Moran" <[EMAIL PROTECTED]> 
> wrote:
> 
> > Jason Merrill wrote:
> >> The C++ committee (well, a subgroup represented at this meeting by Hans
> >> Boehm) is working on a memory model that supports threaded programs.
> >
> > As someone who uses the C++ language and multi-threading
> > extensively in embedded systems, I have come to the following
> > belief/opinion.
> >
> >The language (C++) *should not* have dependencies
> >upon threading. IMHO, threading is a layer above a
> >systems programming language, and having dependencies
> >upon upper layers is evil.
> 
> But the memory model for the language must provide semantics that make it
> possible for threaded programs to be written.  Currently, if you want to
> write a portable pthreads program you need to use a mutex around all uses
> of shared memory, because they are the only way to guarantee sequential
> memory ordering.  The volatile proposal provides a lighter-weight way to
> write portable code with explicit memory ordering.  You need this for
> lockless algorithms to work.
...
> It seems to me that the current specification of volatile already requires
> an lwsync around volatile reads and writes, to guarantee that all previous
> stores have been completed and later ones have not started.

The key question is "completed as seen by whom?"  At present, GCC
answers that question with "instructions on the same processor".  It
would certainly be possible, and useful, to have a (different) mode in
which the answer was "instructions on any processor, even with a
cache-unsynchronized memory map".  It'd be much harder to have a mode
where the answer was "anyone who can see the file system", since that
requires calling msync().

Re: Processor-specific code

[Geoffrey Keating]

Paul Koning <[EMAIL PROTECTED]> writes:

> > "Dave" == Dave Korn <[EMAIL PROTECTED]> writes:
> 
>  Dave> Original Message
>  >> From: Paul Koning Sent: 15 April 2005 17:56
> 
>  >>> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes:
>  >>
>  Dave> Doesn't the C language spec require the mode to be switchable
>  Dave> at runtime?
>  >>
>  Dave> In any case, the ARM or Alpha isn't prevented from working in
>  Dave> such a fashion just because the rounding mode is encoded in the
>  Dave> instruction; it just means that fp primitives have to be
>  Dave> compiled as intrinsics that test whatever flag controls the
>  Dave> rounding mode and then branch to an fp insn of the appropriate
>  Dave> form.
>  >> That only works if the notion of switchable rounding mode exists.
> 
>  Dave> I'm not sure.  Either you don't get me, or I don't get you, but
>  Dave> what I thought I was describing was a way of working around the
>  Dave> lack of a switchable mode by compiling the code both ways with
>  Dave> a runtime test of a flag.
> 
> Sorry, poor wording.  
> 
> What I meant is that those architectures do floating point in exactly
> one way.  You have NO way to say what kind of rounding you want, not
> by a settable state, not by a different opcode -- not at all.

Those architectures simply don't support other rounding modes; they
would define only FE_TONEAREST (or whatever rounding mode is suitable)
and compile fesetround() into a no-op.

Re: Processor-specific code

[Geoffrey Keating]

"Joseph S. Myers" <[EMAIL PROTECTED]> writes:

> On Thu, 14 Apr 2005, Richard Henderson wrote:
> 
> > On Thu, Apr 14, 2005 at 10:47:26AM -0700, Steve Kargl wrote:
> > > Does gcc support 
> > > #pragma STDC FENV_ACCESS
> > 
> > No, but we currently act like access is "on".
> 
> I thought we acted like it is "off", allowing CSE and constant folding 
> which might be affected by changes in rounding mode.  Certainly some of 
> Stephen Moshier's testcases (attached to bug 20785) fail.

The flag that controls this is -ftrapping-math, and it defaults to "on".

That said, though, there *are* bugs.  For instance, we currently take
code like:

(void) 0. / 1.;

and delete it as dead, even though it has side-effects.

Re: My opinions on tree-level and RTL-level optimization

[Roger Sayle]

On Sat, 16 Apr 2005, Richard Kenner wrote:
> Although, RTL expansion may introduce new loops, these tend to be
> rare, and the expanders have all the information they need to
> hoist/sink invariant expressions and unroll/peel themselves.
>
> I disagree.  In order to make the proper decisions about merging givs
> and chosing which giv should represent a biv, you have to know a lot
> about the valid addressing modes on the machine and this isn't something
> the tree level optimizers should have to deal with.
> ...
>
> Simiarly, CSE shouldn't need to process more than a single basic
> blocks,
>
> Again, not clear.  Certainly the costly stuff I put in ages ago to
> walk through comparisons and around loops needs to go, but there's
> no reason to tie CSE to a basic block: it can operate until the next
> label, like it does now.  Admittedly, the number of CSE opportunities
> won't be great, but why restrict them to a basic block?
>
> and GCSE shouldn't need to move anything other than simple
> expressions.
>
> Why would we need a GCSE at the RTL level at all?  I'd guess the number
> of wins it would produce would be very small.
>
> The quality of alias analysis at the RTL-level shouldn't be an issue.
>
> Here I disagree the strongest!  Instruction scheduling is rapidly
> becoming one of the most critical optimizations and must be done at
> the RTL level.  The quality of instruction scheduling depends quite
> heavily on the quality of the aliasing information.


Thanks for your feedback.  I agree with all your points.  I had
greatly underestimated the importance of RTL alias analysis, especially
with respect to scheduling.  The compile-time hog issues with CSE are
primarily due to deep path-following (AFAIU).  Simple/cheap tricks are
such as extended basic blocks are clearly a win, but their benefit depends
on whether we keep GCSE. If we don't then EBBs of course, if we do, the
EBBs are probably subsumed by GCSE.  And its very true at the RTL-level
addressing modes have always been an Achilles' heel.  But whilst
induction variable selection is very dependent upon target parameters,
as is prefetching, but it's not yet clear whether uglifying tree-ssa or
continuing to improve RTL loop analysis is the better long-term strategy.

I take it from your comments, that you are in the camp that believes
that "the sun has not yet set" on the need for RTL optimizers. :-)
The intent of my post was to defend what was seen as my pro-RTL
stance, it's interesting to see that the loudest feedback is that
I'm underestimating/down-playing the importance of the RTL optimizers.

Much appreciated,

Roger
--

Re: Processor-specific code

[François-Xavier Coudert]

I believe that you understand incorrectly.
Of course, you're right. We can choose not to support alteration of rounding 
mode, but we might want to add that nice feature into gfortran. So, I'll 
stop invoking the standard, but I still think it would be interesting. Of 
course, since noone seems to think that way, I won't bother you anymore with 
my FPU-related whims.

FX