Re: Heads-up: volatile and C++

[Gabriel Dos Reis]

Laurent GUERBY <[EMAIL PROTECTED]> writes:

| I'm including the standard annotations, they have no standard
| value but sometimes do help.

[...]

Thanks!

-- Gaby

Re: Heads-up: volatile and C++

[Gabriel Dos Reis]

Richard Henderson <[EMAIL PROTECTED]> writes:

| On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote:
| > Consider Double-Checked Locking
| > (http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html).
| > I used DCL with explicit memory barriers to implement thread-safe
| > initialization of function-local statics
| > (libstdc++-v3/libsupc++/guard.cc).  The proposed change to volatile
| > semantics would allow me to write it more simply, by just making the
| > initialized flag volatile.  Yes, volatile would be stronger than is
| > actually necessary for DCLP, but I don't have to use it if I want
| > finer-grained control over the synchronization.
| 
| Is there any reason to want to overload volatile for this, rather than
| 
|   template T acquire(T *ptr);
|   template void release(T *ptr, T val);
| 
| where the functions do the indirection plus the memory ordering?

My understanding what that some compilers may do "speculative register
promotion". 
(I think the example given by Hans actually involved lock()/unlock()
not acquire/release).

| The biggest problem that I see is that C and C++ have been around far
| too long, and there are far too many existing uses of "volatile" to be
| redefining it now.

That is a legitime concern that was raised.  I think examples of cases
that would be inadvertently affected would be very helpful.

-- Gaby

Re: Heads-up: volatile and C++

[Duncan Sands]

On Thu, 2005-04-14 at 23:33 +0200, Jason Merrill wrote:
> On Thu, 14 Apr 2005 15:47:44 -0500, Robert Dewar <[EMAIL PROTECTED]> wrote:
> > [Ada standard]
> 
> Yep, sounds a lot like C/C++: volatile reads and writes are required to
> have sequential ordering relative to each other, but (outside the current
> thread) they are not ordered relative to non-volatile reads and writes.

Here's an extract from section 9.10 ("sequential"):

15.a
Ramification: If two actions are ``sequential'' it is known that their 
executions
don't overlap in time, but it is not necessarily specified which occurs first. 
For
example, all actions of a single task are sequential, even though the exact 
order
of execution is not fully specified for all constructs. 
15.b
Discussion: Note that if two assignments to the same variable are sequential, 
but
neither signals the other, then the program is not erroneous, but it is not 
specified
which assignment ultimately prevails. Such a situation usually corresponds to a
programming mistake, but in some (rare) cases, the order makes no difference, 
and for
this reason this situation is not considered erroneous nor even a bounded 
error. In
Ada 83, this was considered an ``incorrect order dependence'' if the ``effect'' 
of the
program was affected, but ``effect'' was never fully defined. In Ada 95, this 
situation
represents a potential nonportability, and a friendly compiler might want to 
warn the
programmer about the situation, but it is not considered an error. An example 
where
this would come up would be in gathering statistics as part of referencing some
information, where the assignments associated with statistics gathering don't 
need to
be ordered since they are just accumulating aggregate counts, sums, products, 
etc.

Ciao,

Duncan.

some problem about cross-compile the gcc-2.95.3

[zouq]

first i download the release the version of gcc-2.95.3, binutils 2.15,
and i use the o32 lib, include of gcc3.3.3 .
1. compile the binutils and install it
mkdir binutils-build;
cd binutils-build;
../../binutils-2.15/configure --prefix=/opt/gcc --target=mipsel-linux -v;
make;make install;

2. cp -r ../../lib /opt/gcc/mipsel-linux/
   cp -r ../../include /opt/gcc/mipsel-linux/

3. compile the gcc
mkdir gcc-build;
cd gcc-build;
../../gcc-2.95.3/configure --prefix=/opt/gcc --target=mipsel-linux
--enable-languages=c -enable-shared -disable-checking -v;
make;

then the ERROR happened:
make[1]: Entering directory
`/home/mytask/mywork/WHAT_I_HAVE_DONE/mycompile/gcc-2.95.3-build/gcc/gcc'
(cd intl && make all)
make[2]: Entering directory
`/home/mytask/mywork/WHAT_I_HAVE_DONE/mycompile/gcc-2.95.3-build/gcc/gcc/intl'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory
`/home/mytask/mywork/WHAT_I_HAVE_DONE/mycompile/gcc-2.95.3-build/gcc/gcc/intl'
if [ -f libgcc2.ready ] ; then \
true; \
else \
touch libgcc2.ready; \
fi
rm -f tmplibgcc2.a
for name in _muldi3 _divdi3 _moddi3 _udivdi3 _umoddi3 _negdi2 _lshrdi3
_ashldi3 _ashrdi3 _ffsdi2 _udiv_w_sdiv _udivmoddi4 _cmpdi2 _ucmpdi2
_floatdidf _floatdisf _fixunsdfsi _fixunssfsi _fixunsdfdi _fixdfdi
_fixunssfdi _fixsfdi _fixxfdi _fixunsxfdi _floatdixf _fixunsxfsi _fixtfdi
_fixunstfdi _floatditf __gcc_bcmp _varargs __dummy _eprintf _bb _shtab
_clear_cache _trampoline __main _exit _ctors _pure; \
do \
  echo ${name}; \
  /home/mytask/mywork/WHAT_I_HAVE_DONE/mycompile/gcc-2.95.3-build/gcc/gcc/xgcc
-B/home/mytask/mywork/WHAT_I_HAVE_DONE/mycompile/gcc-2.95.3-build/gcc/gcc/
-B=/opt/gcc-2.95//mipsel-linux/bin/
-I=/opt/gcc-2.95//mipsel-linux/include  -DCROSS_COMPILE -DIN_GCC 
-I./include -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I/usr/include  
-I. -I../../../gcc-2.95.3/gcc -I../../../gcc-2.95.3/gcc/config
-I../../../gcc-2.95.3/gcc/../include -c -DL${name} \
   ../../../gcc-2.95.3/gcc/libgcc2.c -o ${name}.o; \
  if [ $? -eq 0 ] ; then true; else exit 1; fi; \
  mipsel-linux-ar rc tmplibgcc2.a ${name}.o; \
  rm -f ${name}.o; \
done
_muldi3
as: unrecognized option `-O2'
make[1]: *** [libgcc2.a] Error 1
make[1]: Leaving directory
`/home/mytask/mywork/WHAT_I_HAVE_DONE/mycompile/gcc-2.95.3-build/gcc/gcc'

i am very confused about the error.
is there something wrong with my Makefile?
the as should be mipsel-linux-as
is it?

Re: Processor-specific code

[François-Xavier Coudert]

[speaking of an environnement variable used to set IEEE rounding mode]
You'll find that globally changing the rounding mode will screw up
libm functions.  Which is pretty much going to make this useless.
Further, when folks need rounding modes other than round-to-nearest,
they tend to need to switch rounding modes during the program too.
For instance, to perform the same calculation with both round-up and
round-down to get error bounds on the calculation.
Thus I think an environment variable to do this is doubly useless.
Understood. I only tried to write that code because the mechanism for 
reading these environment variables is already in the source (as well as 
documentation on what effect they should have). Currently, when the runtime 
library is loaded, it look at:

GFORTRAN_FPU_ROUND: Set floating point rounding.  Values are NEAREST, UP, 
DOWN, ZERO.
GFORTRAN_FPU_PRECISION: Precision of intermediate results.  Values are 24, 
53 and 64.

GFORTRAN_FPU_INVALID: Raise a floating point exception on invalid FP operation.
GFORTRAN_FPU_DENORMAL: Raise a floating point exception when denormal 
numbers are encountered.
GFORTRAN_FPU_ZERO: Raise a floating point exception when dividing by zero.
GFORTRAN_FPU_OVERFLOW: Raise a floating point exception on overflow.
GFORTRAN_FPU_UNDERFLOW: Raise a floating point exception on underflow.
GFORTRAN_FPU_PRECISION: Raise a floating point exception on precision loss.

So, if we all agree that some of those are useless, we should remove them 
from the code. My humble opinion is:

  1. I don't think GFORTRAN_FPU_PRECISION is useful
  2. GFORTRAN_FPU_INVALID and all other FPE control options are very 
useful, and we want to implement those ones (this is really something one 
could want to turn on at runtime, perhaps just to debug one's code).
  3. GFORTRAN_FPU_ROUND: I have no precise idea (in the long term, we will 
provide subroutines so that the code can control rounding mode).


All that said, C99 has  to control just about anything you
could want about the fpu.
As the linux manpage for "The C99 standard does not define a way to set 
individual bits in the floating point mask, e.g. to trap on specific flags." 
So, unless I am mistaken, if you want to raise a FPE on dividing by zero, 
there is no C99 way to do it.

So I guess we will have to write some non-standard C at some point. Linux 
provide feenableexcept, but on darwin I don't know any way to do that 
without using assembly code. See Arnaud's link for a compilation of tricks 
people have used to do this.

FX

Re: Heads-up: volatile and C++

[Gabriel Dos Reis]

Gabriel Dos Reis <[EMAIL PROTECTED]> writes:

| Richard Henderson <[EMAIL PROTECTED]> writes:
| 
| | On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote:
| | > Consider Double-Checked Locking
| | > (http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html).
| | > I used DCL with explicit memory barriers to implement thread-safe
| | > initialization of function-local statics
| | > (libstdc++-v3/libsupc++/guard.cc).  The proposed change to volatile
| | > semantics would allow me to write it more simply, by just making the
| | > initialized flag volatile.  Yes, volatile would be stronger than is
| | > actually necessary for DCLP, but I don't have to use it if I want
| | > finer-grained control over the synchronization.
| | 
| | Is there any reason to want to overload volatile for this, rather than
| | 
| |   template T acquire(T *ptr);
| |   template void release(T *ptr, T val);
| | 
| | where the functions do the indirection plus the memory ordering?
| 
| My understanding what that some compilers may do "speculative register
| promotion". 
| (I think the example given by Hans actually involved lock()/unlock()
| not acquire/release).

Jason (seating next to me) just pointed out to me that "volatile" did
not appear in the example shown by Hans -- as I mistakenly thought.

So ignore my message.  Sorry for the confusion.

-- Gaby

Re: Heads-up: volatile and C++

[Jason Merrill]

On Thu, 14 Apr 2005 15:26:32 -0400, "Michael N. Moran" <[EMAIL PROTECTED]> 
wrote:

> Again, I understand the need for ordering/synchronization, I
> simply do not believe that volatile should be overloaded to
> include these semantics.
>
> Part of my point is that there are existing uses of volatile
> which whose performance would suffer should ordering and/or
> synchronization instructions be added around each access.
>
> For example, device drivers that perform memory mapped I/O
> on memory spaces which are "guarded" and thus need no additional
> ordering/synchronization instructions.

You mentioned PowerPC in a previous post; while device memory doesn't need
as much explicit ordering as cached memory,

 http://www-128.ibm.com/developerworks/eserver/articles/powerpc.html

says

 All these rules don't prevent stores to device memory from being issued
 out of program order with respect to loads from device memory, or vice
 versa. Instead, the memory-barrier instructions, eieio and sync, must be
 used when out of order operations could yield incorrect results.

you need an eieio between loads and stores, or between two loads, to ensure
proper ordering.  Yes, the proposed volatile semantics are more than you
need.  But you do need something.

That said, perhaps the current volatile semantics are a useful primitive
for building on with more specific explicit ordering, but that's not clear
to me.

Jason

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

[Alexandre Oliva]

On Apr 15, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:

> Richard Henderson wrote:
>> On Thu, Apr 14, 2005 at 05:26:15PM -0700, Mark Mitchell wrote:
>> 
>>> Richard, what's your level of confidence here?  I'd rather not
>>> break C++ or Java...
>> I think it's pretty safe.

> OK, Alexandre, please install the patch.

It's in.

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

Re: GCC 4.0 RC2

[Steven Bosscher]

On Thursday 14 April 2005 21:05, Mark Mitchell wrote:
> > Could you add http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01107.html
> > to your list?  If the patch is OKed by rth (ping! :-), it would fix a
> > -fPIC ICE regression on IA32 and AMD64.
>
> So added.  Will you please let me know if the patch is approved for
> mainline?

It was already rejected by rth.

Gr.
Steven

Re: Patches for coldfire v4e

[arcjai]

--- Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 14, 2005 at 09:36:59AM +0200, Bernardo
> Innocenti wrote:
> > Daniel Jacobowitz wrote:
> > > On Wed, Apr 13, 2005 at 10:10:39AM +0200,
> Bernardo Innocenti wrote:
> > >>
> > >>So it seems adding coldfire-linux is the only
> way
> > >>to address this...
> > > 
> > > Why?  Adding support (if it isn't already there)
> for something like
> > > --with-arch=coldfire should work just as well.
> > 
> > But how do we change behavior in
> gcc/config/t-linux
> > according to the switch?
> 
> You probably don't need to.  The newly built
> compiler will default to
> the right architecture; any assembly routines can be
> keyed off an
> appropriate builtin define.

Will there be any issues with binutils? Assembler
should also default to this architecture (coldfire).

These were the additions i had to make to t-linux for
coldfire

LIB1ASMSRC = m68k/lb1sf68.asm
LIB1ASMFUNCS = _mulsi3 _udivsi3 _divsi3 _umodsi3
_modsi3 \
   _double _float _floatex \
   _eqdf2 _nedf2 _gtdf2 _gedf2 _ltdf2 _ledf2 \
   _eqsf2 _nesf2 _gtsf2 _gesf2 _ltsf2 _lesf2

LIB2FUNCS_EXTRA = fpgnulib.c xfgnulib.c

fpgnulib.c: $(srcdir)/config/m68k/fpgnulib.c
cp $(srcdir)/config/m68k/fpgnulib.c fpgnulib.c
xfgnulib.c: $(srcdir)/config/m68k/fpgnulib.c
echo '#define EXTFLOAT' > xfgnulib.c
cat $(srcdir)/config/m68k/fpgnulib.c >>
xfgnulib.c

MULTILIB_OPTIONS = mcfv4e
EXTRA_MULTILIB_PARTS= crtbegin.o crtend.o crtbeginS.o
crtendS.o crtbeginT.o
EXTRA_MULTILIB_OPTIONS=-mcfv4e
LIBGCC = stmp-multilib
INSTALL_LIBGCC = install-multilib


Can these also be taken care of? LIB2FUNCS_EXTRA?
EXTRA_MULTILIB_PARTS? etc

Regards,
C  Jaiprakash



__ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/

Re: some problem about cross-compile the gcc-2.95.3

[Kai Ruottu]

On 15 Apr 2005 at 14:56, zouq wrote:

> first i download the release the version of gcc-2.95.3, binutils 2.15,

 This message should go to the crossgcc list... But it is nowadays
filled with bolsheviks demanding everyone to start from absolute
scratch, so wacky advices expected there :-(

 So maybe this list starts to be the one for those who cannot
understand the ideas about starting from scratch, avoiding
preinstalling anything from the (usually proprietary/custom) target
systems and replacing it with totally self-built (library) stuff...
So people who need crosstools for Solaris2, AIX, LynxOS, RedHat,
SuSE etc. are adviced to build glibc as the C library, of course the
C library being an essential part of GCC just like the binutils and
everyone being obliged to build all these GCC components from
scratch... "People are like chaff in the wind...", these people
really believe to their bullshitism/bolshevism and think they are
creating a better and perfect world this way, with these ideas...

 Ok, here we are talking about "recycling", "re-use" and other
things some others think the "creating a better and perfect world"
means. Like using existing C libraries for the target instead of
being obliged to rebuild them

> 2. cp -r ../../lib /opt/gcc/mipsel-linux/
>cp -r ../../include /opt/gcc/mipsel-linux/

 There is a well-known bug in GCC and putting the target headers to
the '$prefix/$target/include' is not enough, some of them or maybe
them all must also be seen in the '$prefix/$target/sys-include'.  At
least the 'limits.h', 'stdio.h', 'stdlib.h', 'string.h', 'time.h' and 
unistd.h' are required with the current GCCs.  Seeing them all may
work, sometimes the 'fixinc*' stuff makes garbage from the original
headers... I don't remember the case with gcc-2.95.3. My advice is
to symlink/copy only those six headers into the '.../sys-include'.

> 3. compile the gcc
> mkdir gcc-build;
> cd gcc-build;
> .../../gcc-2.95.3/configure --prefix=/opt/gcc --target=mipsel-linux

 Are you simply not telling the truth here or what?  Please see
later...

> --enable-languages=c -enable-shared -disable-checking -v;
> make;
>
>   /home/mytask/mywork/WHAT_I_HAVE_DONE/mycompile/gcc-2.95.3-build/gcc/gcc/xgcc
> -B/home/mytask/mywork/WHAT_I_HAVE_DONE/mycompile/gcc-2.95.3-build/gcc/gcc/
> -B=/opt/gcc-2.95//mipsel-linux/bin/

 This '-B' option tells that you used a "--prefix=/opt/gcc-2.95", not
the "--prefix=/opt/gcc" you told earlier, when configuring GCC !!!
Using JUST THE SAME PREFIX in both configures is the expected thing,
otherwise you are asking serious problems...

> -I=/opt/gcc-2.95//mipsel-linux/include  -DCROSS_COMPILE -DIN_GCC 
> -I./include -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
> -I/usr/include

 Trying to get (native) headers from '/usr/include' is a bug here...
Especially when the host isn't a Linux.
 
> _muldi3
> as: unrecognized option `-O2'

 An option understood by a MIPS target 'as' was given to the native
