Re: How can I get access to tree representation
Alexander <[EMAIL PROTECTED]> writes: | I started exploring code base of cc1plus, and now I have little | question - how I can get access to tree representation of program (I | should do it after gcc/cp/parser.c:cp_parser_translation unit(...), isnt it?) | If I wasnt mistaken, RTL began build only if parser says that syntax | OK? In an ideal world, that is what we would like to have. But currently, things are a bit intertwined -- and historically, it has been worse :-). In the current state, the gimplifiers run even if -fsyntax-only. Worse, they run even when we know the translation unit contains an error. However, you might get a starting point from the codes that call hooks for tree dumping. -- Gaby
Re: Installing libgcj consumes huge amounts of memory
Hi Gerald, On Mon, 2005-12-12 at 00:21 +0100, Gerald Pfeifer wrote: > On Sun, 4 Dec 2005, Mark Wielaard wrote: > >> 2005-09-21 Mark Wielaard <[EMAIL PROTECTED]> > >> > >> * lib/split-for-gcj.sh: Cut list to 3 package levels deep. > > I reversed this (patch attached) and now my build with ulimit -v45 > > passes. But the total virtual memory usage didn't drop that much. It was > > around 454MB top usage, to 438MB top usage. Build time increased with > > several minutes. Maybe this was just the tipping point for your setup? > > Is it possible that the last Classpath imports caused this to break for > me (and others), since we added some new modules? Yes, I think that is what happened since GNU Classpath added a lot of new standard library code in the last couple of months (those evil productive hackers...). The particular make file dependency generator was part of the code for a much longer time. > Is there any other way to address the problem during installation? > Perhaps by splitting the package set into two partitions and processing > these separately or something along these lines? I hope so, but I admit to not have a real plan yet. But I just setup an auto-builder for GNU Classpath and cannot test it against gcc trunk because of the same reason (it is a Xen instance with access to "only" 512MB of main memory) so it just moved up on my must fix list. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re[2]: How can I get access to tree representation
Hello Gabriel, Monday, December 12, 2005, 12:47:17 PM, you wrote: > Alexander <[EMAIL PROTECTED]> writes: > | I started exploring code base of cc1plus, and now I have little > | question - how I can get access to tree representation of program (I > | should do it after gcc/cp/parser.c:cp_parser_translation unit(...), isnt > it?) > | If I wasnt mistaken, RTL began build only if parser says that syntax > | OK? > In an ideal world, that is what we would like to have. But currently, > things are a bit intertwined -- and historically, it has been worse :-). > In the current state, the gimplifiers run even if -fsyntax-only. > Worse, they run even when we know the translation unit contains an error. > However, you might get a starting point from the codes that call hooks for > tree dumping. > -- Gaby Uhh... sad :-) When cc1plus make tree dumping can we be sure, that tree correctly represented program structure, i.e. symbolic information unharmed, and we could make back-transformation - from tree to source-without-comments level? -- Best regards, Alexandermailto:[EMAIL PROTECTED]
Re: Installing libgcj consumes huge amounts of memory
Mark Wielaard writes: > Hi Gerald, > > On Mon, 2005-12-12 at 00:21 +0100, Gerald Pfeifer wrote: > > On Sun, 4 Dec 2005, Mark Wielaard wrote: > > >> 2005-09-21 Mark Wielaard <[EMAIL PROTECTED]> > > >> > > >> * lib/split-for-gcj.sh: Cut list to 3 package levels deep. > > > I reversed this (patch attached) and now my build with ulimit -v45 > > > passes. But the total virtual memory usage didn't drop that much. It was > > > around 454MB top usage, to 438MB top usage. Build time increased with > > > several minutes. Maybe this was just the tipping point for your setup? > > > > Is it possible that the last Classpath imports caused this to break for > > me (and others), since we added some new modules? > > Yes, I think that is what happened since GNU Classpath added a lot of > new standard library code in the last couple of months (those evil > productive hackers...). The particular make file dependency generator > was part of the code for a much longer time. > > > Is there any other way to address the problem during installation? > > Perhaps by splitting the package set into two partitions and processing > > these separately or something along these lines? > > I hope so, but I admit to not have a real plan yet. But I just setup an > auto-builder for GNU Classpath and cannot test it against gcc trunk > because of the same reason (it is a Xen instance with access to "only" > 512MB of main memory) so it just moved up on my must fix list. Well, as hj has found the problem in make and produced something of a workaround, we should perhaps concentrate our efforts in that direction. I'm not saying we shouldn't split the package set, if it is really useful. Andrew.
gfc_build_addr_expr vs. build_fold_addr_expr{,_with_type}
Always interesting to compare seemingly duplicates. The variant
from fold-const.c seems to be more strict with types and sets
TREE_ADDRESSABLE on the base component, while the gfc variant
sets it on the passed tree itself. Other than that, the gfc variant
uses convert () to do typecasting. And the gfc variant has
parameters swapped compared to the fold-const.c variant which may
cause confusion if we switch.
Would a patch be accepted to convert the gfc_build_addr_expr to
build_fold_addr_expr{,_with_type}?
Richard.
Re: default cflags to compile
I need to generate a gcc binary that will always enable the -fabi-version=1, because I have a library built with gcc 3.3 and I need to link with it, but I would like to use gcc 4. The libstdc++ ABI broke between these releases, so unless your library doesn't use libstdc++ at all (somewhat unlikely), there is little point to this.q The problem is that we are using a closed-source library from Sony (for their robots AIBO, which run on a MIPS) and they don't support anything other than gcc 3.3. If the library uses libstdc++, does it help if I compile it with -fabi-version? I have added that option to the environment of the build script. Is there a simple way to do this (a configure option,..) ? or do I need to patch the gcc/c-cppbuiltin.c file to always define _GXX_ABI_VERSION as 102? The latter, as far as I know. OK, I'll add that patch to our patchset. Nuno
GCC 3.4.6 Release status
Hi, Bugzilla reports this morning that there are 113 open PRs with gcc-3.4.6 target, out of which only two are considered release-critical. There middle-end/18956: [hppa] 'bus error' at runtime while passing a special struct to a C++ member function http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18956 middle-end/24804: Produces wrong code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24804 Help from middle-end maintainers for understandaning and fixing these PRs are much appreciated. I'll go over the hundred PRs and triage which are important to get fixed and which we can leave with. Thanks, -- Gaby
Re: g++.dg/ext/packed3.C
Nathan Sidwell wrote:
> Jan Beulich wrote:
>
>>
>> Why? It's broken. You just cannot embed something that requires
>> alignment into something that doesn't guarantee alignment, except that
>> for built-in types, the compiler can synthesize the necessary splitting,
>> but Foo's assignment operator, in your example, may be totally unaware
>> that it might get called with an unaligned object.
>
>
> People write such code and expect it to work.
The code in question is:
struct Foo { void operator=(Foo const &);};
struct Baz __attribute__((packed))
{
char c;
Foo m;
}
void Bar (Baz *ptr)
{
ptr->m = something;
}
I'm not sure it can be made to work, without making the base class
version of Foo::operator= expect unaligned input, which seems an
unreasonable pessimization. I would expect this code to be invalid, and
either issue a diagnostic, or at least be considered undefined behavior.
(In my idea world, ptr->m has type "packed Foo" in this case, and it's
not permissible to binding a "packed Foo" to a "Foo const&", so this
would be invalid, but I could live with undefined.)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Lots of new failures in objc testsuite
On Linux/x86-64 I now get lots of new failures in the objc testsuite like the following (gcc trunk): Executing on host: /builds/gcc/misc/gcc/xgcc -B/builds/gcc/misc/gcc/ /builds/gcc/misc/gcc/testsuite/obj c.dg-struct-layout-encoding-1/t001_main.m -w -I/cvs/gcc-svn/trunk/gcc/testsuite/objc.dg/gnu-encoding -fgnu-runtime -I/cvs/gcc-svn/trunk/gcc/testsuite/../../libobjc -L/builds/gcc/misc/x86_64-suse-linux-gnu /32/libobjc/.libs -lobjc -lm -m32 -o ./t001_main.exe(timeout = 300) In file included from /builds/gcc/misc/gcc/testsuite/objc.dg-struct-layout-encoding-1/t001_main.m:25: /builds/gcc/misc/gcc/testsuite/objc.dg-struct-layout-encoding-1/t001_test.h: In function 'test23': /builds/gcc/misc/gcc/testsuite/objc.dg-struct-layout-encoding-1/t001_test.h:24: internal compiler error : Floating point exception Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. compiler exited with status 1 output is: In file included from /builds/gcc/misc/gcc/testsuite/objc.dg-struct-layout-encoding-1/t001_main.m:25: /builds/gcc/misc/gcc/testsuite/objc.dg-struct-layout-encoding-1/t001_test.h: In function 'test23': /builds/gcc/misc/gcc/testsuite/objc.dg-struct-layout-encoding-1/t001_test.h:24: internal compiler error : Floating point exception Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. FAIL: objc.dg-struct-layout-encoding-1/t001_main.m (test for excess errors) Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpgC57CxsAbG.pgp Description: PGP signature
Re: Lots of new failures in objc testsuite
> > --=-=-= > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: quoted-printable > > > : Floating point exception > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > > FAIL: objc.dg-struct-layout-encoding-1/t001_main.m (test for excess errors) This is PR 25348 which I posted a patch at http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00822.html I applied the testsuite part before the patch was approved because it passes on most target currently. It just fails on targets where dividing by zero is an signal. -- pinski
Re: g++.dg/ext/packed3.C
Mark Mitchell wrote:
struct Foo { void operator=(Foo const &);};
struct Baz __attribute__((packed))
{
char c;
Foo m;
}
void Bar (Baz *ptr)
{
ptr->m = something;
}
I'm not sure it can be made to work, without making the base class
version of Foo::operator= expect unaligned input, which seems an
unreasonable pessimization. I would expect this code to be invalid, and
either issue a diagnostic, or at least be considered undefined behavior.
It can be made to work by not packing Baz::m, and that is what g++ does (with a
warning%). Issuing an error in this case I don't think is acceptable -- I know
of users who would complain. If the user explicitly packed Baz::m field, rather
than the containing structure, I would be happy with a diagnostic.
(In my idea world, ptr->m has type "packed Foo" in this case, and it's
not permissible to binding a "packed Foo" to a "Foo const&", so this
would be invalid, but I could live with undefined.)
We need to distinguish the meanings of placing the packed attribute on the
structure and on the field itself. I agree with you that when the attribute is
on the field itself, the type should be 'packed Foo' and unbindable. When the
attribute is on the whole struct, I'm not so sure.
% ah, I think that warning should only be given on non-default-packed arches.
Is this your problem Jan?
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Eliminating R_PPC_REL32 relocations
Hello, I am experimenting with some different memory architectures and would like to isolate instruction and data accesses (Harvard architecture style). I am currently working with the PPC 405 processor and I am cross compiling applications using Crosstool (gcc-3.3.1 and glibc-2.3.2). The R_PPC_REL32 relocations that appear when I compile shared/dynamic libraries violate the separation I am trying to achieve by placing data values (essentially jump addresses) in the executable (.text, .fini, .init) segments. I can't seem to find any options that allow me to elminate/remove these types of relocations. Are these types of relocations necessary when compiling shared/dynamic objects for the 405? If not, how the compiler be instructed not to use them? Is this some sort of optimization (note: I did not use optimization in the compile)? Thanks, Josh
GCC CompileFarm Project
Hi, I have updated the wiki with all current information: http://gcc.gnu.org/wiki/CompileFarm As indicated on the wiki: If you are a GCC developper and want access to the compileFarm for GCC development and testing, or if you are a free software developper wishing to set up automated testing of a piece of free software with the current GCC development version (preferably with a test suite), please send your ssh public key (HOME/.ssh/authorized_keys format) and your prefered UNIX login to laurent at guerby dot net. First test results from the compileFarm: http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00569.html Feel free to pass the word around to other free sofware project people you know that could be interested in setting up an automated build of their software with a development version of GCC. For scripts and various things that will be developped for these machines, should we use the GCC SVN repository or set up a project on gna.org (FSF France sourceforge)? I think it would be more flexible to use a separate gna.org project, especially for people from other free software projects who don't have FSF paperwork done. Laurent
Error with released manuals for GCC v3.4.5
On page: http://gcc.gnu.org/onlinedocs/ The Following are corrupted: http://gcc.gnu.org/onlinedocs/gcc-3.4.5/gnat_ugn_unw.pdf http://gcc.gnu.org/onlinedocs/gcc-3.4.5/gnat_ugn_unw-html.tar.gz And the link (http://gcc.gnu.org/onlinedocs/gcc-3.4.5/docs-sources.tar.gz ) to the documentation sources is a tarball of the complete GCC v3.4.5 instead of just the documentation sources. Thought I'd send a quick note just incase no one else noticed yet. Merry Christmas all and thanks for GCC :)
Re: Error with released manuals for GCC v3.4.5
Peter Ward <[EMAIL PROTECTED]> writes: | On page: http://gcc.gnu.org/onlinedocs/ | | The Following are corrupted: | http://gcc.gnu.org/onlinedocs/gcc-3.4.5/gnat_ugn_unw.pdf | http://gcc.gnu.org/onlinedocs/gcc-3.4.5/gnat_ugn_unw-html.tar.gz | | And the link | (http://gcc.gnu.org/onlinedocs/gcc-3.4.5/docs-sources.tar.gz ) to the | documentation sources is a tarball of the complete GCC v3.4.5 instead | of just the documentation sources. | | | Thought I'd send a quick note just incase no one else noticed yet. Thanks for the notice. I did not spot it. Many things seem to have changed for the scripts during the move SVN, and they haven't been fully tested in "real release". We will work out the errors as they show up. Thanks! -- Gaby
Re: g++.dg/ext/packed3.C
Nathan Sidwell wrote:
> Mark Mitchell wrote:
>
>> struct Foo { void operator=(Foo const &);};
>> struct Baz __attribute__((packed))
>> {
>>char c;
>>Foo m;
>> }
>>
>> void Bar (Baz *ptr)
>> {
>>ptr->m = something;
>> }
>>
>> I'm not sure it can be made to work, without making the base class
>> version of Foo::operator= expect unaligned input, which seems an
>> unreasonable pessimization. I would expect this code to be invalid, and
>> either issue a diagnostic, or at least be considered undefined behavior.
>
>
> It can be made to work by not packing Baz::m, and that is what g++ does
> (with a warning%).
Ah! That makes sense.
> % ah, I think that warning should only be given on non-default-packed
> arches. Is this your problem Jan?
I think the warning should be given only if the base class does not
itself have the minimum alignment for the artchitecture. (So that you
would get the warning on a system that was packed by default if you used
a base class which was explicitly aligned on a wider boundary.)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Re: identifying c++ aliasing violations
On Sun, 4 Dec 2005 20:07:33 -0500 (EST), Jack Howarth wrote: >swigpy.cc: In function 'int SWIGPY_Python_ConvertPtr(PyObject*, void**, >swig_typ >e_info*, int)': >swigpy.cc:620: warning: dereferencing type-punned pointer will break >strict-alia >sing rules My recent encounters with python (in my case libboost_python) have shown me that code that uses the Python interface has to use no-strict-aliasing. Even the Python folks decided to use that switch in 2003 for the Python code (written in C). This is mostly because Python code is riddled with casts to PyObject. Philipp
Re: bootstrap GCC-4.1-20051202 on Mac OS X (10.3.9)
On Dec 8, 2005, at 7:24 AM, Paul Martinolich wrote: running 'make' yields the following error: # /Users/martinol/auto_v4.0/third/gcc-4.1-20051202/configure -- disable-multilib I suspect you'll want to file a bug for this so we don't loose track of it.
Re: bootstrap GCC-4.1-20051202 on Mac OS X (10.3.9)
On Dec 12, 2005, at 7:33 PM, Mike Stump wrote: On Dec 8, 2005, at 7:24 AM, Paul Martinolich wrote: running 'make' yields the following error: # /Users/martinol/auto_v4.0/third/gcc-4.1-20051202/configure --disable-multilib I suspect you'll want to file a bug for this so we don't loose track of it. Actually we found out (via a different bug report). That this is a broken strip which was installed from some other package. I think fink is messing up people or something like that. -- Pinski
SVN tags, branches and checkouts
I find the documentation on checking out branches, particularly for branch releases, confusing. It doesn't say you need to use "tags" instead of "branches" for releases. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: RFC: REG_LABEL not sufficient, cbranchM4 causes ambiguity
> Date: Mon, 12 Dec 2005 08:35:41 +0100 > From: Hans-Peter Nilsson <[EMAIL PROTECTED]> > ... the JUMP_LABEL field in a JUMP_P ... Almost-consistent typo: s/JUMP_LABEL/JUMP_TARGET/g to hopefully make a little bit more sense of it all. (Attempting a brain-dump before shuteyes always has some defects.) brgds, H-P
Re: RELOAD_OTHER bug?
> It does seem like reload 0 should be RELOAD_FOR_ something _ADDR.
> What set it to RELOAD_OTHER?
Ok, we start with a RELOAD_OTHER for the zero_extendhisi. The MEM's
address eventually gets RELOAD_FOR_OTHER_ADDRESS. Part of that
address is split out into another RELOAD_FOR_OTHER_ADDRESS.
Separately, we have an RELOAD_FOR_OUTPUT_ADDRESS that matches it. The
OUTPUT_ADDRESS and OTHER_ADDRESS are merged into a RELOAD_OTHER at the
munged patch snippet below, where I added a check for OTHER_ADDRESS to
avoid regressing the priority. It seems to work, but I'm worried that
there's no logic to guarantee the order of output, other than the
sequence number, which is commented as part of the sort "so that qsort
is deterministic". Seems to be a recipe for future disaster.
Index: reload1.c
===
--- reload1.c (revision 108132)
+++ reload1.c (working copy)
@@ -6136,7 +6171,15 @@
|| rld[j].when_needed == RELOAD_FOR_INPUT_ADDRESS
|| rld[j].when_needed == RELOAD_FOR_OTHER_ADDRESS))
{
- rld[i].when_needed = RELOAD_OTHER;
+ if (rld[i].when_needed == RELOAD_FOR_OTHER_ADDRESS
+ || rld[j].when_needed == RELOAD_FOR_OTHER_ADDRESS)
+ rld[i].when_needed = RELOAD_FOR_OTHER_ADDRESS;
+ else
+ rld[i].when_needed = RELOAD_OTHER;
rld[j].in = 0;
reload_spill_index[j] = -1;
transfer_replacements (i, j);
options for compiling C using C++ compiler
I'm working on a project where I post-process AST (.tu) output from gcc using the -fdump-translation-unit option. Problem is the C compiler does not generate useful AST data. So I actually run the preprocessed source again thru g++ to get AST data. This works fine unless there are constructs not allowed under C++. Particular problems are bool and other keyword stuff and K&R style function declarations. I'm trying to find the best way to minimize the problem via options or other ways. I already use "-fpermissive" and this eases it a bit. Suggestions? -J _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/
Re: RELOAD_OTHER bug?
DJ Delorie <[EMAIL PROTECTED]> writes: > > It does seem like reload 0 should be RELOAD_FOR_ something _ADDR. > > What set it to RELOAD_OTHER? > > Ok, we start with a RELOAD_OTHER for the zero_extendhisi. I'm not clear on why that happens. Most reloads start out as RELOAD_FOR_INPUT or RELOAD_FOR_OUTPUT. What does the insn pattern look like in the MD file? It kind of sounds like the insn pattern might use a "+" constraint, but it shouldn't need to do that. > The MEM's > address eventually gets RELOAD_FOR_OTHER_ADDRESS. Part of that > address is split out into another RELOAD_FOR_OTHER_ADDRESS. > Separately, we have an RELOAD_FOR_OUTPUT_ADDRESS that matches it. The > OUTPUT_ADDRESS and OTHER_ADDRESS are merged into a RELOAD_OTHER at the > munged patch snippet below, where I added a check for OTHER_ADDRESS to > avoid regressing the priority. It seems to work, but I'm worried that > there's no logic to guarantee the order of output, other than the > sequence number, which is commented as part of the sort "so that qsort > is deterministic". Seems to be a recipe for future disaster. There is already code which relies on the sequence number; see these comments in reload.c: /* This relies on the fact that emit_reload_insns outputs the instructions for input reloads of type RELOAD_OTHER in the same order as the reloads. Thus if the outer reload is also of type RELOAD_OTHER, we are guaranteed that this inner reload will be output before the outer reload. */ Your patch is a bit troubling because of the following code which tries to set other reloads to RELOAD_FOR_OTHER_ADDRESS. But the current code seems clearly wrong: changing RELOAD_FOR_OTHER_ADDRESS into RELOAD_OTHER can't be right. And the reload ordering should keep things in the right order. I hope. I'll approve your patch if it bootstraps and tests on x86. But check that zero_extend insn also to see why it is RELOAD_OTHER. Ian
Re: RELOAD_OTHER bug?
The insn starts like this:
(insn 238 237 239 35 ../../../../../src/newlib/libc/stdio/vfprintf.c:604 (set
(reg/v:HI 175 [ ch ])
(sign_extend:HI (mem:QI (reg/v/f:HI 176 [ fmt ]) [0 S1 A8]))) 46
{extendqihi2} (nil)
(nil))
Reload 0: reload_in (HI) = (plus:HI (reg/f:HI 7 fb)
(const_int -128
[0xff80]))
A_REGS, RELOAD_FOR_OUTPUT_ADDRESS (opnum = 0)
reload_in_reg: (plus:HI (reg/f:HI 7 fb)
(const_int -128
[0xff80]))
Reload 1: reload_in (HI) = (plus:HI (reg/f:HI 7 fb)
(const_int -128
[0xff80]))
A_REGS, RELOAD_FOR_INPADDR_ADDRESS (opnum = 1)
reload_in_reg: (plus:HI (reg/f:HI 7 fb)
(const_int -128
[0xff80]))
Reload 2: reload_in (HI) = (mem/c:HI (plus:HI (plus:HI (reg/f:HI 7 fb)
(const_int -128
[0xff80]))
(const_int -476
[0xfe24])) [108 fmt+0 S2 A8])
A_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1), can't combine
reload_in_reg: (reg/v/f:HI 176 [ fmt ])
Reload 3: reload_in (QI) = (mem:QI (reg/v/f:HI 176 [ fmt ]) [0 S1 A8])
reload_out (HI) = (mem/c:HI (plus:HI (plus:HI (reg/f:HI 7 fb)
(const_int -128
[0xff80]))
(const_int -474
[0xfe26])) [107 ch+0 S2 A8])
HL_REGS, RELOAD_OTHER (opnum = 0)
reload_in_reg: (mem:QI (reg/v/f:HI 176 [ fmt ]) [0 S1 A8])
reload_out_reg: (reg/v:HI 175 [ ch ])
And the md file:
(define_insn "extendqihi2"
[(set (match_operand:HI 0 "mra_operand" "=RhlSd*Rmm")
(sign_extend:HI (match_operand:QI 1 "mra_operand" "0")))]
""
"exts.b\t%1"
[(set_attr "flags" "sz")]
)
Re: g++.dg/ext/packed3.C
>It can be made to work by not packing Baz::m, and that is what g++ does
(with a
>warning%). Issuing an error in this case I don't think is acceptable
-- I know
>of users who would complain. If the user explicitly packed Baz::m
field, rather
>than the containing structure, I would be happy with a diagnostic.
I don't think this is the case. The questionable code (from the test
case) really is
struct Unpacked { int i; };
struct __attribute__ ((packed)) Packed
{
char c;
int i;
Unpacked u;
};
and the test expects that you cannot bind Packed::u to Unpacked& (error
expected), but that you can bind Packed::u::i to int& (not even a
warning expected). No warning is expected on the definition of Packed's
u member.
>> (In my idea world, ptr->m has type "packed Foo" in this case, and
it's
>> not permissible to binding a "packed Foo" to a "Foo const&", so
this
>> would be invalid, but I could live with undefined.)
>
>We need to distinguish the meanings of placing the packed attribute on
the
>structure and on the field itself. I agree with you that when the
attribute is
>on the field itself, the type should be 'packed Foo' and unbindable.
When the
>attribute is on the whole struct, I'm not so sure.
Yes, except that 'packed' on the containing structure doesn't really
imply 'packed' on the contained structure, it rather implies 'unaligned'
(unless [silently] overridden by ignoring the containing structure's
'packed' attribute, as you say is happening, but as I'm inclined to say
is not, given the expectations of the test case). Unfortunately gcc
(still) doesn't support an 'unaligned' attribute.
>>% ah, I think that warning should only be given on non-default-packed
arches.
>>Is this your problem Jan?
Not exactly. My problems are
(a) the above mentioned inconsistency in allowing binding to the whole
structure but not to its members, and
(b) on a default-packed target (or with -fpack-struct) getting reverse
behavior in allowing binding to Packed::u but not allowing binding to
Packed::u::i.
Jan
Re: RFC: Make is a HUGE memory hog
GNU make 3.80 is a HUGE memory hog. It calls xstrdup to build dependency list. gnu-src-gcc.deps in libjava has 3000+ targets depend the same 3000+ files, whose filenames are more than 260K. For this dependency alone, make takes 3000*260K == 761MB. Then, you should make the 3000+ target depend on the same stamp file, and touch the stamp file whenever one of the 3000+ files are changed. These would make 6000 dependencies, not 3000^2 = 9 million (which is not going to be that efficient anyway). Also, GNU make is not released that often, and it does not seem plausible that we require a CVS make to build libjava on a machine with <1 GB. Paolo
