Question on building a variably modified type at parameter scope
HI,
I'm a newbie and I'm trying to modify the front end to extend C.
I know the following code can be accepted,
void f (struct S { int a; } s, int a[][s.a]) { } .
I'm wondering whether it is possible to build a structure which has a
variably modified array whose size depends on an other field in that
structure at parameter scopes,
i.e, something like this,
void f (struct S { int a; int b[s.a]; } s) { } .
This won't be compiled as s is not declared when build the struct S, but
by modifying the front end code, I can mimic this directly. However, the
assertion,
gcc_assert (SA.partition_to_pseudo[i]);
in the function gimple_expend_cfg in cfgexpand.c fails, and I've no idea
why.
I'm using 4.6.3.
Thanks,
Chenkan
Re: Question on building a variably modified type at parameter scope
On Tue, Mar 5, 2013 at 4:49 AM, YU Chenkan wrote:
>
> I'm a newbie and I'm trying to modify the front end to extend C.
>
> I know the following code can be accepted,
>
> void f (struct S { int a; } s, int a[][s.a]) { } .
>
> I'm wondering whether it is possible to build a structure which has a
> variably modified array whose size depends on an other field in that
> structure at parameter scopes,
> i.e, something like this,
>
> void f (struct S { int a; int b[s.a]; } s) { } .
>
> This won't be compiled as s is not declared when build the struct S, but
> by modifying the front end code, I can mimic this directly. However, the
> assertion,
>
> gcc_assert (SA.partition_to_pseudo[i]);
>
> in the function gimple_expend_cfg in cfgexpand.c fails, and I've no idea
> why.
I believe this should be possible. I believe that Ada has constructs
like this. I think you will need to use a PLACEHOLDER_EXPR to get the
right thing to happen.
Ian
Re: Question on building a variably modified type at parameter scope
> I believe this should be possible. I believe that Ada has constructs > like this. I think you will need to use a PLACEHOLDER_EXPR to get the > right thing to happen. Yes, that's correct.
Re: Question on building a variably modified type at parameter scope
> I believe this should be possible. I believe that Ada has constructs
> like this. I think you will need to use a PLACEHOLDER_EXPR to get the
> right thing to happen.
In Ada, we indeed have the mechanism in its full generality, i.e.
struct S { int a; int b[a]; };
will work anywhere, and for this the PLACEHOLDER_EXPR machinery is needed.
But it seems to me that the case at stake is more specific:
void f (struct S { int a; int b[s.a]; } s) { }
because struct S is defined at parameter scope and s.a is a known object, so
perhaps the use of the (heavy) PLACEHOLDER_EXPR machinery could be avoided.
--
Eric Botcazou
Gcc-4.8 (20130217) dealing with bugfixes in isl
Hello,
I'm trying to compile the gcc-4.8.0-20130217 snapshot with (eg) the last
version of isl.
This version has a bug fix which make that isl_version() returns
"isl-1.11.1", as result that configure script fails to detect isl
because it try to compile a code like
int
main ()
{
printf("%s",isl_version());
if (strncmp (isl_version (), "isl-0.11", strlen ("isl-0.11")) != 0 &&)
return 1;
;
return 0;
}
of course, this code returns 1 and detection fails.
One possible way to deal with bugfix numbers should to modify the test
code in something like
#include
#include
int
main ()
{
char *version[8]={};
strncpy(version, isl_version(),8);
if (strncmp (version, "isl-0.11", strlen ("isl-0.11")) != 0)
return 1;
;
return 0;
}
(works if changed directly in configure script)
What would you thing about idea to integrate such change directly in
Configure.ac ?
PS: Please excuse my poor english but it isn't my native language
Re: Default -fabi-version=0 for 4.9
On 3/4/13, Jason Merrill wrote: > Our policy on mangling bugs has been that we don't change > the mangling unless users explicitly specify -fabi-version. > Over time, this means that quite a few bugs have been found but > continue to accumulate. Most of these are C++11-specific, which > means that as users use C++11 more frequently, the bugs are more > likely to affect code in the wild. > > For templates, it also seems to me that mangling changes have > very little negative impact; in most cases the worst that will > happen is that a program ends up with two compatible versions of > the same function. And none of the changes affect libstdc++.so. > For non-template code, any failures will be at link time, making > them straightforward to deal with. > > The only non-mangling ABI change since version 2 is to argument > promotion of C++11 scoped enums, and since we've been telling > people that they need to rebuild all their C++11 code with every > major release anyway, I don't think that's an obstacle. > > So, for GCC 4.9 I would like to propose that we switch the > default ABI version to 0 so that by default we use the most > correct mangling. If people really need backward compatible > mangling for some reason they can specify the flag appropriately. Are you planning for C++11 ABI stability in 4.9? -- Lawrence Crowl
Re: Default -fabi-version=0 for 4.9
On 03/05/2013 02:28 PM, Lawrence Crowl wrote: Are you planning for C++11 ABI stability in 4.9? Yes. But if mangling bugs are discovered after 4.9, I propose to just fix them (as I believe EDG and Clang do) rather than hold them in reserve as we have been doing. Jason
Re: Default -fabi-version=0 for 4.9
On Tue, Mar 5, 2013 at 1:43 PM, Jason Merrill wrote: > On 03/05/2013 02:28 PM, Lawrence Crowl wrote: >> >> Are you planning for C++11 ABI stability in 4.9? > > > Yes. But if mangling bugs are discovered after 4.9, I propose to just fix > them (as I believe EDG and Clang do) rather than hold them in reserve as we > have been doing. Agreed. -- Gaby > > Jason >
VAMOS MAL
No hay forma de ocultar lo que a todas luces se ve. El partido ARENA se conduce con el hígado en medio de revanchismo, prepotencia y descalificación. De: osantamaria...@hotmail.com Para: < Norman-privado > Cc: Fecha: Dom. 3 de marzo 19:37:15 -0600 Asunto: Instrucciones Los espero a ambos para que planifiquemos la visita a Oriente, las instrucciones son claras así como las áreas de acción en las que nos tenemos que mover. Manejemos estos temas lejos de los medios, eviten pronunciarse, es mejor utilicemos los temas que revisamos hace una semana para desviar la atención. Oscar El dom. 3 Mar 2013 14:11:57 -0700 (PDT), Fredy escribió: Oscar, Lo primero que le dije a Pancho que no hiciera, es lo primero que hizo. Le advertí que saliera sin dar un portazo. Esta es idea del maldito de Saca, y todo el resentimiento es originado porque pusimos a Norman. Fue buena decisión el no tomar en cuenta a este saquista. A los que no les gusten las decisiones pues simplemente que se vayan. Siempre se han manejado institucionalmente varios temas en el COENA con una gran disciplina, y ahora aparece este reclamando cuando él fue uno de los precursores de que Saca intentara adueñarse del partido. Tú eres responsable de mantener calmadas las aguas. Bájenle volumen al reclamo y a la carta. Reúnete e instruye a Donato y a su gente que mejor ataquen en lugar de estarse defendiendo. Como lo hemos conversado infinidad de veces, la defensa siempre nos deja mal parados y nos hace ver débiles. Hay flancos que cubrir y nos deben preocupar: TSE, redes sociales, la propaganda negra que van a comenzar a usar en nuestra contra por negarnos a dar votos y por supuesto lo de Paco y ENEL. Además me informaron hace un par de minutos que en oriente hay dos diputados que se reunieron con Salgado en aquella finca. Reúnete con ellos y Norman antes de la plenaria. AFCB
filling delay slots with branches
Am I correct in my understanding that you can't put a branch instruction in the delay slot of a branch instruction? Semantically, the HW I'm looking at annuls the branch in the delay slot if the first branch is taken, but any other instructions are not annulled; but it appears that there's no way to describe this in the define_delay() and it looks to me like the delay-slot for the instruction in the delay slot won't get filled properly either. e.g. cmpi $r1,0 jeq $1 jlt $2 jmp $3 nop would be a 3-way branch on zero, neg or (by elimination) positive values with the indented instructions being in a branch delay slot.
Re: Gcc-4.8 (20130217) dealing with bugfixes in isl
Hi, --- On Wed, Mar 6, 2013 at 12:34 AM, koala01 wrote: | This version has a bug fix which make that isl_version() returns | "isl-1.11.1", as result that configure script fails to detect isl \-- Perhaps build gcc with the following? $ ../configure --disable-isl-version-check SK -- Shakthi Kannan http://www.shakthimaan.com
