Re: gcc-4.1-20080303 is now available

[Kaveh R. Ghazi]

From: "Mark Mitchell" <[EMAIL PROTECTED]>


Kaveh R. GHAZI wrote:


My understanding is that *users* of GCC are not impacted by the license
change.


Some users certainly are impacted by the license change -- there are in 
fact quite a few companies that disallow their users using any GPLv3 
software!


I think you're right that GPLv3 has no substantial impact on what you can 
or cannot do with GCC, and therefore that most users -- once they and 
their legal departments understand GPLv3 -- can go on using GCC in exactly 
the ways they did when it was GPLv2.  But, that doesn't mean that it's not 
a major surprise to have an update release have a new and different 
license, with which you might not be familiar.


Then it all boils down to FUD.  And IMHO we're being complicit in it by 
validating and enabling it.


Some legal departments may prohibit using all GPLv3 software.  But since we 
haven't released gcc-4.1.3, users are not getting it anyway.  (I'd say very 
few users are adventurous enough to rely on svn or snapshots as Gerald 
suggested.)  At least by releasing 4.1.3 some (many? most?) users would get 
the benefit, and as more legal departments work through their fears more 
(all) users will eventually benefit.


I haven't heard anything that changes my opinion, I still think we should 
relicense the 4.1 branch and do one last release before closing it.


Am I alone here, or does anyone else agree with me? :-/

   --Kaveh
--
Kaveh R. Ghazi

C++0x rvalue references get clobbered somehow

[Lukas Mai]

Hello!

(I sent a copy of this mail to gcc-help a few days ago but didn't
get a response.)

I'm having problems with g++-4.3.0 and C++0x. Disclaimer: I don't
understand rvalue references, but since I need (indirect) argument
forwarding, I copied and modified an example from the web.
(I believe detail_region::fw is equivalent to std::forward.)

Here's (a simplified version of) my code. Details like destructors,
dynamic memory management, etc are gone; it's just generic object
construction.

--
#include 
#include 

namespace awesome {

namespace detail_region {
template struct Typedef { typedef T t; };
template T &&fw(typename Typedef::t &&x) { return x; }

template struct tuple;

template<> struct tuple<> {
template T *capply(void *place, Args 
&&...args) const {
return new (place) T(fw(args) ...);
}
};

template struct tuple {
Hd &&head;
tuple tail;
tuple(Hd &&h, Tl &&...t) : head(fw(h)), tail(fw(t) ...) {}

template T *capply(void *place, Args 
&&...args) const {
return tail.capply(place, fw(args) ..., fw(head));
}
};
}

struct region {
private:
template struct spork {
detail_region::tuple args;

spork(Args &&...x) : args(detail_region::fw(x) ...) {}

template operator T *() const {
// ::operator new(1);
// std::cout << "hi\n";
std::rand();  // XXX any function call here seems to cause 
problems

static char raw_[sizeof (T)];
return args.template capply(raw_);
}
};

public:

template spork alloc(Args &&...args) {
return spork(detail_region::fw(args) ...);
}
};
}


using namespace std;

int main() {
using awesome::region;

region r;
int *p = r.alloc(123);
cout << *p << '\n';
}
--

This code works fine (and prints 123) when compiled with
g++ -std=c++0x -O2 (or -Os or -O). However, without optimization
it produces output like -1207981096. This number changes if
different function calls are used at the location marked XXX.

Somehow args.head loses its value between construction (in alloc)
and use (in capply), but only if optimizations are not enabled.

I think args.head should be bound to the temporary value 123,
which should stay alive until the next statement. But something
seems to overwrite it before p is initialized.

Can you explain to me what's going on here? How can I fix this
code? Or is this a bug in g++? (And is this the right place to ask?)

Thanks in advance
Lukas

Re: Regression with ltrans-7.f90

[FX Coudert]

Hi Steve,

I don't think you should send mail directly to gcc-bugs ("gcc-bugs is  
a relatively high volume list with mails from our Bugzilla bug- 
tracking system"). I think, apart from Andrew, noone's subscribed to  
it :)


FAIL: gfortran.dg/ltrans-7.f90  -O  scan-tree-dump-times ltrans  
"transformed loop" 1



Sounds like a target-specific issue with -ftree-loop-linear.  
According to gcc-testresults, it is seen on i386-freebsd and i386- 
netbsd. Similar C failures happen on i386-rtems. Maybe the loop can  
be transformed only for processors later than i386? In any case, this  
most probably isn't a Fortran issue.


Daniel, Zdenek, I assume you being "linear loop transforms" and "loop  
infrastructure" maintainers means you're the right persons to CC, so  
there you go.


FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: va_list bug?

[Kai Tietz]

[EMAIL PROTECTED] wrote on 19.03.2008 01:59:04:

