Re: Patches for coldfire v4e

[Bernardo Innocenti]

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?

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: GCC 4.0 RC2

[Richard Sandiford]

Richard Sandiford <[EMAIL PROTECTED]> writes:
> Mark,
>
> I tried running some MIPS16 tests against RC1 and found a regression
> from 3.4.  The problem is the following hack in mips.h:
> [...]
> The patch reduces the number of mips64 {-mips16}{-EL,-EB} C failures
> from 203 to 58 with no regressions.  I'm still running normal mips-elf
> tests.  If they pass, is this patch OK for RC2?  Or should it wait
> until 4.0.1?

Just as an update on this: the normal mips-elf RC1 tests passed
and I've since tested and applied the patch to mainline.  It would
be nice to get it into RC2 as well if possible.  Is it OK to add the
patch to the wiki page?

Note that the 58 failures isn't as bad as it sounds.  Many of them
are testsuite glitches caused by the extra flags I'm passing.
I think that this patch makes the difference between a "poor"
and a "good" release as far as MIPS16 goes.

(I'm not trying to be pushy here btw.  I just wanted to
follow up with an updated status.)

Richard

RE: 2 suggestions

[Dave Korn]

Original Message
>From: Kaveh R. Ghazi
>Sent: 14 April 2005 01:11

>  > I'm afraid we'll have to rename all of these in some way, either by
>  > replacing "*" by "x" or by prepending some string.  I'm not too fond
>  > of either, but just using "x" instead "*" might be less ugly.
>  > Somewhat.
>  > What do you think?
>  > Gerald
> 
> I like prepending a string, for example target= or triplet=, etc.
> 
>   --Kaveh


  Is there maybe some unicode char with a completely null glyph that could
be used?


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

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

[Dave Korn]

Original Message
>From: James E Wilson
>Sent: 13 April 2005 20:29

> Dave Korn wrote:
>> [EMAIL PROTECTED] /gnu/testing/obj-HEAD> make check 2>&1 | tee check.log
> 
> Always use "make -k check".  Some testsuites exit with an error if one
> or more tests failed, and because this is the normal situation for
> almost all testsuites, this means the only way to get meaningful results
> is to use -k.
> 
> You will still get a failure for the fixincludes testsuite, but it will
> be ignored, and the other testsuites will work.
> 
> Or alternatively, run the ones you care about individually, e.g. "make
> check-target-libstdc++-v3" which will run only the libstdc++-v3
> testsuite.  Or alternatively, you can cd into the directories you care
> about, e.g. "cd gcc; make check-g++" which will run just the gcc C++
> testsuite.  Etc.


  Thanks James, I did of course forget about "make -k", but I do know about
make in subdirs and about the different targets.  I just did a "egrep
'^check-.*:'" on the top level makefile and ran the c, c++ and libstdc
tests; the test_summary will be forthcoming shortly.

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

RE: 2 suggestions

[Dave Korn]

Original Message
>From: Dave Korn
>Sent: 14 April 2005 10:12

> Original Message
>> From: Kaveh R. Ghazi
>> Sent: 14 April 2005 01:11
> 
>>  > I'm afraid we'll have to rename all of these in some way, either by
>>  > replacing "*" by "x" or by prepending some string.  I'm not too fond
>>  > of either, but just using "x" instead "*" might be less ugly.  >
>>  Somewhat. > What do you think?
>>  > Gerald
>> 
>> I like prepending a string, for example target= or triplet=, etc.
>> 
>>  --Kaveh
> 
> 
>   Is there maybe some unicode char with a completely null glyph that
> could be used? 
 

  LOL, talk about staircase wit; this was still in my outbox but I just
didn't quite click it in time and it was already in transit when I tried to
catch it.  


  Anyway it suddenly also occured to me to wonder if there's a unicode
character that looks exactly the same as an asterisk, but is not
semantically parsed as one, which we could use instead of the asterisks and
not have to prepend anything at all?


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

Re: reload-branch created

[Ulrich Weigand]

Bernd Schmidt <[EMAIL PROTECTED]> wrote on 11.04.2005 14:43:38:

>* reload.c (find_reloads): Only set INC field if we know we have an
>autoinc reload.

Yes, this helps for s390.  With the current reload-branch, and just my
scan_rtx patch on top, I was able to bootstrap and run the test suite
without regressions (all languages, including Ada) on s390-ibm-linux
and s390x-ibm-linux.

Thanks for taking care of this problem!


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: [EMAIL PROTECTED]

Re: internal compiler error at dwarf2out.c:8362

[Martin Koegler]

On Wed, Apr 13, 2005 at 01:55:07PM -0700, James E Wilson wrote:
> Martin Koegler wrote:
> >  tree type = TREE_TYPE (*node);
> >  tree attr = tree_cons (name, args, TYPE_ATTRIBUTES (type));
> >  tree newtype = build_type_attribute_variant (type, attr);
> >  TYPE_MAIN_VARIANT (newtype) = TYPE_MAIN_VARIANT (type);
> >  TREE_TYPE (*node) = newtype;
> 
> You shouldn't be trying to build your own types in a machine dependent 
> attribute handler function.  The compiler's type system is determined by 
> front-ends mainly, and some middle-end infrastructure, and isn't your 
> domain to mess with.  This stuff is subject to change, at which point 
> your code may break.
> 
> There are a number of subtleties in the type system relating to arrays, 
> so it isn't surprising that you are having trouble with them.  For 
> instance, you can't apply some kinds of type modifiers to array types, 
> they have to be applied to the array element types instead.
> 
> I think the problem with your code is that you are setting 
> TYPE_MAIN_VARIANT to point at the original type.  TYPE_MAIN_VARIANT is 
> only supposed to be used in the presence of type qualifiers like const 
> and volatile, to point at the unqualified type.  But you have no type 
> qualifiers here, and hence TYPE_MAIN_VARIANT should point at itself.

I changed the attribute handler to only return NULL_TREE in any case, but
the result is still the same (using the same gcc core).

The problem seems to be, that in the code
  gen_type_die (type, context_die);

  /* We have to get the type_main_variant here (and pass that to the
 `lookup_type_die' routine) because the ..._TYPE node we have
 might simply be a *copy* of some original type node (where the
 copy was created to help us keep track of typedef names) and
 that copy might have a different TYPE_UID from the original
 ..._TYPE node.  */
  if (TREE_CODE (type) != VECTOR_TYPE)
mod_type_die = lookup_type_die (type_main_variant (type));

gen_type_type does not change TYPE_SYMTAB_DIE(type), so the following lookup 
fails
(type has the same value as type_main_variant (type)).

gen_type_die does the following in this case:
gen_type_die calls gen_decl_die (TYPE_NAME (type), context_die). gen_decl_die 
calls
gen_typedef_die passing TYPE_NAME(type) (which is the GROUP9_T).
gen_typedef_die immediatly returns, because this type has already been written.

Here dumps of the types, while compiling 
typedef unsigned char GROUP9_T[3];
typedef GROUP9_T EGROUP9_T __attribute ((eeprom));

with dwarf2 debugging output.

When calling, the attribute handler, the type looks so:

Breakpoint 1, m68hc05_handle_eeprom_attribute (node=0xb7f51220, 
name=0xb7f74bc8, args=0x0, flags=0, no_add_attrs=0xbff60c8b "")
at ../.././gcc/config/m68hc05/m68hc05.c:1690
1690  return NULL_TREE;
(gdb) call debug_tree(*node)
 
unit size 
align 8 symtab -1208530080 alias set -1 precision 8 min  max 
pointer_to_this >
BLK
size  
constant invariant 24>
unit size  constant invariant 3>
align 8 symtab -1208567256 alias set -1
domain 
unit size 
align 8 symtab -1208530132 alias set -1 precision 16 min 
 max >
HI size  unit size 
align 8 symtab 0 alias set -1 precision 16 min  max >>

In modified_type_die, the qualified type looks so:
(gdb) call debug_tree(qualified_type)
 
unit size 
align 8 symtab -1208530080 alias set -1 precision 8 min  max 
pointer_to_this >
BLK
size  
constant invariant 24>
unit size  constant invariant 3>
align 8 symtab 0 alias set -1
attributes >
domain 
unit size 
align 8 symtab -1208530132 alias set -1 precision 16 min 
 max >
HI size  unit size 
align 8 symtab 0 alias set -1 precision 16 min  max >>

The typename of the type looks:
(gdb) call debug_tree(type_name)
 
unit size 
align 8 symtab -1208530080 alias set -1 precision 8 min 
 max 
pointer_to_this >
BLK
size 
unit size 
align 8 symtab -1208567256 alias set -1
domain 
HI
size 
unit size 
align 8 symtab 0 alias set -1 precision 16 min  max >>
asm_written VOID file x.c line 1
align 1
result 
asm_written BLK size  unit size 
align 8 symtab -1208530236 alias set -1 domain >>

DECL_ORIGINAL_TYPE (TYPE_NAME (qualified_type)) is
 
unit size 
align 8 symtab -1208530080 alias set -1 precision 8 min  max 
pointer_to_this >
asm_written BLK
size  
constant invariant 24>
unit size  constant invariant 3>
align 8 symtab -1208530236 alias set -1
domain 
unit size 
align 8 symtab -1208530132 alias set -1 precision 16 min 
 max >
HI size  unit size 
align 8 symta

Re: Patches for coldfire v4e

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Heads-up: volatile and C++

[Jason Merrill]

The C++ committee (well, a subgroup represented at this meeting by Hans
Boehm) is working on a memory model that supports threaded programs.  One
proposed change is to the semantics of volatile.  Currently, volatile
semantics are constrained by:

6 The  observable  behavior  of  the abstract machine is its sequence of
  reads  and  writes  to  volatile  data  and  calls  to   library   I/O
  functions.6)

7 Accessing  an  object  designated by a volatile lvalue (_basic.lval_),
  modifying an object, calling a library  I/O  function,  or  calling  a
  function that does any of those operations are all side effects, which
  are changes in the state of the execution environment.  Evaluation  of
  an expression might produce side effects.  At certain specified points
  in the execution sequence called sequence points, all side effects  of
  previous  evaluations  shall  be  complete  and  no  side  effects  of
  subsequent evaluations shall have taken place.7)

My reading of this is that currently, a volatile read or write should act
as a barrier to other writes ("modifying an object"), because generally
there will be a sequence point between those writes and the volatile
access.

The proposal is that volatile reads act as an acquire (hoist barrier), and
volatile writes act as a release (sink barrier).  These precisely
correspond to the ia-64 ld.acq and st.rel instructions; other architectures
may or may not need memory barrier instructions.  Hans suggests that these
semantics are already required by the Itanium documentation.

The difference from this from what I percieve the current standard to say
is

1) volatile reads and writes now inhibit movement of loads in one direction
   (and therefore constrain CSE).
2) movement of stores is allowed in one direction across volatile reads and
   writes, where before it was fully blocked.

This all makes sense to me, but I'm interested in feedback.

Jason

install

[Master Faris]

I would like to install gcc
can you give me some directions or where to find instructions please as this 
is my first time doing it

thanks

install

[Master Faris]

I would like to install gcc on solaris 9
sun4u sparc SUNW,Sun-Fire-V440
can you give me some directions or where to find instructions please as this 
is my first time doing it

thanks

Re: install

[Gerald Pfeifer]

On Thu, 14 Apr 2005, Master Faris wrote:
> I would like to install gcc on solaris 9
> sun4u sparc SUNW,Sun-Fire-V440
> 
> can you give me some directions or where to find instructions please as this
> is my first time doing it

Please have a look at our website http://gcc.gnu.org, specifically
http://gcc.gnu.org/install.

Note that this list is on the development *of* GCC, not the installation
of or development *with* GCC, so this kind of question is off-topic here.

Gerald

libstdc++ link failures on ppc64

[Diego Novillo]

My ppc64 tester started failing last night while trying to create
libstdc++ libraries with:

