> From: Paul Brook <[EMAIL PROTECTED]>
> On Monday 18 December 2006 01:15, Paul Schlie wrote:
>> Chris Lattner wrote:
>>> On Dec 17, 2006, at 12:40 PM, Rask Engelmann Lamberts wrote:
I seem unable to get a QImode shift instruction from this code:
unsigned char x;
void qis
Janis Johnson <[EMAIL PROTECTED]> wrote on 15/12/2006 03:12:44:
> Checks for vector instruction support are spreading throughout the
> testsuite. I'd like to pull the basic logic into a single place that
> can be referenced wherever it's needed. What's there now isn't always
> consistent and the
Jakub Jelinek wrote on 2006-11-20:
> I think you should use -pthread instead of -lpthread here (and put it into
> CFLAGS too temporarily), to make it more portable, or try all of nothing,
> -pthread and -lpthread, i.e. add a for loop trying to compile and run the
> program 3 times.
Here's a revise
The operand of the shift operator is of type unsigned int.
"x <<= c" is exactly the same as "((int)x) << c"
It doesn't matter whether the promotion is explicit or implicit, the
semantics
are the same.
According to C99, the operand of the shift operator should be "integer
type", which include
No. You're confusing some language you just invented with C.
The operand of the shift operator is of type unsigned int.
"x <<= c" is exactly the same as "((int)x) << c"
It doesn't matter whether the promotion is explicit or implicit,
the semantics
are the same.
((char)x) = ((char)( ((int)((c
Chris Lattner wrote:
Sorry, but you're incorrect. While it may be "logical" that shifting
a value left more bits than its size will give you zero, this is not
what C specifies.
I am puzzled, what exactly *does* C specify in this case? I reread
the thread, but it's not clear what the requi
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> I am building a GCC Compiler. I have some ifdef checks in the compiler
> source code. In case i define a symbolic literal in command line while
> compiling a sample program, I want that set of statements to be
> invoked after ifdef checks.
>
> e.g.
>
On Dec 18, 2006, at 9:24 AM, Robert Dewar wrote:
Chris Lattner wrote:
Sorry, but you're incorrect. While it may be "logical" that
shifting a value left more bits than its size will give you zero,
this is not what C specifies.
I am puzzled, what exactly *does* C specify in this case? I
Chris Lattner wrote:
C99 says:
The integer promotions are performed on each of the operands. The
type of the result is
that of the promoted left operand. If the value of the right operand
is negative or is
greater than or equal to the width of the promoted left operand, the
behavior is un
On Monday 18 December 2006 17:53, Robert Dewar wrote:
> Chris Lattner wrote:
> > C99 says:
> >
> > The integer promotions are performed on each of the operands. The
> > type of the result is
> > that of the promoted left operand. If the value of the right operand
> > is negative or is
> > greater t
On Dec 18, 2006, at 9:53 AM, Robert Dewar wrote:
Chris Lattner wrote:
C99 says:
The integer promotions are performed on each of the operands. The
type of the result is
that of the promoted left operand. If the value of the right
operand is negative or is
greater than or equal to the wid
On Mon, Dec 18, 2006 at 03:19:19AM +, Paul Brook wrote:
> Shifting >= the size of the value being shifted can and do give nonzero
> results on common hardware. Typically hardware will truncate the shift count.
> eg. x << 8 implemented with a QImode shift will give x, not 0.
This is not t
On Sun, Dec 17, 2006 at 09:40:15PM +0100, Rask Ingemann Lambertsen wrote:
>Similarily for m68k,
[cut]
> where
>
> move.l 4(%sp), %d1
> lsl.b %d1,x
> rts
>
> should have been generated.
I'm sorry, please forget that. 8-bit shifts are only supported on
register ope
On Mon, Dec 18, 2006 at 01:19:03PM +0200, Dorit Nuzman wrote:
> Janis Johnson <[EMAIL PROTECTED]> wrote on 15/12/2006 03:12:44:
> >
> > I seem to recall from long ago that some processors support generating,
> > and possibly running, multiple kinds of vector instructions.
>
> maybe you're thinking
Chris Lattner wrote:
It only retains the proper semantics when targeting a machine that
zeros the result of oversized left shifts. The original question was
about X86 codegen, which doesn't have this behavior, so it is not valid.
RIght, I see, though it can still be applied in some cases .
On 11/26/06, Denis Vlasenko <[EMAIL PROTECTED]> wrote:
On Saturday 18 November 2006 00:30, Shaun Jackman wrote:
> The following macro expands to some rather frightful code on the AVR:
>
> #define BSWAP_16(x) \
> x) >> 8) & 0xff) | (((x) & 0xff) << 8))
Sometimes gcc is generating better
Hi,
Every time I build a gcc for mingw, I get the same error as reported
here,
http://gcc.gnu.org/ml/gcc/2006-09/msg00044.html
Basically, I have to edit the Makefile in gcc/Makefile like this,
-ORIGINAL_LD_FOR_TARGET =
./C:/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../mingw32/bin/ld.exe
+OR
On Dec 18, 2006, at 10:19 AM, Rask Ingemann Lambertsen wrote:
On Mon, Dec 18, 2006 at 03:19:19AM +, Paul Brook wrote:
Shifting >= the size of the value being shifted can and do give
nonzero
results on common hardware. Typically hardware will truncate the
shift count.
eg. x << 8 implem
> I am puzzled, what exactly *does* C specify in this case? I reread
> the thread, but it's not clear what the requirement of the standard
> here is (as opposed to what programmers might or might not expect,
> or what hardware does or does not do).
It's undefined. Traditional implementations eith
Chris Lattner wrote:
Thus, the transformation is safe in this specific case on i386.
However, shifting a 32-bit value left by 33 bits would not be safe.
That's the case where the transformation IS safe, since shifting a
32-bit value left by 33 bits gives an undefined result as I understand
t
On 18 December 2006 19:31, Robert Dewar wrote:
> Chris Lattner wrote:
>
>> Thus, the transformation is safe in this specific case on i386.
>> However, shifting a 32-bit value left by 33 bits would not be safe.
>
> That's the case where the transformation IS safe, since shifting a
> 32-bit value
Hello all,
I'm preparing and testing SMS correction/improvements patch and while
testing it on the SPU with the vectorizer testcases I've got an ICE in
the "gcc_assert ( MAX_RECOG_OPERANDS - i)" in function copy_insn_1 in
emit_rtl.c. The call traces back to the loop versionioning called in
modul
> Hello all,
>
> I'm preparing and testing SMS correction/improvements patch and while
> testing it on the SPU with the vectorizer testcases I've got an ICE in
> the "gcc_assert ( MAX_RECOG_OPERANDS - i)" in function copy_insn_1 in
> emit_rtl.c. The call traces back to the loop versionioning call
I just noticed what looks like an anomaly in the gfortran testsuite.
All of the tests that have "dg-do compile" headers are only being
compiled once, with an empty "-O" option, rather than iterating over the
usual list of -O1, -O2, -O3, etc.
(This is, I note, also what's happening with advance
Brooks,
Is this the expected/desired behavior for "dg-do compile"?
I had always thought so :-)
Paul
Paul Thomas wrote:
Brooks,
Is this the expected/desired behavior for "dg-do compile"?
I had always thought so :-)
and Steve Kargl wrote in the "Fix PR 30235" thread on fortran@:
It's my understanding the "dg-do compile" in the gfortran
testsuite should only run once. It is normally used to
On 18 Dec 2006 at 11:28, Shaun Jackman wrote:
> On 11/26/06, Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> > On Saturday 18 November 2006 00:30, Shaun Jackman wrote:
> > > The following macro expands to some rather frightful code on the AVR:
> > >
> > > #define BSWAP_16(x) \
> > > x) >> 8)
On 12/18/06, Anton Erasmus <[EMAIL PROTECTED]> wrote:
Hi,
Not a macro, but the following seems to generate reasonable code.
...
Thanks Anton,
I came to the same conclusion.
Cheers,
Shaun
static inline uint16_t bswap_16_inline(uint16_t x)
{
union {
uint16_t x;
On 12/18/06, David VanHorn <[EMAIL PROTECTED]> wrote:
Am I missing something here?
Why not pop to assembler, push the high, push the low, pop the high, pop the
low?
* Inline assembler cannot be used at compile time, for example to
initialize a static variable.
* If the swap function is called
Hi,
and it is possible to use an anonymous struct:
static inline uint16_t bswap_16_inline(uint16_t x)
{
union {
uint16_t x;
struct {
uint8_t a, b;
};
} in, out;
in.x = x;
out.a = in.b;
out.b = in.a;
return out.x;
}
Regards,
Nils
On Mon, Dec 18, 2006 at 02:29:46PM -0800, Brooks Moses wrote:
>
> Elsewhere in the testsuite, I see that we have one "dg-do assemble" and
> one "dg-do link", which I presume will generate the object code and link
> it, respectively, yes?
>
Until now, I did not know of these dg-do arguments. I
On 12/18/06, Nils Springob <[EMAIL PROTECTED]> wrote:
Hi,
and it is possible to use an anonymous struct:
True. However, unnamed struct/union fields are an extension of the C
language provided by GCC and not strictly portable. It is a nice
feature though. It would be nice if it crept its way in
Paolo --
The GCC SC has appointed you as a co-maintainer of the build machinery.
Please add an appropriate MAINTAINERS entry.
Congratulations, and thank you for accepting this position!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
[ Please see http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/8152
http://www.ginac.de/pipermail/cln-list/2006-December/000259.html ]
Hello Paul, all,
Let's forward your comments and questions to the GCC list, I wasn't
aware of this topic being so disruptive:
* Paul Eggert wrote on Tue, Dec
On Tue, 2006-12-19 at 06:54 +0100, Ralf Wildenhues wrote:
> > Wheeeoo! That optimization is going to break a _lot_ of GNU
> > software. (Silently. Oh my.)
Just like say strict aliasing? :)
> > We tried to do that sort of optimization in the 1990s (back when I
> > was a GCC contributor), but r
Andrew Pinski wrote:
On Tue, 2006-12-19 at 06:54 +0100, Ralf Wildenhues wrote:
[quoting Paul Eggert]
Surely the GCC guys care about LIA-1. After all, gcc has an
-ftrapv option to enable reliable signal generation on signed
overflow. But I'd rather not go the -ftrapv route, since that
will cau
36 matches
Mail list logo
