On x86 processors, I think bitwise operators should be optimized for
individual bit accesses, which should be converted to BT instructions.
For example:
x |= 1<
On Sun, Jan 10, 2010 at 06:24:14PM +, Dave Korn wrote:
> Eric Botcazou wrote:
> >> The aliasing rules treat "char" specially because char is a bit like a
> >> "poor main's void".
> >
> > Not symmetrically though, only for the type of the lvalue expression used
> > to
> > access the object (C
On Sun, Jan 10, 2010 at 10:36 PM, Andrew Hutchinson
wrote:
>
>
> Kai Tietz wrote:
>>
>> Well, open call there aren't that much but point of interest is in
>> 'c-pch.c: fd = open (name, O_RDONLY | O_BINARY, 0666);' as it uses
>> O_BINARY, too. See also for pattern in libiberty mkstemps.c
>>
>> Reg
Snapshot gcc-4.3-20100110 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100110/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Kai Tietz wrote:
Well, open call there aren't that much but point of interest is in
'c-pch.c: fd = open (name, O_RDONLY | O_BINARY, 0666);' as it uses
O_BINARY, too. See also for pattern in libiberty mkstemps.c
Regards,
Kai
It looks like O_BINARY is already defined in system.h, so all
2010/1/10 Kai Tietz :
> 2010/1/10 Andrew Hutchinson :
>>
>>
>> Kai Tietz wrote:
>>>
>>> Well, on linux (libc) fopen/freopen/etc the "b" is an nop (but
>>> handled). For O_BINARY the common approach here is to do the following
>>> condifition before use:
>>>
>>> #ifndef O_BINARY
>>> #define O_BINARY
2010/1/10 Andrew Hutchinson :
>
>
> Kai Tietz wrote:
>>
>> Well, on linux (libc) fopen/freopen/etc the "b" is an nop (but
>> handled). For O_BINARY the common approach here is to do the following
>> condifition before use:
>>
>> #ifndef O_BINARY
>> #define O_BINARY 0
>> #endif
>>
>> This is a patte
Kai Tietz wrote:
Well, on linux (libc) fopen/freopen/etc the "b" is an nop (but
handled). For O_BINARY the common approach here is to do the following
condifition before use:
#ifndef O_BINARY
#define O_BINARY 0
#endif
This is a pattern pretty often used. To rely here on binmode.o is a
way, t
2010/1/10 Andrew Hutchinson :
> I think "rb" is nop. However, O_BINARY is less portable.
>
> There is another way. If MinGW hosted build is linked with binmode.o - the
> default for files become binary
> Some other methods are here:
>
> http://oldwiki.mingw.org/index.php/binary
>
>
>
>
> Rafael
I think "rb" is nop. However, O_BINARY is less portable.
There is another way. If MinGW hosted build is linked with binmode.o -
the default for files become binary
Some other methods are here:
http://oldwiki.mingw.org/index.php/binary
Rafael Espindola wrote:
I hacked fopen/open calls i
> I hacked fopen/open calls in lto.c and lto-elf.c to use O_BINARY and "rb"
> and compilation with -flto was then successful!
>
> I am not sure how this should be fixed properly.
Using O_BINARY and "rb" should be a nop on unix, no? Is it wrong to
use them on any arch we care about?
> Andy
Cheer
Eric Botcazou wrote:
>> Yes, fair enough; but properties can commute just as much as operators
>> can (although it's perhaps less intuitively surprising when they don't).
>
> To be picky, binary operators are commutative (or not), binary relations are
> symmetric (or not).
Ah, I wasn't awar
> Yes, fair enough; but properties can commute just as much as operators
> can (although it's perhaps less intuitively surprising when they don't).
To be picky, binary operators are commutative (or not), binary relations are
symmetric (or not).
--
Eric Botcazou
Andreas Schwab wrote:
> Dave Korn writes:
>
>> Andreas, you wrote: "Aliasing is not symmetric". To be precise, we're
>> saying it's not commutative here; that (A aliases B) does not imply (B
>> aliases
>> A)? I don't think I've ever heard it expressed that explicitly before.
>
> Aliasing is
Dave Korn writes:
> Andreas, you wrote: "Aliasing is not symmetric". To be precise, we're
> saying it's not commutative here; that (A aliases B) does not imply (B aliases
> A)? I don't think I've ever heard it expressed that explicitly before.
Aliasing is not an operator, it's a property of
Eric Botcazou wrote:
>> The aliasing rules treat "char" specially because char is a bit like a
>> "poor main's void".
>
> Not symmetrically though, only for the type of the lvalue expression used to
> access the object (C99 6.5.7).
>
Ok. So if I had four ints, and I wanted to cast the pointe
On Sun, Jan 10, 2010 at 08:58:47AM -0800, Patrick Horgan wrote:
> Andrew Haley wrote:
> > On 01/10/2010 12:39 PM, Andreas Schwab wrote:
> >
> >> Andrew Haley writes:
> >>
> >>
> >>> Why do you say the effective type is different?
> >>>
> >> The object type is uint8_t, but accessed a
Andrew Haley wrote:
> On 01/10/2010 02:39 PM, Paul Koning wrote:
>>> ...
>>> typedef unsigned char uint8_t;
>>> typedef unsigned int uint32_t;
>>>
>>> struct in6_addr
>>> {
>>> uint8_t __s6_addr[16];
>>> };
>>>
>>> static inline int
>>> address_in_use (unsigned char *a, struct in6_addr *in6)
>>>
Patrick Horgan wrote:
> Andrew Haley wrote:
>> On 01/10/2010 12:39 PM, Andreas Schwab wrote:
>>
>>> Andrew Haley writes:
>>>
>>>
Why do you say the effective type is different?
>>> The object type is uint8_t, but accessed as uint32_t. That is
>>> undefined.
>>>
>>
>> U
2010/1/10 swati raina:
>
> I am tried to debug gcc using the following commands
>
> 1)[sw...@localhost ~]$ gdb --args /usr/bin/gcc
See http://gcc.gnu.org/wiki/DebuggingGCC
On Sun, 10 Jan 2010, Patrick Horgan wrote:
> But in the new compilers it's an integer type, not a character type--from the
> spec:
signed char is a signed integer type, and unsigned char is an unsigned
integer type. (char is neither, although it behaves the same as one of
signed char and unsig
On 01/10/2010 04:58 PM, Patrick Horgan wrote:
> Andrew Haley wrote:
>> On 01/10/2010 12:39 PM, Andreas Schwab wrote:
>>
>>> Andrew Haley writes:
>>>
Why do you say the effective type is different?
>>> The object type is uint8_t, but accessed as uint32_t. That is
>>> undefined.
Hi,
I want to detect simple 'if-else' statements for which i need to understand the
source code of gcc. I am using version 4.4.0.
So,
I am tried to debug gcc using the following commands
1)[sw...@localhost ~]$ gdb --args /usr/bin/gcc
Missing separate debuginfos, use: debuginfo-install gcc-4.4.0
Andrew Haley wrote:
On 01/10/2010 12:39 PM, Andreas Schwab wrote:
Andrew Haley writes:
Why do you say the effective type is different?
The object type is uint8_t, but accessed as uint32_t. That is
undefined.
Unless uint8_t is a character type, as I understand it. That
On 01/10/2010 02:39 PM, Paul Koning wrote:
>> ...
>> typedef unsigned char uint8_t;
>> typedef unsigned int uint32_t;
>>
>> struct in6_addr
>> {
>> uint8_t __s6_addr[16];
>> };
>>
>> static inline int
>> address_in_use (unsigned char *a, struct in6_addr *in6)
>> {
>> if const uint32_t *)(a
> The aliasing rules treat "char" specially because char is a bit like a
> "poor main's void".
Not symmetrically though, only for the type of the lvalue expression used to
access the object (C99 6.5.7).
--
Eric Botcazou
> ...
> typedef unsigned char uint8_t;
> typedef unsigned int uint32_t;
>
> struct in6_addr
> {
> uint8_t __s6_addr[16];
> };
>
> static inline int
> address_in_use (unsigned char *a, struct in6_addr *in6)
> {
> if const uint32_t *)(a))[0]
> == ((const uint32_t *)(in6->__
> ...
> >> The object type is uint8_t, but accessed as uint32_t. That is
> >> undefined.
> >
> > Unless uint8_t is a character type, as I understand it.
>
> In which way does it make a difference? For aliasing consideration,
> only the type of access matters.
The aliasing rules treat "char" spe
Andrew Haley writes:
> On 01/10/2010 12:39 PM, Andreas Schwab wrote:
>> Andrew Haley writes:
>>
>>> Why do you say the effective type is different?
>>
>> The object type is uint8_t, but accessed as uint32_t. That is
>> undefined.
>
> Unless uint8_t is a character type, as I understand it.
In
I have just succeed in building last snapshot version 4.5.0 20100107 for
AVR target with working LTO on both LINUX and MinGW hosts!
As noted before #define LINKER_NAME has to be deleted from target avr.h
(I will raise patch for this)
I also built avr target for MINGW under MSYS and this has
On 01/10/2010 12:39 PM, Andreas Schwab wrote:
> Andrew Haley writes:
>
>> Why do you say the effective type is different?
>
> The object type is uint8_t, but accessed as uint32_t. That is
> undefined.
Unless uint8_t is a character type, as I understand it. That is
clearly the assumption on wh
Andrew Haley writes:
> Why do you say the effective type is different?
The object type is uint8_t, but accessed as uint32_t. That is
undefined.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something co
Hi,
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01459.html
This do the problem when compile ffmpeg.all gcc Versions that contain the
Patch fail
-m68020 -m68881 -O1 ("Abort trap")
but work when do
-m68020 -m68881 -O1 -fno-tree-ccp -fno-tree-dominator-opts (works ok).
.See here for more about t
On 01/10/2010 10:30 AM, Andreas Schwab wrote:
> Dave Korn writes:
>
>> Is that really right? The type of the pointer (in6->__s6_addr) that we're
>> casting is unsigned char *, so shouldn't it already alias everything anyway
>> and dereferencing it be allowed, like it is for the casted (a)? I'
Dave Korn writes:
> Is that really right? The type of the pointer (in6->__s6_addr) that we're
> casting is unsigned char *, so shouldn't it already alias everything anyway
> and dereferencing it be allowed, like it is for the casted (a)? I'll file a
> PR if so. (I can't pretend I find the la
On Sun, 10 Jan 2010 00:31:56 +0100, Nenad Vukicevic wrote:
...
> <1><54>: Abbrev Number: 4 (DW_TAG_variable)
> <55> DW_AT_name: (indirect string, offset: 0x38): x
> <59> DW_AT_decl_file : 1
> <5a> DW_AT_decl_line : 1
> <5b> DW_AT_type: <0x4d>
> <5f> DW_AT_external
36 matches
Mail list logo