'as'... This is one of the "serious problems" I told about...

> the as should be mipsel-linux-as

 When we are talking about "FBB" ("FSF's Bad Boy"), an AI being
a "step forwards" from GCC (like IBM -> HAL), then this FBB would
use those '$target-' things... The situation now is that only
humans and scripts written by humans use them... GCC uses those
seen with the './xgcc -print-search-dirs' with the new GCC driver...
(Hmm, when GCC becomes FBB, then GCJ becomes FBI, maybe
called like this because cops like coffee :-)

 Just fix your $prefix and try again after writing 'make distclean'
in your build directory:

/home/mytask/mywork/WHAT_I_HAVE_DONE/mycompile/gcc-2.95.3-build/gcc

Then set the 'sys-include' stuff and use the aimed
'--prefix=/opt/gcc'  in the GCC configure...

Cheers, Kai

ppc32/e500/no float - undefined references in libstdc++ _Unwind_*

[Clemens Koller]

Hello!
I guess I need some help to verify my toolchain.
My host=target=embedded mpc8540 (e500 core) processor which has no fpu.
I am working with:
[EMAIL PROTECTED]:/$gcc -v
Reading specs from /usr/local/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/specs
Configured with: ../gcc-3.4-20050408/configure --with-float=soft
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-languages=c,c++,objc --enable-nls=yes --enable-clocale=gnu
Thread model: posix
gcc version 3.4.4 20050408 (prerelease)
[EMAIL PROTECTED]:/$gcc -print-multi-lib
.;@[EMAIL PROTECTED]
nof;@[EMAIL PROTECTED]@mstrict-align
[EMAIL PROTECTED]:/usr/lib$ l libstdc++.*
-rw-r--r--1 root root  1721590 Apr  6 12:17 libstdc++.a
lrwxrwxrwx1 root root   18 Apr  6 12:18 libstdc++.so -> 
libstdc++.so.5.0.5
lrwxrwxrwx1 root root   18 Apr  6 12:18 libstdc++.so.5 -> 
libstdc++.so.5.0.5
-rwxr-xr-x1 root root   857824 Apr  6 12:17 libstdc++.so.5.0.5
[EMAIL PROTECTED]:/usr/lib$ l ../local/lib/nof/libstdc++.*
-rw-r--r--1 root root  7298624 Apr 12 20:31 
../local/lib/nof/libstdc++.a
-rwxr-xr-x1 root root 1307 Apr 12 20:31 
../local/lib/nof/libstdc++.la
lrwxrwxrwx1 root root   18 Apr 12 20:31 
../local/lib/nof/libstdc++.so -> libstdc++.so.6.0.3
lrwxrwxrwx1 root root   18 Apr 12 20:31 
../local/lib/nof/libstdc++.so.6 -> libstdc++.so.6.0.3
-rwxr-xr-x1 root root  5433010 Apr 12 20:31 
../local/lib/nof/libstdc++.so.6.0.3
[EMAIL PROTECTED]:/usr/lib$

But when I compile X6.7.2 I get undefined references in the nof/libstdc++:
make[4]: Entering directory `/share/home/clemens/newbuild/xc/programs/glxinfo'
gcc -O2 -fno-strict-aliasing -fsigned-char -I../.. -I../../exports/include  
 -Dlinux -D__powerpc__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE 
-D_XOPEN_SOURCE  -D_BSD_SOURCE -D_SVID_SOURCE   
  -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS 
 -D_REENTRANT -DXUSE_MTSAFE_API-DDO_GLU-c -o glxinfo.o glxinfo.c
rm -f glxinfo
gcc -o glxinfo -O2 -fno-strict-aliasing -fsigned-char -L../../exports/lib   
glxinfo.o -lGLU -lGL -lXext -lX11  -lpthread -lm   
-Wl,-rpath-link,../../exports/lib
/usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]'
/usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]'
/usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]'
/usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]'
/usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]'
/usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]'
/usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]'
/usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]'
/usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]'
/usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]'
/usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]'
collect2: ld returned 1 exit status
make[4]: *** [glxinfo] Error 1
make[4]: Leaving directory `/share/home/clemens/newbuild/xc/programs/glxinfo'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/share/home/clemens/newbuild/xc/programs'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/share/home/clemens/newbuild/xc'
make[1]: *** [World] Error 2
make[1]: Leaving directory `/share/home/clemens/newbuild/xc'
make: *** [World] Error 2
So I am concerned if my configuration is correct or is there a problem with the 
lib?
What is _the_ recommended way to build a toolchain for the mpc8540 for the 
latest
mainline? Is the -mfloat-gprs working?
Thanks,
Clemens Koller
___
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19

[PATCH] RE: gcc for syntax check only (C): need to read source from stdin

[Dave Korn]

Original Message
>From: Zack Weinberg
>Sent: 12 April 2005 18:31

> "Dave Korn" <[EMAIL PROTECTED]> writes:
> 
>>   Then the error message *really* ought to say
>> 
>> gcc: -E or -x required when input is from standard input
>> 
>> since it is thoroughly obtuse and non-explanatory as it stands.  The
>> attached is against 4.0 RC1, but I imagine it'll apply cleanly to HEAD
>> with just a little fuzz, if people feel it's the right thing.
> 
> Yes, I think this is the right thing.  Please test against mainline
> and apply it there if successful.  I don't think it is important
> enough to put into 4.0.0, but you should put it on the 4.0 branch
> after the release, and maybe the 3.4 branch as well.
> 
> zw



  Tested on HEAD with --enable-languages=c,c++ by running "make check-gcc
check-libstdc++ check-gcc-c++" (yes I know there's some redundant redundancy
in that list of targets) and then diff'ing the before-and-after outputs from
test_summary to make sure nothing changed (as well as eyeballing the summary
figures); nothing did.  Final patch attached (it hasn't changed any).  It's
a trivial patch, but I have an assign on file and in fact my employer
disclaimer is in the post as we speak.  (Finally got it signed just the
other day, hooray!)  No write privs; Zack, would you be so kind?  TIA!



2005-12-04  Dave Korn  <[EMAIL PROTECTED]>

* gcc.c (default_compilers):  Clarify obscure error message when
  reading from standard input.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


obscure-error-message-patch.diff
Description: Binary data

Re: Heads-up: volatile and C++

[Michael N. Moran]

Jason Merrill wrote:
The device driver case seems like a more plausible objection to me, but I'd
like to see an example there, too.
Though not widely used, download the OSCL and grep
for volatile.
http://mnmoran.org/oscl-v1.1.tgz
There are many device drivers in this tar-ball, mostly related
to the MPC860 PowerPC .
--
Michael N. Moran   (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144http://mnmoran.org
"So often times it happens, that we live our lives in chains
 and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1

Re: Heads-up: volatile and C++

[Michael N. Moran]

Jason Merrill wrote:
On Thu, 14 Apr 2005 15:26:32 -0400, "Michael N. Moran" <[EMAIL PROTECTED]> wrote:
For example, device drivers that perform memory mapped I/O
on memory spaces which are "guarded" and thus need no additional
ordering/synchronization instructions.
You mentioned PowerPC in a previous post; while device memory doesn't need
as much explicit ordering as cached memory,
 http://www-128.ibm.com/developerworks/eserver/articles/powerpc.html
says
 All these rules don't prevent stores to device memory from being issued
 out of program order with respect to loads from device memory, or vice
 versa. Instead, the memory-barrier instructions, eieio and sync, must be
 used when out of order operations could yield incorrect results.
you need an eieio between loads and stores, or between two loads, to ensure
proper ordering.  Yes, the proposed volatile semantics are more than you
need.  But you do need something.
This is not true regarding access to pages of memory marked
"guarded" (e.g.. memory mapped I/O.) Such pages
ensure that access are not re-ordered by the processor.
See the table under "Memory barrier instructions"
That said, perhaps the current volatile semantics are a useful primitive
for building on with more specific explicit ordering, but that's not clear
to me.
I'm very much in favor of fine grained synchronization primitives
in the compiler, but not of changes to volatile semantics.
--
Michael N. Moran   (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144http://mnmoran.org
"So often times it happens, that we live our lives in chains
 and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1

Stack and Function parameters alignment

[Petar Penchev]

Hello All,
The CPU ,I am porting GCC to , has PUSH instruction for half-word (byte)  
and PUSH instruction for word as well.
GCC is using them well, until I was told to add a command-line option  
which allows GCC to align on word.
It has been done, however, there samoe problems. GCC generates following  
code:

PUSH AL ; AL is 8-bit reister
INC S ; increment stack pointer
This is correct code, but it is longer than
PUSH A ; where A is 16 bit register
And if RAM does not allow access on ODD addresses.
I have define following macros as follows
/ *tm.h */
#define PARM_BOUNDARY		(TARGET_STACK_BYTE_ALLIGN?BITS_PER_WORD / 2:  
BITS_PER_WORD)
#define STACK_BOUNDARY		((TARGET_STACK_BYTE_ALLIGN?BITS_PER_WORD / 2:  
BITS_PER_WORD))
/***/

In .md file  have defined
(define_expand "pushqi"
[
 (set (mem:QI (post_inc (reg:HI S_HREG)))
  (match_operand:QI 0 "general_operand" "")
 )
]
""
""
)
(define_insn "*pushqi"
  [(set (mem:QI (post_inc (reg:HI S_HREG)))
(match_operand:QI 0 "general_operand" "b"))]
 "TARGET_STACK_BYTE_ALLIGN"
  "push\t%0\t; *pushqi"
  [(set_attr "cc" "none")]
)

(define_insn "*pushqi_word_aligned"
  [(set (mem:QI (post_inc (reg:HI S_HREG)))
(match_operand:QI 0 "general_operand" "b"))]
  "!TARGET_STACK_BYTE_ALLIGN"
  "#"
  [(set_attr "cc" "none")]
)
(define_split
 [(set (mem:QI (post_inc (reg:HI S_HREG)))
(match_operand:QI 0 "general_operand" "b"))]
  "!TARGET_STACK_BYTE_ALLIGN"
 [
   (set (match_dup 1)
(match_dup 0)
   )
   (set (mem:HI (post_inc (reg:HI S_HREG)))
(match_dup 1)
   )
 ]
  "
  operands[1] = gen_rtx(REG, HImode, A_HREG);
  "
)
The asm code I expect this RTL to generate is
PUSH A
BUT instead of that it generates
PUSH A ; stack is even
INC S ; incorrect (the stack is ODD)
What am I doing wrong ? Can somebody tell me how to solve this problem ?

Regards
Petar Penchev
Software engineer

Re: Stack and Function parameters alignment

[Paul Brook]

On Friday 15 April 2005 13:33, Petar Penchev wrote:
> Hello All,
> The CPU ,I am porting GCC to , has PUSH instruction for half-word (byte)
> and PUSH instruction for word as well.
> GCC is using them well, until I was told to add a command-line option
> which allows GCC to align on word.
> It has been done, however, there samoe problems. GCC generates following
> code:
>
> PUSH AL ; AL is 8-bit reister
> INC S ; increment stack pointer
> 
> This is correct code, but it is longer than
> 
> PUSH A ; where A is 16 bit register<...>

Obviously this only works on little-endian targets.

<...>
>   [(set (mem:QI (post_inc (reg:HI S_HREG)))
>   (match_operand:QI 0 "general_operand" "b"))]
>"!TARGET_STACK_BYTE_ALLIGN"
>   [
> (set (match_dup 1)
>   (match_dup 0)
> )
> (set (mem:HI (post_inc (reg:HI S_HREG)))
>   (match_dup 1)
> )
>   ]
>"
>operands[1] = gen_rtx(REG, HImode, A_HREG);
>"
> )

A post_inc increments by the size of the memory access. A define_split is 
supposed to replace one insn by multiple insns that do the same thing. You're 
replacing a byte increment with a word increment.

You could try adding a define_peephole2 that turns push al; inc S into push a.

Paul

Re: Objective-C++ Status

[James A. Morrison]

"Douglas Charles" <[EMAIL PROTECTED]> writes:

> What is the status of Objective-C++ support in mainline GCC? Ziemowit Laski 
> was 
> working on integrating such support late last year, but has Apple since 
> halted 
> such integration efforts? 
>  
>   Douglas 

 I'm sure integrating Obj-C++ will be a big enough change to mention in the news
section of http://gcc.gnu.org.  So, you don't need to ask this question every 
few
months.  If you would like to speed up the process, feel free to start bringing
over patches from Apple's branch.


-- 
Thanks,
Jim

http://www.student.cs.uwaterloo.ca/~ja2morri/
http://phython.blogspot.com
http://open.nit.ca/wiki/?page=jim

Re: Heads-up: volatile and C++

[Paul Koning]

> "Marcin" == Marcin Dalecki <[EMAIL PROTECTED]> writes:

 Marcin> Templates are a no-go for a well known and well defined
 Marcin> subset for C++ for embedded programming known commonly as
 Marcin> well embedded C++.  

I don't think that's a good argument.  If people want to emasculate
the language, that's their problem.  Especially given that templates
work perfectly well in embedded systems -- we use them (and other
features of real C++) in embedded systems here all the time.

 paul

Re: Re: Stack and Function parameters alignment

[Petar Penchev]

Hmm, I tried to define a peephole like this:
//
(define_peephole2
[   
(set
(mem:QI (post_inc (reg:HI S_HREG)))
(match_operand:QI 0 "general_operand" "b")
)
(set (reg:HI S_HREG)
(plus:HI  (reg:HI S_HREG)
  (const_int 1)
)
)
   ]
"!TARGET_STACK_BYTE_ALLIGN"
[   
(set
(mem:HI (post_inc (reg:HI S_HREG)))
(match_dup  0)
)
]
"
/*PUT_MODE(operands[0],HImode);*/
 operands[0] = force_reg(HImode,operands[0]);
"
)
I tried to use force_reg or PUT_MODE
but it does nothing and PUSH AL, inc S remain.
May be the problem is that the mode of the operand is different in both  
sides of the peephole?


On Friday 15 April 2005 13:33, Petar Penchev wrote:
Hello All,
The CPU ,I am porting GCC to , has PUSH instruction for half-word (byte)
and PUSH instruction for word as well.
GCC is using them well, until I was told to add a command-line option
which allows GCC to align on word.
It has been done, however, there samoe problems. GCC generates following
code:
 PUSH AL ; AL is 8-bit reister
INC S ; increment stack pointer
 This is correct code, but it is longer than
 PUSH A ; where A is 16 bit register<...>
Obviously this only works on little-endian targets.
<...>
  [(set (mem:QI (post_inc (reg:HI S_HREG)))
(match_operand:QI 0 "general_operand" "b"))]
   "!TARGET_STACK_BYTE_ALLIGN"
  [
(set (match_dup 1)
(match_dup 0)
)
(set (mem:HI (post_inc (reg:HI S_HREG)))
(match_dup 1)
)
  ]
   "
   operands[1] = gen_rtx(REG, HImode, A_HREG);
   "
)
A post_inc increments by the size of the memory access. A define_split is
supposed to replace one insn by multiple insns that do the same thing.  
You're
replacing a byte increment with a word increment.

You could try adding a define_peephole2 that turns push al; inc S into  
push a.

Regards
Petar

Questions on CC

[Timothy Bowers]

--- Begin Message ---
I am trying to install gcc on RedHat Enterprise Linux 3.  I do not have 
a compiler installed on the system.  I see that gcc requires a ISO C90 
compiler.  Where can I get one?  Also, when I try to configure gcc for 
install, I get an error that states that I need to set cc environmental 
variable to a working compiler.  I think this will be taken care of when 
I install a ISO C90 compiler.  Any help you can give me would be great.

Thanks,
Tim Bowers


smime.p7s
Description: S/MIME Cryptographic Signature
--- End Message ---


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Processor-specific code

[Richard Earnshaw]

On Thu, 2005-04-14 at 18:35, Richard Henderson wrote:
> On Thu, Apr 14, 2005 at 05:27:16PM +0200, François-Xavier Coudert wrote:
> > No, since reading GFORTRAN_FPU_* variables changes the FPU mode when the 
> > library is loaded, while TR 15580 commands will be ran afterwards (during 
> > execution).
> 
> You'll find that globally changing the rounding mode will screw up
> libm functions.  Which is pretty much going to make this useless.
> 
> Further, when folks need rounding modes other than round-to-nearest,
> they tend to need to switch rounding modes during the program too.
> For instance, to perform the same calculation with both round-up and
> round-down to get error bounds on the calculation.
> 
> Thus I think an environment variable to do this is doubly useless.

Not all environments can change the rounding mode dynamically.  For
example, on the FPA co-processor for ARM, rounding is set by the
instruction selected -- so the concept of having an environment variable
to control this is meaningless.


R.

re: some problem about cross-compile the gcc-2.95.3

[Dan Kegel]

"zouq" <[EMAIL PROTECTED]> wrote:
first i download the release the version of gcc-2.95.3, binutils 2.15,
and i use the o32 lib, include of gcc3.3.3 .
1. compile the binutils and install it
mkdir binutils-build;
cd binutils-build;
../../binutils-2.15/configure --prefix=/opt/gcc --target=mipsel-linux -v;
make;make install;
2. cp -r ../../lib /opt/gcc/mipsel-linux/
   cp -r ../../include /opt/gcc/mipsel-linux/
3. compile the gcc
mkdir gcc-build;
cd gcc-build;
../../gcc-2.95.3/configure --prefix=/opt/gcc --target=mipsel-linux
--enable-languages=c -enable-shared -disable-checking -v;
make;
then the ERROR happened:  ...
as: unrecognized option `-O2'
make[1]: *** [libgcc2.a] Error 1
Ah, you built binutils, but did you put them on your path?
You need
  PATH=$PATH:/opt/gcc/bin
