> The standards did not leave this open. They define precisely what is
> supposed to happen.
>
Really? I'll have to drop this whole lobbying effort then. That
makes me sad that they didn't define it to be comparing of the numbers
where there are overlaps in signed and unsigned instead of causin
J Decker writes:
> Can the severity of signed/unsigned comparisons be raised, since GCC
> does not properly handle the comparisons.
GCC properly handles the comparisons according to the rules laid down in
the C/C++ language standards.
> int main()
>
> {
> int s = -2;
> unsigned int
Can the severity of signed/unsigned comparisons be raised, since GCC
does not properly handle the comparisons.
Every example below is false compiled with gcc 4.5.0
int main()
{
int s = -2;
unsigned int u = 0xFFFDU;
if( s < u )
printf( "okay\n" );
On Sun, Sep 26, 2010 at 06:09:34PM -0700, ir_idjit wrote:
> i can seem to get this to work:
>
> #define PREFIX "p_"
> #define HIGHER_INTERFACE(id) LOWER_INTERFACE(PREFIX, id)
>
> #define LOWER_INTERFACE(prefix, id) struct prefix##id \
> { \
> int i; \
> }
>
> int main(void)
> {
> HIG
drives me crazy that i can't get his to work
--
View this message in context:
http://old.nabble.com/passing--define-d-values-to--define-d-macros-tp29815182p29815215.html
Sent from the gcc - Dev mailing list archive at Nabble.com.
i can seem to get this to work:
#define PREFIX "p_"
#define HIGHER_INTERFACE(id) LOWER_INTERFACE(PREFIX, id)
#define LOWER_INTERFACE(prefix, id) struct prefix##id \
{ \
int i; \
}
int main(void)
{
HIGHER_INTERFACE(0);
/* test if struct declaration went well: */
struct p_0 var;
Hi. You know, gmp/mpfr/mpc are a significant
portion of building any frontend/backend.
So I looked at it.
mpc of course is only for complex numbers.
Our frontend doesn't use them.
Maybe only for "builtins" as well.
#define do_mpc_arg1(a, b, c) NULL_TREE
and such.
mpfr appears to be used fo
Snapshot gcc-4.3-20100926 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100926/
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
On Sun, Sep 26, 2010 at 04:47:29PM +0200, Tobias Burnus wrote:
> Hello all,
>
> given the optimization work which has gone into 4.6, I thought I would
> run the Polyhedron Fortran test suite.
I was interested in seeing how 4.6 stacks up against previous
versions of gfortran. On x86_64-*-freebs
Hello all,
given the optimization work which has gone into 4.6, I thought I would
run the Polyhedron Fortran test suite. The system is
- Intel Core2 Duo CPU E8400 @ 3.00GHz
- CentOS release 5.5 (Final) [x86-64]
Tested compilers:
- GCC 4.6 (recent nightly build)
- Intel Fortran compiler (if
On Sun, 26 Sep 2010, FX wrote:
> How can we fix this? The only way I see would be to have two macros
> instead of TARGET_OS_CPP_BUILTINS: one that will be used for
> source-preprocessing in all languages (maybe keeping the name
> TARGET_OS_CPP_BUILTINS), and one that will be used only for C-fam
On Sun, Sep 26, 2010 at 4:21 PM, FX wrote:
> How can we fix this? The only way I see would be to have two macros
> instead of TARGET_OS_CPP_BUILTINS: one that will be used for source-
> preprocessing in all languages (maybe keeping the name
> TARGET_OS_CPP_BUILTINS), and one that will be used only
Hi all,
I'm trying to see a way forward for PR 42954: when preprocessing Fortran source
files, we used to call the C preprocessor and run the Fortran compiler on the
generated file. We now use libcpp directly, but by doing so, we have lost a
good number of target-dependent CPP builtins that are
On Fri, 10 Sep 2010, Steven Bosscher wrote:
>> The docs say...
>>
>> @item -Os
>> @opindex Os
>> Optimize for size. �...@option{-os} enables all @option{-O2} optimizations
>> that
>> do not typically increase code size. It also performs further
>> optimizations designed to reduce code size.
>>
>>
14 matches
Mail list logo
