Re: [PATCH] SMS - Pass the actual schedulable rows to compute_split_row

[Ayal Zaks]

Revital1 Eres/Haifa/IBM wrote on 13/03/2009 07:50:08:

> Hello,
>
> > > Using testsuite/gcc.dg/sms-6.c as an example and compiling it for
> > PowerPC,
> > > node 18 (see attachment) is in a SCC and cannot be scheduled until
> > spliting
> > > twice. The MII = 20 and the schedule can only  be found at II = 24.
> >
> > Yes, I see. This example raises a couple of issues:
> >
> > o The first row split (from II=20 to II=21) is miscalculated; it should
be
> > row 20=0 instead of 19. Splitting row 19 cannot help schedule node 18,
and
> > indeed we immediately split another row. We're now checking a small
patch
> > to fix this, which should save one cycle of II in the above example.
>
> Here is the patch, on behalf of Ayal.
> Passed bootstrap + regtest with SMS flags on ppc64 and bootstrap +
> regtest x86.
>
> I'll commit it later today to trunk if that's OK.
>

OK for trunk, when it's reopened for general patches (it's currently in
stage 4, allowing only regression fixes; this is a missed-optimization fix,
as splitting a row outside the window should not cause any problems except
for inefficiency). Please add a short comment for this short fix,
documenting the fact that the scheduling window is exclusive of 'end'
whereas compute_split_window() expects an inclusive, ordered range.

Bingfeng, you're welcome to try it out.

Thanks, Ayal.


> Thanks,
> Revital
>
> * modulo-sched.c (sms_schedule_by_order): Pass the actual
> schedulable rows to compute_split_row.
>
> [attachment "patch_sms_12_3.txt" deleted by Ayal Zaks/Haifa/IBM]

Re: [lto] RFC: How should gimple represent enums?

[Richard Guenther]

On Thu, Mar 12, 2009 at 5:50 PM, Diego Novillo  wrote:
> On Thu, Mar 12, 2009 at 12:46, Steven Bosscher  wrote:
>> On Thu, Mar 12, 2009 at 5:36 PM, Diego Novillo  wrote:
>>> The temptation is to use C++'s limits, but I'm concerned that may
>>> produce confusion somewhere down the line with the optimizers or other
>>> diagnostics.  Or should we use C's notion and treat them as ints?
>>
>> The limits are a language-specific thing that the front end should check for.
>
> Right, but we do take advantage of them in the middle end in various
> places (VRP, switch warnings, etc).  Using one or the other will
> probably affect what we do there.  I have no data on whether this is
> true, though, it's only intuition from the fact that we do make
> decisions based in TYPE_{MAX,MIN}_VALUE.
>
>
>> But from the point of view of the middle-end, an enum value is just a
>> number.  So IMHO: Use ints.
>
> That's true.

I agree with Steven.  It is not clearly defined what to do with for example
out-of-range constants, so any means to avoid that situation is good.

Richard.

Re: missing return statement

[Andreas Schwab]

James Dennett  writes:

> This appears to be a difference between C and C++.  Unfortunate.
> 6.6.3 [stmt.return]/2 of N2800 says "Flowing off the end of a function
> is equivalent to a return with no value; this results in undefined
> behavior in a value-returning function."

Since it's merely undefined behavior the compiler cannot reject it,
because if the function is never called the undefined behavior does not
happen.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

ld fails to look under /usr/$arch-linux-gnu/lib64

[Hector Oron]

Hello I posted to binutils list as I guess it is an ld problem, but
maybe some gcc people might be interested as well.

-- Forwarded message --
From: Hector Oron 
Date: 2009/3/13
Subject: Re: ld fails to look under /usr/$arch-linux-gnu/lib64
To: binut...@sources.redhat.com


Hello,

 I have also been trying --with-sysroot option in binutils (2.18 and
2.19) and gcc (4.3), could you give me a hint on how to teach linker
to look for
/usr/s390-linux-gnu/lib64/libc.so, which it really is there. This
process used to work for 3.3, 3.4, 4.0, 4.1 and 4.2 without sysroot
option. But it fails on 4.3, how could i debug it?

Binutils 2.18 configure:
~
../configure --host=x86_64-linux-gnu \
              --build=x86_64-linux-gnu --target=s390-linux-gnu --prefix=/usr \
              --enable-targets=s390x-linux-gnu
--with-sysroot=/usr/s390-linux-gnu/


GCC-4.3 configure:
~~
../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl='file:///usr/share/doc/gcc-4.3/README.Bugs'
--enable-languages=c,c++,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib  --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/s390-linux-gnu/include/c++/4.3.2
--program-suffix=-4.3 --with-sysroot=/usr/s390-linux-gnu/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--with-long-double-128 --enable-checking=release
--program-prefix=s390-linux-gnu-
--includedir=/usr/s390-linux-gnu/include --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=s390-linux-gnu


Output error:
~
/home/zumbi/buildcross/trunk/s390/gcc-4.3-4.3.2/build/./gcc/xgcc
-B/home/zumbi/buildcross/trunk/s390/gcc-4.3-4.3.2/build/./gcc/
-B/usr/s390-linux-gnu/bin/ -B/usr/s390-linux-gnu/lib/ -isystem
/usr/s390-linux-gnu/include -isystem /usr/s390-linux-gnu/sys-include
-O2  -O2 -g -g -O2   -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -mlong-double-128 -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -shared
-nodefaultlibs -Wl,--soname=libgcc_s.so.1
-Wl,--version-script=libgcc.map -o 64/libgcc_s.so.1.tmp -O2 -g -g -O2
-m64 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o
_ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o
_enable_execute_stack_s.o _trampoline_s.o __main_s.o _absvsi2_s.o
_absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o
_mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o
_ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o
_ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o
_paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o
_powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o
_divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o
_bswapdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o
_fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o
_fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o
_floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o
_floatundidf_s.o _floatundixf_s.o _floatunditf_s.o _divdi3_s.o
_moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o
unwind-dw2_s.o unwind-dw2-fde-glibc_s.o unwind-sjlj_s.o gthr-gnat_s.o
unwind-c_s.o emutls_s.o -lc && rm -f 64/libgcc_s.so && if [ -f
64/libgcc_s.so.1 ]; then mv -f 64/libgcc_s.so.1
64/libgcc_s.so.1.backup; else true; fi && mv 64/libgcc_s.so.1.tmp
64/libgcc_s.so.1 && ln -s libgcc_s.so.1 64/libgcc_s.so
/usr/s390-linux-gnu/bin/ld: skipping incompatible
/usr/s390-linux-gnu/lib/libc.so when searching for -lc
/usr/s390-linux-gnu/bin/ld: skipping incompatible
/usr/s390-linux-gnu/lib/libc.a when searching for -lc
/usr/s390-linux-gnu/bin/ld: skipping incompatible
/usr/s390-linux-gnu/bin/../../lib/libc.so when searching for -lc
/usr/s390-linux-gnu/bin/ld: skipping incompatible
/usr/s390-linux-gnu/bin/../../lib/libc.a when searching for -lc
/usr/s390-linux-gnu/bin/ld: s390:31-bit architecture of input file
`/usr/s390-linux-gnu/lib/crti.o' is incompatible with s390:64-bit
output
/usr/s390-linux-gnu/bin/ld: s390:31-bit architecture of input file
`/usr/s390-linux-gnu/lib/crtn.o' is incompatible with s390:64-bit
output
collect2: ld returned 1 exit status

Regards

--
 Héctor Orón



-- 
 Héctor Orón