> hello,
> 
> please try the little program at the end. my naive assumption was that
> it will print "hello world" two times.
> 
> if compiled with gcc 3.4, 4.1, 4.2 or 4.3 for i386, it will print "hello
> world" two times all right.
> 
> however, if compiled with 3.3, 3.4, 4.1 or 4.3 for amd64, the second
> time it will print "hello @[EMAIL PROTECTED]" (garbage).
> 
> it seems that the gp_offset field of the va struct gets modified by
> someone, so the second vprintf prints garbage:
> 
> vp (fmt=0x400672 "hello %s\n", args=0x7fff0e83aec0) at v.c:6
> 6   vprintf(fmt, args);
> (gdb) display *args
> 1: *args = {gp_offset = 8, fp_offset = 48, overflow_arg_area =
> 0x7fff0e83afa0, reg_save_area = 0x7fff0e83aee0}
> (gdb) n
> hello world
> 7   vprintf(fmt, args);
> 1: *args = {gp_offset = 16, fp_offset = 48, overflow_arg_area =
> 0x7fff0e83afa0, reg_save_area = 0x7fff0e83aee0}
> 
> i don't know whether this is a gcc issue or a libc issue, but i suspect
> that it's a bug. please clarify.
> i have a debian etch amd64 system, glibc is 2.3.6.
> 
> searching for "gcc glibc variadic argument bug" didn't give any relevant
> pages.
> 
> regards, peter
> 
> 8<8<8<8<8<8<8<8<8<
> #include 
> #include 
> 
> void vp(const char* fmt, va_list args)
> {
> vprintf(fmt, args);
> vprintf(fmt, args);
> }
> 
> void p(const char* fmt, ...)
> {
> va_list args;
> va_start(args, fmt);
> vp(fmt, args);
> va_end(args);
> }
> 
> int main()
> {
> p("hello %s\n", "world");
> }

You should use va_copy with amd64 abi. See 
http://www.linuxmanpages.com/man3/stdarg.3.php for more details. The amd64 
abi passes arguments in registers.

Cheers,
  Kai

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

Re: [trunk] Addition to subreg section of rtl.text.

[Kenneth Zadeck]

Richard Sandiford wrote:

Hi Joern,

Thanks for the answer,

Joern Rennecke <[EMAIL PROTECTED]> writes:
  
Thanks very much for replying to this.   We were starting to get worried 
that no one was going to reply and we would be left out in the cold.


kenny


1) Is it possible to have a MODE_PARTIAL_INT inner register that is bigger than 
a word?
  

Yes.  You might have a 20 bit register, which is considered Pmode == PHImode,
with a lower half QImode (16 bit, word addressed) which can be accessed
separately by arithmetic instructions.



OK.

  

If so, what restrictions (if any) apply to subregs that access the
partial word? Is the inner register implicitly extended so that it is
a whole number of words? If not, are we effectively allowing
non-contiguous byte ranges when WORDS_BIG_ENDIAN != BYTES_BIG_ENDIAN?
  

As far as GCC is concerned, the partial integer mode has the same size as
the underlying integral mode, but the upper bits are undefined or defined
in a machine-dependent manner.  That makes sense when you consider that in
the example above, the 20 bit register has to be stored in a 32 bit memory
location.  So as far as GCC is concerned, it is a value that is accomodated
in the same storage space as a HImode value, hut some bits behave in a way
it can't quite predict.
Still, you can get two QImode halves out of a PHImode value.  Or you could
choose to take two PQImode halves.
At least that the theory.  I don't know if it still works, as a number of
DSP processors have been removed in the last years, and some new ports
were never contributed.



E.g., suppose we have a 16-bit WORDS_BIG_ENDIAN, !BYTES_BIG_ENDIAN
target in which PSImode is a 24-bit value. Is the layout of 0x543210
"45..0123"?
  

The most natural layout would be 0x45??0123 .
But you could also have 0x345?012? , or even more exotic mappings.



Do we actually support the second mapping though?  Surely the
target-independent code needs to know how bytes are divided into words?

The reason Kenny's looking at this is that he wants to track which
bytes in a SUBREG are actually live.

  

2) Is it possible for the outer register in a normal subreg to be a superword 
MODE_PARTIAL_INT? (Our rules say "no".)
  

It is needed for some processors, currently not officially supported.
In the example above with the 20 bit addresses, some C++ address arithmetic
is performed in SImode, and then at some stage this is converted to PSImode.



3) What about things like 80-bit FP modes on a 32-bit or 64-bit target? Is it 
valid to refer to pieces of an 80-bit FP pseudo? If so, are the rules we've got 
here right?
  

Where the 80-bit mode is stored in multiple words like for x86, you
should be able to refer to word_mode subregs the way the value is
stored in memory.  This is the only way you can get a sane equivalence
between reloads via secondary memory and direct register-register
moves invollving word_mode GENERAL_REGS.



OK, so in all these cases, "N words and a bit" modes can be treated
like "N + 1 words, with the upper bits undefined"?  For both inner
and outer modes?

  

4) Do stores to subregs of hardreg invalidate just the registers
mentioned in the outer mode or do they invalidate the entire set of
registers mentioned in the inner mode? (our rules say only the outer
mode).
  

Where the hardreg is actually a single hardware register, all of it is
clobbered.  If it is a concatenation of multiple actual hard
registers, the idea is that only the one that corresponds to the word
that is stored into gets clobbered.  If more than one word is stored
into, that would logically translate to changing each of the registers
that each word corresponds to.