before you configure gcc.  Then it should pick up mipsel-linux-as
from the path.
But as Kai says, this isn't the list for this sort
of question.  You should take it to the crossgcc list
http://sources.redhat.com/ml/crossgcc/
(where we will tell you to try http://kegel.com/crosstool :-)
or the etux list
http://www.embeddedtux.org/mailman/listinfo/etux
(which is explicitly for people who don't like using canned scripts
like crosstool.  In other words, for people like Kai :-)
- Dan
--
Trying to get a job as a c++ developer?  See 
http://kegel.com/academy/getting-hired.html

Re: [m68k]: More trouble with byte moves into Address registers

[Ian Lance Taylor]

Peter Barada <[EMAIL PROTECTED]> writes:

> Which debugging dump has the output from "local-alloc"? If its
> pp_pack.c.24.lreg, then that is the output I supplied in the original
> message which contains(for all bits regarding register 1420 up until
> the compilation fails):

Sorry, guess I missed that.

> (insn 5559 5558 5560 694 pp_pack.c:2144 (set (reg:SI 1421)
> (plus:SI (subreg:SI (reg:QI 1420) 0)
> (const_int -32 [0xffe0]))) 121 {*addsi3_5200} (insn_list 5558 
> (nil))
> (nil))

So register 1420 is being assigned to a data register.  The
constraints for addsi3_5200 permit the following alternatives:
mem += datareg
addrreg = addrreg + reg|constant
addrreg = reg|constant + addrreg
reg += mem|reg|constant
There is no alternative which permits adding a data register and a
constant and putting the result in an address register.  So reload
picks the alternative "addrreg = addrreg + reg|constant", and decides
to reload register 1420 into an address register.  But that fails
because reload can't find an address register which can accept a
QImode value.

Looking at the dump a little more, it's far from clear why register
1421 is being put into an address register.  I see that insn 5560
wants to compare a byte value which it finds there, so it doesn't seem
like a good fit to put 1421 into an address register.

I don't know where else register 1421 is being used, so my tentative
guess would be that gcc is picking an address register based on the
constraints in addsi3_5200.  Perhaps you need to change "?a" to "*a".
After all, you probably don't want to encourage pseudos to go into the
address registers merely because you add values to them.

But it is also possible that register 1421 is being put into an
address register merely because all the data registers are taken and
there is nothing which forces 1421 to be in a data register.


Or, you might permit an alternative "a a*r rJK" in addsi3_5200.  You
can implement that using a two instruction sequence--copy the data
register to the address register, and then add.  This is obviously not
ideal, but it's more or less what reload would be doing anyhow.


In general, though, I'm not sure that prohibiting QImode values in
address registers is going to be a useful approach.  After all, the
values do fit there, and while we want to discourage it, it's not
obvious that we want to completely prohibit it.  The problem in PR
18421 is that reload decided that it had to reload a QImode value from
memory into an address register, but it couldn't.  That is more or
less easy to handle by defining SECONDARY_RELOAD_CLASS to indicate
that a data register is required to move QImode values between the
address registers and memory, and by defining reload_inqi and
reload_outqi to do the moves.

Ian

Re: Processor-specific code

[Robert Dewar]

Richard Earnshaw wrote:
Not all environments can change the rounding mode dynamically.  For
example, on the FPA co-processor for ARM, rounding is set by the
instruction selected -- so the concept of having an environment variable
to control this is meaningless.
Right, such a feature obviously does not apply to hardware that is this
far from the IEEE standard (which requires dynamic control). The Alpha
architecture has similar problems.

Re: Questions on CC

[Nathan Sidwell]

Timothy Bowers wrote:
I am trying to install gcc on RedHat Enterprise Linux 3.  I do not have 
a compiler installed on the system.  I see that gcc requires a ISO C90 
compiler.  Where can I get one?  Also, when I try to configure gcc for 
install, I get an error that states that I need to set cc environmental 
variable to a working compiler.  I think this will be taken care of when 
I install a ISO C90 compiler.  Any help you can give me would be great.
you should install the gcc package from RedHat. Then you can use that
directly, or build your own (updated?) version from source.
nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

struct __attribute((packed));

[Ralf Corsepius]

Hi,

I just tripped over this snipped below in a piece of code, I didn't
write and which I don't understand:

...
struct somestruct {
  struct entrystruct *e1 __attribute__ ((packed));
  struct entrystruct *e2 __attribute__ ((packed));
};
...

Is this meaningful?

I guess the author wanted e1 and e2 to point to a 
"packed struct entrystruct", but this doesn't seem to be what GCC
interprets this code.

Ralf

Re: struct __attribute((packed));

[E. Weddington]

Ralf Corsepius wrote:
Hi,
I just tripped over this snipped below in a piece of code, I didn't
write and which I don't understand:
...
struct somestruct {
 struct entrystruct *e1 __attribute__ ((packed));
 struct entrystruct *e2 __attribute__ ((packed));
};
...
Is this meaningful?
I guess the author wanted e1 and e2 to point to a 
"packed struct entrystruct", but this doesn't seem to be what GCC
interprets this code.

 

Take a look at the manual in the section about attributes of variables,

It seems that GCC will interpret the above as e1 and e2 is packed within 
the struct somestruct so that e2 "immediately follows e1" (according to 
the manual). The packed attribute in this case does not refer to what e1 
and e2 is pointing to. Though I'm not sure what putting the packed 
attribute on e1 will buy you.

HTH
Eric

Successful bootstrap of GCC 3.4.3 on i586-pc-interix3 (with one little problem)

[Rob Hulswit]

bash-3.00$ ../gcc-3.4.3/config.guess
i586-pc-interix3
bash-3.00$ gcc/xgcc -v
Using built-in specs.
Configured with: ../gcc-3.4.3/configure --verbose --disable-shared
--with-stabs --enable-nls --with-gnu-as --with-gnu-ld
--enable-targets=i586-pc-interix3 --enable-threads=posix
--enable-languages=c,c++ --enable-checking : (reconfigured)
../gcc-3.4.3/configure --verbose --disable-shared --with-stabs
--enable-nls --with-gnu-as --with-gnu-ld
--enable-targets=i586-pc-interix3 --enable-threads=posix
--enable-languages=c,c++,g77,ada,java,objc : (reconfigured)
../gcc-3.4.3/configure --verbose --disable-shared --with-stabs
--enable-nls --with-gnu-as --with-gnu-ld
--enable-targets=i586-pc-interix3 --enable-threads=posix
--enable-languages=ada,c,c++,f77,f95,java,objc,obj-c++ :
(reconfigured) ../gcc-3.4.3/configure --verbose --disable-shared
--with-stabs --enable-nls --with-gnu-as --with-gnu-ld
--enable-targets=i586-pc-interix3 --enable-threads=posix
--enable-languages=ada,c,c++,f77,java,objc
Thread model: posix
gcc version 3.4.3

There was a problem in building libobjc, libtool wouldn't run due to
having '#! sh' as its first line.
Changing it to '#! /bin/sh' enabled the bootstrap to complete.

System: Windows 2000 SP4, Services for Unix 3.5.

Re: struct __attribute((packed));

[Ralf Corsepius]

On Fri, 2005-04-15 at 09:27 -0600, E. Weddington wrote:
> Ralf Corsepius wrote:
> 
> >Hi,
> >
> >I just tripped over this snipped below in a piece of code, I didn't
> >write and which I don't understand:
> >
> >...
> >struct somestruct {
> >  struct entrystruct *e1 __attribute__ ((packed));
> >  struct entrystruct *e2 __attribute__ ((packed));
> >};
> >...
> >
> >Is this meaningful?
> >
> >I guess the author wanted e1 and e2 to point to a 
> >"packed struct entrystruct", but this doesn't seem to be what GCC
> >interprets this code.
> >
> >
> >  
> >
> 
> Take a look at the manual in the section about attributes of variables,
> 

I read this, over and over again, before posting, but ...

> It seems that GCC will interpret the above as e1 and e2 is packed within 
> the struct somestruct so that e2 "immediately follows e1" (according to 
> the manual). The packed attribute in this case does not refer to what e1 
> and e2 is pointing to.
That's what I found out by experimenting and is the reason why I am
asking. From what I see on i386,

struct entrystruct * entry __attribute__ ((packed));

is interpreted as "packed pointer to struct"
not as "pointer to packed struct",
i.e. this construct is not meaningful.

>  Though I'm not sure what putting the packed 
> attribute on e1 will buy you.
You've got the point - I am collecting ammunition to fight a stubborn
original author :-)

Ralf

Re: struct __attribute((packed));

[Paul Koning]

> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:

 Ralf> struct entrystruct * entry __attribute__ ((packed));

 Ralf> is interpreted as "packed pointer to struct" not as "pointer to
 Ralf> packed struct", i.e. this construct is not meaningful.

Yes it's meaningful, it may not be what you intended.

It sure would be useful, though, if there were a construct that does
mean "pointer to packed T".  In particular, I've often needed "pointer
to packed int" and found no way to produce that.  I ended up creating
a one-member struct with a packed int inside, which is a syntactic
nightmare.   (The application was a piece of legacy code that was
writing via int pointers, but sometimes things were not aligned.  The
fix was much more invasive than it should have been because I could
find no way to define a pointer to packed int.)  If there IS a way to
do that, it sure would be nice for the docs to explain it.  Right now
the documentation of "packed" is essentially unintellegible.

paul

inline-unit-growth trouble

[Andreas Krebbel]

Hi,

on S/390 we have currently a plenty of testsuite failures
due to inlining effects.

ld complains about testcases which try to link two files containing the same 
function
in .gnu.linkonce sections but with different code sizes. The sizes differ due
to different inlining decisions. The problem is that inlining maybe
prevented by global limits which maybe exceeded for one file but not for 
the other.
The actual problem occurred with the "inline-unit-growth" limit which
may prevent inlining for a function in one file and allow it for the same
function in another.

I'm not sure how to fix that issue. To my mind the whole concept of per unit
limits influencing local inlining decisions seems a bit questionable.

Any suggestions?

Bye,

-Andreas-

Re: [m68k]: More trouble with byte moves into Address registers

[Peter Barada]

>For some reason reload has decided that it needs ADDR_REGS for the
>register being reloaded, namely (reg:QI 1420).  So gcc looks for a
>register in ADDR_REGS which can hold QImode.  Because of your changes,
>it doesn't find one.  So it crashes.
>
>The question is why reload thinks that it needs ADDR_REGS for this
>register.  Look at the local-alloc debugging dump to see where
>regclass thinks that the register should go.

Which debugging dump has the output from "local-alloc"? If its
pp_pack.c.24.lreg, then that is the output I supplied in the original
message which contains(for all bits regarding register 1420 up until
the compilation fails):

  Register 1420 costs: DATA_REGS:84 GENERAL_REGS:210 DATA_OR_FP_REGS:294 
ALL_REGS:294 MEM:441
  Register 1420 pref DATA_REGS
  Register 1420 costs: DATA_REGS:84 GENERAL_REGS:210 DATA_OR_FP_REGS:294 
