Re: bit_size_type - a data type?

[Florian Weimer]

* Richard Kenner:

>> bitsizetype is a type that can hold any values of sizetype *
>> BITS_PER_UNIT so we can safely do bit-size calculations without overflow.
>> This type shouldn't end up used in code though.
>
> Unfortunately, it does, though not in C.  Ada's 'Size attribute returns
> the size in bits, so the proper type for that computations is bitsizetype,
> though many computations end up being constant-folded.

Ada used a 32-bit signed integer type in this case, limiting object size
to 2**31 bits.  Is this no longer the case?

Re: bit_size_type - a data type?

[Richard Kenner]

> Ada used a 32-bit signed integer type in this case, limiting object size
> to 2**31 bits.  Is this no longer the case?

It was never the case.  You're confusing sizetype with bitsizetype.

gcc-get enabling-only subscription?

[Joern Rennecke]

With my current email setup and the volume of the gcc mailing list,
it is not desirable to be to be subscribed to the gcc mailing list,
I rather read the web archives.
However, this does not allow to make a properly threaded reply.  I've
tried to use gcc-get email interface, but apparently it will only send
to subscribers.
Is there a way to subscribe only for the purpose of being able to receive
messages with the gcc-get mechanism, without getting regular list emails?

RE: gcc-get enabling-only subscription?

[Dave Korn]

Joern Rennecke wrote on 13 May 2008 15:04:

> With my current email setup and the volume of the gcc mailing list,
> it is not desirable to be to be subscribed to the gcc mailing list,
> I rather read the web archives.
> However, this does not allow to make a properly threaded reply.  I've
> tried to use gcc-get email interface, but apparently it will only send
> to subscribers.
> Is there a way to subscribe only for the purpose of being able to receive
> messages with the gcc-get mechanism, without getting regular list emails?

  You could sub up to the digest mode, which might at least be less of a
burden, but we can't let the list manager answer GET requests from
non-subscribers, because "non-subscribing email address" means "non-validated
unconfirmed email address", and we'd get people sending it fakemails in order
to mailbomb the forged "From:" address by backscatter effect.

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

Re: gcc-get enabling-only subscription?

[Joern Rennecke]

>   You could sub up to the digest mode, which might at least be less of a
> burden,

It would reduce the number of messages, but the volume would still be
very high.

> but we can't let the list manager answer GET requests from
> non-subscribers, because "non-subscribing email address" means "non-validated
> unconfirmed email address", and we'd get people sending it fakemails in order
> to mailbomb the forged "From:" address by backscatter effect.

That's why I asked if there was a subscription for the purposes of gcc-get
only.  I originally thought it would be sufficient to subscribe to
gcc-announce, as this already verifies my email address, but apparently
that is not good enough.

Re: gcc-get enabling-only subscription?

[Andreas Schwab]

Joern Rennecke <[EMAIL PROTECTED]> writes:

> That's why I asked if there was a subscription for the purposes of gcc-get
> only.  I originally thought it would be sufficient to subscribe to
> gcc-announce, as this already verifies my email address, but apparently
> that is not good enough.

You can put yourself on the (global) allow list, see
.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gcc-get enabling-only subscription?

[Andrew STUBBS]

Joern Rennecke wrote:

  You could sub up to the digest mode, which might at least be less of a
burden,



It would reduce the number of messages, but the volume would still be
very high.


Hi Joern,

You could just sign up to one of the online mail list services. Here's 
the nabble link for this thread:


http://www.nabble.com/gcc-get-enabling-only-subscription--to17209319.html

You need to register to reply, of course.

HTH

Andrew

Re: gcc-get enabling-only subscription?

[Andreas Schwab]

Andrew STUBBS <[EMAIL PROTECTED]> writes:

> Joern Rennecke wrote:
>>>   You could sub up to the digest mode, which might at least be less of a
>>> burden,
>
>> It would reduce the number of messages, but the volume would still be
>> very high.
>
> Hi Joern,
>
> You could just sign up to one of the online mail list services. Here's the
> nabble link for this thread:
>
> http://www.nabble.com/gcc-get-enabling-only-subscription--to17209319.html

