Re: question on verify_ssa failure due to ccp in dom3 (PR30784)
On 3/24/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote: the problem is that for the case of BIT_FIELD_REF fold_ternary folds only if operand 0 is VECTOR_CST. In our case it's a CONSTRUCTOR. I'm testing the patch below (comments?). This patch looks correct, by the way this was caused by my patch to make constant vector constructors invariant. Thanks, Andrew Pinski
Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Robert Dewar wrote:
Ian Lance Taylor wrote:
The new option -fstrict-overflow tells gcc that it can assume the
strict signed overflow semantics prescribed by the language standard.
This option is enabled by default at -O2 and higher. Using
-fno-strict-overflow will tell gcc that it can not assume that signed
overflow is undefined behaviour. The general effect of using this
option will be that signed overflow will become implementation
defined. This will disable a number of generally harmless
optimizations, but will not have the same effect as -fwrapv.
Can you share the implementation definition (implementation defined
generally means that the implementation must define what it does).
This seems awfully vague.
I believe that what Ian means here is that the effect of a signed
overflow will be to produce some arbitrary but well-defined result, with
"well-defined" here meaning that the program will behave in a manner
that's consistent with every subsequent access of it in the source code
seeing the same value (until it's redefined, of course). The actual
value that is seen should, however, be considered entirely arbitrary.
This is distinguished from the -fstrict-overflow, which can produce
results that are inconsistent, such as cases where "n" is negative but
the"n>0" path of an "if" statement is taken.
An example of that is "if (m>0) {n=m+1; if (n>0) {...}}". If the
-fstrict-overflow option is specified, then the compiler can act as if
m+1 never overflows, and optimize away the second check even if the
addition is actually implemented with wrap in the case of overflow.
Supply m=0xEFFF to the resulting program, and the "..." gets
executed with a negative n.
All that -fno-strict-overflow does is prevent that sort of optimization;
it doesn't make any guarantees whatsoever about what value n will
actually have in the resulting code, just that program is guaranteed to
act as if the "n>0" and the "..." both see the same value.
- Brooks
We're out of tree codes; now what?
> One advantage of most computer languages (with the arguable exception of > C, but even it has preprocessor macros) is that they provide high-level > constructs that make it easier to write programs. Constructors and destructors are quite simple functions which are executed at particular time. You could code constructs and destructs in C if you would like to do it. Have you seen symbian's two-pass constructs ? You may think that yes, constructs are the essence of programming, but in fact they are not. More important is 1. clear, self-descriptive terminology 2. testing 3. dependency tracking (which source depends on which) 1 allows more fluent communication between programmers (and not only programmers) 2 allows to make programs which actually work. 3 improves reusability. (Which is currently does not exist in block box form - most of code is copy pasted from one place to another - white box reuse.) > I believe that many > of these high-level constructs are reduced to more verbose lower-level > constructs in some of the language front ends (I know that this is true > in Fortran; I'm not as sure about other front ends), which means that > programming in Generic will require programming at a much lower level. How to present a program in visual form so it would be easy to understand and edit is another question. I have seen programs written in C++ which were not working at all, and I have seen a programs written in pure C - which were properly tested and worked faster than C++ analogues. (And gcc is one of the examples which is written in C) Sometime high level becomes too "high". Just try to read XML standards - they are suffering from overabstraction and not bound to any particular / real problem. > I don't think your expected advantages to editing the compiler's > representation directly will counteract that disadvantage. If I edit assembler code - of course I will not benefit from it. But it must not be assembler code - it must be as close for human to understand and as simple to edit/modify as possible. -- Have a nice day! Tarmo. 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news
Freescale 8-bit microcontrollers GCC support (gcc-for-68HC08)
Hello All, I am looking for anyone who is interested to develop GCC compiler support for Freescale (ex-Motorola) 8-bit microcontrollers family (68HC08). Thanks in advance, Vadim
Re: No ifcvt during ce1 pass (fails i386/ssefp-2.c)
On 3/15/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 3/15/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> The testcase is:
>
> double x;
> q()
> {
> x=x<5?5:x;
> }
>
> compile this with -O2 -msse2 -mfpmath=sse, and this testcase should
> compile to maxsd.
This happens because a "fallthrough edge" is meaningless in cfglayout
mode, but ifcvt.c still gives special meaning to the fallthrough edge.
This should not matter, but it does for some reason, and I'm
investigating this right now. I'll try to come up with a fix asap.
This is what my fix will probably look like. I've bootstrapped C only
on x86_64 and I have verified that it restores the CE1 transformation
for your test case. I'll do a full bootstrap with testing over the
weekend. Early comments welcome ;-)
Gr.
Steven
* ifcvt.c (noce_try_store_flag_constants): Don't check
no_new_pseudos here.
(noce_try_store_flag_constants): Don't check no_new_pseudos.
(noce_try_addcc, noce_try_store_flag_mask, noce_try_cmove_arith,
noce_try_cmove_arith, noce_try_minmax, noce_try_abs,
noce_try_sign_mask): Likewise.
(if_convert): Check no_new_pseudos here.
(cond_exec_process_if_block, noce_process_if_block, find_if_block):
Remove prototypes.
(struct noce_if_info): Add then_bb, else_bb, join_bb members.
(noce_get_condition): Handle new then_else_reversed argument.
(noce_init_if_info): Remove, fold into noce_find_if_block.
(noce_process_if_block): Take a struct noce_if_info as the
argument. Don't set up one based on ce_if_info. Update pointer
references accordingly.
(cond_move_process_if_block): Likewise.
(process_if_block): Removed.
(find_if_block): Removed. Move functionality two new functions,
noce_find_if_block and cond_exec_find_if_block.
(noce_find_if_block): New function. Be aware of IF-THEN-JOIN
blocks and the symmetric IF-ELSE-JOIN case.
(cond_exec_find_if_block): Also new function mostly based on old
find_if_block and process_if_block.
(find_if_header): Replace find_if_block call with separately
guarded calls to noce_find_if_block and cond_exec_find_if_block.
(find_cond_trap): Update noce_get_condition call.
(dead_or_predicable): Likewise.
Index: ifcvt.c
===
--- ifcvt.c (revision 123180)
+++ ifcvt.c (working copy)
@@ -96,16 +96,14 @@ static rtx last_active_insn (basic_block
static basic_block block_fallthru (basic_block);
static int cond_exec_process_insns (ce_if_block_t *, rtx, rtx, rtx, rtx, int);
static rtx cond_exec_get_condition (rtx);
-static int cond_exec_process_if_block (ce_if_block_t *, int);
-static rtx noce_get_condition (rtx, rtx *);
+static rtx noce_get_condition (rtx, rtx *, bool);
static int noce_operand_ok (rtx);
-static int noce_process_if_block (ce_if_block_t *);
-static int process_if_block (ce_if_block_t *);
static void merge_if_block (ce_if_block_t *);
static int find_cond_trap (basic_block, edge, edge);
static basic_block find_if_header (basic_block, int);
static int block_jumps_and_fallthru_p (basic_block, basic_block);
-static int find_if_block (ce_if_block_t *);
+static int noce_find_if_block (basic_block, edge, edge, int);
+static int cond_exec_find_if_block (ce_if_block_t *);
static int find_if_case_1 (basic_block, edge, edge);
static int find_if_case_2 (basic_block, edge, edge);
static int find_memory (rtx *, void *);
@@ -598,8 +596,8 @@ cond_exec_process_if_block (ce_if_block_
struct noce_if_info
{
- /* A basic block that ends in a simple conditional jump. */
- basic_block test_bb;
+ /* The basic blocks that make up the IF-THEN-{ELSE-,}JOIN block. */
+ basic_block test_bb, then_bb, else_bb, join_bb;
/* The jump that ends TEST_BB. */
rtx jump;
@@ -938,8 +936,7 @@ noce_try_store_flag_constants (struct no
int normalize, can_reverse;
enum machine_mode mode;
- if (! no_new_pseudos
- && GET_CODE (if_info->a) == CONST_INT
+ if (GET_CODE (if_info->a) == CONST_INT
&& GET_CODE (if_info->b) == CONST_INT)
{
mode = GET_MODE (if_info->x);
@@ -1065,8 +1062,7 @@ noce_try_addcc (struct noce_if_info *if_
rtx target, seq;
int subtract, normalize;
- if (! no_new_pseudos
- && GET_CODE (if_info->a) == PLUS
+ if (GET_CODE (if_info->a) == PLUS
&& rtx_equal_p (XEXP (if_info->a, 0), if_info->b)
&& (reversed_comparison_code (if_info->cond, if_info->jump)
!= UNKNOWN))
@@ -1157,9 +1153,8 @@ noce_try_store_flag_mask (struct noce_if
int reversep;
reversep = 0;
- if (! no_new_pseudos
- && (BRANCH_COST >= 2
- || STORE_FLAG_VALUE == -1)
+ if ((BRANCH_COST >= 2
+ || STORE_FLAG_VALUE == -1)
&& ((if_info->a == const0_rtx
&& rtx_equal_p (if_info->b, if_info->x))
|| ((reversep = (reversed_comparison_code (if_info->cond,
@@ -1314,7 +1309,8 @@ noce_try_cmove_arith (struct noce_if_inf
conditional on their addresses followed by a load. Don't do this
early because it'll screw alias analysis. Note that we've
already che
Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Robert Dewar <[EMAIL PROTECTED]> writes: > Ian Lance Taylor wrote: > > > The new option -fstrict-overflow tells gcc that it can assume the > > strict signed overflow semantics prescribed by the language standard. > > This option is enabled by default at -O2 and higher. Using > > -fno-strict-overflow will tell gcc that it can not assume that signed > > overflow is undefined behaviour. The general effect of using this > > option will be that signed overflow will become implementation > > defined. This will disable a number of generally harmless > > optimizations, but will not have the same effect as -fwrapv. > > Can you share the implementation definition (implementation defined > generally means that the implementation must define what it does). > This seems awfully vague. You're right, I shouldn't have said "implementation defined." What will happen with -fno-strict-overflow is whatever the processor ISA happens to do when a signed arithmetic operation overflows. For ordinary machines it will just wrap. It is intentionally vague. If you need non-vague semantics, you should use -fwrapv. -fno-strict-overflow is intended to provide the vague semantics which C compilers have historically provided, in support of existing code. -fstrict-overflow provides the reasonably precise semantics of the language standard. The options are generally analogous to -fstrict-aliasing and -fno-strict-aliasing. Ian
[patch, fortran] Remove redundant check in error.c
I added this TODO about a year ago, because at that point I wasn't completely sure if this particular check was needed or not. It still looks like a no-op to me -- the only things that affect the "offset" variable are that it's set to zero some dozen lines above the patch region, and of course the two lines of context in the top of the patch -- and so I'm now proposing to remove it. --- 2007-03-23 Brooks Moses <[EMAIL PROTECTED]> * error.c (show_locus): Remove always-false test. --- Tested with "make check-fortran" on i686-pc-linux-gnu. Ok for mainline? - Brooks Index: error.c === --- error.c (revision 123170) +++ error.c (working copy) @@ -233,12 +233,6 @@ if (cmax > terminal_width - 5) offset = cmax - terminal_width + 5; - /* TODO: Is there a good reason for the following apparently-redundant - check, and the similar ones in the single-locus cases below? */ - - if (offset < 0) -offset = 0; - /* Show the line itself, taking care not to print more than what can show up on the terminal. Tabs are converted to spaces, and nonprintable characters are converted to a "\xNN" sequence. */
--disable-multilib broken on x86_64
The following change broke --disable-multilib: 2007-03-23 Michael Meissner <[EMAIL PROTECTED]> H.J. Lu <[EMAIL PROTECTED]> ../src/configure --enable-languages=c --disable-multilib x86_64-linux-gnu /home/tbm/build/gcc-snapshot-20070324/build/./gcc/xgcc -B/home/tbm/build/gcc-snapshot-20070324/build/./gcc/ -B/usr/lib/gcc-snapshot/x86_64-linux-gnu/bin/ -B/usr/lib/gcc-snapshot/x86_64-linux-gnu/lib/ -isystem /usr/lib/gcc-snapshot/x86_64-linux-gnu/include -isystem /usr/lib/gcc-snapshot/x86_64-linux-gnu/sys-include -g -fkeep-inline-functions -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../src/libgcc -I../../../src/libgcc/. -I../../../src/libgcc/../gcc -I../../../src/libgcc/../include -I../../../src/libgcc/../libdecnumber/no -I../../../src/libgcc/../libdecnumber -I../../libdecnumber -o decLibrary.o -MT decLibrary.o -MD -MP -MF decLibrary.dep -c ../../../src/libgcc/../libdecnumber/decLibrary.c ../../../src/libgcc/../libdecnumber/decLibrary.c:32:24: error: decimal128.h: No such file or directory ../../../src/libgcc/../libdecnumber/decLibrary.c:33:23: error: decimal64.h: No such file or directory ../../../src/libgcc/../libdecnumber/decLibrary.c:34:23: error: decimal32.h: No such file or directory ../../../src/libgcc/../libdecnumber/decLibrary.c:36: error: expected declaration specifiers or '...' before 'decimal32' ../../../src/libgcc/../libdecnumber/decLibrary.c:37: error: expected declaration specifiers or '...' before 'decimal64' ../../../src/libgcc/../libdecnumber/decLibrary.c:38: error: expected declaration specifiers or '...' before 'decimal128' ../../../src/libgcc/../libdecnumber/decLibrary.c: In function 'isinfd32': ... -- Martin Michlmayr http://www.cyrius.com/
Re: --disable-multilib broken on x86_64
* Martin Michlmayr <[EMAIL PROTECTED]> [2007-03-24 19:01]: > The following change broke --disable-multilib: Actually, it also fails without that option. -- Martin Michlmayr http://www.cyrius.com/
RE: --disable-multilib broken on x86_64
I know. I will post a patch very soon. H.J. [EMAIL PROTECTED] >-Original Message- >From: Martin Michlmayr [mailto:[EMAIL PROTECTED] >Sent: Saturday, March 24, 2007 12:03 PM >To: Michael Meissner; Lu, Hongjiu >Cc: gcc@gcc.gnu.org >Subject: Re: --disable-multilib broken on x86_64 > >* Martin Michlmayr <[EMAIL PROTECTED]> [2007-03-24 19:01]: >> The following change broke --disable-multilib: > >Actually, it also fails without that option. >-- >Martin Michlmayr >http://www.cyrius.com/
Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Ian Lance Taylor wrote: You're right, I shouldn't have said "implementation defined." What will happen with -fno-strict-overflow is whatever the processor ISA happens to do when a signed arithmetic operation overflows. For ordinary machines it will just wrap. Given that all ordinary machines wrap, is there really enough difference in performance in practice between -fno-strict-overflow and -fwrapv to justify adding this vague and rather dubious (given it is vague) switch. Saying "whatever the processor does" is not enough, since on some processors there are multiple addition instructions (e.g. trapping and non-trapping variants) It is intentionally vague. If you need non-vague semantics, you should use -fwrapv. -fno-strict-overflow is intended to provide the vague semantics which C compilers have historically provided, in support of existing code. Well I find vague semantics intrinsically unappealing!
RE: --disable-multilib broken on x86_64
I can't duplicate the problem. It works fine for me. H.J. [EMAIL PROTECTED] >-Original Message- >From: Martin Michlmayr [mailto:[EMAIL PROTECTED] >Sent: Saturday, March 24, 2007 12:03 PM >To: Michael Meissner; Lu, Hongjiu >Cc: gcc@gcc.gnu.org >Subject: Re: --disable-multilib broken on x86_64 > >* Martin Michlmayr <[EMAIL PROTECTED]> [2007-03-24 19:01]: >> The following change broke --disable-multilib: > >Actually, it also fails without that option. >-- >Martin Michlmayr >http://www.cyrius.com/
Re: --disable-multilib broken on x86_64
* Lu, Hongjiu <[EMAIL PROTECTED]> [2007-03-24 12:27]: > I can't duplicate the problem. It works fine for me. I put the complete log at http://people.debian.org/~tbm/logs/gcc-bootstrap.bz2 in case that helps. -- Martin Michlmayr http://www.cyrius.com/
generated string libraries & -Wformat
Hello,
I mess around with a lot of generated code. That means I do automated
construction of libraries that use literal strings. In order to
reduce address fixups, I often put all the literal strings into one long
string with each piece separated from the others with a NUL byte.
Unfortunately, I am then constrained from using ``-Wformat'' because
it fears I might accidentally be doing something wrong.
I believe the attached patch is sufficient to implement
-Wno-format-contains-nul
(I am bootstrapping GCC and will be testing for a few hours.)
I'd like to hear any complaints about the change before I
spend too much time polishing it. Thank you!
Regards, Bruce
patterned after usage of "format-nonliteral"
Index: c-format.c
===
--- c-format.c (revision 123186)
+++ c-format.c (working copy)
@@ -43,6 +43,7 @@
if (setting != 1)
{
warn_format_nonliteral = setting;
+ warn_format_contains_nul = setting;
warn_format_security = setting;
warn_format_y2k = setting;
}
@@ -1482,7 +1483,7 @@
if (*format_chars == 0)
{
if (format_chars - orig_format_chars != format_length)
- warning (OPT_Wformat, "embedded %<\\0%> in format");
+ warning (OPT_Wformat_contains_nul, "embedded %<\\0%> in format");
if (info->first_arg_num != 0 && params != 0
&& has_operand_number <= 0)
{
Index: c.opt
===
--- c.opt (revision 123186)
+++ c.opt (working copy)
@@ -216,6 +216,10 @@
C ObjC C++ ObjC++ Var(warn_format_nonliteral) Warning
Warn about format strings that are not literals
+Wformat-contains-nul
+C ObjC C++ ObjC++ Var(warn_format_contains_nul)
+Warn about format strings that contain NUL bytes
+
Wformat-security
C ObjC C++ ObjC++ Var(warn_format_security) Warning
Warn about possible security problems with format functions
Index: c-opts.c
===
--- c-opts.c(revision 123186)
+++ c-opts.c(working copy)
@@ -1106,6 +1106,8 @@
"-Wformat-zero-length ignored without -Wformat");
warning (OPT_Wformat_nonliteral,
"-Wformat-nonliteral ignored without -Wformat");
+ warning (OPT_Wformat_contains_nul,
+ "-Wformat-contains-nul ignored without -Wformat");
warning (OPT_Wformat_security,
"-Wformat-security ignored without -Wformat");
}
RE: --disable-multilib broken on x86_64
Do you have any local changes? Does it work on Debian/i686? H.J. [EMAIL PROTECTED] >-Original Message- >From: Martin Michlmayr [mailto:[EMAIL PROTECTED] >Sent: Saturday, March 24, 2007 1:10 PM >To: Lu, Hongjiu >Cc: Michael Meissner; gcc@gcc.gnu.org >Subject: Re: --disable-multilib broken on x86_64 > >* Lu, Hongjiu <[EMAIL PROTECTED]> [2007-03-24 12:27]: >> I can't duplicate the problem. It works fine for me. > >I put the complete log at >http://people.debian.org/~tbm/logs/gcc-bootstrap.bz2 in case that >helps. >-- >Martin Michlmayr >http://www.cyrius.com/
Re: --disable-multilib broken on x86_64
On Sat, Mar 24, 2007 at 12:27:32PM -0700, Lu, Hongjiu wrote: > I can't duplicate the problem. It works fine for me. > > H.J. > [EMAIL PROTECTED] > > >-Original Message- > >From: Martin Michlmayr [mailto:[EMAIL PROTECTED] > >Sent: Saturday, March 24, 2007 12:03 PM > >To: Michael Meissner; Lu, Hongjiu > >Cc: gcc@gcc.gnu.org > >Subject: Re: --disable-multilib broken on x86_64 > > > >* Martin Michlmayr <[EMAIL PROTECTED]> [2007-03-24 19:01]: > >> The following change broke --disable-multilib: > > > >Actually, it also fails without that option. > >-- > >Martin Michlmayr > >http://www.cyrius.com/ Same here. I won't be able to look at it in more detail until I get back to the office on Monday. -- Michael Meissner, AMD 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA [EMAIL PROTECTED]
Re: --disable-multilib broken on x86_64
* Lu, Hongjiu <[EMAIL PROTECTED]> [2007-03-24 13:22]: > Do you have any local changes? Does it work on Debian/i686? I get the failure without any local patches applied. I don't know about i686 but it works on ia64. -- Martin Michlmayr http://www.cyrius.com/
RE: --disable-multilib broken on x86_64
Do you have enable_decimal_float = no in your gcc/Makefile? H.J. [EMAIL PROTECTED] >-Original Message- >From: Martin Michlmayr [mailto:[EMAIL PROTECTED] >Sent: Saturday, March 24, 2007 1:31 PM >To: Lu, Hongjiu >Cc: Michael Meissner; gcc@gcc.gnu.org >Subject: Re: --disable-multilib broken on x86_64 > >* Lu, Hongjiu <[EMAIL PROTECTED]> [2007-03-24 13:22]: >> Do you have any local changes? Does it work on Debian/i686? > >I get the failure without any local patches applied. I don't know >about i686 but it works on ia64. >-- >Martin Michlmayr >http://www.cyrius.com/
Re: --disable-multilib broken on x86_64
* Lu, Hongjiu <[EMAIL PROTECTED]> [2007-03-24 13:22]: > Do you have any local changes? Does it work on Debian/i686? I noticed that my build does: -I../../../src/libgcc/../libdecnumber/no which obviously cannot work. I'm not quite sure why it's "no" though. During configure I see checking for decimal floating point... dpd ./gcc/Makefile:enable_decimal_float = bid ./libdecnumber/Makefile:enable_decimal_float= dpd ./x86_64-linux-gnu/libgcc/Makefile:enable_decimal_float = no ./x86_64-linux-gnu/libgcc/Makefile:DECNUMINC = -I$(srcdir)/../libdecnumber/$(enable_decimal_float) \ So where does enable_decimal_float = no come from? config.* doesn't say anyhing. It checks whether decimal floating point is supported, but there's nothing about enable_decimal_float. -- Martin Michlmayr http://www.cyrius.com/
Re: --disable-multilib broken on x86_64
* Lu, Hongjiu <[EMAIL PROTECTED]> [2007-03-24 14:00]: > Do you have > enable_decimal_float = no > in your gcc/Makefile? No, gcc/Makefile says enable_decimal_float = bid gcc/Makefile:enable_decimal_float = bid libdecnumber/Makefile:enable_decimal_float= dpd x86_64-linux-gnu/libgcc/Makefile:enable_decimal_float = no x86_64-linux-gnu/32/libgcc/Makefile:enable_decimal_float = no -- Martin Michlmayr http://www.cyrius.com/
Re: --disable-multilib broken on x86_64
* Martin Michlmayr <[EMAIL PROTECTED]> [2007-03-24 21:04]: > So where does enable_decimal_float = no come from? config.* doesn't > say anyhing. Sorry, I meant: "config.* in x86_64-linux-gnu/libgcc doesn't..." > It checks whether decimal floating point is supported, but there's > nothing about enable_decimal_float. -- Martin Michlmayr http://www.cyrius.com/
RE: --disable-multilib broken on x86_64
enable_decimal_float should be the same for all Makefiles. I have: [EMAIL PROTECTED] build-x86_64-linux]$ find -name Makefile | xargs egrep "enable_decimal_float[ \t]*=" ./stage1-libdecnumber/Makefile:enable_decimal_float= bid ./x86_64-unknown-linux-gnu/libgcc/Makefile:enable_decimal_float = bid ./x86_64-unknown-linux-gnu/32/libgcc/Makefile:enable_decimal_float = bid ./prev-gcc/Makefile:enable_decimal_float = bid ./gcc/Makefile:enable_decimal_float = bid ./stage1-gcc/Makefile:enable_decimal_float = bid ./prev-libdecnumber/Makefile:enable_decimal_float= bid ./libdecnumber/Makefile:enable_decimal_float= bid ./prev-x86_64-unknown-linux-gnu/libgcc/Makefile:enable_decimal_float = bid ./prev-x86_64-unknown-linux-gnu/32/libgcc/Makefile:enable_decimal_float = bid ./stage1-x86_64-unknown-linux-gnu/libgcc/Makefile:enable_decimal_float = bid ./stage1-x86_64-unknown-linux-gnu/32/libgcc/Makefile:enable_decimal_floa t = bid [EMAIL PROTECTED] build-x86_64-linux]$ You need to find out why yours are different. H.J. [EMAIL PROTECTED] >-Original Message- >From: Martin Michlmayr [mailto:[EMAIL PROTECTED] >Sent: Saturday, March 24, 2007 2:06 PM >To: Lu, Hongjiu >Cc: Michael Meissner; gcc@gcc.gnu.org >Subject: Re: --disable-multilib broken on x86_64 > >* Lu, Hongjiu <[EMAIL PROTECTED]> [2007-03-24 14:00]: >> Do you have >> enable_decimal_float = no >> in your gcc/Makefile? > >No, gcc/Makefile says enable_decimal_float = bid > >gcc/Makefile:enable_decimal_float = bid >libdecnumber/Makefile:enable_decimal_float= dpd >x86_64-linux-gnu/libgcc/Makefile:enable_decimal_float = no >x86_64-linux-gnu/32/libgcc/Makefile:enable_decimal_float = no > >-- >Martin Michlmayr >http://www.cyrius.com/
Re: --disable-multilib broken on x86_64
* Lu, Hongjiu <[EMAIL PROTECTED]> [2007-03-24 14:11]:
> You need to find out why yours are different.
The reason is that I configure for the target x86_64-linux-gnu while
you check for x86_64*-*-linux* (which doesn't match). This means that
- libdecnumber: sets "dpd"
- gcc: sets "bid" (the match works because the canonical target is used)
- libgcc: sets "no"
... and we get a build failure.
This can be fixed by making sure the canonical target is used in
configure.ac so the check for the target will actually work, as below.
OK to commit?
2007-03-24 Martin Michlmayr <[EMAIL PROTECTED]>
configure.ac: Run AC_CANONICAL_{BUILD,HOST,TARGET} so the newly
added checks for decimal floating point work.
Index: libgcc/configure.ac
===
--- libgcc/configure.ac (revision 123187)
+++ libgcc/configure.ac (working copy)
@@ -7,6 +7,11 @@
AC_INIT([GNU C Runtime Library], 1.0,,[libgcc])
AC_CONFIG_SRCDIR([static-object.mk])
+# Determine the host, build, and target systems
+AC_CANONICAL_BUILD
+AC_CANONICAL_HOST
+AC_CANONICAL_TARGET
+
AC_ARG_WITH(target-subdir,
[ --with-target-subdir=SUBDIR Configuring in a subdirectory for target])
AC_ARG_WITH(cross-host,
Index: libdecnumber/configure.ac
===
--- libdecnumber/configure.ac (revision 123187)
+++ libdecnumber/configure.ac (working copy)
@@ -25,6 +25,11 @@
AC_CONFIG_SRCDIR(decNumber.h)
AC_CONFIG_MACRO_DIR(../config)
+# Determine the host, build, and target systems
+AC_CANONICAL_BUILD
+AC_CANONICAL_HOST
+AC_CANONICAL_TARGET
+
# Checks for programs.
AC_PROG_MAKE_SET
AC_PROG_CC
--
Martin Michlmayr
http://www.cyrius.com/
Re: --disable-multilib broken on x86_64
* Martin Michlmayr <[EMAIL PROTECTED]> [2007-03-24 22:25]: > This can be fixed by making sure the canonical target is used in > configure.ac so the check for the target will actually work, as below. > OK to commit? Actually, I should mention that I haven't fully bootstrapped GCC with this change (although it fixes the build failure I saw before). libgcc/configure.ac also uses $target for something else so I'm not sure it's okay to canonicalize it. But at least the patch shows the problem and a possible solution, so maybe you (or someone who understsands the build scripts) can fully test it. -- Martin Michlmayr http://www.cyrius.com/
Re: --disable-multilib broken on x86_64
On Sat, Mar 24, 2007 at 11:04:12PM +, Martin Michlmayr wrote: > * Martin Michlmayr <[EMAIL PROTECTED]> [2007-03-24 22:25]: > > This can be fixed by making sure the canonical target is used in > > configure.ac so the check for the target will actually work, as below. > > OK to commit? > > Actually, I should mention that I haven't fully bootstrapped GCC with > this change (although it fixes the build failure I saw before). > libgcc/configure.ac also uses $target for something else so I'm not > sure it's okay to canonicalize it. But at least the patch shows the > problem and a possible solution, so maybe you (or someone who > understsands the build scripts) can fully test it. libgcc should not use AC_CANONICAL_TARGET; --target doesn't mean anything to a target library. I'm not sure about libdecnumber - it probably shouldn't be sensitive to $target either. -- Daniel Jacobowitz CodeSourcery
Re: We're out of tree codes; now what?
Several alternatives were tried -- the sub-code approach, the 9-bit approach, the 16-bit approach. It might be interesting to try using Cachegrind or Callgrind to better understand why the performance changes occurred. Nick
Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Robert Dewar <[EMAIL PROTECTED]> writes: > > You're right, I shouldn't have said "implementation defined." > > What will happen with -fno-strict-overflow is whatever the processor > > ISA happens to do when a signed arithmetic operation overflows. For > > ordinary machines it will just wrap. > > Given that all ordinary machines wrap, is there really enough > difference in performance in practice between -fno-strict-overflow > and -fwrapv to justify adding this vague and rather dubious (given > it is vague) switch. Saying "whatever the processor does" is not > enough, since on some processors there are multiple addition > instructions (e.g. trapping and non-trapping variants) I believe there is a comprehensible distinction between "compiler will not assume that signed overflow is undefined behaviour" and "compiler will cause all arithmetic to wrap around." In any case, I have no plans to continue working on this. I described my work in considerable detail as I did it and the patches have gone through multiple rounds of review. I would be happy to see your concrete proposal. Ian
Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Ian Lance Taylor wrote: I believe there is a comprehensible distinction between "compiler will not assume that signed overflow is undefined behaviour" and "compiler will cause all arithmetic to wrap around." In any case, I have no plans to continue working on this. I described my work in considerable detail as I did it and the patches have gone through multiple rounds of review. I would be happy to see your concrete proposal. First, I would get some real figures on performance comparing -fstrict-overflow -fno-strict-overflow -fwrapv It is really hard to estimate the value of the second dubious (dubious because ill-defined, it seems to try to create a state of undefined definedness) switch compared to the other two possibilities. Ian
Re: [patch] generated string libraries & -Wformat
This bootstraps in Linux i686 & I can use -Wno-format-contains-nul to
suppress that warning. OK?
Bruce Korb wrote:
> Hello,
>
> I mess around with a lot of generated code. That means I do automated
> construction of libraries that use literal strings. In order to
> reduce address fixups, I often put all the literal strings into one long
> string with each piece separated from the others with a NUL byte.
> Unfortunately, I am then constrained from using ``-Wformat'' because
> it fears I might accidentally be doing something wrong.
>
> I believe the attached patch is sufficient to implement
>-Wno-format-contains-nul
> (I am bootstrapping GCC and will be testing for a few hours.)
>
> I'd like to hear any complaints about the change before I
> spend too much time polishing it. Thank you!
>
> Regards, Bruce
2007-03-24 Bruce Korb <[EMAIL PROTECTED]>
* c-format.c (set_Wformat): set warn_format_contains_nul to -Wformat
setting
(check_format_info_main): changed embedded NUL byte warning to test
for OPT_Wformat_contains_nul
* c.opt: define Wformat-contains-nul
* c-opts.c (c_common_post_options): complain if -Wformat-contains-nul
is set and -Wformat is not set
> Index: c-format.c
> ===
> --- c-format.c (revision 123186)
> +++ c-format.c (working copy)
> @@ -43,6 +43,7 @@
>if (setting != 1)
> {
>warn_format_nonliteral = setting;
> + warn_format_contains_nul = setting;
>warn_format_security = setting;
>warn_format_y2k = setting;
> }
> @@ -1482,7 +1483,7 @@
>if (*format_chars == 0)
> {
> if (format_chars - orig_format_chars != format_length)
> - warning (OPT_Wformat, "embedded %<\\0%> in format");
> + warning (OPT_Wformat_contains_nul, "embedded %<\\0%> in format");
> if (info->first_arg_num != 0 && params != 0
> && has_operand_number <= 0)
> {
> Index: c.opt
> ===
> --- c.opt (revision 123186)
> +++ c.opt (working copy)
> @@ -216,6 +216,10 @@
> C ObjC C++ ObjC++ Var(warn_format_nonliteral) Warning
> Warn about format strings that are not literals
>
> +Wformat-contains-nul
> +C ObjC C++ ObjC++ Var(warn_format_contains_nul)
> +Warn about format strings that contain NUL bytes
> +
> Wformat-security
> C ObjC C++ ObjC++ Var(warn_format_security) Warning
> Warn about possible security problems with format functions
> Index: c-opts.c
> ===
> --- c-opts.c(revision 123186)
> +++ c-opts.c(working copy)
> @@ -1106,6 +1106,8 @@
>"-Wformat-zero-length ignored without -Wformat");
>warning (OPT_Wformat_nonliteral,
>"-Wformat-nonliteral ignored without -Wformat");
> + warning (OPT_Wformat_contains_nul,
> + "-Wformat-contains-nul ignored without -Wformat");
>warning (OPT_Wformat_security,
>"-Wformat-security ignored without -Wformat");
> }
>
RE: Building GCC 4.3.0 on Cygwin...
On 22 March 2007 22:08, Brian Dessent wrote:
> The real problem seems to be that the libgcc is broken:
>
> configure:2121: /home/User/cvsroot/gcc-obj/./prev-gcc/xgcc
> -B/home/User/cvsroot/gcc-obj/./prev-gcc/
> -B/usr/local/i686-pc-cygwin/bin/
> conftest.c >&5
> /home/User/cvsroot/gcc-obj/./prev-gcc/libgcc.a(_ctors.o): In function
> `__sgetc_r':
> /usr/include/stdio.h:414: undefined reference to `_ungetc'
> /usr/include/stdio.h:410: undefined reference to `___srget_r'
> /usr/include/stdio.h:407: undefined reference to `___srget_r'
> collect2: ld returned 1 exit status
>
> It looks like a problem with some function being defined as a macro when
> it shouldn't, or vice versa. You'll need to look into how _ctors.o is
> built to see exactly, since I can't find any reference to _sgetc_r or
> ungetc in any of the libgcc2.{c,h} files. You can try the trick of
> going into the libgcc build directory (you may have to "make restage1"
> to back up one stage), "rm _ctors.o" and then "make CFLAGS="-g -O2
> -save-temps"" (or some variant) and then look at the preprocessed source
> to see what's happening.
This is what's happening:
configure, make all (fails), make stage1-bubble, cd i686-pc-cygwin/libgcc,
rm _ctors.o, make _ctors.o (optional), cd ../.., make all (succeeds).
This is how _ctors.o looks the first time:-
/gnu/gcc/obj2/i686-pc-cygwin/libgcc $ nm bad-one/_ctors.o
b .bss
d .data
N .stab
N .stabstr
t .text
0010 C ___CTOR_LIST__
0010 C ___DTOR_LIST__
t ___sgetc_r
U ___srget_r
U _ungetc
This is how it looks the second time:-
/gnu/gcc/obj2/i686-pc-cygwin/libgcc $ nm good-one/_ctors.o
b .bss
d .data
N .stab
N .stabstr
t .text
0010 C ___CTOR_LIST__
0010 C ___DTOR_LIST__
The source of the problem? From libgcc2.i after rebuilding _ctors.o:
# 1 "/gnu/gcc/gcc/libgcc/../gcc/libgcc2.c"
# 1 "/gnu/gcc/obj/i686-pc-cygwin/libgcc//"
# 1 ""
# 1 ""
# 1 "/gnu/gcc/gcc/libgcc/../gcc/libgcc2.c"
# 32 "/gnu/gcc/gcc/libgcc/../gcc/libgcc2.c"
# 1 "../.././gcc/tconfig.h" 1
[ ... snip ... ]
# 405 "/usr/include/stdio.h" 3 4
static __inline__ int __sgetc_r(struct _reent *__ptr, FILE *__p)
{
int __c = (--(__p)->_r < 0 ? __srget_r(__ptr, __p) : (int)(*(__p)->_p++));
if ((__p->_flags & 0x4000) && (__c == '\r'))
{
int __c2 = (--(__p)->_r < 0 ? __srget_r(__ptr, __p) :
(int)(*(__p)->_p++));
if (__c2 == '\n')
__c = __c2;
else
ungetc(__c2, __p);
}
return __c;
}
# 487 "/usr/include/stdio.h" 3 4
# 91 "/gnu/gcc/gcc/libgcc/../gcc/tsystem.h" 2
Here's the bad build command diffed against the good build command:
--- a0 2007-03-25 00:27:08.556375000 +
+++ a1 2007-03-25 00:27:21.85325 +
@@ -1,5 +1,5 @@
-#bad
+#good
/gnu/gcc/obj2/./gcc/xgcc -B/gnu/gcc/obj2/./gcc/
-B/gnu/install/i686-pc-cygwin/bin/ -B/gnu/install/i686-pc-cygwin/lib/ -isystem
/gnu/install/i686-pc-cygwin/include -isystem
/gnu/install/i686-pc-cygwin/sys-include
--g -fkeep-inline-functions -O2 -I/gnu/gcc/gcc/gcc/../winsup/w32api/include
-O2 -g -O2 -DIN_GCC
+-O2 -g -O2 -O2 -I/gnu/gcc/gcc/gcc/../winsup/w32api/include -O2 -g -O2
-DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -g -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED
--I. -I. -I../.././gcc -I/gnu/gcc/gcc/libgcc -I/gnu/gcc/gcc/libgcc/.
-I/gnu/gcc/gcc/libgcc/../gcc -I/gnu/gcc/gcc/libgcc/../include
-I/gnu/gcc/gcc/libgcc/../libdecnumber -I../../libdecnumber -o _ctors.o -MT
_ctors.o -MD -MP -MF _ctors.dep -DL_ctors -c
/gnu/gcc/gcc/libgcc/../gcc/libgcc2.c
+-I. -I. -I../.././gcc -I/gnu/gcc/gcc/libgcc -I/gnu/gcc/gcc/libgcc/.
-I/gnu/gcc/gcc/libgcc/../gcc -I/gnu/gcc/gcc/libgcc/../include
-I/gnu/gcc/gcc/libgcc/../libdecnumber -I../../libdecnumber -o _ctors.o -MT
_ctors.o -MD -MP -MF _ctors.dep -DL_ctors -c
/gnu/gcc/gcc/libgcc/../gcc/libgcc2.c
The critical difference is the presence or absence of
-fkeep-inline-functions. I think I remember there being some change between
gcc-3.x and gcc-4.x in inline handling and I think that's what's biting us
now; I think this may only arise in stage1 where we're trying to use 3.x to
compile 4.x.
What I dunno yet is why it doesn't just link against -lcygwin and pick up
the definitions of _ungetc and ___srget_r from there...
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: [patch] generated string libraries & -Wformat
On Sat, 24 Mar 2007, Bruce Korb wrote: > This bootstraps in Linux i686 & I can use -Wno-format-contains-nul to > suppress that warning. OK? This is not a complete patch submission, I await one with documentation and testcases (both for the option disabling the diagnostic and for the use of -Wformat-contains-nul being diagnosed just as other such "ignored without" diagnostics are tested in gcc.dg/format/opt-*.c). -- Joseph S. Myers [EMAIL PROTECTED]
Re: SoC Project: Propagating array data dependencies from Tree-SSA to RTL
On 3/23/07, Alexander Monakov <[EMAIL PROTECTED]> wrote: Hello, I would be pleased to see Ayal Zaks as my mentor, because proposed improvement is primarily targeted as modulo scheduling improvement. In case this is not possible, I will seek guidance from Maxim Kuvyrkov. Ayal has not signed up to be a mentor (as of yet). If he doesn't, i'd be happy to mentor you here, since i wrote part of tree-data-ref.c
Re: We're out of tree codes; now what?
On 3/23/07, Marc Espie <[EMAIL PROTECTED]> wrote: In article <[EMAIL PROTECTED]> you write: >On 19 Mar 2007 19:12:35 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: >> similar justifications for yet another small% of slowdown have been >> given routinely for over 5 years now. small% build up; and when they >> build up, they don't not to be convincing ;-) > >But what is the solution? We can complain about performance all we >want (and we all love to do this), but without a plan to fix it we're >just wasting effort. Shall we reject every patch that causes a slow >down? Hold up releases if they are slower than their predecessors? >Stop work on extensions, optimizations, and bug fixes until we get our >compile-time performance back to some predetermined level? Simple sociology. Working on new optimizations = sexy. Trimming down excess weight = unsexy. GCC being vastly a volunteer project, it's much easier to find people who want to work on their pet project, and implement a recent optimization they found in a nice paper (that will gain 0.5% in some awkward case) than to try to track down speed-downs and to reverse them. I'm not sure I buy this. Most of the new algorithm implementations I see are generally replacing something slower with something faster. Examples: GVN-PRE is about 10x faster than SSAPRE in all cases, while doing about 30% better on every testcase that SSAPRE sucked at. The new points-to implementation is about 100x faster than the old one (on smaller cases, it actually gets faster as the size of the problem to be solved grows). New ivopts algorithm replaced old ivopts algorithm for a large speedup Newer propagation algorithm replaced older CCP implementation for a speedup Most of these have not had *any* real effect on the time it takes to run GCC in the common case. Why? Because except for the same edge cases you complain we are spending time speeding up, they aren't a significant amount of time! Most of the time is in building and manipulating trees and RTL. And then disappointment, as the ssa stuff just got added on top of the RTL stuff, and the RTL stuff that was supposed to vanish takes forever to go away... Mainly because people want it to produce *exactly* the same code it used to, instead of being willing to take a small generated code performance hit for a while. Since backend code generation is a moving target with very complex dependencies, this is a hard target to hit. At some point, it's going to be really attractive to start again from scratch, without all the backends/frontend complexities and interactions that make cleaning up stuff harder and harder... This i agree with. I'd much rather stop trying to do everything we can to support more than the top 5 architectures (though i have no problem with all their OS variants). Also, I have the feeling that quite a few of gcc sponsors are in it for the publicity mostly (oh look, we're nice people giving money to gcc), and new optimization passes that get 0.02% out of SPEC are better bang for their money. And some people just like to sit on the sidelines and complain instead of submitting patches to do anything. Kuddoes go to the people who actually manage to reverse some of the excesses of the new passes. Most of these people are the same people who implemented the passes in the first place!
Obtaining FUNCTION_DECL arglist as defined in source
Hi All,
I am writing to find out if there is any method of obtaining or
constructing a function parameter list string as it would have been
defined in the source code?
For example for the function:
int Function(std::string v1, std::string v2) {return F(v1, v2);}
I would like to obtain a string that looks like:
"std::string v1, std::string v2"
OR:
"std::string, std::string"
I am currently doing something like this using DECL_ARGUMENTS(fndecl)
and then for each of the arguments in the list (skipping the "this" arg
for member functions and the occasional in_charge_identifier or
vtt_parm_identifier args) I obtain a string representation of the type
and use this to construct the function parameter string.
Anyhow, there are a number of "special" cases that i need to handle
using this method, such as DECL_ARGUMENTS returning a NULL_TREE or the
... parameter type etc. With all this i still do not quite get the
results i need.
What i find is that often the resulting parameter string is not exactly
or even functionally the same as what is specified in the source code.
For example some functions that receive a std::string parameter by value
are modified by the compiler for optimization reasons to pass the
parameter in by reference instead, and this shows up in the resulting
parameter string i construct.
So for the example before i would sometimes find that the string contains:
"std::string&, std::string&"
What i need to achieve:
BEST OPTION:
I need to get a string exactly the same as defined in the source code.
It is fine for this to include parameter names and default argument
values if that is how it has to be.
SECOND BEST OPTION:
Otherwise i need to at least obtain names for the types as they were
specified. I.e. without the optimizations applied or this parameter
added or typedefs substituted etc.
Is this possible? And if so where is the best place to look?
By the way i am using the source for GCC 4.0.1 in case that makes a
difference.
Thanks,
Brendon.
-fkeep-inline-functions and broken Cygwin bootstrap (was: Building GCC 4.3.0 on Cygwin...)
Dave Korn wrote:
> # 405 "/usr/include/stdio.h" 3 4
[ Which is from newlib (libc/include/stdio.h) if anyone reading this
doesn't have a Cygwin system handy. ]
> static __inline__ int __sgetc_r(struct _reent *__ptr, FILE *__p)
> {
> [...]
>
> The critical difference is the presence or absence of
> -fkeep-inline-functions. I think I remember there being some change between
> gcc-3.x and gcc-4.x in inline handling and I think that's what's biting us
> now; I think this may only arise in stage1 where we're trying to use 3.x to
> compile 4.x.
I too thought that this was related to the c99 inline changes, but I
think those only apply to "extern inline" which is not the case here.
The real cause seems to be that -fkeep-inline-functions was a no-op up
until: , which
seems to roughly correspond to when bootstrap stopped working on Cygwin.
So it looks like we need to either stop using -fkeep-inline-functions
for this file, change the definition to extern inline (or extern inline
plus __attribute__((gnu_inline))? I'm still a little confused there),
or link against -lcygwin. I kind of think the latter sounds wrong,
since there really is no reason that these unused function bodies should
end up in the .o file simply because it happens to have #include
at the top.
Brian
Re: -fkeep-inline-functions and broken Cygwin bootstrap (was: Building GCC 4.3.0 on Cygwin...)
On 3/24/07, Brian Dessent <[EMAIL PROTECTED]> wrote:
Dave Korn wrote:
> # 405 "/usr/include/stdio.h" 3 4
[ Which is from newlib (libc/include/stdio.h) if anyone reading this
doesn't have a Cygwin system handy. ]
> static __inline__ int __sgetc_r(struct _reent *__ptr, FILE *__p)
> {
> [...]
>
> The critical difference is the presence or absence of
> -fkeep-inline-functions. I think I remember there being some change between
> gcc-3.x and gcc-4.x in inline handling and I think that's what's biting us
> now; I think this may only arise in stage1 where we're trying to use 3.x to
> compile 4.x.
I too thought that this was related to the c99 inline changes, but I
think those only apply to "extern inline" which is not the case here.
The real cause seems to be that -fkeep-inline-functions was a no-op up
until: , which
seems to roughly correspond to when bootstrap stopped working on Cygwin.
Actually it was not a no-op in 3.4, just 4.2 (or was it also broken in
4.1) broke -fkeep-inline-functions and nobody noticed until later.
Cygwin's headers are broken with respect of -fkeep-inline-functions
and need to be fixed.
-- Pinski
Bootstrap comparison failure with -O2 -funroll-loops -funsafe-math-optimizations
Hello, I get the following error while bootstraping mainline with -O2 -funroll-loops -funsafe-math-optimizations options on PPC. Thanks, Revital make[3]: Leaving directory `/home/revitale/mainline_zero_mve/build' Comparing stages 2 and 3 warning: ./cc1plus-checksum.o differs warning: ./cc1obj-checksum.o differs warning: ./cc1-checksum.o differs Bootstrap comparison failure! ./ipa-inline.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/home/revitale/mainline_zero_mve/build' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/home/revitale/mainline_zero_mve/build' make: *** [bootstrap] Error 2