-
/home/cygnus/dnovillo/perf/sbox/gcc/local.ppc64/bld.torreja/./gcc/xgcc -shared-l
ibgcc -B/home/cygnus/dnovillo/perf/sbox/gcc/local.ppc64/bld.torreja/./gcc/ -nost
dinc++ -L/home/cygnus/dnovillo/perf/sbox/gcc/local.ppc64/bld.torreja/powerpc64-u
nknown-linux-gnu/libstdc++-v3/src -L/home/cygnus/dnovillo/perf/sbox/gcc/local.pp
c64/bld.torreja/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/cygnu
s/dnovillo/perf/sbox/gcc/local.ppc64/inst.torreja/powerpc64-unknown-linux-gnu/bi
n/ -B/home/cygnus/dnovillo/perf/sbox/gcc/local.ppc64/inst.torreja/powerpc64-unkn
own-linux-gnu/lib/ -isystem /home/cygnus/dnovillo/perf/sbox/gcc/local.ppc64/inst
.torreja/powerpc64-unknown-linux-gnu/include -isystem /home/cygnus/dnovillo/perf
/sbox/gcc/local.ppc64/inst.torreja/powerpc64-unknown-linux-gnu/sys-include -shar
ed -nostdlib /usr/lib/../lib64/crti.o /home/cygnus/dnovillo/perf/sbox/gcc/local.
ppc64/bld.torreja/./gcc/crtbeginS.o  .libs/bitmap_allocator.o .libs/pool_allocat
or.o .libs/mt_allocator.o .libs/codecvt.o .libs/complex_io.o .libs/ctype.o .libs
/debug.o .libs/debug_list.o .libs/functexcept.o .libs/globals_locale.o .libs/glo
[  ]
gcc_s -lc -lgcc_s   /home/cygnus/dnovillo/perf/sbox/gcc/local.ppc64/bld.torreja/
./gcc/crtsavres.o /home/cygnus/dnovillo/perf/sbox/gcc/local.ppc64/bld.torreja/./
gcc/crtendS.o /usr/lib/../lib64/crtn.o  -Wl,-O1 -Wl,--version-script=libstdc++-s
ymbol.ver -Wl,-soname -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.4
.libs/complex_io.o(.opd+0x0): In function `__gnu_cxx::__common_pool_policy<__gnu
_cxx::__pool, true>::_S_get_pool()':
/home/cygnus/dnovillo/perf/sbox/gcc/local.ppc64/bld.torreja/powerpc64-unknown-li
nux-gnu/libstdc++-v3/include/ext/mt_allocator.h:448: multiple definition of `__g
nu_cxx::__common_pool_policy<__gnu_cxx::__pool, true>::_S_get_pool()'
.libs/mt_allocator.o(.opd+0xa8):/home/cygnus/dnovillo/perf/sbox/gcc/local.ppc64/
src/libstdc++-v3/src/mt_allocator.cc:190: first defined here
.libs/functexcept.o(.opd+0x168): In function `__gnu_cxx::__common_pool_policy<__
gnu_cxx::__pool, true>::_S_get_pool()':
[ ... various other multiply defined symbols ... ]
-

I see no changes in libstdc++ since the previous run and nothing
in the C++ FE, so I'm not sure whether it may be something broken
in my box.

Anybody else seeing this failure?


Thanks.  Diego.

RE: install

[Dave Korn]

Original Message
>From: Gerald Pfeifer
>Sent: 14 April 2005 13:45

> On Thu, 14 Apr 2005, Master Faris wrote:
>> I would like to install gcc on solaris 9
>> sun4u sparc SUNW,Sun-Fire-V440
>> 
>> can you give me some directions or where to find instructions please as
>> this is my first time doing it
> 
> Please have a look at our website http://gcc.gnu.org, specifically
> http://gcc.gnu.org/install.
> 
> Note that this list is on the development *of* GCC, not the installation
> of or development *with* GCC, so this kind of question is off-topic here.
> 
> Gerald


  And for a *total* newbie, the easiest thing of all might be a quick trip
to www.sunfreeware.com for a precompiled binary.



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

ld segfaults on ia64 trying to create libgcj.so

[Diego Novillo]

Is anybody seeing this failure on ia64?  ld segfaults trying to
create libgcj.so in mainline.  This was working as of 2005-04-13:

-
/home/cygnus/dnovillo/perf/sbox/gcc/local.ia64/bld.tonic/./gcc/xgcc -shared-libg
cc -B/home/cygnus/dnovillo/perf/sbox/gcc/local.ia64/bld.tonic/./gcc/ -nostdinc++
 -L/home/cygnus/dnovillo/perf/sbox/gcc/local.ia64/bld.tonic/ia64-unknown-linux-g
nu/libstdc++-v3/src -L/home/cygnus/dnovillo/perf/sbox/gcc/local.ia64/bld.tonic/i
a64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/cygnus/dnovillo/perf/sbox/g
cc/local.ia64/inst.tonic/ia64-unknown-linux-gnu/bin/ -B/home/cygnus/dnovillo/per
f/sbox/gcc/local.ia64/inst.tonic/ia64-unknown-linux-gnu/lib/ -isystem /home/cygn
us/dnovillo/perf/sbox/gcc/local.ia64/inst.tonic/ia64-unknown-linux-gnu/include -
isystem /home/cygnus/dnovillo/perf/sbox/gcc/local.ia64/inst.tonic/ia64-unknown-l
inux-gnu/sys-include -shared -nostdlib /usr/lib/crti.o /home/cygnus/dnovillo/per
f/sbox/gcc/local.ia64/bld.tonic/./gcc/crtbeginS.o  gnu/regexp/.libs/MessagesBund
le.properties.o gnu/regexp/.libs/MessagesBundle_fr.properties.o org/ietf/jgss/.l
ibs/MessagesBundle.properties.o -Wl,--whole-archive ./.libs/libgcj0_convenience.
a ../libffi/.libs/libffi_convenience.a ../zlib/.libs/libzgcj_convenience.a ../bo
ehm-gc/.libs/libgcjgc_convenience.a ./libltdl/.libs/libltdlc.a -Wl,--no-whole-ar
chive  -L/home/cygnus/dnovillo/perf/sbox/gcc/local.ia64/bld.tonic/ia64-unknown-l
inux-gnu/libstdc++-v3/src -L/home/cygnus/dnovillo/perf/sbox/gcc/local.ia64/bld.t
onic/ia64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/cygnus/dnovillo/perf/
sbox/gcc/local.ia64/bld.tonic/ia64-unknown-linux-gnu/libjava ./.libs/libgcj0_con
venience.a ../libffi/.libs/libffi_convenience.a ../zlib/.libs/libzgcj_convenienc
e.a ../boehm-gc/.libs/libgcjgc_convenience.a -lpthread ./libltdl/.libs/libltdlc.
a -ldl -L/home/cygnus/dnovillo/perf/sbox/gcc/local.ia64/bld.tonic/./gcc -lgcc_s
-lc -lgcc_s /usr/lib/libunwind.so  /home/cygnus/dnovillo/perf/sbox/gcc/local
.ia64/bld.tonic/./gcc/crtendS.o /usr/lib/crtn.o  -Wl,-soname -Wl,libgcj.so.6 -o
.libs/libgcj.so.6.0.0
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
make[3]: *** [libgcj.la] Error 1
make[3]: Leaving directory `/notnfs/dnovillo/sbox/gcc/bld.tonic/ia64-unknown-lin
ux-gnu/libjava'
make[2]: *** [all-recursive] Error 1
rm gnu/gcj/tools/gcj_dbtool/Main.class
make[2]: Leaving directory `/notnfs/dnovillo/sbox/gcc/bld.tonic/ia64-unknown-lin
ux-gnu/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/notnfs/dnovillo/sbox/gcc/bld.tonic'
make: *** [bootstrap] Error 2
-

I'm using binutils 2.14:

$ ld --version
GNU ld version 2.14.90.0.4 20030523
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.


Thanks.  Diego.

Re: libstdc++ link failures on ppc64

[Diego Novillo]

On Thu, Apr 14, 2005 at 09:33:52AM -0400, Diego Novillo wrote:
> My ppc64 tester started failing last night while trying to create
> libstdc++ libraries with:
> 
I forgot to mention.  This is on mainline.


Diego.

Re: Heads-up: volatile and C++

[Michael N. Moran]

Jason Merrill wrote:
The C++ committee (well, a subgroup represented at this meeting by Hans
Boehm) is working on a memory model that supports threaded programs.  
As someone who uses the C++ language and multi-threading
extensively in embedded systems, I have come to the following
belief/opinion.
  The language (C++) *should not* have dependencies
  upon threading. IMHO, threading is a layer above a
  systems programming language, and having dependencies
  upon upper layers is evil.
One
proposed change is to the semantics of volatile. 
Since IANALL, but I believe (as obviously you do)
that changing the semantics of volatile should be
under-taken with great care.
I'm not familiar with ia64 barrier instructions, but I
*am* familiar with PowerPC barrier and synchronization
instructions (eieio, sync, isync, etc.), and I would
question the practice of automatically generating
these as side effect of a variable being declared
as volatile, if for no other reason than the possible
presence of code that is unnecessary in some (perhaps
most) circumstances.
If the committee believes that the language needs
support for barriers, then I believe it would be
better to use a different approach. For example:
o barrier keyword(s)
o barrier qualifier(s)

While I'm on my soap-box ...
I would like to see some sort of alignment qualifiers
added to the C++ language for those of us that need
to deal with directly with page/cache alignment
(for both types and objects.)

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

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

[Peter Barada]

This is driving me up a tree.  I have a fix for 18421(on mainline &
gcc-3.4.3) that uses HARD_REGNO_MODE_OK to prevent bytes into address
registers, and modified movqi for ColdFire to drop the '*a' in
d*a/di*a constraint, as well as modified addsi3_5200 to us 'i' instead
of 's'.

My current problem is when I'm compiling Perl for the ColdFire v4e
using gcc-3.4.3 for m68k-linux, and I'm seeing:

[EMAIL PROTECTED] tmp]$ 
/opt/logicpd/ColdFire-new12/m68k-linux/gcc-3.4.3-glibc-2.3.2/bin/m68k-linux-gcc 
-DPERL_CORE -mcfv4e -fno-strict-aliasing -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 pp_pack.c -S -o pp_pack.s -da
pp_pack.c: In function `S_unpack_rec':
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))
(nil))
pp_pack.c:2220: confused by earlier errors, bailing out

The RTL surrounding this from pp_pack.c.24.lreg is:
;; 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)))


pp_pack.c.25.greg stops with the line 'Spilling for insn 5559.'  This
line is repeated twice previously. the first with no
information attached(just 'Spilling for insn 5559.'), and then second
time has 'Using reg 9 for reload 0' after it.

This also fails on gcc-3.4.3 for -m5407, but compiles for -m5200.  The
5407 has more instructions and less restrictive addressing modes on
some instructions than the 5200 has.

Can anyone take a stab at describing *how* to debug this?  Is this
just a case where there are so many live registers that reload has
just backed itself into a corner?

Any suggestions are appreciated!

-- 
Peter Barada
[EMAIL PROTECTED]

Re: Heads-up: volatile and C++

[Gabriel Dos Reis]

"Michael N. Moran" <[EMAIL PROTECTED]> writes:

[...]

| While I'm on my soap-box ...
| I would like to see some sort of alignment qualifiers
| added to the C++ language for those of us that need
| to deal with directly with page/cache alignment
| (for both types and objects.)

We just discuss (again) the topic a few minutes ago in the C++
evolution group. I'm taking care of this.  A proposal with tentative
standardese will be in the post-Lillehammer mailing.  Anyone
interested in this may send me an email and I'll be glad to send them a
copy for review/comments. 
(Notice that TR1 already has a suggestion for aligned_storage).


Independently of that, I believe the issue raised by Jason is of most
importance and need not be diverted.

-- Gaby

Re: GCC 4.0 RC1 Available

[Andrew Haley]

Eric Botcazou writes:
 > > which I see you've already committed a patch for, and a large number
 > > of Java failures.
 > >
 > > 
 > >
 > > for 4.0.0-20050410.
 > 
 > Same failure as on Solaris.
 > 
 > Andrew, do you have a Darwin machine at hand?

Yes, but I cannot reproduce the failure.  See
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00990.html

Andrew.

Re: Heads-up: volatile and C++

[Paul Koning]

> "Michael" == Michael N Moran <[EMAIL PROTECTED]> writes:

 Michael> Jason Merrill wrote:
 >> One proposed change is to the semantics of volatile.

 Michael> Since IANALL, but I believe (as obviously you do) that
 Michael> changing the semantics of volatile should be under-taken
 Michael> with great care.

