Re: question on verify_ssa failure due to ccp in dom3 (PR30784)
On 3/14/07, Dorit Nuzman [EMAIL PROTECTED] wrote:
Hi,
We have a '{2,2}' expression (vector initializer) propagated by dom
into a
BIT_FIELD_REF:
before (bug.c.105t.vrp2):
vector long int vect_cst_.47;
vect_cst_.47_66 = {2, 2};
D.2103_79 = BIT_FIELD_REF vect_cst_.47_66, 64, 0;
after (bug.c.106t.dom3):
Optimizing block #7
Optimizing statement L0:;
Optimizing statement D.2102_78 = BIT_FIELD_REF
vect_vec_iv_.48_67,
64, 0;
Optimizing statement D.2103_79 = BIT_FIELD_REF vect_cst_.47_66,
64,
0;
Replaced 'vect_cst_.47_66' with constant '{2, 2}'
D.2103_79 = BIT_FIELD_REF {2, 2}, 64, 0;
...which causes he following ICE:
bug.c:8: error: invalid reference prefix
{2, 2}
bug.c:8: internal compiler error: verify_stmts failed
Several testcases are available in the bugzilla report (PR30784).
So, the question is - what needs to be fixed - is it copy propagation
that
allows propagating the initializer into a BIT_FIELD_REF? or vect_lower
pass
that creates these BIT_FIELD_REFs after vectorization?
I think the BIT_FIELD_REF should be properly folded to a constant or
the propagation
not done. fold_stmt_inplace is the candidate to look at,
propagate_rhs_into_lhs in
tree-ssa-dom.c to reject propagation into BIT_FIELD_REF.
fold_ternary should be
able to fold the BIT_FIELD_REF in question, it would be interesting to
know why it
doesn't.
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?).
Thanks a bunch!
dorit
(See attached file: fix.txt)
Richard.Index: fold-const.c
===
--- fold-const.c(revision 123159)
+++ fold-const.c(working copy)
@@ -12470,7 +12470,8 @@
gcc_unreachable ();
case BIT_FIELD_REF:
- if (TREE_CODE (arg0) == VECTOR_CST
+ if ((TREE_CODE (arg0) == VECTOR_CST
+ || (TREE_CODE (arg0) == CONSTRUCTOR TREE_CONSTANT (arg0)))
type == TREE_TYPE (TREE_TYPE (arg0))
host_integerp (arg1, 1)
host_integerp (op2, 1))
@@ -12484,7 +12485,18 @@
(idx = idx / width)
TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0)))
{
- tree elements = TREE_VECTOR_CST_ELTS (arg0);
+ tree elements = NULL_TREE;
+
+ if (TREE_CODE (arg0) == VECTOR_CST)
+ elements = TREE_VECTOR_CST_ELTS (arg0);
+ else
+ {
+ unsigned HOST_WIDE_INT idx;
+ tree value;
+
+ FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (arg0), idx,
value)
+ elements = tree_cons (NULL_TREE, value, elements);
+ }
while (idx-- 0 elements)
elements = TREE_CHAIN (elements);
if (elements)
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
then0 path of an if statement is taken.
An example of that is if (m0) {n=m+1; if (n0) {...}}. 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 n0 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=x5?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 checked for no side effects. */
- if (!
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: [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!
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: http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01396.html, 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
[Bug target/30784] [4.3 regression] ICE on loop vectorization (-O1 -march=athlon-xp -ftree-vectorize)
--- Comment #7 from dorit at il dot ibm dot com 2007-03-24 08:00 --- patch: http://gcc.gnu.org/ml/gcc/2007-03/msg00918.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30784
[Bug fortran/31200] wrong code: procedure call with pointer-returning-function as argument
--- Comment #5 from patchapp at dberlin dot org 2007-03-24 08:10 --- Subject: Bug number PR31200 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01595.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31200
[Bug fortran/31320] Illegal read with gfortran.dg/alloc_comp_assign_2.f90 and *_3.f90
--- Comment #1 from pault at gcc dot gnu dot org 2007-03-24 08:16 --- (In reply to comment #0) Is this example (PR 20541) really valid? Lahey does not complain. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31320
[Bug tree-optimization/31333] New: ICE with -fno-tree-dominator-opts -ftree-vectorize -msse
The testcase gcc.dg/vect/no-tree-dom-vect-bug.c ICEs on i386-linux when compiled as follows: gcc no-tree-dom-vect-bug.c -O2 -fno-tree-dominator-opts -ftree-vectorize -msse no-tree-dom-vect-bug.c: In function âmain1â: no-tree-dom-vect-bug.c:15: internal compiler error: in expand_simple_binop, at optabs.c:1192 This happens somewhere between these passes: no-tree-dom-vect-bug.c.036t.release_ssa no-tree-dom-vect-bug.c.044t.apply_inline (maybe when the vectorized main1 is inlined into main?) gdb traceback: function=0x8703852 expand_simple_binop) at ../../gcc/gcc/diagnostic.c:656 656 internal_error (in %s, at %s:%d, function, trim_filename (file), line); (gdb) backtrace #0 fancy_abort (file=0x8703282 ../../gcc/gcc/optabs.c, line=1192, function=0x8703852 expand_simple_binop) at ../../gcc/gcc/diagnostic.c:656 #1 0x08271467 in expand_simple_binop (mode=Variable mode is not available. ) at ../../gcc/gcc/optabs.c:1192 #2 0x081a2a3f in force_operand (value=0xb7d01d98, target=0xb7a9d960) at ../../gcc/gcc/expr.c:6069 #3 0x08622a4d in move_invariant_reg (loop=0xa363f60, invno=0) at ../../gcc/gcc/loop-invariant.c:1180 #4 0x086236bd in move_loop_invariants () at ../../gcc/gcc/loop-invariant.c:1242 #5 0x08621757 in rtl_move_loop_invariants () at ../../gcc/gcc/loop-init.c:256 #6 0x082775c6 in execute_one_pass (pass=0x87ad8a0) at ../../gcc/gcc/passes.c:1058 #7 0x082777b7 in execute_pass_list (pass=0x87ad8a0) at ../../gcc/gcc/passes.c:1110 #8 0x082777ca in execute_pass_list (pass=0x87ad7e0) at ../../gcc/gcc/passes.c: #9 0x082777ca in execute_pass_list (pass=0x87aab60) at ../../gcc/gcc/passes.c: #10 0x08356638 in tree_rest_of_compilation (fndecl=0xb7ce9a80) at ../../gcc/gcc/tree-optimize.c:412 #11 0x0808db8c in c_expand_body (fndecl=0xb7ce9a80) at ../../gcc/gcc/c-common.c:4285 #12 0x084b4ab1 in cgraph_expand_function (node=0xb7c1b700) at ../../gcc/gcc/cgraphunit.c:1015 #13 0x084b6e96 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1084 #14 0x0805b4df in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:7930 #15 0x082f5bd6 in toplev_main (argc=20, argv=0xbfd26434) at ../../gcc/gcc/toplev.c:1063 #16 0x080d5e02 in main (argc=Cannot access memory at address 0x1 ) at ../../gcc/gcc/main.c:35 (gdb) up #2 0x081a2a3f in force_operand (value=0xb7d01d98, target=0xb7a9d960) at ../../gcc/gcc/expr.c:6069 6069 return expand_simple_binop (GET_MODE (value), code, op1, op2, (gdb) p code $1 = VEC_SELECT -- Summary: ICE with -fno-tree-dominator-opts -ftree-vectorize -msse Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at il dot ibm dot com GCC build triplet: i386-linux GCC host triplet: i386-linux GCC target triplet: i386-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31333
[Bug bootstrap/31039] Latest CVS-stage 2-Cannot create executables
--- Comment #4 from schwab at suse dot de 2007-03-24 08:26 --- (In reply to comment #2) Note that the newly built bootstrap compiler fails the configure tests which have a trailing -V on the command line. This is harmless, it's only for informational purpose (various tries to make the compiler display its version number, but nothing depends on this). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31039
Re: [Bug bootstrap/31039] Latest CVS-stage 2-Cannot create executables
--- Comment #3 from tprince at computer dot org 2007-03-24 01:22 (In reply to comment #3) The code thus commented out apparently requires some cygwin extensions in the library which have disappeared since 20070224 (quoted by submitter as last working build). I concur, having built successfully the 20070223 For the sake of completeness, the last useful trunk that builds fine is trunk 122292-20070224 downloaded with svn -q co -r122292 svn://gcc.gnu.org/svn/gcc/trunk gcc Since trunk 122293 the build fails as reported. Cheers, Angelo.
[Bug target/31334] New: Bad codegen for vectorized induction with altivec
Turns out the code we are generating for vectorized induction ppc is quite
terrible - the vector induction variable is advanced by a constant step in the
loop (e.g., {4,4,4,4} as in the testcase below). This is the sequence gcc
currently creates for altivec in order to generate the {4,4,4,4} vector:
li 0,4
stw 0,-48(1)
lvewx 0,0,9
vspltw 0,0,0
So, one thing to figure out is why we don't use the immediate form of the splat
(vspltiw); The other is - why this sequence ends up getting generated not only
before the loop (see insns marked with 1 below), but also inside the
loop... (see insns marked with 2 below).
This is the testcase (it is basically the testcase
gcc.dg/vect/no-tree-scev-cprop-vect-iv-1.c with larger loop count to avoid
complete unrolling):
int main1 (int X)
{
int s = X;
int i;
for (i = 0; i 96; i++)
s += i;
return s;
}
compiled as follows:
gcc -O2 -ftree-vectorize -maltivec -fno-tree-scev-cprop -S t.c
li 0,4 1
stw 0,-48(1)1
ld 9,[EMAIL PROTECTED](2)
li 0,23
mr 11,3
mtctr 0
lvx 1,0,9
addi 9,1,-48
vor 13,1,1
lvewx 0,0,9 1
vspltw 0,0,01
vadduwm 1,1,0
.p2align 4,,15
.L2:
li 0,4 2
addi 9,1,-48
vadduwm 13,13,1
stw 0,-48(1)2
lvewx 0,0,9 2
vspltw 0,0,02
vadduwm 1,1,0
bdnz .L2
--
Summary: Bad codegen for vectorized induction with altivec
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
GCC build triplet: powerpc-linux
GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31334
[Bug libfortran/31335] New: Calls lstat(), stat() and fstat() in libgfortran should be protected by autoconf HAVE_{L,,F}STAT macros
In libgfortran/intrinsics/stat.c, we unconditionally issue calls to stat(),
fstat() and lstat(). This is wrong, and these calls should be protected by
HAVE_{,F,L}STAT macros, themselves defined by autoconf.
This bug is annoying especially for lstat(), because it's non-POSIX and it's
not present on mingw; this, in turns, prevent us from creating a DLL
libgfortran (when the recent libtool patch by Steve Ellcey will be commited, it
will be the only bug still preventing this!). In the lstat() case, when lstat()
is not available and stat() is available, we should use it instead.
PS: We already have a test HAVE_WORKING_STAT that is used by the I/O system to
see if the system stat implementation fits the needs of the I/O code, but this
is unrelated.
--
Summary: Calls lstat(), stat() and fstat() in libgfortran should
be protected by autoconf HAVE_{L,,F}STAT macros
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: fxcoudert at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31335
[Bug libfortran/31335] Calls lstat(), stat() and fstat() in libgfortran should be protected by autoconf HAVE_{L,,F}STAT macros
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-24 11:02:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31335
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #40 from manu at gcc dot gnu dot org 2007-03-24 11:10 --- In the current version of the patch janis-try2, this is more correct -set expmsg $msgprefix\[^\n]*$expmsg +set expmsg $msgprefix\[^\n\]*$expmsg But it doesn't make any real difference (or so it seems). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug fortran/31278] Backtrace/coredump for array-out-of-bounds errors (-fbounds-check)
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-24 12:13 --- We already have that, if you compile with both -fbounds-check and -fbacktrace. (Same thing is true for coredump, with -fdump-core.) Do you want fries with that? $ cat bbb.f90 subroutine f integer :: x(2), u u = 3 x(u) = 0 end subroutine f call f end $ gfortran -static bbb.f90 -fbounds-check -fbacktrace -g ./a.out Fortran runtime error: Array reference out of bounds for array 'x', upper bound of dimension 1 exceeded (in file 'bbb.f90', at line 4) Backtrace for this error: + function f_ (0x8048229) at line 4 of file bbb.f90 + in the main program at line 7 of file bbb.f90 + function __libc_start_main (0x805C9F9) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31278
[Bug fortran/31219] ICE on array of character function results
--- Comment #3 from pault at gcc dot gnu dot org 2007-03-24 12:31 --- Subject: Bug 31219 Author: pault Date: Sat Mar 24 12:30:58 2007 New Revision: 123183 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123183 Log: 2007-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/31215 * trans-expr.c (gfc_apply_interface_mapping_to_expr): Return int result that is non-zero if the expression is the function result. Only the characteristics of the result expression can be used in a procedure interface, so simplify LEN in situ using its character length. PR fortran/31219 PR fortran/31200 * trans-expr.c (gfc_conv_function_call): Do not use gfc_conv_expr_reference for actual pointer function with formal target because a temporary is created that does not transfer the reference correctly. Do not indirect formal pointer functions since it is the function reference that is needed. 2007-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/31219 * gfortran.dg/pointer_function_actual_1.f90: New test. PR fortran/31200 * gfortran.dg/pointer_function_actual_2.f90: New test. PR fortran/31215 * gfortran.dg/result_in_spec_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pointer_function_actual_1.f90 trunk/gcc/testsuite/gfortran.dg/pointer_function_actual_2.f90 trunk/gcc/testsuite/gfortran.dg/result_in_spec_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31219
[Bug fortran/31200] wrong code: procedure call with pointer-returning-function as argument
--- Comment #6 from pault at gcc dot gnu dot org 2007-03-24 12:31 --- Subject: Bug 31200 Author: pault Date: Sat Mar 24 12:30:58 2007 New Revision: 123183 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123183 Log: 2007-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/31215 * trans-expr.c (gfc_apply_interface_mapping_to_expr): Return int result that is non-zero if the expression is the function result. Only the characteristics of the result expression can be used in a procedure interface, so simplify LEN in situ using its character length. PR fortran/31219 PR fortran/31200 * trans-expr.c (gfc_conv_function_call): Do not use gfc_conv_expr_reference for actual pointer function with formal target because a temporary is created that does not transfer the reference correctly. Do not indirect formal pointer functions since it is the function reference that is needed. 2007-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/31219 * gfortran.dg/pointer_function_actual_1.f90: New test. PR fortran/31200 * gfortran.dg/pointer_function_actual_2.f90: New test. PR fortran/31215 * gfortran.dg/result_in_spec_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pointer_function_actual_1.f90 trunk/gcc/testsuite/gfortran.dg/pointer_function_actual_2.f90 trunk/gcc/testsuite/gfortran.dg/result_in_spec_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31200
[Bug fortran/31215] ICE on valid code with gfortran
--- Comment #4 from pault at gcc dot gnu dot org 2007-03-24 12:31 --- Subject: Bug 31215 Author: pault Date: Sat Mar 24 12:30:58 2007 New Revision: 123183 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123183 Log: 2007-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/31215 * trans-expr.c (gfc_apply_interface_mapping_to_expr): Return int result that is non-zero if the expression is the function result. Only the characteristics of the result expression can be used in a procedure interface, so simplify LEN in situ using its character length. PR fortran/31219 PR fortran/31200 * trans-expr.c (gfc_conv_function_call): Do not use gfc_conv_expr_reference for actual pointer function with formal target because a temporary is created that does not transfer the reference correctly. Do not indirect formal pointer functions since it is the function reference that is needed. 2007-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/31219 * gfortran.dg/pointer_function_actual_1.f90: New test. PR fortran/31200 * gfortran.dg/pointer_function_actual_2.f90: New test. PR fortran/31215 * gfortran.dg/result_in_spec_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pointer_function_actual_1.f90 trunk/gcc/testsuite/gfortran.dg/pointer_function_actual_2.f90 trunk/gcc/testsuite/gfortran.dg/result_in_spec_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31215
[Bug target/31334] Bad codegen for vectorized induction with altivec
--- Comment #1 from dje at gcc dot gnu dot org 2007-03-24 13:30 ---
Loading the constant through memory appears to be related to the vector plus
expander.
118t.final_cleanup shows:
vect_vec_iv_.32 = vect_cst_.30 + {4, 4, 4, 4};
and 120r.expand shows:
;; vect_vec_iv_.32 = vect_cst_.30 + {4, 4, 4, 4}
(insn 12 10 13 (set (reg:SI 134)
(const_int 4 [0x4])) -1 (nil)
(nil))
(insn 13 12 14 (set (mem/c/i:SI (plus:SI (reg/f:SI 115 virtual-stack-vars)
(const_int 8 [0x8])) [2 S4 A128])
(reg:SI 134)) -1 (nil)
(nil))
(insn 14 13 15 (parallel [
(set (reg:V4SI 133)
(mem/c/i:V4SI (plus:SI (reg/f:SI 115 virtual-stack-vars)
(const_int 8 [0x8])) [2 S16 A128]))
(unspec [
(const_int 0 [0x0])
] 196)
]) -1 (nil)
(nil))
(insn 15 14 16 (set (reg:V4SI 133)
(vec_duplicate:V4SI (vec_select:SI (reg:V4SI 133)
(parallel [
(const_int 0 [0x0])
] -1 (nil)
(nil))
(insn 16 15 0 (set (reg:V4SI 126 [ vect_vec_iv_.32 ])
(plus:V4SI (reg:V4SI 127 [ vect_cst_.30 ])
(reg:V4SI 133))) -1 (nil)
(nil))
The constants appear to be constructor expressions:
plus_expr 0x4019d700
type vector_type 0x400e7ea0 __vector signed int
type integer_type 0x40074340 int sizes-gimplified public SI
size integer_cst 0x40068500 constant invariant 32
unit size integer_cst 0x400682a0 constant invariant 4
align 32 symtab 0 alias set 2 canonical type 0x40074340 precision
32 min integer_cst 0x400684a0 -2147483648 max integer_cst 0x400684c0
2147483647
pointer_to_this pointer_type 0x40074e38
V4SI
size integer_cst 0x40068740 constant invariant 128
unit size integer_cst 0x40068760 constant invariant 16
align 128 symtab 0 alias set -1 canonical type 0x400e7ea0 nunits 4
arg 0 var_decl 0x401a3150 vect_vec_iv_.32 type vector_type 0x400e7ea0
__vector signed int
used ignored V4SI file d.c line 2 size integer_cst 0x40068740 128
unit size integer_cst 0x40068760 16
align 128 context function_decl 0x4015ae00 main1
(reg:V4SI 126 [ vect_vec_iv_.32 ])
arg 1 constructor 0x401a6120 type vector_type 0x400e7ea0 __vector signed
int
constant
constructor 0x401a6120
type vector_type 0x400e7ea0 __vector signed int
type integer_type 0x40074340 int sizes-gimplified public SI
size integer_cst 0x40068500 constant invariant 32
unit size integer_cst 0x400682a0 constant invariant 4
align 32 symtab 0 alias set 2 canonical type 0x40074340 precision
32 min integer_cst 0x400684a0 -2147483648 max integer_cst 0x400684c0
2147483647
pointer_to_this pointer_type 0x40074e38
V4SI
size integer_cst 0x40068740 constant invariant 128
unit size integer_cst 0x40068760 constant invariant 16
align 128 symtab 0 alias set -1 canonical type 0x400e7ea0 nunits 4
constant
And the constructors are thrown into memory. The original expression with a
constant never gets converted to RTL and never is evaluated as an easy vector
constant.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-03-24 13:30:37
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31334
[Bug fortran/31219] ICE on array of character function results
--- Comment #4 from pault at gcc dot gnu dot org 2007-03-24 13:56 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31219
[Bug fortran/31215] ICE on valid code with gfortran
--- Comment #5 from pault at gcc dot gnu dot org 2007-03-24 13:57 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31215
[Bug fortran/31200] wrong code: procedure call with pointer-returning-function as argument
--- Comment #7 from pault at gcc dot gnu dot org 2007-03-24 13:58 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31200
[Bug fortran/31209] too much indirection for actual pointer procedure
--- Comment #2 from pault at gcc dot gnu dot org 2007-03-24 13:59 --- Fixed on trunk but wrongly numbered in ChangeLog Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31209
[Bug fortran/31219] ICE on array of character function results
--- Comment #5 from pault at gcc dot gnu dot org 2007-03-24 14:00 --- Sorry, this was not fixed - it was PR31209 that was fixed. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31219
[Bug fortran/31200] wrong code: procedure call with pointer-returning-function as argument
--- Comment #8 from pault at gcc dot gnu dot org 2007-03-24 14:17 --- Subject: Bug 31200 Author: pault Date: Sat Mar 24 14:17:34 2007 New Revision: 123184 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123184 Log: 2007-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/31215 * trans-expr.c (gfc_apply_interface_mapping_to_expr): Return int result that is non-zero if the expression is the function result. Only the characteristics of the result expression can be used in a procedure interface, so simplify LEN in situ using its character length. PR fortran/31219 PR fortran/31200 * trans-expr.c (gfc_conv_function_call): Do not use gfc_conv_expr_reference for actual pointer function with formal target because a temporary is created that does not transfer the reference correctly. Do not indirect formal pointer functions since it is the function reference that is needed. 2007-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/31219 * gfortran.dg/pointer_function_actual_1.f90: New test. PR fortran/31200 * gfortran.dg/pointer_function_actual_2.f90: New test. PR fortran/31215 * gfortran.dg/result_in_spec_1.f90: New test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pointer_function_actual_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31200
[Bug fortran/31215] ICE on valid code with gfortran
--- Comment #6 from pault at gcc dot gnu dot org 2007-03-24 14:17 --- Subject: Bug 31215 Author: pault Date: Sat Mar 24 14:17:34 2007 New Revision: 123184 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123184 Log: 2007-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/31215 * trans-expr.c (gfc_apply_interface_mapping_to_expr): Return int result that is non-zero if the expression is the function result. Only the characteristics of the result expression can be used in a procedure interface, so simplify LEN in situ using its character length. PR fortran/31219 PR fortran/31200 * trans-expr.c (gfc_conv_function_call): Do not use gfc_conv_expr_reference for actual pointer function with formal target because a temporary is created that does not transfer the reference correctly. Do not indirect formal pointer functions since it is the function reference that is needed. 2007-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/31219 * gfortran.dg/pointer_function_actual_1.f90: New test. PR fortran/31200 * gfortran.dg/pointer_function_actual_2.f90: New test. PR fortran/31215 * gfortran.dg/result_in_spec_1.f90: New test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pointer_function_actual_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31215
[Bug fortran/31219] ICE on array of character function results
--- Comment #6 from pault at gcc dot gnu dot org 2007-03-24 14:17 --- Subject: Bug 31219 Author: pault Date: Sat Mar 24 14:17:34 2007 New Revision: 123184 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123184 Log: 2007-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/31215 * trans-expr.c (gfc_apply_interface_mapping_to_expr): Return int result that is non-zero if the expression is the function result. Only the characteristics of the result expression can be used in a procedure interface, so simplify LEN in situ using its character length. PR fortran/31219 PR fortran/31200 * trans-expr.c (gfc_conv_function_call): Do not use gfc_conv_expr_reference for actual pointer function with formal target because a temporary is created that does not transfer the reference correctly. Do not indirect formal pointer functions since it is the function reference that is needed. 2007-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/31219 * gfortran.dg/pointer_function_actual_1.f90: New test. PR fortran/31200 * gfortran.dg/pointer_function_actual_2.f90: New test. PR fortran/31215 * gfortran.dg/result_in_spec_1.f90: New test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pointer_function_actual_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31219
[Bug libfortran/31335] Calls lstat(), stat() and fstat() in libgfortran should be protected by autoconf HAVE_{L,,F}STAT macros
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||03/msg01605.html Keywords||patch Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31335
[Bug target/30784] [4.3 regression] ICE on loop vectorization (-O1 -march=athlon-xp -ftree-vectorize)
--- Comment #8 from patchapp at dberlin dot org 2007-03-24 17:10 --- Subject: Bug number PR30784 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01607.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30784
[Bug java/31325] gcj support for ARM EABI
--- Comment #10 from s_j_newbury at yahoo dot co dot uk 2007-03-24 17:30 --- (In reply to comment #3) Created an attachment (id=13262) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13262action=view) [edit] EABI can't implement _Unwind_Backtrace This patch is from this bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206 This patch doesn't help right now. It only affects sjlj exceptions and they obviously aren't used due to --disable-sjlj-exceptions anyhow. Using this patch as is causes _Unwind_Reason_Code to be undefined when sjlj exceptions are disabled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
[Bug tree-optimization/31333] ICE with -fno-tree-dominator-opts -ftree-vectorize -msse
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-24 17:30 --- The backtrace shows rtl invariant motion. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31333
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #41 from manu at gcc dot gnu dot org 2007-03-24 17:55 ---
(In reply to comment #38)
For comment #32 I get the failure but don't understand the problem; the regexp
matches the message, doesn't it? This doesn't seem any different from other
Fortran tests but it's the only one that fails; perhaps there's something
special about specifying the line number in the test directive, or that the
message comes from a file with a different name. I'll stare at it again
later.
No, it doesn't match. If you look closely to this message compared to other
fortran messages:
* Broken match:
Warning: /home/manuel/src/trunk/gcc/testsuite/gfortran.dg/badline.f:2: file
src/badline.F left but not entered
* Correct match:
/home/manuel/src/trunk/gcc/testsuite/gfortran.dg/blockdata_1.f90:17.7:
common j ! { dg-warning cannot contain blank COMMON }
1
Warning: BLOCK DATA unit cannot contain blank COMMON at (1)
The difference is that in the first case the filename plus position is between
the Warning: and the message to match. Actually I think the deja-gnu or some
*.exp file does some preprocessing of the output. For example, if you look at
the output of gcc/testsuite/gfortran.dg/continuation_1.f90
/home/manuel/src/trunk/gcc/testsuite/gfortran.dg/continuation_1.f90:11.10:
world! ! { dg-warning Warning: Missing '' in continued character co
1
Warning: Missing '' in continued character constant at (1)
FAIL: gfortran.dg/continuation_1.f90 -O0 (test for warnings, line 11)
FAIL: gfortran.dg/continuation_1.f90 -O0 (test for excess errors)
Excess errors:
/home/manuel/src/trunk/gcc/testsuite/gfortran.dg/continuation_1.f90:11:
Warning: Missing '' in continued character constant at (1)
The message shown after Excess errors is slightly different than the
original.
I don't think that we should handle this corner case in our patch: either it is
handled by whatever function preprocesses fortran output or the output itself
is changed by the fortran front-end. We could as well use the original
dg-warning / dg-error directives for fortran.
So, gcc/testsuite/gcc.dg/20041213-1.c is the issue number 1 now. I think it
should match without modifying the testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #30 from jvdelisle at verizon dot net 2007-03-24 19:02 --- Subject: Re: Bad IOSTAT values when readings NAMELISTs past EOF I will keep at it on this. It seems we have a conflict between the SPEC test that was failing and the namelist testcases. Unfortunately I don't have the SPEC test case to see to try to weed this out. What I will do is work on the patch i had before and send it to folks to test the SPEC portion. That may take a while, so please be patient. Sorry for the troubles. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug java/31325] gcj support for ARM EABI
--- Comment #11 from s_j_newbury at yahoo dot co dot uk 2007-03-24 19:58 --- I have everything built except for libjava/exception.cc which fails as seen below. This I believe is due to the lack of an implementation of _Unwind_Backtrace in the ARM EABI. What needs to be done to address this? Can anybody give me any pointers? In http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206 Daniel Jackobowitz says As for ARM, I'm not sure what to do to fix the issue. ARM old ABI is stuck with SJLJ. And the EABI can't implement _Unwind_Backtrace either. I have been speaking with someone at ARM about the ABI implications of this, on and off, but I don't have a lot of hope for it working out without a GNU extension. depbase=`echo jni.lo | sed 's|[^/]*$|.deps/|;s|\.lo$||'`; \ if /bin/sh ./libtool --mode=compile /home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/build/./gcc/xgcc -shared-libgcc -B/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/build/./gcc -nostdinc++ -L/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/build/arm-iwmmxt-linux-gnueabi/libstdc++-v3/src -L/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/build/arm-iwmmxt-linux-gnueabi/libstdc++-v3/src/.libs -B/usr/lib/gcj-4.2.0_beta20070307/arm-iwmmxt-linux-gnueabi/bin/ -B/usr/lib/gcj-4.2.0_beta20070307/arm-iwmmxt-linux-gnueabi/lib/ -isystem /usr/lib/gcj-4.2.0_beta20070307/arm-iwmmxt-linux-gnueabi/include -isystem /usr/lib/gcj-4.2.0_beta20070307/arm-iwmmxt-linux-gnueabi/sys-include -DHAVE_CONFIG_H -I. -I/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava -I./include -I./gcj -I/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava -Iinclude -I/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava/include -I/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava/classpath/include -Iclasspath/include -I/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava/classpath/native/fdlibm -I/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava/../boehm-gc/include -I../boehm-gc/include -I/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava/libltdl -I/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava/libltdl -I/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava/.././libjava/../gcc -I/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\/usr/lib/gcj-4.2.0_beta20070307\ -DTOOLEXECLIBDIR=\/usr/lib/gcj-4.2.0_beta20070307/lib\ -DJAVA_HOME=\/usr/lib/gcj-4.2.0_beta20070307/jre\ -DBOOT_CLASS_PATH=\/usr/lib/gcj-4.2.0_beta20070307/jre/lib/rt.jar\ -DJAVA_EXT_DIRS=\/usr/lib/gcj-4.2.0_beta20070307/share/java/ext\ -DGCJ_ENDORSED_DIRS=\/usr/lib/gcj-4.2.0_beta20070307/share/java/gcj-endorsed\ -DGCJ_VERSIONED_LIBDIR=\/usr/lib/gcj-4.2.0_beta20070307/lib/gcj-4.2.0-beta20070307\ -DPATH_SEPARATOR=\:\ -DLIBGCJ_DEFAULT_DATABASE=\/usr/lib/gcj-4.2.0_beta20070307/lib/gcj-4.2.0-beta20070307/classmap.db\ -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\gcj-4.2.0-beta20070307/classmap.db\ -O2 -pipe -D_GNU_SOURCE -MT jni.lo -MD -MP -MF $depbase.Tpo -c -o jni.lo /home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava/jni.cc; \ then mv -f $depbase.Tpo $depbase.Plo; else rm -f $depbase.Tpo; exit 1; fi /home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/build/./gcc/xgcc -shared-libgcc -B/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/build/./gcc -nostdinc++ -L/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/build/arm-iwmmxt-linux-gnueabi/libstdc++-v3/src -L/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/build/arm-iwmmxt-linux-gnueabi/libstdc++-v3/src/.libs -B/usr/lib/gcj-4.2.0_beta20070307/arm-iwmmxt-linux-gnueabi/bin/ -B/usr/lib/gcj-4.2.0_beta20070307/arm-iwmmxt-linux-gnueabi/lib/ -isystem /usr/lib/gcj-4.2.0_beta20070307/arm-iwmmxt-linux-gnueabi/include -isystem /usr/lib/gcj-4.2.0_beta20070307/arm-iwmmxt-linux-gnueabi/sys-include -DHAVE_CONFIG_H -I. -I/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava -I./include -I./gcj -I/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava -Iinclude -I/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava/include -I/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava/classpath/include -Iclasspath/include -I/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava/classpath/native/fdlibm -I/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava/../boehm-gc/include -I../boehm-gc/include -I/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava/libltdl
[Bug fortran/30655] Undue out-of-bounds warning
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-24 20:20 --- Subject: Bug 30655 Author: fxcoudert Date: Sat Mar 24 20:19:51 2007 New Revision: 123187 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123187 Log: PR fortran/30655 * expr.c (check_dimension): Fix logic of comparisons. * gfortran.dg/bounds_check_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/bounds_check_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30655
[Bug fortran/30655] Undue out-of-bounds warning
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-03-24 20:21 --- Fixed on 4.3, will not backport. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30655
[Bug fortran/31213] ICE on valid code with gfortran
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-24 20:53 --- Reduced testcase: function tricky(ugly) interface yoagly pure function ugly() complex ugly(2) end function ugly end interface yoagly logical la(size(yoagly())) print *, size(la) end function tricky I would have bet that this would be fixed when Paul fixed PR31215, because it's an ICE in the same place, but it appears it isn't fixed. Paul, since the previous PRs were really related, you might understand this one easily? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org, pault at gcc dot gnu ||dot org Known to fail||4.1.3 4.2.0 4.3.0 Last reconfirmed|2007-03-21 17:15:41 |2007-03-24 20:53:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31213
[Bug c++/31336] New: template friends and Koenig lookup
Koenig lookup doesn't seem to work properly when dealing with template friends
defined within a class. Friends defined within the definition of a class
shouldn't be visible to the enclosing namespace, and should only be able to be
found via Koenig lookup. I see that this appears to work as expected for
normal friends, but GCC still appears make the name visible for template
friends.
I think that this behaviour is incorrect, but could I be missing something?
The Comeau C++ with EDG front end seems to agree with my reading of the spec,
but then its possible that its behaviour is incorrect instead.
In the following test program, I think that tests #5 and #7 should fail to
compile, but do not. Neither bar(int, int) and bar(Foo, int) contain an
associated class to class Bar and therefore should not be found.
Thanks!
Andy
#include iostream
struct Bar;
struct Foo
{
Foo() { }
Foo(const Bar src) { std::cout Bar-Foo std::endl; }
Foo(int src) { std::cout int-Foo std::endl; }
friend void foo(const Foo a, int b)
{
std::cout Foo b std::endl;
}
};
struct Bar
{
operator int() { return(9); } // for test 9
templatetypename A, typename B
friend void bar(const A a, B b)
{
std::cout Bar b std::endl;
}
};
int main(int argc, char *argv[])
{
Foo f;
Bar b;
//foo(1, 0); // #0 - EDG, MSVC 8, GCC 4.1.2 no yes via conversion ctor
foo((Foo)1, 1); // #1 ok via conv ctor
foo(f, 2); // #2 ok
//foo(b, 3); // #3 EDG no, GCC 4.1.2 no, MSVC 8 yes via conv ctor
foo((Foo)b, 4); // #4 ok via conv ctor
bar(1, 5); // #5 EDG, MSVC 8 no, GCC 4.1.2 yes
bar(b, 6); // #6 ok
bar(f, 7); // #7 EDG no, MSVC 8, GCC 4.1.2 yes
bar(b, 8); // #8 ok
bar(f, b); // #9 ok
return(0);
}
--
Summary: template friends and Koenig lookup
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot olson at hughes dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31336
[Bug fortran/31196] wrong code generated with RESHAPE/TRANSPOSE
--- Comment #3 from tkoenig at alice-dsl dot net 2007-03-24 21:35 --- Created an attachment (id=13278) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13278action=view) proposed patch This should fix it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31196
[patch, libfortran] Fix PR 31196
:ADDPATCH fortran:
Hello world,
this one-liner fixes PR 31196, where reshape of a
transposed array led to silent wrong results.
Currently regtesting on i686-pc-linux-gnu. OK for 4.3
if this passes? OK for 4.2?
Thomas
2007-03-24 Thomas Koenig [EMAIL PROTECTED]
* intrinsic/reshape_generic.c (reshape_internal): Increment
correct variable.
! { dg-do run }
! PR 31196 - reshape of transposed derived types generated
!wront results.
program main
implicit none
TYPE datatype
INTEGER :: I
END TYPE datatype
character (len=20) line1, line2
TYPE(datatype), dimension(2,2) :: data, result
data(1,1)%i = 1
data(2,1)%i = 2
data(1,2)%i = 3
data(2,2)%i = 4
write (unit=line1, fmt=(4I4)) reshape(transpose(data),shape(data))
write (unit=line2, fmt=(4I4)) (/ 1, 3, 2, 4 /)
if (line1 /= line2) call abort
END program main
Index: intrinsics/reshape_generic.c
===
--- intrinsics/reshape_generic.c (revision 123028)
+++ intrinsics/reshape_generic.c (working copy)
@@ -266,7 +266,7 @@ reshape_internal (parray *ret, parray *s
else
{
scount[n]++;
- sptr += sstride[n] * size;
+ src += sstride[n] * size;
}
}
}
[Bug libfortran/31297] Use of uninitialized variables in libgfortran's I/O
--- Comment #1 from tkoenig at alice-dsl dot net 2007-03-24 22:17 --- This is a bug in the test case. I'll commit a correct version. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31297
[Bug testsuite/31240] gfortran.dg/pointer_intent_1.f90 failure at -O0
--- Comment #1 from dominiq at lps dot ens dot fr 2007-03-24 22:28 --- xlf yields a bus error without optimization and -O, and abort with -O3. g95 gives the following errors: In file pointer_intent_1.f90:39 nullify(t%point) 1 Error: Cannot NULLIFY the INTENT(IN) pointer 't' at (1) In file pointer_intent_1.f90:42 deallocate(t%point) 1 Error: Cannot DEALLOCATE INTENT(IN) dummy variable 't' at (1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31240
[Bug libfortran/31297] Use of uninitialized variables in libgfortran's I/O
--- Comment #2 from tkoenig at alice-dsl dot net 2007-03-24 22:44 --- Created an attachment (id=13279) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13279action=view) patch for the test cases All but one of these were errors in the test cases, which are corrected with this patch. unf_io_convert_3.f90 is a case where we don't initialize the left-over bytes when converting. Hmm... I'll have to look into this some more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31297
[Bug middle-end/31337] New: [4.2/4.3 regression] ICE with statement expression
The following valid code snippet triggers an ICE on mainline and 4.2 branch:
===
struct A
{
int i[0];
A();
A(const A);
};
void foo()
{
A a = ({ A(); });
}
===
bug.cc: In function 'void foo()':
bug.cc:10: internal compiler error: in create_tmp_var, at gimplify.c:488
Please submit a full bug report, [etc.]
--
Summary: [4.2/4.3 regression] ICE with statement expression
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31337
[Bug middle-end/31337] [4.2/4.3 regression] ICE with statement expression
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31337
[Bug libfortran/31297] Use of uninitialized variables in libgfortran's I/O
--- Comment #3 from tkoenig at alice-dsl dot net 2007-03-24 23:07 --- Created an attachment (id=13280) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13280action=view) proposed patch This one also fixes the last case. It does so by reading size bytes instead of the kind number when converting endianness. This makes the buffers initialized, and also makes sure the number of bytes are the same when using CONVERT=SWAP or when using the native format. Not that I really expect anybody to use CONVERT with 10-byte reals, anyway :-) -- tkoenig at alice-dsl dot net changed: What|Removed |Added Attachment #13279|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31297
Re: [patch, libfortran] Fix PR 31196
:REVIEWMAIL: this one-liner fixes PR 31196, where reshape of a transposed array led to silent wrong results. Yes, this brings the code in intrinsics/reshape_generic.c in line with m4/reshape.m4. What's amusing is that this difference appears to go back to the initial merge of code from tree-ssa to mainline. By the way, did you audit these two files for other differences? (I try to keep them in sync when I change one, but I'm not sure I ever gave it a global look.) 2007-03-24 Thomas Koenig [EMAIL PROTECTED] * intrinsic/reshape_generic.c (reshape_internal): Increment correct variable. This is OK for mainline. As for 4.2: it's not a regression, but it's a silent wrong-code bug, and those are always nasty; it's not in a very exposed part of the library, though (character transpose is probably not the most used feature of gfortran), and it's not risky at all, since it's both very short and known to be correctly working in m4/reshape.m4 for years. So, all considered, I think it's worthy to have in 4.2. I'm not sure whether a mail to Mark M. is needed; if, when you want to commit, the 4.2 branch is still documented as stage 3, I think maintainer approval is enough. But please let at least a few days for others to object/argue before commiting to 4.2. Thanks, FX
[Bug c++/31338] New: [4.1/4.2/4.3 regression] Cannot apply ! to complex constants
The following IMHO valid code snippet is rejected since GCC 3.4.0: === bool b = !0i; === bug.cc:1: error: could not convert '#'complex_cst' not supported by dump_expr#expression error' to 'bool' bug.cc:1: error: in argument to unary ! The C front-end accepts complex constants as argument to !. This is related to PR30209. Btw, the fact that dump_expr cannot handle complex_cst is already tracked in PR 30896. -- Summary: [4.1/4.2/4.3 regression] Cannot apply ! to complex constants Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid, monitored Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org BugsThisDependsOn: 30209 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31338
[Bug c++/31338] [4.1/4.2/4.3 regression] Cannot apply ! to complex constants
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31338
[Bug middle-end/31339] New: [4.3 regression] ICE on invalid use of complex constant
The following invalid code snippet triggers an ICE on mainline: === bool b = --0i == 0; === bug.cc:1: error: lvalue required as decrement operand bug.cc:1: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in fold_comparison, at fold-const.c:8459 Please submit a full bug report, [etc.] -- Summary: [4.3 regression] ICE on invalid use of complex constant Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery, monitored Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31339
[Bug middle-end/31339] [4.3 regression] ICE on invalid use of complex constant
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31339
[Bug c/31340] New: testsuite setjmp-3 and setjmp-4 fail attempting to redefine raise
signal.h is in scope when gcc.dg/setjmp-3.c and setjmp-4.c are compiled. The attempt to redefine raise() causes the tests to fail. Either this should be an XFAIL, or the test should be changed so as to remove the conflict with pre-existing definition. The definition in the testsuite conflicts with Open Group specification http://www.opengroup.org/onlinepubs/95399/functions/raise.html -- Summary: testsuite setjmp-3 and setjmp-4 fail attempting to redefine raise Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31340
[Bug c/31341] New: testsuite pr31041.c fails conflicting with stdint.h
gcc.dg/vect/pr31041 attempts to redefine int32_t while stdint.h is in scope, so test reports FAIL. Is this the intent of the test? -- Summary: testsuite pr31041.c fails conflicting with stdint.h Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31341
[Bug c/31342] New: testsuite i386/pic-1.c FAILed for warning -fPIC ignored
This case issues the warning -fPIC ignored and is FAILed on account of it. -- Summary: testsuite i386/pic-1.c FAILed for warning -fPIC ignored Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31342
[Bug testsuite/31340] testsuite setjmp-3 and setjmp-4 fail attempting to redefine raise
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-25 08:11 --- The name of the function should be changed, it is just a local function name anyways. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |testsuite http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31340
[Bug middle-end/31339] [4.3 regression] ICE on invalid use of complex constant
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-25 08:21 --- if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (arg0)) I think we are just checking TYPE_OVERFLOW_UNDEFINED too early. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ian at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31339
[Bug c++/31337] [4.2/4.3 regression] ICE with statement expression
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-25 08:46 --- This is a front-end issue: cleanup_point Unknown tree: expr_stmt (void) (a = TARGET_EXPR D.2077, cleanup_point TARGET_EXPR D.2076, Unknown tree: aggr_init_expr 4 __comp_ctor D.2076 0B ) We have a cleanup_point expression which causes an extra variable to be created but since the type is addressable, we abort. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |c++ Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-25 07:46:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31337