What seems less defined is what happens when the underlying hard registers
are smaller than a word, and either the mode size or SUBREG_BYTE
is not a multiple of a word.



Yeah, my version of the question was more: do we support subregs of
hard registers in which the normal word-based semantics of pseudos
do not apply?  The current documentation expressly forbids taking
an SImode subreg of a DImode hard register on a 32-bit machine,
for example, and I agree that the subword hard register case is
also suspicious.

  

It is seldom necessary to wrap
hard registers in @code{subreg}s; such registers would normally
reduce to a single @code{reg} rtx.
  

reload handling of matching operands of different size is broken for
big endian, hence paradoxical subregs of hard registers are essential
to express such matching operands.



Without wanting to fan flames, isn't this something that should
be fixed in reload? ;)  Reload is amenable to change...

Richard
  

Re: gcj broken on darwin

[Andrew Haley]

Jack Howarth wrote:
>It appears that gcj in gcc 4.3.0 is broken on Darwin. If
> one builds gcc 4.3.0 executing...
> 
> contrib/download_ecj
> 
> before running configure, the build succeeds in creating an
> ecj1 but when gcj is used to compile an example like testme.java...
> 
> public class testme {
>   public static void main(String args[]){
> System.out.println("Hello");
>   }
> }
> 
> the command fails with the error...
> 
> gcj testme.java
> Undefined symbols:
>   "_main", referenced from:
>   start in crt1.10.5.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> 
> Any idea how to work around this?

It might be worth building the 4.3 branch, not 4.3.0.

Andrew.

Re: C++0x rvalue references get clobbered somehow

[Doug Gregor]

Hello,

On Wed, Mar 19, 2008 at 4:23 AM, Lukas Mai <[EMAIL PROTECTED]> wrote:
>  I'm having problems with g++-4.3.0 and C++0x. Disclaimer: I don't
>  understand rvalue references, but since I need (indirect) argument
>  forwarding, I copied and modified an example from the web.
>  (I believe detail_region::fw is equivalent to std::forward.)
>
>  Here's (a simplified version of) my code. Details like destructors,
>  dynamic memory management, etc are gone; it's just generic object
>  construction.
[snip code]
>
>  This code works fine (and prints 123) when compiled with
>  g++ -std=c++0x -O2 (or -Os or -O). However, without optimization
>  it produces output like -1207981096. This number changes if
>  different function calls are used at the location marked XXX.
>
>  Somehow args.head loses its value between construction (in alloc)
>  and use (in capply), but only if optimizations are not enabled.
>
>  I think args.head should be bound to the temporary value 123,
>  which should stay alive until the next statement. But something
>  seems to overwrite it before p is initialized.

I think you've tripped across a bug in the C++0x standard. GCC is
implementing exactly what the C++0x standard currently says, but
that's not what we want rvalue references to do :)

The issue, I believe, is that when forwarding built-in types like
integers, the compiler will end up making extra temporaries... and
tuple::head will end up being bound to a temporary that doesn't
live long enough for your code to work (at -O0). This issue is being
tracked as GCC bug 34022, here:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34022

But the important part is that it is core issue 664 for C++0x, tracked here:

  http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#664

Current status: the Core Working Group of the C++ committee agrees
that there is a problem, and what the general solution is, but we
don't yet have the wording to update the C++ standard (and, then, GCC)
to fix the problem. Note that, if I tweak your example to use the
following test case, it works (because we don't make more temporaries
of class type; just of built-in types):

struct X {
  X(int value ) : value(value) {}

  int value;
};

int main() {
   using awesome::region;

   region r;
   X *p = r.alloc(X(123));
   cout << p->value << '\n';
}

  - Doug

Re: gcc-4.1-20080303 is now available

[NightStrike]

On 3/19/08, Kaveh R. Ghazi <[EMAIL PROTECTED]> wrote:
> I haven't heard anything that changes my opinion, I still think we should
> relicense the 4.1 branch and do one last release before closing it.
>
> Am I alone here, or does anyone else agree with me? :-/

FWIW, I vote on releasing another version of it in any way possible.
Heck, I say don't even close it as long as there are 1) regressions
open, and 2) people fixing those regressions.

Re: gcj broken on darwin

[Matthias Klose]

Andrew Haley schrieb:
> Jack Howarth wrote:
>>It appears that gcj in gcc 4.3.0 is broken on Darwin. If
>> one builds gcc 4.3.0 executing...
>>
>> contrib/download_ecj
>>
>> before running configure, the build succeeds in creating an
>> ecj1 but when gcj is used to compile an example like testme.java...
>>
>> public class testme {
>>   public static void main(String args[]){
>> System.out.println("Hello");
>>   }
>> }
>>
>> the command fails with the error...
>>
>> gcj testme.java
>> Undefined symbols:
>>   "_main", referenced from:
>>   start in crt1.10.5.o
>> ld: symbol(s) not found
>> collect2: ld returned 1 exit status
>>
>> Any idea how to work around this?
> 
> It might be worth building the 4.3 branch, not 4.3.0.
> 
> Andrew.

isn't this just a missing --main=testme option?

  Matthias