Agreed.

 Michael> I'm not familiar with ia64 barrier instructions, but I *am*
 Michael> familiar with PowerPC barrier and synchronization
 Michael> instructions (eieio, sync, isync, etc.), and I would
 Michael> question the practice of automatically generating these as
 Michael> side effect of a variable being declared as volatile, if for
 Michael> no other reason than the possible presence of code that is
 Michael> unnecessary in some (perhaps most) circumstances.

I don't understand that.  My reaction is just the opposite -- obeying
the defined semantics of "volatile" (the present ones as well as the
proposed ones) requires the insertion of barrier or synchronizing
instructions on platforms where those are needed to ensure ordered
global visibility.

Or are you talking about a system (such as the BCM1250 MIPS processor)
which implements coherency across most, but not all, of the system
blocks?  In that case, yes, when you are using "volatile" to
communicate within the coherence domain, barrier instructions are not
needed -- but if you use "volatile" to communicate *outside* the
coherence domain, they are.  If you assume most cases are in the first
set, then you'd want the compiler not to supply barriers, you'd
handcode them instead using "asm" or builtins.  Conversely, if you
assume that most cases are in the second set, then your code will be
more reliable and only slightly slower if the compiler supplies the
barriers. 

  paul

Processor-specific code

[FranÃois-Xavier Coudert]

Hi all,
I'm working on implementation of the different FPU options for libgfortran, 
the runtime library for gfortran (e.g., on which floating-point exception do 
we want a SIGFPE to be raised, what rounding-mode does the user want, etc.).

There is nothing in standard C (or even POSIX) to do that, and we'll have to 
include some processor-specific code. How does the build system allow that? 
Can we have a system of MACRO defined depending on the target processor 
(something like TARGET_FPU_IS_PPC)?

PS: If I said something stupid or offended your sense of riguor, please 
don't be too harsh on someone new to this kind of problem.

FX

Re: Processor-specific code

[Steve Kargl]

On Thu, Apr 14, 2005 at 04:39:30PM +0200, Fran??ois-Xavier Coudert wrote:
> 
> I'm working on implementation of the different FPU options for libgfortran, 
> the runtime library for gfortran (e.g., on which floating-point exception 
> do we want a SIGFPE to be raised, what rounding-mode does the user want, 
> etc.).
> 

Can you explain in a little more detail what you are trying
to accomplish?  gfortran can already pass the -m and -f
options suppported by gcc.  For example, -ffast-math works.

One other thing to keep in mind, at some point we'll 
want to implement TR 15880.  Are there any potential
conflicts?

-- 
Steve

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

[Kate Minola]

David,

Kate> Err ... what target-specific installation notes for AIX?
Kate> Where are you looking?

David>  *-ibm-aix*

Hmm ... The ordering of targets seems rather confusing.
I guess I expect that 

  *-*-freebsd*
  *-*-linux-gnu
  *-*-solaris2*
  *-*-sysv*
  *-*-vxworks* 
  *-ibm-aix*

will be contiguous and at the front of the list.  As they
are currently scattered among the targets it can be
difficult to find them.  In particular, I do not understand
why *-ibm-aix* is between ia64-*-hpus* and ip2k-*-elf:

  ia64-*-hpux* 
  *-ibm-aix* 
  ip2k-*-elf 

I will be happy to reorder the page if someone will check
my ordering for sanity and then check in the submission if
approved.

Now back to my original problem.  I have checked with my
local sys admin and he tells me that the updates mentioned
in *-ibm-aix* - specifically PTF U455193, PTF U461879, and
PTF U453956 - all refer to 4.3, whereas we are at AIX 5.2.

So I am back to my original question.  What is different
between your machine and mine?  Any further ideas as to
what I should look at?

Kate Minola
University of Maryland, College Park

Re: 2 suggestions

[Gerald Pfeifer]

On Wed, 13 Apr 2005, Kaveh R. Ghazi wrote:
> I like prepending a string, for example target= or triplet=, etc.

Okay.  However,...

On Thu, 14 Apr 2005, Georg Bauhaus wrote:
> If "*-*-solaris2*" should appear as/in the "name" attribute of an ,
> prepending a name start character is not enough, because this attribute
> is of type NMTOKEN. Therefore it cannot contain * at all.

...if we are absolutely disallowed to use "*", probably just replacing
"*" by "x" without any prefix might be the lesser of all evils?

> If international character sets in XHTML are o.K., maybe there are
> some letter sets to choose from. Here is a sample.

I feel this might be worse, because it'll look as if everything was okay,
but when someone copies and pastes the string, it won't work as a proper
target string.  (Thanks for your expert input, by the way.)

Okay?

Gerald

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

[Alexandre Oliva]

On Apr 12, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:

> On Apr 12, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> It looks like it wouldn't be too hard to overcome this problem by
>> generating the artificial labels in case_index order, instead of in
>> goto_queue order, but it's not obvious to me that the potential
>> randomness from sorting of stmt addresses in the goto_queue that have
>> the same index couldn't possibly affect the outcome.

> This is what I had in mind with the paragraph above.  Does it feel
> like a reasonable approach?  (Note that the two sets of
> last_case_index were dead, so the patch removes them)

The patch I posted before wasn't enough to fix the problem, there was
another portion of code that walked the goto queue in order.  This one
fixes the problem, and enables GCC mainline as of a week ago or so to
bootstrap on i686-pc-linux-gnu (Fedora Core devel, with exec-shield
mmap randomization enabled).  I haven't used a newer tree to test this
because I've been unable to bootstrap it for other reasons.

Ok to install?

Index: gcc/ChangeLog
from  Alexandre Oliva  <[EMAIL PROTECTED]>

	* tree-eh.c (lower_try_finally_copy): Generate new code in
	response to goto_queue entries as if the queue was sorted by
	index, not pointers.
	(lower_try_finally_switch): Likewise.

