[Bug c/54823] New: string literal characters not constant

2012-10-05 Thread devel at fresse dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54823



 Bug #: 54823

   Summary: string literal characters not constant

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: de...@fresse.org





this:



int main(void)

{

  int c = * ;

  printf(%x\n, c);

  return 0;

}



results in (the constant expression):



 movl$32, %eax



But this:



int main(void)

{

  enum {foo = * };

  printf(%x\n, foo);

  return 0;

}



gives

error: enumerator value for 'foo' is not an integer constant.



Whereas icc for instance just accepts the second form as constant integer

expression.


[Bug c/54823] string literal characters not constant

2012-10-05 Thread devel at fresse dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54823



--- Comment #3 from Sebastian Freundt devel at fresse dot org 2012-10-05 
11:46:20 UTC ---

I'm more or less referring to the internals, why is it a constant expression in

the first case, but not treated as an integer constant expression.



Also, according to the rules of indirection (6.5.3.2):

If [a string literal X] has type pointer to TYPE then *X should have type X.



Now if internally *  is a integer (or char) internally, and taking the rules

of indirection literally, then



  enum {foo = * };



should be (in my eyes) the same as



  enum {foo = (char)32};


[Bug c/54823] string literal characters not constant

2012-10-05 Thread devel at fresse dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54823



--- Comment #5 from Sebastian Freundt devel at fresse dot org 2012-10-05 
12:45:45 UTC ---

Ok, I see.  I assume, there's no plans on widening the allowed expressions for

constant integers?



It's autogenerated code a la:



  #define foo bar

  (foo)[1] * 0x55 + (foo)[2] * 0x30



where the indices are calculated.  I was trying to port the generated code to

gcc.



Thanks anyway.


[Bug c/54391] New: transparent_union typedef'ing inconsistent

2012-08-28 Thread devel at fresse dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54391

 Bug #: 54391
   Summary: transparent_union typedef'ing inconsistent
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: de...@fresse.org


This works as expected:

union __attribute__((transparent_union)) m30_u {
uint32_t u;
};

typedef union m30_u m30_t;

static inline double
make_double(m30_t m)
{
return (double)m.u;
}

But typedef'ing upfront does not:

typedef union m30_u m30_t;

union __attribute__((transparent_union)) m30_u {
uint32_t u;
};

static inline double
make_double(m30_t m)
{
return (double)m.u;
}

...
uint32_t bar = 17;
make_double(bar);


transpu.c:27:2: error: incompatible type for argument 1 of 'make_double'
  printf(%.6f\n, make_double());
transpu.c:11:1: note: expected 'm30_t' but argument is of type 'uint32_t'

This is very inconsistent.


[Bug c/50422] New: -Wswitch warns about unhandled cases in nested switches

2011-09-15 Thread devel at fresse dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50422

 Bug #: 50422
   Summary: -Wswitch warns about unhandled cases in nested
switches
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: de...@fresse.org


Linux plutos 2.6.37.6-0.7-desktop #1 SMP PREEMPT 2011-07-21 02:17:24 +0200
x86_64 x86_64 x86_64 GNU/Linux

freundt@clyde:pts/10:~ gcc --version
gcc (GCC) 4.7.0 20110811 (experimental)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Recipe to reproduce:
freundt@clyde:pts/10:~ gcc -x c -c -Wall -o /dev/null - EOF
typedef enum {
NAUGHT,
ONE,
TWO,
} foo_t;

int
test(foo_t arg)
{
switch (arg) {
case NAUGHT:
case ONE:
switch (arg) {
case NAUGHT:
return 0;
case ONE:
return 1;
}
break;
case TWO:
return 2;
}
return -1;
}
EOF
stdin: In function 'test':
stdin:13:3: warning: enumeration value 'TWO' not handled in switch [-Wswitch]

This is _similar_ to bug 23577 but not quite as nested switches should be
easier to handle than separate fragments.