ALL_REGS:294 MEM:441
Register 1420 used 3 times across 6 insns; set 1 time; 1 bytes; pref DATA_REGS.
Registers live at end: 14 [%a6] 15 [%sp] 24 [argptr] 31 35 36 37 38 39 43 45 46 
47 48 50 52 57 70 1369 1370 1371 1378 1391 1402 1413 1420 1725 1734 1735 1736 
1738 1740
Registers live at start: 14 [%a6] 15 [%sp] 24 [argptr] 31 35 36 37 38 39 43 45 
46 47 48 50 52 57 70 1369 1370 1371 1378 1391 1402 1413 1420 1725 1734 1735 
1736 1738 1740

;; Start of basic block 694, registers live: 14 [%a6] 15 [%sp] 24 [argptr] 31 
35 36 37 38 39 43 45 46 47 48 50 52 57 70 1369 1370 1371 1378 1391 1402 1413 
1725 1734 1735 1736 1738 1740 1756
(note 6967 5556 5558 694 [bb 694] NOTE_INSN_BASIC_BLOCK)

(insn 5558 6967 5559 694 pp_pack.c:2144 (set (reg:QI 1420)
(mem:QI (reg:SI 1756 [ s ]) [0 S1 A8])) 43 {movqi_cfv4} (nil)
(expr_list:REG_DEAD (reg:SI 1756 [ s ])
(nil)))

(insn 5559 5558 5560 694 pp_pack.c:2144 (set (reg:SI 1421)
(plus:SI (subreg:SI (reg:QI 1420) 0)
(const_int -32 [0xffe0]))) 121 {*addsi3_5200} (insn_list 5558 
(nil))
(nil))

(insn:QI 5560 5559 5561 694 pp_pack.c:2144 (set (cc0)
(compare (subreg:QI (reg:SI 1421) 3)
(const_int 64 [0x40]))) 15 {cfv4_cmpqi} (insn_list 5559 (nil))
(expr_list:REG_DEAD (reg:SI 1421)
(nil)))


BTW: the patterns mentioned in the dump:

(define_insn "movqi_cfv4"
  [(set (match_operand:QI 0 "nonimmediate_operand" "=d,dmU,U,d")
(match_operand:QI 1 "general_src_operand" "dmi,d,Ui,di"))]
  "TARGET_CFV4"
  "* return output_move_qimode (operands);")

(define_insn "*addsi3_5200"
  [(set (match_operand:SI 0 "nonimmediate_operand" "=m,?a,?a,r")
(plus:SI (match_operand:SI 1 "general_operand" "%0,a,rJK,0")
 (match_operand:SI 2 "general_src_operand" 
"dIL,rJK,a,mrIKLi")))]
  "TARGET_COLDFIRE"
  "* return output_addsi3 (operands);")

(define_insn "cfv4_cmpqi"
  [(set (cc0)
(compare (match_operand:QI 0 "nonimmediate_operand" "mdKs,d")
 (match_operand:QI 1 "general_operand" "d,mdKs")))]
  "TARGET_CFV4"
  "*
{
  if (REG_P (operands[1])
  || (!REG_P (operands[0]) && GET_CODE (operands[0]) != MEM))
{ cc_status.flags |= CC_REVERSED;
#ifdef SGS_CMP_ORDER
  return \"cmp%.b %d1,%d0\";
#else
  return \"cmp%.b %d0,%d1\";
#endif
}
#ifdef SGS_CMP_ORDER
  return \"cmp%.b %d0,%d1\";
#else
  return \"cmp%.b %d1,%d0\";
#endif
}")

And the function called for HARD_REGNO_MODE_OK is:

/* Value is 1 if hard register REGNO can hold a value of machine-mode MODE.
   On the 68000, the cpu registers can hold any mode except bytes in
   address registers, but the 68881 registers
   can hold only SFmode or DFmode.  */
int m68k_hard_regno_mode_ok(int regno, enum machine_mode mode)
{
  if (regno < 8)
{
  /* Data Registers can hold anything if it fits into them */
  if (((regno) + GET_MODE_SIZE (mode) / 4) <= 8)
return 1;
}
  else if (regno < 16)
{
  /* Address Registers can't hold bytes, can hold aggregate if
 it fits into them */
  if (GET_MODE_SIZE (mode) == 1)
return 0;
  if (((regno) + GET_MODE_SIZE (mode) / 4) <= 16)
return 1;
}
  else if (regno < 24)
{
  /* FPU registers, hold float or complex float of long double or smaller */
  if ((GET_MODE_CLASS (mode) == MODE_FLOAT
   || GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT)
  && (((GET_MODE_UNIT_SIZE (mode) <= 12) && TARGET_68881)
  || ((GET_MODE_UNIT_SIZE (mode) <= 8) && TARGET_CFV4E)))
return 1;
}
  return 0;
}

Any further insight or suggestions are *really* appreciated!

-- 
Peter Barada
[EMAIL PROTECTED]

Re: struct __attribute((packed));

[E. Weddington]

Ralf Corsepius wrote:
On Fri, 2005-04-15 at 09:27 -0600, E. Weddington wrote:
 

It seems that GCC will interpret the above as e1 and e2 is packed within 
the struct somestruct so that e2 "immediately follows e1" (according to 
the manual). The packed attribute in this case does not refer to what e1 
and e2 is pointing to.
   

That's what I found out by experimenting and is the reason why I am
asking. From what I see on i386,
struct entrystruct * entry __attribute__ ((packed));
is interpreted as "packed pointer to struct"
not as "pointer to packed struct",
 

I would interpret it that way too: packed pointer to struct. The 
"packed" attribute is on the variable itself, not the type of the 
variable (pointer to struct)

i.e. this construct is not meaningful.
 

Is it?
The manual says
"The |packed| attribute specifies that a variable or structure field 
should have the smallest possible alignment".

So it sounds like that:
struct entrystruct * entry __attribute__ ((packed));
by itself would mean that the variable entry has the smallest possible 
alignment. I don't know if that is meaningful just by itself or whether 
it is meaningful in your context.
And realise that I'm just postulating from looking at the manual. 
Somebody with more expertise would have to comment about this.

You've got the point - I am collecting ammunition to fight a stubborn
original author :-)
 

Yeah, if that author was thinking that the packed attribute applied to 
what the variable pointed to, then I would think that it is wrong usage 
of the attribute.
I would suggest pointing the author to the description of "packed" in 
the section on attributes of types:


HTH
Eric

Re: Semi-Latent Bug in tree vectorizer

[Jeffrey A Law]

On Sat, 2005-04-09 at 23:23 -0400, Diego Novillo wrote:
> On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
> 
> > When we vectorize the store we copy the virtual operands from the
> > original statement to the new vectorized statement via this code:
> > 
> >   /* Copy the V_MAY_DEFS representing the aliasing of the original array
> >  element's definition to the vector's definition then update the
> >  defining statement.  The original is being deleted so the same
> >  SSA_NAMEs can be used.  */
> >   copy_virtual_operands (*vec_stmt, stmt);
> >   v_may_defs = STMT_V_MAY_DEF_OPS (*vec_stmt);
> >   nv_may_defs = NUM_V_MAY_DEFS (v_may_defs);
> > 
> >   for (i = 0; i < nv_may_defs; i++)
> > {
> >   tree ssa_name = V_MAY_DEF_RESULT (v_may_defs, i);
> >   SSA_NAME_DEF_STMT (ssa_name) = *vec_stmt;
> > }
> > 
> > This is safe if and only if the the operand scanning code will compute
> > the same V_MAY_DEFS for the original scalar statement and the new
> > vectorized statement.  ie, *D.1470 must have the same aliasing
> > properties as *vect_px.17.
> > 
> Right.  Both the vectorizer and ivopts have the side-effect of
> refining aliasing information.  Therefore, blindly copying
> virtual operands is not correct.
> 
> Could you try this patch?  It fixes your test case and doesn't
> produce new regressions in the vectorizer tests.  It's not
> bootstrapped nor tested otherwise.
> 
> The idea is that we should treat both the vectorized statement
> and the old statement separately.  The virtual defs from the old
> statement are going away and the new one is getting brand new
> symbols exposed.  That's why we mark them separately.
I went ahead and ran this through the usual bootstrap and regression
test.  Installed this morning...

jeff

Re: Heads-up: volatile and C++

[Paul Schlie]

> Michael N. Moran wrote:
> I'm very much in favor of fine grained synchronization primitives
> in the compiler, but not of changes to volatile semantics.

I wonder if it would be sufficient (if not preferable) to only extend
(modify) the semantics for heap/stack and const volatile variables, as
enforcing existing volatile semantics for such variables are at best
of questionable existing value. i.e.:

 volatile vv;// volatile sync primitive, w/normal access semantics.
 volatile const vc;  // universal sync primitive, w/normal access semantics.
 volatile *vp = ;  // a true volatile reference.

 vv; // volatile sync, all pending volatile transactions logically emitted
 // into the code, but not hard physically synchronized via a HW sync.

 vc; // universal sync, all pending transactions hard physically sync'ed.

 *vp = ; // volatile access semantics enforced, with ordering
 // warranted between equivalent references, but not
 // otherwise (unless synchronized by referencing a
 // declared or (cast) volatile sync variable).

(with the exception of new sync semantics, non-reference volatile variables
 do not need to have volatile access semantics, as it would seem to serve
 no useful purpose for stack/heap allocated variables, and should be allowed
 to be optimized always just as for any other allocated variable; although
 their sync, semantic actions must be preserved, thereby may still be used
 as synchronized value semaphores, etc, or as simply sync's when no access
 would otherwise be required; and/or allow regular variables to be cast as
 (volatile), thereby enabling a arbitrary expression to insert a sync, i.e.:
 (volatile)x = y, or x = (const volatile)y; forcing a specified sync prior
 to, or after the assignment?)

Where the above is just expressed as a loose possible alternative to
strictly enforcing ordering between all volatile or otherwise transactions
without having to necessarily introduce another keyword, for good or bad.

Re: struct __attribute((packed));

[E. Weddington]

Paul Koning wrote:
It sure would be useful, though, if there were a construct that does
mean "pointer to packed T".  In particular, I've often needed "pointer
to packed int" and found no way to produce that.  I ended up creating
a one-member struct with a packed int inside, which is a syntactic
nightmare.   (The application was a piece of legacy code that was
writing via int pointers, but sometimes things were not aligned.  The
fix was much more invasive than it should have been because I could
find no way to define a pointer to packed int.)  If there IS a way to
do that, it sure would be nice for the docs to explain it.  Right now
the documentation of "packed" is essentially unintellegible.
 

According to the docs here:

what about doing something like this?:
---
typedef int packed_int __attribute__ ((aligned (1)));
packed_int *ppi;
---
Eric

RE: struct __attribute((packed));

[Dave Korn]

Original Message
>From: E. Weddington
>Sent: 15 April 2005 17:10

> Ralf Corsepius wrote:

>> struct entrystruct * entry __attribute__ ((packed));
>> 
>> is interpreted as "packed pointer to struct"
>> not as "pointer to packed struct",
>> 
>> 
> I would interpret it that way too: packed pointer to struct. The
> "packed" attribute is on the variable itself, not the type of the
> variable (pointer to struct)
   [...snip!...]
> Yeah, if that author was thinking that the packed attribute applied to
> what the variable pointed to, then I would think that it is wrong usage
> of the attribute.


  I've often wished that __attribute__s would behave like CV-quals:

char * const ptr;

  == const pointer to char

struct entrystruct * __attribute__ ((packed)) entry;

  == packed pointer to struct

char const *  ptr;

  == pointer to const char

struct entrystruct __attribute__ ((packed))  * entry;

  ==  pointer to packed struct

  I haven't done an exhaustive survey of attributes, but I know it doesn't
work that way for section attributes, and there have been times when I would
have liked it to.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: Heads-up: volatile and C++

[Paul Koning]

> "Paul" == Paul Schlie <[EMAIL PROTECTED]> writes:

 >> Michael N. Moran wrote: I'm very much in favor of fine grained
 >> synchronization primitives in the compiler, but not of changes to
 >> volatile semantics.

 Paul> I wonder if it would be sufficient (if not preferable) to only
 Paul> extend (modify) the semantics for heap/stack and const volatile
 Paul> variables, as enforcing existing volatile semantics for such
 Paul> variables are at best of questionable existing value

I'm not sure I completely understand, but volatile heap variables are
perfectly meaningful today.  For example, if I need to define a
communication data area for the program to talk to some DMA I/O
device, a volatile struct, or a struct some of whose members are
volatile, allocated on the heap, makes perfect sense.

  paul

Re: struct __attribute((packed));

[E. Weddington]

Dave Korn wrote:

 I've often wished that __attribute__s would behave like CV-quals:
char * const ptr;
 == const pointer to char
struct entrystruct * __attribute__ ((packed)) entry;
 == packed pointer to struct
char const *  ptr;
 == pointer to const char
struct entrystruct __attribute__ ((packed))  * entry;
 ==  pointer to packed struct
 I haven't done an exhaustive survey of attributes, but I know it doesn't
work that way for section attributes, and there have been times when I would
have liked it to.
 

That's got my vote! (As if anyone's counting). That would make things so 
much easier, for example, in the AVR port for dealing with multiple 
memory spaces.

Eric

Re: struct __attribute((packed));

[Paul Koning]

> "E" == E Weddington <[EMAIL PROTECTED]> writes:

 E> Paul Koning wrote:
 >> It sure would be useful, though, if there were a construct that
 >> does mean "pointer to packed T".  In particular, I've often needed
 >> "pointer to packed int" and found no way to produce that.  I ended
 >> up creating a one-member struct with a packed int inside, which is
 >> a syntactic nightmare.  (The application was a piece of legacy
 >> code that was writing via int pointers, but sometimes things were
 >> not aligned.  The fix was much more invasive than it should have
 >> been because I could find no way to define a pointer to packed
 >> int.)  If there IS a way to do that, it sure would be nice for the
 >> docs to explain it.  Right now the documentation of "packed" is
 >> essentially unintellegible.
 >> 
 >> 
 >> 
 >> 
 E> According to the docs here:
 E> 


 E> what about doing something like this?:

 E> --- typedef int packed_int
 E> __attribute__ ((aligned (1)));

 E> packed_int *ppi;

That would make sense, but it has never worked for me.  It seems that
attributes don't apply to type names, only to variables and members. 

   paul

Re: struct __attribute((packed));

[E. Weddington]

Paul Koning wrote:
E> According to the docs here:
E> 

E> what about doing something like this?:
E> typedef int packed_int
E> __attribute__ ((aligned (1)));
E> packed_int *ppi;
That would make sense, but it has never worked for me.  It seems that
attributes don't apply to type names, only to variables and members. 

 

What?! That whole section in the docs talks about attributes on types. 
If it doesn't work as described, then the docs need some serious rework.

Eric

Re: Processor-specific code

[Richard Earnshaw]

On Fri, 2005-04-15 at 15:50, Robert Dewar wrote:
> Richard Earnshaw wrote:
> 
> > Not all environments can change the rounding mode dynamically.  For
> > example, on the FPA co-processor for ARM, rounding is set by the
> > instruction selected -- so the concept of having an environment variable
> > to control this is meaningless.
> 
> Right, such a feature obviously does not apply to hardware that is this
> far from the IEEE standard (which requires dynamic control). The Alpha
> architecture has similar problems.

Precisely which statement in IEEE 754-1985 states this?  As far as I can
tell this standard is a mathematical abstraction for mapping floating
point onto machine types.  Chapter 4 describes the required rounding
modes but definitely makes no statement saying that this has to be
selectable in a dynamic manner.

R.

RE: Processor-specific code

[Dave Korn]

Original Message
>From: Richard Earnshaw
>Sent: 15 April 2005 17:42