help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Paolo Bonzini]

These are all the !SHIFT_COUNT_TRUNCATED targets.

For 4.5 I would like to improve our RTL canonicalization so that no
out-of-range shifts are ever in the RTL representation.

This in turn means that the description given by SHIFT_COUNT_TRUNCATED
must be exact.  Right now !SHIFT_COUNT_TRUNCATED means "I don't know",
I want it to mean "it is never truncated".

I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000
(which define SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which
do not define it at all) it is right that shift counts are never
truncated.

In addition, for arm and m68k I'd like to know whether bitfield
instructions truncate the bit position the same as shifts (8 bits for
arm, 6 bits for m68k).

This information is particularly important for targets that do not
have a simulator in src.

Thanks in advance!

Paolo

[Cross toolchains] Multiarch and cross toolchains compatibility

[Hector Oron]

Hello,

  I have been discussing lately with other people about implementing a
proof of concept for multiarch[1] (my objectives are to improve cross
building), as I understand you already have a nice approach to cross
building with-sysroot option, but I would like to know how much it
this compatible with multiarch proposal[1].

  Current multiarch layout[2] it does not look to me like it would be
accepted into gcc's mainstream. For me multiarch implementation is not
as clean as what sysroot has achived. I could be wrong, so what do you
think?
Could multiarch proposal fit into mainstream? Would it be a
better/nicer way to get cross compile to work?

Kind regards,
  Hector Oron a.k.a. 'zumbi'

[1] http://lackof.org/taggart/hacking/multiarch/
[2] http://wiki.debian.org/toolchain-multiarch

-- 
 Héctor Orón

Re: missing return statement

[Dave Korn]

Andreas Schwab wrote:
> James Dennett  writes:
> 
>> This appears to be a difference between C and C++.  Unfortunate.
>> 6.6.3 [stmt.return]/2 of N2800 says "Flowing off the end of a function
>> is equivalent to a return with no value; this results in undefined
>> behavior in a value-returning function."
> 
> Since it's merely undefined behavior the compiler cannot reject it,
> because if the function is never called the undefined behavior does not
> happen.

  Yes, James did mention "[if it] is called at all" in his earlier post.

cheers,
  DaveK

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Kaz Kojima]

Paolo Bonzini  wrote:
> I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000
> (which define SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which
> do not define it at all) it is right that shift counts are never
> truncated.

sh defines SHIFT_COUNT_TRUNCATED according to target and
there are comments for it:

/* Immediate shift counts are truncated by the output routines (or was it
   the assembler?).  Shift counts in a register are truncated by SH.  Note
   that the native compiler puts too large (> 32) immediate shift counts
   into a register and shifts by the register, letting the SH decide what
   to do instead of doing that itself.  */
/* ??? The library routines in lib1funcs.asm truncate the shift count.
   However, the SH3 has hardware shifts that do not truncate exactly as gcc
   expects - the sign bit is significant - so it appears that we need to
   leave this zero for correct SH3 code.  */
#define SHIFT_COUNT_TRUNCATED (! TARGET_SH3 && ! TARGET_SH2A)


Is this enough information for you?

Regards,
kaz

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Ian Lance Taylor]

Paolo Bonzini  writes:

> This in turn means that the description given by SHIFT_COUNT_TRUNCATED
> must be exact.  Right now !SHIFT_COUNT_TRUNCATED means "I don't know",
> I want it to mean "it is never truncated".

You need to do more work to make that happen, as SHIFT_COUNT_TRUNCATED
applies to both the shift instructions and the bitfield instructions.
On some processors one or the other is truncated; SHIFT_COUNT_TRUNCATED
may currently only be set to 1 if both are truncated.  (E.g., I believe
that m68k truncates shifts but not bitfield instructions.)

Ian

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Bernd Schmidt]

Paolo Bonzini wrote:
> These are all the !SHIFT_COUNT_TRUNCATED targets.
> 
> For 4.5 I would like to improve our RTL canonicalization so that no
> out-of-range shifts are ever in the RTL representation.
> 
> This in turn means that the description given by SHIFT_COUNT_TRUNCATED
> must be exact.  Right now !SHIFT_COUNT_TRUNCATED means "I don't know",
> I want it to mean "it is never truncated".
> 
> I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000
> (which define SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which
> do not define it at all) it is right that shift counts are never
> truncated.

The Blackfin does not truncate shift counts.  The documentation
specifies that e.g. for "Dx >>= Dy" instructions, shift counts greater
than 31 produce a result of zero.  Other shift instructions use a sign
extended part of the shift count to shift either left or right.  "I
don't know" is probably the best answer we can give the compiler.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH  Wilhelm-Wagenfeld-Str. 6  80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Paolo Bonzini]

Ian Lance Taylor wrote:
> Paolo Bonzini  writes:
> 
>> This in turn means that the description given by SHIFT_COUNT_TRUNCATED
>> must be exact.  Right now !SHIFT_COUNT_TRUNCATED means "I don't know",
>> I want it to mean "it is never truncated".
> 
> You need to do more work to make that happen, as SHIFT_COUNT_TRUNCATED
> applies to both the shift instructions and the bitfield instructions.
> On some processors one or the other is truncated; SHIFT_COUNT_TRUNCATED
> may currently only be set to 1 if both are truncated.  (E.g., I believe
> that m68k truncates shifts but not bitfield instructions.)

Yes, I've also split TARGET_SHIFT_TRUNCATION_MASK and
TARGET_EXTRACT_TRUNCATION_MASK, but for the latter a conservative
default can be used since it's used only in one optimization in combine.

[trimmed CC list]

Paolo

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Paolo Bonzini]

> The Blackfin does not truncate shift counts.  The documentation
> specifies that e.g. for "Dx >>= Dy" instructions, shift counts greater
> than 31 produce a result of zero.  Other shift instructions use a sign
> extended part of the shift count to shift either left or right.  "I
> don't know" is probably the best answer we can give the compiler.

In my plan, the truncation of shifts is used to canonicalize RTL created
with out of range shift counts.  This is useful because such out of
range RTL can appear because of unrolling or inlining.  Then the answer
should be based on this: would a "typical" C programmer expect a left
and a right shift from this:

int f(int a)
{
  return 0x4000 << a;
}

int x, y;
int main()
{
  x = f(1);
  y = f(-1);
}

If the C program above can be reasonably considered undefined with
Blackfin, saying "shifts are not truncated" is okay.  This is because
the variable left/right shifts can still be described as rtl like

  (set A (if_then_else (lt B (const_int 0))
   (lshiftrt A (minus (const_int 0) B))
   (lshift A B)))

so that the actual arguments are LSHIFT/LSHIFTRT are positive.

Paolo

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Richard Earnshaw]

On Fri, 2009-03-13 at 12:34 +0100, Paolo Bonzini wrote:
> These are all the !SHIFT_COUNT_TRUNCATED targets.
> 
> For 4.5 I would like to improve our RTL canonicalization so that no
> out-of-range shifts are ever in the RTL representation.
> 
> This in turn means that the description given by SHIFT_COUNT_TRUNCATED
> must be exact.  Right now !SHIFT_COUNT_TRUNCATED means "I don't know",
> I want it to mean "it is never truncated".
> 
> I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000
> (which define SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which
> do not define it at all) it is right that shift counts are never
> truncated.
> 
> In addition, for arm and m68k I'd like to know whether bitfield
> instructions truncate the bit position the same as shifts (8 bits for
> arm, 6 bits for m68k).
> 
> This information is particularly important for targets that do not
> have a simulator in src.