You can also use gmane.org, see for example
.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: bit_size_type - a data type?

[Florian Weimer]

* Richard Kenner:

>> Ada used a 32-bit signed integer type in this case, limiting object size
>> to 2**31 bits.  Is this no longer the case?
>
> It was never the case.  You're confusing sizetype with bitsizetype.

The limit was definitely there.  Maybe it had a different root cause,
though.

Re: Reviving old port

[Richard Sandiford]

Omar <[EMAIL PROTECTED]> writes:
>  1-The c816's port is heavily using the c816.c instead of better
> describing the cpu in the c816.md file. For instance, looking at the
> define_insn movhi:
> ;; movhi
> (define_insn "movhi"
>  [(set (match_operand:HI 0 "general_operand" "=g")
>(match_operand:HI 1 "general_operand" "g"))]
>  ""
>  "*
>{
>  return output_move(insn, operands);
>}
>  ")
>
>  I noticed that predicates and constraints are essentially disabled,
> and the output_move function in the c816.c  does all the work. Also,
> since c816 can only move bytes, it looks to me like this definition is
> incorrectly since it is basically lying to gcc and making it believe
> that there is a two byte move. Is a define_split (or a define_expand)
> more appropriate in this situation?

A define_split has traditionally been the best way, yes.  The splitter
would normally be a postreload one (i.e. it would normally be conditional
on reload_completed).

There's no real point doing a define_expand, unless it needs to do
something particularly magical.  If there is no move pattern for a
wide mode, emit_move_insn & friends can break it up into narrower
pieces.

>  2- I am trying to sort-out define_expand from define_split. Looks
> like they can be used to perform similar tasks. By looking at other
> ports I came to the following conclusions (I gather this from reading
> multiple posts, please correct me if this statements are not true):
>  2.1  define_split should be used to break an operation into simpler
> operations *of a different mode*. That is, to describe a movhi in
> terms of two movqi I should use a define_split instead of a
> define_expand.
>  2.2 the define_expand expects the mode of the matching rtl macro and
> the output operations to be preserve. Otherwise gcc could get confuse
> since the mode will be change for no apparent reason.

To answer the question directly first: define_splits don't need to
operate on different modes.  Sometimes you have a define_insn with
several (constraint) alternatives, some of which map to a single
instruction and some of which map to several instructions.  You can
then use a define_split to split up the multi-instruction alternatives.

As far as define_expands go: named instructions like "addhi3" must
implement the addition of two given HImode values and store the result
in a given HImode location.  The expander is free to implement the
operation however it likes within those constraints.

The difference between define_expands and define_splits is really
one of timing.  define_expands are applied immediately, so the
optimisers can see the individual instructions straight away.
This can make some optimisations harder and others easier.

define_splits are applied later, and were traditionally used to
"lower" multiword operations into word operations.  The idea was
to let the higher-level rtl optimisers see the complete multiword
operation (like a DImode addition on a 32-bit target) and let the
later, lower-level optimisations see the individual word-mode
operations.

However, most of the interesting higher-level, multiword optimisations
now happen at the tree level.  The higher-level rtl stuff is mostly for
port-specific things like address logic.  (OK, so that's a fairly big
generalisation.)

The MIPS port used to have define_splits for multiword operations,
but I found after tree-ssa that we got better code by expanding into
individual instructions immediately.  optabs knows how to decompose
most multiword operations, so you'll only need your own define_expand if
your target has a feature that is not associated with a named pattern.
E.g. ports with an "add-with-carry" instruction might implement a
doubleword addition pattern, but those that can't better an add-and-shift-
based sequence don't need to.

There's a second use of define_splits that you don't mention explicitly:
they allow the "combine" pass to decompose a single, unrecognisable
operation into instructions that are recognisable.  define_expands
are not used for this.

Also, define_expands can be useful if you want to implement a named
pattern in more than one way, perhaps depending on command-line options.
You can only have one pattern called "addsi3", but if you make it a
define_expand, you can emit any specific define_insn you like.
Some of the define_insns might have more clobbers than others,
for example.

Probably most of that was just telling you what you already knew, sorry.
Good luck with the port,

Richard

h8/300 build failure

[DJ Delorie]

Anyone else seeing this on trunk?

if test -z "$objects"; then \
  echo 'int __libgcc_eh_dummy;' > eh_dummy.c;   \
  /sata/dj/gnu/newlib/h8300-elf/./gcc/xgcc 
-B/sata/dj/gnu/newlib/h8300-elf/./gcc/ -B/sata/dj/gnu/install/h8300-elf/bin/ 
-B/sata/dj/gnu/install/h8300-elf/lib/ -isystem 
/sata/dj/gnu/install/h8300-elf/include -isystem 
/sata/dj/gnu/install/h8300-elf/sys-include -g -O2 -O2  -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -DDF=SF -g  
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc 
-I/sata/dj/gnu/gcc/gcc/libgcc -I/sata/dj/gnu/gcc/gcc/libgcc/. 
-I/sata/dj/gnu/gcc/gcc/libgcc/../gcc -I/sata/dj/gnu/gcc/gcc/libgcc/../include  
-DHAVE_CC_TLS  -c eh_dummy.c\
 -o eh_dummy.o; \
  objects=eh_dummy.o;   \
fi; \
/sata/dj/gnu/install/h8300-elf/bin/ar  rc libgcc.a $objects
/sata/dj/gnu/install/h8300-elf/bin/ranlib libgcc.a
/sata/dj/gnu/newlib/h8300-elf/./gcc/xgcc -B/sata/dj/gnu/newlib/h8300-elf/./gcc/ 
-B/sata/dj/gnu/install/h8300-elf/bin/ -B/sata/dj/gnu/install/h8300-elf/lib/ 
-isystem /sata/dj/gnu/install/h8300-elf/include -isystem 
/sata/dj/gnu/install/h8300-elf/sys-include -g -O2 -O2  -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -DDF=SF -g  
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc 
-I/sata/dj/gnu/gcc/gcc/libgcc -I/sata/dj/gnu/gcc/gcc/libgcc/. 
-I/sata/dj/gnu/gcc/gcc/libgcc/../gcc -I/sata/dj/gnu/gcc/gcc/libgcc/../include  
-DHAVE_CC_TLS -o _gcov.o -MT _gcov.o -MD -MP -MF _gcov.dep -DL_gcov -c 
/sata/dj/gnu/gcc/gcc/libgcc/../gcc/libgcov.c
/sata/dj/gnu/gcc/gcc/libgcc/../gcc/libgcov.c: In function '__gcov_init':
/sata/dj/gnu/gcc/gcc/libgcc/../gcc/libgcov.c:555: warning: left shift count >= 
width of type
/sata/dj/gnu/gcc/gcc/libgcc/../gcc/libgcov.c: In function 'gcov_exit':
/sata/dj/gnu/gcc/gcc/libgcc/../gcc/libgcov.c:532: error: invalid rtl sharing 
found in the insn
(insn 2148 2147 2149 104 /sata/dj/gnu/gcc/gcc/libgcc/../gcc/libgcov.c:373 
(parallel [
(set (subreg:HI (reg:SI 323) 0)
(ashift:HI (subreg:HI (reg:SI 323) 0)
(const_int 1 [0x1])))
(clobber (scratch:QI))
]) 219 {*shifthi} (expr_list:REG_EQUAL (ashift:HI (reg:HI 729 [ 
t_ix___558 ])
(const_int 1 [0x1]))
(nil)))
/sata/dj/gnu/gcc/gcc/libgcc/../gcc/libgcov.c:532: error: shared rtx
(subreg:HI (reg:SI 323) 0)
/sata/dj/gnu/gcc/gcc/libgcc/../gcc/libgcov.c:532: internal compiler error: 
internal consistency failure
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [_gcov.o] Error 1
make[2]: Leaving directory `/sata/dj/gnu/newlib/h8300-elf/h8300-elf/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/sata/dj/gnu/newlib/h8300-elf'
make: *** [all] Error 2

Re: h8/300 build failure

[Uros Bizjak]

Hello!


Anyone else seeing this on trunk?

if test -z "$objects"; then   \
  echo 'int __libgcc_eh_dummy;' > eh_dummy.c;\
  /sata/dj/gnu/newlib/h8300-elf/./gcc/xgcc 
-B/sata/dj/gnu/newlib/h8300-elf/./gcc/ -B/sata/dj/gnu/install/h8300-elf/bin/ 
-B/sata/dj/gnu/install/h8300-elf/lib/ -isystem 
/sata/dj/gnu/install/h8300-elf/include -isystem 
/sata/dj/gnu/install/h8300-elf/sys-include -g -O2 -O2  -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -DDF=SF -g  
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc 
-I/sata/dj/gnu/gcc/gcc/libgcc -I/sata/dj/gnu/gcc/gcc/libgcc/. 
-I/sata/dj/gnu/gcc/gcc/libgcc/../gcc -I/sata/dj/gnu/gcc/gcc/libgcc/../include  
-DHAVE_CC_TLS  -c eh_dummy.c\
 -o eh_dummy.o; \
  objects=eh_dummy.o;   \
fi; \
/sata/dj/gnu/install/h8300-elf/bin/ar  rc libgcc.a $objects
/sata/dj/gnu/install/h8300-elf/bin/ranlib libgcc.a
/sata/dj/gnu/newlib/h8300-elf/./gcc/xgcc -B/sata/dj/gnu/newlib/h8300-elf/./gcc/ 
-B/sata/dj/gnu/install/h8300-elf/bin/ -B/sata/dj/gnu/install/h8300-elf/lib/ 
-isystem /sata/dj/gnu/install/h8300-elf/include -isystem 
/sata/dj/gnu/install/h8300-elf/sys-include -g -O2 -O2  -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -DDF=SF -g  
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc 
-I/sata/dj/gnu/gcc/gcc/libgcc -I/sata/dj/gnu/gcc/gcc/libgcc/. 
-I/sata/dj/gnu/gcc/gcc/libgcc/../gcc -I/sata/dj/gnu/gcc/gcc/libgcc/../include  
-DHAVE_CC_TLS -o _gcov.o -MT _gcov.o -MD -MP -MF _gcov.dep -DL_gcov -c 
/sata/dj/gnu/gcc/gcc/libgcc/../gcc/libgcov.c
/sata/dj/gnu/gcc/gcc/libgcc/../gcc/libgcov.c: In function '__gcov_init':
/sata/dj/gnu/gcc/gcc/libgcc/../gcc/libgcov.c:555: warning: left shift count >= 
width of type
/sata/dj/gnu/gcc/gcc/libgcc/../gcc/libgcov.c: In function 'gcov_exit':
/sata/dj/gnu/gcc/gcc/libgcc/../gcc/libgcov.c:532: error: invalid rtl sharing 
found in the insn
(insn 2148 2147 2149 104 /sata/dj/gnu/gcc/gcc/libgcc/../gcc/libgcov.c:373 
(parallel [
(set (subreg:HI (reg:SI 323) 0)
(ashift:HI (subreg:HI (reg:SI 323) 0)
(const_int 1 [0x1])))
(clobber (scratch:QI))
]) 219 {*shifthi} (expr_list:REG_EQUAL (ashift:HI (reg:HI 729 [ 
t_ix___558 ])
(const_int 1 [0x1]))
(nil)))
/sata/dj/gnu/gcc/gcc/libgcc/../gcc/libgcov.c:532: error: shared rtx
(subreg:HI (reg:SI 323) 0)
/sata/dj/gnu/gcc/gcc/libgcc/../gcc/libgcov.c:532: internal compiler error: 
internal consistency failure


Can you please test attached patch?

Thanks,
Uros.
Index: h8300.c
===
--- h8300.c (revision 135265)
+++ h8300.c (working copy)
@@ -3668,7 +3668,8 @@ expand_a_shift (enum machine_mode mode, 
  gen_rtvec (2,
 gen_rtx_SET (VOIDmode, operands[0],
  gen_rtx_fmt_ee (code, mode,
- operands[0], 
operands[2])),
+ copy_rtx (operands[0]),
+ operands[2])),
 gen_rtx_CLOBBER (VOIDmode,
  gen_rtx_SCRATCH (QImode);
   return true;

Re: h8/300 build failure

[DJ Delorie]

Sorry, didn't help.

Re: gcc-get enabling-only subscription?

[Magnus Fromreide]

On tis, 2008-05-13 at 15:03 +0100, Joern Rennecke wrote:
> With my current email setup and the volume of the gcc mailing list,
> it is not desirable to be to be subscribed to the gcc mailing list,
> I rather read the web archives.

I have read the list like that for years.

> However, this does not allow to make a properly threaded reply.  I've
> tried to use gcc-get email interface, but apparently it will only send
> to subscribers.
> Is there a way to subscribe only for the purpose of being able to receive
> messages with the gcc-get mechanism, without getting regular list emails?

I tend to use the "Other Format: Raw Text" link and then sed the header
to undo the anti-address-harvester measures.

/MF

Re: Reviving old port

[Omar Torres]

Richard,
  Thanks a lot for the detailed explanation. I need some time to digest,
since this is my first experience doing a gcc backend port.

> Probably most of that was just telling you what you already knew, sorry.
Not really, I am new to most of these concepts. At this stage, this is
exactly the amount of details I am looking for. Thanks a lot for your
patience and level of detail.

> Good luck with the port,
>
> Richard

Regards,
-Omar

Re: RFH: Building and testing gimple-tuples-branch

[Diego Novillo]

On 5/12/08 1:21 PM, David Daney wrote:


For mipsel-linux:

http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg01055.html


Thanks.

The complete bootstrap/test cycle seems to be about 10% faster than on 
the trunk.  I didn't try to figure out why, although I can speculate 
that it is due to the fact that some optimization passes are still 
disabled and that tests that ICE prevent the corresponding execution 
test to be run.


Perhaps.  There are still some unconverted passes that are run by 
default (e.g., PRE).  That could explain the faster bootstrap times.  I 
will try to set up apples-to-apples comparisons between the branch and 
mainline in the next few days.



Although I didn't investigate, the FAILure in libjava/Array_3, usually 
indicate that exception handling is broken in some way.


OK, thanks.  EH has certainly given us no end of headaches.


Diego.

Supporting an instruction in the back-end - II

[Mohamed Shafi]

Hello all,

Will it be possible to write a pattern in the md file to support
setting/clearing a bit of a particular register?
The instructions are as follows:

clrb Rx, bitNo
setb Rx, bitNo

Could you point me to the back-ends that has support for this kind of
instructions?

Thanks for your time.

Regards,
Shafi.

Re: How to implement the instruction in the back end

[Mohamed Shafi]

On Fri, May 9, 2008 at 12:03 AM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> "Mohamed Shafi" <[EMAIL PROTECTED]> writes:
>
>  > For the 16-bit target that i porting now to gcc 4.1.2 doesn't have any
>  > branch instructions. It only has jump instructions. For comparison
>  > operation it has this instruction:
>  >
>  > if cond Rx Ry
>  >  execute this insn
>  >
>  > So compare and branch is implemented as
>  >
>  > if cond Rx Ry
>  >   jmp Label
>
>  For gcc's purposes this is no different from having a usual
>  conditional branch instruction.  It's just a jump with a condition.
>
>
>  > This instructions has also another form. To check whether a particular
>  > bit in a register is set or not.
>  >
>  > if bs Rx, bitNo
>  >  execute this insn
>  >
>  > My questions is how will i be able to implement this instruction in
>  > the back-end?
>
>  Sure, this is just a conditional instruction where the condition is a
>  ZERO_EXTRACT.
>
>  Look at the ARM backend for examples of how to work with conditional
>  instructions.

thanks for the pointer. In fact many back-ends have this, now that you
have showed me where to look
But it would of great help if you could tell the C statment that
actually invoked this type of pattern .. Maybe wrt some back-end?

Regards,
Shafi