> On Fri, 2005-04-15 at 15:50, Robert Dewar wrote:
>> Richard Earnshaw wrote:
>> 
>>> Not all environments can change the rounding mode dynamically.  For
>>> example, on the FPA co-processor for ARM, rounding is set by the
>>> instruction selected -- so the concept of having an environment variable
>>> to control this is meaningless.
>> 
>> Right, such a feature obviously does not apply to hardware that is this
>> far from the IEEE standard (which requires dynamic control). The Alpha
>> architecture has similar problems.
> 
> Precisely which statement in IEEE 754-1985 states this?  As far as I can
> tell this standard is a mathematical abstraction for mapping floating
> point onto machine types.  Chapter 4 describes the required rounding
> modes but definitely makes no statement saying that this has to be
> selectable in a dynamic manner.
> 
> R.

  Doesn't the C language spec require the mode to be switchable at runtime?

  In any case, the ARM or Alpha isn't prevented from working in such a
fashion just because the rounding mode is encoded in the instruction; it
just means that fp primitives have to be compiled as intrinsics that test
whatever flag controls the rounding mode and then branch to an fp insn of
the appropriate form.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: struct __attribute((packed));

[Paul Koning]

> "E" == E Weddington <[EMAIL PROTECTED]> writes:

 E> Paul Koning wrote: According to the docs here:
 E> 

 >>
 E> what about doing something like this?:
 >>
 E> typedef int packed_int __attribute__ ((aligned (1)));
 >>
 E> packed_int *ppi;
 >> That would make sense, but it has never worked for me.  It seems
 >> that attributes don't apply to type names, only to variables and
 >> members.
 >> 
 >> 
 >> 
 E> What?! That whole section in the docs talks about attributes on
 E> types. If it doesn't work as described, then the docs need some
 E> serious rework.

I'd rather the compiler got the work than the docs.

Maybe it's better in newer versions; I don't have anything newer than
3.4.1 built right now.

Test program:

typedef int pi __attribute__((packed));

void set(void *p, int v)
{
pi *ppi;

ppi = (pi *) p;
*ppi = v;
}

On 3.3.3, this compiles without any warnings (in spite of -Wall) but
the store is an aligned store (MIPS "sw" instruction).

With 3.4.1, I get this:

test.c:1: warning: `packed' attribute ignored

Sigh.

And yes, I agree with Dave that having attributes work syntactically
the same as CV-modifiers -- so they can be directly applied to the
pointed-to type in pointer declarations -- would be a Good Thing.

   paul

RE: Processor-specific code

[Paul Koning]

> "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.  It
doesn't on VAX, PDP-11, PDP-10, ...

paul

RE: struct __attribute((packed));

[Joseph S. Myers]

On Fri, 15 Apr 2005, Dave Korn wrote:

>   I've often wished that __attribute__s would behave like CV-quals:

The syntax of attributes is documented in the Attribute Syntax section of 
the manual.

http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html

Nested in pointer sequences they do act like cv-quals.  In amongst the 
declaration specifiers on a declaration they act like storage class 
specifiers, but a particular attribute's handler can make them act like 
cv-quals there as well if not constrained by compatibility with how 
previous versions of GCC implemented the attribute.  (See how this is done 
for vector_size attributes.)

The __section__ attribute is purely a storage-class-like attribute.  If 
you want DTR18037 address space specifiers, feel free to implement them; 
they are probably the least problematic part of that TR.

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

Re: [m68k]: More trouble with byte moves into Address registers

[Peter Barada]

>> (insn 5559 5558 5560 694 pp_pack.c:2144 (set (reg:SI 1421)
>> (plus:SI (subreg:SI (reg:QI 1420) 0)
>> (const_int -32 [0xffe0]))) 121 {*addsi3_5200} (insn_list 
>> 5558 (nil))
>> (nil))
>
>So register 1420 is being assigned to a data register.  The
>constraints for addsi3_5200 permit the following alternatives:
>mem += datareg
>addrreg = addrreg + reg|constant
>addrreg = reg|constant + addrreg
>reg += mem|reg|constant
>There is no alternative which permits adding a data register and a
>constant and putting the result in an address register.  So reload
>picks the alternative "addrreg = addrreg + reg|constant", and decides
>to reload register 1420 into an address register.  But that fails
>because reload can't find an address register which can accept a
>QImode value.

Would it help to rearrange the constraints to have reg +=
mem|reg|constant before the addreg += ...  ?

>Looking at the dump a little more, it's far from clear why register
>1421 is being put into an address register.  I see that insn 5560
>wants to compare a byte value which it finds there, so it doesn't seem
>like a good fit to put 1421 into an address register.
>
>
>I don't know where else register 1421 is being used, so my tentative
>guess would be that gcc is picking an address register based on the
>constraints in addsi3_5200.  Perhaps you need to change "?a" to "*a".
>After all, you probably don't want to encourage pseudos to go into the
>address registers merely because you add values to them.

1421 is only used in 5559 and 5560.  from the lreg dump:

Register 1421 used 2 times across 2 insns in block 694; set 1 time; pref 
DATA_REGS.

>But it is also possible that register 1421 is being put into an
>address register merely because all the data registers are taken and
>there is nothing which forces 1421 to be in a data register.

In the function S_unpack_rec, there are 190 registers to allocate, so
I'd guess everything will be in use.

>Or, you might permit an alternative "a a*r rJK" in addsi3_5200.  You
>can implement that using a two instruction sequence--copy the data
>register to the address register, and then add.  This is obviously not
>ideal, but it's more or less what reload would be doing anyhow.
>
>
>In general, though, I'm not sure that prohibiting QImode values in
>address registers is going to be a useful approach.  After all, the
>values do fit there, and while we want to discourage it, it's not
>obvious that we want to completely prohibit it.  The problem in PR
>18421 is that reload decided that it had to reload a QImode value from
>memory into an address register, but it couldn't.  That is more or
>less easy to handle by defining SECONDARY_RELOAD_CLASS to indicate
>that a data register is required to move QImode values between the
>address registers and memory, and by defining reload_inqi and
>reload_outqi to do the moves.

The problem is that there is no valid QImode instruction that can move
values in/out of an address register

This has been an ongoing problem for more than a year, and each
"fix" treats the particular bug/problem at hand.  rth is the one who
recommended punting QImode out of address registers:

http://gcc.gnu.org/ml/gcc/2003-07/msg00743.html

Looking over the code, I see that PREFERRED_RELOAD_CLASS is:

#define PREFERRED_RELOAD_CLASS(X,CLASS)  \
  ((GET_CODE (X) == CONST_INT   \
&& (unsigned) (INTVAL (X) + 0x80) < 0x100   \
&& (CLASS) != ADDR_REGS)\
   ? DATA_REGS  \
   : (GET_MODE (X) == QImode && (CLASS) != ADDR_REGS) \
   ? DATA_REGS  \
   : (GET_CODE (X) == CONST_DOUBLE  \
  && GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT)   \
   ? ((TARGET_68881|TARGET_CFV4E) && (CLASS == FP_REGS || CLASS == 
DATA_OR_FP_REGS) \
  ? FP_REGS : NO_REGS)  \
   : (TARGET_PCREL  \
  && (GET_CODE (X) == SYMBOL_REF || GET_CODE (X) == CONST \
  || GET_CODE (X) == LABEL_REF))\
   ? ADDR_REGS  \
   : (CLASS))

Which looks like it allows QImode into ADDR_REGS instead
of insisting on DATA_REGS.  Do you think this should be:
  
#define PREFERRED_RELOAD_CLASS(X,CLASS)  \
  (((GET_CODE (X) == CONST_INT  \
&& (unsigned) (INTVAL (X) + 0x80) < 0x100)  \
|| GET_MODE(X) == QImode)   \
   ? DATA_REGS  \
   : (GET_CODE (X) == CONST_DOUBLE  \
  && GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT)   \
   ? ((TARGET_68881|TARGET_CFV4E) && (CLASS == FP_REGS || CLASS == 
DATA_OR_FP_REGS) \
  ? FP_REGS : NO_REGS)  \
   : (TARGET_PCREL  \
  && (GET_CODE (X) == SYMBOL_REF || GET_CODE (X) == CONST \
 

Re: struct __attribute((packed));

[Dale Johannesen]

On Apr 15, 2005, at 8:27 AM, E. Weddington wrote:
Ralf Corsepius wrote:
Hi,
I just tripped over this snipped below in a piece of code, I didn't
write and which I don't understand:
...
struct somestruct {
 struct entrystruct *e1 __attribute__ ((packed));
 struct entrystruct *e2 __attribute__ ((packed));
};
...
Is this meaningful?
I guess the author wanted e1 and e2 to point to a "packed struct 
entrystruct", but this doesn't seem to be what GCC
interprets this code.
There is no reason a definition of "struct entrystruct" should even be 
visible at
this point, so that doesn't seem like a very reasonable interpretation.

Re: Heads-up: volatile and C++

[Gabriel Dos Reis]

Marcin Dalecki <[EMAIL PROTECTED]> writes:

| On 2005-04-15, at 01:10, Richard Henderson wrote:
| 
| > On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote:
| >> Consider Double-Checked Locking
| >> (http://www.cs.umd.edu/~pugh/java/memoryModel/
| >> DoubleCheckedLocking.html).
| >> I used DCL with explicit memory barriers to implement thread-safe
| >> initialization of function-local statics
| >> (libstdc++-v3/libsupc++/guard.cc).  The proposed change to volatile
| >> semantics would allow me to write it more simply, by just making the
| >> initialized flag volatile.  Yes, volatile would be stronger than is
| >> actually necessary for DCLP, but I don't have to use it if I want
| >> finer-grained control over the synchronization.
| >
| > Is there any reason to want to overload volatile for this, rather than
| >
| >   template T acquire(T *ptr);
| >   template void release(T *ptr, T val);
| >
| > where the functions do the indirection plus the memory ordering?
| 
| Templates are a no-go for a well known and well defined subset for C++
| for embedded programming known commonly as well embedded C++.

You'd be surprised to learn that embedded systems people do use
templates for various things -- among which, maybe the most
"paradoxical" is to avoid code bloat.

Embedded C++ was a mistake, alas a mistake that seems to last.

-- Gaby

RE: Processor-specific code

[Richard Earnshaw]

On Fri, 2005-04-15 at 17:49, Dave Korn wrote:
> Original Message
> >From: Richard Earnshaw
> >Sent: 15 April 2005 17:42
> 
> > On Fri, 2005-04-15 at 15:50, Robert Dewar wrote:
> >> Richard Earnshaw wrote:
> >> 
> >>> Not all environments can change the rounding mode dynamically.  For
> >>> example, on the FPA co-processor for ARM, rounding is set by the
> >>> instruction selected -- so the concept of having an environment variable
> >>> to control this is meaningless.
> >> 
> >> Right, such a feature obviously does not apply to hardware that is this
> >> far from the IEEE standard (which requires dynamic control). The Alpha
> >> architecture has similar problems.
> > 
> > Precisely which statement in IEEE 754-1985 states this?  As far as I can
> > tell this standard is a mathematical abstraction for mapping floating
> > point onto machine types.  Chapter 4 describes the required rounding
> > modes but definitely makes no statement saying that this has to be
> > selectable in a dynamic manner.
> > 
> > R.
> 
>   Doesn't the C language spec require the mode to be switchable at runtime?
> 
>   In any case, the ARM or Alpha isn't prevented from working in such a
> fashion just because the rounding mode is encoded in the instruction; it
> just means that fp primitives have to be compiled as intrinsics that test
> whatever flag controls the rounding mode and then branch to an fp insn of
> the appropriate form.

c90 doesn't require anything; it's all new in c99.

C99 has a number of functions and defines a number of macros *iff* the
environment supports rounding switching.  It certainly doesn't require
it.

Code that changes the rounding has to be wrapped with certain pragmas to
inform the compiler that this might happen: on something like ARM+FPA
that might permit dynamic code switching, but I doubt anyone would
really want to pay that price.

R.

Re: struct __attribute((packed));

[E. Weddington]

Paul Koning wrote:
"E" == E Weddington <[EMAIL PROTECTED]> writes:
   


E> typedef int packed_int __attribute__ ((aligned (1)));
I'd rather the compiler got the work than the docs.
Maybe it's better in newer versions; I don't have anything newer than
3.4.1 built right now.
Test program:
typedef int pi __attribute__((packed));
 

No, look what I wrote above. Can you try using the *aligned* attribute?:
typedef int packed_int __attribute__ ((aligned (1)));

void set(void *p, int v)
{
   pi *ppi;
   
   ppi = (pi *) p;
   *ppi = v;
}

 

Eric

Re: struct __attribute((packed));

[Andrew Haley]

E. Weddington writes:
 > Paul Koning wrote:
 > 
 > >>"E" == E Weddington <[EMAIL PROTECTED]> writes:
 > >>
 > >>
 > >
 > > 
 > > E> typedef int packed_int __attribute__ ((aligned (1)));
 > >
 > >I'd rather the compiler got the work than the docs.
 > >
 > >Maybe it's better in newer versions; I don't have anything newer than
 > >3.4.1 built right now.
 > >
 > >Test program:
 > >
 > >typedef int pi __attribute__((packed));
 > >
 > >  
 > >
 > No, look what I wrote above. Can you try using the *aligned* attribute?:
 > 
 > typedef int packed_int __attribute__ ((aligned (1)));

gcc.info:

 The `aligned' attribute can only increase the alignment; but you
 can decrease it by specifying `packed' as well.  See below.

Andrew.

RE: Processor-specific code

[Dave Korn]

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.  

  I'm not sure.  Either you don't get me, or I don't get you, but what I
thought I was describing was a way of working around the lack of a
switchable mode by compiling the code both ways with a runtime test of a
flag.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

RE: Processor-specific code

[Dave Korn]

Original Message
>From: Richard Earnshaw
>Sent: 15 April 2005 18:08

>>   In any case, the ARM or Alpha isn't prevented from working in such a
>> fashion just because the rounding mode is encoded in the instruction; it
>> just means that fp primitives have to be compiled as intrinsics that test
>> whatever flag controls the rounding mode and then branch to an fp insn of
>> the appropriate form.

> Code that changes the rounding has to be wrapped with certain pragmas to
> inform the compiler that this might happen: on something like ARM+FPA
> that might permit dynamic code switching, but I doubt anyone would
> really want to pay that price.


  It's a very arch-dependent price, though.  On an arch where you have
conditional execution per-instruction, it could be a very low overhead
indeed.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: "make bootstrap" for cross builds

[Janis Johnson]

On Fri, Apr 15, 2005 at 01:23:39AM -0400, Andrew Pinski wrote:
> 
> On Apr 15, 2005, at 1:19 AM, Ranjit Mathew wrote:
> 
> >Hi,
> >
> >  I think "make bootstrap" does not make sense for
> >cross builds. We however seem to allow it but
> >fail in a weird way later on (as on mainline).
> >I think this should not be allowed.
> >
> >I discovered this when I mistakenly typed
> >"make bootstrap" out of habit on a cross build.
> 
> Huh? there is one case where this does makes sense, take for example:
> ppc64-linux-gnu, you were running the ppc-linux-gnu compiled GCC and 
> you need
> a 64bit compatible one.  You can compile with --with-cpu=default32 and 
> still
> have a "cross" compiler but can still do a native compiling, it is 
> weird case
> but it does show up.

I always set build, host, and target to powerpc64-linux when
bootstrapping a biarch compiler, and use --with-cpu=default32 to
generate 32-bit binaries by default.  I seem to recall running
into problems when they weren't all the same for bootstraps.

Janis

Re: struct __attribute((packed));

[E. Weddington]

Andrew Haley wrote:
gcc.info:
The `aligned' attribute can only increase the alignment; but you
can decrease it by specifying `packed' as well.  See below.
 

Thanks for the correction.
Bleah. :-P
I'll go back into lurk mode now
Eric

Re: [m68k]: More trouble with byte moves into Address registers

[Ian Lance Taylor]

Peter Barada <[EMAIL PROTECTED]> writes:

> >So register 1420 is being assigned to a data register.  The
> >constraints for addsi3_5200 permit the following alternatives:
> >mem += datareg
> >addrreg = addrreg + reg|constant
> >addrreg = reg|constant + addrreg
> >reg += mem|reg|constant
> >There is no alternative which permits adding a data register and a
> >constant and putting the result in an address register.  So reload
> >picks the alternative "addrreg = addrreg + reg|constant", and decides
> >to reload register 1420 into an address register.  But that fails
> >because reload can't find an address register which can accept a
> >QImode value.
> 
> Would it help to rearrange the constraints to have reg +=
> mem|reg|constant before the addreg += ...  ?

Probably not in this case.  You could try it.  It is true that when
two alternatives have the same cost, reload will pick the first one
listed.


> >Looking at the dump a little more, it's far from clear why register
> >1421 is being put into an address register.  I see that insn 5560
> >wants to compare a byte value which it finds there, so it doesn't seem
> >like a good fit to put 1421 into an address register.
> >
> >
> >I don't know where else register 1421 is being used, so my tentative
> >guess would be that gcc is picking an address register based on the
> >constraints in addsi3_5200.  Perhaps you need to change "?a" to "*a".
> >After all, you probably don't want to encourage pseudos to go into the
> >address registers merely because you add values to them.
> 
> 1421 is only used in 5559 and 5560.  from the lreg dump:
> 
> Register 1421 used 2 times across 2 insns in block 694; set 1 time; pref 
> DATA_REGS.

That is odd.  Your earlier e-mail seemed to show that register 1421
was specifically put into an address register, specifically %a0.  Why
would that happen if it has a preference for DATA_REGS?  Was it
assigned by local-alloc?  In that case you would see a line like ";;
Register 2421 in NNN." in the .lreg dump file.


> >In general, though, I'm not sure that prohibiting QImode values in
> >address registers is going to be a useful approach.  After all, the
> >values do fit there, and while we want to discourage it, it's not
> >obvious that we want to completely prohibit it.  The problem in PR
> >18421 is that reload decided that it had to reload a QImode value from
> >memory into an address register, but it couldn't.  That is more or
> >less easy to handle by defining SECONDARY_RELOAD_CLASS to indicate
> >that a data register is required to move QImode values between the
> >address registers and memory, and by defining reload_inqi and
> >reload_outqi to do the moves.
> 
> The problem is that there is no valid QImode instruction that can move
> values in/out of an address register

I know.  I'm suggesting that QImode values have to move in and out of
address registers via data registers, so you just put the QImode value
into the data register, and then move it into the address register, or
vice-versa.

But I see from your reference that Jim Wilson already suggested this,
and that RTH advised against it.  Hmmm.


> Looking over the code, I see that PREFERRED_RELOAD_CLASS is:

...

> Which looks like it allows QImode into ADDR_REGS instead
> of insisting on DATA_REGS.  Do you think this should be:

No, that will break reload.  If it calls PREFERRED_RELOAD_CLASS with
ADDR_REGS, then it has already selected an alternative which requires
ADDR_REGS.  Returning a register class which does not permit any
register in ADDR_REGS will give you a constraint violation later on.


You could probably get this to work if you changed "?a" to "!a" in
addsi3_5200.  But that would probably give you worse code when dealing
with SImode value.

You could probably get this to work if you wrote the predicate for
addsi3_5200 to specifically reject a subreg:SI of a QImode value, and
then defined a new insn which specifically accepted it and nothing
else, but did not permit address registers in the alternatives.  You
might have to play similar tricks with some other instructions, but
perhaps addsi3 is relatively special here, just to handle cases
generated by reload.

Ian

RE: Processor-specific code

[Paul Koning]

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

   paul

Re: Heads-up: volatile and C++

[Michael N. Moran]

Gabriel Dos Reis wrote:
Marcin Dalecki <[EMAIL PROTECTED]> writes:
| Templates are a no-go for a well known and well defined subset for C++
| for embedded programming known commonly as well embedded C++.
You'd be surprised to learn that embedded systems people do use
templates for various things -- among which, maybe the most
"paradoxical" is to avoid code bloat.
Embedded C++ was a mistake, alas a mistake that seems to last.
Just in case there is any voting going on here ... agreed :)
--
Michael N. Moran   (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144http://mnmoran.org
"So often times it happens, that we live our lives in chains
 and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1

Re: Processor-specific code

[Vincent Lefevre]

On 2005-04-14 10:35:06 -0700, Richard Henderson wrote:
> All that said, C99 has  to control just about anything you
> could want about the fpu.

It is not possible to change the rounding precision with .

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: Heads-up: volatile and C++

[Michael N. Moran]

Paul Schlie wrote:
Michael N. Moran wrote:
I'm very much in favor of fine grained synchronization primitives
in the compiler, but not of changes to volatile semantics.

I wonder if it would be sufficient (if not preferable) to only extend
(modify) the semantics for heap/stack and const volatile variables, as
enforcing existing volatile semantics for such variables are at best
of questionable existing value. i.e.:
 volatile vv;// volatile sync primitive, w/normal access semantics.
 volatile const vc;  // universal sync primitive, w/normal access semantics.
 volatile *vp = ;  // a true volatile reference.
 vv; // volatile sync, all pending volatile transactions logically emitted
 // into the code, but not hard physically synchronized via a HW sync.
 vc; // universal sync, all pending transactions hard physically sync'ed.
 *vp = ; // volatile access semantics enforced, with ordering
 // warranted between equivalent references, but not
 // otherwise (unless synchronized by referencing a
 // declared or (cast) volatile sync variable).
(with the exception of new sync semantics, non-reference volatile variables
 do not need to have volatile access semantics, as it would seem to serve
 no useful purpose for stack/heap allocated variables, and should be allowed
 to be optimized always just as for any other allocated variable; although
 their sync, semantic actions must be preserved, thereby may still be used
 as synchronized value semaphores, etc, or as simply sync's when no access
 would otherwise be required; and/or allow regular variables to be cast as
 (volatile), thereby enabling a arbitrary expression to insert a sync, i.e.:
 (volatile)x = y, or x = (const volatile)y; forcing a specified sync prior
 to, or after the assignment?)
I'm not certain I understand what you are proposing, other than
there being some difference connection between how objects are
declared (their scope) and the semantics attached with uses of
the object.
What happens to volatile pointers/references passed through
functions? Which "semantic" would be emitted by the compiler when
these are dereferenced?
Even without a thorough understanding, on the surface,
this seems ... unintuitive.
Where the above is just expressed as a loose possible alternative to
strictly enforcing ordering between all volatile or otherwise transactions
without having to necessarily introduce another keyword, for good or bad.
I guess that the reason adding new keywords is a problem is its
interaction with existing C++ code? Sorry, I'm not an expert.
--
Michael N. Moran   (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144http://mnmoran.org
"So often times it happens, that we live our lives in chains
 and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1

Re: Processor-specific code

[Paul Brook]

On Friday 15 April 2005 18:43, Vincent Lefevre wrote:
> On 2005-04-14 10:35:06 -0700, Richard Henderson wrote:
> > All that said, C99 has  to control just about anything you
> > could want about the fpu.
>
> It is not possible to change the rounding precision with .

That's because it's an x86/m68k specific implementation detail and the 
compiler should be setting it for you. gcc doesn't do this because noone 
cares enough to implement it.

Paul

Re: inline-unit-growth trouble

[Richard Guenther]

On 4/15/05, Andreas Krebbel <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> on S/390 we have currently a plenty of testsuite failures
> due to inlining effects.
> 
> ld complains about testcases which try to link two files containing the same 
> function
> in .gnu.linkonce sections but with different code sizes. The sizes differ due
> to different inlining decisions. The problem is that inlining maybe
> prevented by global limits which maybe exceeded for one file but not for
> the other.
> The actual problem occurred with the "inline-unit-growth" limit which
> may prevent inlining for a function in one file and allow it for the same
> function in another.
> 
> I'm not sure how to fix that issue. To my mind the whole concept of per unit
> limits influencing local inlining decisions seems a bit questionable.

Why does the linker not just pick either of the functions?  The size
difference should not matter.

Richard.

Re: [m68k]: More trouble with byte moves into Address registers

[Peter Barada]

>> Would it help to rearrange the constraints to have reg +=
>> mem|reg|constant before the addreg += ...  ?
>
>Probably not in this case.  You could try it.  It is true that when
>two alternatives have the same cost, reload will pick the first one
>listed.

With my luck that will cause a bigger problem somewhere else. :)  I'll
try it once I get past this.

>> >I don't know where else register 1421 is being used, so my tentative
>> >guess would be that gcc is picking an address register based on the
>> >constraints in addsi3_5200.  Perhaps you need to change "?a" to "*a".
>> >After all, you probably don't want to encourage pseudos to go into the
>> >address registers merely because you add values to them.
>> 
>> 1421 is only used in 5559 and 5560.  from the lreg dump:
>> 
>> Register 1421 used 2 times across 2 insns in block 694; set 1 time; pref 
>> DATA_REGS.
>
>That is odd.  Your earlier e-mail seemed to show that register 1421
>was specifically put into an address register, specifically %a0.  Why
>would that happen if it has a preference for DATA_REGS?  Was it
>assigned by local-alloc?  In that case you would see a line like ";;
>Register 2421 in NNN." in the .lreg dump file.

Uggh.  I've been trying changes currently so I don't have the original
compiler to regenerate the output.

>> The problem is that there is no valid QImode instruction that can move
>> values in/out of an address register
>
>I know.  I'm suggesting that QImode values have to move in and out of
>address registers via data registers, so you just put the QImode value
>into the data register, and then move it into the address register, or
>vice-versa.

Is there another backend in GCC I can look at for examples of how this
is done?

>> Which looks like it allows QImode into ADDR_REGS instead
>> of insisting on DATA_REGS.  Do you think this should be:
>
>No, that will break reload.  If it calls PREFERRED_RELOAD_CLASS with
>ADDR_REGS, then it has already selected an alternative which requires
>ADDR_REGS.  Returning a register class which does not permit any
>register in ADDR_REGS will give you a constraint violation later on.

Well I tried it anyway and was able to build a complete C
toolchain(including glibc-2.3.2), but it blew up at the same point
building perl with a constraint violation of:

pp_pack.c: In function `S_unpack_rec':
pp_pack.c:2220: error: insn does not satisfy its constraints:
(insn 5559 8594 8595 694 pp_pack.c:2144 (set (reg:SI 8 %a0 [1421])
(plus:SI (reg:SI 0 %d0)
(const_int -32 [0xffe0]))) 121 {*addsi3_5200} (insn_list 5558 
(nil))
(nil))
pp_pack.c:2220: internal compiler error: in reload_cse_simplify_operands, at 
postreload.c:391

