Yes, this is OK.
Thanks, applied.
(to be very pedantic, we can assert that MAX_OFILE_ALIGNMENT=256 on
x86-64 targets, but well).
My head hurts at the thought of x86_64-aout.
I fully agree with Richard's interpretation concerning
BIGGEST_ALIGNMENT meaning - ie in special cases for
Something like this, then?
Sure.
Committed, then.
Why do we use 256 instead of BIGGEST ALIGNMENT in ix86_data_alignment?
This is causing all sorts of build problems for djgpp, as I'm getting
lots of warnings about too-big alignments, and with -Werror...
Index: i386.c
===
--- i386.c
It is to improve performance of string functions on larger chunks of
data. x86-64 specify this, for x86 it is optional. I don't think we
should end up warning here - it is done only for static variables where
the alignment can be higher than what BIGGEST_ALIGNMENT promise.
Higher than
Yes, BIGGEST_ALIGNMENT is supposed to be the biggest alignment the
compiler will ever use.
Will ever use, or can ever use? Based on the code, it looks like can
ever use - i.e. it's an edict to the compiler to not exceed that
value, thus varasm warns when you exceed it.
So if
For ELF, this would be 256, good. For pecoff, that would be smaller.
Actually, I think pecoff supports larger alignments. DJGPP is plain
COFF (similar to i386-coff).
On behalf of Red Hat I would like to publish patches to add support
for the Toshiba Media Processor (MeP) to GCC 3.4.
We don't expect this port to be accepted into the gcc source tree
as-is, as the 3.4 branch is closed to new ports, and this port needs
some core gcc changes. We don't yet have a
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.
I believe we've generally assumed that all hard registers can be
subreg'd. That said, HARD_REGNO_MODE_OK should keep QImode values
out of those registers. And insn constraints should keep reload
from using those registers for QImode insns. So can you expand on
what is actually going
Followup - it seems that CANNOT_CHANGE_MODE_CLASS governs whether
these subregs are attempted. It's not clear from the documentation
that it does this.
Here's an example of bad assumptions. The current code calculates the
subreg location BEFORE checking to see if such a subreg is legal.
This patch moved the legality check before the location calculations.
With this patch, I can build gcc's libraries and newlib, but I haven't
run full
Hello to everyone,
Wrong list. The R8C link scripts are part of newlib (libgloss), not
gcc.
RESETVEC (r) : ORIGIN = 0xfffc, LENGTH = 4
But this is wrong. The Resetvektor for R8C is only 16Bit and not
32bit.
The REJ09B0169-0100 page 61 shows the reset vector as being 0FFFCh to
0h.
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.
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.
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.
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.
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 started and
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
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/whatever.
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.
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
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;
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 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.
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 were
# I'm not trying to dereference any of these nonstandard pointers.
Not *now*. I'd like to in the future.
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 the
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
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
you mean?
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.
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
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 standard does
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't
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) if the
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
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
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?
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
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 affects
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,
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!
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 source
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 those.
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.
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.
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
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,
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
Sounds like you need a memory clobber constraint on the asm... ?
Yup, that looks like it would do the trick. Thanks!
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
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
! 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 next
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 for
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.
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 defined.
* doc/tm.text
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
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
mips, iq2000
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 link
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 changed
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
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)
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 and
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
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
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 working
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
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).
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).
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 */
[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
(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
removed
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.
When reporting DJGPP bugs, please run your app under gdb and use
where to get a traceback, or use djgpp's symify (or bfdsymify) to
replace these hex numbers with file/line information. You may need to
compile your application with -g to get symbolic debugging
information.
Call frame traceback
Is there a function like prev_nonnote_insn that, when it encounters a
label preceeded by a barrier, attempts to determine if there's a
single jump to that branch and returns it if so?
Some multi-core processors come with less L2 cache than their multi-CPU
counterparts.
This, and your other arguments, while valid, apply independently of
the CPU. There are a lot of factors that determine compile speed.
FYI SGIs tend to have crossbars.
Was that UMA or NUMA, and how far up
I think this is caused by a typos error in libiberty/pexecute.c. Doesn't
anyone
else see it?
Already fixed.
Has anybody done timings for gcc bootstrap / cross builds and
regtests with modern multi-core processors? I wonder what a
sensible modern configuration would be for gcc development, but the
the multimedia and games benchmarks I found on the web neither seem
particularily relevant, nor do
cc1: error: ../include/sys/version.h: No such file or directory
What I'm doing wrong?. Where should I get the missing header files?.
This is a header that comes with DJGPP's library. Like most cross
compilers, you have to install part of the runtime package (usually at
least the
Well, cmpsi2 for example. and divsi2.
You mean divsi3? Many targets don't have div at all.
Er, right. divsi3.
What's so bad about have the flag as side-effects ?
You can't put any other insn between the compare and the jump. Like,
if you wanted to move an address into a register to do the jump, you'd
lose the condition bits.
The advantage of having most insns set flags, is you can sometimes
avoid the
1001 - 1100 of 1257 matches
Mail list logo