Re: Basic block infrastructure after dbr pass

[Boris Boesler]

Am 18.03.2008 um 18:47 schrieb Richard Guenther:

On Tue, Mar 18, 2008 at 6:40 PM, Boris Boesler <[EMAIL PROTECTED]> wrote:

Am 18.03.2008 um 16:21 schrieb Jim Wilson:


Boris Boesler wrote:

 The following code generators use FOR_EACH_BB[_REVERSE] in the
target machine dependent reorg pass:
- bfin
- frv
- ia64
- mt
- s390


The very first thing that ia64_reorg does is
  compute_bb_for_insn ();


  For a few seconds I thought you saved my day.

  I'm not talking about BLOCK_FOR_INSN (insn)

  I haven't specified my problem properly? If I traverse basic blocks
 via FOR_EACH_BB (used in compute_bb_for_insn, too) I get insns which
 are not in the insn-stream for(insn = get_insns(), insn; insn =
 NEXT_INSN(insn)) ..


...


You are probably mix-matching functions for use in cfg_layout mode
vs. non-cfg_layout mode.


 Probably not, because all functions I use are used by other  
backends in the reorg phase, too.

So, it's a bug?

Boris

Re: gcj broken on darwin

[Jack Howarth]

Matthias,
   My mistake. I see the same issue with gcc-4.2.2 on darwin
which is indeed resolved with --main=testme. I am puzzled why
this isn't automatically handled (as it seems to be with
javac)?
  Jack

On Wed, Mar 19, 2008 at 02:56:40PM +0100, Matthias Klose wrote:
> Andrew Haley schrieb:
> > Jack Howarth wrote:
> >>It appears that gcj in gcc 4.3.0 is broken on Darwin. If
> >> one builds gcc 4.3.0 executing...
> >>
> >> contrib/download_ecj
> >>
> >> before running configure, the build succeeds in creating an
> >> ecj1 but when gcj is used to compile an example like testme.java...
> >>
> >> public class testme {
> >>   public static void main(String args[]){
> >> System.out.println("Hello");
> >>   }
> >> }
> >>
> >> the command fails with the error...
> >>
> >> gcj testme.java
> >> Undefined symbols:
> >>   "_main", referenced from:
> >>   start in crt1.10.5.o
> >> ld: symbol(s) not found
> >> collect2: ld returned 1 exit status
> >>
> >> Any idea how to work around this?
> > 
> > It might be worth building the 4.3 branch, not 4.3.0.
> > 
> > Andrew.
> 
> isn't this just a missing --main=testme option?
> 
>   Matthias

GNU linker ld

[Duncan Purll]

Hi

I am in the process of verifying that the GNU linker (gcc 3.3.2 VxWorks AE653) 
does not introduce untraceable object code when creating an executable image.

This involves verifying the affects of code relocation, copying of code from 
ROM to RAM etc. the documentation for which I can locate. However, does ld 
include a decompression feature, ie. compressed ROM section decompressed into 
RAM? If so where can I find documentation for this and any other relevant (to 
embedded applications) feature?

Target is PowerPC (MPC603/604) embedded .

Thanks

Duncan




  ___ 
Rise to the challenge for Sport Relief with Yahoo! For Good  

http://uk.promotions.yahoo.com/forgood/

Re: gcj broken on darwin

[David Daney]

Jack Howarth wrote:

Matthias,
   My mistake. I see the same issue with gcc-4.2.2 on darwin
which is indeed resolved with --main=testme. I am puzzled why
this isn't automatically handled (as it seems to be with
javac)?
  
We give you the flexibility to write your own main.  As a side benefit, 
you also get the ability to shoot yourself in the foot.


This is of course documented in: 
http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcj/Linking.html



David Daney

Re: gcj broken on darwin

[Andrew Haley]

Jack Howarth wrote:
> Matthias,
>My mistake. I see the same issue with gcc-4.2.2 on darwin
> which is indeed resolved with --main=testme. I am puzzled why
> this isn't automatically handled (as it seems to be with
> javac)?

It's isn't automatically handled, you have to provide it at runtime:

  java testme

Andrew.

Re: GNU linker ld

[Nick Clifton]

Hi Duncan,


I am in the process of verifying that the GNU linker (gcc 3.3.2 VxWorks AE653)


The GNU linker is not part of the GCC project.  It is part of the 
Binutils project, so this question really should be asked on the 
binutils mailing list:  [EMAIL PROTECTED]


However, does ld include a decompression feature, 


No it does not.

Cheers
  Nick

GCC 4.3 license in manual still under GPLv2

[qunying]

Hi,

I have the impression that GCC 4.3.0 has updated to GPLv3. But
http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Copying.html still using 
GPLv2.  Does it need to be updated?

push_secondary_reload: give me a break...

[Joern Rennecke]

Bellow the comment "\
  /* See if we can reuse an existing secondary reload.  */",
there is a loop with an if inside - the idea is that when the
if triggers, we have found a secondary reload to reuse.

However, it won't stop then.  It will just continue to loop, so it
might reuse multiple previous reloads, and when it eventually exits the
loop the condition (s_reload == n_reloads) will be satisfied, so it will
allocate a new secondary reload.