This would be easy to fix by adding "?r/r/mi" to addsi3_5200 and
emit code that first 'move.l %1,%0', and then add the string from
output_addsi3().

That is assuming that changing PREFERRED_RELOAD_CLASS this way doesn't
severely break reload.

Where in reload would you think it decides that it absolutely has to
have an ADDR_REG for 1421?  I'll dig into it with gdb, but there's so
much code in reload that a clue or two would *really* help :)

I'll undo the change to PREFERRED_RELOAD_CLASS, and then change the
'?a' to '*a' in addsi3_5200 to see if that helps reload to not pick
and ADDR_REG for the value.  If it still fails, I'll regenerate all
the information as I did in the 2nd email to you.

Thanks!

-- 
Peter Barada
[EMAIL PROTECTED]

Re: inline-unit-growth trouble

[Andrew Pinski]

> 
> On 4/15/05, Andreas Krebbel <[EMAIL PROTECTED]> wrote:
> > Hi,
> > 
> > on S/390 we have currently a plenty of testsuite failures
> > due to inlining effects.
> > 
> > ld complains about testcases which try to link two files containing the 
> > same function
> > in .gnu.linkonce sections but with different code sizes. The sizes differ 
> > due
> > to different inlining decisions. The problem is that inlining maybe
> > prevented by global limits which maybe exceeded for one file but not for
> > the other.
> > The actual problem occurred with the "inline-unit-growth" limit which
> > may prevent inlining for a function in one file and allow it for the same
> > function in another.
> > 
> > I'm not sure how to fix that issue. To my mind the whole concept of per unit
> > limits influencing local inlining decisions seems a bit questionable.
> 
> Why does the linker not just pick either of the functions?  The size
> difference should not matter.

The linker warns about them being different sizes.  Oh well.  Someone
would need to look into how to fix this.

-- Pinski

Re: [m68k]: More trouble with byte moves into Address registers

[Ian Lance Taylor]

Peter Barada <[EMAIL PROTECTED]> writes:

> >> The problem is that there is no valid QImode instruction that can move
> >> values in/out of an address register
> >
> >I know.  I'm suggesting that QImode values have to move in and out of
> >address registers via data registers, so you just put the QImode value
> >into the data register, and then move it into the address register, or
> >vice-versa.
> 
> Is there another backend in GCC I can look at for examples of how this
> is done?

Well, the i386, for example, does it for QImode spills from anything
other than the basic four registers.  Look at
SECONDARY_OUTPUT_RELOAD_CLASS and reload_outqi.