Index: gcc/tree-eh.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-eh.c,v
retrieving revision 2.28
diff -u -p -r2.28 tree-eh.c
--- gcc/tree-eh.c 1 Apr 2005 03:42:44 - 2.28
+++ gcc/tree-eh.c 14 Apr 2005 01:15:45 -
@@ -1038,47 +1038,72 @@ lower_try_finally_copy (struct leh_state
 {
   struct goto_queue_node *q, *qe;
   tree return_val = NULL;
-  int return_index;
-  tree *labels;
+  int return_index, index;
+  struct
+  {
+	struct goto_queue_node *q;
+	tree label;
+  } *labels;
 
   if (tf->dest_array)
 	return_index = VARRAY_ACTIVE_SIZE (tf->dest_array);
   else
 	return_index = 0;
-  labels = xcalloc (sizeof (tree), return_index + 1);
+  labels = xcalloc (sizeof (*labels), return_index + 1);
 
   q = tf->goto_queue;
   qe = q + tf->goto_queue_active;
   for (; q < qe; q++)
 	{
-	  int index = q->index < 0 ? return_index : q->index;
-	  tree lab = labels[index];
-	  bool build_p = false;
+	  index = q->index < 0 ? return_index : q->index;
 
-	  if (!lab)
-	{
-	  labels[index] = lab = create_artificial_label ();
-	  build_p = true;
-	}
+	  if (!labels[index].q)
+	labels[index].q = q;
+	}
+
+  for (index = 0; index < return_index + 1; index++)
+	{
+	  tree lab;
+
+	  q = labels[index].q;
+	  if (! q)
+	continue;
+
+	  lab = labels[index].label = create_artificial_label ();
 
 	  if (index == return_index)
 	do_return_redirection (q, lab, NULL, &return_val);
 	  else
 	do_goto_redirection (q, lab, NULL);
 
-	  if (build_p)
-	{
-	  x = build1 (LABEL_EXPR, void_type_node, lab);
-	  append_to_statement_list (x, &new_stmt);
+	  x = build1 (LABEL_EXPR, void_type_node, lab);
+	  append_to_statement_list (x, &new_stmt);
 
-	  x = lower_try_finally_dup_block (finally, state);
-	  lower_eh_constructs_1 (state, &x);
-	  append_to_statement_list (x, &new_stmt);
+	  x = lower_try_finally_dup_block (finally, state);
+	  lower_eh_constructs_1 (state, &x);
+	  append_to_statement_list (x, &new_stmt);
 
-	  append_to_statement_list (q->cont_stmt, &new_stmt);
-	  maybe_record_in_goto_queue (state, q->cont_stmt);
-	}
+	  append_to_statement_list (q->cont_stmt, &new_stmt);
+	  maybe_record_in_goto_queue (state, q->cont_stmt);
+	}
+
+  for (q = tf->goto_queue; q < qe; q++)
+	{
+	  tree lab;
+
+	  index = q->index < 0 ? return_index : q->index;
+
+	  if (labels[index].q == q)
+	continue;
+
+	  lab = labels[index].label;
+
+	  if (index == return_index)
+	do_return_redirection (q, lab, NULL, &return_val);
+	  else
+	do_goto_redirection (q, lab, NULL);
 	}
+	
   replace_goto_queue (tf);
   free (labels);
 }
@@ -1194,7 +1219,6 @@ lower_try_finally_switch (struct leh_sta
   q = tf->goto_queue;
   qe = q + tf->goto_queue_active;
   j = last_case_index + tf->may_return;
-  last_case_index += nlabels;
   for (; q < qe; ++q)
 {
   tree mod;
@@ -1217,20 +1241,37 @@ lower_try_finally_switch (struct leh_sta
 
   case_index = j + q->index;
   if (!TREE_VEC_ELT (case_label_vec, case_index))
-	{
-	  last_case = build (CASE_LABEL_EXPR, void_type_node,
-			 build_int_cst (NULL_TREE, switch_id), NULL,
-			 create_artificial_label ());
-	  TREE_VEC_ELT (case_label_vec, case_index) = last_case;
-
-	  x = build (LABEL_EXPR, void_type_node, CASE_LABEL (last_case));
-	  append_to_statement_list (x, &switch_body);
-	  append_to_statement_list (q->cont_stmt, &switch_body);
-	  maybe_record_in_goto_queue (state, q->cont_stmt);
-	}
+	TREE_VEC_ELT (case_label_vec, case_index)
+	  = build (CASE_LABEL_EXPR, void_type_no

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

[David Edelsohn]

> Kate Minola writes:

Kate> will be contiguous and at the front of the list.  As they
Kate> are currently scattered among the targets it can be
Kate> difficult to find them.  In particular, I do not understand
Kate> why *-ibm-aix* is between ia64-*-hpus* and ip2k-*-elf:

Kate> ia64-*-hpux* 
Kate> *-ibm-aix* 
Kate> ip2k-*-elf

Alphabetical.

IA
IB
IP

Kate> Now back to my original problem.  I have checked with my
Kate> local sys admin and he tells me that the updates mentioned
Kate> in *-ibm-aix* - specifically PTF U455193, PTF U461879, and
Kate> PTF U453956 - all refer to 4.3, whereas we are at AIX 5.2.

Kate> So I am back to my original question.  What is different
Kate> between your machine and mine?  Any further ideas as to
Kate> what I should look at?

Please look at the AIX information again.  There are AIX 5.1 and
AIX 5.2 PTFs.

David

Re: GCC 4.0 RC2

[Mark Mitchell]

Richard Sandiford wrote:
Richard Sandiford <[EMAIL PROTECTED]> writes:
Mark,
I tried running some MIPS16 tests against RC1 and found a regression
from 3.4.  The problem is the following hack in mips.h:
[...]
The patch reduces the number of mips64 {-mips16}{-EL,-EB} C failures
from 203 to 58 with no regressions.  I'm still running normal mips-elf
tests.  If they pass, is this patch OK for RC2?  Or should it wait
until 4.0.1?

Just as an update on this: the normal mips-elf RC1 tests passed
and I've since tested and applied the patch to mainline.  It would
be nice to get it into RC2 as well if possible.  Is it OK to add the
patch to the wiki page?
Yes, please.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: Processor-specific code

[François-Xavier Coudert]

Can you explain in a little more detail what you are trying
to accomplish?  gfortran can already pass the -m and -f
options suppported by gcc.  For example, -ffast-math works.
Runtime library reads GFORTRAN_FPU_* environment variables if they exist, 
and set up the FPU accordingly.

One other thing to keep in mind, at some point we'll 
want to implement TR 15880.  Are there any potential
conflicts?
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).

Of course, when the code for GFORTRAN_FPU_* is written (which is much easier 
than full TR 15580 support), we can use it for TR 15580.

FX

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

[Kate Minola]

David,

> Kate> ia64-*-hpux* 
> Kate> *-ibm-aix* 
> Kate> ip2k-*-elf
> 
> Alphabetical.
> 
> IA
> IB
> IP

I guess we will have to agree to disagree as to the ordering.
I do not like an ordering that has "i < * < i" !!!

> Please look at the AIX information again.  There are AIX 5.1 and
> AIX 5.2 PTFs.

The only mention I see of AIX 5.1 and 5.2 the target specific notes
uder *-ibm-aix* is 

: Building libstdc++.a requires a fix for an AIX Assembler
: bug APAR IY26685 (AIX 4.3) or APAR IY25528 (AIX 5.1). It
: also requires a fix for another AIX Assembler bug and a
: co-dependent AIX Archiver fix referenced as APAR IY53606
: (AIX 5.2) or a APAR IY54774 (AIX 5.1)

I am just trying to build with --enable-languages=c.  Thus I
do not think this applies.  (Otherwise the note needs to be
improved.)

I am looking at 

  gcc-4.0.0-20050410/INSTALL/specific.html

Is it identical to what you are looking at?  Perhaps what
you are looking at comes from the CVS repository?  In which
case, it is NOT being included in the scripts that spin out
a release.

Kate Minola
University of Maryland, College Park

Re: Heads-up: volatile and C++

[Jason Merrill]

On Thu, 14 Apr 2005 10:12:37 -0400, "Michael N. Moran" <[EMAIL PROTECTED]> 
wrote:

> Jason Merrill wrote:
>> The C++ committee (well, a subgroup represented at this meeting by Hans
>> Boehm) is working on a memory model that supports threaded programs.
>
> As someone who uses the C++ language and multi-threading
> extensively in embedded systems, I have come to the following
> belief/opinion.
>
>The language (C++) *should not* have dependencies
>upon threading. IMHO, threading is a layer above a
>systems programming language, and having dependencies
>upon upper layers is evil.

But the memory model for the language must provide semantics that make it
possible for threaded programs to be written.  Currently, if you want to
write a portable pthreads program you need to use a mutex around all uses
of shared memory, because they are the only way to guarantee sequential
memory ordering.  The volatile proposal provides a lighter-weight way to
write portable code with explicit memory ordering.  You need this for
lockless algorithms to work.

> Since IANALL, but I believe (as obviously you do)
> that changing the semantics of volatile should be
> under-taken with great care.
>
> I'm not familiar with ia64 barrier instructions, but I
> *am* familiar with PowerPC barrier and synchronization
> instructions (eieio, sync, isync, etc.), and I would
> question the practice of automatically generating
> these as side effect of a variable being declared
> as volatile, if for no other reason than the possible
> presence of code that is unnecessary in some (perhaps
> most) circumstances.

It seems to me that the current specification of volatile already requires
an lwsync around volatile reads and writes, to guarantee that all previous
stores have been completed and later ones have not started.

Jason

Re: 2 suggestions

[Hugh Sasse Staff Elec Eng]

On Thu, 14 Apr 2005, Gerald Pfeifer wrote:
On Thu, 14 Apr 2005, Georg Bauhaus wrote:
If "*-*-solaris2*" should appear as/in the "name" attribute of an ,
prepending a name start character is not enough, because this attribute
is of type NMTOKEN. Therefore it cannot contain * at all.
...if we are absolutely disallowed to use "*", probably just replacing
"*" by "x" without any prefix might be the lesser of all evils?
So long as things to get ported to the x-box?  We can't use ?
because it looks like a cgi call.  * looks like it came from
globbing, so is . such a bad choice?  I know it only stands for a
single char in globbing, but it won't run into the 8.3 problems of
DOS filenames because, and  ".-.-solaris2."  looks like soemthing is
missing. "^-^-solaris2^", perhaps, as in printers marks for "insert
this here"?

If international character sets in XHTML are o.K., maybe there are
some letter sets to choose from. Here is a sample.
I feel this might be worse, because it'll look as if everything was okay,
but when someone copies and pastes the string, it won't work as a proper
target string.  (Thanks for your expert input, by the way.)
Also URLs end up in funny places, so they may not end up where
unicode (or other non-ascii) is supported.
Okay?
Gerald
HTH
Hugh

Re: Heads-up: volatile and C++

[Nathan Sidwell]

Jason Merrill wrote:
The C++ committee (well, a subgroup represented at this meeting by Hans
Boehm) is working on a memory model that supports threaded programs.  One
proposed change is to the semantics of volatile.  Currently, volatile
semantics are constrained by:
6 The  observable  behavior  of  the abstract machine is its sequence of
  reads  and  writes  to  volatile  data  and  calls  to   library   I/O
  functions.6)
7 Accessing  an  object  designated by a volatile lvalue (_basic.lval_),
  modifying an object, calling a library  I/O  function,  or  calling  a
  function that does any of those operations are all side effects, which
  are changes in the state of the execution environment.  Evaluation  of
  an expression might produce side effects.  At certain specified points
  in the execution sequence called sequence points, all side effects  of
  previous  evaluations  shall  be  complete  and  no  side  effects  of
  subsequent evaluations shall have taken place.7)
My reading of this is that currently, a volatile read or write should act
as a barrier to other writes ("modifying an object"), because generally
there will be a sequence point between those writes and the volatile
access.
Could you clarify whether 'other writes' means 'other _volatile_ writes',
or '_any_ other writes'?  Since non-volatile writes are not visible
outside of the abstract machine, how can they be ordered wrt volatiles?
It seems to me that threads require barriers _within_ the abstract machine,
and currently there is no mechanism to specify just that.  Volatile is all
we have, and AFAICT those are only ordered WRT other volatile accesses
separated by a sequence point.
It appears to me that the proposal is providing more restrictions
on volatile and other accesses, not fewer -- and cursorily that seems
sane.
nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: libstdc++ link failures on ppc64

[Jon Grimm]

Diego Novillo wrote:

I see no changes in libstdc++ since the previous run and nothing
in the C++ FE, so I'm not sure whether it may be something broken
in my box.
Anybody else seeing this failure?
Yep. I see this here on the PPC64 nightly autotester.
Br, Jon

Re: unreducable cp_tree_equal ICE in gcc-4.0.0-20050410

[Andrew Pinski]

On Apr 13, 2005, at 10:39 PM, Michael Matz wrote:
So PRE is trying to compare two types, and they contains something 
which
can't be handled.  Either because they were silently overwritten, or
because of a logical error.
Or because the C++ front-end does not handle SSA_NAME, there was a 
thread
about this.

-- Pinski

Re: unreducable cp_tree_equal ICE in gcc-4.0.0-20050410

[Andrew Pinski]

On Apr 13, 2005, at 9:25 PM, Nick Rasmussen wrote:
I'm running into an ICE in the prerelease, that is proving to be
very difficult in reducing to a small testcase.  If I preprocess
the source (via -E or -save-temps) the code successfully compiles.
 If I minimally change the source file in some ways(like adding a
static integer in the global scope) the code compiles.  I've been
able to delete some lines from the source file that's triggering
the bug, including some from within the function that is
triggering the ICE, but I'm down to a point where I can't easily
reduce it further, or even get it into a single source file.
Does this bug look familiar?  20629 is ICEing in the same spot, but
it looks like theirs was reproducible after preprocessing.  Is there
any more information that I provide that would be helpful?  I've
attached the command line, specs and a stacktrace from cc1plus.
I think this was fixed on the mainline by:
2005-03-18  Dale Johannese  <[EMAIL PROTECTED]>
* cp/tree.c (cp_tree_equal):  Handle SSA_NAME.
-- Pinski

Re: libstdc++ link failures on ppc64

[Diego Novillo]

On Thu, Apr 14, 2005 at 11:26:33AM -0500, Jon Grimm wrote:
> Diego Novillo wrote:
> 
> 
> >
> >I see no changes in libstdc++ since the previous run and nothing
> >in the C++ FE, so I'm not sure whether it may be something broken
> >in my box.
> >
> >Anybody else seeing this failure?
> >
> 
> Yep. I see this here on the PPC64 nightly autotester.
> 
Undoing this patch fixes the build failure on ppc64 (though it
doesn't affect the ld segfault on ia64 that I reported
separately).  Thanks to drow and jbrown for pointing it out to
me:

2005-04-13  Julian Brown  <[EMAIL PROTECTED]>

* config/elfos.h (MAKE_DECL_ONE_ONLY): Redefined to stop DECL_WEAK from
being used for symbols with vague linkage when HAVE_GAS_COMDAT_GROUP
is true.


Diego.

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

[Richard Henderson]

On Thu, Apr 14, 2005 at 12:13:59PM -0300, Alexandre Oliva wrote:
>   * tree-eh.c (lower_try_finally_copy): Generate new code in
>   response to goto_queue entries as if the queue was sorted by
>   index, not pointers.
>   (lower_try_finally_switch): Likewise.

Ok.


r~

Re: libstdc++ link failures on ppc64

[H. J. Lu]

On Thu, Apr 14, 2005 at 12:46:08PM -0400, Diego Novillo wrote:
> On Thu, Apr 14, 2005 at 11:26:33AM -0500, Jon Grimm wrote:
> > Diego Novillo wrote:
> > 
> > 
> > >
> > >I see no changes in libstdc++ since the previous run and nothing
> > >in the C++ FE, so I'm not sure whether it may be something broken
> > >in my box.
> > >
> > >Anybody else seeing this failure?
> > >
> > 
> > Yep. I see this here on the PPC64 nightly autotester.
> > 
> Undoing this patch fixes the build failure on ppc64 (though it
> doesn't affect the ld segfault on ia64 that I reported
> separately).  Thanks to drow and jbrown for pointing it out to
> me:
> 

You may need to upgrade your binutils to the one in CVS to get proper
COMDAT support.

BTW, I didn't get ld segfault on ia64. But all libjava tests failed.
I am looking into it now.


H.J.

Re: Heads-up: volatile and C++

[Jason Merrill]

On Thu, 14 Apr 2005 17:11:58 +0100, Nathan Sidwell <[EMAIL PROTECTED]> wrote:

> Jason Merrill wrote:

>> 7 Accessing  an  object  designated by a volatile lvalue (_basic.lval_),
>>   modifying an object, calling a library  I/O  function,  or  calling  a
>>   function that does any of those operations are all side effects, which
>>   are changes in the state of the execution environment.  Evaluation  of
>>   an expression might produce side effects.  At certain specified points
>>   in the execution sequence called sequence points, all side effects  of
>>   previous  evaluations  shall  be  complete  and  no  side  effects  of
>>   subsequent evaluations shall have taken place.7)
>> My reading of this is that currently, a volatile read or write should act
>> as a barrier to other writes ("modifying an object"), because generally
>> there will be a sequence point between those writes and the volatile
>> access.
>
> Could you clarify whether 'other writes' means 'other _volatile_ writes',
> or '_any_ other writes'?  Since non-volatile writes are not visible
> outside of the abstract machine, how can they be ordered wrt volatiles?

Any others.  I was basing that on the requirement that the side-effects of
those writes are required to be complete, though I suppose you could argue
that they aren't required to be visible outside the current thread.

> It seems to me that threads require barriers _within_ the abstract machine,
> and currently there is no mechanism to specify just that.  Volatile is all
> we have, and AFAICT those are only ordered WRT other volatile accesses
> separated by a sequence point.
>
> It appears to me that the proposal is providing more restrictions
> on volatile and other accesses, not fewer -- and cursorily that seems
> sane.

Yep.

Jason

Re: unreducable cp_tree_equal ICE in gcc-4.0.0-20050410

[Dale Johannesen]

On Apr 14, 2005, at 7:14 AM, Andrew Pinski wrote:
Does this bug look familiar?  20629 is ICEing in the same spot, but
it looks like theirs was reproducible after preprocessing.  Is there
any more information that I provide that would be helpful?  I've
attached the command line, specs and a stacktrace from cc1plus.
I think this was fixed on the mainline by:
2005-03-18  Dale Johannese  <[EMAIL PROTECTED]>
* cp/tree.c (cp_tree_equal):  Handle SSA_NAME.
Yep, and I didn't put it in the release branch.  Bad Dale.  OK to do 
that?

If this is the same problem, changing the VN hashtable size to 1
should make it show up reproducibly.

Re: 2 suggestions

[Kaveh R. Ghazi]

 > ...if we are absolutely disallowed to use "*", probably just
 > replacing "*" by "x" without any prefix might be the lesser of all
 > evils?

I guess "x" is fine with me.  However can we use "x" only in the
anchor and not the link's text label?  E.g.:

alpha*-*-*

That way, the part people actually read in the document still uses
asterisk that they are used to seeing.

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: GCC 4.0 RC1 Available

[Joseph S. Myers]

On Wed, 13 Apr 2005, Paul Jarc wrote:

> gcc/doc/install.texi still mentions gcc 3.5 in a few places.

Fixed thus (and a similar reference in cpp.texi).  It passes "make info", 
"make dvi" and "install.texi2html".  Applied to mainline and 4.0 branch 
(as a doc patch for which the branch is still open).

In checking for any similar references which should be fixed I noticed 
that config/arm/libgcc-bpabi.ver defines a GCC_3.5 symbol version, but 
it's probably rather too late to change that and may not be desirable to 
change it anyway.

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

2005-04-14  Joseph S. Myers  <[EMAIL PROTECTED]>

* doc/cpp.texi, doc/install.texi: Change references to GCC 3.5 to
refer to 4.0.

diff -rupN GCC.orig/gcc/doc/cpp.texi GCC/gcc/doc/cpp.texi
--- GCC.orig/gcc/doc/cpp.texi   2005-03-06 13:02:34.0 +
+++ GCC/gcc/doc/cpp.texi2005-04-14 17:09:20.0 +
@@ -4045,7 +4045,7 @@ they generally represent bugs in the sna
 
 @item -I- deprecated
 
-This option has been deprecated in 3.5.  @option{-iquote} is meant to
+This option has been deprecated in 4.0.  @option{-iquote} is meant to
 replace the need for this option.
 
 @item Order of evaluation of @samp{#} and @samp{##} operators
diff -rupN GCC.orig/gcc/doc/install.texi GCC/gcc/doc/install.texi
--- GCC.orig/gcc/doc/install.texi   2005-04-06 17:01:03.0 +
+++ GCC/gcc/doc/install.texi2005-04-14 17:09:12.0 +
@@ -442,7 +442,7 @@ Please refer to the @uref{http://gcc.gnu
 for information on how to obtain [EMAIL PROTECTED]
 
 The full distribution includes the C, C++, Objective-C, Fortran 77, Fortran
-(in case of GCC 3.5 and later), Java, and Ada (in case of GCC 3.1 and later)
+(in case of GCC 4.0 and later), Java, and Ada (in case of GCC 3.1 and later)
 compilers.  The full distribution also includes runtime libraries for C++,
 Objective-C, Fortran 77, Fortran, and Java.  In GCC 3.0 and later versions,
 GNU compiler testsuites are also included in the full distribution.
@@ -2685,7 +2685,7 @@ configuring if you want a model other th
 TARGET_SCHED_DEFAULT can be defined in BOOT_CFLAGS if a different
 default scheduling model is desired.
 
-As of GCC 3.5, GCC uses the UNIX 95 namespace for HP-UX 10.10
+As of GCC 4.0, GCC uses the UNIX 95 namespace for HP-UX 10.10
 through 11.00, and the UNIX 98 namespace for HP-UX 11.11 and later.
 This namespace change might cause problems when bootstrapping with
 an earlier version of GCC or the HP compiler as essentially the same
@@ -2726,10 +2726,10 @@ the 3-stage comparison test to fail duri
 You should be able to continue by saying @samp{make all} after getting
 the failure from @samp{make bootstrap}.
 
-GCC 3.5 requires CVS binutils as of April 28, 2004 or later.  Earlier
+GCC 4.0 requires CVS binutils as of April 28, 2004 or later.  Earlier
 versions require binutils 2.8 or later.
 
-The C++ ABI has changed incompatibly in GCC 3.5.  COMDAT subspaces are
+The C++ ABI has changed incompatibly in GCC 4.0.  COMDAT subspaces are
 used for one-only code and data.  This resolves many of the previous
 problems in using C++ on this target.  However, the ABI is not compatible
 with the one implemented under HP-UX 11 using secondary definitions.
@@ -2802,7 +2802,7 @@ This has been been reported to sometimes
 binutils and [EMAIL PROTECTED]
 
 GCC 3.0 through 3.2 require binutils 2.11 or above.  GCC 3.3 through
-GCC 3.5 require binutils 2.14 or later.
+GCC 4.0 require binutils 2.14 or later.
 
 Although the HP assembler can be used for an initial build, it shouldn't
 be used with any languages other than C and perhaps Fortran due to its

Re: GCC 4.0 RC1 Available

[Mark Mitchell]

Joseph S. Myers wrote:
On Wed, 13 Apr 2005, Paul Jarc wrote:

gcc/doc/install.texi still mentions gcc 3.5 in a few places.

Fixed thus (and a similar reference in cpp.texi).  It passes "make info", 
"make dvi" and "install.texi2html".  Applied to mainline and 4.0 branch 
(as a doc patch for which the branch is still open).
Thanks!
In checking for any similar references which should be fixed I noticed 
that config/arm/libgcc-bpabi.ver defines a GCC_3.5 symbol version, but 
it's probably rather too late to change that and may not be desirable to 
change it anyway.
Correct.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: ld segfaults on ia64 trying to create libgcj.so

[Richard Henderson]

On Thu, Apr 14, 2005 at 09:39:37AM -0400, Diego Novillo wrote:
> GNU ld version 2.14.90.0.4 20030523

Worked for me with 2.15.94.


r~

Re: ld segfaults on ia64 trying to create libgcj.so

[Diego Novillo]

On Thu, Apr 14, 2005 at 10:24:32AM -0700, Richard Henderson wrote:
> On Thu, Apr 14, 2005 at 09:39:37AM -0400, Diego Novillo wrote:
> > GNU ld version 2.14.90.0.4 20030523
> 
> Worked for me with 2.15.94.
> 
OK.  Thanks.


Diego.

Re: Processor-specific code

[Richard Henderson]

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.

All that said, C99 has  to control just about anything you
could want about the fpu.


r~

Re: Processor-specific code

[Steve Kargl]

On Thu, Apr 14, 2005 at 10:35:06AM -0700, 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.

I agree with Richard.

> 
> All that said, C99 has  to control just about anything you
> could want about the fpu.
> 

Does gcc support 
#pragma STDC FENV_ACCESS

-- 
Steve

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

[Alexandre Oliva]

On Apr 14, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote:

> On Thu, Apr 14, 2005 at 12:13:59PM -0300, Alexandre Oliva wrote:
>> * tree-eh.c (lower_try_finally_copy): Generate new code in
>> response to goto_queue entries as if the queue was sorted by
>> index, not pointers.
>> (lower_try_finally_switch): Likewise.

> Ok.

Mark, ok for 4.0 as well?

-- 
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: Processor-specific code

[Andrew Pinski]

On Apr 14, 2005, at 1:47 PM, Steve Kargl wrote:
Does gcc support
#pragma STDC FENV_ACCESS
No, there is a bug about that somewhere.
-- Pinski

Re: GCC 4.0 RC2

[Mark Mitchell]

Steven Bosscher wrote:
On Tuesday 12 April 2005 19:59, Mark Mitchell wrote:
Therefore, I'm going to allow some of the queued patches into 4.0 at
this time.  If your patch isn't on this list, but is here:
http://gcc.gnu.org/wiki/Last-Minute%20Requests%20for%204.0.0
I'm still considering it.  I'll let you know if I've firmly decided that
your patch will not be in RC2.

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?

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: libstdc++ link failures on ppc64

[Mark Mitchell]

Diego Novillo wrote:
On Thu, Apr 14, 2005 at 11:26:33AM -0500, Jon Grimm wrote:
Diego Novillo wrote:

I see no changes in libstdc++ since the previous run and nothing
in the C++ FE, so I'm not sure whether it may be something broken
in my box.
Anybody else seeing this failure?
Yep. I see this here on the PPC64 nightly autotester.
Undoing this patch fixes the build failure on ppc64 (though it
doesn't affect the ld segfault on ia64 that I reported
separately).  Thanks to drow and jbrown for pointing it out to
me:
Would you report your as + ld version numbers?  Again, I'm guessing that 
you have an assembler with COMDAT and a linker without, or a broken 
assembler.

Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: Heads-up: volatile and C++

[Michael N. Moran]

Paul Koning wrote:
"Michael" == Michael N Moran <[EMAIL PROTECTED]> writes:

 Michael> Jason Merrill wrote:
 >> One proposed change is to the semantics of volatile.
 Michael> I'm not familiar with ia64 barrier instructions, but I *am*
 Michael> familiar with PowerPC barrier and synchronization
 Michael> instructions (eieio, sync, isync, etc.), and I would
 Michael> question the practice of automatically generating these as
 Michael> side effect of a variable being declared as volatile, if for
 Michael> no other reason than the possible presence of code that is
 Michael> unnecessary in some (perhaps most) circumstances.
I don't understand that.  My reaction is just the opposite -- obeying
the defined semantics of "volatile" (the present ones as well as the
proposed ones) requires the insertion of barrier or synchronizing
instructions on platforms where those are needed to ensure ordered
global visibility.
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.

Or are you talking about a system (such as the BCM1250 MIPS processor)
which implements coherency across most, but not all, of the system
blocks?  In that case, yes, when you are using "volatile" to
communicate within the coherence domain, barrier instructions are not
needed -- but if you use "volatile" to communicate *outside* the
coherence domain, they are.  If you assume most cases are in the first
set, then you'd want the compiler not to supply barriers, you'd
handcode them instead using "asm" or builtins.  Conversely, if you
assume that most cases are in the second set, then your code will be
more reliable and only slightly slower if the compiler supplies the
barriers. 
Again, remember that there is *much* existing code that expects
the current implementation of volatile semantics.
For new code, the addition of a new qualifier specifically geared
toward this purpose would protect the current code base and allow
for a more precise specification of architectural intent.
Clearly, I come from the camp that appreciates fine grained
control. I don't like the idea of paying for features I don't
need/use.
IMHO, this concept is *very* important in systems programming
languages.
--
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: libstdc++ link failures on ppc64

[Diego Novillo]

On Thu, Apr 14, 2005 at 12:20:05PM -0700, Mark Mitchell wrote:

> Would you report your as + ld version numbers?  Again, I'm guessing that 
> you have an assembler with COMDAT and a linker without, or a broken 
> assembler.
> 
binutils-2.15.92.0.2-5

$ ld --version
GNU ld version 2.15.92.0.2 20040927


Diego.

Re: GCC 4.0 RC1 Available

[Gerald Pfeifer]

On Thu, 14 Apr 2005, Joseph S. Myers wrote:
>> gcc/doc/install.texi still mentions gcc 3.5 in a few places.
> Fixed thus (and a similar reference in cpp.texi).  It passes "make info", 
> "make dvi" and "install.texi2html".  Applied to mainline and 4.0 branch 
> (as a doc patch for which the branch is still open).

Fortunately I just checked my mailbox, because I was going to the same.
Well, in that case I'll take the other open doc issue. ;-)

Gerald

Re: Heads-up: volatile and C++

[Michael N. Moran]

Jason Merrill wrote:
On Thu, 14 Apr 2005 10:12:37 -0400, "Michael N. Moran" <[EMAIL PROTECTED]> 
wrote:

Jason Merrill wrote:
The C++ committee (well, a subgroup represented at this meeting by Hans
Boehm) is working on a memory model that supports threaded programs.
As someone who uses the C++ language and multi-threading
extensively in embedded systems, I have come to the following
belief/opinion.
  The language (C++) *should not* have dependencies
  upon threading. IMHO, threading is a layer above a
  systems programming language, and having dependencies
  upon upper layers is evil.

But the memory model for the language must provide semantics that make it
possible for threaded programs to be written.  Currently, if you want to
write a portable pthreads program you need to use a mutex around all uses
of shared memory, because they are the only way to guarantee sequential
memory ordering.  The volatile proposal provides a lighter-weight way to
write portable code with explicit memory ordering.  You need this for
lockless algorithms to work.
I am not arguing against such a language capability,
I am only arguing against overloading volatile to achieve
the goal. Thus, the other suggestions.

It seems to me that the current specification of volatile already requires
an lwsync around volatile reads and writes, to guarantee that all previous
stores have been completed and later ones have not started.
I can see how you could arrive at this point-of-view
if you accept the view that the C++ language is responsible
for understanding multi-threading. However, in the absence
of that responsibility, there is no reason for the compiler
to perform this function.
I prefer requiring the programmer to be explicit,
and understand the environment for which he writes.
In the spirit of C++, I do not want to pay overhead
for features that I do not need or use. And, as an
embedded systems programmer, I need and use volatile
frequently.
--
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 17:11:58 +0100, Nathan Sidwell <[EMAIL PROTECTED]> wrote:
... though I suppose you could argue
that they aren't required to be visible outside the current thread.
This is my interpretation since (to my knowledge) the C++ language
does not generally address threading.
--
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++

[Robert Dewar]

One interesting thing to consider here is how the C++ semantics
compares with that of pragma Volatile in Ada, which is roughly
intended to be equivalent to volatile in C.

Re: Heads-up: volatile and C++

[Diego Novillo]

On Thu, Apr 14, 2005 at 05:40:04PM +0200, Jason Merrill wrote:

> But the memory model for the language must provide semantics that make it
> possible for threaded programs to be written.  Currently, if you want to
> write a portable pthreads program you need to use a mutex around all uses
> of shared memory, because they are the only way to guarantee sequential
> memory ordering.  The volatile proposal provides a lighter-weight way to
> write portable code with explicit memory ordering.  You need this for
> lockless algorithms to work.
> 
Not necessarily.  Sequential memory ordering is not always
desirable.  There exist concurrent algorithms out there that rely
on extremely weak memory ordering semantics for performance.

Those algorithms will not appreciate the fact that 'volatile' is
now inserting unnecessary (and unwanted) synchronization that is
hidden from the programmer.

Seems to me that if C++ is all of the sudden interested in
dictating memory semantics for threaded programs, it should also
provide language capabilities for other synchronization models
and for threads (as in Java, though the memory model of Java used
to have problems of its own, dunno if they've been fixed).

Anything else will only be an incomplete specification.
Particularly if it dictates stronger semantics on 'volatile',
which has been long used in chaotic situations where you either
don't care about synchronization or are doing it explicitly.


Diego.

Re: Heads-up: volatile and C++

[Gabriel Dos Reis]

Robert Dewar <[EMAIL PROTECTED]> writes:

| One interesting thing to consider here is how the C++ semantics
| compares with that of pragma Volatile in Ada, which is roughly
| intended to be equivalent to volatile in C.

The suggestion made by Hans is to improve over the existing semantics
in C++ (which is more or less copied from C90).  Consequently, if
Ada's is roughly equivalent to volatile in C, then I would say that
the suggested semantics is roughly an improvement more or less over
Ada's ;-).

Seriously, could you give the Ada standardese even though I'm not
supposed to understand?

-- Gaby

Re: Processor-specific code

[Richard Henderson]

On Thu, Apr 14, 2005 at 10:47:26AM -0700, Steve Kargl wrote:
> Does gcc support 
> #pragma STDC FENV_ACCESS

No, but we currently act like access is "on".


r~

Re: 2 suggestions

[Georg Bauhaus]

Gerald Pfeifer wrote:
On Thu, 7 Apr 2005, Kaveh R. Ghazi wrote:
Not necessary.  If people would simply follow the directions here:
 by setting
Also, when I click on the link above, it doesn't follow down the page
to the anchor.  I'm not sure why that is.  Gerald?

Just a few days ago I learned that this is a "feature" in current
versions of texinfo: apparently XHTML disallows characters like "*"
at the beginning of an anchor, so makeinfo now prepends some magic
string.
Looking at specific.html as created by install.texi2html,
I see that that "*-" is translated to "_002a_002d".
This happens only in name attributes, not in href attributes.
So maybe the production of hrefs can use the anchor name
production function? (Can't tell where exactly the character
substitutions are done in texi2html, but this should be easy
to say for someone who knows it.)
Example from a section heading for the above link:



*-*-solaris2*

-- Georg 

Re: Heads-up: volatile and C++

[Gabriel Dos Reis]

Diego Novillo <[EMAIL PROTECTED]> writes:

[...]

| Seems to me that if C++ is all of the sudden interested in
| dictating memory semantics for threaded programs, it should also
| provide language capabilities for other synchronization models
| and for threads (as in Java, though the memory model of Java used
| to have problems of its own, dunno if they've been fixed).

There has been formed a subgroup of the C++ evolution group looking at 
concurrency/threading. 

-- Gaby

Re: 2 suggestions

[Georg Bauhaus]

Gerald Pfeifer wrote:
On Wed, 13 Apr 2005, Kaveh R. Ghazi wrote:
 

I like prepending a string, for example target= or triplet=, etc.
   

Okay.  However,...
On Thu, 14 Apr 2005, Georg Bauhaus wrote:
 

If "*-*-solaris2*" should appear as/in the "name" attribute of an ,
prepending a name start character is not enough, because this attribute
is of type NMTOKEN. Therefore it cannot contain * at all.
   

...if we are absolutely disallowed to use "*", probably just replacing
"*" by "x" without any prefix might be the lesser of all evils?
 

Or maybe 'X' for better disambiguation in hpux* -> hpuxX,
x-box vs X-box, linux*, etc.
Or '.' as Hugh suggested? ('^' leads to a type mismatch in XML.)

If international character sets in XHTML are o.K., maybe there are
some letter sets to choose from. Here is a sample.
   

I feel this might be worse, because it'll look as if everything was okay,
but when someone copies and pastes the string, it won't work as a proper
target string.  (Thanks for your expert input, by the way.)
 

True, perhaps the text that is substituted for the triplet
should look sufficiently unfamiliar in URLs. (BTW no expert
here, just frequent encounters with SGML and XML.)
-- Georg

Re: Heads-up: volatile and C++

[Diego Novillo]

On Thu, Apr 14, 2005 at 11:19:19PM +0200, Gabriel Dos Reis wrote:
> Diego Novillo <[EMAIL PROTECTED]> writes:
> 
> [...]
> 
> | Seems to me that if C++ is all of the sudden interested in
> | dictating memory semantics for threaded programs, it should also
> | provide language capabilities for other synchronization models
> | and for threads (as in Java, though the memory model of Java used
> | to have problems of its own, dunno if they've been fixed).
> 
> There has been formed a subgroup of the C++ evolution group looking at 
> concurrency/threading. 
> 
Sounds interesting.  But pretty please, don't introduce hidden
synchronization?  Particularly if it's overloading keywords that
have been used for decades with completely different semantics.


Diego.

Re: libstdc++ link failures on ppc64

[H. J. Lu]

On Thu, Apr 14, 2005 at 03:29:36PM -0400, Diego Novillo wrote:
> On Thu, Apr 14, 2005 at 12:20:05PM -0700, Mark Mitchell wrote:
> 
> > Would you report your as + ld version numbers?  Again, I'm guessing that 
> > you have an assembler with COMDAT and a linker without, or a broken 
> > assembler.
> > 
> binutils-2.15.92.0.2-5
> 
> $ ld --version
> GNU ld version 2.15.92.0.2 20040927
> 
> 

You need at least

http://sourceware.org/ml/binutils/2004-12/msg7.html

for COMDAT. Otherwise, you will get what you saw and

http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01606.html



H.J.

Re: Processor-specific code

[Joseph S. Myers]

On Thu, 14 Apr 2005, Richard Henderson wrote:

> On Thu, Apr 14, 2005 at 10:47:26AM -0700, Steve Kargl wrote:
> > Does gcc support 
> > #pragma STDC FENV_ACCESS
> 
> No, but we currently act like access is "on".

I thought we acted like it is "off", allowing CSE and constant folding 
which might be affected by changes in rounding mode.  Certainly some of 
Stephen Moshier's testcases (attached to bug 20785) fail.

-- 
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: libstdc++ link failures on ppc64

[Diego Novillo]

On Thu, Apr 14, 2005 at 01:29:53PM -0700, H. J. Lu wrote:

> You need at least
> 
> http://sourceware.org/ml/binutils/2004-12/msg7.html
> 
> for COMDAT. Otherwise, you will get what you saw and
> 
> http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01606.html
> 
OK, thanks.


Diego.

Re: Heads-up: volatile and C++

[Robert Dewar]

Gabriel Dos Reis wrote:
Seriously, could you give the Ada standardese even though I'm not
supposed to understand?
-- Gaby
Here is the relevant RM quote
15   For an atomic object (including an atomic component) all reads and
updates of the object as a whole are indivisible.
16   For a volatile object all reads and updates of the object as a whole are
performed directly to memory.
17   Two actions are sequential (see 9.10) if each is the read or update of
the same atomic object.
18   If a type is atomic or volatile and it is not a by-copy type, then the
type is defined to be a by-reference type.  If any subcomponent of a type is
atomic or volatile, then the type is defined to be a by-reference type.
19   If an actual parameter is atomic or volatile, and the corresponding
formal parameter is not, then the parameter is passed by copy.
 Implementation Requirements
20   The external effect of a program (see 1.1.3) is defined to include each
read and update of a volatile or atomic object.  The implementation shall not
generate any memory reads or updates of atomic or volatile objects other than
those specified by the program.

Cross Compile PowerPC for ReactOS

[James Tabor]

Hi!
I started resurrecting PowerPC WinNT GCC support, Ha! I'm running into this atm.
/home/gcc-3.4.3-ros/CROSS/gcc/xgcc -B/home/gcc-3.4.3-ros/CROSS/gcc/ -B/usr/powerpcle-pe/bin/ 
-B/usr/powerpcle-pe/lib/ -isystem /usr/powerpcle-pe/include -isystem /usr/powerpcle-pe/sys-include 
-O2  -DIN_GCC -DCROSS_COMPILE  -D__CYGWIN__ -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g  -DIN_LIBGCC2 
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include 
-DFINE_GRAINED_LIBRARIES -fPIC -DL_pack_sf -c fp-bit.c -o libgcc/./_pack_sf.o

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

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

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

Re: Heads-up: volatile and C++

[Jason Merrill]

On Thu, 14 Apr 2005 16:04:33 -0400, Diego Novillo <[EMAIL PROTECTED]> wrote:

> On Thu, Apr 14, 2005 at 05:40:04PM +0200, Jason Merrill wrote:
>
>> But the memory model for the language must provide semantics that make it
>> possible for threaded programs to be written.  Currently, if you want to
>> write a portable pthreads program you need to use a mutex around all uses
>> of shared memory, because they are the only way to guarantee sequential
>> memory ordering.  The volatile proposal provides a lighter-weight way to
>> write portable code with explicit memory ordering.  You need this for
>> lockless algorithms to work.

> Not necessarily.  Sequential memory ordering is not always
> desirable.  There exist concurrent algorithms out there that rely
> on extremely weak memory ordering semantics for performance.

I shouldn't have used the term "sequential memory ordering."  Nobody is
suggesting that C++ should enforce sequential consistency between threads.
But even in the weakest memory models...*especially* in the weakest memory
models, you need a way of making sure that you are up to date with the
global state (in one of several senses) before you continue execution, and
acquire/release semantics are a very convenient synchronization model.

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.

> Seems to me that if C++ is all of the sudden interested in
> dictating memory semantics for threaded programs, it should also
> provide language capabilities for other synchronization models
> and for threads (as in Java, though the memory model of Java used
> to have problems of its own, dunno if they've been fixed).

I believe the plan is to offer library functions which provide
finer-grained control over synchronization primitives, but that volatile
would be good enough for most uses, and easy to teach.

> Anything else will only be an incomplete specification.
> Particularly if it dictates stronger semantics on 'volatile',
> which has been long used in chaotic situations where you either
> don't care about synchronization or are doing it explicitly.

The main reason I posted this now was to get more information about current
uses of volatile, so I can block this proposal in the committee if
necessary.  I find it hard to believe that volatile is currently used in
multithreaded code in ways that would be negatively impacted by this
change, but I'm very interested in examples.

The device driver case seems like a more plausible objection to me, but I'd
like to see an example there, too.

Jason

Re: Heads-up: volatile and C++

[Jason Merrill]

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.

Jason

Re: 2 suggestions

[Gerald Pfeifer]

On Thu, 14 Apr 2005, Hugh Sasse Staff Elec Eng wrote:
>> ...if we are absolutely disallowed to use "*", probably just replacing
>> "*" by "x" without any prefix might be the lesser of all evils?
> So long as things to get ported to the x-box?

That port wouldn't be called x-box, because dash separates the different 
parts of a target tripplet (which is why the platform by the marketing 
name of AMD64 is spelled x86_64 instead x86-64).
 
On Thu, 14 Apr 2005, Kaveh R. Ghazi wrote:
> I guess "x" is fine with me.  However can we use "x" only in the
> anchor and not the link's text label?  E.g.:
> 
>   alpha*-*-*
> 
> That way, the part people actually read in the document still uses
> asterisk that they are used to seeing.

Your wish is my command.  Patch proposal below for comments

This patch accomplishes the goal to get rid of asterisks in @anchor
names by

 - replacing components of a target triplet which read "*" by "x",
 - and omiting trailing asterisks from all other components.

Tested by running doc/install.texi2html and selecting every single
link in the directory of specific.html.

Gerald


2005-04-14  Gerald Pfeifer  <[EMAIL PROTECTED]>

* doc/install.texi: Avoid using asterisks in @anchor names.
Remove i?86-*-esix from platform directory.
Remove powerpc-*-eabiaix from platform directory.

Index: doc/install.texi
===
RCS file: /cvs/gcc/gcc/gcc/doc/install.texi,v
retrieving revision 1.344
diff -u -3 -p -r1.344 install.texi
--- doc/install.texi6 Apr 2005 15:36:04 -   1.344
+++ doc/install.texi14 Apr 2005 21:40:28 -
@@ -2167,19 +2167,19 @@ GNU Compiler Collection on your machine.
 @ifhtml
 @itemize
 @item
[EMAIL PROTECTED],,alpha*-*-*}
[EMAIL PROTECTED],,alpha*-*-*}
 @item
[EMAIL PROTECTED],,alpha*-dec-osf*}
[EMAIL PROTECTED],,alpha*-dec-osf*}
 @item
[EMAIL PROTECTED],,alphaev5-cray-unicosmk*}
[EMAIL PROTECTED],,alphaev5-cray-unicosmk*}
 @item
[EMAIL PROTECTED],,arc-*-elf}
[EMAIL PROTECTED],,arc-*-elf}
 @item
