Andrew Pinski <[EMAIL PROTECTED]> writes:
> On Jan 21, 2006, at 1:09 PM, Andreas Jaeger wrote:
>
>> On Sat, Jan 21, 2006 at 12:42:24PM -0500, Andrew Pinski wrote:
>>>
>>> On Jan 21, 2006, at 12:38 PM, Andreas Jaeger wrote:
>>>
I'm still seeing this with current Subversion. Anybody else
At first glace it seems that the .c variants represents hand optimized
C code, which get's never called. I'm quite convinced that it should
be just removed, since it's never used due to overschadowing by the .h
variant
You need the .c variant for the cases where inlining cannot be
>
>
> On 2006-01-22, at 04:17, Andrew Pinski wrote:
>
> >>
> >> OK. Looking closer I have just found that in gcc/toplev.c
> >>
> >> #if GCC_VERSION < 3004
> >> ...
> >> #endif
> >>
> >> Is missing around the floor_log2() and exact_log2() functions.
> >
> > You are mssing the fact that the ones i
On 2006-01-22, at 04:17, Andrew Pinski wrote:
OK. Looking closer I have just found that in gcc/toplev.c
#if GCC_VERSION < 3004
...
#endif
Is missing around the floor_log2() and exact_log2() functions.
You are mssing the fact that the ones in the headers are declared
as extern inline.
Yes
>
> OK. Looking closer I have just found that in gcc/toplev.c
>
> #if GCC_VERSION < 3004
> ...
> #endif
>
> Is missing around the floor_log2() and exact_log2() functions.
You are mssing the fact that the ones in the headers are declared
as extern inline.
-- Pinski
OK. Looking closer I have just found that in gcc/toplev.c
#if GCC_VERSION < 3004
...
#endif
Is missing around the floor_log2() and exact_log2() functions.
Andrew Pinski wrote:
> I noticed today that there were three projects which were merged into
> the mainline within a 24 hour period yesterday.
>
> Date: Thu, 19 Jan 2006 01:42:49 - IAB - Daniel Berlin
> Date: Thu, 19 Jan 2006 10:24:04 - Vect - Dorit
> Date: Thu, 19 Jan 2006 16:55:54 -00
Looking at gcc/toplev.h and gcc/toplev.c I have found the following
two variants of the same
function once in the header and once in the definition fine.
extern inline int
floor_log2 (unsigned HOST_WIDE_INT x)
{
return x ? HOST_BITS_PER_WIDE_INT - 1 - (int) CLZ_HWI (x) : -1;
}
and again the
"Dave Korn" <[EMAIL PROTECTED]> writes:
> I think he's saying that _this_ one might generate invalid code:
>
> void test(void)
> {
> union { int i; double d; } u;
> int *ip;
> double *dp;
> int ii;
> double dd;
>
> dp = &u.d;
> ip = &u.i;
[EMAIL PROTECTED] (Kai Henningsen) writes:
> ian@airs.com (Ian Lance Taylor) wrote on 20.01.06 in <[EMAIL PROTECTED]>:
>
> > When dealing with unions, you can take pointers to different fields in
> > the unions. If the fields have different types, these pointers can
> > have non-conflicting ali
Kai Henningsen wrote:
> ian@airs.com (Ian Lance Taylor) wrote on 20.01.06 in
> <[EMAIL PROTECTED]>:
>
>> When dealing with unions, you can take pointers to different fields in
>> the unions. If the fields have different types, these pointers can
>> have non-conflicting alias sets. Therefore wi
Uttam Pawar wrote:
> Hi All,
>
> I found following code snippet in file, trunk/gcc/loop-unroll.c
>
>1814 /* Locate in EXPR the expression corresponding to the location
>recorded 1815in IVTS, and return a pointer to the RTX for this
>location. */ 1816
>1817 static rtx *
>1
DJ Delorie wrote:
> Why are one-bit bitfields not allowed? I'm trying to support a
> BSET/BCLR pair that *only* support single bit fields, for I/O ports,
> which are always volatile (and thus you have to use insv, as gcc won't
> do a "or #1,port5" if port5 is volatile).
;) Of course, you could
On Jan 21, 2006, at 9:01 AM, Travis Athougies wrote:
with gcc-3.3.2 i get this error when building a cross-compiler:
You need an i386-elf (your cross target) assembler installed in your
path.
-eric
Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| > See -Walways-true.
|
| gcc-4.1.0-0.20051206r108118 doesn't know this option.
| Is it newer or in some unofficial patch?
GCC-4.2.0.
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#i
>
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> > Well this warning just found a bug in GCC's code where we had an enum and
> > that enum was stored in a bitfield but the bitfield did not span the
> > whole enum so we get this warning.
>
> Couldn't this be detected when the enum is stored in t
Andrew Pinski <[EMAIL PROTECTED]> writes:
> Well this warning just found a bug in GCC's code where we had an enum and
> that enum was stored in a bitfield but the bitfield did not span the
> whole enum so we get this warning.
Couldn't this be detected when the enum is stored in the bitfield?
> S
Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> writes:
| Hello.
|
| There was a discussion about this warning about a year ago, but it
| seems to have been forgotten without a resolution.
|
| This warning is issued unconditionally, impossible to disable, hard
| to work around, and it depends on i
>
> Hello.
>
> There was a discussion about this warning about a year ago, but it
> seems to have been forgotten without a resolution.
>
> This warning is issued unconditionally, impossible to disable, hard
> to work around, and it depends on integer sizes even when the code
> is portable.
Well
Hello.
There was a discussion about this warning about a year ago, but it
seems to have been forgotten without a resolution.
This warning is issued unconditionally, impossible to disable, hard
to work around, and it depends on integer sizes even when the code
is portable.
I think it should be re
"John David Anglin" <[EMAIL PROTECTED]> writes:
> > No, the ISO C standard is clear that the value of an uninitialized
> > variable is indeterminate. It may be a trap representation, or it may
> > be an unspecified value. In the latter case it must have the correct
> > type. But there is no oth
ian@airs.com (Ian Lance Taylor) wrote on 20.01.06 in <[EMAIL PROTECTED]>:
> When dealing with unions, you can take pointers to different fields in
> the unions. If the fields have different types, these pointers can
> have non-conflicting alias sets. Therefore within a single union the
> same m
On Jan 21, 2006, at 1:09 PM, Andreas Jaeger wrote:
On Sat, Jan 21, 2006 at 12:42:24PM -0500, Andrew Pinski wrote:
On Jan 21, 2006, at 12:38 PM, Andreas Jaeger wrote:
I'm still seeing this with current Subversion. Anybody else having
the same problem on x86-64? It fails for me on the two
> No, the ISO C standard is clear that the value of an uninitialized
> variable is indeterminate. It may be a trap representation, or it may
> be an unspecified value. In the latter case it must have the correct
> type. But there is no other restriction on it, and the standard
> specifically say
On Sat, Jan 21, 2006 at 12:42:24PM -0500, Andrew Pinski wrote:
>
> On Jan 21, 2006, at 12:38 PM, Andreas Jaeger wrote:
>
> >
> >I'm still seeing this with current Subversion. Anybody else having
> >the same problem on x86-64? It fails for me on the two systems I
> >tested it on,
>
> What rever
Snapshot gcc-4.2-20060121 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060121/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Sat, Jan 21, 2006 at 12:42:24PM -0500, Andrew Pinski wrote:
>
> On Jan 21, 2006, at 12:38 PM, Andreas Jaeger wrote:
>
> >
> >I'm still seeing this with current Subversion. Anybody else having
> >the same problem on x86-64? It fails for me on the two systems I
> >tested it on,
>
> What rever
On Jan 21, 2006, at 12:38 PM, Andreas Jaeger wrote:
I'm still seeing this with current Subversion. Anybody else having
the same problem on x86-64? It fails for me on the two systems I
tested it on,
What reversion is this on?
This worked for me on 110050 and 110059.
Thanks,
Andrew Pinski
iadic-macros -Wold-style-definition
> -Wmissing-format-attribute -Werror -version -fno-common -o insn-recog.s -dm
> GNU C version 4.2.0 20060121 (experimental) (x86_64-suse-linux-gnu)
> compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE Linux).
> GGC heuristics: -
with gcc-3.3.2 i get this error when building a cross-compiler:
/home/Owner/src/build/gcc/gcc
/xgcc -B/home/Owner/src/build/gcc/gcc/
-B/usr/bin/cross/i386-elf/i386-elf/bin/
-B/usr/bin/cross/i386-elf/i386-elf/lib/ -isystem
/usr/bin/cross/i386-elf/i386-elf/include -O2 -DIN_GCC -DCROSS_COMPILE
-W -
On Sat, 2006-01-21 at 15:33 +0100, Jan Hubicka wrote:
> > One way to avoid this restriction would be to extend RTL alias
> > analysis to not be strictly type based. In particular, we could
> > extend it to know that a particular stack slot has a range of alias
> > sets. And we would then have to
> One way to avoid this restriction would be to extend RTL alias
> analysis to not be strictly type based. In particular, we could
> extend it to know that a particular stack slot has a range of alias
> sets. And we would then have to know whether a particular pointer
> could possibly point to th
On Sat, 21 Jan 2006, Georg Steffers wrote:
> if i compile this with my gcc (GCC) 3.3.4 (pre 3.3.5 20040809) i got the
3.3.x is old and no longer maintained, try using 3.4.x or later.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
DJ Delorie wrote:
> This seems to have gotten forgotten:
>
>
>>Date: Wed, 14 Dec 2005 21:12:20 -0500
>>From: DJ Delorie <[EMAIL PROTECTED]>
>>CC: gcc@gcc.gnu.org, ian@airs.com
>
>
>>It seems like the very next thing it does is generate and emi
Hello!
The ssp check (gcc_cv_libc_provides_ssp) is glibc centric and the
ssp implementation itself assumes that if ssp is provided by libc/ld
combo, then the guard is for sure set up in TLS.
What would be an acceptable way to provide support for non-glibc/non-TLS?
1. provide 2 configure option
Hi,
i just played around a little with wchar_t. I am not sure, but i think
i got a warning that did not make any sense at all. Here's the small
test:
#include
#include
#include
int
main (void)
{
wchar_t a = L'©'; /* The copyright sign */
setlocale (LC_ALL, "");
printf ("c
iadic-macros -Wold-style-definition
-Wmissing-format-attribute -Werror -version -fno-common -o insn-recog.s -dm
GNU C version 4.2.0 20060121 (experimental) (x86_64-suse-linux-gnu)
compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE Linux).
GGC heuristics: --param ggc-min-expand=30 --para
37 matches
Mail list logo
