[Bug c++/37213] New: Declaration/expression ambiguity resolution does not extend beyond initializer

[akyrtzi at gmail dot com]

When compiling the following program:


struct S {int z;};
typedef S* (*FuncType)(int,int);
int x,y;
S* a() {
  FuncType(a)(x,y)->z = 0; // treated as declaration
  return 0;
}


This is the result:

t.cpp: In function 'S* a()':
t.cpp:5: error: initializer expression list treated as compound expression
t.cpp:5: error: invalid conversion from 'int' to 'S* (*)(int, int)'
t.cpp:5: error: expected ',' or ';' before '->' token


Shouldn't GCC examine '->' after 'FuncType(a)(x,y)' and conclude that the
statement is an expression instead of a declaration ?


-- 
   Summary: Declaration/expression ambiguity resolution does not
extend beyond initializer
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
    AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: akyrtzi at gmail dot com


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

[Bug c++/37213] Declaration/expression ambiguity resolution does not extend beyond initializer

[akyrtzi at gmail dot com]

--- Comment #2 from akyrtzi at gmail dot com  2008-08-24 22:42 ---
I forgot to mention that both MSVC and Comeau compilers interpret

FuncType(a)(x,y)->z = 0;

as expression and compile the test program without errors.


-- 


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

[Bug c++/37213] Declaration/expression ambiguity resolution does not extend beyond initializer

[akyrtzi at gmail dot com]

--- Comment #3 from akyrtzi at gmail dot com  2008-10-08 09:19 ---
And some bit of C++ standard wisdom:
C++ 6.8p1: "To disambiguate, the whole statement might have to be examined to
determine if it is an expression-statement or a declaration"

And there's this example given:

T(a)->m = 7; // expression-statement

I think the same applies to the example I gave:

T(a)(x,y)->m = 7; // should be an expression


-- 


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

[Bug c++/18770] g++ accepts invalid code with scopes on ifs

[akyrtzi at gmail dot com]

--- Comment #3 from akyrtzi at gmail dot com  2008-10-08 09:09 ---
Note that the same rule applies to the 'switch' statement too:

switch (int x = 1)
{
  default:
  int x = 2; // there should be an error because of redeclaration
}


-- 

akyrtzi at gmail dot com changed:

   What|Removed |Added

 CC|        |akyrtzi at gmail dot com


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

[Bug c/47557] New: Effect of aligned attribute on arrays

[akyrtzi at gmail dot com]

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

   Summary: Effect of aligned attribute on arrays
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: akyr...@gmail.com


The following test case demonstrates what the effect aligned on the size of
arrays:

typedef __attribute__((aligned(2))) struct {
char a[3];
} T;

unsigned x1 = sizeof(T);// sizeof is 3
unsigned x2 = sizeof(T[1]); // sizeof is 4
unsigned x3 = sizeof(T[2]); // sizeof is 6
unsigned x4 = sizeof(T[2][1]);  // sizeof is 8
unsigned x5 = sizeof(T[1][2]);  // sizeof is 6


The result is that type 'T' is not aligned by the array-of-T is.
Padding arrays seems like a mistake, I couldn't find any mention in the
standards about padding in arrays. C++ 5.3.3p2 (expr.sizeof) says:
"When applied to an array, the result is the total number of bytes in the
array. This implies that the size of an array of n elements is n times the size
of an element."

C99 6.5.3.4p6 (sizeof) implies the same with "Another use of the sizeof
operator is to compute the number of elements in an array: sizeof array /
sizeof array[0]"

Note that in both standards, in those sections they specifically mention
padding for classes/structures.

IMO the reasonable thing is to fully respect the alignment of T and pad it to 4
bytes so that the elements in array-of-T are aligned, e.g. second element of
array-of-T is not aligned as it is now.

So, to sum up, I think the test case should be like this:

typedef __attribute__((aligned(2))) struct {
char a[3];
} T;

unsigned x1 = sizeof(T);// sizeof is 4
unsigned x2 = sizeof(T[1]); // sizeof is 4
unsigned x3 = sizeof(T[2]); // sizeof is 8
unsigned x4 = sizeof(T[2][1]);  // sizeof is 8
unsigned x5 = sizeof(T[1][2]);  // sizeof is 8

[Bug c/47557] Effect of aligned attribute on arrays

[akyrtzi at gmail dot com]

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

--- Comment #2 from Argiris Kirtzidis  2011-02-01 
17:00:56 UTC ---
(In reply to comment #1)
> I think the current behavior is correct.

Could you elaborate ? What is the actual benefit of padding T[1] ? Access to
elements of array-of-T is still unaligned.