Re: Different *CFLAGS in gcc/Makefile.in

[Ralf Wildenhues]

* Basile STARYNKEVITCH wrote on Tue, Mar 18, 2008 at 09:06:33PM CET:
> in gcc/Makefile.in there are many different *CFLAGS, notablye
>
> ALL_CFLAGS = $(X_CFLAGS) $(T_CFLAGS) \
>   $(CFLAGS) $(INTERNAL_CFLAGS) $(COVERAGE_FLAGS) $(WARN_CFLAGS)  
> $(XCFLAGS) @DEFS@
>
> Do anyone have a precise idea of what all these *CFLAGS are exactly for?

AFAICS each warning flag is described where it is defined.  So just
search for ^INTERNAL_CFLAGS, for example.

Cheers,
Ralf

Re: Different *CFLAGS in gcc/Makefile.in

[Basile STARYNKEVITCH]

Ralf Wildenhues wrote:

* Basile STARYNKEVITCH wrote on Tue, Mar 18, 2008 at 09:06:33PM CET:

in gcc/Makefile.in there are many different *CFLAGS, notablye

ALL_CFLAGS = $(X_CFLAGS) $(T_CFLAGS) \
  $(CFLAGS) $(INTERNAL_CFLAGS) $(COVERAGE_FLAGS) $(WARN_CFLAGS)  
$(XCFLAGS) @DEFS@


Do anyone have a precise idea of what all these *CFLAGS are exactly for?


AFAICS each warning flag is described where it is defined.  So just
search for ^INTERNAL_CFLAGS, for example.


It is indeed the easiest. But for X_CFLAGS & T_CFLAGS I only found the 
comment

# These exists to be overridden by the x-* and t-* files, respectively.
and for XCFLAGS

# XCFLAGS is used for most compilations but not when using the GCC just 
built.


Actually, I am asking because for my MELT branch, I need to run 
(sometimes) a C compiler from within a (resource hungry) C pass. So I 
guessed


## the C flags (without any gcc -I...stuff) to be included in
## compilation of MELT generated C code thru the melt-cc-script
## do not put  $(INTERNAL_CFLAGS) $(COVERAGE_FLAGS) $(WARN_CFLAGS) ##there!
MELT_CFLAGS= $(X_CFLAGS) $(T_CFLAGS) $(CFLAGS) $(XCFLAGS)

But I'm not sure of the T_CFLAGS (it probably is related to target 
specific stuff only).


A big thanks to Ralf for his reply.

Regards.

--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: GCC 4.3 license in manual still under GPLv2

[Joseph S. Myers]

On Wed, 19 Mar 2008, qunying wrote:

> Hi,
> 
> I have the impression that GCC 4.3.0 has updated to GPLv3. But
> http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Copying.html still using GPLv2.
> Does it need to be updated?

I pointed out  
that the manual should be updated and that GCC's gpl.texi is not a direct 
copy of the file from the FSF but has local Texinfo changes.  But all 
that's happened since then is the addition of an unused file gpl_v3.texi 
with none of our local changes merged in.  Since many free software 
developers don't like Invariant Sections in the GFDL, they are perhaps 
unlikely to take the time required to update one in the GCC manual.  
Patches merging the necessary changes into gpl_v3.texi and arranging for 
it to be used will of course be considered.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: [trunk] Addition to subreg section of rtl.text.

[Joern Rennecke]

On Tue, Mar 18, 2008 at 09:40:49PM +, Richard Sandiford wrote:
> > The most natural layout would be 0x45??0123 .
> > But you could also have 0x345?012? , or even more exotic mappings.
> 
> Do we actually support the second mapping though?  Surely the
> target-independent code needs to know how bytes are divided into words?

I don't see why the target-independent code would need to know what the bits
inside a partial integer mode mean.
A partial exception to this is when aritmetic for partial integers has to
be implemented using arithmetic for integral integers; in this case, it is
assumed that moving partial integers to integral integers, performing the
arithmetic, and moving back to partial integers will produce the right result.
So, if partial integer addition or subtraction is present, and no named
pattern for these operations exits, this implies that valid bits are
contiguous, and that any unused lower bits will read as zero (assuming we
are actually dealing with bits here.  Stranger scenarious are possible,
e.g. mod 81 arithmtic.)

> The reason Kenny's looking at this is that he wants to track which
> bytes in a SUBREG are actually live.

A conservative assumption is that all bits occupied by the integral mode the
partial integral mode is associated with are live.  If we really find that
there is a code quality issue when making this assumption, we can add a hook
to define the salient semantics, but I doubt this will come up.

> >> 3) What about things like 80-bit FP modes on a 32-bit or 64-bit target? Is 
> >> it valid to refer to pieces of an 80-bit FP pseudo? If so, are the rules 
> >> we've got here right?
> >
> > Where the 80-bit mode is stored in multiple words like for x86, you
> > should be able to refer to word_mode subregs the way the value is
> > stored in memory.  This is the only way you can get a sane equivalence
> > between reloads via secondary memory and direct register-register
> > moves invollving word_mode GENERAL_REGS.
> 
> OK, so in all these cases, "N words and a bit" modes can be treated
> like "N + 1 words, with the upper bits undefined"?  For both inner
> and outer modes?

