Successfull build of gcc-4.4.0 [gcc-4_4-branch revision 145224] for target x86_64-pc-mingw32 (cross build from i686-pc-cygwin)

[Rainer Emrich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Compiler version: 4.4.0 20090329 (prerelease) [gcc-4_4-branch revision 145224]
(GCC)
Platform: x86_64-pc-mingw32
configure flags:
- --prefix=/opt/devel/gnu/cross-gcc/gcc-4.4.0/mingw/x86_64-pc-mingw32/mingw
- 
--with-sysroot=/opt/devel/gnu/cross-gcc/gcc-4.4.0/mingw/x86_64-pc-mingw32/mingw
- --with-gmp=/opt/devel/gnu/gcc/gcc-4.4.0/i686-pc-cygwin
- --with-mpfr=/opt/devel/gnu/gcc/gcc-4.4.0/i686-pc-cygwin --build=i686-pc-cygwin
- --host=i686-pc-cygwin --target=x86_64-pc-mingw32 --disable-bootstrap
- --with-gnu-as
-
--with-as=/opt/devel/gnu/cross-gcc/gcc-4.4.0/mingw/x86_64-pc-mingw32/mingw/bin/x86_64-pc-mingw32-as.exe
- --with-gnu-ld
-
--with-ld=/opt/devel/gnu/cross-gcc/gcc-4.4.0/mingw/x86_64-pc-mingw32/mingw/bin/x86_64-pc-mingw32-ld.exe
- --enable-checking=release 
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++
- --enable-libgomp

binutils:
binutils-2.19.51.20090329


Build system:
CYGWIN_NT-5.2-WOW64 kasandra 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin

cc for building:
gcc-4.4.0 revision 145224
i686-pc-cygwin-gcc (GCC) 4.4.0 20090329 (prerelease) [gcc-4_4-branch revision
145224]
Copyright (C) 2009 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.

as for building:
GNU assembler (GNU Binutils) 2.19.51.20090329
Copyright 2008 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of \`i686-pc-cygwin'.

ld for building:
GNU ld (GNU Binutils) 2.19.51.20090329
Copyright 2008 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

testresults:

http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg03193.html


There are three major issues.

1.) The acats testsuite is completely broken, doesn't run at all.

2.) libgomp is completely broken. I'm using the pthread for windows
implementation from the mingw-64 site. For the testsuite the neccessary header
files are not found.

set_ld_library_path_env_vars:
ld_library_path=.:/home/rainer/software/build/i686-pc-cygwin_cross_x86_64-pc-mingw32/gcc-4.4.0/gcc/x86_64-pc-mingw32/./libgomp/.libs:/home/rainer/software/build/i686-pc-cygwin_cross_x86_64-pc-mingw32/gcc-4.4.0/gcc/gcc
Executing on host:
/home/rainer/software/build/i686-pc-cygwin_cross_x86_64-pc-mingw32/gcc-4.4.0/gcc/gcc/xgcc
-
-B/home/rainer/software/build/i686-pc-cygwin_cross_x86_64-pc-mingw32/gcc-4.4.0/gcc/gcc/
/home/rainer/software/src/gcc-4.4.0/libgomp/testsuite/libgomp.c/appendix-a/a.15.1.c
 
-B/home/rainer/software/build/i686-pc-cygwin_cross_x86_64-pc-mingw32/gcc-4.4.0/gcc/x86_64-pc-mingw32/./libgomp/
-
-I/home/rainer/software/build/i686-pc-cygwin_cross_x86_64-pc-mingw32/gcc-4.4.0/gcc/x86_64-pc-mingw32/./libgomp
- -I/home/rainer/software/src/gcc-4.4.0/libgomp/testsuite/.. -fmessage-length=0
- -fopenmp  -O2
-
-L/home/rainer/software/build/i686-pc-cygwin_cross_x86_64-pc-mingw32/gcc-4.4.0/gcc/x86_64-pc-mingw32/./libgomp/.libs
- -lgomp -lm   -o ./a.15.1.exe(timeout = 300)
spawn
/home/rainer/software/build/i686-pc-cygwin_cross_x86_64-pc-mingw32/gcc-4.4.0/gcc/gcc/xgcc
-
-B/home/rainer/software/build/i686-pc-cygwin_cross_x86_64-pc-mingw32/gcc-4.4.0/gcc/gcc/
/home/rainer/software/src/gcc-4.4.0/libgomp/testsuite/libgomp.c/appendix-a/a.15.1.c
-
-B/home/rainer/software/build/i686-pc-cygwin_cross_x86_64-pc-mingw32/gcc-4.4.0/gcc/x86_64-pc-mingw32/./libgomp/
-
-I/home/rainer/software/build/i686-pc-cygwin_cross_x86_64-pc-mingw32/gcc-4.4.0/gcc/x86_64-pc-mingw32/./libgomp
- -I/home/rainer/software/src/gcc-4.4.0/libgomp/testsuite/.. -fmessage-length=0
- -fopenmp -O2
-
-L/home/rainer/software/build/i686-pc-cygwin_cross_x86_64-pc-mingw32/gcc-4.4.0/gcc/x86_64-pc-mingw32/./libgomp/.libs
- -lgomp -lm -o ./a.15.1.exe
/home/rainer/software/src/gcc-4.4.0/libgomp/testsuite/libgomp.c/appendix-a/a.15.1.c:3:19:
error: stdio.h: No such file or directory
/home/rainer/software/src/gcc-4.4.0/libgomp/testsuite/libgomp.c/appendix-a/a.15.1.c:
In function 'work':
/home/rainer/software/src/gcc-4.4.0/libgomp/testsuite/libgomp.c/appendix-a/a.15.1.c:8:
warning: incompatible implicit declaration of built-in function 'printf'
compiler exited with status 1
output is:
/home/rainer/software/src/gcc-4.4.0/libgomp/testsuite/libgomp.c/appendix-a/a.15.1.c:3:19:
error: stdio.h: No such file or directory
/home/rainer/software/src/gcc-4.4.0/libgomp/testsuite/libgomp.c/appendix-a/a.15.1.c:
In function 'work':
/home/rainer/software/src/gcc-4.4.0/libgomp/testsuite/libgomp.c/appendix-a/a.15.1.c:8:
warning: incompatible implicit declaration of built-in function 'printf'

FAIL: libgomp.c/appendix-a/a.15.1.c (test for excess errors)

3.) g

Re: {gSoc}application : Automatic parallelization in Graphite

[Razya Ladelsky]

Tobias Grosser  wrote on 26/03/2009 09:17:26:

> On Thu, 2009-03-26 at 10:36 +0800, Li Feng wrote:
> > Hi all,
> > 
> > Below is the proposal of this gSoc project.  I'd really like you 
review and
> > comment on this and then I can plan this project better.
> 
> Hi Li,
> 
> this looks nice. Thanks for your work on this.
> 
> Tobias
> 
> > 
> > Thanks,
> > Li Feng
> > 
> 

> > #title Automatic parallelization in Graphite
> > 
> > * Synopsis
> > 
> > With the integration of Graphite to GCC4.4, a strong loop nest
> > analysis and transformation engine was introduced. But now it
> > does only non-parallel loop generation. My work is to detect
> > synchronization free parallel loops and generate parallel code
> > for them, which will mainly enables programs to run faster.
> > 
> [..]
> 
> > * Road-map
> > 
> >  1. Since data dependency analysis is not available, I will firstly
> > integrate autopar's code generation to Graphite. This work will
> > be done step by step.(Mid June)
> > - Introduce a flag -fgraphite-parallelize that forces auto-
> parallelization
> >   for all loops.
> > - Make sure the loops Graphite creates can be handled by the 
autopar's
> >   code generation.
> > - Call autopar for every loop.(The loops that can not be 
paralleled will
> >   just fail/crash.)
> 
> I think on this point we should discuss with Razya and the others where
> your work ends.  Just adapting autopar to handle all graphite loops is a
> project on its own. So I do not think it can be done by you in two
> weeks.
> 
> >  2. Write test cases for the loops that can be parallelized. This 
> will take a
> > few discussions with Graphite developers to see which kind
> > of loops we will should detect and can be auto-parallelized.(End 
June)
> >  3. Write code for parallel code detection. This part of job will 
based on
> > SCoP detection and data dependency, and at this time, data 
dependency
> > analysis should have been done. This part of work will take most 
of
> > the time.(First week of August)
> 
> How much time this point takes depends how exact you want to solve it. I
> think a correct but conservative implementation might be written in a
> week. If you want to detect all loops it will take you more time.
> 
> >  4. Code cleaning and write documents.(Second week of August)
> 
> I think it is useful to define the limits of your work a little bit
> stricter. For me there are two options:
> 
> 1. You stay more on the autopar/gimple side (Step 1) and adapt autopar
> for graphite. This is very necessary for graphite, but it might need
> some time to get up to speed in autopar.
> 
> 2. You stay more on the graphite/polyhedral side. You work on all these
> steps, but we limit step 1 to the graphite internal parts. This means
> you connect autopar to graphite and try to generate parallel loop nests.
> If autopar can not handle a loop nest you analyse it and write a bug
> report. Someone else will extend autopar.
> 
> As Razya already has some knowlege about autopar and she is also
> interested in working on parallelization maybe she is able to support
> you with the autopar stuff? So you might be able to actually focus more
> on the polyhedral part.

I think this sounds like a good plan for the parallel code generation part 
(phase 1)
Li will focus more on the Graphite side  and I will contribute on the 
gimple side.

Razya

> 
> > * Profit for GCC
> > 
> >  - When the auto-parallelization has been done in Graphite, developer
> >can mostly take their effort to loop transformations. Graphite will
> 
> be
> 
> >in charge of optimizations(generate parallelism) and the autopar
> >code in Graphite will just detect and generate code for them.
> 
> 
> 
> Tobias
> 

gcc.gnu.org ftp down?

[Jack Howarth]

  Does anyone know why the gcc.gnu.org ftp site
is no longer available? Oddly it seems to have
also disappeared for at least one of the ftp
mirrors in the last day as well...

ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc

Are we supposed to access the gcc infrastructure
directories from the main gnu ftp site now?
   Jack

gcc99 inlining rules

[Bingfeng Mei]

Hello, 
I found the following code doesn't compile with gcc4.4. and -std=c99. Does this 
behaviour conform to standard? 
 
inline int foo(){
  return 10;
}
 
int main(int argc, char **argv){
  return foo();
}

I goolged the c99 inlining rule as follows. They does't seem to say such code 
cannot be compiled. 
 
C99 inline rules

The specification for "inline" is section 6.7.4 of the C99 standard (ISO/IEC 
9899:1999). This isn't freely available, but you can buy a PDF of it from ISO 
relatively cheaply.

*

  A function where all the declarations (including the definition) mention 
"inline" and never "extern". There must be a definition in the same translation 
unit. No stand-alone object code is emitted. You can (must?) have a separate 
(not inline) definition in another translation unit, and the compiler might 
choose either that or the inline definition.

  Such functions may not contain modifiable static variables, and may not 
refer to static variables or functions elsewhere in the source file where they 
are declared.
*

  A function where at least one declaration mentions "inline", but where 
some declaration doesn't mention "inline" or does mention "extern". There must 
be a definition in the same translation unit. Stand-alone object code is 
emitted (just like a normal function) and can be called from other translation 
units in your program.

  The same constraint about statics above applies here, too.
* A function defined "static inline". A local definition may be emitted if 
required. You can have multiple definitions in your program, in different 
translation units, and it will still work. This is the same as the GNU C rules.


Cheers,
Bingfeng Mei

Re: gcc99 inlining rules

[Richard Guenther]

On Tue, Mar 31, 2009 at 4:24 PM, Bingfeng Mei  wrote:
> Hello,
> I found the following code doesn't compile with gcc4.4. and -std=c99. Does 
> this behaviour conform to standard?
>
> inline int foo(){
>  return 10;
> }
>
> int main(int argc, char **argv){
>  return foo();
> }

It works for me.  What is your error?

Richard.

Re: gcc99 inlining rules

[Joseph S. Myers]

On Tue, 31 Mar 2009, Bingfeng Mei wrote:

> Hello, 
> I found the following code doesn't compile with gcc4.4. and -std=c99. 
> Does this behaviour conform to standard?

It does compile.  It may or may not link depending on compilation options, 
since you are missing an external definition for foo, so this is not a 
valid program without another translation unit with such a definition.

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

new cloog-ppl-0.15.tar.gz broken on darwin

[Jack Howarth]

   The gcc.gnu.org ftp server is back up. However, the newer
cloog-ppl-0.15.tar.gz in the infrastructure directory is broken
on darwin. The size is now much smaller which makes me suspect that
autogen.sh wasn't run before the tarball was created. On darwin,
the build fails with...

/bin/sh ./libtool --mode=link gcc -Wall -fomit-frame-pointer -g -O2  -L/sw/lib 
-L/sw/lib -o cloog  cloog.o libcloog.la -lgmp -lppl_c -lppl -lgmpxx
gcc -Wall -fomit-frame-pointer -g -O2 -o .libs/cloog cloog.o  -L/sw/lib 
./.libs/libcloog.dylib /sw/lib/libppl_c.dylib /sw/lib/libppl.dylib -lm 
/sw/lib/libgmpxx.dylib /sw/lib/libgmp.dylib
creating cloog
cd . && /bin/sh /sw/src/fink.build/cloog-0.15-1/cloog-ppl/autoconf/missing 
--run autoheader
autoheader: warning: missing template: HAS_SYS_RESOURCE_H
autoheader: Use AC_DEFINE([HAS_SYS_RESOURCE_H], [], [Description])
make[1]: *** [include/cloog/cloog-config.h.in] Error 1
make: *** [all-recursive] Error 1
### execution of make failed, exit code 2

Re: gcc.gnu.org ftp down?

[Ian Lance Taylor]

Jack Howarth  writes:

>   Does anyone know why the gcc.gnu.org ftp site
> is no longer available?

FTP on gcc.gnu.org is up again.  The outage was accidentally caused
while updating the machine.  Thanks for reporting it.

Ian

RE: gcc99 inlining rules

[Bingfeng Mei]

Link error. 

/tmp/ccqpP1D1.o: In function `main':
tst.c:(.text+0x15): undefined reference to `foo'
collect2: ld returned 1 exit status


As Joseph said, I found the original text in c99 standard in section 6.7.4.

"
EXAMPLE The declaration of an inline function with external linkage can result 
in either an external
definition, or a definition available for use only within the translation unit. 
A file scope declaration with
extern creates an external definition. The following example shows an entire 
translation unit.
inline double fahr(double t)
{
return (9.0 * t) / 5.0 + 32.0;
}
inline double cels(double t)
{
return (5.0 * (t - 32.0)) / 9.0;
}
extern double fahr(double); // creates an external definition
double convert(int is_fahr, double temp)
{
/* A translator may perform inline substitutions */
return is_fahr ? cels(temp) : fahr(temp);
}
8 Note that the definition of fahr is an external definition because fahr is 
also declared with extern, but
the definition of cels is an inline definition. Because cels has external 
linkage and is referenced, an
external definition has to appear in another translation unit (see 6.9); the 
inline definition and the external
definition are distinct and either may be used for the call. "

I understand now the GCC implementation conforms to c99, but don't see 
rationale behind it :-). Anyway,
this is not gcc dev question any more.

Cheers,
Bingfeng
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com] 
> Sent: 31 March 2009 15:32
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: Re: gcc99 inlining rules
> 
> On Tue, Mar 31, 2009 at 4:24 PM, Bingfeng Mei 
>  wrote:
> > Hello,
> > I found the following code doesn't compile with gcc4.4. and 
> -std=c99. Does this behaviour conform to standard?
> >
> > inline int foo(){
> >  return 10;
> > }
> >
> > int main(int argc, char **argv){
> >  return foo();
> > }
> 
> It works for me.  What is your error?
> 
> Richard.
> 
> 

RE: GCC at Google Summer of Code'2009

[Grigori Fursin]

Hi Phil,

Sorry I couldn't reply earlier to your email (have a few deadlines at the 
moment)
so will reply here:

I would be extremely interested to see the support for OpenCL and either GPU
or CELL implemented in GCC. My personal interest here is to extend work on
adaptive scheduling. A few years ago together with UPC colleagues I started a 
small project 
to do predictive code scheduling and data manipulation for heterogeneous
processors. We used CUDA and CPU/GPU processors. The projects stalled
but we managed to get some preliminary results - if you are interested you can
find more info about run-time predictive scheduling at this paper and 
presentation:

http://unidapt.org/index.php/Dissemination#JGVP2009

I will not be available much this summer due to personal constraints, but if 
you will
manage to get support for this work, I would be interested to see if we can 
connect
this framework with the Collective Optimization Framework at the end to 
automatically learn how to 
predict good scheduling strategy based on kernel and dataset parameters. This 
relates to your 
"Able to manage scheduling, compute and memory resources"...

Take care and good luck,
Grigori


Paolo,

Thanks for the feedback, I am not very experienced in compilers so it
is hard to judge how long a task will take...

By sharing I meant sharing of code between NVIDIA and GCC.  It
probably won't happen I guess.

Here is my proposal for an OpenCL runtime with a target runtime as
well.  If you think it is too ambitious or not
ambitious enough, I will change it.
=

Project Title:
Make the OpenCL Platform Layer API and Runtime API for the Cell
Processor and CPUs.

Project Synopsis:
The aim of this project is to create an implementation that supports
the Platform Layer API
and Runtime API of OpenCL that can target the Cell Processor and CPUs.
The Platform
Layer API is:
-A hardware abstraction layer over diverse computational resources
-An interface to query, select and initialize compute devices
-An interface to create compute devices and work-queues
The Runtime API is:
-Able to execute compute kernels
-Able to manage scheduling, compute and memory resources (I am
confused as to the wording
of this, does it mean: manage the scheduling of compute and memory resources?)
(Source http://www.khronos.org/developers/library/overview/opencl_overview.pdf,
page 13).

This project will use the existing gcc and ppu-gcc/spu-gcc compilers for offline
compilation of binary programs.

Project Details:
(Part 1)
In this project I will make a C library and runtime that supports some
of the functions listed
here: http://www.khronos.org/registry/cl/api/1.0/cl.h
Specifically I will add support for:
clGetPlatformInfo - Get info about OpenCL
clGetDeviceIDs - Get what devices are supported on system
clGetDeviceInfo - Get info about a specific device
clCreateContext - Create an OpenCL context
clReleaseContext - Release an OpenCL context
clCreateCommandQueue - Create a command-queue on a specific device
clReleaseCommandQueue - Release a command-queue
clCreateBuffer - Create a buffer object
clEnqueueReadBuffer - Enqueue a read
clEnqueueWriteBuffer - Enqueue a write
clCreateProgramWithBinary - Create a program object from a pre-compiled binary.
clReleaseProgram - Release a program object
clCreateKernel - Create a kernel object
clReleaseKernel - Release a kernel object
clSetKernelArg - Set the kernel arguments
clEnqueueNDRangeKernel - Enqueue a command to execute a kernel on a device
clEnqueueTask - Enqueue a single work item
clWaitForEvents - Wait for events to complete
clReleaseEvent - Release an event

This will allow for rudimentary launches of CPU and Cell kernels in a
common interface.  Any functions
that are required for the above to work will also be added.  The
OpenCL compiler will not be implemented.

(Part 2)
Also, a runtime library for the target (CPU or Cell) must be created
that includes the following intrinsics:
Information Functions: (section 6.11.1 of
http://www.khronos.org/registry/cl/specs/opencl-1.0.33.pdf)
uint get_work_dim ()
size_t get_global_size (uint dimindx)
size_t get_global_id (uint dimindx)
size_t get_local_size (uint dimindx)
size_t get_local_id (uint dimindx)
size_t get_num_groups (uint dimindx)
size_t get_group_id (uint dimindx)
Synchronization Functions: (sections 6.11.9 - 6.11.10 of
http://www.khronos.org/registry/cl/specs/opencl-1.0.33.pdf)
void barrier (cl_mem_fence_flags flags)
void mem_fence (cl_mem_fence_flags flags)
void read_mem_fence (cl_mem_fence_flags flags)
void write_mem_fence (cl_mem_fence_flags flags)
Async Copies to/from Memory: (section 6.11.11 of
http://www.khronos.org/registry/cl/specs/opencl-1.0.33.pdf)
event_t async_work_group_copy (__local gentype *dst, const __global
gentype *src,size_t num_elements, event_t event)
event_t async_work_group_copy (__global gentype *dst,const __local
gentype *src,size_t num_elements, event_t event)
void 

[cond-optab] update and first call for review

[Paolo Bonzini]

I meant to start the big assembly comparison run today, but I was busy
and tomorrow I have to leave.  So I'll create the branch before doing
that but after finishing building newlibs.

There were no other target-independent change to make.

I fixed the Blackfin regressions.

I also fixed a few minidetails in a couple other ports (ARM and SHmedia;
too large constraints in cbranch, causing unrecognized instructions later).

Building newlib has the following results:

- fails at the same spot as base for arc and m68hc11;

- passes for stormy16 where base fails (PR39601; will investigate if no
one beats me);

- passes for arm, avr, bfin, cris (v1/v32), crx, e500, fr30, frv,
iq2000, m32c, m32r, mcore, mmix, mn10300, sh, sparc, spu, stormy16, v850

- is finishing now for h8300 and sh64

I still have to post m68k, m68hc11, mips changes but I have them.

I'll create the branch early next week, volunteers for reviewing the
target-independent parts are welcome (for now, only those already posted).

I'll need help bootstrapping on pa, rs6000, s390, alpha, ia64, arm.
I'll try assembly language comparisons there too though.

Paolo

Re: GCC 4.4 Branch Created

[Rainer Orth]

Daniel Berlin  writes:

> On Fri, Mar 27, 2009 at 6:34 PM, Joseph S. Myers
>  wrote:
> > On Fri, 27 Mar 2009, Mark Mitchell wrote:
[...]
> > If we want to deprecate gccbug in 4.4 and remove it in 4.5 (and so not
> > need 4.5.1 or subsequent versions in this script), there is still time to
> > do so (though not to get it in the first deprecated-features-removal patch
> > for 4.5 - that has already been approved for 4.5 and I am retesting it
> > tonight before committing it to trunk).
> 
> 
> I think we should.
> We haven't received a bug through gccbug in quite a while :)

No wonder: it didn't work for quite some time (reports didn't make it
through), and despite several request from me you couldn't make time to
find out what was going on.  I don't blame you at all, but find it highly
unfortunate to be forced to use a browser for initial submission instead of
being able to use a proper mailer/editor.

Rainer

-- 
-
Rainer Orth, Faculty of Technology, Bielefeld University

Re: GCC 4.4 Branch Created

[Daniel Berlin]

On Tue, Mar 31, 2009 at 2:46 PM, Rainer Orth
 wrote:
> Daniel Berlin  writes:
>
>> On Fri, Mar 27, 2009 at 6:34 PM, Joseph S. Myers
>>  wrote:
>> > On Fri, 27 Mar 2009, Mark Mitchell wrote:
> [...]
>> > If we want to deprecate gccbug in 4.4 and remove it in 4.5 (and so not
>> > need 4.5.1 or subsequent versions in this script), there is still time to
>> > do so (though not to get it in the first deprecated-features-removal patch
>> > for 4.5 - that has already been approved for 4.5 and I am retesting it
>> > tonight before committing it to trunk).
>>
>>
>> I think we should.
>> We haven't received a bug through gccbug in quite a while :)
>
> No wonder: it didn't work for quite some time (reports didn't make it
> through), and despite several request from me you couldn't make time to
> find out what was going on.

This is true, I don't have time to maintain an incoming email script
used solely by you

>  I don't blame you at all, but find it highly
> unfortunate to be forced to use a browser for initial submission instead of
> being able to use a proper mailer/editor.
I'm sorry you feel that way, but I simply don't have the extra time to
support a method of submission used by exactly one person.

Re: GCC 4.4 Branch Created

[Rainer Orth]

Daniel Berlin writes:

> > No wonder: it didn't work for quite some time (reports didn't make it
> > through), and despite several request from me you couldn't make time to
> > find out what was going on.
>
> This is true, I don't have time to maintain an incoming email script
> used solely by you

Which may be due both to obsoleteness (everyone and his mother thinks all
the world it the web nowadays ;-) or lack of awareness.

> >  I don't blame you at all, but find it highly
> > unfortunate to be forced to use a browser for initial submission instead of
> > being able to use a proper mailer/editor.
> I'm sorry you feel that way, but I simply don't have the extra time to
> support a method of submission used by exactly one person.

Understood, but I wonder how other projects deal with this.  I cannot
possibly be the only one in the world who wants to submit structured bug
reports by mail.  Doesn't bugzilla have something native to handle this?

Rainer

-
Rainer Orth, Faculty of Technology, Bielefeld University

Successfull build of gcc-4.4.0 [gcc-4_4-branch revision 145224] for target i686-pc-mingw32 (cross build from i686-pc-cygwin)

[Rainer Emrich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Compiler version: 4.4.0 20090329 (prerelease) [gcc-4_4-branch revision 145224]
(GCC)
Platform: i686-pc-mingw32
configure flags:
- --prefix=/opt/devel/gnu/cross-gcc/gcc-4.4.0/mingw/i686-pc-mingw32/mingw
- --with-sysroot=/opt/devel/gnu/cross-gcc/gcc-4.4.0/mingw/i686-pc-mingw32
- --with-gmp=/opt/devel/gnu/gcc/gcc-4.4.0/i686-pc-cygwin
- --with-mpfr=/opt/devel/gnu/gcc/gcc-4.4.0/i686-pc-cygwin --build=i686-pc-cygwin
- --host=i686-pc-cygwin --target=i686-pc-mingw32 --disable-bootstrap 
--with-gnu-as
-
--with-as=/opt/devel/gnu/cross-gcc/gcc-4.4.0/mingw/i686-pc-mingw32/mingw/bin/i686-pc-mingw32-as.exe
- --with-gnu-ld
-
--with-ld=/opt/devel/gnu/cross-gcc/gcc-4.4.0/mingw/i686-pc-mingw32/mingw/bin/i686-pc-mingw32-ld.exe
- --enable-checking=release 
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++
- --enable-libgomp

binutils:
bintuils-2.19.51.20090329


Build system:
CYGWIN_NT-5.2-WOW64 kasandra 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin

cc for building:
gcc-4.4.0 [gcc-4_4-branch revision 145224]
gcc (GCC) 4.4.0 20090329 (prerelease) [gcc-4_4-branch revision 145224]
Copyright (C) 2009 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.


as for building:
GNU assembler (GNU Binutils) 2.19.51.20090329
Copyright 2008 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of \`i686-pc-cygwin'.

ld for building:
GNU ld (GNU Binutils) 2.19.51.20090329
Copyright 2008 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

testresults:

http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg03249.html


There are two major issues.

1.) The acats testsuite is completely broken, doesn't run at all.

2.) libgomp is completely broken, nearly all execution tests fail. I'm using the
pthread for windows implementation.


Cheers,

Rainer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknSZz0ACgkQoUhjsh59BL6MMACgpOVq3R0qdBUXe+gWbRioe6dq
SUYAoMCx73F43pBF+ug+EvqRSILTuFNT
=2t91
-END PGP SIGNATURE-

Re: GCC 4.4 Branch Created

[Daniel Berlin]

On Tue, Mar 31, 2009 at 2:51 PM, Rainer Orth
 wrote:
> Daniel Berlin writes:

>
>> >  I don't blame you at all, but find it highly
>> > unfortunate to be forced to use a browser for initial submission instead of
>> > being able to use a proper mailer/editor.
>> I'm sorry you feel that way, but I simply don't have the extra time to
>> support a method of submission used by exactly one person.
>
> Understood, but I wonder how other projects deal with this.  I cannot
> possibly be the only one in the world who wants to submit structured bug
> reports by mail.  Doesn't bugzilla have something native to handle this?

Bugzilla had a few things in the contrib dir at one point to handle
this, but they have all gone unmaintained, AFAIK.

The closest thing that exists in newer bugzilla is xmlrpc server
support, which you could use to make a client htat acted however you
want.

Re: GCC 4.4 Branch Created

[Daniel Berlin]

On Tue, Mar 31, 2009 at 3:01 PM, Gabriel Dos Reis  wrote:
> On Tue, Mar 31, 2009 at 1:51 PM, Rainer Orth
>  wrote:
>> Daniel Berlin writes:
>
>> Understood, but I wonder how other projects deal with this.  I cannot
>> possibly be the only one in the world who wants to submit structured bug
>> reports by mail.
>
> No, you are not the only one.  Unless my memory is
> failing me I believe last time, I was told I was the only one...

But you also believed lynx accounted for more than 0.1% of web traffic, so 
In any case, this is simple:
we have not had an incoming email for gcc-gnats in all of march
or february
or january

If you two want to get together and write some perl incoming email
handler for bugzilla for whatever format and get it set up, i'm not
going to stop you.

Re: GCC 4.4 Branch Created

[Gabriel Dos Reis]

On Tue, Mar 31, 2009 at 1:51 PM, Rainer Orth
 wrote:
> Daniel Berlin writes:

> Understood, but I wonder how other projects deal with this.  I cannot
> possibly be the only one in the world who wants to submit structured bug
> reports by mail.

No, you are not the only one.  Unless my memory is
failing me I believe last time, I was told I was the only one...

-- Gaby

Re: GCC 4.4 Branch Created

[Gabriel Dos Reis]

On Tue, Mar 31, 2009 at 2:05 PM, Daniel Berlin  wrote:
> On Tue, Mar 31, 2009 at 3:01 PM, Gabriel Dos Reis  wrote:
>> On Tue, Mar 31, 2009 at 1:51 PM, Rainer Orth
>>  wrote:
>>> Daniel Berlin writes:
>>
>>> Understood, but I wonder how other projects deal with this.  I cannot
>>> possibly be the only one in the world who wants to submit structured bug
>>> reports by mail.
>>
>> No, you are not the only one.  Unless my memory is
>> failing me I believe last time, I was told I was the only one...
>
> But you also believed lynx accounted for more than 0.1% of web traffic, so 
> 

?

> In any case, this is simple:
> we have not had an incoming email for gcc-gnats in all of march
> or february
> or january
>
> If you two want to get together and write some perl incoming email
> handler for bugzilla for whatever format and get it set up, i'm not
> going to stop you.

I was careful not to blame anyone.

>

gcc-4.4-20090331 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch 
revision 145377

You'll find:

gcc-4.4-20090331.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.4-20090331.tar.bz2 C front end and core compiler

gcc-ada-4.4-20090331.tar.bz2  Ada front end and runtime

gcc-fortran-4.4-20090331.tar.bz2  Fortran front end and runtime

gcc-g++-4.4-20090331.tar.bz2  C++ front end and runtime

gcc-java-4.4-20090331.tar.bz2 Java front end and runtime

gcc-objc-4.4-20090331.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.4-20090331.tar.bz2The GCC testsuite

Diffs from 4.4-20090327 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.4
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.

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

[Alexandre Oliva]

On Mar 13, 2009, Paolo Bonzini  wrote:

> For 4.5 I would like to improve our RTL canonicalization so that no
> out-of-range shifts are ever in the RTL representation.

FR-V non-vector shifts truncate a register shift count to 5 bits; it's
from the ISA specs, it doesn't appear that the same truncation is
applied to 10- or 12-bit immediate shift operands.  Vector shifts
truncate the 6-bit immediate shift count to 4 bits.

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist  Red Hat Brazil Compiler Engineer

stdint.h type information needed

[Joseph S. Myers]

GCC now supports providing the header  (required by C99 of 
freestanding implementations) and having information within the compiler 
about the types used in this header.  For further discussion of this and 
its benefits, see 
.

Right now, the information is present in GCC for targets using glibc or 
uClibc, bare-metal and RTEMS targets (which are taken to use newlib's 
default stdint.h types) and Solaris targets.  To get the full benefits of 
this support, the information needs adding for all OSes supported by GCC.  
This is information about all the types C99 specifies for , plus 
sig_atomic_t whose limits go in that header.

To add information for a target OS, put definitions such as those in 
glibc-stdint.h, newlib-stdint.h or sol2.h in a suitable target header, and 
set use_gcc_stdint in config.gcc.  It should be set to "wrap" if the 
system has its own stdint.h header, or "provide" if it doesn't.  (There 
might be special cases when some other arrangement is needed, but I expect 
those two generally to suffice.)  Make sure the new c99-stdint-*.c tests 
pass; if they show up bugs in the system's stdint.h header (as wrapped by 
GCC with the "wrap" setting) then report those upstream and fix them in 
GCC with fixincludes.

If the system does not have stdint.h, then suitable types may be found in 
one of the following places:

* A later OS version.

* inttypes.h (some systems have headers from C9x drafts that had only 
inttypes.h and not stdint.h).

* Other headers such as sys/types.h, including possibly variant type names 
such as u_int32_t in those headers.

* As a last resort, for OSes that are no longer maintained or whose 
maintainers have had no interest in defining those types for the OS, the 
types may be invented for GCC.

At least the following OSes need the information added (for all supported 
architectures):

* Darwin
* FreeBSD
* NetBSD
* OpenBSD
* VxWorks
* alpha*-dec-osf[45]*
* VMS
* SymbianOS
* WinCE
* HP-UX
* DJGPP
* LynxOS
* Netware
* QNX
* Cygwin
* MinGW
* Interix
* IRIX
* AIX
* s390x-ibm-tpf*

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

Re: stdint.h type information needed

[DJ Delorie]

DJGPP has its own , at least in DJGPP 2.04.

Re: stdint.h type information needed

[Joseph S. Myers]

On Tue, 31 Mar 2009, DJ Delorie wrote:

> DJGPP has its own , at least in DJGPP 2.04.

I expect most of the OSes listed do; the types should still be entered 
into GCC (so the Fortran front end can know them, for example), and 
use_gcc_stdint set to "wrap" unless there is a particular problem with 
using GCC's version in freestanding mode.  If the OS has its own copy, you 
can just go there to determine the types to enter into the appropriate 
tm.h header, instead of needing to try the other sources I listed.

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

Re: stdint.h type information needed

[DJ Delorie]

> I expect most of the OSes listed do; the types should still be entered 
> into GCC (so the Fortran front end can know them, for example), and 

Well, I'm not a big fan of duplicating information, but if that's what
you want to do, here it is.  Enjoy.


/* Copyright (C) 2003 DJ Delorie, see COPYING.DJ for details */
/* Copyright (C) 2002 DJ Delorie, see COPYING.DJ for details */
/* Copyright (C) 2001 DJ Delorie, see COPYING.DJ for details */
#ifndef __dj_stdint__h_
#define __dj_stdint__h_

#ifdef __cplusplus
extern "C" {
#endif

#if (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) \
  || !defined(__STRICT_ANSI__)

typedef signed char int_least8_t;
typedef unsigned char uint_least8_t;
typedef signed char int_fast8_t;
typedef unsigned char uint_fast8_t;
typedef signed char int8_t;
typedef unsigned char uint8_t;

typedef signed short int int_least16_t;
typedef unsigned short int uint_least16_t;
typedef signed int int_fast16_t;
typedef unsigned int uint_fast16_t;
typedef signed short int int16_t;
typedef unsigned short int uint16_t;

typedef signed int int_least32_t;
typedef unsigned int uint_least32_t;
typedef signed int int_fast32_t;
typedef unsigned int uint_fast32_t;
typedef signed long int32_t;
typedef unsigned long uint32_t;

__extension__ typedef signed long long int_least64_t;
__extension__ typedef unsigned long long uint_least64_t;
__extension__ typedef signed long long int_fast64_t;
__extension__ typedef unsigned long long uint_fast64_t;
__extension__ typedef signed long long int64_t;
__extension__ typedef unsigned long long uint64_t;

typedef long int intptr_t;
typedef unsigned long uintptr_t;

__extension__ typedef signed long long intmax_t;
__extension__ typedef unsigned long long uintmax_t;

/* ANSI/ISO C99 says these should not be visible in C++ unless
   explicitly requested.  */

#if !defined(__cplusplus) || defined(__STDC_LIMIT_MACROS)

#define INT_LEAST8_MAX   127
#define UINT_LEAST8_MAX  255
#define INT_FAST8_MAX127
#define UINT_FAST8_MAX   255
#define INT8_MAX 127
#define UINT8_MAX255 
#define INT_LEAST8_MIN   (-128)
#define INT_FAST8_MIN(-128)
#define INT8_MIN (-128)

#define INT_LEAST16_MAX  32767
#define UINT_LEAST16_MAX 65535
#define INT_FAST16_MAX   2147483647
#define UINT_FAST16_MAX  4294967295U
#define INT16_MAX32767
#define UINT16_MAX   65535
#define INT_LEAST16_MIN  (-32768)
#define INT_FAST16_MIN   (-2147483647-1)
#define INT16_MIN(-32768)

#define INT_LEAST32_MAX  2147483647
#define UINT_LEAST32_MAX 4294967295U
#define INT_FAST32_MAX   2147483647
#define UINT_FAST32_MAX  4294967295U
#define INT32_MAX2147483647L
#define UINT32_MAX   4294967295UL
#define INT_LEAST32_MIN  (-2147483647-1)
#define INT_FAST32_MIN   (-2147483647-1)
#define INT32_MIN(-2147483647L-1)

#define INT_LEAST64_MAX  9223372036854775807LL
#define UINT_LEAST64_MAX 18446744073709551615ULL
#define INT_FAST64_MAX   9223372036854775807LL
#define UINT_FAST64_MAX  18446744073709551615ULL
#define INT64_MAX9223372036854775807LL
#define UINT64_MAX   18446744073709551615ULL
#define INT_LEAST64_MIN  (-9223372036854775807LL-1LL)
#define INT_FAST64_MIN   (-9223372036854775807LL-1LL)
#define INT64_MIN(-9223372036854775807LL-1LL)

#define INTPTR_MAX  2147483647L
#define INTPTR_MIN  (-2147483647L-1L)
#define UINTPTR_MAX 0xUL

#define INTMAX_MAX  9223372036854775807LL
#define UINTMAX_MAX 18446744073709551615ULL
#define INTMAX_MIN  (-9223372036854775807LL-1LL)

#define PTRDIFF_MAX 2147483647
#define PTRDIFF_MIN (-2147483647-1)
#define SIG_ATOMIC_MAX  2147483647
#define SIG_ATOMIC_MIN  (-2147483647-1)
#define SIZE_MAX4294967295U

  /* These are defined by limits.h, so make them conditional.  */
#ifndef WCHAR_MAX
#define WCHAR_MAX   65535
#endif
#ifndef WCHAR_MIN
#define WCHAR_MIN   0
#endif
#ifndef WINT_MAX
#define WINT_MAX2147483647
#endif
#ifndef WINT_MIN
#define WINT_MIN(-2147483647-1)
#endif

#endif /* !__cplusplus || __STDC_LIMIT_MACROS */


#if !defined(__cplusplus) || defined(__STDC_CONSTANT_MACROS)

#define INT8_C(x)   x
#define UINT8_C(x)  x ## U
#define INT16_C(x)  x
#define UINT16_C(x) x ## U
#define INT32_C(x)  x
#define UINT32_C(x) x ## U
#define INT64_C(x)  x ## LL
#define UINT64_C(x) x ## ULL

#define INTMAX_C(x) x ## LL
#define UINTMAX_C(x)x ## ULL

#endif /* !__cplusplus || __STDC_CONSTANT_MACROS */

#endif /* (__STDC_VERSION__ >= 199901L) || !__STRICT_ANSI__ */

#ifndef __dj_ENFORCE_ANSI_FREESTANDIGN

#if (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) \
  || !defined(__STRICT_ANSI__)

#endif /* (__STDC_VERSION__ >= 199901L) || !__STRICT_ANSI__ */

#ifndef __STRICT_ANSI__

#ifndef _POSIX_SOURCE

#endif /* !_POSIX_SOURCE */
#endif /* !__STRICT_ANSI__ */
#endif /* !__dj_ENFORCE_ANSI_FREESTANDING */

#ifndef __dj_ENFORCE_FUNCTION_CALLS
#endif /* !__dj_ENFORCE_FUNCTION_CALLS */

#ifdef __cpluspl

Re: [PPL-devel] PPL broken for Canadian-cross builds

[Ryan Hill]

On Sun, 29 Mar 2009 14:11:37 -0500
Sebastian Pop  wrote:

> I committed the attached fix to the cloog-ppl repo, and I will prepare
> a new tar.gz for the gcc infrastructure.

Is changing the contents of the tarball without changing the name going
to be a habit or just something we'll have to live with until release?
It wrecks havoc with our (Gentoo's) manifest system and I'll have to
host a copy here if it's going to continue to be modified without a
version bump.


-- 
gcc-porting,  by design, by neglect
treecleaner,  for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


signature.asc
Description: PGP signature

Revised GCC Runtime Library Exception

[David Edelsohn]

The revised GCC Runtime Library Exception now is published on the FSF website:

http://www.gnu.org/licenses/gcc-exception.html

The FSF carefully considered the comments and concerns of the
community about the terminology and hopes that this new text clarifies
the permissions in conjunction with the FAQ.  The FAQ will continue to
expand to clarify the exception.

David

Re: [PPL-devel] PPL broken for Canadian-cross builds

[Sebastian Pop]

On Tue, Mar 31, 2009 at 21:41, Ryan Hill  wrote:
> On Sun, 29 Mar 2009 14:11:37 -0500
> Sebastian Pop  wrote:
>
>> I committed the attached fix to the cloog-ppl repo, and I will prepare
>> a new tar.gz for the gcc infrastructure.
>
> Is changing the contents of the tarball without changing the name going
> to be a habit or just something we'll have to live with until release?

Sorry to not have paid attention to this: Joseph Myers already warned
me about this.

> It wrecks havoc with our (Gentoo's) manifest system and I'll have to
> host a copy here if it's going to continue to be modified without a
> version bump.
>

I will call the next package cloog-ppl-0.15.2.tar.gz
Would that work for you?

Sebastian

Re: [PPL-devel] PPL broken for Canadian-cross builds

[Ryan Hill]

On Wed, 1 Apr 2009 00:02:43 -0500
Sebastian Pop  wrote:

> On Tue, Mar 31, 2009 at 21:41, Ryan Hill  wrote:
> > On Sun, 29 Mar 2009 14:11:37 -0500
> > Sebastian Pop  wrote:
> >
> >> I committed the attached fix to the cloog-ppl repo, and I will
> >> prepare a new tar.gz for the gcc infrastructure.
> >
> > Is changing the contents of the tarball without changing the name
> > going to be a habit or just something we'll have to live with until
> > release?
> 
> Sorry to not have paid attention to this: Joseph Myers already warned
> me about this.
> 
> > It wrecks havoc with our (Gentoo's) manifest system and I'll have to
> > host a copy here if it's going to continue to be modified without a
> > version bump.
> >
> 
> I will call the next package cloog-ppl-0.15.2.tar.gz
> Would that work for you?

You bet.  Thanks!


-- 
gcc-porting,  by design, by neglect
treecleaner,  for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


signature.asc
Description: PGP signature

Re: bitfields: types vs modes?

[DJ Delorie]

So... can I/we move forward on this?  Or will such a change be
rejected?

BTW, Since sending this I discovered that gcc treats these
differently wrt TARGET_NARROW_VOLATILE_BITFIELD:

volatile struct
{
  unsigned int a:8;
  unsigned int b:24;
} t1;

volatile struct
{
  unsigned int a:7;
  unsigned int b:25;
} t2;

t1.a will be accessed as a byte regardless of the target's
preferences, whereas t2.c follows the target preferences.

> One of our customers has a chip with memory-mapped peripheral
> registers that need to be accessed in a specific mode.  The registers
> represent bitfields within the hardware, so a volatile struct is an
> obvious choice to represent them in C.
> 
> However, gcc has a very simplistic heuristic for deciding what mode to
> use to access bitfields in structures - it uses either the biggest or
> smallest mode practical.  This offers the programmer no way to tell
> gcc what mode the accesses need to be in, aside from manually
> reading/writing memory with integer types and casting.
> 
> Options?  My thought, after some internal discussion, is that (if the
> target chooses) we allow gcc to honor the type of a volatile bitfield
> as the mode as long as it can do so without otherwise violating the
> structure's layout.  Some new hook will be needed for the backend, and
> perhaps a -W option for when the type cannot be honored.
> 
> I.e. if the programmer is careful enough to properly lay out the
> struct, the programmer should get what the programmer asks for.
> 
> Comments?  Alternatives?

Re: bitfields: types vs modes?

[Ian Lance Taylor]

DJ Delorie  writes:

> So... can I/we move forward on this?  Or will such a change be
> rejected?
>
> BTW, Since sending this I discovered that gcc treats these
> differently wrt TARGET_NARROW_VOLATILE_BITFIELD:
>
> volatile struct
> {
>   unsigned int a:8;
>   unsigned int b:24;
> } t1;
>
> volatile struct
> {
>   unsigned int a:7;
>   unsigned int b:25;
> } t2;
>
> t1.a will be accessed as a byte regardless of the target's
> preferences, whereas t2.c follows the target preferences.
>
>> One of our customers has a chip with memory-mapped peripheral
>> registers that need to be accessed in a specific mode.  The registers
>> represent bitfields within the hardware, so a volatile struct is an
>> obvious choice to represent them in C.
>> 
>> However, gcc has a very simplistic heuristic for deciding what mode to
>> use to access bitfields in structures - it uses either the biggest or
>> smallest mode practical.  This offers the programmer no way to tell
>> gcc what mode the accesses need to be in, aside from manually
>> reading/writing memory with integer types and casting.
>> 
>> Options?  My thought, after some internal discussion, is that (if the
>> target chooses) we allow gcc to honor the type of a volatile bitfield
>> as the mode as long as it can do so without otherwise violating the
>> structure's layout.  Some new hook will be needed for the backend, and
>> perhaps a -W option for when the type cannot be honored.
>> 
>> I.e. if the programmer is careful enough to properly lay out the
>> struct, the programmer should get what the programmer asks for.
>> 
>> Comments?  Alternatives?


It's hard for me to get excited about something like this.  It's
straightforward a programmer to write code that is clearly correct in
this sort of situation: just don't use a bitfield.  gcc doesn't even
document the order of bits in a bitfield, so it's generally difficult to
reliably use bitfields to access memory mapped registers.  If this were
my customer, I would tell them to write inline functions which access
the data as integers of the appropriate size and do the required
shifting and masking.  That code only has to be written once, it will be
just as efficient as the code generated by using a volatile bitfield
struct, and it will be clearly correct with any reasonable compiler.

A volatile bitfield is a dubious construct all by itself.  The volatile
qualifier is supposed to direct the compiler to act exactly like the
virtual machine.  But what does the virtual machine do on an assignment
to a volatile bitfield?  Many real machines must read the value, change
some bits, and then write the value back.  Is that following the virtual
machine or not?  Is the volatile qualifier misleading in such a case?

In any case, while I recommend against it, I won't stop you if you
really want to follow your proposal.  The most important thing for this
approach would be the documentation, so write that first.  Your brief
description above is insufficient; I'm not sure what you mean by
"without otherwise violating the structure's layout," and I don't know
why you might need a -W option.  Then, of course, you will need a fairly
complete set of test cases.


I want to say that I think that this comment:

>> I.e. if the programmer is careful enough to properly lay out the
>> struct, the programmer should get what the programmer asks for.

is misleading.  When I give a type to a bitfield, I don't think I am
asking for the bitfield to be accessed in that type.  It's not a case of
the programmer getting what he or she asks for; it's a case of the
programmer wants to define a specific set of semantics to bitfields, a
language construct which can provide a range of different semantics.

Ian