[EMAIL PROTECTED],,arm-*-elf}
[EMAIL PROTECTED],,arm-*-coff}
[EMAIL PROTECTED],,arm-*-aout}
[EMAIL PROTECTED],,arm-*-elf}
[EMAIL PROTECTED],,arm-*-coff}
[EMAIL PROTECTED],,arm-*-aout}
 @item
[EMAIL PROTECTED],,xscale-*-*}
[EMAIL PROTECTED],,xscale-*-*}
 @item
 @uref{#avr,,avr}
 @item
@@ -2189,39 +2189,37 @@ GNU Compiler Collection on your machine.
 @item
 @uref{#dos,,DOS}
 @item
[EMAIL PROTECTED],,*-*-freebsd*}
[EMAIL PROTECTED],,*-*-freebsd*}
 @item
 @uref{#h8300-hms,,h8300-hms}
 @item
[EMAIL PROTECTED],,hppa*-hp-hpux*}
[EMAIL PROTECTED],,hppa*-hp-hpux*}
 @item
[EMAIL PROTECTED],,hppa*-hp-hpux10}
[EMAIL PROTECTED],,hppa*-hp-hpux10}
 @item
[EMAIL PROTECTED],,hppa*-hp-hpux11}
[EMAIL PROTECTED],,hppa*-hp-hpux11}
 @item