N + 1 words, yes, but it doesn't follow that it must be the upper bits
that are undefined.  If that is actually the case, however, for an 80 bit
value on a little-endian byte-addressed the target, the port could refer
to the bits in the highest words as (subreg:HI (reg:XF inner_reg) 8) or
(subreg:HI (mem:XF mem_addr) 8) to make this explicit.
However, what would we do with a true-blue big endian target?
Would the highest bits be (subreg:HI (reg:XF inner_reg 2)) ?

> >> 4) Do stores to subregs of hardreg invalidate just the registers
> >> mentioned in the outer mode or do they invalidate the entire set of
> >> registers mentioned in the inner mode? (our rules say only the outer
> >> mode).
> >
> > Where the hardreg is actually a single hardware register, all of it is
> > clobbered.  If it is a concatenation of multiple actual hard
> > registers, the idea is that only the one that corresponds to the word
> > that is stored into gets clobbered.  If more than one word is stored
> > into, that would logically translate to changing each of the registers
> > that each word corresponds to.
> >
> > What seems less defined is what happens when the underlying hard registers
> > are smaller than a word, and either the mode size or SUBREG_BYTE
> > is not a multiple of a word.
> 
> Yeah, my version of the question was more: do we support subregs of
> hard registers in which the normal word-based semantics of pseudos
> do not apply?

Having some data registers larger than word size is quite common,
particularily floating point registers on machines with a word size
smaller than the largest supported floating point mode.

IIRC we support this, but not very well.

Where the hardware allows transfers bewteen differently sized registers,
it seems most natural to use SUBREGs to express this.

IIRC you have to do something like (SUBREG:SI (SUBREG:DI (REG:DF...
and even spread it across multiple instruction patterns.
I don't see why we should be picky about the MODE_CLASS of inner or
outer modes of SUBREGs.

If individual portions of multiple-word registers can be accessed individually
like normal registers, it makes sense to mode the individual parts as
separate registers, but it is essential that all parts can be both
read from and writen to separately with moves from/to general purpose
registers to make this work sanely.  Also, group spill allocation
has extra costs in several ways, so if the predominant way to use the
wide registers is to use them as a whole, it is still desirable to
model them as wide registers and have the narrower accesses use
SUBREG and/or zero_extract.

But there is also part of an answer here for the original question:
when a wide register is only partially available as separate words,
it is more likely to be available as separate values to read.
If you can't write separate parts separately, it fol

gcc-4.2-20080319 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch 
revision 133353

You'll find:

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

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

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

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

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

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

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

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

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

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

Re: [trunk] Addition to subreg section of rtl.text.

[Richard Sandiford]

Joern Rennecke <[EMAIL PROTECTED]> writes:
> On Tue, Mar 18, 2008 at 09:40:49PM +, Richard Sandiford wrote:
>> > The most natural layout would be 0x45??0123 .
>> > But you could also have 0x345?012? , or even more exotic mappings.
>> 
>> Do we actually support the second mapping though?  Surely the
>> target-independent code needs to know how bytes are divided into words?
>
> I don't see why the target-independent code would need to know what the bits
> inside a partial integer mode mean.

Consider:

   (set (subreg:HI (reg:PDI ...) ...) ...)
   (set (zero_extract (subreg:SI (reg:PDI ...) ...) 16 ...) ...)

on a 32-bit machine with "..." filled in such that, with s/PDI/DI/, the
second store would kill the first.  We want to know if the same is true
of the original PDI version.

> A partial exception to this is when aritmetic for partial integers has to
> be implemented using arithmetic for integral integers; in this case, it is
> assumed that moving partial integers to integral integers, performing the
> arithmetic, and moving back to partial integers will produce the right result.
> So, if partial integer addition or subtraction is present, and no named
> pattern for these operations exits, this implies that valid bits are
> contiguous, and that any unused lower bits will read as zero (assuming we
> are actually dealing with bits here.  Stranger scenarious are possible,
> e.g. mod 81 arithmtic.)

>> The reason Kenny's looking at this is that he wants to track which
>> bytes in a SUBREG are actually live.
>
> A conservative assumption is that all bits occupied by the integral mode the
> partial integral mode is associated with are live.  If we really find that
> there is a code quality issue when making this assumption, we can add a hook
> to define the salient semantics, but I doubt this will come up.

But what we're trying to do here is define what bytes are _modified_
by a definition as well as what bytes are live in a use.  I assume
you're saying that a definition of any subreg that involves partial
integer modes should behave like a full definition _and_ a full use
of the partial mode?  If so, I'd argue that a special case like that is
too complicated to be justified if no mainline port uses it.  It seems
reasonable to require the port to behave "as if" the natural byte order
applies.

If a new port needs something different, it should be the port
submitter's responsibility to add suitable infrastructure
(where "suitable" means that the target-independent code can
follow that's going on).

>> >> 3) What about things like 80-bit FP modes on a 32-bit or 64-bit target? 
>> >> Is it valid to refer to pieces of an 80-bit FP pseudo? If so, are the 
>> >> rules we've got here right?
>> >
>> > Where the 80-bit mode is stored in multiple words like for x86, you
>> > should be able to refer to word_mode subregs the way the value is
>> > stored in memory.  This is the only way you can get a sane equivalence
>> > between reloads via secondary memory and direct register-register
>> > moves invollving word_mode GENERAL_REGS.
>> 
>> OK, so in all these cases, "N words and a bit" modes can be treated
>> like "N + 1 words, with the upper bits undefined"?  For both inner
>> and outer modes?
>
> N + 1 words, yes, but it doesn't follow that it must be the upper bits
> that are undefined.

Breaking the paragraph here because, as above, I'd argue that it's
reasonable to assume that the upper bits are the undefined ones unless
a mainline port needs something else.

> If that is actually the case, however, for an 80 bit
> value on a little-endian byte-addressed the target, the port could refer
> to the bits in the highest words as (subreg:HI (reg:XF inner_reg) 8) or
> (subreg:HI (mem:XF mem_addr) 8) to make this explicit.

Agreed.  The rules in the rtl.texi proposal allow this.

> However, what would we do with a true-blue big endian target?  Would
> the highest bits be (subreg:HI (reg:XF inner_reg 2)) ?

That's my understanding, yes (and it's what the proposed rules allow).

>> >> 4) Do stores to subregs of hardreg invalidate just the registers
>> >> mentioned in the outer mode or do they invalidate the entire set of
>> >> registers mentioned in the inner mode? (our rules say only the outer
>> >> mode).
>> >
>> > Where the hardreg is actually a single hardware register, all of it is
>> > clobbered.  If it is a concatenation of multiple actual hard
>> > registers, the idea is that only the one that corresponds to the word
>> > that is stored into gets clobbered.  If more than one word is stored
>> > into, that would logically translate to changing each of the registers
>> > that each word corresponds to.
>> >
>> > What seems less defined is what happens when the underlying hard registers
>> > are smaller than a word, and either the mode size or SUBREG_BYTE
>> > is not a multiple of a word.
>> 
>> Yeah, my version of the question was more: do we support subregs of
>> hard registers in which the normal word-based semantics

Re: [trunk] Addition to subreg section of rtl.text.

[Richard Sandiford]

Richard Sandiford <[EMAIL PROTECTED]> writes:
> I think one reason is that allowing zero_extracts of multi-word modes is
> (like this subreg thing) a little hard to pin down.  What happens when
> WORDS_BIG_ENDIAN && !BYTES_BIG_ENDIAN on a 32-bit target, and you have:
>
> (zero_extract (reg:DI ) (const_int 16) (const_int 24))
>
> (which should be BITS_BIG_ENDIAN-neutral).  0x76543210 would be laid out
> in memory as "0x45670123", so is this extract equivalent to "0x70" or
> "0x43"?  You could probably make a case for both, and I doubt the
> target-independent code handles this consistently at the moment.

Sorry, those 0x numbers were base 256. ;)

