Re: [gSoc] [graphite] general plan for Automatic parallelization in Graphite

[Tobias Grosser]

Hi Alex,

On Wed, 2009-04-22 at 08:19 -0700, Alex Turjan wrote:
> Are there any plans to move the partial unrolling phase from
> RTL to Tree-SSA?
> The move would benefit from better (or easier to implement) Tree-SSA alias 
> analysis. 

We thought about loop unrolling in graphite.
It seems to be an interesting project and definitely possible in
general.
But at the moment I do not know of anybody who is working on this. So it
is an open project. If you want to work on this we will definitely
support you. ;-)

Tobi

> 
> Alex
> > 
> > 
> > 
> > 
> > --- On Wed, 4/22/09, Li Feng 
> > wrote:
> > 
> > > From: Li Feng 
> > > Subject: [gSoc] [graphite] general plan for Automatic
> > parallelization in   Graphite
> > > To: "GCC" 
> > > Cc: "Tobias Grosser"
> > , "Sebastian"
> > , "Razya Ladelsky"
> > , konrad.trifuno...@gmail.com
> > > Date: Wednesday, April 22, 2009, 5:10 PM
> > > Hi,
> > > 
> > > It's nice that the proposal 'Automatic
> > > parallelization in Graphite'
> > > is accepted. Which means I will be working with great
> > > Graphtie
> > > developers this summer, and trying to implement the
> > project
> > > .
> > > 
> > > I have set up a blog for this project, which will
> > mainly
> > > about this
> > > project: 1. plans 2. what I have done 3. related
> > Graphite
> > > internals
> > > You can subscribe to it if you like:
> > > http://summergraphite.blogspot.com/
> > > 
> > > Here is a general plan for this project, keep you in
> > loop,
> > > and feel free to comment :)
> > > 
> > >  1. Mark the innermost loop parallel  [done]
> > > 
> > >  2. Try to schedule autopar pass after Graphite, and
> > enable
> > >  code generation if flag_graphite_force_parallel
> > is set
> > >  - There should be some discussion with Razya
> > about
> > >her plan about the autopar part
> > >  - But before that, I'll try to schedule
> > > autopar first
> > > 
> > >  3. I may try to write testcases for the loops that
> > should
> > > be
> > >  parallel, from simple to hard, and check
> > autopar's
> > > code
> > >  generation part, make sure this works correctly
> > as we
> > >  expected.
> > >  - The testcases is important. There should be
> > some
> > >detailed discussion maybe with Sebastian
> > and
> > > Konrad.
> > >To see what kind of loop we can/decide to
> > > handle.
> > >  - Check autopar's code generation with
> > >flag_graphite_force_parallel set with these
> > > testcases,
> > >report bugs if it goes wrong.
> > > 
> > >  4. Try to write code for deciding if a loop can be
> > > parallel
> > >  with data dependency test under this polyhedral
> > model.
> > > - Try to understand the interface of data
> > > dependency test
> > > - Write code, if data dependency success, mark
> > the
> > > loop parallel
> > > 
> > > Cheers,
> > > Li
> 
> 
>   

GCC 4.4.0 Released

[Jakub Jelinek]

The GNU Compiler Collection version 4.4.0 has been released.

GCC 4.4.0 is a major release, containing substantial new functionality
not available in GCC 4.3.x or previous GCC releases.

See:

  http://gcc.gnu.org/gcc-4.4/changes.html

for more information about changes in GCC 4.4.0.

This release is available from the FTP servers listed here:

  http://www.gnu.org/order/ftp.html

The release is in gcc/gcc-4.4.0/ subdirectory.

If you encounter difficulties using GCC 4.4, please do not contact me
directly.  Instead, please visit http://gcc.gnu.org for information
about getting help.

As always, a vast number of people contributed to this GCC releases --
far too many to thank individually!

GCC 4.5: "nonconstant array index in initializer" error

[Denis Onischenko]

The following errors appears when I tried to compile linux kernel
2.6.30-rc2 with GCC 4.5:


linux-2.6/drivers/gpu/drm/drm_drv.c:59: error: nonconstant array index
in initializer
linux-2.6/drivers/gpu/drm/drm_drv.c:59: error: (near initialization
for 'drm_ioctls')
...

compiled code looks like this:

static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version, 0),
DRM_IOCTL_DEF(DRM_IOCTL_GET_UNIQUE, drm_getunique, 0),
...

where DRM_IOCTL_DEF defined as

#define DRM_IOCTL_DEF(ioctl, _func, _flags) \
[DRM_IOCTL_NR(ioctl)] = {.cmd = ioctl, .func = _func, .flags = _flags}

Just released GCC 4.4 compiles this code without errors.

Is this a bug in GCC 4.5 or the errors caused by folowing changes in GCC 4.5:

"GCC now implements C90- and C99-conforming rules for constant
expressions. This may cause warnings or errors for some code using
expressions that can be folded to a constant but are not constant
expressions as defined by ISO C"
?

If it is not a bug, is there a way to disable this conformance rules
checking with GCC 4.5 ?

Re: new offset outside bounds of constant string warning

[Manuel López-Ibáñez]