[EMAIL PROTECTED],,*-*-linux-gnu}
[EMAIL PROTECTED],,*-*-linux-gnu}
 @item
[EMAIL PROTECTED],,i?86-*-linux*aout}
[EMAIL PROTECTED],,i?86-*-linux*aout}
 @item
[EMAIL PROTECTED],,i?86-*-linux*}
[EMAIL PROTECTED],,i?86-*-linux*}
 @item
[EMAIL PROTECTED],,i?86-*-sco3.2v5*}
[EMAIL PROTECTED],,i?86-*-sco3.2v5*}
 @item
[EMAIL PROTECTED],,i?86-*-udk}
[EMAIL PROTECTED],,i?86-*-udk}
 @item
[EMAIL PROTECTED],,i?86-*-esix}
[EMAIL PROTECTED],,ia64-*-linux}
 @item
[EMAIL PROTECTED],,ia64-*-linux}
[EMAIL PROTECTED],,ia64-*-hpux*}
 @item
[EMAIL PROTECTED],,ia64-*-hpux*}
[EMAIL PROTECTED],,*-ibm-aix*}
 @item
[EMAIL PROTECTED],,*-ibm-aix*}
[EMAIL PROTECTED],,ip2k-*-elf}
 @item
[EMAIL PROTECTED],,ip2k-*-elf}
[EMAIL PROTECTED],,iq2000-*-elf}
 @item