Richard

Come join me on ssbbw4u...

[P Alb]

Come join me on ssbbw4u.

Click here to join:
http://ssbbw4u.ning.com/?xgi=g2fNo2Y

Thanks,
P Alb

Re: [trunk] Addition to subreg section of rtl.text.

[Joern Rennecke]

On Wed, Mar 19, 2008 at 10:56:29PM +, Richard Sandiford wrote:
> > I don't see why the target-independent code would need to know what the bits
> > inside a partial integer mode mean.
> 
> Consider:
> 
>(set (subreg:HI (reg:PDI ...) ...) ...)
>(set (zero_extract (subreg:SI (reg:PDI ...) ...) 16 ...) ...)
> 
> on a 32-bit machine with "..." filled in such that, with s/PDI/DI/, the
> second store would kill the first.  We want to know if the same is true
> of the original PDI version.

Yes.  This should still address the same bits in both cases, even if you
don't know which of them are valid and what numerical significance
they have.

> But what we're trying to do here is define what bytes are _modified_
> by a definition as well as what bytes are live in a use.  I assume
> you're saying that a definition of any subreg that involves partial
> integer modes should behave like a full definition _and_ a full use
> of the partial mode?

The use and full definition comes only into play if you also would have them
for the associated integral mode.
I.e. for QImode == word_mode, if you write to an QImode lowpart of
a PHImode value, the upper part remains untouched, and the lowpart
gets replaced.  In general, you can't assume that you could read back
the value that you have just written, though.  Although in the 20 bit
address case, you could; the funkyness is all in the highpart.

If you don't want to track low and highpart separately, you can
pretend that all of the register is used and then re-defined, just like for
a Qimode subreg of HImode.

The same access, but with wordmode == HImode, will set the entire
PHImode register.

> If so, I'd argue that a special case like that is
> too complicated to be justified if no mainline port uses it.  It seems
> reasonable to require the port to behave "as if" the natural byte order
> applies.

Since you don't know how many invalid bits there are, requiring them to
be all on the side where the natural byte order would put the most significant
bits wouldn't help you.

