Re: A plan for eliminating cc0
On Mar 23, 2005, Ian Lance Taylor wrote:
> Of course, correctly modeling the effect on the condition codes
> really means putting the information in the RTL so that it is
> exposed to the RTL optimizers.
True, but we want to avoid that because of the loss of optimization
opportunities. Besides, there's really no way in GCC (AFAIK) to have
a pattern such that, if reload selects one alternative, you get a
register set in one way; if you select another, you get it set
differently, or even not set at all, and this is what we'd need to be
able to model the correct effect of instructions as common as mov.
>> >2b) Convert conditional branch instructions from separate
>> >cmpMODE/bCOND instructions to a single conditional branch
>> >instruction, either by saving condition codes in cmpMODE or
>> >tstMODE or by using cbranch.
>> The problem here IIRC is a combinatorial explosion on the number of
>> alternatives for the now-merged compare&branch instructions. Have a
>> look, for example, at the cc0-setting patterns on h8300.md, including
>> the zero-extend and zero-extract ones. There are many of them, with
>> operands that aren't easy to get into a single cbranch instruction.
> I'm not proposing any sort of combinatorial explosion.
Yes, you are. Converting cmpMODE/bCOND to cbranch will involve some
combinatorial explosion in cbranch. We can use computers to handle
this explosion for us, instead of forcing port maintainers to deal
with all the complexity.
> It is not necessary to combine every condition code setting
> instruction with every branch instruction.
Note that I'm not talking about those that set cc as a side effect;
I'm talking only about those whose main purpose is to set the cc.
Even if you limit yourself to those on say h8sx or mn10300, you still
get a very large number of possibilities, because you have to combine
tst/cmp for all available modes, with and without extends or bit
extracts, with condbranch, for all available conditions. Ok, the
problem of all available conditions is easy to overcome, but you still
have the problem of having to duplicate a dozen or so test/cmp
patterns in the patterns that combine them with branches.
The proposal that RTH and I sort of came up with years ago was meant
to overcome this very duplication issue. See below.
>> I think a better approach would be to enable cc0 to be used in
>> patterns, but have some machinery behind the scenes that combines
>> expanders for cc0-setting and cc0-using instructions, creates the
>> post-reload splitters and makes the actual insns conditional on
>> reload_completed. Then one can still model the port in the most
>> natural way, but not overburden the rest of the compiler with cc0
>> support.
> Can you spell that out in more detail, up to the point where somebody
> could start working on it? That description doesn't give me enough to
> go on. How would this machinery be invoked? How would it be
> implemented?
The idea is to get the programs that process .md files such that, when
it reads something like:
;; cc0-setter
(define_insn "cmpsi"
[(set (cc0)
(compare (match_operand:SI 0 "register_operand" "!*d*a*x,dax")
(match_operand:SI 1 "nonmemory_operand" "*0,daxi")))]
""
"@
btst 0,d0
cmp %1,%0"
[(set_attr "cc" "compare,compare")])
;; cc0-user
(define_insn "condbranch"
[(set (pc)
(if_then_else (match_operator 1 "comparison_operator"
[(cc0) (const_int 0)])
(label_ref (match_operand 0 "" ""))
(pc)))]
""
"*
{
if (cc_status.mdep.fpCC)
return \"fb%b1 %0\";
if ((cc_status.flags & CC_OVERFLOW_UNUSABLE) != 0
&& (GET_CODE (operands[1]) == GT
|| GET_CODE (operands[1]) == GE
|| GET_CODE (operands[1]) == LE
|| GET_CODE (operands[1]) == LT))
return 0;
return \"b%b1 %0\";
}"
[(set_attr "cc" "none")])
it interprets it as something like:
(define_insn "cmpsi"
[(set (cc0)
(compare (match_operand:SI 0 "register_operand" "!*d*a*x,dax")
(match_operand:SI 1 "nonmemory_operand" "*0,daxi")))]
"(! before_cc0_collapsing || reload_completed) && "
"@
btst 0,d0
cmp %1,%0"
[(set_attr "cc" "compare,compare")])
(define_insn "condbranch"
[(set (pc)
(if_then_else (match_operator 1 "comparison_operator"
[(cc0) (const_int 0)])
(label_ref (match_operand 0 "" ""))
(pc)))]
"(before_cc0_collapsing || reload_completed) && "
"*
{
if (cc_status.mdep.fpCC)
return \"fb%b1 %0\";
if ((cc_status.flags & CC_OVERFLOW_UNUSABLE) != 0
&& (GET_CODE (operands[1]) == GT
|| GET_CODE (operands[1]) == GE
|| GET_CODE (operands[1]) == LE
|| GET_CODE (operands[1]) == LT))
return 0;
return \"b%b1 %0\";
}"
[(set_attr "cc" "none")])
(define_insn_and_split "cc0_condbranch_cmpsi"
[(seq
gcc-3.3.3 ppc e500 - Abort of uic from Qt
Hello, hopefully, you can give me a hint of what's wrong with my Qt compile issues... (I got no answer in Qt-interest so you are my last chance): I ran into a problem installing Qt on my embedded PowerPC platform (without previous install of Qt). The build was fine, but the installation breaks when it wants to build the qmake_image_collection.cpp: /[..]/qt-x11-free-3.3.4/bin/uic -L /[..]/qt-x11-free-3.3.4/plugins -embed designercore [lots of images/*.png's] -o qmake_image_collection.cpp make: *** [qmake_image_collection.cpp] Aborted make: *** Deleting file `qmake_image_collection.cpp' I was googling for this problem and found that it might be related either to the toolchain or to some library compatibility issues: http://sourceforge.net/mailarchive/forum.php?forum_id=3200&style=flat&viewday=20&viewmonth=200311 (search for uic, mail from Martin Costabel) http://lists.trolltech.com/qt-interest/2004-03/msg00507.html http://lists.trolltech.com/qt-interest/2003-07/thread00564-0.html I've checked uic: $ ldd /[..]/qt-x11-free-3.3.4/bin/uic libqt.so.3 => /[..]/qt-x11-free-3.3.4/lib/libqt.so.3 0x0f71f000) libGLU.so.1 => /usr/X11R6/lib/libGLU.so.1 (0x0f675000) libGL.so.1 => /usr/lib/libGL.so.1 (0x0f5bc000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x0f583000) libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x0f559000) libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x0f535000) libXcursor.so.1 => /usr/X11R6/lib/libXcursor.so.1 (0x0f50a000) libXinerama.so.1 => /usr/X11R6/lib/libXinerama.so.1 (0x0f4e7000) libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0x0f4b4000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x0f41b000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x0f3c2000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x0f39) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x0f29) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x0f266000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x0f22d000) libdl.so.2 => /lib/libdl.so.2 (0x0f20a000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x0f112000) libm.so.6 => /lib/libm.so.6 (0x0f046000) libc.so.6 => /lib/libc.so.6 (0x0eee7000) libpthread.so.0 => /lib/libpthread.so.0 (0x0ee76000) libXxf86vm.so.1 => /usr/X11R6/lib/libXxf86vm.so.1 (0x0ee5) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x0edd2000) libz.so.1 => /usr/lib/libz.so.1 (0x0eda3000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x0ed5f000) /lib/ld.so.1 => /lib/ld.so.1 (0x3000) $ldconfig -p tells me nothing suspicious... everything is in it's place and seems to have the correct version. I am looking for the right way to fix it, so maybe you can help me to point me into the right direction and how to get more debugging output to see what really breaks. More information about my environment: Platform: ppc32 / e500 / Freescale embedded MPC8540 processor. linux 2.6.11 gcc 3.3.3 (from Embedded Linux Development Kit (ELDK3.1, www.denx.de) $ gcc -v Reading specs from /usr/lib/gcc-lib/ppc-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libgcj --build=i386-redhat-linux-gnu --host=ppc-linux --target=ppc-linux --with-newlib --with-gnu-ld --with-gnu-as --enable-languages=c,c++ --enable-multilib=no --enable-nls=yes Thread model: posix gcc version 3.3.3 (DENX ELDK 3.1 3.3.3-10) glibc 2.3.1 binutils 2.14 (now updated to 2.15.96.0 without any effects) X11R6.8.2 libpng-1.2.8 zlib-1.2.2 libXft-2.1.6 freetype-2.1.9 fontconfig-2.3.1 BTW: What are the most current versions for a toolchain which generates working and efficient code for the MPC8540 (ppc32, e500, spe)? Thank you in advance, Clemens Koller ___ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
Re: Questions about trampolines
Hans-Peter Nilsson wrote: On Sun, 13 Mar 2005, Øyvind Harboe wrote: Trampolines are strange things... :-) - AFAICT, the cris target is saving the value of the static chain register in the trampoline. How can that work with recursive functions? What's wrong with that? Do I miss something fundamental? You miss nothing, the whole point of a trampoline is to save the value of the static chain value.
GCC version 3.4.2 and 4 inconsistency on "error: creating array with size zero (`0')"
Call the following snippet `bug.cc':
struct a {
static const int size = 0;
};
template
struct p {
int a[T::size]; // Here it says "error: creating array with size zero (`0')"
};
p n;
template
struct q {
int a[0]; // Here it says nothing!
};
q m;
$ g++ -v
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.2/specs
Configured with: ../gcc-3.4.2/configure --prefix=/usr/local
Thread model: posix
gcc version 3.4.2
$ g++ -c bug.cc
bug.cc: In instantiation of `p':
bug.cc:10: instantiated from here
bug.cc:7: error: creating array with size zero (`0')
$ /opt/beta/bin/g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0/gcc/configure --prefix=/opt/beta
Thread model: posix
gcc version 4.0.0 20050226 (prerelease)
$ /opt/beta/bin/g++ -c bug.cc
bug.cc: In instantiation of 'p':
bug.cc:10: instantiated from here
bug.cc:7: error: creating array with size zero ('0')
Should I report this as a bug?
If so, which kind of bug is it?
All the best,
Roberto
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:[EMAIL PROTECTED]
Re: Conversion from fold (buildN (...)) to fold_buildN.
Kazu Hirata wrote:
Hi,
I would like to announce that fold_buildN are now ready.
Great!
When and how do we want to do these conversion?
Currently, I am thinking about doing converting all of
"fold (buildN (...))" and "fold (build (...))" to fold_buildN as soon
as stage 2 starts, which is about one month away, so that I won't
annoy people as much. I don't mind people starting to use fold_buildN
on new code or doing conversions on what they maintain, but I don't
think now is the right time to do the wholesale conversion.
I agree.
I think it's fine to change parts of the compiler that don't look like
they will be affected by upcoming merges, like Steven's recent changes
to the C++ front end. But, let's try to avoid making it harder for
people who are merging major changes from branches.
Would you like fold_{unary,binary,ternary} exported?
Let's do that when and if there is something that needs to use them.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Re: GCC version 3.4.2 and 4 inconsistency on "error: creating array with size zero (`0')"
Hi Roberto, > Should I report this as a bug? > If so, which kind of bug is it? Isn't this c++/19989? Paolo.
Re: GCC version 3.4.2 and 4 inconsistency on "error: creating array with size zero (`0')"
Paolo Carlini wrote: >Hi Roberto, > >>Should I report this as a bug? >>If so, which kind of bug is it? >> >Isn't this c++/19989? > I should add that, on top of pt.c:tsubst (where the first error is issued unconditionally, irrespective of -pedantic) there is the following comment: ... Note that we must be relatively non-tolerant of extensions here, in order to preserve conformance; if we allow substitutions that should not be allowed, we may allow argument deductions that should not succeed, and therefore report ambiguous overload situations where there are none. In theory, we could allow the substitution, but indicate that it should have failed, and allow our caller to make sure that the right thing happens, but we don't try to do this yet. So... probably not trivially fixable... Paolo.
Re: GCC version 3.4.2 and 4 inconsistency on "error: creating array with size zero (`0')"
Paolo Carlini wrote: Should I report this as a bug? If so, which kind of bug is it? Isn't this c++/19989? Hi Paolo, yes, I think it is that one. Thanks, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Re: A plan for eliminating cc0
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Mar 23, 2005, Ian Lance Taylor wrote:
>
> > Of course, correctly modeling the effect on the condition codes
> > really means putting the information in the RTL so that it is
> > exposed to the RTL optimizers.
>
> True, but we want to avoid that because of the loss of optimization
> opportunities. Besides, there's really no way in GCC (AFAIK) to have
> a pattern such that, if reload selects one alternative, you get a
> register set in one way; if you select another, you get it set
> differently, or even not set at all, and this is what we'd need to be
> able to model the correct effect of instructions as common as mov.
There is no way to write such a pattern before reload, but that's OK
because there is nothing that the optimizers could do with it anyhow.
The pattern would mean something like "if unpredictable option 1
happens, the condition codes are set this way; if unpredictable option
2 happens, they are set this way." You can correctly represent the
condition code setting after reload easily enough, by splitting the
instruction to show the real effect on the condition code.
> >> >2b) Convert conditional branch instructions from separate
> >> >cmpMODE/bCOND instructions to a single conditional branch
> >> >instruction, either by saving condition codes in cmpMODE or
> >> >tstMODE or by using cbranch.
>
> >> The problem here IIRC is a combinatorial explosion on the number of
> >> alternatives for the now-merged compare&branch instructions. Have a
> >> look, for example, at the cc0-setting patterns on h8300.md, including
> >> the zero-extend and zero-extract ones. There are many of them, with
> >> operands that aren't easy to get into a single cbranch instruction.
>
> > I'm not proposing any sort of combinatorial explosion.
>
> Yes, you are. Converting cmpMODE/bCOND to cbranch will involve some
> combinatorial explosion in cbranch. We can use computers to handle
> this explosion for us, instead of forcing port maintainers to deal
> with all the complexity.
We are clearly somehow talking past each other. There is a pattern
named cmpMODE. There is a pattern named bCOND. Currently gcc emits
one and then the other. I am suggesting that they be combined into a
single pattern named cbranch. The fact that there are many patterns
in h8300.md which set cc0 is not relevant. The only cc0 setter which
matters is cmpMODE.
What you are talking about is something different. You are talking
about combining every cc0 setter with every cc0 user into a single
insn. I agree that that is impractical.
The question is how much optimization we lose if we don't do the full
combinatorial explosion. I'm assuming that we will get most back in
the NOTICE_UPDATE_CC pass. But perhaps I am being to optimistic.
I'll note that h8300.md has 17 insn patterns which set cc0, and that
number could be cut down by several by using mode macros and more
flexible predicates. And in this scheme the tstMODE operations would
disappear--only the cmpMODE ones are useful. And there are 4
conditional branch insn patterns, which could be reduced to 3 by using
code macros. So while doing the full crossbar would be a
combinatorial explosion, it would not be an impossible one.
> The idea is to get the programs that process .md files such that, when
> it reads something like:
>
> ;; cc0-setter
> (define_insn "cmpsi"
> [(set (cc0)
> (compare (match_operand:SI 0 "register_operand" "!*d*a*x,dax")
>(match_operand:SI 1 "nonmemory_operand" "*0,daxi")))]
> ""
> "@
> btst 0,d0
> cmp %1,%0"
> [(set_attr "cc" "compare,compare")])
>
> ;; cc0-user
> (define_insn "condbranch"
> [(set (pc)
> (if_then_else (match_operator 1 "comparison_operator"
> [(cc0) (const_int 0)])
> (label_ref (match_operand 0 "" ""))
> (pc)))]
> ""
> "*
> {
> if (cc_status.mdep.fpCC)
> return \"fb%b1 %0\";
> if ((cc_status.flags & CC_OVERFLOW_UNUSABLE) != 0
> && (GET_CODE (operands[1]) == GT
> || GET_CODE (operands[1]) == GE
> || GET_CODE (operands[1]) == LE
> || GET_CODE (operands[1]) == LT))
> return 0;
> return \"b%b1 %0\";
> }"
> [(set_attr "cc" "none")])
>
>
> it interprets it as something like:
>
> (define_insn "cmpsi"
> [(set (cc0)
> (compare (match_operand:SI 0 "register_operand" "!*d*a*x,dax")
>(match_operand:SI 1 "nonmemory_operand" "*0,daxi")))]
> "(! before_cc0_collapsing || reload_completed) && "
> "@
> btst 0,d0
> cmp %1,%0"
> [(set_attr "cc" "compare,compare")])
>
> (define_insn "condbranch"
> [(set (pc)
> (if_then_else (match_operator 1 "comparison_operator"
> [(cc0) (const_int 0)])
> (label_ref (match_operand 0 "" ""))
> (pc)))]
> "(before_cc0_collapsing || reload_completed) && "
> "*
>
Re: A plan for eliminating cc0
Ian Lance Taylor writes: > Looking at your suggestion makes me realize that my suggestion is too > complicated. It's not necessary to generate the combinatorial > explosion at all. We can always keep cc0 setters and cc0 users in > separate instructions. The key is to keep them from getting > disconnected, and the key to that is to indicate which instructions > clobber the condition codes (i.e., most of them). Sorry, of course that is not true, but I'll still send a description for a new proposal. Ian
Re: A plan for eliminating cc0
OK, here is a different approach toward eliminating cc0, based on a combination of my earlier proposal and what Alex described. I'm looking for comments from anybody. 1) Modify the programs which read the .md file to look for an attribute named clobbercc. If such an attribute exists, then for any instruction pattern which defines clobbercc as "yes" (or "true", or whatever), automatically add "(clobber (reg:CC CC_REG))" to the instruction. 2) Modify the programs which read the .md file to look for instructions which set cc0 and instructions which use cc0. If CC_REG is defined for the backend, then for each such instruction: 2a) Rewrite the instruction to change (cc0) to (reg:CC CC_REG). 2b) Rewrite the condition such that the instruction is only recognized before the cc0 collapse pass and after reload. For each pair of cc0 setting instruction and cc0 using instruction: 2c) Define a new instruction which combines the cc0 set and cc0 use into a single combined instruction which does not refer to cc0 or CC_REG at all. This is done by mechanically replacing (cc0) in the cc0 using instruction with the source of the set of (cc0) in the cc0 setting instruction. (Cases in which cc0 is used more than once, or is not simply set, will most likely require manual intervention; I don't know how many such cases exist). This instruction will only be recognized after (and during) the cc0 collapse pass and before (and during) reload. 2d) Define a splitter for this new instruction, to be run after reload, which splits the combined instruction into the two original instructions. 3) Write a new CC0 collapse pass. This pass is run immediately after RTL expansion. It walks the instruction stream looking for instructions which set and use CC_REG. At this point these instructions will always be adjacent. The pass combines them into the combined instruction defined in step 2c above. 4) For each target which uses cc0: 4a) Define the clobbercc attribute to be "yes" for each insn which changes the condition codes unpredictably. Typically the default would be "yes", and then either clobbercc would be defined to use cond to select instruction for which it should be "no", or those instructions would be marked specifically. 4b) For insn patterns for which some alternatives clobber CC and some do not, split the instruction after reload into one variant which clobbers the CC and one variant which does not. Or just write different patterns which are only recognized after reload. 4c) Define CC_REG as a new register which accept CCmode values, and update the appropriate macros and hooks. At this point we have eliminated cc0 for the target. The .md file still refers to it, but all such references are translated to refer to CC_REG in the code which the compiler sees. After reload, the instructions which use CC_REG are split into instructions which set CC_REG and instruction which use CC_REG. These instructions will be kept as close as they need to be, because most other instructions will clobber CC_REG. The generated code should be correct. However, the generated code will not be as good, because there will be unnecessary comparison instructions. (A note for the uninitiated. We need to combine the instructions which set and use CC_REG into a single instruction which is split after reload because reload has to be able to move values in and out of memory, and compute addresses, between arbitrary pairs of instructions. On cc0 machines, those moves and computations will themselves change the condition codes, and we will wind up testing the wrong conditions in the branch instruction. So reload has to see set-and-use-cc0 as a single instruction.) 5) Write a new optimization pass enabled on targets which define NOTICE_UPDATE_CC. I think this pass would be run just before machine dependent reorg, although perhaps there is a better place for it. Walk through the instructions, calling NOTICE_UPDATE_CC on each one. When we find an instruction which sets CC_REG, check the source of the set with the current CC status, just as final_scan_insn does now. If the current CC status is the same, delete the instruction which sets CC_REG. At this point, the generated code quality should be approximately the same as when the target used cc0. 6) When all targets have been converted, remove all the code in the compiler protected by #ifdef HAVE_cc0. Remove the CC_SETTER and CC_USER register notes. Remove the associated documentation. 7) Profit! I want to stress that that this approach is intended to permit reasonably simple elimination of cc0 for all targets. It does not preclude any particular target from using a different approach. In particular, the main oddity here is clobbercc. Any particular target can
Re: A plan for eliminating cc0
On Thu, Mar 24, 2005 at 11:44:52AM -0500, Ian Lance Taylor wrote: > OK, here is a different approach toward eliminating cc0, based on a > combination of my earlier proposal and what Alex described. I'm > looking for comments from anybody. One potential problem: once the NOTICE_UPDATE_CC pass is done, we can no longer run *any* pass that reorders code, because we're left with [(set (reg 1) (plus (reg 1) (reg 2))) (clobber (reg cc_reg))] [(set (pc) (if_then_else (lt (reg cc_reg) 0) (label 1) (label 2)))] Note that there's no longer any insn that *sets* cc_reg. I think that's a bit dangerous. One solution to this is to convert the new setter to [(set (reg 1) (plus (reg 1) (reg 2))) (set (reg cc_reg) (unspec [(const_int 0)] cc_set))] I don't think it matters what we set cc_reg to, just that *some* set is visible in the instruction stream. This requires that we generate two patterns for clobbercc insns, but that shouldn't be a problem. Otherwise I like the proposal. In particular, I like being able to reuse the existing NOTICE_UPDATE_CC code. r~
Re: A plan for eliminating cc0
Richard Henderson <[EMAIL PROTECTED]> writes: > Note that there's no longer any insn that *sets* cc_reg. I think > that's a bit dangerous. Hmmm, good point. > One solution to this is to convert the new setter to > > [(set (reg 1) (plus (reg 1) (reg 2))) >(set (reg cc_reg) (unspec [(const_int 0)] cc_set))] > > I don't think it matters what we set cc_reg to, just that *some* > set is visible in the instruction stream. > > This requires that we generate two patterns for clobbercc insns, > but that shouldn't be a problem. Makes sense. Ian
Help procob
Hi, only one question please, gcc can compile cobol source? (procobol) thanks very much! bye
Re: A plan for eliminating cc0
Ian Lance Taylor writes: > 3) Write a new CC0 collapse pass. This pass is run immediately > after RTL expansion. It walks the instruction stream looking for > instructions which set and use CC_REG. At this point these > instructions will always be adjacent. The pass combines them into > the combined instruction defined in step 2c above. I'm not understanding why this is a separate pass, instead of generating the combined instructions directly in the expander. I think generic expander support for compare-and-branch instructions already exists... zw
Re: A plan for eliminating cc0
Zack Weinberg <[EMAIL PROTECTED]> writes: > Ian Lance Taylor writes: > > > 3) Write a new CC0 collapse pass. This pass is run immediately > > after RTL expansion. It walks the instruction stream looking for > > instructions which set and use CC_REG. At this point these > > instructions will always be adjacent. The pass combines them into > > the combined instruction defined in step 2c above. > > I'm not understanding why this is a separate pass, instead of > generating the combined instructions directly in the expander. I > think generic expander support for compare-and-branch instructions > already exists... We have to worry not just about compare-and-branch, but also about test-and-branch, compare-and-set, compare-and-move, and compare-and-add. Basically, look for the various calls to emit_cmp_insn. We could modify the expander to try combined instructions in all those cases. Or we could modify the cc0 backends to save the comparison operands in cmpMODE and use them in the various conditional instructions (that was my original proposal). Overall it seems simpler to use a separate pass. I'm not wedded to it, though. Ian
GCC 4.0 Status Report (2005-03-24)
[If you're in the explicit CC: list for this mail, I've mentioned you explicitly below, and I'm hoping that you'll be able to provide me some feedback.] I've looked through the 36 critical (i.e., wrong-code, ice-on-valid, or rejects-valid) regressions open against 4.0. They are categorized below into several sections: * Truly Critical These are ones that I think are definite showstoppers, including problems building Qt, GLIBC, and the AIX port. * Less Critial These are problems that seem less vitally important, while still significant. * Need Review These are PRs (also included in the lists above in some cases) which have patches posted, and need review. * Already Fixed These are PRs that have been approved for 4.0, but aren't applied yet. I'm still shooting for an April 15th release. As I indicated previously, please do not mark any new non-critical regressions with the 4.0 target milestone; use 4.0.1 instead. There are about 70 non-critical regressions; it would of course be good to fix these, but realistically we're not going to get them all. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] Truly Critical -- 19225 Segmentation fault with VLAs, affects GLIBC This is the TYPE_STUB_DECL that Dan Berlin looked into for a while. What is the current status? 19317 C++ problems with temporary return values This patch breaks Qt builds. One of my patches is implicated, but I believe that the consensus is that this is an NRV bug. Jason made several attempts at fixing this. Does anyone know what the current status is? 19199 Wrong code using ?: operator in C++ This is the bug Alexandre, Roger, and I had a long discussion about on the mailing lists. I'm not sure we ever came to a good conclusion. In the 4.0 time frame, I can think of two viable solutions: 1. Disable the (problematic) transformation of ?: into MIN_EXPR/MAX_EXPR, at least for C++. That's what Alexandre's latest patch in the PR purports to do. 2. Extend the logic handling MIN_EXPR/MAX_EXPR as lvalues throughout the C++ front end. Roger, is Alexandre's patch OK? 20126 Wrong memcmp code on AMD64 Alexandre posted a patch. Review? 20290 Wrong code on PPC/ARM with -Os Alexandre posted a patch. Review? 19159 Undefined vtable symbols on AIX I'll be working on another attempt at fixing the bug. Less Critical - 17855 ICE on C code that modifies call return values RTH and Joseph looked at this; no fix yet. 20342 ICE in reload w/ SSE/MMX RTH, is this related to your vector changes? 20491 ICE on inline asm Alexandre's posted a patch. 20103 C++ problem with compound literals Poor Alexandre has really been trying hard to fix this one. I should review the C++ bits of his latest change. 17053 -frepo broken on AIX I broke it. David volunteered to fix it for me, but he might have decided he'd rather I work on it? 20263 SPARC64 ASM bug Eric has a patch; I've asked about possible other ways to fix it. 18644 -Wysnth warning on This is only really critical, in that it breaks code for people using -Werror. 19406 C++ ICE with -gdwarf2 PR unclear: Jakub produced a patch, which is on a Red Hat branch, but what is the current status? 19312 C++ ICE in stabilize_call This is a 3.4 regression; it's assigned to Jason. Any updates? 20225 ICE during GC Patch checked in -- but the issue has not yet been marked fixed. Why not? 20505 Crash with -ggdb2 on C++ initializers The compiler is no longer simplifying certain address expressions to constants, and is therefore crashing in the debug generators. 20519 ICE-on-valid for typeof Joseph and RTH have analyzed the problem. Who's going to fix it? 18604 Rejects-valid for C++ due to "strong using". Jason was asked about this bug in November. Jason, any word? 19203 C++ templates/overloading issue Nathan is looking into the validity of this one. 13300 Wrong assumptions in loop It's unclear whether we still have any known manifestations of this bug in 4.0. 14711 ICE on programs with very large line numbers I cannot presently reproduce the bug. 17913 ICE on jumping into statement expression. I asked Joseph if we can declare this invalid code, for 4.0. 19255 EH bug on IA32 when using heavy optimization We don't know what the design is supposed to be more this case; I've asked RTH for feedback. 19475 CPP conformance issue with "#define a!" May be an easy fix; cpplib maintainers? 20076 inlining bug with __builtin_return, __builtin_apply No status. 20442 Problem with setjmp/longjmp mixed with EH on sjlj platforms I've asked RTH about this. 20524 Problem with new .alias stuff on ARM, et. al. RTH is presumably on the case. Need review --- 19199 Wrong code using ?: operator in C++ 20249 ICE w/ -fprofile-arcs on PPC 20203 ICE on PowerPC 19108 ICE initializing arrays in C++ 20126 Wrong memcmp code on
Re: Help procob
On Mar 24, 2005, at 10:32 AM, Galli Andrea wrote: only one question please, gcc can compile cobol source? (procobol) You know, there is this thing called google. It is wonderful, you can type http://www.google.com into your favorite web browser, and the type GNU cobol and then return, and it will tell you all sorts of neat things. It will usually provide a more complete and expansive answer in about 0.025 seconds, slightly faster than we are able to reply.
building GCC 4.0 for arm-elf target on mingw host
Hi, I've been attempting to build the gcc-4.0 20050319 snapshot under mingw/msys for arm-elf target with a few problems. the mingw32 gcc is 3.4.2 Configuring seems to work fine. ../../$GCC_SRCDIR/configure \ --enable-languages=c,c++ \ --enable-interwork --enable-multilib\ --with-gcc --with-gnu-ld --with-gnu-as --with-stabs \ --disable-shared --disable-threads --disable-win32-registry --disable-nls\ --target=arm-elf \ --with-newlib \ --prefix=c:/devkitARM_r12 proceeding with make all-gcc results in a number of weird errors configuring in subdirectories Configuring in intl make[1]: Entering directory `/c/projects/devkitPro/sources/arm-elf/gcc/intl' make[1]: *** No rule to make target `all'. Stop. make[1]: Leaving directory `/c/projects/devkitPro/sources/arm-elf/gcc/intl' make: *** [all-intl] Error 2 The build process doesn't stop but carries on with configuring (in some cases displaying the command prompt as if the build had stopped). Removing the files from the subdirectory in the build directory & restarting make all-gcc allows me to continue but results in the same error in a number of subdirectories. After 3 or 4 restarts it finally appears to proceed normally until building libgcc make[3]: Leaving directory `/c/projects/devkitPro/sources/arm-elf/gcc/gcc' /c/projects/devkitPro/sources/arm-elf/gcc/gcc/xgcc -B/c/projects/devkitPro/sources/arm-elf/gcc/gcc/ -Bc:/devkitARM_r12/arm-elf/bin/ -Bc:/devkitARM_r12/arm-elf/lib/ -isystem c:/devkitARM_r12/arm-elf/include -isystem c:/devkitARM_r12/arm-elf/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -Dinhibit_libc -fno-inline -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I -I../../../gcc-4.0-20050319-new/gcc -I../../../gcc-4.0-20050319-new/gcc/ -I../../../gcc-4.0-20050319-new/gcc/../include -I../../../gcc-4.0-20050319-new/gcc/../libcpp/include -DL_muldi3 -c ../../../gcc-4.0-20050319-new/gcc/libgcc2.c -o libgcc/./_muldi3.o In file included from ../../../gcc-4.0-20050319-new/gcc/libgcc2.c:43: ./tm.h:5:28: error: config/dbxelf.h: No such file or directory ./tm.h:6:27: error: config/elfos.h: No such file or directory ./tm.h:7:37: error: config/arm/unknown-elf.h: No such file or directory ./tm.h:8:29: error: config/arm/elf.h: No such file or directory ./tm.h:9:30: error: config/arm/aout.h: No such file or directory ./tm.h:10:29: error: config/arm/arm.h: No such file or directory ./tm.h:11:23: error: defaults.h: No such file or directory In file included from ../../../gcc-4.0-20050319-new/gcc/libgcc2.c:56: ../../../gcc-4.0-20050319-new/gcc/libgcc2.h:230:3: error: #error "expand the table" ../../../gcc-4.0-20050319-new/gcc/libgcc2.c: In function '__mulhi3': ../../../gcc-4.0-20050319-new/gcc/libgcc2.c:527: error: 'BITS_PER_UNIT' undeclared (first use in this function) ../../../gcc-4.0-20050319-new/gcc/libgcc2.c:527: error: (Each undeclared identifier is reported only once ../../../gcc-4.0-20050319-new/gcc/libgcc2.c:527: error: for each function it appears in.) make[2]: *** [libgcc/./_muldi3.o] Error 1 make[2]: Leaving directory `/c/projects/devkitPro/sources/arm-elf/gcc/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/c/projects/devkitPro/sources/arm-elf/gcc/gcc' make: *** [all-gcc] Error 2 copying the compile line and removing the spurious -I and the -I../../../gcc-4.0-20050319-new/gcc/ results in no errors. I'm having a little trouble finding where this line is built up in the makefiles, can anyone point me in the right direction to solve this problem? Dave
Re: GCC 4.0 Status Report (2005-03-24)
> Truly Critical > -- > > 19225 Segmentation fault with VLAs, affects GLIBC > > This is the TYPE_STUB_DECL that Dan Berlin looked into for a while. > What is the current status? I think you mean 19345. Anyway, the long and short of it is that the real bug here is that TYPE_NAME (TYPE_MAIN_VARIANT (origin)) is NULL, and it shouldn't be. Or at least, that is what jason says.
Re: RFA: PR 19225
Dale Johannesen wrote: I'm interested in fixing this, but could use some help from somebody knowledgeable about how x86 EH is supposed to work. In particular, what's the expected relationship between SP at the point of a throwing call, and when it gets back to the landing pad? There is no direct relationship between the two SP values. If they are different, then there should be unwind info indicating the difference, and the unwinder should be applying those differences while unwinding. There is a statement to this effect in comment #3 from Andrew. However, looking at this, I am tempted to call it a bug in the defer pop optimization. The testcase works with -fno-defer-pop. This is something we only do for old and/or embedded targets that push/pop function arguments, so it wouldn't be noticable on most any system that a gcc developer would be using. It is probably much easier to fix the defer pop optimization than to fix the unwinder to handle this. An unwinder fix would allow us to keep this optimization though. Perhaps adding something to expand_calls like /* ??? Defer pop and unwinding don't work well together. */ if (flag_exceptions && ! (flags & ECF_NOTHROW)) NO_DEFER_POP; along with a corresponding OK_DEFER_POP later. Actually, looking at this, I am surprised how may NO_DEFER_POP calls we have without corresponding OK_DEFER_POP calls. I wonder if this optimization is already broken, in the sense that is it being accidentally disabled when it shouldn't be. Or maybe the code is just more obtuse than it needs to be. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: inefficient code output?
Stefan Strasser wrote: movl %ebx, -200(%ebp) movl %ebx, -196(%ebp) movl %eax, 4(%esp) movl -200(%ebp), %edx movl -196(%ebp), %ecx It is hard to say without a testcase, but my first guess would be reload inheritance and/or the post-reload cse pass. Reload may need to load/store something from a stack slot to satisfy a reload. If we have two instructions in a row that need the same reload, then reload inheritance will try to reuse the value. This may avoid loading it twice and/or storing then reloading a value. If reload inheritance is successful, it then tries to delete the now unnecessary load/store, but this is a complicated operation, and doesn't always succeed. So sometimes we end up with unnecessary loads/stores for partially deleted reloads. A similar thing might happen if post-reload cse succeeds in simplifying some code, but doesn't succeed in deleting the now unnecessary stack load/store. Deleting a stack slot store is difficult, as it requires memory alias analysis that probably isn't being done in reload and the post-reload cse passes. It is better to avoid creating them in the first place, which is why we have reload inheritance, and why reload is so complicated. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: A plan for eliminating cc0
Ian Lance Taylor writes: > Zack Weinberg <[EMAIL PROTECTED]> writes: >> I'm not understanding why this is a separate pass, instead of >> generating the combined instructions directly in the expander. I >> think generic expander support for compare-and-branch instructions >> already exists... > > We have to worry not just about compare-and-branch, but also about > test-and-branch, compare-and-set, compare-and-move, and > compare-and-add. Basically, look for the various calls to > emit_cmp_insn. We could modify the expander to try combined > instructions in all those cases. Or we could modify the cc0 > backends to save the comparison operands in cmpMODE and use them in > the various conditional instructions (that was my original > proposal). Overall it seems simpler to use a separate pass. I'm > not wedded to it, though. I kinda like the idea of having the cc0 backends save the comparison operands. That is, after all, what most of the non-cc0 backends do. It is not the way that I think things *should* work, but it does reduce the number of ways that things are done. (Long term, I *would* like to see named optabs for all of the above as fused operations, ideally as the only way the expander works.) zw
Re: RFA: PR 19225
On Mar 24, 2005, at 12:35 PM, James E Wilson wrote: Dale Johannesen wrote: I'm interested in fixing this, but could use some help from somebody knowledgeable about how x86 EH is supposed to work. In particular, what's the expected relationship between SP at the point of a throwing call, and when it gets back to the landing pad? There is no direct relationship between the two SP values. If they are different, then there should be unwind info indicating the difference, and the unwinder should be applying those differences while unwinding. There is a statement to this effect in comment #3 from Andrew. Actually I wrote that comment. While I see that it could be done that way in the unwinder, I found no code that was actually trying to do it. So I was unclear about the intent. However, looking at this, I am tempted to call it a bug in the defer pop optimization. ...It is probably much easier to fix the defer pop optimization than to fix the unwinder to handle this. I had tentatively reached this conclusion also, more slowly I'm sure. Actually, looking at this, I am surprised how may NO_DEFER_POP calls we have without corresponding OK_DEFER_POP calls. I wonder if this optimization is already broken, in the sense that is it being accidentally disabled when it shouldn't be. Or maybe the code is just more obtuse than it needs to be. No, I think you are right, I'll see if I can clean things up without breaking it. Thanks for your comments.
Re: GCC 4.0 Status Report (2005-03-24)
On Thu, Mar 24, 2005 at 11:29:09AM -0800, Mark Mitchell wrote: > 17855 ICE on C code that modifies call return values > > RTH and Joseph looked at this; no fix yet. I'm not sure why this is marked as ice-on-valid; the construct in question has undefined behaviour. > 20342 ICE in reload w/ SSE/MMX > > RTH, is this related to your vector changes? Not sure; havn't looked at it yet. > 20519 ICE-on-valid for typeof > > Joseph and RTH have analyzed the problem. Who's going to fix it? I've been working on this one. I think the C++ front end has a similar problem. I've been iterating toward a common solution; I don't think it'll take too much longer. > 19255 EH bug on IA32 when using heavy optimization > > We don't know what the design is supposed to be more this case; I've > asked RTH for feedback. Typo in pr number? > 20442 Problem with setjmp/longjmp mixed with EH on sjlj platforms > > I've asked RTH about this. I'll have to build a toolchain and debug it. Nothing leaps out at me as to what may be wrong. > 20524 Problem with new .alias stuff on ARM, et. al. > > RTH is presumably on the case. Next on the list. r~
Re: GCC 4.0 Status Report (2005-03-24)
On Thu, 24 Mar 2005, Richard Henderson wrote: > On Thu, Mar 24, 2005 at 11:29:09AM -0800, Mark Mitchell wrote: > > 17855 ICE on C code that modifies call return values > > > > RTH and Joseph looked at this; no fix yet. > > I'm not sure why this is marked as ice-on-valid; the construct in > question has undefined behaviour. Undefined behavior on execution, not on translation. Undefined behavior only if bar is called and the call to f from bar returns. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: GCC 4.0 Status Report (2005-03-24)
On Thu, Mar 24, 2005 at 09:27:37PM +, Joseph S. Myers wrote: > Undefined behavior on execution, not on translation. It's still a stretch on the word "valid". r~
Re: GCC3 to GCC4 performance regression. Bug?
Steve Ellcey wrote: Any optimization experts care to take a look at this test case and help me understand what is going on and if this change from 3.4 to 4.0 is intentional or not? Use the -da -fdump-tree-all options, and start looking at the dumps. The first thing I notice is that in the RTL .loop dump file, gcc-3.4 does interesting stuff, like loop invariant code motion and the do-loop optimization. However, gcc-4 reports only Loop at 81 ignored due to multiple entry points. Loop at 83 ignored due to multiple entry points. This seems to be sufficient to explain the slow down, as the gcc-3.4 RTL loop pass moves some loads out of the inner loop, and adds a special looping branch instruction. And none of this happens in mainline. So the problem seems to be that tree-ssa optimizations have confused the loop structure to the point that the RTL loop pass doesn't work anymore. That is a serious problem. I'm guessing, but I think the problem is that we have (note 81 22 83 NOTE_INSN_LOOP_BEG) (note 83 81 23 NOTE_INSN_LOOP_BEG) (code_label 23 83 24 2 13 "" [2 uses]) i.e. two loops are using the same code label. This is a problem, as now we have no place to put loop invariant instructions for either loop. We used to have code to ensure that each loop had its own code label. tree-ssa could perhaps be modified to preserve that property, but probably a better solution is to make loop.c smart enough to detect this case and fix it itself by splitting the code label into two. I'd suggest filing a bug report for this problem to make sure it gets fixed. As for why the testcase works when you delete the M field, in this case tree-ssa does the loop invariant code motion itself. We still don't get any RTL loop optimization, but now all we are missing is the br.cloop instruction, and that causes only a small performance loss. tree-ssa isn't in my purview, so I won't try to guess what might be wrong here. I'll only point out that the difference occurs in the lim (loop invariant motion) pass, which makes sense. This might be worth a second bug report. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: GCC 4.0 Status Report (2005-03-24)
Richard Henderson wrote: 19255 EH bug on IA32 when using heavy optimization Typo in pr number? I think that is supposed to be 19225, for which I have already suggested a solution though not a patch (disable deferred argument popping when a call can throw). It isn't marked critical though, so I don't know why it is on the list, unless perhaps Mark just changed the status to be not critical. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: GCC 4.0 Status Report (2005-03-24)
On Mar 24, 2005, at 3:08 PM, James E Wilson wrote: Richard Henderson wrote: 19255 EH bug on IA32 when using heavy optimization Typo in pr number? I think that is supposed to be 19225, for which I have already suggested a solution though not a patch (disable deferred argument popping when a call can throw). It isn't marked critical though, so I don't know why it is on the list, unless perhaps Mark just changed the status to be not critical. I'm testing a fix for this. Will assign to myself.
Re: What does --enable-altivec do?
Michael LeBlanc wrote: Does that option do anything except supply -maltivec implicitly? As explained in the install docs, it does two things, enables -maltivec by default, and enables -mabi=altivec by default. This option has been deprecated and removed in the upcoming gcc-4.0 release. The preferred solution is to configure for an altivec target instead, e.g. powerpc-linux-gnualtivec. I see we still have the install docs for --enable-altivec. I will remove them. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: GCC 4.0 Status Report (2005-03-24)
Richard Henderson wrote: On Thu, Mar 24, 2005 at 09:27:37PM +, Joseph S. Myers wrote: Undefined behavior on execution, not on translation. It's still a stretch on the word "valid". It's probably reasonable to say that this is not absolutely a showstopper, as well-written code presumably won't contain this kind of construct. I suppose one approach would be to decree the C front end broken, and require that it replace the problematic constructs with "abort()", as Joseph mentioned as a possibility. I don't know how tractable that is, but you and Joseph are the C front end maintainers, so you probably do. :-) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC3 to GCC4 performance regression. Bug?
On Thursday 24 March 2005 23:28, James E Wilson wrote: > I'd suggest filing a bug report for this problem to make sure it gets > fixed. I'd suggest trying -fmove-loop-invariants, and report a bug about that instead if it does not move those loop invariants. We really should move away from loop.c anyway. Gr. Steven
Re: GCC3 to GCC4 performance regression. Bug?
On Thu, 2005-03-24 at 15:52, Steven Bosscher wrote: > I'd suggest trying -fmove-loop-invariants, and report a bug about > that instead if it does not move those loop invariants. We really > should move away from loop.c anyway. In general, yes, but we will probably always need some RTL loop optimizations. Lowering gimple to RTL may expose target dependent loop invariants that were not present in the gimple. Hence, we still need the RTL loop pass to work. There is also the issue of the special looping branches, which is a low level target dependent issue that is probably better handled in RTL than gimple. The -fmove-loop-invariants option can't fix this problem, and this results in a few percentage points of performance loss for this testcase. We need the RTL loop pass for this. There is also the more pragmatic problem that we are suffering user visible performance losses right now, and we shouldn't force users to wait for future tree-ssa enhancements to fix them when an apparently relatively simple RTL optimizer change can fix them. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: GCC3 to GCC4 performance regression. Bug?
On Mar 24, 2005, at 7:31 PM, James E Wilson wrote: On Thu, 2005-03-24 at 15:52, Steven Bosscher wrote: I'd suggest trying -fmove-loop-invariants, and report a bug about that instead if it does not move those loop invariants. We really should move away from loop.c anyway. In general, yes, but we will probably always need some RTL loop optimizations. Lowering gimple to RTL may expose target dependent loop invariants that were not present in the gimple. Hence, we still need the RTL loop pass to work. Jim you know that -fmove-loop-invariants enables the "new" RTL BB based loop optimizer? This option was added back in 3.4.0. -- Pinski
Re: GCC3 to GCC4 performance regression. Bug?
On Thu, 2005-03-24 at 16:39, Andrew Pinski wrote: > Jim you know that -fmove-loop-invariants enables the "new" RTL BB based > loop optimizer? This option was added back in 3.4.0. No, I don't, and I stupidly didn't bother to check. I thought he was talking about some tree-ssa option. I tried it, it doesn't help. It solves neither the loop invariant code motion problem nor the do-loop optimization problem. If we are going to be moving to the new RTL loop optimizer soon then fixing it only there would be acceptable. Otherwise, it probably would be good to fix it in the old RTL loop optimizer too. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: GCC3 to GCC4 performance regression. Bug?
On Mar 24, 2005, at 8:09 PM, James E Wilson wrote: I tried it, it doesn't help. It solves neither the loop invariant code motion problem nor the do-loop optimization problem. The do-loop optimization which 3.3/3.4 was doing was invalid (see the bug referenced below). I filed it under PR 19210 and was told we should suspended it as there was no way to tell if the loop was finite. -- Pinski
getopt.h getopt() decl broken for many targets
Targets, such as Windows, that don't have getopt() will probably have get the following error when compiling binutils. gcc -DHAVE_CONFIG_H -I. -I/aaronwl/cs/compilers/binutils/src/cvs/src/binutils -I. -D_GNU_SOURCE -I. -I/aaronwl/cs/compilers/binutils/src/cvs/src/binutils -I../bfd -I/aaronwl/cs/compilers/binutils/src/cvs/src/binutils/../bfd -I/aaronwl/cs/compilers/binutils/src/cvs/src/binutils/../include -D__USE_MINGW_FSEEK -I/aaronwl/cs/compilers/binutils/src/cvs/src/binutils/../intl -I../intl -DLOCALEDIR="\"/aaronwl/cs/env/mingw-head/20040323/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2 -c /aaronwl/cs/compilers/binutils/src/cvs/src/binutils/strings.c In file included from /aaronwl/cs/compilers/binutils/src/cvs/src/binutils/strings.c:65: /aaronwl/cs/compilers/binutils/src/cvs/src/binutils/../include/getopt.h:116: warning: function declaration isn't a prototype make[4]: *** [strings.o] Error 1 This is due to this code: #if !HAVE_DECL_GETOPT #if defined (__GNU_LIBRARY__) || defined (HAVE_DECL_GETOPT) /* Many other libraries have conflicting prototypes for getopt, with differences in the consts, in unistd.h. To avoid compilation errors, only prototype getopt for the GNU C library. */ extern int getopt (int argc, char *const *argv, const char *shortopts); #else #ifndef __cplusplus extern int getopt (); #endif /* __cplusplus */ #endif #endif /* !HAVE_DECL_GETOPT */ Is the situation described in this comment still true? Would it be possible to turn this whitelist into a blacklist?
Re: GCC 4.0 Status Report (2005-03-24)
Daniel Berlin wrote: Truly Critical -- 19225 Segmentation fault with VLAs, affects GLIBC This is the TYPE_STUB_DECL that Dan Berlin looked into for a while. What is the current status? I think you mean 19345. Anyway, the long and short of it is that the real bug here is that TYPE_NAME (TYPE_MAIN_VARIANT (origin)) is NULL, and it shouldn't be. Or at least, that is what jason says. Thanks, I've updated the PR to reflect that. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
BOOT_CFLAGS and -fomit-frame-pointer
Hi There are occasions, especially when bootstrapping a whole new World where one needs to build GCC multiple times, that you don't want to be bootstrapping GCC on every invocation, only the first. On x86 with GCC-4 and above, `make bootstrap' results in the compiler being built with `BOOT_CFLAGS = -O2 -g -fomit-frame-pointer' (picked up from config/mh-x86omitfp). However, if performing a non-bootstrap build ie: built with a plain old `make', BOOT_CFLAGS have no effect and the compiler gets built without `-fomit-frame-pointer'. This means you get a different compiler depending on whether you `make bootstrap'ed it or not, which just seems wrong to me. This never used to be the case. Of course, the problem can easily be worked around once you know what's going on.. but that's not the point. Thanks for any comments. Regards Greg
Re: GCC 4.0 Status Report (2005-03-24)
> 20263 SPARC64 ASM bug > > Eric has a patch; I've asked about possible other ways to fix it. I've answered, but probably not very constructively as your remark was not crystal-clear either. :-) Btw, I think you should "Add CC" you when you comment on specific PRs in order to speed up the discussion. Note that the patch has been approved by Roger for 4.x, so it should already have been checked in, had I not run into technical contingencies lately. However the same problem is present in 3.4.x for the C++ compiler (but is not a regression there) so I'd like you to make a decision for that branch too. Thanks in advance. -- Eric Botcazou
Re: BOOT_CFLAGS and -fomit-frame-pointer
> This means you get a different compiler depending on whether you `make > bootstrap'ed it or not, which just seems wrong to me. This never used to > be the case. Isn't that always the case in general? With a 'make bootstrap' the compiler is built by itself whereas with a bare 'make' it is built by the installed compiler. So in general the final compilers are not identical. What prevents you from setting CFLAGS="-O2 -fomit-frame-pointer" if you happen to be rebuilding the compiler with an installed version of itself? -- Eric Botcazou
