> In file included from /usr/include/stdio.h:831,
> from ../../gcc/gcc/tsystem.h:90,
> from ../../gcc/gcc/crtstuff.c:62:
> /usr/include/bits/stdio.h: In function 'vprintf':
> /usr/include/bits/stdio.h:37: internal compiler error: Segmentation fault
You are getting a
This one also works for -mno-80387 and simplifies insn pattern constraints a
bit:
2005-10-05 Uros Bizjak <[EMAIL PROTECTED]>
* config/i386/i386.h (TARGET_FISTTP): Enable also for
TARGET_SSE3 and only for TARGET_80387.
* config/i386/i386.md (fix_trunc_fisttp_i387_1,
Biggs <[EMAIL PROTECTED]>
Paolo Bonzini <[EMAIL PROTECTED]>
PR target/23809
* doc/extend.texi (x86 Built-ins): Document that -msse and friends
enable the instructions and not just the built-ins.
* doc/invoke.texi (x86 Options): Likewise.
I
But if it's not a win for most of us, we probably shouldn't do it.
There is no perfect revision control system. None of the currently
production quality open source ones are any better.
I think it is natural that people start asking questions when they are
getting ready for the real thing.
Having 5 subversion trees will need much more space (for local
pristine copies), which I don't really have. Is there any way to force
subversion use one pristine tree for all modified trees, or is my way
of handling things completely rotten?
I have a script called svn-switch-patch that undoes
uses "CVS" for mainline most people people can check out; it uses
"arch" for manging branches where developers do experiments.
I found arch very interesting, and I am using it for GNU sed and GNU
Smalltalk. I liked very much the idea of working offline, and the very
small requirements that
| Even if we assume that it's impossible to upgrade OpenSSH on a given platform
| for some weird reason,
I appreciate your effort in this, but I strongly suggest that you
refrain from calling reasons why people can't install the latest
versions of supporting tools "weird".
I agree. For examp
For example a cron job could simply grab a diff of
everything since the last time it ran and then apply it to the CVS
repository. The only even slightly tricky part would be getting the
cvs add and rm commands right. We could run that script an hour.
Anybody who needs more cutting edge sources
(define_insn "loadsf"
[(set (match_operand:SF 0 "register_operand" "=r")
(mem:SF (match_operand:SI 1 "immediate_operand" "m")))]
This makes no sense, because the constraint means that the mem's operand
is an immediate before reload (and you want it to be a register), and a
mem afte
Thanks. It seems work now. But... when I define the like insn for QImode,
(define_insn "loadqi_men"
[(set (match_operand:QI 0 "register_operand" "=r")
(mem:QI (match_operand:SI 1 "general_operand" "r")))]
""
"lbu.u\t%0,0(%1)"
)
The compiler comes out such error,
error: insn do
Just a nit: 5 years ago that was true. Now \n is "native"
Was that part of the OS/X migration, or otherwise? Just curious.
Part of the migration. OS X /is/ unix. Ok, I'm sure that's an
inaccurate statement and I trust the more experienced Apple guys here
will gently correct me. But
Is there a quick way to turn a CVS checkout to SVN, other than making a
patch and applying to a fresh SVN checkout?
By the way, it could be a good thing to tag the SVN repository revision
corresponding to the transition.
Paolo
Branko Čibej wrote:
Joe Buck wrote:
On Wed, Nov 02, 2005 at 06:28:42PM -0500, Daniel Berlin wrote:
On Wed, 2005-11-02 at 14:33 -0800, Mike Stump wrote:
On Nov 2, 2005, at 2:18 PM, Joern RENNECKE wrote:
I tried:
bash-2.05b$ svn diff Makefile.in svn+ssh://[EMAIL PROTECTED]/svn/
- I should add a GMPLBISDIR variable in the configure.in to store the
paths to the libraries as a colon-separated list of absolute paths
- the GMPLIBSDIR should be added to the HOST_LIB_PATH
Yes.
- then, i don't really know how this should come into HOST_LIB_PATH;
perhaps by way of HOST
Middle-End
--
>>
>> [snip approvals]
This only leaves out the two patches for 23948 and 24365, which are both
showstoppers; plus 24408, whose audit trail says it's rather hard to fix
it in 4.1.
Paolo
François-Xavier Coudert wrote:
- with this patch, the libgfortran is built, but the gfortran
testsuite doesn't run; why isn't $(RPATH_ENVVAR) including HOST_LIB_PATH
for the testsuite?
It should
Well, it doesn't. The problem is that the gfortran testsuite is not
run with the topl
I must say I am a bit surprised that gcc never takes advantage
of the fact that inc and dec do not destroy the carry flag, this
is quite significant for some loops.
And which is extremely bad on Pentium II and newer.
Paolo, who made the first paid computer work on Realia COBOL
I would like that svn print the URL of each file in the diff output,
like CVS's `RCS file'. One of the scripts I use to test GCC (which I
have not contributed yet because of the svn transition) used it to
detect the directory in which the patch should apply.
Danny, can you do it for 1.3? If
BTW: Is there a way to include a C function heading in diff output? I have tried
'svn diff -x -p' to get:
svn: '-p' is not supported
To add this by default, I made diff-cmd point to this script I called
gcc-diff
#! /bin/sh
case "$1" in
-u|-U*) exec diff -p "$@" ;;
-c|-C*) exec diff -p
Yes, of course, but what if you've checked out using a read-only
protocol? Is it going to fall down? Refuse to commit entirely?
You can use svk mirror --relocate before and after svn push --lump.
Paolo
This patch has both a toplevel part and a part in gcc/, so I don't
know exactly who can approve it.
I haven't really understood why you need this patch.
If you need to set the LD_LIBRARY_PATH manually after installation,
something is broken. If the GMPLIBSDIR is for example something in your
Adrian Prantl wrote:
Hello everybody,
I am currently working on creating a new gcc backend for a word-addressable
machine with 24-Bit general purpose registers.
While doing so I came across a few inconsistencies regarding the usage of the
BITS_PER_UNIT Macro. (and UNITS_PER_WORD, in a related st
I didn't realize that we had a target with BITS_PER_UNIT == 8 &&
UNITS_PER_WORD == 1. I see that for the AVR POINTER_SIZE is 16, which
suggests that this code should use POINTER_SIZE or GET_MODE_BITSIZE
(Pmode) rather than BITS_PER_WORD. But restricting it to
BITS_PER_WORD >= 32 should also be f
There are several examples. One is converting from a derived class
to a base class when there is multiple inheritance. An offset must
be subtracted, unless it is a null pointer.
Why does it matter if the pointer is null? It is an error
in the program if it uses the result, but the same is true
As an example, combine pass is based on outdated work of Fraser,
Proebsting etc.
And combine is useful for ia64 because...? Alternatives for combine
exist for targets with relatively simple ISAs with few parallels.
While it is true that combine is not a very good algorithm, combine is
not
for (i = ((unsigned) ~0 >> 1) - 3; i <= ((unsigned) ~0 >> 1) + 3; i++)
i <= ((unsigned)~0>>1) + 3
Seems like it overflows to me, or would cause "i" to have to
overflow to terminate the loop.
Yes, the two expression are respectively 0x7FFC and 0x8002.
It ought to work with -fwrapv, t
Graham Stott wrote:
It looks kike that patch contains a typo
The entry for nonmemory_operand has an extra bogus false
I'm sorry. The patch has been in my powerpc-apple-darwin8.2.0 tree for
months but rs6000 does not use nonmemory_operand. Thanks for fixing it.
Paolo
This patch makes --with-gmp and --with-mpfr similar to --with-as and
others, where you don't need to have the as program in your PATH if
explicitly specified.
I now understood what you are looking for.
A good solution would be to use the macros AC_LIB_LINKFLAGS and friends,
which were first
Robert Dewar wrote:
Richard Earnshaw wrote:
Possibly, but I think the more interesting observation is listed in
parenthesis: Can a volatile access ever alias a non-volatile access?
I think the answer is no, Certainly Ada has compile time rules
carefully written to make this impossible.
Usua
In his original message, Torbjorn indicated that Swox AB (the company of
which he is CEO) donated the code, and the old copyright file had an
entry for Torbjorn, though not Swox AB.
Well, the problem is that you're raising a legal technicality, and legal
technicalities are up to the FSF. Mayb
Well, I've been talking about doing this for so long that I feel I must
take this as a challenge... I will give it a shot.
All that I've done so far is to look at config.gcc and shudder at what a
mess it would be to separate libgcc. But really it is not necessary,
and one could keep #includ
Jeffrey A Law wrote:
I just tried to check in a change on the 4.1 branch. I get this
nice little message :
svn: Commit failed (details follow):
svn: Authorization failed
svn: Your commit message was left in a temporary file:
svn:'/fuel98/export/svn/gcc-4_1-branch/svn-commit.2.tmp'
You pro
GCC 4.0.x on s390{,x} aligned vector_size 1/2/4/8/64/128/... types
to their size, just vector_size 16 and 32 has been 8 bytes aligned
(BIGGEST_ALIGNMENT).
It is just a side-effect of the 3.4/4.0 code - if there was a supported
integer mode on the target for the requested size, then alignment of
svn switch --relocate {svn://,svn+ssh://[EMAIL PROTECTED]/svn/gcc
Thanks. I doubt I would have come up with that one on my own! :-)
Oh, that's just shell expansion for
svn switch --relocate svn://gcc.gnu.org/svn/gcc \
svn+ssh://[EMAIL PROTECTED]/svn/gcc
BTW Dan, though Jeff did not see it
J.C. wrote:
*** gcc-4.0-20051124/gcc/config/i386/i386.c Mon Nov 7 18:55:03 2005
--- gcc-4.0-20051201/gcc/config/i386/i386.c Thu Dec 1 01:53:01 2005
! #if defined(HAVE_GAS_HIDDEN) && defined(SUPPORTS_ONE_ONLY)
! #if defined(HAVE_GAS_HIDDEN) && (SUPPORTS_ONE_ONLY - 0)
Why did he remove
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
I've been considering working around this problem by just redoing the
whole .java->.class step whenever any .java file changes. That would
probably be slower for libgcj developers but at least wouldn't hugely
hurt folks working elsewhere. Also, most class library development
happens in Classpath
This is just a heads up that GCC has switched so that the toplevel
coordinates the bootstrapping.
The main change is that on a native configuration `make' will
automatically bootstrap, unless you configure with --disable-bootstrap
(and, since the binutils list is receiving this message, if you
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?
First of all, it's not polite to send things twice just because nobody
answered you.
Second, people on this listcould have as well ignored
s if you're not
bootstrapping).
Try the attached patch.
Paolo
2005-12-15 Paolo Bonzini <[EMAIL PROTECTED]>
* Makefile.tpl (all, do-[+make_target+], do-check, install,
install-host-nogcc): Don't invoke $(stage) at the end.
*
Yes it does. If nothing else, the archives are used to
provide canonical URLs for referring to messages.
What might not be clear is the need to run a search
engine on the sourceware server, especially if it
puts an awful load on the server at times and especially
when "foo bar site:gcc.gnu.org"
H. J. Lu wrote:
How can I rebuild stage 1 compiler with the system compiler? I used
to be able to do
# cd gcc
# make unstage1
# make restage1
But now ./prev-gcc/xgcc is used to build stage 1 compiler, not the
system compiler.
If the old bootstrap mechanism had already been garbage collected,
Will make quickstrap do the same as "make all"?
No, there's no "make quickstrap" at all! Citing from the "Top-Level
Bootstrap" wiki page:
Toplevel bootstrap is able to bootstrap a compiler with separate
reconfigurations and rebuilds of libiberty/libcpp/gcc in all the three
stages. It is
Christian Joensson wrote:
What about bubblestrap?
(See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25438)
A "make" from a toplevel is equivalent to the old "make bubblestrap" or
"make -C bubblestrap". In practice "make" just does the right thing,
compiling all that is needed to not h
Andrew Pinski wrote:
doing the following
$(srcdir)/configure --prefix=${HOME}/libobjc.trunk
--enable-languages=c,objc
make all
make -k check
make install
Why is it recompiling libcpp? That's the real bug.
Please open a PR because the discussion really belongs in Bugzilla.
Paolo
At the moment, we do this deliberately to preserve debug information.
However, once libgcc is moved out of to top level - hopefully along
with the gcc-provided include files - then gcc can be a pure host
directory, and we won't need to worry about this.
Uhm, we'd still need to have prev-libgcc w
I just did a fresh build testing a patch here and then I try make bubblestrap
and "no target 'bubblestrap'
I'm curious myself. Was this an intentional result of the toplevel bootstrap
stuff?
Yes. "make bubblestrap" is now called simply "make". As Giovanni put
it a few minutes ago:
"I wou
make[2]: Entering directory `/scratch/ogcc/stagefeedback-libcpp'
gcc -I/scratch/gcc/libcpp -I. -I/scratch/gcc/libcpp/../include
-I/scratch/gcc/libcpp/include -g -O2 -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -pedantic
Andrew Pinski wrote:
Trying to see if a bug was fixed (and an approved patch by me was still
needed), I
noticed that BOOT_CFLAGS was being ignored for profiled_bootstrap.
BOOT_CFLAGS was being ignored, period. :-)
Can you try this (and maybe commit it as obvious)?
Index: Makefile.def
===
I normally work in the "gcc" object directory and keep files there built by
the system compiler. That's my starting point.
Then I do a "make" to build, "make bootstrap" to do a bootstrap, "make
gnatlib_and_tools" and "make check-ada" to run acats, and then "make
unstage1" to get back where I s
Even better though would be some option to keep the "old style". As I
understand it, the point here is to add functionality at top level, but that
shouldn't be at the expense of functionality at the gcc/ level. Indeed I
see no reason that we can't be upwards compatible.
I can of course provi
Paolo, what do you think?
I think I agree. After all when I added the "ln -s" support we did not
have anything remotely similar to the current logic for "make all",
"make unstage", "make stage".
Paolo
(But let's give Paolo some time to address the technical issues first;
we are still in stage 1, so only developers, packagers, and brave testers
are supposed to use what is going to become GCC 4.2. ;-)
Also the reason why I've been collecting issues so far, instead of
posting all patches for ap
Yes, -gnatp is certainly not required in all cases (e.g. for debugging).
Sorry if I don't understand. How is a debugging option related to the
error Andreas reported, which is:
gcc -c -g -I- -I. -Iada -I/cvs/gcc-svn/trunk/gcc/ada
/cvs/gcc-svn/trunk/gcc/ada/ada.ads -o ada/ada.o
ada.
gcc -c -g -I- -I. -Iada -I/cvs/gcc-svn/trunk/gcc/ada
/cvs/gcc-svn/trunk/gcc/ada/ada.ads -o ada/ada.o
ada.ads:16:01: language defined units may not be recompiled
Here you are missing "-gnatpg gnata" in your line, although that could be
"-gnatg" or "-gnatpgn"
So you need a -gnat
Arnaud Charlet wrote:
So you need a -gnat option, or compilation fails?
You need at the very least -gnatg, although -gnatpg is highly recommended,
and -gnata is highly desirable for development
Ok. For now I'd stick with the patch I proposed to Andreas, but please
tell me if these asse
Arnaud Charlet wrote:
Could you please find a more elegant solution ? Thanks in advance.
See e.g. setting of EXTRA_GCC_FLAGS in Makefile.tpl for a way to handle that:
EXTRA_GCC_FLAGS = \
[...]
"`echo 'LANGUAGES=$(LANGUAGES)' | sed -e s'/[^=][^=]*=$$/XFOO=/'`" \
Unfortunately, t
ln: creating symbolic link `x86_64-suse-linux-gnu/stage1-x86_64-suse-linux-gnu'
to `stage1-x86_64-suse-linux-gnu': File exists
make[3]: *** [stage1-start] Error 1
make[3]: Leaving directory `/builds/gcc/misc'
make[2]: *** Waiting for unfinished jobs
make[2]: *** [configure-build-fixincludes
Arnaud Charlet wrote:
EXTRA_GCC_FLAGS = \
[...]
"`echo 'LANGUAGES=$(LANGUAGES)' | sed -e s'/[^=][^=]*=$$/XFOO=/'`" \
Unfortunately, there is no really easy and elegant solution. This one,
for example, would really oblige targets that want to specify Ada-only
flags to also include -Wall
So, the AIX makefile fragments config/mh-ppc-aix and
config/mt-ppc-aix could not just do
ADAFLAGS += -mminimal-toc
ADAFLAGS_FOR_TARGET += -mminimal-toc
The Ada Makefile already takes into account $(X_ADAFLAGS) and
$(T_ADAFLAGS)
Yes, but it provides no way to set them globally. That means
What is T_ADAFLAGS used for if as you say there is no way to set it globally ?
You can set it for gcc/ada only, not for the benefit of the entire
tree. It makes it hard, for example, to make libada really its own
toplevel directory, because T_ADAFLAGS is set within the gcc target
fragment
When the data section patch is merged into GCC, this may not be
necessary, so maybe we should just declare GNU Ada unusable on AIX until
that patch is committed.
Didn't you mention it is already broken for other reasons?
Paolo
Since I don't understand really if what I'm saying makes sense, I think
the best solution is to revert because it is also affecting people that
use --disable-bootstrap (whom I cannot blame at all).
That would certainly be better than the current situation, although if
you look at Makefile
Well if that's your criteria then sure, your previous change was also not
in the obvious category ;-)
Well, the `obvious' part of it was
flags_to_pass = { flag = ADAFLAGS };
flags_to_pass = { flag = BOOT_ADAFLAGS };
flags_to_pass = { flag = BOOT_LDFLAGS };
which I admit should not have commi
Etienne Lorrain wrote:
Hello,
A lot of people (me too) write this kind of code:
struct param1_str *param1;
struct param2_str *param2;
struct param3_str *param3;
error = treat_alpha (param1, param2, param3);
if (error)
printf ("treat_alpha failed error %d, param1 = %p, "
inish overnight,
this time including Java.
Paolo
2005-12-18 Paolo Bonzini <[EMAIL PROTECTED]>
* combine.c (simplify_shift_const): Leave only the fallback
case when no simplification is possible. Extract to...
(simplify_shift_const_1): ... here. Always create a new
This was meant for gcc-patches of course, sorry.
http://gcc.gnu.org/ml/gcc/2005-12/msg00633.html
Paolo
It looks to me like this last changed around 2005-06-16 on HEAD, and we
assume that the assembler installed in $prefix is the assembler you
want the compiler to be using - it's the same assembler you'd get if
you said "as", so why shouldn't we use it?
When building from a combined tree, I sti
Daniel Jacobowitz wrote:
On Thu, Dec 22, 2005 at 05:58:34PM +0100, Paolo Bonzini wrote:
It looks to me like this last changed around 2005-06-16 on HEAD, and we
assume that the assembler installed in $prefix is the assembler you
want the compiler to be using - it's the same assembler
One appropriate default for --with-build-tools could be the same as
the defaults for --program-transform-name. A default native build
would use 'as', a default cross build would use '$target-as'. Most
people using --program-prefix would probably also pass the same value
to --with-build-tools.
Gunther Nikl wrote:
On Fri, Dec 23, 2005 at 10:10:01AM +0100, Paolo Bonzini wrote:
2) look into the --with-build-tools path, for both a Canadian cross and
a native build. This defaults to $exec_prefix/$target/bin, so the
default build tools (used in autoconf tests and by the being-built
Wait wait wait wait wait. This is a cross compiler. Are we mistakenly
running $prefix/bin/$target-as, which is a bad version, or are we
really running $prefix/bin/as, a program named "as"? If we're doing
that, let's fix that separately - it's a nasty bug!
Probably my configuration will not
Gunther Nikl wrote:
On Fri, Dec 23, 2005 at 08:36:21AM -0500, Daniel Jacobowitz wrote:
On Fri, Dec 23, 2005 at 01:19:14PM +0100, Gunther Nikl wrote:
Sorry for being vague, its a cross-compiler (build == host). The build
errors out for libgcc.a since gcc/xgcc uses the "wrong" assembler. The
la
Hello,
this is a real log of debugging GCC (with stage1 C miscompiling stage2
Fortran), including finding the miscompilation and fixing it. I hope it
helps understanding the way toplevel bootstrap works.
../configure
I just need two stages because I know that stage1 C miscompiles stage2
I just found this in tree-cfg.c; the comment is probably wrong with
respect to const and pure. What do you think?
/* Return true if we need to add fake edge to exit at statement T.
Helper function for tree_flow_call_edges_add. */
static bool
need_fake_edge_p (tree t)
{
tree call;
/* NORE
Just to remember you all that before committing a patch, you now have to
check if the copyright year includes 2006.
CCing people who committed patches so far this year. :-)
Paolo
make all-stage2 STAGE1_LANGUAGES=c,fortran
So, how would I now get a cc1plus/f951/jc1/cc1 binary compiled by the
stage0 (host) compiler?
That would give me the 4 '-g -O0' binaries compiled with the system
compiler. I've tried following these notes, but it always gives me
binaries built
ion calls if they specify call-clobbered registers.
This patch was bootstrapped on powerpc-apple-darwin8.3.0, and H-P
Nilsson tested on cris-axis-elf that it causes no assembly code
generation difference on the testsuite (except for fixing the bug!) and
CSiBE.
Ok for mainline?
2005
> make stage1-bubble STAGE1_LANGUAGES=c,c++,fortran,java
> Wow, that's awkward.
I understand, but I have a patch to make it easier.
Patches for the toplevel take a long time to review, and I cannot handle
posting too many patches and tracking them. Not even two patches. Currently I
> > So the previous system was easy? IMO it's just that it's been tested for
> > 15 years. Personally it took me a lot of time to understand the working of
> > bubblestrap, stage*_copy, stage*_build, and so on
>
> The previous "make" was easy. Now even "make" is too much intricate for
> common
I see it as "impossible with the old bootstrapping mechanism" as being
for a good reason: it's not part of the compiler! I still fail to understand
what it means to "bootstrap" anything other than a compiler: that word, to
me, talks only about compilers.
Bootstrap, to me talks about the whol
I *suppose* you could include other parts of the toolchain in the "bootstrap",
but I think the advantages of doing so are pretty small.
What about libraries used by GCC? From the user point of view it is a
bad bug that you cannot bootstrap a 64-bit compiler starting from a
32-bit one (beca
Richard Kenner wrote:
From the user point of view it is a bad bug that you cannot bootstrap
a 64-bit compiler starting from a 32-bit one (because stage2 does not
find a 64-bit libiberty to use).
To me, "bootstrap" means that all three compilers are identical in
configuration, so I don'
So please, propose your usage case. Don't tell us which commands you expect
to be working, tell us of your workflow and why you think it's broken by the
new system. Probably it's just a misunderstanding, since there are no real
features that are being lost with the new system (while many bugs an
The point is that 32->64 is a cross-compiler and it's only meaningful to talk
about "bootstrapping" a native compiler.
It's not 32->64. It's 64->64, but built with a 32-bit compiler.
Anyway, I find this discussion secondary now that we reached a point
from which I can help you.
You
Richard Kenner wrote:
If you configure with --enable-languages=c,ada (which I guess is a good
option for you), a toplevel "make" does everything you need -- nothing
less, nothing more.
No, I want to configure with all the languages since I want to build them
all (and have to, in orde
Eric Botcazou wrote:
Then I'm confused: I thought the whole point of --disable-bootstrap is
to keep the old mechanism instead of getting the new one.
Not quite. You can do an old-style build and an old-style bootstrap from the
*toplevel* directory with --disable-bootstrap by issuing "make" a
Richard Kenner wrote:
Then it seems to me that you are just relying on a peculiarity of the
Ada build system, that is the fact that you can work entirely from
within the GCC directory.
That's by design, of course.
Though it makes me wonder why people did not replicate the design for
> But you cannot compile *any* Ada program (even
an empty function) without an RTS in the path since it makes builtin
references to the RTS.
For what it's worth, that's the same for Java. But the compiler is not
written in Java so you can "bootstrap" it as part of GCC even if you
build libja
Dorit Nuzman wrote:
I am pretty sure that adding -fwrapv will
fix the problem, but that means we are changing the test case.
gen-vect-11.c is Paolo's test, so it's his call I guess
(he already agreed to add -fwrapv -
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00579.html)
Well, gen-ve
Mike Stump wrote:
On Jan 13, 2006, at 5:01 PM, Richard Kenner wrote:
Steven Bosscher wrote:
... you can use --disable-bootstrap and do a regular make, or is there
some reason why you can't do that?
I thought the point was that that option is temporary and will go away.
Over my d
Richard Kenner wrote:
As I said multiple times, *of course* bootstrapping will *never* be
mandatory. On the other hand, GCC-only bootstrapping
(i.e. configuring with disabled bootstrap, and then typing "make
bootstrap") will be deleted.
You've now heard *a lot* of people say that t
Richard Kenner wrote:
I've seen many people saying not wanting something to go away, but
that something is not proposed by Paolo to disappear.
Can you say *exactly* what those two different things are because I'm confused?
Thanks.
MRS and Eric Botcazou objected strongly against not bei
(define_insn ""
[(set (match_operand:CCFP 0 "register_operand" "=z")
(match_operator:SF 1 "signed_comparison_operator"
[(match_operand:SF 2 "register_operand" "f")
(match_operand:SF 3 "register_operand" "f")]))]
""
"%C1f\\t%2,%3"
[(set_attr "type" "fp")
(set_a
On 05/06/2015 17:45, Peter Maydell wrote:
>>> ...but things like "(1U << 31)" are entirely valid.
>>
>> They're only valid until someone does a ~ on them. I think it's
>> reasonable to forbid them in our coding standards, if we want to fix
>> ubsan's warning of (1 << 31).
>>
>> I don't think it'
On 20/11/2015 14:14, David Edelsohn wrote:
> On Fri, Nov 20, 2015 at 7:53 AM, Richard Biener wrote:
>>
>> Status
>> ==
>>
>> We plan to do a GCC 5.3 release candidate at the end of next week
>> followed by the actual release a week after that.
>>
>> So now is the time to look at your regress
On 24/11/2015 16:57, David Edelsohn wrote:
> > > We plan to do a GCC 5.3 release candidate at the end of next week
> > > followed by the actual release a week after that.
> > >
> > > So now is the time to look at your regression bugs in bugzilla and
> > > do some backporting for things already fi
On 05/12/2014 23:47, Jakub Jelinek wrote:
> On Fri, Dec 05, 2014 at 11:34:28PM +0100, Dominique Dhumieres wrote:
>>> As I've tried to explain, that is IMHO wrong though.
>>> If what you are after is the -B stuff too, then perhaps:
>>> ...
>>
>> Sorry but it does not work:
>
> Sorry, make that (j
On 02/24/2011 06:04 PM, Michael Matz wrote:
Funny. As far back as I remember we consistently said that bits of the
same word, but outside the subreg are left with undefined values after
storing into the subreg, except if wrapped with a strict_low_part. In
fact that's the whole point of strict_l
On 03/02/2011 10:00 PM, Ian Lance Taylor wrote:
That does not sound like the right approach to me. Why not add the new
flags to GCC_FOR_TARGET at top-level? It seems to me that
GCC_FOR_TARGET should mean the same thing at all levels.
I agree. Why is it incorrect to use those flags when, say,
201 - 300 of 1079 matches
Mail list logo