2009/4/23 Ben Elliston :
> Hi HJ
>
> According to svn annotate, it was you who authored the new 'offset
> outside bounds of constant string warning' warning in GCC (well, I think
> so, anyway).  The compiler now complains about some code in the C++
> demangler:
>
> /home/bje/source/gcc-trunk/libiberty/cplus-dem.c:2651: warning: offset ‘3’ 
> outside bounds of constant string
>
> I tracked this down to the definition of strspn used on my Linux system:
>
> #   define strspn(s, accept) \
>  __extension__                                                               \
>  ({ char __a0, __a1, __a2;                                                   \
>     (__builtin_constant_p (accept) && __string2_1bptr_p (accept)             \
>      ? ((__builtin_constant_p (s) && __string2_1bptr_p (s))                  \
>         ? __builtin_strspn (s, accept)                                       \
>         : ((__a0 = ((__const char *) (accept))[0], __a0 == '\0')             \
>            ? ((void) (s), 0)                                                 \
>            : ((__a1 = ((__const char *) (accept))[1], __a1 == '\0')          \
>               ? __strspn_c1 (s, __a0)                                        \
>               : ((__a2 = ((__const char *) (accept))[2], __a2 == '\0')       \
>                  ? __strspn_c2 (s, __a0, __a1)                               \
>                  : (((__const char *) (accept))[3] == '\0'                   \
>                     ? __strspn_c3 (s, __a0, __a1, __a2)                      \
>                     : __builtin_strspn (s, accept))                      \
>      : __builtin_strspn (s, accept)); })
>
> Is this something you can fix?
>

I authored the patch, HJ just committed it. I cannot think any trivial
way to fix this and I don't have much time to investigate. The PR is
already reopened, so I think the patch should be reverted. Probably we
warn too early now but the above testcase seems specially difficult to
handle.

With the revert, it would useful to add one of the failing testcases
to the testsuite, to avoid repeating this situation.

Cheers,

Manuel.

Re: Machine description

[Jean Christophe Beyler]

I've actually done that. I defined the expansion like this:

/* If we can create pseudos, the first operand is a register but the
second is memory */
  if (
(
 can_create_pseudo_p () &&
 register_operand (operands[0], DImode)
  && memory_operand (operands[1], DImode)))
  {
/* If the memory is not a REG */
if (GET_CODE(XEXP (operands[1], 0)) != REG)
{
/* Make a register and move it there first before performing the load*/
rtx tmp = gen_reg_rtx(DImode);
emit_move_insn (tmp, XEXP (operands[1], 0));
emit_move_insn (operands[0], gen_rtx_MEM (DImode,tmp));
DONE;
}
  }

Then I have my base cost for address_cost that is used and actually
does tell GCC that loading from a global address is expensive (I put a
value like 10 for that) whereas a register with an offset would get 2.

For the moment, no change, the expansion code is actually not used in
this case because GCC only presents me with the load from a global
during or after reload. Therefore, it's already done and he doesn't
seem to want to change his ways. I haven't played with the rtx_cost
but that's my next step.

Any comments, ideas?
Jc

On Wed, Apr 22, 2009 at 4:08 PM, Ian Lance Taylor  wrote:
> Jean Christophe Beyler  writes:
>
>> I've been working on the Machine description of my target and was
>> wondering if you could help me out here.
>>
>> I've been trying to force GCC out of it's habit of generating this code :
>> (insn 28 8 10 2 glob.c:13 (set (reg:DI 9 r9)
>> (mem/s:DI (symbol_ref:DI ("data") )
>> [4 data+0 S8 A64])) 71 {*movdi_internal1} (nil))
>>
>> -> Load r9, 0(data)
>>
>> Because, in my target it's costly to do so, I would prefer :
>>
>> Mov r10, data
>> Load r9, 0(r10)
>>
>> This way, GCC can optimize this by taking the first move out of the
>> loop for example. Otherwise, I have do a final pass but that's too
>> late for all the optimizations.
>>
>> My problem is that I've defined the define_expand "movdi" and it only
>> sees the right case after reload is in progress or completed.
>> Therefore, I can't create any new pseudos.
>>
>> Any ideas on how to do this, I've been looking at the other
>> architectures but haven't seen anything that resembles this,
>
> This looks somewhat difficcult.  I would suggest having the movMM
> expander generate the two instruction sequence when can_create_pseudo_p
> returns true.  Then set the costs so that a load from an address plus an
> offset is expensive.
>
> Ian
>

Error on http://gcc.gnu.org/gcc-4.4/changes.html (-Wsequence-points)

[Vincent Lefevre]

There seems to be an error on

  http://gcc.gnu.org/gcc-4.4/changes.html

It says:

  -Wsequence-points now warns within if, while,do while and for
  conditions, and within for begin/end expressions.

However the -Wsequence-points option doesn't seem to exist.
Shouldn't it be -Wsequence-point (without an "s")?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

[wwwdocs] Error on http://gcc.gnu.org/gcc-4.4/changes.html (-Wsequence-points)

[Manuel López-Ibáñez]

2009/4/23 Vincent Lefevre :
> There seems to be an error on
>
>  http://gcc.gnu.org/gcc-4.4/changes.html
>
> It says:
>
>  -Wsequence-points now warns within if, while,do while and for
>  conditions, and within for begin/end expressions.
>
> However the -Wsequence-points option doesn't seem to exist.
> Shouldn't it be -Wsequence-point (without an "s")?

Yes. Committed as obvious.

Index: htdocs/gcc-4.4/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.4/changes.html,v
retrieving revision 1.70
diff -r1.70 changes.html
325c325
< -Wsequence-points now warns within
---
> -Wsequence-point now warns within

Cheers,

Manuel.

Re: GCC 4.5: "nonconstant array index in initializer" error

[Joseph S. Myers]

On Thu, 23 Apr 2009, Denis Onischenko wrote:

> The following errors appears when I tried to compile linux kernel
> 2.6.30-rc2 with GCC 4.5:
> 
> 
> linux-2.6/drivers/gpu/drm/drm_drv.c:59: error: nonconstant array index
> in initializer
> linux-2.6/drivers/gpu/drm/drm_drv.c:59: error: (near initialization
> for 'drm_ioctls')
> ...
> 
> compiled code looks like this:
> 
> static struct drm_ioctl_desc drm_ioctls[] = {
> DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version, 0),
> DRM_IOCTL_DEF(DRM_IOCTL_GET_UNIQUE, drm_getunique, 0),
> ...
> 
> where DRM_IOCTL_DEF defined as
> 
> #define DRM_IOCTL_DEF(ioctl, _func, _flags) \
> [DRM_IOCTL_NR(ioctl)] = {.cmd = ioctl, .func = _func, .flags = _flags}

And how is DRM_IOCTL_NR defined?  To be used here it should be defined to 
expand to an integer constant expression.

> If it is not a bug, is there a way to disable this conformance rules
> checking with GCC 4.5 ?

There is no general way.  In particular cases the errors can be made into 
pedwarns or pedwarns-if-pedantic if there seems to be a good reason for a 
coding style not letting proper integer constant expressions be used in a 
particular case.

-- 
Joseph S. Myers
jos...@codesourcery.com

-O3 and new optimizations in 4.4.0

[David Ronis]

>From the info pages it seems that the new optimizations,
-floop-interchange, -floop-strip-mine, and -floop-block, are NOT turned
on when -O3 is specified.  Is this correct and if so, why aren't they?

David

Re: -O3 and new optimizations in 4.4.0

[Joseph S. Myers]

On Thu, 23 Apr 2009, David Ronis wrote:

> >From the info pages it seems that the new optimizations,
> -floop-interchange, -floop-strip-mine, and -floop-block, are NOT turned
> on when -O3 is specified.  Is this correct and if so, why aren't they?

Because the behavior of -O3 must not depend on whether optional libraries 
are linked into GCC, and we did not decide to make PPL and CLooG required 
to build GCC, so -O3 cannot enable any optimizations using optional 
libraries.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: -O3 and new optimizations in 4.4.0

[David Ronis]

Thanks for the reply.  On the other hand, it seems that PPL and Cloog
are auto-detected  by configure; shouldn't that be enough to dynamically
modify what -O3 does (or perhaps enable -O4)?   On a related point,
having used my old build script to build gcc I, of course, didn't read
the prerequisites section.  I have to rebuild right?

David 


On Thu, 2009-04-23 at 15:57 +, Joseph S. Myers wrote:
> On Thu, 23 Apr 2009, David Ronis wrote:
> 
> > >From the info pages it seems that the new optimizations,
> > -floop-interchange, -floop-strip-mine, and -floop-block, are NOT turned
> > on when -O3 is specified.  Is this correct and if so, why aren't they?
> 
> Because the behavior of -O3 must not depend on whether optional libraries 
> are linked into GCC, and we did not decide to make PPL and CLooG required 
> to build GCC, so -O3 cannot enable any optimizations using optional 
> libraries.
> 

Re: -O3 and new optimizations in 4.4.0

[Joseph S. Myers]

On Thu, 23 Apr 2009, David Ronis wrote:

> Thanks for the reply.  On the other hand, it seems that PPL and Cloog
> are auto-detected  by configure; shouldn't that be enough to dynamically
> modify what -O3 does (or perhaps enable -O4)?   On a related point,
> having used my old build script to build gcc I, of course, didn't read
> the prerequisites section.  I have to rebuild right?

The whole point is that gcc -O3 should not depend on what was detected at 
configure time; everyone's gcc -O3 (with the same configure options) 
should behave the same way to avoid mysterious problems appearing only for 
some people (unreproducible bug reports, etc.) depending on what they had 
installed when GCC was built.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [m32c] IRA reload failures in libstdc++

[DJ Delorie]

> > m32c has no problem loading a 24-bit register from a 32-bit memory
> > location.
> 
> The only truncsipsi2* alternative part that seems to match is Raa / Sd* .
> Does that mean that Sd* is as good as m?

m32c doesn't use any of the single-character constraints, as they're
too general to pretty much every apply.  Sd ("standard displacement")
is the most popular addressing mode the m32c supports.

> The salient fact here is that there is no register r in A_REGS such
> that HARD_REGNO_MODE_OK (rn, PSImode) && !fixed_regs[rn] is true
> for [ r , r + HARD_REGNO_NREGS (r, PSImode) ) .

If you mean r + HARD_REGNO_NREGS (r, PSImode) - 1, then any of the
A_REGS can hold a PSImode.  Either A0 or A1 can hold a PSImode, but
neither nor both can hold an SImode.

> So, personally, I would welcome a new macro or hook to make the decision
> to reload the inside or the outside of the subreg target-dependent.

It should be easy enough to test for the "this just doesn't work"
cases and choose the other one, though, yes?

Re: [m32c] IRA reload failures in libstdc++

[Joern Rennecke]

Quoting DJ Delorie :




> m32c has no problem loading a 24-bit register from a 32-bit memory
> location.

The only truncsipsi2* alternative part that seems to match is Raa / Sd* .
Does that mean that Sd* is as good as m?


m32c doesn't use any of the single-character constraints, as they're
too general to pretty much every apply.  Sd ("standard displacement")
is the most popular addressing mode the m32c supports.


The salient fact here is that there is no register r in A_REGS such
that HARD_REGNO_MODE_OK (rn, PSImode) && !fixed_regs[rn] is true
for [ r , r + HARD_REGNO_NREGS (r, PSImode) ) .


If you mean r + HARD_REGNO_NREGS (r, PSImode) - 1, then any of the


Oops, I meant SImode.

And HARD_REGNO_MODE_OK should only be checked for the first hard reg.



It should be easy enough to test for the "this just doesn't work"
cases and choose the other one, though, yes?


We can test for the 'this cannot possibly work' cases, i.e. where there is
no suitable register at all.  That would address the problems you have
originally identified for the m32c.

There could still be further complications with call return values and
requirements for multiple reload registers overall.

There is also no easy way to check if we need a particular mode because
of addressing restrictions, and doing a performance-optimal solution is
way beyond the scope of reload.

Build report for AIX 6.1

[Mario Linke]

Hi,

i just built  GCC 4.4.0  on AIX 6.1 using the following commands:
setenv LDR_CNTRL MAXDATA=0x5000
../gcc-4.4.0/configure --disable-multilib --with-gmp=/usr/local
make bootstrap-lean
make install

$ config.guess
powerpc-ibm-aix6.1.0.0

$ gcc -v
Using built-in specs.
Target: powerpc-ibm-aix6.1.0.0
Configured with: ../gcc-4.4.0/configure --disable-multilib 
--with-gmp=/usr/local

Thread model: aix
gcc version 4.4.0 (GCC)
The system is an IBM System p JS21 Blade with AIX 6.1 at the latest
patchlevel.
The building c-complier is  IBM xlC 10.1
Make is  gnu-make 3.80

The disable-multilib configure-option shouldn't be necessary, i used it
for buildtime- and space-saving reasons.
The 'setenv LDR_CNTRL MAXDATA=0x5000' was necessary to get gcc built
(found that hint in the gcc bug database).
Generally the AIX default memory settings are too low to build/install
the actual gcc-versions. Had to increase the max-data-segment size for
the building user and the environment size on the system, too...


Mario Linke

Re: [m32c] IRA reload failures in libstdc++

[DJ Delorie]

> We can test for the 'this cannot possibly work' cases, i.e. where there is
> no suitable register at all.  That would address the problems you have
> originally identified for the m32c.

Sounds good to me ;-)

Re: GCC 4.5: "nonconstant array index in initializer" error

[Denis Onischenko]

Thanks for reply!

DRM_IOCTL_NR is defined as

#define _IOC_NRBITS  8

#define _IOC_NRSHIFT 0
#define _IOC_NRMASK  ((1 << _IOC_NRBITS)-1)

#define _IOC_NR(nr)(((nr) >> _IOC_NRSHIFT) & _IOC_NRMASK)

#define DRV_IOCTL_NR(n)_IOC_NR(n)



i.e. expands to an integer constant expression




2009/4/23 Joseph S. Myers :
> On Thu, 23 Apr 2009, Denis Onischenko wrote:
>
>> The following errors appears when I tried to compile linux kernel
>> 2.6.30-rc2 with GCC 4.5:
>>
>>
>> linux-2.6/drivers/gpu/drm/drm_drv.c:59: error: nonconstant array index
>> in initializer
>> linux-2.6/drivers/gpu/drm/drm_drv.c:59: error: (near initialization
>> for 'drm_ioctls')
>> ...
>>
>> compiled code looks like this:
>>
>> static struct drm_ioctl_desc drm_ioctls[] = {
>>     DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version, 0),
>>     DRM_IOCTL_DEF(DRM_IOCTL_GET_UNIQUE, drm_getunique, 0),
>> ...
>>
>> where DRM_IOCTL_DEF defined as
>>
>> #define DRM_IOCTL_DEF(ioctl, _func, _flags) \
>>     [DRM_IOCTL_NR(ioctl)] = {.cmd = ioctl, .func = _func, .flags = _flags}
>
> And how is DRM_IOCTL_NR defined?  To be used here it should be defined to
> expand to an integer constant expression.
>
>> If it is not a bug, is there a way to disable this conformance rules
>> checking with GCC 4.5 ?
>
> There is no general way.  In particular cases the errors can be made into
> pedwarns or pedwarns-if-pedantic if there seems to be a good reason for a
> coding style not letting proper integer constant expressions be used in a
> particular case.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
>

Re: Machine description

[Ian Lance Taylor]

Jean Christophe Beyler  writes:

> For the moment, no change, the expansion code is actually not used in
> this case because GCC only presents me with the load from a global
> during or after reload. Therefore, it's already done and he doesn't
> seem to want to change his ways. I haven't played with the rtx_cost
> but that's my next step.

A load from a global variable should certainly be seen before reload,
unless your insn patterns permit addition, or whatever, using a memory
address.

It's true in any case that you will sometimes see these loads during
reload, and you will have to cope with that.  However, that should not
be the common case--it should only happen when a register is spilled.

Ian

Re: GCC 4.5: "nonconstant array index in initializer" error

[Joseph S. Myers]

On Thu, 23 Apr 2009, Denis Onischenko wrote:

> Thanks for reply!
> 
> DRM_IOCTL_NR is defined as
> 
> #define _IOC_NRBITS  8
> 
> #define _IOC_NRSHIFT 0
> #define _IOC_NRMASK  ((1 << _IOC_NRBITS)-1)
> 
> #define _IOC_NR(nr)(((nr) >> _IOC_NRSHIFT) & _IOC_NRMASK)
> 
> #define DRV_IOCTL_NR(n)_IOC_NR(n)
> 
> 
> 
> i.e. expands to an integer constant expression

How then are its operands (DRM_IOCTL_VERSION, DRM_IOCTL_GET_UNIQUE, etc.) 
defined?

You should send a complete, self-contained, minimal code example that 
reproduces the issue you see, complete with the compilation options used, 
rather than snippets without all the previous declarations they require.  
Your message needs to contain all the information needed to reproduce the 
problem without referring to any external sources.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: -O3 and new optimizations in 4.4.0

[Kate Minola]

On Thu, 23 Apr 2009, Joseph S. Myers wrote:

> Because the behavior of -O3 must not depend on whether optional libraries
> are linked into GCC, and we did not decide to make PPL and CLooG required
> to build GCC, so -O3 cannot enable any optimizations using optional
> libraries.

Ok, I am confused.  You imply that PPL and CLooG are NOT required to
build GCC, yet

 http://gcc.gnu.org/install/prerequisites.html

lists them as prerequisites to a build.

Who is correct?

Kate Minola

Re: -O3 and new optimizations in 4.4.0

[Andrew Pinski]

On Thu, Apr 23, 2009 at 12:11 PM, Kate Minola  wrote:
> Ok, I am confused.  You imply that PPL and CLooG are NOT required to
> build GCC, yet
>
>     http://gcc.gnu.org/install/prerequisites.html
>
> lists them as prerequisites to a build.
>
> Who is correct?

Both, the website says:
Necessary to build GCC with the Graphite loop optimizations.

Witness the "with the Graphite loop optimizations" part of that
sentence.  So if you want the graphite loop optimizers you need PPL
and CLooG, otherwise you don't need them to compile GCC.

-- Pinski

Updating gnu.org/software Fortran Page

[Rob Myers]

Hi.

The gnu.org webmaster team are going to be updating all the pages in the
gnu.org/software subdirectory, which includes -

http://www.gnu.org/software/fortran

This will involve changing the design of the page to match the new style
of gnu.org, and updating the information about the GNU Fortran project
if possible.

Is there any information you would like adding to the project page or
any other changes you would like making to its content?

Thanks.

- Rob Myers, Chief GNU Webmaster.

Re: GCC 4.5: "nonconstant array index in initializer" error

[Denis Onischenko]

The minimal code example is following:


extern unsigned int __invalid_size_argument;
#define TYPECHECK(t)( sizeof(t) == sizeof(t[1]) ?  sizeof(t) :
__invalid_size_argument )

static int arr[] = {
[TYPECHECK(int)] = 0,
};

int main()
{
  return 0;
}


command line is: gcc test.c

GCC 4.5.0 revision 146607 compiles this code with following errors:
test.c:5: error: nonconstant array index in initializer
test.c:5: error: (near initialization for 'arr')

released GCC 4.4.0 compiles without any errors



2009/4/23 Joseph S. Myers :
> On Thu, 23 Apr 2009, Denis Onischenko wrote:
>
>> Thanks for reply!
>>
>> DRM_IOCTL_NR is defined as
>>
>> #define _IOC_NRBITS  8
>>
>> #define _IOC_NRSHIFT 0
>> #define _IOC_NRMASK  ((1 << _IOC_NRBITS)-1)
>>
>> #define _IOC_NR(nr)        (((nr) >> _IOC_NRSHIFT) & _IOC_NRMASK)
>>
>> #define DRV_IOCTL_NR(n)            _IOC_NR(n)
>>
>>
>>
>> i.e. expands to an integer constant expression
>
> How then are its operands (DRM_IOCTL_VERSION, DRM_IOCTL_GET_UNIQUE, etc.)
> defined?
>
> You should send a complete, self-contained, minimal code example that
> reproduces the issue you see, complete with the compilation options used,
> rather than snippets without all the previous declarations they require.
> Your message needs to contain all the information needed to reproduce the
> problem without referring to any external sources.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
>

Re: new offset outside bounds of constant string warning

[Ian Lance Taylor]

Manuel López-Ibáñez  writes:

> I authored the patch, HJ just committed it. I cannot think any trivial
> way to fix this and I don't have much time to investigate. The PR is
> already reopened, so I think the patch should be reverted. Probably we
> warn too early now but the above testcase seems specially difficult to
> handle.

We may be able to handle it in a manner similar to skip_evaluation in
the C++ frontend.  When we see a conditional whose test evaluates to a
constant, then while processing the false branch we can note that the
code will never be executed, and suppress immediate warnings, and set
TREE_NO_WARNING to suppress future warnings.

Ian

dg-warning: bogus target expectations?

[DJ Delorie]

In gcc.dg/Wconversion-real.c we see this:

  vdouble = 3.1L; /* { dg-warning "conversion" "" { target large_long_double } 
} */

It turns out check_effective_target_large_long_double is NEVER called.
You can change it to some bogus string:

  fdouble (3.1L); /* { dg-warning "conversion" "" { target dj_wins } } */

and the test still passes - no complaints about a missing "dj_wins"
like you'd get with the dg-require-effective-target command.  Have we
been silently ignoring those warnings for *every* target all along?

I ask because I'm adding some new check-effectives, and reversed the
sense of the check to make sure it was doing its job, and found that
it wasn't.

Re: Side effects on memory access

[Michael Hope]

Thanks for the response Ian.  Doing the define_expand inserts the post
increment but GCC doesn't seem to notice the change in X.

I added this code:


(define_expand "movqi"
  [(set (match_operand:QI 0 "nonimmediate_operand")
(match_operand:QI 1 "general_operand" ""))]
  ""
  {
if (can_create_pseudo_p () && MEM_P (operands[1]))
  {
rtx reg = copy_to_reg (XEXP (operands[1], 0));
emit_insn (gen_movqi_mem (operands[0], reg));
DONE;
  }
  }
)

; PENDING: The SI here is actually a P
(define_insn "movqi_mem"
  [(set (match_operand:QI 0 "register_operand" "=d")
(mem:QI (post_inc:SI (match_operand:SI 1 "register_operand" "a"]
  ""
  "LOADACC, (%1+)\;STOREACC, %0"
)

The 'd' constraint is for data registers and the 'a' for address
registers, which is only the X register due to cache coherency
reasons.

When compiling this test case:

uint store5(volatile char* p)
{
  return *p + *p;
}

I get the following move2.i.139r.subreg:
---
(insn 3 5 4 2 move2.c:56 (set (reg/v/f:SI 30 [ p ])
(reg:SI 5 R10 [ p ])) 6 {movsi} (nil))

(note 4 3 7 2 NOTE_INSN_FUNCTION_BEG)

(insn 7 4 8 2 move2.c:57 (set (reg:QI 31)
(mem:QI (post_inc:SI (reg/v/f:SI 30 [ p ])) [0 S1 A8])) 0
{movqi_mem} (nil))

(insn 8 7 9 2 move2.c:57 (set (reg:SI 27 [ D.1191 ])
(zero_extend:SI (reg:QI 31))) 24 {zero_extendqisi2} (nil))

(insn 9 8 10 2 move2.c:57 (set (reg:QI 32)
(mem:QI (post_inc:SI (reg/v/f:SI 30 [ p ])) [0 S1 A8])) 0
{movqi_mem} (nil))

(insn 10 9 11 2 move2.c:57 (set (reg:SI 26 [ D.1193 ])
(zero_extend:SI (reg:QI 32))) 24 {zero_extendqisi2} (nil))

(insn 11 10 12 2 move2.c:57 (set (reg:SI 33)
(plus:SI (reg:SI 26 [ D.1193 ])
(reg:SI 27 [ D.1191 ]))) 9 {addsi3} (nil))

(insn 12 11 16 2 move2.c:57 (set (reg:SI 28 [  ])
(reg:SI 33)) 6 {movsi} (nil))

(insn 16 12 22 2 move2.c:58 (set (reg/i:SI 5 R10)
(reg:SI 28 [  ])) 6 {movsi} (nil))

(insn 22 16 0 2 move2.c:58 (use (reg/i:SI 5 R10)) -1 (nil))
---
Instruction 3 copies incoming argument in R10 is copied into pseudo
30.  Pseudo 30 is then used at instruction 7 then instruction 9
without either being reloaded or corrected for the post increment.

-- Michael

2009/4/22 Ian Lance Taylor :
> Michael Hope  writes:
>
>> Hi there.  I'm looking at porting GCC to a new architecture which has
>> a quite small instruction set and I'm afraid I can't figure out how to
>> represent unintended side effects on instructions.
>>
>> My current problem is accessing memory.  Reading an aligned 32 bit
>> word is simple using LOADACC, (X).  Half words and bytes are harder as
>> the only instruction available is a load byte with post increment
>> 'LOADACC, (X+)'.
>
> Wow.
>
>> How can I tell GCC that loading a byte also increases the pointer
>> register?  My first version reserved one of the pointer registers and
>> threw away the modified value but this is inefficient.  I suspect that
>> some type of clobber or define_expand is required but I can't figure
>> it out.
>
> Well, you can use a define_expand to generate the move in the first
> place.  If can_create_pseudo_p() returns true, then you can call
> copy_to_reg (addr) to get the address into a register, and you can
> generate the post increment.
>
> (define_expand "movhi"
>  ...
>  if (can_create_pseudo_p () && MEM_P (operands[1]))
>    {
>      rtx reg = copy_to_reg (XEXP (operands[1], 0));
>      emit_insn (gen_movhi_insn (operands[0], reg));
>      DONE;
>    }
>  ...
> )
>
> (define_insn "movhi_insn"
>  [(set (match_operand:HI 0 ...)
>        (mem:HI (post_inc:P (match_operand:P 1 "register_operand" ...]
>  ...
> )
>
> The difficulties are going to come in reload.  Reload will want to load
> and store 16-bit values in order to spill registers.  You will need a
> scratch register to dothis, and that means that you need to implement
> TARGET_SECONDARY_RELOAD.  This is complicated:read the docs carefully
> and look at the existing examples.
>
> Ian
>

gcc-4.5-20090423 is now available

[gccadmin]

Snapshot gcc-4.5-20090423 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090423/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 146658

You'll find:

gcc-4.5-20090423.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.5-20090423.tar.bz2 C front end and core compiler

gcc-ada-4.5-20090423.tar.bz2  Ada front end and runtime

gcc-fortran-4.5-20090423.tar.bz2  Fortran front end and runtime

gcc-g++-4.5-20090423.tar.bz2  C++ front end and runtime

gcc-java-4.5-20090423.tar.bz2 Java front end and runtime

gcc-objc-4.5-20090423.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.5-20090423.tar.bz2The GCC testsuite

Diffs from 4.5-20090416 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

16 bits char string from C to FORTRAN

[Americo Barbosa da Cunha Junior]

Hello there,

I'm  calling a FORTRAN subroutine in a ANSI C program. The subroutine
has the following prototype:

C:

void CKINIT_(int *LENICK,int *LENRCK,int *LENCCK,int *LINC,int *LOUT,
    int *ICKWRK,double *RCKWRK,char *CCKWRK,int *IFLAG);

FORTRAN:

  SUBROUTINE CKINIT (LENIWK, LENRWK, LENCWK, LINC, LOUT, ICKWRK,
 1   RCKWRK, CCKWRK, IFLAG)
C
C  START PROLOGUE
C
C  SUBROUTINE CKINIT (LENIWK, LENRWK, LENCWK, LINC, LOUT, ICKWRK,
C RCKWRK, CCKWRK, IFLAG)*
C Reads the binary file and creates the internal work arrays
C ICKWRK, CCKWRK, and RCKWORK.  CKINIT must be called before any
C other CHEMKIN subroutine is called.  The work arrays must then
C be made available as input to the other CHEMKIN subroutines.
C
C  INPUT
C LENIWK - Length of the integer work array, ICKWRK.
C   Data type - integer scalar
C LENCWK - Length of the character work array, CCKWRK.
C  The minimum length of CCKWRK(*) is MM + KK.
C   Data type - integer scalar
C LENRWK - Length of the real work array, WORK.
C   Data type - integer scalar
C LINC  -  Logical file number for the binary file.
C   Data type - integer scalar
C LOUT  -  Output file for printed diagnostics.
C   Data type - integer scalar
C
C  OUTPUT
C ICKWRK - Array of integer workspace.
C   Data type - integer array
C   Dimension ICKWRK(*) at least LENIWK.
C RCKWRK - Array of real work space.
C   Data type - real array
C   Dimension RCKWRK(*) at least LENRWK.
C CCKWRK - Array of character work space.
C   Data type - CHARACTER*16 array
C   Dimension CCKWRK(*) at least LENCWK.
C IFLAG  - IFLAG=0 indicates successful reading of
C  binary linking file; IFLAG>0 indicates
C  error type.
C   Data type - integer
C  END PROLOGUE


The char* string passed to CKINIT must be at least 16 bits
(CHARACTER*16) or the program is finished with the error message:

  CHARACTER LENGTH OF CCKWRK MUST BE AT LEAST 16


I've tried to change the length of the char type in C redefining
CHAR_BIT constant:

#include 
#define CHAR_BIT 16


The program compiles without errors but every time that it is executed
the error message above is returned.

I'll become extremely grateful if someone can help me.


Thank you in advance.

Americo Cunha Jr
http://web.me.com/americo

Re: GCC 4.5: "nonconstant array index in initializer" error

[James Dennett]

On Thu, Apr 23, 2009 at 1:38 PM, Denis Onischenko
 wrote:
> The minimal code example is following:
>
>
> extern unsigned int __invalid_size_argument;
> #define TYPECHECK(t)    ( sizeof(t) == sizeof(t[1]) ?  sizeof(t) :
> __invalid_size_argument )
>
> static int arr[] = {
>        [TYPECHECK(int)] = 0,
> };
>
> int main()
> {
>  return 0;
> }
>
>
> command line is: gcc test.c
>
> GCC 4.5.0 revision 146607 compiles this code with following errors:
> test.c:5: error: nonconstant array index in initializer
> test.c:5: error: (near initialization for 'arr')
>
> released GCC 4.4.0 compiles without any errors

A diagnostic is required in standards-conforming modes, as
TYPECHECK(int) is not an "integral constant expression" (because it
includes a non-constant in a potentially-evaluated operand).

-- James

Re: Side effects on memory access

[Ian Lance Taylor]

Michael Hope  writes:

> (define_expand "movqi"
>   [(set (match_operand:QI 0 "nonimmediate_operand")
>   (match_operand:QI 1 "general_operand" ""))]
>   ""
>   {
> if (can_create_pseudo_p () && MEM_P (operands[1]))
>   {
>   rtx reg = copy_to_reg (XEXP (operands[1], 0));
>   emit_insn (gen_movqi_mem (operands[0], reg));
>   DONE;
>   }
>   }
> )

It's hideous, but you're going to need to do

insn = emit_insn (gen_movqi_mem (operands[0], reg));
add_reg_note (insn, REG_INC, reg);

add_reg_note is pretty new; if you don't have it in your sources, it
amounts to

REG_NOTES (insn) = gen_rtx_EXPR_LIST (REG_INC, reg, REG_NOTES (insn));

Ian

testsuite fixes for small doubles

[DJ Delorie]

SH (and I'm sure others) has some multilibs (like -m2a-single-only)
where sizeof(double) is 4, which breaks some testcases.  Here's a
patch which adds checks for small doubles (and small long doubles),
and adjusts some of the tests which depend on large doubles.
Comments?  Ok to apply?


* lib/target-supports.exp (check_effective_target_double64): New.
(check_effective_target_double64plus): New.
(check_effective_target_large_double): New.
* gcc.dg/Wconversion-real-integer.c: Require double64plus.
* gcc.dg/div-double-1.c: Likewise.
* gcc.dg/Wconversion-real.c: Require large_double.
* gcc.dg/cdce1.c: Require large_double instead of checking targets.

* gcc.c-torture/execute/ieee/unsafe-fp-assoc-1.c: Skip if
doubles are too small.

* gcc.c-torture/execute/ieee/20010226-1.c: Mark all floating point
constants as long.

* gcc.dg/torture/fp-int-convert-long-double.c (main): Check
long double vs long long sizes.


Index: gcc.c-torture/execute/ieee/unsafe-fp-assoc-1.c
===
--- gcc.c-torture/execute/ieee/unsafe-fp-assoc-1.c  (revision 146652)
+++ gcc.c-torture/execute/ieee/unsafe-fp-assoc-1.c  (working copy)
@@ -29,9 +29,11 @@ void func ( double x )
}
  return;
 }
 
 int main()
 {
+   if (sizeof (double) == 4)
+   return 0;
func((double)1.00);
return 0;
 }
Index: gcc.c-torture/execute/ieee/20010226-1.c
===
--- gcc.c-torture/execute/ieee/20010226-1.c (revision 146652)
+++ gcc.c-torture/execute/ieee/20010226-1.c (working copy)
@@ -1,23 +1,23 @@
 #include 
 
-long double dfrom = 1.1;
+long double dfrom = 1.1L;
 long double m1;
 long double m2;
 unsigned long mant_long;
 
 int main()
 {
   /* Some targets don't support a conforming long double type.  This is
  common with very small parts which set long double == float.   Look
  to see if the type has at least 32 bits of precision.  */
   if (LDBL_EPSILON > 0x1p-31L)
 return 0;
 
-  m1 = dfrom / 2.0;
-  m2 = m1 * 4294967296.0;
+  m1 = dfrom / 2.0L;
+  m2 = m1 * 4294967296.0L;
   mant_long = ((unsigned long) m2) & 0x;
 
   if (mant_long == 0x8ccc)
 return 0;
   else
 abort();
Index: gcc.dg/Wconversion-real.c
===
--- gcc.dg/Wconversion-real.c   (revision 146652)
+++ gcc.dg/Wconversion-real.c   (working copy)
@@ -1,11 +1,12 @@
 /* Test for diagnostics for Wconversion for floating-point.  */
 
 /* { dg-do compile } */
 /* { dg-skip-if "doubles are floats" { "avr-*-*" } { "*" } { "" } } */
 /* { dg-options "-std=c99 -Wconversion" } */
+/* { dg-require-effective-target large_double } */
 
 float  vfloat;
 double vdouble;
 long double vlongdouble;
 
 void ffloat (float f);
Index: gcc.dg/cdce1.c
===
--- gcc.dg/cdce1.c  (revision 146652)
+++ gcc.dg/cdce1.c  (working copy)
@@ -1,11 +1,11 @@
 /* { dg-do  run  } */
-/* { dg-skip-if "doubles are floats" { "avr-*-*" "m32c-*-*" } { "*" } { "" } } 
*/
 /* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details  -lm" } */
 /* { dg-final { scan-tree-dump  "cdce1.c:16: note: function call is 
shrink-wrapped into error conditions\."  "cdce" } } */
 /* { dg-final { cleanup-tree-dump "cdce" } } */
+/* { dg-require-effective-target large_double } */
 
 #include 
 #include 
 #include 
 int total_err_count = 0;
 double foo_opt (int x, double y) __attribute__((noinline));
Index: gcc.dg/torture/fp-int-convert-long-double.c
===
--- gcc.dg/torture/fp-int-convert-long-double.c (revision 146652)
+++ gcc.dg/torture/fp-int-convert-long-double.c (working copy)
@@ -10,9 +10,12 @@ int
 main (void)
 {
   TEST_I_F(signed char, unsigned char, long double, LDBL_MANT_DIG);
   TEST_I_F(signed short, unsigned short, long double, LDBL_MANT_DIG);
   TEST_I_F(signed int, unsigned int, long double, LDBL_MANT_DIG);
   TEST_I_F(signed long, unsigned long, long double, LDBL_MANT_DIG);
-  TEST_I_F(signed long long, unsigned long long, long double, LDBL_MANT_DIG);
+  if (sizeof(long double) > sizeof(long long))
+{
+  TEST_I_F(signed long long, unsigned long long, long double, 
LDBL_MANT_DIG);
+}
   exit (0);
 }
Index: gcc.dg/Wconversion-real-integer.c
===
--- gcc.dg/Wconversion-real-integer.c   (revision 146652)
+++ gcc.dg/Wconversion-real-integer.c   (working copy)
@@ -2,12 +2,13 @@
integers.  */
 
 /* { dg-do compile }
 /* { dg-skip-if "doubles are floats,ints are 16bits" { "avr-*-*" } { "*" } { 
"" } } */
 /* { dg-options "-std=c99 -Wconversion" } */
 /* { dg-require-effective-target int32plus } */
+/* { dg-require-effective-target double64plus } */
 #include 
 
 void fsi (si

Re: GCC 4.5: "nonconstant array index in initializer" error

[Joe Buck]

On Thu, Apr 23, 2009 at 1:38 PM, Denis Onischenko
>  wrote:
> > The minimal code example is following:
> >
> >
> > extern unsigned int __invalid_size_argument;
> > #define TYPECHECK(t)( sizeof(t) == sizeof(t[1]) ?  sizeof(t) :
> > __invalid_size_argument )
> >
> > static int arr[] = {
> >[TYPECHECK(int)] = 0,
> > };
> >
> > int main()
> > {
> >  return 0;
> > }
> >
> >
> > command line is: gcc test.c
> >
> > GCC 4.5.0 revision 146607 compiles this code with following errors:
> > test.c:5: error: nonconstant array index in initializer
> > test.c:5: error: (near initialization for 'arr')
> >
> > released GCC 4.4.0 compiles without any errors

On Thu, Apr 23, 2009 at 04:58:17PM -0700, James Dennett wrote:
> A diagnostic is required in standards-conforming modes, as
> TYPECHECK(int) is not an "integral constant expression" (because it
> includes a non-constant in a potentially-evaluated operand).

But there are cases where we avoid issuing such a diagnostic by
default, without flags such as -pedantic or calling out a specific
language standard.

The compiler is not supposed to be pedantic by default.  A standards
document saying that a diagnostic is required should not be the end
of the story, especially when we're talking about important, widely
used code bases.

Re: GCC 4.5: "nonconstant array index in initializer" error

[James Dennett]

On Thu, Apr 23, 2009 at 5:39 PM, Joe Buck  wrote:
>
> On Thu, Apr 23, 2009 at 1:38 PM, Denis Onischenko
>>  wrote:
>> > The minimal code example is following:
>> >
>> >
>> > extern unsigned int __invalid_size_argument;
>> > #define TYPECHECK(t)    ( sizeof(t) == sizeof(t[1]) ?  sizeof(t) :
>> > __invalid_size_argument )
>> >
>> > static int arr[] = {
>> >        [TYPECHECK(int)] = 0,
>> > };
>> >
>> > int main()
>> > {
>> >  return 0;
>> > }
>> >
>> >
>> > command line is: gcc test.c
>> >
>> > GCC 4.5.0 revision 146607 compiles this code with following errors:
>> > test.c:5: error: nonconstant array index in initializer
>> > test.c:5: error: (near initialization for 'arr')
>> >
>> > released GCC 4.4.0 compiles without any errors
>
> On Thu, Apr 23, 2009 at 04:58:17PM -0700, James Dennett wrote:
>> A diagnostic is required in standards-conforming modes, as
>> TYPECHECK(int) is not an "integral constant expression" (because it
>> includes a non-constant in a potentially-evaluated operand).
>
> But there are cases where we avoid issuing such a diagnostic by
> default, without flags such as -pedantic or calling out a specific
> language standard.
>
> The compiler is not supposed to be pedantic by default.  A standards
> document saying that a diagnostic is required should not be the end
> of the story, especially when we're talking about important, widely
> used code bases.

Very true.  Note that I explicitly refer only to "standards-conforming
modes".  Generating warnings for idiomatic use of system headers is
not good for usability, though sometimes hard to avoid.

-- James

Re: testsuite fixes for small doubles

[Kaveh R. GHAZI]

On Thu, 23 Apr 2009, DJ Delorie wrote:

> +# Return 1 if the target supports double larger than float,
> +# 0 otherwise.
> +
> +proc check_effective_target_large_double { } {
> +return [check_no_compiler_messages large_double object {
> + int dummy[sizeof(double) < sizeof(float) ? 1 : -1];
> +}]


Isn't that comparison reversed?

Re: testsuite fixes for small doubles

[DJ Delorie]

> On Thu, 23 Apr 2009, DJ Delorie wrote:
> > +# Return 1 if the target supports double larger than float,
> > +# 0 otherwise.
> > +
> > +proc check_effective_target_large_double { } {
> > +return [check_no_compiler_messages large_double object {
> > +   int dummy[sizeof(double) < sizeof(float) ? 1 : -1];
> > +}]
> 
> Isn't that comparison reversed?

Yes, yes it is.  After the first funny test case (which I reported
earlier), I double checked every test I put in.  This one got left in
the "reversed" test state.  Fixed.

[plugins] Name for pass_all_optimizations

[Justin Seyster]

I'm working on porting a plug-in designed for the old
branches/plugin branch to the (recently merged) shiny new
branches/plugins branch.  One thing that's turning out to be tricky is
placing the plug-in transform in exactly the same place.  In the old
branch, plug-ins hook in just before the pass_all_optimizations
passes.  I want to specify pass_all_optimizations as the reference
pass for register_callback(), but pass_all_optimizations doesn't have
a name (the name field is NULL).
Unless that's not a good place to put plug-in passes, I propose
giving the pass_all_optimizations pass the name "all_optimizations."
I believe that there are a handful of other unnamed passes that might
also be useful for plug-in developers.
--Justin

Re: GCC 4.5: "nonconstant array index in initializer" error

[Miles Bader]

Joe Buck  writes:
> The compiler is not supposed to be pedantic by default.  A standards
> document saying that a diagnostic is required should not be the end
> of the story, especially when we're talking about important, widely
> used code bases.

Sure, but at least your example code seems pretty dodgy -- it would be
quite reasonable to argue that even a compiler in "practical mode" (as
opposed to "pedantic mode") should reject it.

-Miles

-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

gcc-4.4.0.tar.gz.sig, expired key

[Keith Thompson]

gcc-4.4.0.tar.gz.sig was generated with an expired key:

gpg: Signature made Tue 21 Apr 2009 07:35:29 AM PDT using DSA key ID C3C45C06
gpg: Good signature from "Jakub Jelinek "
gpg: Note: This key has expired!
Primary key fingerprint: 33C2 35A3 4C46 AA3F FB29  3709 A328 C3A2 C3C4 5C06

I'm using ftp://ftp.gnu.org/gnu/gnu-keyring.gpg, downloaded after I
downloaded gcc-4.4.0.tar.gz.sig.

-- 
Keith Thompson (The_Other_Keith) k...@mib.org  
Nokia
"We must do something.  This is something.  Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: 16 bits char string from C to FORTRAN

[Ian Lance Taylor]

Americo Barbosa da Cunha Junior  writes:

> I'm  calling a FORTRAN subroutine in a ANSI C program. The subroutine
> has the following prototype:

This message is not appropriate for the mailing list gcc@gcc.gnu.org,
which is for gcc developers.  This question would have been appropriate
on gcc-h...@gcc.gnu.org or fort...@gcc.gnu.org.  Thanks.


> I've tried to change the length of the char type in C redefining
> CHAR_BIT constant:
>
> #include 
> #define CHAR_BIT 16

Doing that does not change the size of the char type.  Unless you are
using an unusual embedded processor, the size of char in C is always 8.

If you need a string whose characters are a different length, you need
to use a wide character string, via L"".  Wide characters in C is a
general topic in C and is not specific to gcc, and this mailing list is
not the right place to discuss them.

Ian

Re: 16 bits char string from C to FORTRAN

[Americo Barbosa da Cunha Junior]

Sorry for my mistake. I'll send the message to the appropriate mailing list.

Americo


On Fri, Apr 24, 2009 at 12:31 AM, Ian Lance Taylor  wrote:
> Americo Barbosa da Cunha Junior  writes:
>
>> I'm  calling a FORTRAN subroutine in a ANSI C program. The subroutine
>> has the following prototype:
>
> This message is not appropriate for the mailing list gcc@gcc.gnu.org,
> which is for gcc developers.  This question would have been appropriate
> on gcc-h...@gcc.gnu.org or fort...@gcc.gnu.org.  Thanks.
>
>
>> I've tried to change the length of the char type in C redefining
>> CHAR_BIT constant:
>>
>> #include 
>> #define CHAR_BIT 16
>
> Doing that does not change the size of the char type.  Unless you are
> using an unusual embedded processor, the size of char in C is always 8.
>
> If you need a string whose characters are a different length, you need
> to use a wide character string, via L"".  Wide characters in C is a
> general topic in C and is not specific to gcc, and this mailing list is
> not the right place to discuss them.
>
> Ian
>