A number of years ago (probably more than 10 now) I tried to rework the
ARM backend code to use a QImode register to represent the shift.  That
then fully described the behaviour of the shift operation.  While this
made a small number of cases generate code the overall result was
overwhelmingly worse.  Maybe I didn't push the tweaks far enough to
recover the lost cases, but I suspect that, at least at that time, GCC
just couldn't do a decent job with having a subreg in the shift operand
position.

Will have to check up on the bitfields question.  I do know that the
rules for Neon instructions are not the same as those for ARM
instructions.

R.

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Paolo Bonzini]

> /* Immediate shift counts are truncated by the output routines (or was it
>the assembler?).  Shift counts in a register are truncated by SH.  Note
>that the native compiler puts too large (> 32) immediate shift counts
>into a register and shifts by the register, letting the SH decide what
>to do instead of doing that itself.  */
> /* ??? The library routines in lib1funcs.asm truncate the shift count.
>However, the SH3 has hardware shifts that do not truncate exactly as gcc
>expects - the sign bit is significant - so it appears that we need to
>leave this zero for correct SH3 code.  */

So you have that in the RTL stream we should canonicalize "a << 32" to
"a", but "a << (b & 31)" is not the same as "a << b"?

Also, how is the sign bit is significant?  Does it determine whether the
value is left- or right-shifted?

Finally, is SH2A the same as SH3?

Thanks!

Paolo

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Richard Guenther]

On Fri, Mar 13, 2009 at 2:14 PM, Bernd Schmidt  wrote:
> Paolo Bonzini wrote:
>> These are all the !SHIFT_COUNT_TRUNCATED targets.
>>
>> For 4.5 I would like to improve our RTL canonicalization so that no
>> out-of-range shifts are ever in the RTL representation.
>>
>> This in turn means that the description given by SHIFT_COUNT_TRUNCATED
>> must be exact.  Right now !SHIFT_COUNT_TRUNCATED means "I don't know",
>> I want it to mean "it is never truncated".
>>
>> I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000
>> (which define SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which
>> do not define it at all) it is right that shift counts are never
>> truncated.
>
> The Blackfin does not truncate shift counts.  The documentation
> specifies that e.g. for "Dx >>= Dy" instructions, shift counts greater
> than 31 produce a result of zero.  Other shift instructions use a sign
> extended part of the shift count to shift either left or right.  "I
> don't know" is probably the best answer we can give the compiler.

Hm.  In fold-const.c we try to make sure to produce the same result
as the target would for constant-folding shifts.  Thus, Paolo, I think
what fold-const.c does is what we should assume for
!SHIFT_COUNT_TRUNCATED.  No?

Richard.

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Paolo Bonzini]

> Hm.  In fold-const.c we try to make sure to produce the same result
> as the target would for constant-folding shifts.  Thus, Paolo, I think
> what fold-const.c does is what we should assume for
> !SHIFT_COUNT_TRUNCATED.  No?

Unfortunately it is not so simple.  fold-const.c is actually wrong, as
witnessed by this program

  static inline int f (int s) { return 2 << s; }
  int main () { printf ("%d\n", f(33)); }

which prints 4 at -O0 and 0 at -O2 on i686-pc-linux-gnu.

This might mean either that it is easier than I thought (i.e. that all
the subtleties of the targets could be ignored), but I want to play it
safe and actually take the opportunity to fix the above problem (my
current patch does fix it).

Paolo

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Richard Guenther]

On Fri, Mar 13, 2009 at 4:07 PM, Paolo Bonzini  wrote:
>
>> Hm.  In fold-const.c we try to make sure to produce the same result
>> as the target would for constant-folding shifts.  Thus, Paolo, I think
>> what fold-const.c does is what we should assume for
>> !SHIFT_COUNT_TRUNCATED.  No?
>
> Unfortunately it is not so simple.  fold-const.c is actually wrong, as
> witnessed by this program
>
>  static inline int f (int s) { return 2 << s; }
>  int main () { printf ("%d\n", f(33)); }
>
> which prints 4 at -O0 and 0 at -O2 on i686-pc-linux-gnu.

But this is because i?86 doesn't define SHIFT_COUNT_TRUNCATED, no?

Richard.

> This might mean either that it is easier than I thought (i.e. that all
> the subtleties of the targets could be ignored), but I want to play it
> safe and actually take the opportunity to fix the above problem (my
> current patch does fix it).
>
> Paolo
>

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Kaz Kojima]

Paolo Bonzini  wrote:
> So you have that in the RTL stream we should canonicalize "a << 32" to
> "a", but "a << (b & 31)" is not the same as "a << b"?

Yes when the msb of b is set.
  
> Also, how is the sign bit is significant?  Does it determine whether the
> value is left- or right-shifted?

Yep.  SH3 uses SHLD (SHift Logical Dynamically) insn which
is modeled like as:

SHLD (Rm, Rn)
{
  int sign = Rm & 0x8000;

  if (sign == 0)
Rn <<= (Rm & 0x1f);
  else if ((Rm & 0x1f) == 0)
Rn = 0;
  else
Rn = (unsigned)Rn >> ((~Rm & 0x1f)+1);
}

> Finally, is SH2A the same as SH3?

Although SH2A has a new arithmetic shift instruction, it's
same as SH3 in this regard, I think.

Regards,
kaz

Re: recent regression on darwin

[Kaveh R. GHAZI]

On Thu, 12 Mar 2009, H.J. Lu wrote:

> > Executing on host: 
> > /sw/src/fink.build/gcc44-4.3.999-20090312/darwin_objdir/gcc/xgcc 
> > -B/sw/src/fink.build/gcc44-4.3.999-20090312/darwin_objdir/gcc/ 
> > /sw/src/fink.build/gcc44-4.3.999-20090312/gcc-4.4
> > -20090312/gcc/testsuite/gcc.dg/asm-b.c   -O1  -lm   -m32 -o ./asm-b.exe    
> > (timeout = 300)
> > /sw/src/fink.build/gcc44-4.3.999-20090312/gcc-4.4-20090312/gcc/testsuite/gcc.dg/asm-b.c:27:bad
> >  register name `%sil'
> > /sw/src/fink.build/gcc44-4.3.999-20090312/gcc-4.4-20090312/gcc/testsuite/gcc.dg/asm-b.c:27:`%si'
> >  not allowed with `movb'
> > compiler exited with status 1
> > output is:
>
> It is Darwin specific. Linux is OK. Please find out which revision causes it.
> H.J.

Actually x86-linux -m32 *with pic* does fail.  Anytime you have a darwin
error you cannot reproduce on linux, try adding -fpic as it often shows up
that way.  See:
http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg01362.html

--Kaveh

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Michael Meissner]

On Fri, Mar 13, 2009 at 12:34:49PM +0100, Paolo Bonzini wrote:
> These are all the !SHIFT_COUNT_TRUNCATED targets.
> 
> For 4.5 I would like to improve our RTL canonicalization so that no
> out-of-range shifts are ever in the RTL representation.
> 
> This in turn means that the description given by SHIFT_COUNT_TRUNCATED
> must be exact.  Right now !SHIFT_COUNT_TRUNCATED means "I don't know",
> I want it to mean "it is never truncated".
> 
> I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000
> (which define SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which
> do not define it at all) it is right that shift counts are never
> truncated.
> 
> In addition, for arm and m68k I'd like to know whether bitfield
> instructions truncate the bit position the same as shifts (8 bits for
> arm, 6 bits for m68k).
> 
> This information is particularly important for targets that do not
> have a simulator in src.

Note, one thing I encountered when doing the SSE5 work at AMD, is
SHIFT_COUNT_TRUNCATED really needs a mode argument (and ideally should be moved
into the gcc_target structure).  In particular, shifts done in the general
purpose registers were not truncated, but vector shifts done in the SSE5
instructions were truncated (or vice versa).

-- 
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meiss...@linux.vnet.ibm.com

GCC 4.4.0 Status Report (2009-03-13)

[Richard Guenther]

Status
==

The trunk is still in stage 4 which means it is open under the usual
release branch rules.  Thus the trunk is open for regression and
documentation fixes only.

We have been asked by the SC to not branch for now but wait for
the wording for the new runtime license to arrive from the FSF and
that being put in place.

We currently have 82 serious regressions, which is below 100 and zero
P1 regressions.


Quality Data


Priority  # Change from Last Report
--- ---
P10 -  3
P2   79 +  2
P33 +  2
--- ---
Total82 +  1


Previous Report
===
http://gcc.gnu.org/ml/gcc/2009-02/msg00262.html

The next status report will be sent by Jakub.

Richard.

Re: GCC 4.4.0 Status Report (2009-03-13)

[DJ Delorie]

Richard Guenther  writes:
> We have been asked by the SC to not branch for now but wait for
> the wording for the new runtime license to arrive from the FSF and
> that being put in place.

We've been waiting a long time.  At what point do we give up and
branch anyway?

Re: GCC 4.4.0 Status Report (2009-03-13)

[Steven Bosscher]

On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther  wrote:
> We have been asked by the SC to not branch for now but wait for
> the wording for the new runtime license to arrive from the FSF and
> that being put in place.

This is the saddest thing that I have seen in GCC politics so far.

Gr.
Steven

Understand BLKmode and returning structure in register.

[Bingfeng Mei]

Hello,
I came across an issue regarding BLKmode and returning structure in register.  
For following code,  I try to return the structure in register instead of 
memory. 
 
extern void abort();
typedef struct {
  short x;
  short y;
} COMPLEX;
 
COMPLEX foo (void) __attribute__ ((noinline));
COMPLEX foo (void)
{
  COMPLEX  x;  
 
  x.x = -7;
  x.y = -7;
 
  return x;
}
 

int main(){
  COMPLEX x = foo();
  if(x.y != -7)
abort();
}

 
In foo function, compute_record_mode function will set the mode for struct 
COMPLEX as BLKmode partly because STRICT_ALIGNMENT is 1 on my target. In 
TARGET_RETURN_IN_MEMORY hook, I return 1 for BLKmode type and 0 otherwise for 
small size (<8) (like MIPS). Thus, this structure is still returned through 
memory, which is not very efficient. More importantly, ABI is NOT FIXED under 
such situation. If an assembly code programmer writes a function returning a 
structure. How does he know the structure will be treated as BLKmode or 
otherwise? So he doesn't know whether to pass result through memory or 
register. Do I understand correctly?

On the other hand, if I return 0 only according to struct type's size 
regardless BLKmode or not, GCC will produces very inefficient code. For 
example, stack setup code in foo is still generated even it is totally 
unnecessary.

Only when I set STRICT_ALIGNMENT to 0, the structure can be passed through 
register in an efficient way. Unfortunately, our machine is strictly aligned 
and I cannot really do that. 

Any suggestion? 

Thanks,
Bingfeng Mei
Broadcom UK 

Re: GCC 4.4.0 Status Report (2009-03-13)

[Manuel López-Ibáñez]

2009/3/13 Steven Bosscher :
> On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther  wrote:
>> We have been asked by the SC to not branch for now but wait for
>> the wording for the new runtime license to arrive from the FSF and
>> that being put in place.
>
> This is the saddest thing that I have seen in GCC politics so far.

Why? The FSF is offering free legal advice *after* they put forward a
proposal that raised doubts by some people. This is a very important
step that will open the door for the plugins framework. So better safe
than fast. I wish it would be faster but I can understand the FSF
limitations.

Moreover, a few P1 regressions have been fixed thanks to the wait.
Also, nowadays it is very easy to work on branches. Is there anyone
that is being held back by the release delay?

Cheers,

Manuel.

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Paolo Bonzini]

>>> Hm.  In fold-const.c we try to make sure to produce the same result
>>> as the target would for constant-folding shifts.  Thus, Paolo, I think
>>> what fold-const.c does is what we should assume for
>>> !SHIFT_COUNT_TRUNCATED.  No?
>> Unfortunately it is not so simple.  fold-const.c is actually wrong, as
>> witnessed by this program
>>
>>  static inline int f (int s) { return 2 << s; }
>>  int main () { printf ("%d\n", f(33)); }
>>
>> which prints 4 at -O0 and 0 at -O2 on i686-pc-linux-gnu.
> 
> But this is because i?86 doesn't define SHIFT_COUNT_TRUNCATED, no?

Yes, so fold-const.c is *not* modeling the target in this case.

But on the other hand, this means we can get by with documenting the
effect of a conservative truncation mask: no wrong code bugs, just
differences between optimization levels for undefined programs.  I'll
check that the optimizations done based on the truncation mask are all
conservative or can be made so.

So, I'd still need the information for arm and m68k, because that
information is about the bitfield instructions.  For rs6000 it would be
nice to see what they do for 64-bits (for 32-bit I know that PowerPCs
truncate to 6 bits, not 5).  But for the other architectures, we can be
conservative.

Paolo

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Matt Thomas]

On Mar 13, 2009, at 10:06 AM, Paolo Bonzini wrote:




Hm.  In fold-const.c we try to make sure to produce the same result
as the target would for constant-folding shifts.  Thus, Paolo, I  
think

what fold-const.c does is what we should assume for
!SHIFT_COUNT_TRUNCATED.  No?
Unfortunately it is not so simple.  fold-const.c is actually  
wrong, as

witnessed by this program

static inline int f (int s) { return 2 << s; }
int main () { printf ("%d\n", f(33)); }

which prints 4 at -O0 and 0 at -O2 on i686-pc-linux-gnu.


But this is because i?86 doesn't define SHIFT_COUNT_TRUNCATED, no?


Yes, so fold-const.c is *not* modeling the target in this case.

But on the other hand, this means we can get by with documenting the
effect of a conservative truncation mask: no wrong code bugs, just
differences between optimization levels for undefined programs.  I'll
check that the optimizations done based on the truncation mask are all
conservative or can be made so.

So, I'd still need the information for arm and m68k, because that
information is about the bitfield instructions.  For rs6000 it would  
be

nice to see what they do for 64-bits (for 32-bit I know that PowerPCs
truncate to 6 bits, not 5).  But for the other architectures, we can  
be

conservative.


VAX doesn't truncate at all, if you specify >31 bits it raises a
reserved operand exception.

Re: GCC 4.4.0 Status Report (2009-03-13)

[Steven Bosscher]

On Fri, Mar 13, 2009 at 5:42 PM, Manuel López-Ibáñez
 wrote:
> 2009/3/13 Steven Bosscher :
>> On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther  wrote:
>>> We have been asked by the SC to not branch for now but wait for
>>> the wording for the new runtime license to arrive from the FSF and
>>> that being put in place.
>>
>> This is the saddest thing that I have seen in GCC politics so far.
>
> Why? The FSF is offering free legal advice *after* they put forward a
> proposal that raised doubts by some people. This is a very important
> step that will open the door for the plugins framework. So better safe
> than fast. I wish it would be faster but I can understand the FSF
> limitations.

As if the plugins framework matters for GCC 4.4...

There are alternatives to waiting.

For example, GCC has shipped with the old runtime license for more
than a decade. Why not return to that?

Or ship as-is and fix the license for GCC 4.5.  I haven't followed the
legal discussion -- so maybe I'm being naive or I've missed it -- but
I haven't seen anyone explaining why this is not an option.

Or what about branching now and starting the gcc 4.5 development
cycle?  The argument against this, that the same changes will have to
be applied to the trunk and to the release branch, is getting really
weak IMHO, because the argument does not seem to consider all those
other changes that have to be applied many more times than just twice
-- all the merges from trunk to the branches waiting to be merged for
GCC 4.5, for example.


> Moreover, a few P1 regressions have been fixed thanks to the wait.
> Also, nowadays it is very easy to work on branches. Is there anyone
> that is being held back by the release delay?

Perhaps not the individual branches. But there are interactions
between the branches, and the longer it takes to branch for GCC 4.4,
the more difficult it will be to merge all the branches in for GCC
4.5.  So GCC 4.5 is *also* being delayed, not just GCC 4.4.

What is also being held back, is more than a year of improvements since GCC 4.3.

Gr.
Steven

Re: GCC 4.4.0 Status Report (2009-03-13)

[Dave Korn]

[resend to list only owing to running up against the spamfilter]

Manuel López-Ibáñez wrote:
> 2009/3/13 Steven Bosscher :
>> On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther  wrote:
>>> We have been asked by the SC to not branch for now but wait for
>>> the wording for the new runtime license to arrive from the FSF and
>>> that being put in place.
>> This is the saddest thing that I have seen in GCC politics so far.
> 
> Why? The FSF is offering free legal advice *after* they put forward a
> proposal that raised doubts by some people. This is a very important
> step that will open the door for the plugins framework. So better safe
> than fast. I wish it would be faster but I can understand the FSF
> limitations.
> 
> Moreover, a few P1 regressions have been fixed thanks to the wait.
> Also, nowadays it is very easy to work on branches. Is there anyone
> that is being held back by the release delay?

  Well it's causing a backlog of patches for 4.5 to build up.  If we branched
first and fixed the licence on the branch, we'd have to do more work by
applying the same changes to trunk and branch separately, but it would clear
the blockage.  So I don't understand why we aren't going that way.

  Can anyone clarify if the SC *really* need us to not branch before the
licence change, as opposed to merely not /release/ until then?  (And why, if 
so?)

cheers,
  DaveK

Re: GCC 4.4.0 Status Report (2009-03-13)

[Richard Guenther]

On Fri, 13 Mar 2009, Dave Korn wrote:

> >> On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther  
> >> wrote:
> >>> We have been asked by the SC to not branch for now but wait for

[...]

>   Can anyone clarify if the SC *really* need us to not branch before the
> license change, as opposed to merely not /release/ until then?

The topmost sentence should be unambiguous.  Yes, the SC asked us not
to branch.

Richard.

Re: GCC 4.4.0 Status Report (2009-03-13)

[Janis Johnson]

On Fri, 2009-03-13 at 17:04 +0100, Richard Guenther wrote:
> Status
> ==
> 
> The trunk is still in stage 4 which means it is open under the usual
> release branch rules.  Thus the trunk is open for regression and
> documentation fixes only.

What do you think about possibly-disruptive testsuite patches?
In particular, the patch in

  http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01496.html

fixes an actual bug on Darwin (testsuite/38562) and cleans up
earlier fixes for testsuite/36443.  I didn't want to add it to
trunk if the branch was imminent, but otherwise would it be OK,
since not much is happening in stage 4 and there will apparently
be plenty of time to revert it if there are problems?

Janis

Re: GCC 4.4.0 Status Report (2009-03-13)

[Richard Guenther]

On Fri, 13 Mar 2009, Janis Johnson wrote:

> On Fri, 2009-03-13 at 17:04 +0100, Richard Guenther wrote:
> > Status
> > ==
> > 
> > The trunk is still in stage 4 which means it is open under the usual
> > release branch rules.  Thus the trunk is open for regression and
> > documentation fixes only.
> 
> What do you think about possibly-disruptive testsuite patches?
> In particular, the patch in
> 
>   http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01496.html
> 
> fixes an actual bug on Darwin (testsuite/38562) and cleans up
> earlier fixes for testsuite/36443.  I didn't want to add it to
> trunk if the branch was imminent, but otherwise would it be OK,
> since not much is happening in stage 4 and there will apparently
> be plenty of time to revert it if there are problems?

It is up to the maintainers to decide.  testsuite is somewhere on
the border of "documentation" for me ;)

What makes stage 4 easier than a branch is that you do not risk
to leak a regression relative to an earlier dot release into a release.

Richard.

RE: Understand BLKmode and returning structure in register.

[Bingfeng Mei]

I found that compiling for mips with -mabi=n32 produces such inefficient code. 
When -mabi=n32, mips_return_in_memory returns 0 if size is small regardless 
BLKmode or not. 

.type   foo, @function
foo:
.frame  $sp,16,$31  # vars= 16, regs= 0/0, args= 0, gp= 0

addiu   $sp,$sp,-16
li  $2,-7   # 0xfff9
sh  $2,0($sp)
sh  $2,2($sp)
ld  $3,0($sp)
addiu   $sp,$sp,16
dsrl$4,$3,32
andi$4,$4,0x
dsrl$3,$3,48
dsll$4,$4,32
dsll$2,$3,48
j   $31
or  $2,$2,$4

.entmain
.type   main, @function
main:

addiu   $sp,$sp,-48
sd  $31,40($sp)
jal foo
nop

dsra$3,$2,32
dsrl$2,$2,48
sh  $3,18($sp)
sh  $2,16($sp)
lw  $2,16($sp)
sll $3,$2,16
sw  $2,0($sp)
sra $3,$3,16
li  $2,-7   # 0xfff9
bne $3,$2,$L8
ld  $31,40($sp)

j   $31
addiu   $sp,$sp,48

$L8:
jal abort
nop


With old ABI, produced code is much simpler but the structure is returned 
through memory. mips_retrun_in_memory returns 1 because the structure type is 
BLKmode.

foo:
li  $3,-7   # 0xfff9
move$2,$4
sh  $3,0($4)
j   $31
sh  $3,2($4)

.entmain
.type   main, @function
main:
.frame  $sp,32,$31  # vars= 8, regs= 1/0, args= 16, gp= 0

addiu   $sp,$sp,-32
sw  $31,28($sp)
jal foo
addiu   $4,$sp,16

lh  $3,18($sp)
li  $2,-7   # 0xfff9
bne $3,$2,$L8
nop

lw  $31,28($sp)
nop
j   $31
addiu   $sp,$sp,32

$L8:
jal abort
nop

> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On 
> Behalf Of Bingfeng Mei
> Sent: 13 March 2009 16:35
> To: gcc@gcc.gnu.org
> Cc: Adrian Ashley
> Subject: Understand BLKmode and returning structure in register.
> 
> Hello,
> I came across an issue regarding BLKmode and returning 
> structure in register.  For following code,  I try to return 
> the structure in register instead of memory. 
>  
> extern void abort();
> typedef struct {
>   short x;
>   short y;
> } COMPLEX;
>  
> COMPLEX foo (void) __attribute__ ((noinline));
> COMPLEX foo (void)
> {
>   COMPLEX  x;  
>  
>   x.x = -7;
>   x.y = -7;
>  
>   return x;
> }
>  
> 
> int main(){
>   COMPLEX x = foo();
>   if(x.y != -7)
> abort();
> }
> 
>  
> In foo function, compute_record_mode function will set the 
> mode for struct COMPLEX as BLKmode partly because 
> STRICT_ALIGNMENT is 1 on my target. In 
> TARGET_RETURN_IN_MEMORY hook, I return 1 for BLKmode type and 
> 0 otherwise for small size (<8) (like MIPS). Thus, this 
> structure is still returned through memory, which is not very 
> efficient. More importantly, ABI is NOT FIXED under such 
> situation. If an assembly code programmer writes a function 
> returning a structure. How does he know the structure will be 
> treated as BLKmode or otherwise? So he doesn't know whether 
> to pass result through memory or register. Do I understand correctly?
> 
> On the other hand, if I return 0 only according to struct 
> type's size regardless BLKmode or not, GCC will produces very 
> inefficient code. For example, stack setup code in foo is 
> still generated even it is totally unnecessary.
> 
> Only when I set STRICT_ALIGNMENT to 0, the structure can be 
> passed through register in an efficient way. Unfortunately, 
> our machine is strictly aligned and I cannot really do that. 
> 
> Any suggestion? 
> 
> Thanks,
> Bingfeng Mei
> Broadcom UK 
> 
> 
> 

Re: GCC 4.4.0 Status Report (2009-03-13)

[Daniel Jacobowitz]

On Fri, Mar 13, 2009 at 06:25:34PM +0100, Richard Guenther wrote:
> On Fri, 13 Mar 2009, Dave Korn wrote:
> 
> > >> On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther  
> > >> wrote:
> > >>> We have been asked by the SC to not branch for now but wait for
> 
> [...]
> 
> >   Can anyone clarify if the SC *really* need us to not branch before the
> > license change, as opposed to merely not /release/ until then?
> 
> The topmost sentence should be unambiguous.  Yes, the SC asked us not
> to branch.

But:

> (And why, if so?)

-- 
Daniel Jacobowitz
CodeSourcery

Re: GCC 4.4.0 Status Report (2009-03-13)

[Dave Korn]

Richard Guenther wrote:
> On Fri, 13 Mar 2009, Dave Korn wrote:
> 
 On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther  
 wrote:
> We have been asked by the SC to not branch for now but wait for
> 
> [...]
> 
>>   Can anyone clarify if the SC *really* need us to not branch before the
>> license change, as opposed to merely not /release/ until then?
> 
> The topmost sentence should be unambiguous.  

  Well it is, but I wasn't sure if it was intentionally so or just an
accidental choice of wording.  Thank you for the clarification (even if it's
only my own dumbness that necessitated it).

> Yes, the SC asked us not to branch.

  The 'why' is the really interesting bit.  And I'm not necessarily even about
to propose some smart-ass way to get around it either :), I just want to
understand.

cheers,
  DaveK

Re: GCC 4.4.0 Status Report (2009-03-13)

[Dave Korn]

Steven Bosscher wrote:

> Or ship as-is and fix the license for GCC 4.5.  I haven't followed the
> legal discussion -- so maybe I'm being naive or I've missed it -- but
> I haven't seen anyone explaining why this is not an option.

  I can see why that won't work.  If there's a problem with the current
licence that would open a backdoor to proprietary plugins, and we ever release
the code under that licence, evaders will be able to maintain a fork under the
original licence no matter how we subsequently relicense it.

  BTW, re your initial post ...

Steven Bosscher wrote:
>
> This is the saddest thing that I have seen in GCC politics so far.

  IMO if a few weeks delay to sort out a really complicated legal technicality
is the saddest thing you've seen so far, we can't be doing that badly.

cheers,
  DaveK

Re: GCC 4.4.0 Status Report (2009-03-13)

[Steven Bosscher]

On Fri, Mar 13, 2009 at 6:47 PM, Dave Korn
 wrote:
> Steven Bosscher wrote:
>
>> Or ship as-is and fix the license for GCC 4.5.  I haven't followed the
>> legal discussion -- so maybe I'm being naive or I've missed it -- but
>> I haven't seen anyone explaining why this is not an option.
>
>  I can see why that won't work.  If there's a problem with the current
> licence that would open a backdoor to proprietary plugins, and we ever release
> the code under that licence, evaders will be able to maintain a fork under the
> original licence no matter how we subsequently relicense it.

And this is the legal concern raised about the current license?  I
thought the problem was that the license was too restraining...  But
if what you say here is the issue, then I understand the reasons
better now.


>  BTW, re your initial post ...
>
> Steven Bosscher wrote:
>>
>> This is the saddest thing that I have seen in GCC politics so far.
>
>  IMO if a few weeks delay to sort out a really complicated legal technicality
> is the saddest thing you've seen so far, we can't be doing that badly.

It's not a few weeks.  It is months already.  And who knows how much
longer it can take.

But you're right, there actually are sadder things... ;-)

Gr.
Steven

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Paul Koning]

> "Paolo" == Paolo Bonzini  writes:

 Paolo> These are all the !SHIFT_COUNT_TRUNCATED targets.  For 4.5 I
 Paolo> would like to improve our RTL canonicalization so that no
 Paolo> out-of-range shifts are ever in the RTL representation.

 Paolo> This in turn means that the description given by
 Paolo> SHIFT_COUNT_TRUNCATED must be exact.  Right now
 Paolo> !SHIFT_COUNT_TRUNCATED means "I don't know", I want it to mean
 Paolo> "it is never truncated".

 Paolo> I would like to know whether for
 Paolo> avr,bfin,cris,frv,h8300,pdp11,rs6000 (which define
 Paolo> SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which do not
 Paolo> define it at all) it is right that shift counts are never
 Paolo> truncated.

For PDP11, shift counts are actually truncated to a signed 6-bit
value.  Somewhat odd for a 16 bit machine but that's what the book
says.

paul

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Paolo Bonzini]

> Note, one thing I encountered when doing the SSE5 work at AMD, is
> SHIFT_COUNT_TRUNCATED really needs a mode argument (and ideally should be 
> moved
> into the gcc_target structure).

In fact I'm reusing the TARGET_SHIFT_TRUNCATION_MASK element that is
already there and accepts a mode.

Paolo

Re: GCC 4.4.0 Status Report (2009-03-13)

[Joseph S. Myers]

On Fri, 13 Mar 2009, Steven Bosscher wrote:

> Or what about branching now and starting the gcc 4.5 development
> cycle?  The argument against this, that the same changes will have to

There might also be the temptation to create a trunk-substitute branch to 
receive Stage 1 developments and branch merges until such can go on trunk 
itself.  But this would not be appropriate given the SC statement the last 
time this was done .  In 
addition, if an early trunk commit for 4.5 were a merge of a branch with a 
bunch of unrelated changes, that would be a pain for future binary 
searches for regressions that track them to such a commit.

Declaring that 4.4 will be branched based on past revision X once the 
licensing issues have been resolved (and moving trunk to Stage 1) would 
also be problematic as it would prevent an FSF or SC decision that the new 
license terms must be present on the branch from the point at which it is 
created.

Given the SC request we need to stay in Stage 4 rather than trying to work 
around it.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: GCC 4.4.0 Status Report (2009-03-13)

[Joe Buck]

On Fri, Mar 13, 2009 at 09:30:19AM -0700, Steven Bosscher wrote:
> On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther  wrote:
> > We have been asked by the SC to not branch for now but wait for
> > the wording for the new runtime license to arrive from the FSF and
> > that being put in place.
> 
> This is the saddest thing that I have seen in GCC politics so far.

I don't understand why you think it's sad.  The reason for the delay
is the objections that were raised on this list, well-summarized by
Ian Taylor in

http://gcc.gnu.org/ml/gcc/2009-01/msg00596.html

The delay is because the FSF is taking these objections seriously
and is trying to correct the problems.  Would it be happier for you
if the FSF just ignored developers' concerns?

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Joseph S. Myers]

On Fri, 13 Mar 2009, Richard Guenther wrote:

> Hm.  In fold-const.c we try to make sure to produce the same result
> as the target would for constant-folding shifts.  Thus, Paolo, I think
> what fold-const.c does is what we should assume for
> !SHIFT_COUNT_TRUNCATED.  No?

I think attempting the same result as the target for this undefined 
behavior is a pretty futile endeavour; I think we also optimize in places 
on the basis of it being undefined.  We don't attempt to generate the same 
results at compile time and runtime for out of range floating-point to 
integer conversions (unspecified value according to C99 Annex F, so we 
don't need to generate the same results), which has actually attracted bug 
reports; there, some languages may place more precise requirements on what 
the results are (e.g. bug 28144).

This does not of course rule out adding options in future (and associated 
tree codes) that make this defined (probably making negative shifts act 
like shifts in the opposite direction, and out-of-range shifts act like 
shifting one bit at a time, rather than using target-specific semantics) 
or causing the undefined cases to generate traps.

As I understand it, SHIFT_COUNT_TRUNCATED is about the semantics of RTL, 
and has no bearing on the implemented semantics of any source language or 
of GENERIC or GIMPLE; GENERIC and GIMPLE both follow the rule that 
out-of-range shifts (or rotates?), including those by negative amounts, 
are undefined.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Richard Guenther]

On Fri, Mar 13, 2009 at 7:07 PM, Joseph S. Myers
 wrote:
> On Fri, 13 Mar 2009, Richard Guenther wrote:
>
>> Hm.  In fold-const.c we try to make sure to produce the same result
>> as the target would for constant-folding shifts.  Thus, Paolo, I think
>> what fold-const.c does is what we should assume for
>> !SHIFT_COUNT_TRUNCATED.  No?
>
> I think attempting the same result as the target for this undefined
> behavior is a pretty futile endeavour; I think we also optimize in places
> on the basis of it being undefined.  We don't attempt to generate the same
> results at compile time and runtime for out of range floating-point to
> integer conversions (unspecified value according to C99 Annex F, so we
> don't need to generate the same results), which has actually attracted bug
> reports; there, some languages may place more precise requirements on what
> the results are (e.g. bug 28144).

Last time I sent a patch to remove the SHIFT_COUNT_TRUNCATED check
from fold-const.c the reason that this was rejected was that we want to
be consistend with target behavior...

> This does not of course rule out adding options in future (and associated
> tree codes) that make this defined (probably making negative shifts act
> like shifts in the opposite direction, and out-of-range shifts act like
> shifting one bit at a time, rather than using target-specific semantics)
> or causing the undefined cases to generate traps.
>
> As I understand it, SHIFT_COUNT_TRUNCATED is about the semantics of RTL,
> and has no bearing on the implemented semantics of any source language or
> of GENERIC or GIMPLE; GENERIC and GIMPLE both follow the rule that
> out-of-range shifts (or rotates?), including those by negative amounts,
> are undefined.

"Undefined" is a bad semantic for GIMPLE.  If the frontends want the middle-end
to take advantage of undefinedness it needs to translate it to a useful defined
state.

Richard.

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Andreas Schwab]

Paolo Bonzini  writes:

> In addition, for arm and m68k I'd like to know whether bitfield
> instructions truncate the bit position the same as shifts (8 bits for
> arm, 6 bits for m68k).

For the m68k bitfield insns (when operating on memory) the bit position
can be in the full range of a signed 32-bit number, and the field width
is truncated to 5 bits (range 1-32, where 32 is encoded as 0).

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GCC 4.4.0 Status Report (2009-03-13)

[Steven Bosscher]

On Fri, Mar 13, 2009 at 7:03 PM, Joe Buck  wrote:
> On Fri, Mar 13, 2009 at 09:30:19AM -0700, Steven Bosscher wrote:
>> On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther  wrote:
>> > We have been asked by the SC to not branch for now but wait for
>> > the wording for the new runtime license to arrive from the FSF and
>> > that being put in place.
>>
>> This is the saddest thing that I have seen in GCC politics so far.
>
> I don't understand why you think it's sad.

I think it is sad because there is a lengthy delay for the release and
for GCC 4.5 development while, at least as far as I can see, the whole
discussion is not relevant for GCC 4.4.  The new license exception is
written to support a plugin infrastructure, right? But that won't be
in GCC 4.4.  So why can't GCC 4.4 ship with the old license?

Gr.
Steven

Re: GCC 4.4.0 Status Report (2009-03-13)

[Joe Buck]

On Fri, Mar 13, 2009 at 10:25:34AM -0700, Richard Guenther wrote:
> The topmost sentence should be unambiguous.  Yes, the SC asked us not
> to branch.

The request came from RMS, the SC just passed it on.

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Joseph S. Myers]

On Fri, 13 Mar 2009, Richard Guenther wrote:

> Last time I sent a patch to remove the SHIFT_COUNT_TRUNCATED check
> from fold-const.c the reason that this was rejected was that we want to
> be consistend with target behavior...

I would disagree with such a rejection.  If we want to provide any sort of 
consistency I think it should be optional (an option like -fwrapv) and 
define the semantics at the language level rather than depending on the 
target.

> > As I understand it, SHIFT_COUNT_TRUNCATED is about the semantics of RTL,
> > and has no bearing on the implemented semantics of any source language or
> > of GENERIC or GIMPLE; GENERIC and GIMPLE both follow the rule that
> > out-of-range shifts (or rotates?), including those by negative amounts,
> > are undefined.
> 
> "Undefined" is a bad semantic for GIMPLE.  If the frontends want the 
> middle-end
> to take advantage of undefinedness it needs to translate it to a useful 
> defined
> state.

By undefined I mean that the middle-end may assume that the value is 
within range [0, number of value and sign bits in type) and transform on 
the basis of that assumption (including value range propagation).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Hans-Peter Nilsson]

> Date: Fri, 13 Mar 2009 12:34:49 +0100
> From: Paolo Bonzini 

> I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000
> (which define SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which
> do not define it at all) it is right that shift counts are never
> truncated.

The answer to the question is "no", but I'd guess the more
useful answer is "yes", for different definitions of "truncate".

For CRIS, shift counts (variable; literate ones are 5 bits) are
truncated to 6 (six) bits, regardless of the mode of the shift
result (NB, all standard-named shifts are define_expanded to
SImode, though anon strict_low_part-matching patterns for other
modes exist).  See also
,

and src/cpu/cris.cpu.

So, if the result of the truncation has bit 5 set for SImode,
the results is 0.  For smaller modes, a size larger than the
number of bits of the mode yields the extended result in those
bits (i.e. all 1 or 0, depending on the operation).

brgds, H-P

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Laurent Desnogues]

On Fri, Mar 13, 2009 at 6:06 PM, Paolo Bonzini  wrote:
>
> So, I'd still need the information for arm and m68k, because that
> information is about the bitfield instructions.

For ARM, shifts by immediate use a 5-bit constant, shifts by register
use the lower 8 bits of the register.

For ARMv6T2/ARMv7, bitfield instructions:

  - BFC, BFI specify an immediate 5-bit starting bit position and
an immediate 5-bit ending bit position
  - SBFX, UBFX specify an immediate 5-bit starting bit position
and an immediate 5-bit width.


Laurent

sign/zero extension of function arguments on x86-64

[Rafael Espindola]

This is similar to the discussion that happened some time ago about
extending return values. The decisions for that was that the callee
could just leave the higher bits undefined and the caller would
extent the result if it needed to.

We have a similar issue with function arguments. We compile

void g(short);

void f(short a) {
  g(a);
}

into

f:
.LFB2:
movswl  %di,%edi
jmp g

we should really be able to remove the movswl. If the caller
is required to do sign extension, who called f has
extended the argument already. If the callee is required,
then g will do it and there is no need for f to do it.

What is more interesting is the case

void g(int);

void f(short a) {
  g(a);
}

Can f assume that its caller did a sign extension or
it is its responsibility to extend A?

Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

Re: GCC 4.4.0 Status Report (2009-03-13)

[Toon Moene]

Steven Bosscher wrote:


On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther  wrote:

We have been asked by the SC to not branch for now but wait for
the wording for the new runtime license to arrive from the FSF and
that being put in place.


This is the saddest thing that I have seen in GCC politics so far.


That's just because you haven't been around long enough.

It *is* however, the saddest thing I've seen since we (the egcs 
developers) have been handed the GCC maintainership in April, 1999 by 
the FSF.


I don't mind if the FSF asks us to hold up the release of 4.4 until the 
run-time library license is finalized.


What I *do* object to is micro-management by the FSF in "preventing" us 
to make a 4.4 branch.


If we have a 4.4 branch, people could commit the megabytes of stuff 
that's now piling up in developers branches, home changed repositories, 
private patches, etc.


It's just bad economics.

--
Toon Moene - e-mail: t...@moene.org (*NEW*) - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.4/changes.html

how to report a bug which doesn't happen on the .ii file generated with -save-temps?

[Francesco Montorsi]

Hi,
  I'm new to GCC project so let me know if this is the wrong place where I can 
ask such a question.


I've found a bug in Gcc 4.3.3 (on machine "Linux ubuntu 2.6.28-9-generic 
#31-Ubuntu SMP Wed Mar 11 15:43:49 UTC 2009 x86_64 GNU/Linux") which I can 
reliably reproduce (just running "make") and which generates:


g++ -c lots of other options... ../src/stc/stc.cpp
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See  for instructions.
make: *** [stclib_stc.o] Errore 1

However if I try to follow README.Bugs and use the -save-temps option and then 
try to compile the generated .ii file:


g++ -c lots of other options... stc.ii

the crash doesn't happen.

How can I report such a bug? Including all involved files in a tarball would 
violate the rules for reporting bugs.
Moreover, I could not find -dbg packages for GCC itself on my Ubuntu Jaunty so 
that running GCC in GDB doesn't give me a valid stack trace... I'd prefer not to 
build GCC myself... is there some alternative I'm missing?


Thanks,
Francesco Montorsi

Re: how to report a bug which doesn't happen on the .ii file generated with -save-temps?

[Ian Lance Taylor]

Francesco Montorsi  writes:

>   I'm new to GCC project so let me know if this is the wrong place
> where I can ask such a question.

The mailing list gcc-h...@gcc.gnu.org would be a better place.


> I've found a bug in Gcc 4.3.3 (on machine "Linux ubuntu
> 2.6.28-9-generic #31-Ubuntu SMP Wed Mar 11 15:43:49 UTC 2009 x86_64
> GNU/Linux") which I can reliably reproduce (just running "make") and
> which generates:
>
> g++ -c lots of other options... ../src/stc/stc.cpp
> g++: Internal error: Segmentation fault (program cc1plus)
> Please submit a full bug report.
> See  for instructions.
> make: *** [stclib_stc.o] Errore 1
>
> However if I try to follow README.Bugs and use the -save-temps option
> and then try to compile the generated .ii file:
>
> g++ -c lots of other options... stc.ii
>
> the crash doesn't happen.

It may not matter.  As long as the crash happens when you use the
--save-temps option, then reporting the bug with the .ii file may be
enough.  However, it's true that if other people are unable to recreate
the problem then it may not be possible to fix it.

Sometimes this can indicate that there is a problem with precompiled
haders.  Do you know if you are using a precompiled header?


> How can I report such a bug? Including all involved files in a tarball
> would violate the rules for reporting bugs.

Do it anyhow if that is the only way.

Ian

Re: Constant folding and Constant propagation

[Jean Christophe Beyler]

I set up your patch and I get an internal error on this test program:

extern void foo(int, int);
extern int bar(void);
int startup;

void foobar()
{
  int i;
  while(1)
  {
if (bar()) {
foo(0,0);
}
  }
}

Here's the error:
/home/beyler/cyclops64/src/tnt/kernel/process_manager/testnode.c: In
function 'foobar':
/home/beyler/cyclops64/src/tnt/kernel/process_manager/testnode.c:15:
internal compiler error: in insert_regs, at cse.c:1156
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


I think it's got something to do with my machine description but this
only happens when the values of foo are both 0. I haven't found
another case where it fails. It seems when the compiler sees two
constants 0 for the register (r8 which is my first input register), it
fails on the second. Somewhere between both calls, it must remove the
quantity.

Any ideas ?
Jc

Re: how to report a bug which doesn't happen on the .ii file generated with -save-temps?

[Francesco Montorsi]

Hi,

Ian Lance Taylor ha scritto:

Francesco Montorsi  writes:


  I'm new to GCC project so let me know if this is the wrong place
where I can ask such a question.


The mailing list gcc-h...@gcc.gnu.org would be a better place.

ok, thanks for the info; I'll post there in future.


However if I try to follow README.Bugs and use the -save-temps option
and then try to compile the generated .ii file:

g++ -c lots of other options... stc.ii

the crash doesn't happen.


It may not matter.  As long as the crash happens when you use the
--save-temps option, then reporting the bug with the .ii file may be
enough.  However, it's true that if other people are unable to recreate
the problem then it may not be possible to fix it.

Sometimes this can indicate that there is a problem with precompiled
haders.  Do you know if you are using a precompiled header?

yes, I am!
In fact, removing the PCH and recreating it fixed the problem! Thanks for the 
hint.


How can I report such a bug? Including all involved files in a tarball
would violate the rules for reporting bugs.


Do it anyhow if that is the only way.
hmmm, actually I didn't make a backup copy of the damaged PCH and so I cannot 
reproduce the bug anymore myself :/


I suspect that the problem comes from using "make -j4" (on a quadcore system): 
sometimes the PCH files get corrupted and problems like the one reported above 
happen. It maybe a race condition somewhere...


For now I think I won't spend time any further on this - since I have no 
reliable way to reproduce the bug in the PCH; if I hit it once again, I'll try 
to save the damaged PCH (in the hope it's useful to somebody to understand 
what's wrong)...


Thanks,
Francesco

gcc-4.4-20090313 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 144850

You'll find:

gcc-4.4-20090313.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.4-20090313.tar.bz2 C front end and core compiler

gcc-ada-4.4-20090313.tar.bz2  Ada front end and runtime

gcc-fortran-4.4-20090313.tar.bz2  Fortran front end and runtime

gcc-g++-4.4-20090313.tar.bz2  C++ front end and runtime

gcc-java-4.4-20090313.tar.bz2 Java front end and runtime

gcc-objc-4.4-20090313.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.4-20090313.tar.bz2The GCC testsuite

Diffs from 4.4-20090306 are available in the diffs/ subdirectory.

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