[EMAIL PROTECTED],,iq2000-*-elf}
[EMAIL PROTECTED]
[EMAIL PROTECTED],,m32r-*-elf}
[EMAIL PROTECTED],,m32r-*-elf}
 @item
 @uref{#m6811-elf,,m6811-elf}
 @item
@@ -2229,63 +2227,61 @@ GNU Compiler Collection on your machine.
 @item
 @uref{#m68k-hp-hpux,,m68k-hp-hpux}
 @item
[EMAIL PROTECTED],,mips-*-*}
[EMAIL PROTECTED],,mips-*-*}
 @item
 @uref{#mips-sgi-irix5,,mips-sgi-irix5}
 @item
 @uref{#mips-sgi-irix6,,mips-sgi-irix6}
 @item
[EMAIL PROTECTED],,powerpc*-*-*, powerpc-*-sysv4}
[EMAIL PROTECTED]
[EMAIL PROTECTED],,powerpc-*-darwin*}
[EMAIL PROTECTED],,powerpc*-*-*, powerpc-*-sysv4}
 @item
[EMAIL PROTECTED],,powerpc-*-elf, powerpc-*-sysv4}
[EMAIL PROTECTED],,powerpc-*-darwin*}
 @item
[EMAIL PROTECTED],,powerpc*-*-linux-gnu*}
[EMAIL PROTECTED],,powerpc-*-elf, powerpc-*-sysv4}
 @item
[EMAIL PROTECTED],,powerpc-*-netbsd*}
[EMAIL PROTECTED],,powerpc*-*-linux-gnu*}
 @item
[EMAIL PROTECTED],,powerpc-*-eabiaix}
[EMAIL PROTECTED],,powerpc-*-netbsd*}
 @item
[EMAIL PROTECTED],,powerpc-*-eabisim}
[EMAIL PROTECTED],,powerpc-*-eabisim}
 @item
[EMAIL PROTECTED],,powerpc-*-eabi}
[EMAIL PROTECTED],,powerpc-*-eabi}
 @item
[EMAIL PROTECTED],,powerpcle-*-elf, powerpcle-*-sysv4}
[EMAIL PROTECTED],,powerpcle-*-elf, powerpcle-*-sysv4}
 @item
[EMAIL PROTECTED],,powerpcle-*-eabisim}
[EMAIL PROTECTED],,powerpcle-*-eabisim}
 @item
[EMAIL PROTECTED],,powerpcle-*-eabi}
[EMAIL PROTECTED],,powerpcle-*-eabi}
 @item
[EMAIL PROTECTED],,s390-*-linux*}
[EMAIL PROTECTED],,s390-*-linux*}

Joseph appointed i18n maintainer

[Gerald Pfeifer]

It is my pleasure to announce that the steering committee has appointed 
Joseph Myers i18n maintainer, an area he's been taking care of for quite
some time now.

Please adjust the MAINTAINERS file accordingly, Joseph, and Happy hacking!

Gerald

Re: internal compiler error at dwarf2out.c:8362

[James E Wilson]

Martin Koegler wrote:
I changed the attribute handler to only return NULL_TREE in any case, but
the result is still the same (using the same gcc core).
But you are still creating the types in the attribute function right? 
If so, that is probably why you still have a problem.

You mentioned that this works for all types except array types.  Instead 
of trying to figure out why array types don't work, perhaps you should 
figure out why other types do work, and then maybe you can understand 
why array types don't work.

Looking at this, I see that you have two array types, both with the same 
typename which points at the same type decl.  It doesn't seem right for 
two different types to both claim to be the same typedef.  That doesn't 
seem to be an issue though.

I tried grepping the sources, and I see this same code appears in the 
avr and ip2k ports.  That gives me a way to try to reproduce the problem 
with FSF sources.  Avr doesn't support DWARF2, and ip2k is being 
obsoleted because it is unmaintained.  These probably aren't very good 
examples to copy from.  Anyways, I tried building ip2k-elf, changing 
your testcase to use progmem instead of eeprom, and it compiles OK. 
Perhaps your problem is already fixed on mainline, or maybe you have 
some other changes in your tree that are causing problems.  I suggest 
you try looking at why the ip2k port works when yours doesn't.

If you can produce an example that fails in the FSF tree, then I can try 
looking at this some more.  Otherwise, it seems to be a bug in your 
port, and you will need to find the problem yourself.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Heads-up: volatile and C++

[Laurent GUERBY]

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

Laurent

C.6 Shared Variable Control

  Dynamic Semantics

15For an atomic object (including an atomic component) all reads and
updates of the object as a whole are indivisible.

16For a volatile object all reads and updates of the object as a whole are
performed directly to memory.

16.a  Implementation Note: This precludes any use of register temporaries,
  caches, and other similar optimizations for that object.

17{sequential (actions)} Two actions are sequential (see 9.10) if each is
the read or update of the same atomic object.

18{by-reference type (atomic or volatile) [partial]} If a type is atomic
or volatile and it is not a by-copy type, then the type is defined to be a
by-reference type. If any subcomponent of a type is atomic or volatile, then
the type is defined to be a by-reference type.

19If an actual parameter is atomic or volatile, and the corresponding
formal parameter is not, then the parameter is passed by copy.

19.a  Implementation Note: Note that in the case where such a parameter is
  normally passed by reference, a copy of the actual will have to be
  produced at the call-site, and a pointer to the copy passed to the
  formal parameter. If the actual is atomic, any copying has to use
  indivisible read on the way in, and indivisible write on the way
  out.

19.b  Reason: It has to be known at compile time whether an atomic or a
  volatile parameter is to be passed by copy or by reference. For some
  types, it is unspecified whether parameters are passed by copy or by
  reference. The above rules further specify the parameter passing
  rules involving atomic and volatile types and objects.


 Implementation Requirements

20{external effect (volatile/atomic objects) [partial]} The external
effect of a program (see 1.1.3) is defined to include each read and update of
a volatile or atomic object. The implementation shall not generate any memory
reads or updates of atomic or volatile objects other than those specified by
the program.

20.a  Discussion: The presumption is that volatile or atomic objects might
  reside in an ``active'' part of the address space where each read
  has a potential side-effect, and at the very least might deliver a
  different value.

20.b  The rule above and the definition of external effect are intended to
  prevent (at least) the following incorrect optimizations, where V is
  a volatile variable:

20.c  X:= V; Y:=V; cannot be allowed to be translated as Y:=V; X:=V;

20.d  Deleting redundant loads: X:= V; X:= V; shall read the value of V
  from memory twice.

20.e  Deleting redundant stores: V:= X; V:= X; shall write into V twice.

20.f  Extra stores: V:= X+Y; should not translate to something like V:= X;
  V:= V+Y;

20.g  Extra loads: X:= V; Y:= X+Z; X:=X+B; should not translate to
  something like Y:= V+Z; X:= V+B;

20.h  Reordering of loads from volatile variables: X:= V1; Y:= V2;
  (whether or not V1 = V2) should not translate to Y:= V2; X:= V1;

20.i  Reordering of stores to volatile variables: V1:= X; V2:= X; should
  not translate to V2:=X; V1:= X;

Re: Heads-up: volatile and C++

[Paul Koning]

> "Jason" == Jason Merrill <[EMAIL PROTECTED]> writes:

 Jason> On Thu, 14 Apr 2005 15:47:44 -0500, Robert Dewar
 Jason> <[EMAIL PROTECTED]> wrote:
 >> [Ada standard]

 Jason> Yep, sounds a lot like C/C++: volatile reads and writes are
 Jason> required to have sequential ordering relative to each other,
 Jason> but (outside the current thread) they are not ordered relative
 Jason> to non-volatile reads and writes.

That sounds sensible, but I have no idea how you distilled that
meaning out of the text that Robert quoted.

paul

