> most code and GCC documentation uses the less clear do-what-I-mean
> positions instead.
Ok, that's kinda what I figured. Thanks!
> "section" attributes are presently storage-class-like (similar to
> "static") and only work on declarations.
Ok, I see that we set the "apply to decl" bit for "section". I guess
the question is - why? Would it be more consistent to keep track of
where it is given, and complain if it is applie
Consider:
int __attribute__((section("foo"))) *var1;
int * __attribute__((section("foo"))) var2;
var2 is itself in section foo, and points to an int.
Isn't var1 a pointer to something in section foo, and not itself in
foo? GCC instead treats var1 like var2.
I couldn't figure out a suitable se
> Some of the work being carried out and posted on the gcc-patches
> mailing list makes those projects seem insignificant in comparision.
There's a wide range of ability in gcc developers, so there's a wide
range of projects to work on. They all use the same *process* so
starting with "trivial"
> struct-layout-1_generate.c is run on the host, not on the target.
> And for hosts AFAIK GCC requires 32-bit int.
But the structures it generates assume 32-bit ints:
T(0,enum E2 a:31;,B(0,a,e2_m1,e2_0))
You can't have a 31 bit enum on a 16 bit target. You get messages
like this:
gcc.dg/compat/struct-layout-1_generate.c assumes sizeof(int) is 4.
This of course fails on any target where sizeof(int) is 2. They may
fail when sizeof(int) is 8 too, or at least they won't be testing the
full range of possibilities.
I've noticed that quite a few testcases make these types of
as
> which is defined to correspond to some physical mode
Close. Defined to correspond to one or more physical modes.
> - Huh?, can you provide a single example of where a char type would
> be mapped by the target to two different target specified modes?
i386 can hold a char in %al (QImode) o
> - ok, and how does it know that it needs a 32-bit unsigned scalar?
tm.h: #define INT_TYPE_SIZE 32
Combined with "unsigned int foo;" in the user's source file.
The MI doesn't need to know that this fits in a QImode.
> the world is it desirable to go go in a big circle to identify
> which
> where then the target may declare class machine_mode
> target_int_mode ("HI", 16),
This is where we disagree. The *target* shouldn't map types to modes.
The *MI* should map types to modes. The target just creates the modes
it supports and describes them. The MI looks them up by descripti
> Now we have e.g. XNEW* and all we need is a new -W* flag to catch
> things like using C++ keywords and it should be fairly automatic to
> keep incompatibilities out of the sources.
Why not this?
#ifndef __cplusplus
#pragma GCC poison class template new . . .
#endif
> Might it be more desirable for the compiler's code to only refer to
> target "type" modes as opposed to "size" modes?
Not always, see my mail about Pmode. The problem isn't just how gcc
refers to machine words, but that gcc assumes their usage is context
independent or inflexible. For example
> The cases I've found in my conversion was when codes use plain
> "0" instead of VOIDmode or whatever machine_mode is appropriate.
> That use of plain 0 breaks compilation with a C++ compiler.
If the #include isn't portable enough, just hard code a 42. We'd need
suitable changes for insn-modes
> Furthermore, that does not stop an enthusiastic programmer from
> feeding the interface functions with the wrong values
If you seed the first enum from DATESTAMP, and properly range check,
you can find these cases pretty quickly and abort.
TVQ_SEED = (DATESTAMP%10) * 1000,
TVQ_FOO1,
...
> No, the goal is to make the *values* inaccessible, not the names.
No, *I* want gcc to stop doing *&$@ like this:
stack_parm = gen_rtx_PLUS (Pmode, stack_parm, offset_rtx);
It should use GET_MODE(stack_parm) in case the target has multiple
pointer sizes.
And YES I have a port with multiple
>(2) When and if you switch to this:
>
> class machine_mode
> {
> enum value_t {
>VOIDmode, SImode, // ...
> } value;
>
> // accessors, whatever ...
> };
I think what Mark wants is to migrate to this:
class machine_mo
> This doesn't do what I want at all. The goal is to make the *symbolic
> enumeration constants* inaccessible to most code.
Oh.
enum {
THE_VAL_QUUX_ENUMS
} TheValQuux;
If not defined, you get one enum, THE_VAL_QUUX_ENUMS. The "authority"
can define it to a list of enums, so it gets expanded.
> This is still not an answer to the question I originally asked - do you
> see any way IN C to write code which has the relevant property of the
> class above (that is, that the FOOmode constants are not accessible
> except to authorized code) and which does not rely on free conversion
> between
> (There's still a POSIX-ism in the generator, in that it tries to
> write to "/dev/null". On Windows systems, I bet this will often
> work, but create a real file with that name. It would be better,
> and avoid portability problems, to guard the calls to fwrite, etc.,
> with "if (file)" rather
> So you can say "mem=128m" or the like.
Yes, but that doesn't help when I want to test one application on a
system that's been otherwise up and running for months, and is busy
doing other things. The RSS limit is *supposed* to do just what we
want, but nobody seems to implement it correctly any
> What I have problem understanding is the last sentence of this
> paragraph in the light of your claim that it will results in
> swapping especially when we consider developers' machines with
> 512MB/1GB RAM, i.e. machines where memory is not "tight".
Sigh, Linux works the same way. Processes c
> so I assume setting hard ulimit to 128MB will just result in build
> process crashing instead of slowdown and swapping,
We would limit physical ram, not virtual ram. If you do a "man
setrlimit", I'm talking about RLIMIT_RSS. The result would be slowing
down and swapping, not crashing.
> We already do that for when checking is enabled, well the GC heuristics
> are tuned such that it does not change which is why
> --enable-checking=release is always faster than without it.
Right, but it doesn't call ulimit(), so other sources of memory
leakage wouldn't be affected. I'm thinking
> No company is going to spend money on fixing this until we adjust
> our (collective) attitude and take this seriously.
We could call ulimit() to force everyone to have less available RAM.
Connect it with one of the maintainer flags, like enable-checking or
something, so it doesn't penalize dist
> To reflect the logical intent of these options while passing a
> unique OPT_* to each warning call, you'd need to add an option
> -Wformat-security-nonliteral for the warnings in the intersection of
> the two options;
At one point I proposed a system that let you say "this option infers
these o
How to convert this code? There is no single OPT_* that reflects when
the first warning is emitted.
if (params == 0 && (warn_format_nonliteral || warn_format_security))
warning (0, "format not a string literal and no format arguments");
else
warning (O
> Isn't that what newlib is for...?
"Should be" does not mean "is". I know libiberty has been used for
this purpose in the past (remember the demangler in libstdc++ times?)
so I wouldn't want to assume we aren't still doing it.
> I should be clear, though; I only want to make this assumption fo
> Less to maintain is all I was hoping for. I think the configure
> scripts (both libiberty's and gcc's) could be simplified quite a bit
> if we assumed a C89 compliant runtime library, as could libiberty.h
> and system.h.
Well, gcc can make assumptions libiberty can't, and as far as
libiberty's
> I take it that all libiberty-using projects have taken the plunge,
> then? You vetoed this conversion awhile back because libiberty had
> to be done last.
At this point, I think libiberty *is* the last.
> What's your opinion on dropping C89 library routines from libiberty?
What would that bu
> Just to make sure I understand. I was thinking of whatever was
> under $GCC/libiberty (and included). Are you thinking of something
> more?
No.
> A single patch is a huge stuff; I propose to break it into a series
> of patches. Is that OK with you?
I only want to avoid a situation where li
> Would there be any objection to patches that convert function
> definitions in libiberty to use ISO C prototype style, instead of
> K&R style?
I would be in support of such a patch iff it converts all the
functions, not just the ones gcc happens to use.
> On Mon, 21 Mar 2005, DJ Delorie wrote:
> > 2005-03-21 DJ Delorie <[EMAIL PROTECTED]>
> >
> > * optabs.c (expand_binop): Make sure the first subword's result
> > gets stored.
>
> This is OK for mainline, provided that you bootstrap and r
> Nick Clifton and I have been discussing the idea of keeping GCC and
> binutils' copy of dwarf.h in sync. I've just resolved all of the
> differences with the binutils version of the file. Perhaps DJ's
> merge script could keep gcc/gcc/dwarf.h in sync with
> src/include/elf/dwarf.h as it does f
It seems to me that this kind of bug should have been noticed already,
so... am I missing something?
2005-03-21 DJ Delorie <[EMAIL PROTECTED]>
* optabs.c (expand_binop): Make sure the first subword's result
gets st
> Is there a good way of creating an assembler comments directly from RTL?
>
> I want to be able to add debugging/explanation strings to assembler
> listing (GAS). Unfortunately I want to do this from RTL prologue and
> epilogue (and thus avoid using TARGET_ASM_FUNCTION_EPILOGUE - where
> it woul
> That script doesn't really parse the file at all, it just scans for
> #include lines, and it processes each header only once no matter how
> many files reference it. Which has got to be faster than what
> cpplib is doing.
Right, I figured you could run it once just to see how *much* faster
it
> probably the sanest thing is to go with the automake-like approach of
> one .d file per .c file, which then can be annotated without having to
> write logic to parse a big dependency file and update it in place.
The problem with .d files is that there's no good automatic way to
deal with header
> > Dual Opteron 246 (FC3 x86_64, 3GHz) 2Gb (new)
>
> Lucky guy! ;)
Oops, I mean 2GHz :-P
(I have another new machine that's a P4 3GHz)
> (a) the numbers reported by the "time" command,
> (b) what sort of machine this is and how old,
Thinkpad 600 (RHL 9 i386, PII 266MHz) 192Mb (7 yrs old)
real0m46.115s
user0m40.080s
sys 0m3.930s
Dual Opteron 246 (FC3 x86_64, 3GHz) 2Gb (new)
real0m4.344s
user0m3.875s
sys
> (insn 28 26 29 1 /mnt/disk2/src/gcc/gcc/libgcc2.c:464 (set (mem/i:HI
> (reg/f:HI 8 si [orig:30 D.1371 ] [30]) [5 +0 S2 A16])
> (subreg:HI (reg/v:DI 31 [ u ]) 0)) 1 {*movhi} (nil)
> (nil))
This is a tricky one. You need to split up the moves early enough to
let reload be flexible,
> Complex. RM places a 64K stack segment limit. As far as I
> know, GCC requires more than that. Also, GCC was only
> written for 32-bit machines. My suggestions:
You're confusing hosts with targets. GCC *runs on* 32 bit (or more)
hosts, but it can *target* smaller machines. We've got lot
> I ponder about writing a "i386 16bit realmode" gcc backend as my master
> thesis - which would be usefull for generating 16-bit bios code needed
> by the virtual machine developed at my university.
It's been done a couple of times already, first by me, and later my
code was extended by a couple
> On Jan 19, 2005, at 22:48, Richard Henderson wrote:
> > On Wed, Jan 19, 2005 at 09:19:58PM -0500, DJ Delorie wrote:
> >> - int regno = 0;
> >> + int regno = FIRST_PSEUDO_REGISTER;
> >
> > To be totally safe, you need LAST_VIRTUAL_REGISTER+1.
>
&g
701 - 742 of 742 matches
Mail list logo
