Claus-Justus Heine <[EMAIL PROTECTED]> writes:
> (signed long) = (signed int) x (unsigned int)
>
> Surprisingly the sign is not promoted in this case:
>
> a = -1 * 20, then a = 0x ffec
>
> IMHO, this is a bug.
No, it isn't. In this context, -1 is converted to unsigned, yielding
0xff
Etienne Lorrain <[EMAIL PROTECTED]> writes:
> Shall I enter that on Bugzillia or is that a known problem?
You should always enter it on bugzilla, if you cannot find this out
for yourself. We have highly trained professionals who will swiftly
close duplicate bug reports, and that way the report
Michael Veksler <[EMAIL PROTECTED]> writes:
> So maybe introduce a -fsigned-wraps flag, that the user can use
> to make 'int' wrap even in loops.
We have that already, it's called "-fwrapv".
--
Falk
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> Does -ftrapv ever take advantage of trapping instructions where the
> hardware has them available?
Yes, for example Alpha.
> Does anyone make substantial use of -ftrapv in production
There are rarely bug reports about it; for example pointer diffe
"Julio Garvia Honrado" <[EMAIL PROTECTED]> writes:
> I am trying to compile a C++ program (with cxx - Compaq compiler)
> that uses a C++ shared library (compiled with g++), but several
> 'unresolved' messages are reported.
>
> Is there any way to solve this incidence?
No, the two compilers are in
Dan Kegel <[EMAIL PROTECTED]> writes:
> Likewise, compiling that version of gcc for alpha
> dies while building the linux kernel, but for a different reason:
>
> {standard input}:496: Error: macro requires $at register while noat in effect
> make[1]: *** [arch/alpha/kernel/core_cia.o] Error 1
Thi
Dan Kegel <[EMAIL PROTECTED]> writes:
> Can somebody familiar with inline assembly guess whether the source
> or the compiler are wrong here?
>
> --- snip ---
> inline unsigned int
> cia_bwx_ioread8(void *a)
> {
> return ({ unsigned char __kir; __asm__("ldbu %0,%1" : "=r"(__kir) :
> "m"(*(volat
"Dave Korn" <[EMAIL PROTECTED]> writes:
>>From: Joe Buck
>>
>> there are no uninitialized variables, as the address of k is
>> perfectly well defined.
>
> Indeed so, but I think Sylvester's point is that given that foo
> takes a const pointer, the compiler could theoretically know that
> foo ca
Erik Trulsson <[EMAIL PROTECTED]> writes:
> On Tue, Jul 12, 2005 at 03:08:54PM -0700, Joe Buck wrote:
>> On Tue, Jul 12, 2005 at 11:42:23PM +0200, Erik Trulsson wrote:
>> > Pointer subtraction is only well defined if both pointers point to elements
>> > in the same array (or one past the end of th
Joe Buck <[EMAIL PROTECTED]> writes:
> On Wed, Jul 13, 2005 at 12:38:11AM +0200, Falk Hueffner wrote:
>> Erik Trulsson <[EMAIL PROTECTED]> writes:
>> > I believe most C compilers support it in practice, but few, if any, have
>> > actually documented it
Richard Henderson <[EMAIL PROTECTED]> writes:
> I've got no interest in reading a thread with 250 messages wherein
> language lawyers battle it out in a no-holds-barred grudge match.
> Would someone like to summarize, preferably with a test case that
> one side assumes to be miscompiled?
Case 1:
Shaun Jackman <[EMAIL PROTECTED]> writes:
> In a typical Ethernet/IP ARP header the source IP address is
> unaligned. Instead of using...
> out->srcIPAddr = in->dstIPAddr;
> ... I used...
> memcpy(&out->srcIPAddr, &in->dstIPAddr, sizeof(uint32_t));
> ... to account for the unaligned de
Hi,
I'm trying to implement a tree pass that warns about bad array
accesses as suggested for PR 8268 by Jeff Law. However, I have trouble
with the following:
char digit_vector[5];
const char *ggc_alloc_string(int length) {
return digit_vector + ((length - 17) * 2);
}
this translates to:
ggc
Kean Johnston <[EMAIL PROTECTED]> writes:
>> A common situation would be:
>> if (condition) {
>> flag = 1
>> msg = "Hello World";
>> } else
>> flag = 0; [1]
>> ...
>> if (flag)
>> printf ("I say, %s\n", m
Andrew Pinski <[EMAIL PROTECTED]> writes:
> If we look at this testcase, we have a function like:
> int foo(unsigned short x)
> {
> unsigned short y;
> y = x > 32767 ? x - 32768 : 0;
> return y;
> }
>
>
> x is promoted to a signed int by the front-end as the type
> of 32768 is signed. So wh
Sulabh Nangalia <[EMAIL PROTECTED]> writes:
> 5 < 10 ? a = 5 : a = 7; is giving error
> 15 < 10 ? a = 5 : a = 7; is not giving any error
>
> why?
Because of a bug in gcc. It's been fixed in 4.0, though.
--
Falk
Greg McGary <[EMAIL PROTECTED]> writes:
> I'm working on a port that has instructions to move bits between
> 64-bit floating-point and 64-bit general-purpose regs. I say "bits"
> because there's no conversion between float and int: the bit pattern
> is unaltered. Therefore, it's possible to use
Roger Sayle <[EMAIL PROTECTED]> writes:
> [...] the patch below removes the TREE_CONSTANT_OVERFLOW checks from
> integer_zerop, integer_onep, and friends in tree.c.
Incidentally, this fixes PR 26729.
--
Falk
Olivier Galibert <[EMAIL PROTECTED]> writes:
> I need to be able to do unaligned memory accesses to memory in
> big-endian or little-endian mode. For portability, I'd like to do it
> in pure C, but I'd like the compiler to generate optimal sequences for
> the operations.
It's probably not feasib
Mike Frysinger <[EMAIL PROTECTED]> writes:
> i was trying to cross-compile glibc-2.4 with gcc-4.1.1 when it failed on me
> while building ioperm.c ... poking around a bit, looks like the same issue
> discussed here:
> http://gcc.gnu.org/ml/gcc/2005-07/msg00371.html
> however, this seems to have
Mike Frysinger <[EMAIL PROTECTED]> writes:
> On Saturday 15 July 2006 05:12, Falk Hueffner wrote:
>> The cheap fix is to have gcc not emit .arch ev4. I was planning on
>> testing and submitting the following patch for this, but gcc didn't
>> bootstrap for a few day
21 matches
Mail list logo