Re: internal compiler error at dwarf2out.c:8362

[E. Weddington]

James E Wilson wrote:
I tried grepping the sources, and I see this same code appears in the 
avr and ip2k ports.  That gives me a way to try to reproduce the 
problem with FSF sources.  Avr doesn't support DWARF2, and ip2k is 
being obsoleted because it is unmaintained.

As a side note, the AVR port is migrating to using DWARF2, especially on 
Windows hosts. But there are known bugs regarding AVR and DWARF2:





Eric

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

[John David Anglin]

> : build/genattrtab 
> /home/kate/gcc-4.0.0-20050410/src/gcc-4.0.0-20050410/gcc/config/rs6000/ 
> rs6000.md > tmp-attrtab.c
> : 
> : out of memory allocating 12016 bytes after a total of 4161654476 bytes

You need to increase the application limits for data on your system.
That's what the above rather uninformative message is trying to say.
You might be able to do this with ulimit but most likely you need to
change the kernel limits.

This worked for me on AIX 4.3:

ginyu% ulimit -a
cpu time (seconds) unlimited
file size (blocks) unlimited
data seg size (kbytes) unlimited
stack size (kbytes)131072
core file size (blocks)unlimited
resident set size (kbytes) unlimited
virtual memory size (kb)   unlimited
file descriptors   2000

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Mainline bootstrap failure in tree-ssa-pre.c:create_value_expr_from

[Wolfgang Bangerth]

For the last few days, since April 8th, I get bootstrap failures on 
mainline like this:

stage1/xgcc -Bstage1/
   -B/ices/bangerth/tmp/build-gcc/gcc-install/i686-pc-linux-gnu/bin/ -c -g
   -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
   -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
   -Wold-style-definition -Werror -fno-common   -DHAVE_CONFIG_H-I. -I.
   -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
   -I../../gcc/gcc/../libcpp/include  ../../gcc/gcc/tree-ssa-pre.c -o
   tree-ssa-pre.o
../../gcc/gcc/tree-ssa-pre.c: In function 'execute_pre':
../../gcc/gcc/tree-ssa-pre.c:1812: sorry, unimplemented: inlining failed in 
call to 'create_value_expr_from': recursive inlining
../../gcc/gcc/tree-ssa-pre.c:1853: sorry, unimplemented: called from here
make[1]: *** [tree-ssa-pre.o] Error 1
The failure happens in a piece of code that was added here:
   http://gcc.gnu.org/ml/gcc-bugs/2005-04/msg00337.html
by Dan Berlin (it introduced the recursive calls), though it certainly 
isn't the cause, just the trigger. It also was added already April 4th.

Since this has been happening for the last 10 days for me, I start to 
believe that I may be the only one seeing this. Anyone any explanations?

Thanks
   Wolfgang
PS: System is "Linux terra.ices.utexas.edu 2.4.25-13mdkenterprise #1 SMP 
Tue Jan 18 14:02:17 MST 2005 i686 unknown unknown GNU/Linux", the 
bootstrap compiler is Mandrake's gcc 3.3.2.

-
Wolfgang Bangerth  email:[EMAIL PROTECTED]
www: http://www.ices.utexas.edu/~bangerth/

Re: GCC 4.0 RC2

[Mark Mitchell]

Joel Sherrill <[EMAIL PROTECTED]> wrote:
I know I asked late in the process but this fix for a m68k/coldfire 
failure just showed up:

[Bug target/18421] ICE in reload_cse_simplify_operands, at postreload.c:391
Any chance at it getting considered?
This is OK if approved for mainline by a 68K maintainer.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: GCC 4.0 RC2

[Mark Mitchell]

Richard Sandiford wrote:
Mark,
I tried running some MIPS16 tests against RC1 and found a regression
from 3.4.  The problem is the following hack in mips.h:

/* When generating mips16 code we want to put the jump table in the .text
   section.  In all other cases, we want to put the jump table in the .rdata
   section.  Unfortunately, we can't use JUMP_TABLES_IN_TEXT_SECTION, because
   it is not conditional.  Instead, we use ASM_OUTPUT_CASE_LABEL to switch back
   to the .text section if appropriate.  */
#undef ASM_OUTPUT_CASE_LABEL
#define ASM_OUTPUT_CASE_LABEL(FILE, PREFIX, NUM, INSN)  \
do {\
  if (TARGET_MIPS16)\
function_section (current_function_decl);   \
  (*targetm.asm_out.internal_label) (FILE, PREFIX, NUM);\
} while (0)


* config/mips/mips.h (ASM_OUTPUT_CASE_LABEL): Delete.
(JUMP_TABLES_IN_TEXT_SECTION): Define.
OK for 4.0 RC2.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: Mainline bootstrap failure in tree-ssa-pre.c:create_value_expr_from

[Andrew Pinski]

On Apr 14, 2005, at 6:51 PM, Wolfgang Bangerth wrote:
For the last few days, since April 8th, I get bootstrap failures on 
mainline like this:

stage1/xgcc -Bstage1/
   -B/ices/bangerth/tmp/build-gcc/gcc-install/i686-pc-linux-gnu/bin/ 
-c -g
   -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
   -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
   -Wold-style-definition -Werror -fno-common   -DHAVE_CONFIG_H-I. 
-I.
   -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
   -I../../gcc/gcc/../libcpp/include  ../../gcc/gcc/tree-ssa-pre.c -o
   tree-ssa-pre.o
../../gcc/gcc/tree-ssa-pre.c: In function 'execute_pre':
../../gcc/gcc/tree-ssa-pre.c:1812: sorry, unimplemented: inlining 
failed in call to 'create_value_expr_from': recursive inlining
../../gcc/gcc/tree-ssa-pre.c:1853: sorry, unimplemented: called from 
here
make[1]: *** [tree-ssa-pre.o] Error 1
Isn't this the normal always_inline problem from the kernel headers?
-- Pinski

Re: Heads-up: volatile and C++

[Richard Henderson]

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?

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.


r~

Re: Mainline bootstrap failure in tree-ssa-pre.c:create_value_expr_from

[Wolfgang Bangerth]

Isn't this the normal always_inline problem from the kernel headers?
Yes, good spot. Thanks for the help!
W.
-
Wolfgang Bangerth  email:[EMAIL PROTECTED]
   www: http://www.ices.utexas.edu/~bangerth/

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

[Mark Mitchell]

Alexandre Oliva wrote:
On Apr 14, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote:

On Thu, Apr 14, 2005 at 12:13:59PM -0300, Alexandre Oliva wrote:
* tree-eh.c (lower_try_finally_copy): Generate new code in
response to goto_queue entries as if the queue was sorted by
index, not pointers.
(lower_try_finally_switch): Likewise.

Ok.

Mark, ok for 4.0 as well?
Richard, what's your level of confidence here?  I'd rather not break C++ 
or Java...

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

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

[Alexandre Oliva]

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

> Alexandre Oliva wrote:
>> On Apr 14, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote:
>> 
>>> On Thu, Apr 14, 2005 at 12:13:59PM -0300, Alexandre Oliva wrote:
>>> 
 * tree-eh.c (lower_try_finally_copy): Generate new code in
 response to goto_queue entries as if the queue was sorted by
 index, not pointers.
 (lower_try_finally_switch): Likewise.
>> 
>>> Ok.
>> Mark, ok for 4.0 as well?

> Richard, what's your level of confidence here?  I'd rather not break
> C++ or Java...

If you look closely, you'll see it's just enforcing a known order to
the operations.  If you prefer, I can prepare a patch that copies the
goto_queue, sorts that by index, and iterates on that instead of the
sorted-by-stmt goto_queue.

If it helps any, bootstrap and regtest passed on 4.0 branch,
amd64-linux-gnu.

-- 
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: Heads-up: volatile and C++

[Diego Novillo]

On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote:

> I shouldn't have used the term "sequential memory ordering."  Nobody is
> suggesting that C++ should enforce sequential consistency between threads.
> But even in the weakest memory models...*especially* in the weakest memory
> models, you need a way of making sure that you are up to date with the
> global state (in one of several senses) before you continue execution, and
> acquire/release semantics are a very convenient synchronization model.
> 
Again, not always.  Consider chaotic asynchronous algorithms
(like variations of simulated annealing).  They need no locks nor
any other kind of synchronization, though sometimes they'll use
some form of control synchronization to delimit phases.

When implementing them in a shared-memory multithreaded
environment, they typically mark shared data as 'volatile' to
prevent the compiler from optimizing those references away.

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

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

> The main reason I posted this now was to get more information about current
> uses of volatile, so I can block this proposal in the committee if
> necessary.  I find it hard to believe that volatile is currently used in
> multithreaded code in ways that would be negatively impacted by this
> change, but I'm very interested in examples.
> 
Oh, it's been a while.  All the ones that come to mind are
relatively obscure research topics.  One I remember was from the
game theory folks at my old school

http://www.cs.ualberta.ca/~jonathan/Grad/Papers/aphidiee.ps

There's a somewhat tedious survey of asynchronous parallel
techniques at

http://web.nchu.edu.tw/~jlu/research/papers/asynch.ps

Note that the initial motivation for many of these techniques was
to yield good results on distributed systems.  But if you were to
implement them in a multithreaded environment with shared data
instead of message passing, they'd declare the shared data volatile.

> The device driver case seems like a more plausible objection to me, but I'd
> like to see an example there, too.
> 
Perhaps Windows?  I'd think Windows is chok full of device
drivers written in C++.


Diego.

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

[Ian Lance Taylor]

Peter Barada <[EMAIL PROTECTED]> writes:

> This is driving me up a tree.  I have a fix for 18421(on mainline &
> gcc-3.4.3) that uses HARD_REGNO_MODE_OK to prevent bytes into address
> registers, and modified movqi for ColdFire to drop the '*a' in
> d*a/di*a constraint, as well as modified addsi3_5200 to us 'i' instead
> of 's'.
> 
> My current problem is when I'm compiling Perl for the ColdFire v4e
> using gcc-3.4.3 for m68k-linux, and I'm seeing:
> 
> [EMAIL PROTECTED] tmp]$ 
> /opt/logicpd/ColdFire-new12/m68k-linux/gcc-3.4.3-glibc-2.3.2/bin/m68k-linux-gcc
>  -DPERL_CORE -mcfv4e -fno-strict-aliasing -D_LARGEFILE_SOURCE 
> -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 pp_pack.c -S -o pp_pack.s -da
> pp_pack.c: In function `S_unpack_rec':
> 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))
> (nil))
> pp_pack.c:2220: confused by earlier errors, bailing out

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.

Ian

Re: Heads-up: volatile and C++

[Marcin Dalecki]

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++.
Actually speaking about embedded C++. Well, it would be helpful
to have an option for the C++ frontend which would disallow
constructs prohibited by it. If I only could find the time right now...

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

[Richard Henderson]

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.


r~

Objective-C++ Status

[Douglas Charles]

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 
 
 
-- 
___
NEW! Lycos Dating Search. The only place to search multiple dating sites at 
once.
http://datingsearch.lycos.com

Re: Heads-up: volatile and C++

[Devang Patel]

On Apr 14, 2005, at 8:11 PM, Diego Novillo wrote:
The device driver case seems like a more plausible objection to  
me, but I'd
like to see an example there, too.

Perhaps Windows?  I'd think Windows is chok full of device
drivers written in C++.
Here in Mac OS X land, many device drivers are written in C++ using  
IOKit.

-
Devang

"make bootstrap" for cross builds

[Ranjit Mathew]

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.

Ranjit.

-- 
Ranjit Mathew  Email: rmathew AT gmail DOT com

Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/

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 the data registers */
  if ((regno) + GET_MODE_SIZE (mode) / 4 > 8)
return 0;
  return 1;
}
  else if (regno < 16)
{
  /* Address Registers, can't hold bytes, can hold aggregate if
 fits in */
  if (GET_MODE_SIZE (mode) == 1)
return 0;
  if (!((regno) < 8 && (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: "make bootstrap" for cross builds

[Andrew Pinski]

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.

-- Pinski

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

[Mark Mitchell]

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.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: Heads-up: volatile and C++

[Alexandre Oliva]

On Apr 15, 2005, Marcin Dalecki <[EMAIL PROTECTED]> wrote:

> On 2005-04-15, at 01:10, Richard Henderson wrote:

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

It doesn't really have to be templates.  Consider static_cast et al.
They look like template function calls, but aren't.

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