> >> Which looks like it allows QImode into ADDR_REGS instead
> >> of insisting on DATA_REGS.  Do you think this should be:
> >
> >No, that will break reload.  If it calls PREFERRED_RELOAD_CLASS with
> >ADDR_REGS, then it has already selected an alternative which requires
> >ADDR_REGS.  Returning a register class which does not permit any
> >register in ADDR_REGS will give you a constraint violation later on.
> 
> Well I tried it anyway and was able to build a complete C
> toolchain(including glibc-2.3.2), but it blew up at the same point
> building perl with a constraint violation of:
> 
> pp_pack.c: In function `S_unpack_rec':
> pp_pack.c:2220: error: insn does not satisfy its constraints:
> (insn 5559 8594 8595 694 pp_pack.c:2144 (set (reg:SI 8 %a0 [1421])
> (plus:SI (reg:SI 0 %d0)
> (const_int -32 [0xffe0]))) 121 {*addsi3_5200} (insn_list 5558 
> (nil))
> (nil))
> pp_pack.c:2220: internal compiler error: in reload_cse_simplify_operands, at 
> postreload.c:391
> 
> This would be easy to fix by adding "?r/r/mi" to addsi3_5200 and
> emit code that first 'move.l %1,%0', and then add the string from
> output_addsi3().

If you add that alternative, then you don't need to change
PREFERRED_RELOAD_CLASS anyhow.

> That is assuming that changing PREFERRED_RELOAD_CLASS this way doesn't
> severely break reload.

It will.  Don't do it.  Once reload has decided that it needs
ADDR_REGS, you can't use PREFERRED_RELOAD_CLASS to back out of that
decision.

> Where in reload would you think it decides that it absolutely has to
> have an ADDR_REG for 1421?  I'll dig into it with gdb, but there's so
> much code in reload that a clue or two would *really* help :)

Basically, it's because reload decided that the best matching
alternative was the one which used address regs for both registers.
This presumably happened in find_reloads.

Ian

Re: Heads-up: volatile and C++

[Mike Stump]

On Thursday, April 14, 2005, at 08:48  PM, Marcin Dalecki wrote:
Templates are a no-go for a well known and well defined subset for C++
for embedded programming known commonly as well embedded C++.
My god, you didn't actually buy into that did you?  Hint, it was is, 
and always will be a joke.

Re: Semi-Latent Bug in tree vectorizer

[Diego Novillo]

On Fri, Apr 15, 2005 at 10:18:35AM -0600, Jeffrey A Law wrote:

> I went ahead and ran this through the usual bootstrap and regression
> test.  Installed this morning...
> 
Excellent.  Thanks.


Diego.

Re: Heads-up: volatile and C++

[Mike Stump]

On Friday, April 15, 2005, at 10:58  AM, Gabriel Dos Reis wrote:
Embedded C++ was a mistake, alas a mistake that seems to last.
No, there are just confused people in the world that think that it is 
relevant because they just don't know better, treat the as you'd treat 
a person that talks about a flat world.  Laugh at them, the hard core 
ones will cling forever, but the normal people will get a clue.

Re: Processor-specific code

[Mike Stump]

On Friday, April 15, 2005, at 09:55  AM, Paul Koning wrote:
That only works if the notion of switchable rounding mode exists.  It
doesn't on VAX, PDP-11, PDP-10, ...
What, you mean VAX isn't turing complete?  :-)

Re: Heads-up: volatile and C++

[Paul Schlie]

> From: Paul Koning <[EMAIL PROTECTED]>
>> "Paul" == Paul Schlie <[EMAIL PROTECTED]> writes:
> 
>>> Michael N. Moran wrote: I'm very much in favor of fine grained
>>> synchronization primitives in the compiler, but not of changes to
>>> volatile semantics.
> 
>  Paul> I wonder if it would be sufficient (if not preferable) to only
>  Paul> extend (modify) the semantics for heap/stack and const volatile
>  Paul> variables, as enforcing existing volatile semantics for such
>  Paul> variables are at best of questionable existing value
> 
> I'm not sure I completely understand, but volatile heap variables are
> perfectly meaningful today.  For example, if I need to define a
> communication data area for the program to talk to some DMA I/O
> device, a volatile struct, or a struct some of whose members are
> volatile, allocated on the heap, makes perfect sense.

- yes, but only if through a reference it would seem, as otherwise a
  volatile object couldn't be modifiable by anything outside of the
  program itself. But acknowledge that this would require an allocated
  volatile's semantics be dependant on potential references to it being
  declared, which is likely too messy to be worthy of any consideration.

Re: Processor-specific code

[Vincent Lefevre]

On 2005-04-15 18:56:23 +0100, Paul Brook wrote:
> On Friday 15 April 2005 18:43, Vincent Lefevre wrote:
> > It is not possible to change the rounding precision with .
> 
> That's because it's an x86/m68k specific implementation detail and
> the compiler should be setting it for you.

Setting the rounding direction is also processor-specific, but
this is standardized.

> gcc doesn't do this because noone cares enough to implement it.

The user could also want to change the rounding precision dynamically.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: inline-unit-growth trouble

[Christopher Jefferson]

Richard Guenther wrote:
On 4/15/05, Andreas Krebbel <[EMAIL PROTECTED]> wrote:
Hi,
on S/390 we have currently a plenty of testsuite failures
due to inlining effects.
ld complains about testcases which try to link two files containing the same 
function
in .gnu.linkonce sections but with different code sizes. The sizes differ due
to different inlining decisions. The problem is that inlining maybe
prevented by global limits which maybe exceeded for one file but not for
the other.
The actual problem occurred with the "inline-unit-growth" limit which
may prevent inlining for a function in one file and allow it for the same
function in another.
I'm not sure how to fix that issue. To my mind the whole concept of per unit
limits influencing local inlining decisions seems a bit questionable.

Why does the linker not just pick either of the functions?  The size
difference should not matter.
Is it really the job of the linker to choose between different 
implementations of a function? It seems to me that this might lead to 
very, very difficult to track down bugs

rtx/tree calling function syntax

[Chris Kirby]

I am trying to backport how -finstrument-functions is handled from gcc 4.0 to 
gcc 3.4.2.

If function instrumentation is enabled, the whole function is wrapped in a try 
finally block, where the exit call is done from the finally block.

So I think the whole function is generated in tree_rest_of_compilation() in 
tree-optimize.c.  I am able to create the try finally node, but I am having 
trouble determining the syntax to call the exit method inside the finally block.

Below is the code I am trying to insert after the function is fully created but 
before the assembly has been generated.  Does anyone have any ideas as to the 
correct syntax for building this call?

if (flag_instrument_function_entry_exit
&& ! DECL_NO_INSTRUMENT_FUNCTION_ENTRY_EXIT (fndecl))
  {
tree tf, try, finally;
rtx entry;

try = DECL_SAVED_TREE (fndecl);

/** wrap the current function inside the try finally block *.
tf = build (TRY_FINALLY_EXPR, void_type_node, try, NULL);
TREE_SIDE_EFFECTS (tf) = 1;

/** Following is code that does not work to call the exit function

entry = DECL_RTL(tf);
entry = XEXP(entry,0);

emit_library_call (profile_function_exit_libfunc, LCT_NORMAL, VOIDmode,
 2, entry, Pmode,
 expand_builtin_return_addr 
(BUILT_IN_RETURN_ADDRESS,
   
0,
   
hard_frame_pointer_rtx),
 Pmode);
*/

DECL_SAVED_TREE (fndecl) = tf;
  }

- Chris

At 10:08 AM 4/13/2005 -0400, Andrew Pinski wrote:

>On Apr 13, 2005, at 10:06 AM, Chris Kirby wrote:
>
>>We are trying to use -finstrument-functions to do some custom profiling on 
>>x86 and ppc.
>>
>>For normal code execution, it works fine, calling our entry and exit methods 
>>as expected.
>>
>>Unfortunately, we are running into problems related to exceptions.  If we 
>>exit a function because of an exception, no exit method is called.  
>>This greatly diminishes the usefulness of the instrumentation since we are no 
>>longer guaranteed to get matching entry and exit calls.
>
>It works the way you want to for the 4.0 release.

Unfortunately our next release will be using gcc 3.4.2.

Looking at the 4.0 code, I can see that the exit instrumentation is done by 
wrapping a try finally around the entire function.  Backporting this to 3.4.2 
isn't as straightforward as I hoped.  I think something similar could be done 
in tree-optimize.c's tree_rest_of_compilation() but it looks like some of the 
tree/RTL methods have changed in 4.0.

Are there any examples of wrapping a method with a try finally clause and 
calling a given method compatible with 3.4.2?

- Chris

Re: Objective-C++ Status

[Mike Stump]

On Thursday, April 14, 2005, at 09:50  PM, Douglas Charles wrote:
What is the status of Objective-C++ support in mainline GCC? Ziemowit 
Laski was
working on integrating such support late last year, but has Apple 
since halted
such integration efforts?
I don't believe anyone is working on it at the moment.  It exists, you 
just have to grab from the apple-local-200502-branch if you want it.

If you'd like to work on it, let us know, we'd be happy to have the 
help.

Re: inline-unit-growth trouble

[Mike Stump]

On Friday, April 15, 2005, at 09:01  AM, Andreas Krebbel wrote:
on S/390 we have currently a plenty of testsuite failures
due to inlining effects.
ld complains about testcases which try to link two files containing 
the same function in .gnu.linkonce sections but with different code 
sizes.
This is a linker bug, fix it, then come back.  If you're confused, try 
porting GNU ld and using it, or take a look at bfd/elflink.c, under 
SEC_LINK_DUPLICATES_DISCARD v SEC_LINK_DUPLICATES_SAME_SIZE.

Re: inline-unit-growth trouble

[Mike Stump]

On Friday, April 15, 2005, at 11:50  AM, Christopher Jefferson wrote:
Is it really the job of the linker to choose between different 
implementations of a function?
Yes.  Why do you ask?
It seems to me that this might lead to very, very difficult to track 
down bugs
Nope.  All those bugs are trivial to track down, as once you find the 
translation unit that contained the compiled code with something called 
a debugger, you submit the -E for it and that flags used to compile it, 
and because the compiler is deterministic, all such bugs are trivial to 
track down.

Re: inline-unit-growth trouble

[Joe Buck]

On Fri, Apr 15, 2005 at 12:18:54PM -0700, Mike Stump wrote:
> On Friday, April 15, 2005, at 09:01  AM, Andreas Krebbel wrote:
> >on S/390 we have currently a plenty of testsuite failures
> >due to inlining effects.
> >
> >ld complains about testcases which try to link two files containing 
> >the same function in .gnu.linkonce sections but with different code 
> >sizes.
> 
> This is a linker bug, fix it, then come back.  If you're confused, try 
> porting GNU ld and using it, or take a look at bfd/elflink.c, under 
> SEC_LINK_DUPLICATES_DISCARD v SEC_LINK_DUPLICATES_SAME_SIZE.

Agreed.  At first I was inclined to think otherwise, but then I realized
that we could also get different sizes by linking together code produced
by different compiler versions, or at different optimization levels,
and it certainly must be supported that -00 code can be linked with -O2
code.

So yes, the linker should just shut up and pick one version.  Consistency
of inlining might be an issue, but it's a red herring in this case.  There
are too many other circumstances that could yield different sizes.

Re: GCC 4.0 RC1 Available

[Mark Mitchell]

Paolo Bonzini wrote:
Kaveh R. Ghazi wrote:
Nathanael removed the surrounding for-stmt but left
the break inside the if-stmt.
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg02109.html

2005-04-12  Paolo Bonzini  <[EMAIL PROTECTED]>
   * acx.m4 (ACX_PROG_GNAT): Remove stray break.
OK for 4.0.0.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: [m68k]: More trouble with byte moves into Address registers

[Peter Barada]

>For some reason reload has decided that it needs ADDR_REGS for the
>register being reloaded, namely (reg:QI 1420).  So gcc looks for a
>register in ADDR_REGS which can hold QImode.  Because of your changes,
>it doesn't find one.  So it crashes.
>
>The question is why reload thinks that it needs ADDR_REGS for this
>register.  Look at the local-alloc debugging dump to see where
>regclass thinks that the register should go.

Ok, will do.  The previous suggetsion of converting from ?a to *a with
the original version of PREFERRRED_RELOAD_CLASS causes the build of
glibc to crash with: 

../sysdeps/generic/printf_fphex.c: In function `__printf_fphex':
../sysdeps/generic/printf_fphex.c:490: error: unable to find a register to 
spill in class `ADDR_REGS'
../sysdeps/generic/printf_fphex.c:490: error: this is the insn:
(insn 3081 3080 3075 216 ./_itowa.h:58 (set (subreg:SI (reg/v:QI 49 [ leading 
]) 0)
(plus:SI (subreg:SI (reg/v:QI 49 [ leading ]) 0)
(const_int 1 [0x1]))) 121 {*addsi3_5200} (nil)
(nil))
../sysdeps/generic/printf_fphex.c:490: confused by earlier errors, bailing out


I'm rebuilding the toolchain without the ?a change.  What in the .lreg
dump am I looking for that will tellm "where regclass things that the
register should go"?  Is it:

;; Register 1421 in 0.

-- 
Peter Barada
[EMAIL PROTECTED]

Re: inline-unit-growth trouble

[Christopher Jefferson]

Mike Stump wrote:
On Friday, April 15, 2005, at 11:50  AM, Christopher Jefferson wrote:
Is it really the job of the linker to choose between different 
implementations of a function?

Yes.  Why do you ask?
Because I'm not an expert on linkers :)
It seems to me that this might lead to very, very difficult to track 
down bugs

Nope.  All those bugs are trivial to track down, as once you find the 
translation unit that contained the compiled code with something called 
a debugger, 
OK, it was a silly question, but was it necessary to be that insulting?
you submit the -E for it and that flags used to compile it,
and because the compiler is deterministic, all such bugs are trivial to 
track down.
I was more thinking a situation like:
1) I write slightly buggy file A, which generates some some function in 
.gnu.linkonce from a library function. I also have good file B (assume A 
and B have no real connection), which generates the same library 
function. My program works.

2) I edit and recompile file B which causes some different inlining to 
occur in the functions in .gnu.linkonce. B's copy of the library 
function gets chosen, and this happens to break functions in file A. I 
assume however the bug has to be in file B, as thats what I just 
changed, and it has no connection to file A I know of.

Of course it's been pointed out that of course exactly the same problem 
occurs if you compile different files at different optimisation levels, 
so it's unavoidable anywhere perhaps...

Chris

Re: struct __attribute((packed));

[Ralf Corsepius]

On Fri, 2005-04-15 at 10:39 -0600, E. Weddington wrote:

> What?! That whole section in the docs talks about attributes on types. 
> If it doesn't work as described, then the docs need some serious rework.

>From what I see, the example for packed types doesn't even compile:

(Direct cut'n'paste from
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Type-Attributes.html#Type-
Attributes):

# cat tmp.c
struct my_unpacked_struct
{
  char c;
  int i;
};

struct my_packed_struct __attribute__ ((__packed__))
{
  char c;
  int i;
  struct my_unpacked_struct s;
};

# gcc -Wall -o tmp.o -c tmp.c
tmp.c:8: error: syntax error before '{' token
tmp.c:12: error: syntax error before '}' token

# gcc --version
gcc (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)


Ralf

Re: struct __attribute((packed));

[E. Weddington]

Ralf Corsepius wrote:
On Fri, 2005-04-15 at 10:39 -0600, E. Weddington wrote:
 

What?! That whole section in the docs talks about attributes on types. 
If it doesn't work as described, then the docs need some serious rework.
   


From what I see, the example for packed types doesn't even compile:
(Direct cut'n'paste from
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Type-Attributes.html#Type-
Attributes):
# cat tmp.c
struct my_unpacked_struct
{
 char c;
 int i;
};
struct my_packed_struct __attribute__ ((__packed__))
{
 char c;
 int i;
 struct my_unpacked_struct s;
};
# gcc -Wall -o tmp.o -c tmp.c
tmp.c:8: error: syntax error before '{' token
tmp.c:12: error: syntax error before '}' token
# gcc --version
gcc (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)
 

Saved as PR 21052

Eric

Re: inline-unit-growth trouble

[Mike Stump]

On Friday, April 15, 2005, at 01:49  PM, Christopher Jefferson wrote:
Mike Stump wrote:
On Friday, April 15, 2005, at 11:50  AM, Christopher Jefferson wrote:
Is it really the job of the linker to choose between different 
implementations of a function?
Yes.  Why do you ask?
Because I'm not an expert on linkers :)
That's ok, I'm not either.  [honest]
OK, it was a silly question, but was it necessary to be that insulting?
Sorry, I could have phrased it better.
I was more thinking a situation like:
Well, let me just say that a debugger will tell you what is wrong, and 
where it was, and from which translation unit it came from.

Re: Heads-up: volatile and C++

[Marcin Dalecki]

On 2005-04-15, at 20:18, Mike Stump wrote:
On Thursday, April 14, 2005, at 08:48  PM, Marcin Dalecki wrote:
Templates are a no-go for a well known and well defined subset for C++
for embedded programming known commonly as well embedded C++.
My god, you didn't actually buy into that did you?  Hint, it was is, 
and always will be a joke.
You dare to explain what's so funny about it?

Re: Heads-up: volatile and C++

[Marcin Dalecki]

On 2005-04-15, at 19:58, Gabriel Dos Reis wrote:
| Templates are a no-go for a well known and well defined subset for 
C++
| for embedded programming known commonly as well embedded C++.

You'd be surprised to learn that embedded systems people do use
templates for various things -- among which, maybe the most
"paradoxical" is to avoid code bloat.

Embedded C++ was a mistake, alas a mistake that seems to last.
The "seems to last" point is the significant one. Not your superstitions
about what I do or don't know about.

Re: Heads-up: volatile and C++

[Mike Stump]

On Friday, April 15, 2005, at 02:52  PM, Marcin Dalecki wrote:
My god, you didn't actually buy into that did you?  Hint, it was is, 
and always will be a joke.
You dare to explain what's so funny about it?
Oh, it wasn't funny.  Maybe the English is slightly too idiomatic?  I'd 
need someone that understands the English and German to translate.

You can read it as, it was and will always be, just a bad idea.

Vectorizing my loops. Some problems.

[Øystein Johansen]

Hi,
I just started to work on some loop vectorizing for my project. Some 
weeks ago I got a snapshot of GCC-4.1-20050313. It compiled my code but 
I was not able to get the auto-vectorization working. (Yes, I understand 
why)

I decided to try sse intrinsics (X86 Built-in Functions as the manual 
says) instead of auto-vectorization.

I wrote some lines:
typedef int v4sf __attribute__ ((mode(V4SF)));
typedef union _vec4f {
  v4sf v;
  float f[4];
} vec4f;
Blah bla
   for( j = 32; j ; j--, prW += 4, pr += 4 ){
 vec0 = __builtin_ia32_loadups(pr);
 vec1 = __builtin_ia32_loadups(prW);
 vec3 = __builtin_ia32_mulps(vec0, vec1);
 sum.v = __builtin_ia32_addps(sum.v, vec3);
   }
and this works fine when I compile with GCC 3.4.2
However... If I try to compile this with the GCC 4.1 snapshot I get 
errors and warnings:

/msys/1.0/local/bin/gcc.exe -O3 -msse -Wall -DHAVE_CONFIG_H  -I. -I.. 
-c -o neuralnet.o neuralnet.c
neuralnet.c:447: warning: specifying vector types with __attribute__ 
((mode)) is deprecated
neuralnet.c:447: warning: use __attribute__ ((vector_size)) instead
neuralnet.c:447: error: mode 'V4SF' applied to inappropriate type
neuralnet.c: In function 'Evaluate':
neuralnet.c:510: error: incompatible type for argument 1 of 
'__builtin_ia32_xorps'
neuralnet.c:510: error: incompatible type for argument 2 of 
'__builtin_ia32_xorps'
neuralnet.c:510: error: incompatible types in assignment
neuralnet.c:512: error: incompatible types in assignment
neuralnet.c:513: error: incompatible types in assignment
neuralnet.c:514: error: incompatible type for argument 1 of 
'__builtin_ia32_mulps'
neuralnet.c:514: error: incompatible type for argument 2 of 
'__builtin_ia32_mulps'
neuralnet.c:514: error: incompatible types in assignment
neuralnet.c:515: error: incompatible type for argument 1 of 
'__builtin_ia32_addps'
neuralnet.c:515: error: incompatible type for argument 2 of 
'__builtin_ia32_addps'
neuralnet.c:515: error: incompatible types in assignment
make: *** [neuralnet.o] Error 1

So... from when was __attribute__ ((mode)) deprecated? How do I declear 
the v4sf vector type?

Will the right declaration of v4sf type fix the incompatible type in 
assignment and argument problems?

Thanks for any help!
-Øystein

Re: Heads-up: volatile and C++

[Paul Koning]

> "Marcin" == Marcin Dalecki <[EMAIL PROTECTED]> writes:

 Marcin> On 2005-04-15, at 20:18, Mike Stump wrote:

 >> On Thursday, April 14, 2005, at 08:48 PM, Marcin Dalecki wrote:
 >>> Templates are a no-go for a well known and well defined subset
 >>> for C++ for embedded programming known commonly as well embedded
 >>> C++.
 >> My god, you didn't actually buy into that did you?  Hint, it was
 >> is, and always will be a joke.

 Marcin> You dare to explain what's so funny about it?

The fact that many of the C++ features omitted from "embedded C++" are
perfectly valid and useful for embedded systems programming, and cause
neither space nor speed problems in the hands of reasonably competent
programmers. 

I looked at it once, prompted by a question from engineering
management here.  It was immediately obvious that many of the feature
deletions were driven by language religion (e.g., design choices made
differently in some other object-oriented languages) and had no
factual basis in performance or code size.  Either that, or the
choices were based on the assumption that cfront is a state of the art
C++ compiler.  So we decided to ignore "embedded C++" as irrelevant.

Our subsequent system implementation experience confirmed the validity
of this analysis.

paul

Re: Heads-up: volatile and C++

[Marcin Dalecki]

On 2005-04-15, at 23:59, Mike Stump wrote:
On Friday, April 15, 2005, at 02:52  PM, Marcin Dalecki wrote:
My god, you didn't actually buy into that did you?  Hint, it was is, 
and always will be a joke.
You dare to explain what's so funny about it?
Oh, it wasn't funny.  Maybe the English is slightly too idiomatic?  
I'd need someone that understands the English and German to translate.

You can read it as, it was and will always be, just a bad idea.
When will be a full and standard conforming template implementation in 
GCC finished then?

Re: Vectorizing my loops. Some problems.

[Øystein Johansen]

Richard Guenther wrote:
Try
typedef float v4sf __attribute__((vector_size(16)));
note that the base type (float) now matters, and the vector size
is in bytes.  This works even for gcc 3.3, so I don't know exactly
when it was introduced.
D'oh!
...but now I get a more serious problem
/msys/1.0/local/bin/gcc.exe -O3 -msse -Wall -DHAVE_CONFIG_H  -I. -I..
-c -o neuralnet.o neuralnet.c
neuralnet.c: In function 'Evaluate':
neuralnet.c:525: internal compiler error: in output_constant_pool_2, at
varasm.c:3121
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
-Øystein

Re: Heads-up: volatile and C++

[Mike Stump]

On Friday, April 15, 2005, at 03:19  PM, Marcin Dalecki wrote:
You can read it as, it was and will always be, just a bad idea.
When will be a full and standard conforming template implementation in 
GCC finished then?
?
Seriously, what does that have to do with anything?
I know, let's not recommend C for device driver programming, because 
there doesn't exist a C compiler that doesn't have a bug in the world.

My claim would be, there is a reasonable portable subset of C, or C++ 
that one can use in their endeavors.  Further, while in 1992, this 
subset maybe didn't reasonably include templates, that in 2005, it does.

If for you, it doesn't, well, ok, fine.
Go research why that thing that I refuse to even name, doesn't include 
templates, report back here, when you have the answer.  Don't accept 
the marketing explanation either.  I can then check, and see if your 
answer matches mine.  We can then discuss if, at the time, it made for 
a good decision for the so named subset, it did not.

gcc-3.4-20050415 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050415 

You'll find:

gcc-3.4-20050415.tar.bz2  Complete GCC (includes all of below)

gcc-core-3.4-20050415.tar.bz2 C front end and core compiler

gcc-ada-3.4-20050415.tar.bz2  Ada front end and runtime

gcc-g++-3.4-20050415.tar.bz2  C++ front end and runtime

gcc-g77-3.4-20050415.tar.bz2  Fortran 77 front end and runtime

gcc-java-3.4-20050415.tar.bz2 Java front end and runtime

gcc-objc-3.4-20050415.tar.bz2 Objective-C front end and runtime

gcc-testsuite-3.4-20050415.tar.bz2The GCC testsuite

Diffs from 3.4-20050408 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-3.4
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: Heads-up: volatile and C++

[Marcin Dalecki]

On 2005-04-16, at 00:38, Mike Stump wrote:
Seriously, what does that have to do with anything?
Well perhaps my view is somehow shed by the project I'm currently 
sitting on.
It's actually kernel programming. And this occurs for me quite to be 
quite the kind of
stuff, which may be very well put this kind of object serialization to 
good use...

I know, let's not recommend C for device driver programming, because 
there doesn't exist a C compiler that doesn't have a bug in the world.
Actually I see you point and agree. However what one really needs for 
device driver programming
is actually a super-set of C.

My claim would be, there is a reasonable portable subset of C, or C++ 
that one can use in their endeavors.  Further, while in 1992, this 
subset maybe didn't reasonably include templates, that in 2005, it 
does.

If for you, it doesn't, well, ok, fine.
OK agreed.
Go research why that thing that I refuse to even name, doesn't include 
templates, report back here, when you have the answer.
As you already pointed out the reasons stated that long ago are of no 
particular argumentative
interest nowadays. However the conclusions itself may still be valid 
for other reasons.
Well as a side note - my main problems with templates are not the ideas 
involved here. Or the
coding style design paradigmas it permits.
However there are serous validation concerns in shed of the seemingly 
always evolving
and very very extensive specification. It looks like there is always a 
corner case in behavior
which has to be plunged in the next standard revision. Template driven 
code too tends to be somehow
immune to even simpler things like independent peer review. There are 
pragmatical deficiencies in
*all* the implementations I had to deal with thus far. There are 
related maintenance problems over
time and when changing compilers. And so on. However I fully agree that 
those points don't apply
universally  and there are a lot of valid uses of the whole C++ set. I 
recognize as well that
in the case of GCC itself the implementation of this facility got much 
much better during recent years.

I just don't agree that something specified as a subset guided 
effectively at the lie of exclusion of
all language constructs which can be described as conceptually 
difficult should be dismissed straight
away. It can be useful if only for example for the case where you have 
some people with truly bad habits on
your team to put a stop gap on them. (Most of template driven code out 
there written in house sure as
hell didn't look exactly pretty thus far to me...)

 Don't accept the marketing explanation either.
Agreed. Maybe the idea of a subset of C++ basically coming down what 
would be a C with inheritance
was somehow over-hyped by too much marketing bragging as an excuse for 
some defective C++ compiler
implementation at introduction? Thus you still have grief memories 
about it?

  I can then check, and see if your answer matches mine.  We can then 
discuss if, at the time, it made for a good decision for the so named 
subset, it did not.
Well I don't thing it's a question of good or bad. It's more like a 
question of whatever it's sufficiently
usefull.

Re: [m68k]: More trouble with byte moves into Address registers

[James E Wilson]

Peter Barada wrote:
pp_pack.c:2220: error: unable to find a register to spill in class `ADDR_REGS'
pp_pack.c:2220: error: this is the insn:
(insn 5559 5558 5560 694 pp_pack.c:2144 (set (reg:SI 8 %a0 [1421])
(plus:SI (subreg:SI (reg:QI 1420) 0)
(const_int -32 [0xffe0]))) 121 {*addsi3_5200} (insn_list 5558 
(nil))
You might want to look at CANNOT_CHANGE_MODE_CLASS, which can be used to 
change how reload handles (subreg:SI (reg:QI)).  That might help avoid 
generating QImode ADDR_REG reloads in the first place.

But if they are generated, then you need second reloads to resolve them 
as Ian mentioned.  There is probably no way to avoid implementing this.

You should also look at MODES_TIEABLE_P, which may also help prevent 
getting QImode ADDR_REG reloads.

Even if you fix both of these, you will probably still need the 
secondary reload support for this case.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Heads-up: volatile and C++

[Gabriel Dos Reis]

Marcin Dalecki:

>>  Don't accept the marketing explanation either.
>
> Agreed. Maybe the idea of a subset of C++ basically coming down what
> would be a C with inheritance
> was somehow over-hyped by too much marketing bragging as an excuse for
> some defective C++ compiler
> implementation at introduction? Thus you still have grief memories
> about it?

I distinctly remember the Sophia Antipolis meeting (just after
the standard was completed, pending ISO official approval) where
the issue was brought up vividly with "numbers".  At the time,
the reasons (whether excuses or not) were unconvincing, today
they still are unconvincing.  One ends up trying to find other
reasons or excuses to make the conclusion hold.  Ahem.

I guess this subthread is diluting the topic advertized by
the Subject: of this message.

-- Gaby

Re: Heads-up: volatile and C++

[Robert Dewar]

Paul Koning wrote:
"Marcin" == Marcin Dalecki <[EMAIL PROTECTED]> writes:

 Marcin> On 2005-04-15, at 20:18, Mike Stump wrote:
 >> On Thursday, April 14, 2005, at 08:48 PM, Marcin Dalecki wrote:
 >>> Templates are a no-go for a well known and well defined subset
 >>> for C++ for embedded programming known commonly as well embedded
 >>> C++.
 >> My god, you didn't actually buy into that did you?  Hint, it was
 >> is, and always will be a joke.
 Marcin> You dare to explain what's so funny about it?
The fact that many of the C++ features omitted from "embedded C++" are
perfectly valid and useful for embedded systems programming, and cause
neither space nor speed problems in the hands of reasonably competent
programmers. 
One other driver here is certification issues. For example, there are
severe concerns about safety critical certification of dynamic
dispatching, and templates (and Ada generics) cause trouble with some
certification requirements and formal verification tools. I don't know
if these considerations played a part in embedded C++ design, but one
would think that this would be a consideration.

Re: Template and dynamic dispatching

[Gabriel Dos Reis]

[ I changed the title so that the main topic -- volatile and C++ -- not
  be diluted ]

Robert Dewar:
> Paul Koning wrote:
>>>"Marcin" == Marcin Dalecki <[EMAIL PROTECTED]> writes:
>>
>>
>>  Marcin> On 2005-04-15, at 20:18, Mike Stump wrote:
>>
>>  >> On Thursday, April 14, 2005, at 08:48 PM, Marcin Dalecki wrote:
>>  >>> Templates are a no-go for a well known and well defined subset
>>  >>> for C++ for embedded programming known commonly as well embedded
>>  >>> C++.
>>  >> My god, you didn't actually buy into that did you?  Hint, it was
>>  >> is, and always will be a joke.
>>
>>  Marcin> You dare to explain what's so funny about it?
>>
>> The fact that many of the C++ features omitted from "embedded C++" are
>> perfectly valid and useful for embedded systems programming, and cause
>> neither space nor speed problems in the hands of reasonably competent
>> programmers.
>
> One other driver here is certification issues. For example, there are
> severe concerns about safety critical certification of dynamic
> dispatching, and templates (and Ada generics) cause trouble with some
> certification requirements and formal verification tools. I don't know
> if these considerations played a part in embedded C++ design, but one
> would think that this would be a consideration.

C++ templates do not involve dynamic dispatching (I would suspect the
same to be true for Ada generics) so I do not understand your comment.
Maybe there are unsopken assumptions?

-- Gaby


>
>

Re: Template and dynamic dispatching

[Robert Dewar]

Gabriel Dos Reis wrote:
C++ templates do not involve dynamic dispatching (I would suspect the
same to be true for Ada generics) so I do not understand your comment.
Maybe there are unsopken assumptions?
As I said, templates and Ada generics cause trouble with certification
requirements in two respects. First, they have the potential to intefere
with required traceability from source to object. Second, there are a
number of formal techniques that are used in certification for which
support of generics/templates is an issue. Visit the praxis site
(www.praxis-his.com) for more insight into this issue.
Praxis is certainly of the opinion that a limited form of generics
can be accomodated, but I do not think that anyone would suggest
that unlimited use of C++ templates could be easily accomodated
by some of these tools.