> (more precisely, for int128_integer_type_node to cease to exist and
> for any front-end places needing it to call a function, with a type
> size that should not be a constant 128).
The complications I've seen there is, for example, when you're
iterating through types looking for a "best" type,
> In general you need to analyze each such case individually to produce a
> reasoned argument for what it should logically be doing. Given such
> analyses, maybe then you can identify particular tables of types in
> particular orders (for example) that should be set up to iterate through.
Ok,
First pass at actual code. I took the path of using a new macro in
TARGET-modes.def and having genmodes build the relevent tables. Part
of the table is created by genmodes, the rest is created at runtime.
genmodes: bitsize, mode.
runtime: signed/unsigned type trees
(eventually, flag for "tar
> This seems mostly plausible, though I don't see anything to ensure that
> __intN does not exist at all if the size matches one of the standard C
> types,
My thought here was that, since each __intN is specified by the
target, they'd know to only do so if it doesn't match an existing (for
that
> (For the types you do have, there's a need to define C++ name mangling.
I mentioned this before, and I don't have a good solution for it.
Both C++ and LTO need a mangled form of __intN types.
Where is the right place to set the array of "this __intN mode is
enabled" flags? I initially set it in tree.c where __int128 is set
up, but that happens *after* c_parse_init() needs the flag to set up
the RID_* keywords for them.
Alternately, should I be calling targetm.scalar_mode_supported_p(
> This seems mostly plausible, though I don't see anything to ensure that
> __intN does not exist at all if the size matches one of the standard C
> types, or if the mode fails targetm.scalar_mode_supported_p.
What do we check against for this? Is there some table of standard
types we can read
> I think using the macros for type sizes is fine, and float / vector /
> complex types are completely irrelevant to this (so standard_type_bitsize
> should maybe be standard_integer_type_bitsize).
Whew. Am I missing any in the previous code snippet (char, short,
int, long, long long) ? Those
Ok, so I've got it checking for existing types and checking the target
for supported modes. Any other features, or is it time for a second
patch? Should I cut out the __int128 parts yet, or do you just want
to see the new code still?
To-Do: C++ parser, C++ mangling. Still no idea what to do ab
> I think a patch is more useful once believe feature-complete, which
> means replacing the __int128 support with the new mechanism.
One of the side-effects of taking out the existing __int128 support is
that __int128 isn't in the integer_type_kind list, so isn't a type
that is usable for constan
> I don't see constants in that test.
// Test for int128 enums.
// { dg-do compile { target int128 } }
// { dg-options "" }
enum E {
e1 = 0x,
e2, e3
} e = e3;
#define SA(I,X) int a##I[(X)? 1 : -1]
SA(1, sizeof(E) == sizeof(__int128));
> Integer constant types should be tak
The v850 is a dwarf-debug target, but not a dwarf-unwind target. In
dwarf2out.c we first calculate the "fp to fb offset" in
compute_frame_pointer_to_fb_displacement. The frame pointer is not
needed, so note that we include the fp-sp elimination offset in
frame_pointer_fb_offset.
---
> (And who are all of the people in the CC list? Is there some other
> list discussing this?)
We were randomly CC'd in the initial spew of emails, although I
personally am already on the gcc list, so CC'ing me on this only
serves to mess up my procmail filters. I've asked privately to be
remove
> Here, if Company A and Company B both want to recruit, but A adheres
> to the policy while B does not, A loses.
I think that's a compelling reason to keep it at "no ads". We've got
enough stress just developing gcc; we don't need the extra stress of
corporate pressure to act against our fellow
[note subject change, since I suspect it's not v850-specific]
There are 18 target directories that define DWARF2_DEBUGGING_INFO (not
counting all those that get it from elfos.h et al) but only 8 that
define DWARF2_UNWIND_INFO (both from just a simple grep).
> Date: Tue, 4 Apr 2006 16:41:25 -0400
> Both are supposed to happen. I can't really debug this without a
> test case. This works on ia64, which is a non-dwarf-unwind target,
> so that in-and-of itself isn't the problem.
This is from the gdb.base testsuite:
int factorial (int value)
{
if (value > 1) { /* set breakpoint 7 here */
Don't build *in* the source directory. Use two separate build
directories, one for each target.
At this point, you should run "make distclean" to clean up the source
tree before doing anything else.
> "gcc -o myprog myprog.c -L./ -lfoo" I get an error for each one of the
This isn't the right forum for this (try the binutils or cygwin
forums), but try just listing the .dll itself on the gcc command line
(no -L or -l).
Try this patch: http://people.redhat.com/dj/m32c/gcc-reload1.c.patch
It might help a little, although it doesn't solve the fundamental
design flaw (not being able to restart reload after breaking a complex
insn apart).
If I try to build libssp in a combined tree with newlib and binutils,
for an embedded target, configure keeps barfing because libssp's
configury is trying (in lots of places) to build executables and/or
run them, neither of which works in for crosses in a combined tree.
And GCC_NO_EXECUTABLES jus
Another one like libssp.
In libstdc++-v3's configure.ac, we see this:
# This depends on GLIBCXX CHECK_LINKER_FEATURES, but without it assumes no.
GLIBCXX_ENABLE_SYMVERS([yes])
The comment lies. If we haven't yet checked the linker features, it
will check them, and configure will fail in a comb
> The key problem is that we have two ways
And then he lists *three* ;-)
> * Hard-coded information about the target
I seem to recall a long time ago, talk of a global target capabilities
database. It proved too unwieldy to implement. However, a toplevel
configury snippet (aka config.gcc) mig
> Right, I understand. Assuming that they exist at this point, you
> could theoretically pass enough options to make it work -- although,
> as you say, it's hard to know what those options ought to be. If
> everything is set up right, it's -I options (for libc headers), -L
> options (for libc an
> Well, that sounds like an autoconf bug. If it refuses to work when
> presented with a pile of compiler options, that just sounds bad.
No, I think it's our bug - we do this:
GCC_NO_EXECUTABLES
GLIBCXX_ENABLE_SYMVERS([yes])
You can't logically expect that to work, no matter how many compiler
o
> I see -- but why did we set GCC_NO_EXECUTABLES? Don't we only do that
> when we've failed to link things?
No, it's explicit:
if test "$build" != "$host"; then
# We are being configured with some form of cross compiler.
GLIBCXX_IS_NATIVE=false
case "$host","$target" in
*-*-darwin*,
> What are you building here? A combined tree including newlib? If
> so, I bet you aren't specifying --with-newlib; that turns off a
> bunch
The toplevel configure automatically adds that in a combined tree (or
at least it should), if newlib is being built.
The two targets I'm currently workin
I'd like to extend the FPSCR support functions in SH's libgcc.a to
include a way for applications to change the bits that GCC doesn't
care about (exception handling, denormals, etc). I've come up with
this routine and (after much head-banging) managed to test it on real
hardware. The idea is tha
> > __fpscr_values[0] &= off;
> > __fpscr_values[0] |= on;
> > __fpscr_values[1] &= off;
> > __fpscr_values[1] |= on;
>
> Ok, I'll bite. Why are there two of them?!
Well, this is the real reason why we need an API and not just a simple
builtin. GCC uses that table of values to quickl
> Well, if changing fpscr and fpscr_values at the same time was your
> only concern, you could just call __set_fpscr. That puts the burden
> of preserving the SZ / PR bit in fpscr on the caller, though.
> (i.e. read the current value of fpscr, modify the bits you want changed,
> place that change
For mips-elf builds, crtbegin.o is built with -G 0 ("in case $gp isn't
used"). This makes __dso_handle be put in .data. However, the
"prototype" created by cp/decl.c is "void *__dso_data" which causes
GPrel addressing if your application is built without -G 0 (i.e. the
default), which causes lin
In default_secondary_reload, we have this code:
if (reg_class_subset_p (reload_class, insn_class))
{
gcc_assert (scratch_class == class);
class = NO_REGS;
Why doesn't it allow the scratch class to be a superset of the desired
class? I'm trying t
> What reason is there to have scratch_class be something else?
SECONDARY_RELOAD_CLASS has the option of limiting the reload class.
The mn10300 has a generic SImode reload_in that allows GENERAL_REGS,
but SECONDARY_RELOAD_CLASS specifies a smaller class based on the
registers that need reloading.
> I'd hesitate to apply patches to default_secondary_reload.
Even if it's wrong?
> If your port triggers any of the sanity checks, convert it to the
> new infrastructure, as it provides a much better interface.
In my case, I'm just trying to get the am33 port to function, because
I have some pa
How about this? Tested under mipsisa64-elf with no regressions. The
other two I found by inspection; they're the only other two that have
.sdata and use -G 0.
2006-05-09 DJ Delorie <[EMAIL PROTECTED]>
* crtstuff.c: Ensure that __dso_handle is placed in .sdata for
> I'll pre-approve that change, but I'll also defer to any other
> maintainer who has a solution they prefer.
How about this one?
2006-05-15 DJ Delorie <[EMAIL PROTECTED]>
* crtstuff.c (__dso_handle): Set section from
TARGET_LBIGCC_SDATA_SECTION if
> > How about this one?
>
> OK.
Thanks; committed.
> Who maintains this automatic merge process?
Me. I have a cron job that checks out gcc's and src's libiberty and
include, compares them, copies any differing files to src, and sends
me email. I then run a "do it" script to do the actual commit.
There's not much advantage in using this setup f
> Was there not a way to combine the two (gcc and src) via console commands?
We're not talking about combining source trees for a build, we're
talking about making sure both source trees happen to have the same
sources in them to start with.
> ! intl/; config.rhost; libiberty/; libiberty's part
> ! ...
> ! merge. Otherwise, changes are automatically merged, usually
> ! within a day.
Who signed up to do the automatic merge?
> I will unless you want to add this to the libiberty merge you do now.
I don't mind adding it to my script, if people agree that's what they
want. It's just that nobody asked :-P
> Then this must be a very dummy question. How the compiler keep the
> instruction order in the RTL IR format in a function? By the information
> like "insn 50 56 51" ? e.g.,
> (insn 50 56 51 4 (clobber (reg/i:SI 0 ax)) -1 (nil) )
It's a linked list. The 56 and 51 link to the previous and nex
> I hereby request that you add automatic intl/ merging to your script. :-)
Ok :-)
FYI m32c still doesn't build libssp due to the GCC_NO_EXECUTABLES
thing. Works OK with it disabled, though, for C and C++. From whence
will release notes be published?
> From whence will release notes be published?
>From *where* of course.
vec.h has a lot of unprotected 'static inline' functions. With its
inclusion in many build-machine files via rtl.h, this essentially
precludes building on a machine without gcc (and a recent enough one,
at that). It also requires using optimization for build/*.o, which
complicates debugging (tha
I've got a case where an unconditional simple jump is being removed,
yet it doesn't jump to the next insn. The code in question seems
suspect...
Here we force CLEANUP_CFGLAYOUT true:
void
cfg_layout_initialize (unsigned int flags)
{
. . .
cleanup_cfg (CLEANUP_CFGLAYOUT | flags);
}
in clean
> I'd imagine you might want to update bugs.html, in this case?
Or, perhaps, branch's install.texi's "Host/Target specific
installation notes for GCC" ?
> You're misunderstanding how this code works. In cfglayout mode,
> there is no "order" in the basic blocks such that
> BLOCK_FOR_INSN(NEXT_INSN(BB_END(BB)) ) == BB->next_bb. This means
> that you can fall through to other blocks than next_bb.
Thanks for the tip, I figured out what was really ha
> Sounds like you need a memory clobber constraint on the asm... ?
Yup, that looks like it would do the trick. Thanks!
> I haven't found anything in the docs that I see that explains
> the libiberty library.
You didn't find the libiberty documentation? It's separate from the
gcc documentation, but available on the gcc docs web page.
> Can this be compiled without having to compile a whole new compiler?
Er,
h8300 has an HImode insv pattern. If you try to use it with an SImode
argument, expmed.c uses gen_lowpart to force it into the desired mode.
However, gen_lowpart eventually fails for pseudos on big endian:
rtx
gen_rtx_SUBREG (enum machine_mode mode, rtx reg, int offset)
{
gcc_assert (validate_
> Feedback welcome!
Right-side navigation bars are nonstandard. It should be moved to the
left side. Don't accept the search engine excuse; that's easily
fixable. Also, by fixing the search engine issue you punish Lynx
users; the navigation menu is now near (but not at) the end of the
text.
S
> On this one, we follow the style of http://www.gnu.org. Looking
> into the CSS there, I see that indeed they (and thus us) set a
> different background color, alas that color is #fefefe which is
> white for all practical matters.
>
> Okay?
It addresses that issue, yes.
> Is your concern mainly Lynx users (and similar users)? It should be
> feasible to move the navigation bar to the beginning for these while
> still keeping it on the right side to be in sync with www.gnu.org.
Lynx is an example of a non-GUI browser. All non-GUI browsers would
suffer similarly.
> So I guess that there is no baseline as such, and the only
> meaningful way to use the results is to compare testsuite outputs
> with and without your changes?
That's what I always do. Hence the "no regressions" we report;
they're before/after regressions.
Very important to diff the two sourc
> If you're doing up a new port, and want it to work well, then the
> absolute, there should be no unexpected failures is a good place to
> aim for.
It's a wonderful absolute, but not always practical. I keep a history
of test results for my ports, with a goal of "no regressions" relative
to tho
It looks like crt1.asm unconditionally includes an sh3e opcode (stc
spc,r1) which causes problems trying to build an sh2a-single-only
executable, which falls back to sh2e but doesn't have this sh3e
opcode. Comments?
1091 ! Here handler available, call it.
1092
> It's not actually unconditional, but the condition it depends on is set
> conditionally with a flawed condition. Please try the attached patch.
That seems to fix it, although I only tested a simple hello.c program.
Thanks!
I'm looking at the H8/300 frame debugging info, and it seems to me
that gdb needs to have at least *some* information about where the
return address is in order to unwind the stack using dwarf2 call frame
information, perhaps because H8/300 saves the RA on the stack, not in
a register. However, w
> Yes, that's clever. But, you can create a symbolic link to the
> sysroot from each installation with a single command. And, your
> installer for third-party developers can do that for you.
Beware - the linker expands symlinks to determine if a library comes
from the sysroot or not. It affect
In cp/cvt.c we have this code in cp_convert_to_pointer:
if (INTEGRAL_CODE_P (form))
{
if (TYPE_PRECISION (intype) == POINTER_SIZE)
return build1 (CONVERT_EXPR, type, expr);
expr = cp_convert (c_common_type_for_size (POINTER_SIZE, 0), expr);
/* Modes may be differen
> Who's "we"?
"We" means "gcc".
> The middle-end and relevant back-ends support it, but clearly not
> all the front ends. C and Ada does but your experiment seems to
> show that C++ does not.
Does this mean that there's a bug in the C++ front end?
> I'd say so, but is more likely is in the ICE-on-illegal-program
> class.
That puts it back to the original question. Is the program legal or
not? I.e. do we support multiple simultaneous pointer sizes?
> And back to my original answer: it's up to each language to decide
> that.
Hence my original question: is it legal or not? What did the C++
developers decide?
There are occasions where gcc wants to read some subreg of an address
in the GOT (builtin_strlen is one example, depending on optimization).
However, this code in s390.c (s390_decompose_address()) seems to disallow
such constructs:
/* In the small-PIC case, the linker converts @GOT
> The GOT is an array of addresses, and [EMAIL PROTECTED] addresses one of these
> addresses. Thus [EMAIL PROTECTED] points to the address of a different and
> unrelated variable, assuming it is still within the range of the GOT.
You must have a 32 bit machine on your desk ;-)
On a 64 bit BE ma
> However, the C++ definition has been amended at the last Lillehammer
> meeting to allow that cast as "conditionally supported": either it is
> valid or it errors out. the compiler has to tell.
Also, the mechanism to create multiple pointer sizes
(attribute((mode))) is a GCC extension. Hence,
> I'm very suspicious of allowing users to specify this via attributes.
Me too, but that's what extensions are all about. You never know what
the user is going to need to do.
The M16C is an example - it has a 16 bit pointer, but has a few
special opcodes for using a 32 bit pointer to access add
> Aren't there some targets (like ia64-hpux) that support two different
> sizes of pointers,
Heck, the i386 has ALWAYS supported multiple pointer sizes (16, 16+16,
32, and 32+16). We've just refused to pay the (high) price for
supporting them.
> Well, I think it's in direct conflict with the C++ standard. If "X" is
> a 32-bit pointer type, and "x" is a value of type X, "Y" is a 16-bit
> pointer type, then:
>
> (X*)(Y*)x
>
> is supposed to get you back the value of "x", but I don't see how that
> can work, in general.
Where in the
> The "except that" sentence implies the statement above, assuming
> that the pointed-to type does not have stricter alignment. So, if
> casting a 32-bit pointer to int to a 16-bit pointer to char and back
> does not always yield the same value, then something has to give.
reinterpret_cast doesn
> > reinterpret_cast doesn't require that the intermediate form have the
> > same bit pattern.
>
> Exactly so. However, all valid pointers must be handles, so unless the
> 32-bit address space is "sparse", something will go wrong.
I would go so far as to say that it's defined (hence supported)
> I think having pointers be the same size is ingrained in the whole
> compiler, not just the front ends.
Having *implicit* pointers be *a specific* size certainly is. Made
the m32c project a lot harder. There's a lot of places that use
POINTER_SIZE instead of MODE_SIZE(x), or Pmode instead of
> I'm not sure if I understand. In ISO C++, it would be fine for "char *"
> to have more bits than all other pointers. The standard says X* -> Y*
> -> X* is value-preserving if Y has no stricter alignment than X. Since
> "char" has weak alignment requirements, Y can be "char". Is that what
> y
> 1) Any advise on selecting Linux distro?
Any one will do. Or Windows, MS-DOS, AIX, IRIX, Solaris, Mac OS/X, or
any other platform GCC runs on. Use whatever you're comfortable with.
> Although, I guess the FSF and RedHat would encourage you to use a
> free operating system instead of any of the propietary ones
> mentioned above. Isn't it? ;-)
Although this is straying off-topic, I'll answer this one time - the
FSF would prefer that everyone use nothing but free software, but
> > typedef void (*ifunc)() __attribute__((mode(SI)));
> > ifunc __attribute__((section(".resetvec"))) reset_vector = start;
>
> Maybe it is just me, but it seems more natural to have:
> typedef void (*long ifunc)();
You can use #defines to make it pretty:
#define far __attribute__((mode(SI)))
> I'll again point out that in your reset-vector example you don't
> actually need any pointer operations.
I'm not trying to dereference any of these nonstandard pointers. I
just need to do all the other things - assignment, copy, storage, cast
to/from integers, etc. Rarely, calling a function
> vects[A0_VEC] = __builtin_pointer32 (timer_a0_handler);
Note that the builtin would be needed for run-time conversion between
pointers of different sizes, i.e. casts. Why? Well, gcc doesn't
"just know" how to do such conversions. For example, TPF has a 31 bit
address. To convert it to 64,
> Good! In that case, you don't need them to be pointers at all. :-)
>
> I think you should just declare them as integer types.
That makes initializing function pointers messy.
Besides, they're not integers. They're pointers. I'd *like* to be
able to dereference them in some simple ways in t
> but I think you're much more likely to actually get the built-in
> approach to work correctly in C++.
But... initializing function pointers already works, without builtins.
Initializing an N bit pointer from an N bit integer now works with a
cast.
Copying an N bit pointer to another N bit poi
> Sure, it would be nice if these things were pointers.
At the moment, they are.
> However, I will reject any patch to support these alternative
> pointers in C++ until all the language issues have been resolved.
At the moment, there are no language issues to resolve. The only
thing people we
> # I'm not trying to dereference any of these nonstandard pointers.
Not *now*. I'd like to in the future.
> Okay for stage1?
Ok, assuming everyone agrees to those versions ;-)
> 2006-10-12 Kaveh R. Ghazi <[EMAIL PROTECTED]>
>
> * configure.in: Require GMP-4.1+ and MPFR-2.2+.
> * configure: Regenerate.
> Could this patch be applied now?
> http://gcc.gnu.org/ml/gcc/2006-07/msg00210.html
Assuming it's been bootstrapped with no regressions, and the legal
paperwork is in place, yes.
> Okay for mainline?
Ok. src too, please.
> 2006-11-06 Kaveh R. Ghazi <[EMAIL PROTECTED]>
>
> * configure.in: Robustify error message for missing GMP/MPFR.
>
> * configure: Regenerate.
The r8c/m16c family cannot shift by more than 16 bits at a time ever,
or 8 bits at a time with constant shifts. So, to do a variable number
of shift on a 32 bit value, it needs to emit a conditional, turning
the attached example into this:
i = 0xf;
if (j >= 16)
{
i >>= 8;
i >>= 8;
I compared the generated code with an equivalent explicit test,
and discovered that gcc uses a separate rtx for the intermediate:
i = 0xf;
if (j >= 16)
{
int i2;
i2 = i >> 8;
i = i2 >> 8;
j -= 16;
}
This seems to avoid the combiner problem, becuase you don't have the
same
"Ed S. Peschko" <[EMAIL PROTECTED]> writes:
> And in any case, why should it be off-topic?
Regardless of how much it affects, us, it's off-topic *by definition*
in *this forum*. This isn't the right place to discuss such topics
because that's the way we want it to be.
> This is because libiberty's API is all internal really and is always
> changing and never stable. It is not really a well defined library
> unlike say libgomp.
... although we do try to keep backward compatiblity when possible, so
that newer libiberties work with older gcc/binutils/gdb/whateve
Joe Buck <[EMAIL PROTECTED]> writes:
> The ordinary user who builds gcc from source does not need *any*
> version of automake, autoconf, etc., so any strict requirements that
> are imposed on these tools have an impact only on gcc developers.
I wish we could have similar requirements for GMP and
> > I wish we could have similar requirements for GMP and MPFR, rather
> > than requiring the user to pre-install them on pretty much EVERY
> > computer.
>
> Do you mean that gcc should be distributed with GMP and MPFR libraries
> in the tarball? (There had been a discussion about including them
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> > That idea got nixed, but I think it's time to revisit it. Paolo has
> > worked out the kinks in the configury and we should apply his patch and
> > import the gmp/mpfr sources, IMHO.
>
> Note that these two issues (my patch, which by the way was start
> DJ, as a build machinery maintainer, you are authorized to approve
> such a patch. Is anything holding you back?
You mean, besides politics?
The last time such a patch came through, we were in the middle of
discussing the various --with-* options. I wanted to let that settle
first.
> I suggest that you send this report to [EMAIL PROTECTED], the
> DJGPP port of GCC maintainers are much more likely to respond there.
He did that first.
Is your target a newlib target? If so, are you including --with-newlib?
> Why isn't --with-newlib the default for newlib targets?
--with-newlib *tells* us that it's a newlib target.
> Newlib targets are targets without their own native libc. I find it
> exceedingly hard to believe that AIX falls into this category.
Newlib supports some platforms that have their own native libc.
subreg_get_inf() in rtlanal.c blindly assumes that any hard register
can hold any smaller-than-native mode:
nregs_ymode = hard_regno_nregs[xregno][ymode];
. . .
&& (GET_MODE_SIZE (ymode) % nregs_ymode) == 0)
However, there are registers in m32c that cannot hold a QImode value.
By this,
> So can you expand on what is actually going wrong?
At the moment, the problem is divide by zero - nregs_ymode is zero.
IIRC the problem before was that reload kept choosing $r2 or $r3 for
pseudos that were QImode. Since the m32c is already register starved,
this leads to unfixable situations.
101 - 200 of 742 matches
Mail list logo