But the SUBREGS and ZERO_EXTRACTs should still mean the same with respect to
selecting groups of bits.  You simply don't know which of them mean anything
and what their positional value is, if any, but you shouldn't need to.
So in that respect, it still behaves "as if" the natural byte order applies.

Note that it might be that the nature of a partial integer mode is such that
some narrowing subregs of it are simply invalid for a given mode, or storing
particular values into them is invalid, because they could form bit patterns
that have no equivalent in the actual hard register.

If the register is not valid in an integral mode, the register allocator
should never use it for ordinary values, so all that ends up in such a
register should result from target-specific expanders which have to know
what they are doing.

> >> OK, so in all these cases, "N words and a bit" modes can be treated
> >> like "N + 1 words, with the upper bits undefined"?  For both inner
> >> and outer modes?
> >
> > N + 1 words, yes, but it doesn't follow that it must be the upper bits
> > that are undefined.
> 
> Breaking the paragraph here because, as above, I'd argue that it's
> reasonable to assume that the upper bits are the undefined ones unless
> a mainline port needs something else.

The SH port does, in its handling of FPSCR.
But you shouldn't see any subregs in connection with this.
And even if it did, it would not really make lifeness tracking of PSImode any
different than for SImode.

> Yes, MIPS is one such port, but we expressly forbid conversions
> between full-width and partial-width modes for the very reason
> given in mainline rtl.texi:
> 
> It is also not valid to access a single word of a multi-word value in a
> hard register when less registers can hold the value than would be
> expected from its size.  For example, some 32-bit machines have
> floating-point registers that can hold an entire @code{DFmode} value.
> If register 10 were such a register @code{(subreg:SI (reg:DF 10) 4)}
> would be invalid because there is no way to convert that reference to
> a single machine register.  The reload pass prevents @code{subreg}
> expressions such as these from being formed.

The reasoning there is flawed.  You could still identify a specific hard
register when you are presented with a DFmode subreg of a DCmode or V2DFmode
inner register.
And @code{(subreg:SI (reg:DF 10) 0)} would be a natural way to express that
you are using the floating point register as a 32 bit integer register,
with writes clobbering the entire 64 bit of the register.

> > IIRC you have to do something like (SUBREG:SI (SUBREG:DI (REG:DF...
> > and even spread it across multiple instruction patterns.
> > I don't see why we should be picky about the MODE_CLASS of inner or
> > outer modes of SUBREGs.
> 
> My understanding was that nested subregs aren't allowed (any more).

That's why I taked about spreading it across

Re: C++ FE question: When is CLASSTYPE_VBASECLASSES valid?

[Mark Mitchell]

Doug Kwan (關振德) wrote:


I have a question about the validity of CLASSTYPE_VBASECLASSES.
Due to templates, it is not possible to know if a class has virtual
bases or not until the class is fully instantiated.  Is checking
processing_template_decl sufficient to guarantee that
CLASSTYPE_VBASECLASSES is valid?


No; if the class is presently being defined, that will not be set. 
However, it should be safe to check that for a complete class when 
!processing_template_decl.


--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Different *CFLAGS in gcc/Makefile.in

[Jim Wilson]

Basile STARYNKEVITCH wrote:
It is indeed the easiest. But for X_CFLAGS & T_CFLAGS I only found the 
comment

# These exists to be overridden by the x-* and t-* files, respectively.


t-* files are target makefile fragments.  x-* files are (cross)-host 
makefile fragments.  See config.gcc and config.host respectively.  You 
can find example uses by greping in config/*/*.



and for XCFLAGS
# XCFLAGS is used for most compilations but not when using the GCC just 
built.


XCFLAGS is apparently obsolete and unused.  Looks like the last use was 
removed in 2004 from rs6000/x-darwin.  I see that libgomp is using 
XCFLAGS, but I think it is a different makefile variable than the gcc one.


By the way, X_CFLAGS and XCFLAGS are documented in doc/fragments.texi. 
T_CFLAGS docs are missing there though.  You can find all sorts of stuff 
if you grep the entire gcc source tree.


Jim

Re: Basic block infrastructure after dbr pass

[Jim Wilson]

Boris Boesler wrote:
 I haven't specified my problem properly? If I traverse basic blocks via 
FOR_EACH_BB (used in compute_bb_for_insn, too) I get insns which are not 
in the insn-stream for(insn = get_insns(), insn; insn = NEXT_INSN(insn)) ..


As Ian mentioned, the delay-slot filling pass does not update the CFG. 
So you can't use it after this pass, at least for any target that has 
delay slots.


As I mentioned, the machine dependent reorg passes are the very first 
passes that are run after the last pass that updates the CFG.  Hence, 
the CFG is still valid when machine dependent reorg runs, and it can 
still be used there if you are careful.


You really need to look at the order of passes defined in passes.c, 
particularly the pass_free_cfg I pointed you at earlier.  The CFG is 
always valid before this point.  The CFG is not valid after this point, 
if you run any optimization pass that moves instructions around, which 
includes most all of them that run after this point.  None of these 
passes try to maintain the CFG info.  md_reorg is a special case because 
it is the first one run after we stop maintaining the CFG, so the 
residual info is still usable if you are careful.


Jim