[Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
--- Comment #6 from irar at il dot ibm dot com 2008-09-21 07:54 --- (In reply to comment #5) > The data dependence on the previous loop is clearly not considered, the loop > is > vectorized as if c on the rhs and c on the lhs were different non-overlapping > arrays. > The data dependence analysis returns chrec_known for that ddr (probably getting confused by *&s.c[0] and *&s.c[1] base objects), so the vectorizer thinks they are independent and vectorizes the loop. *D.1659_13 base_address: &s.c[0] offset from base address: 0 constant offset from base address: 0 step: 4 aligned to: 128 base_object: *&s.c[0] symbol tag: SMT.62 *D.1655_9 base_address: &s.c[1] offset from base address: 0 constant offset from base address: 0 step: 4 aligned to: 128 base_object: *&s.c[1] symbol tag: SMT.62 (compute_affine_dependence (stmt_a = D.1660_14 = *D.1659_13; ) (stmt_b = *D.1655_9 = D.1664_23; ) ) -- irar at il dot ibm dot com changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug tree-optimization/37539] [4.4 Regression] Hang for -O3
--- Comment #5 from irar at gcc dot gnu dot org 2008-09-21 08:37 --- Subject: Bug 37539 Author: irar Date: Sun Sep 21 08:36:07 2008 New Revision: 140522 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140522 Log: PR tree-optimization/37539 * tree-vect-transform.c (vect_transform_strided_load): Save vector statement in related statement field only for the first load of the group of loads with the same data reference. Added: trunk/gcc/testsuite/gcc.dg/vect/pr37539.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37539
[Bug tree-optimization/37539] [4.4 Regression] Hang for -O3
--- Comment #6 from irar at gcc dot gnu dot org 2008-09-21 08:52 --- Subject: Bug 37539 Author: irar Date: Sun Sep 21 08:51:01 2008 New Revision: 140523 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140523 Log: PR tree-optimization/37539 * tree-vect-transform.c (vect_transform_strided_load): Save vector statement in related statement field only for the first load of the group of loads with the same data reference. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37539
[Bug target/35574] [4.4 regresion] unrecognizable insn generated for vector move
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-09-21 09:08 --- Confirmed on Solaris. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|sparc-rtems4.9 |sparc-*-* Last reconfirmed|-00-00 00:00:00 |2008-09-21 09:08:28 date|| Summary|ICE: pdist-3.c |[4.4 regresion] ||unrecognizable insn ||generated for vector move http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35574
[Bug target/35574] [4.4 regresion] unrecognizable insn generated for vector move
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-09-21 09:08 --- Fixing. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-09-21 09:08:28 |2008-09-21 09:08:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35574
[Bug fortran/37605] New: Remarks on user manual for Gfortran
Remarks on manual Gfortran -- (Page numbers and such refer to the PDF-file available online at 19 september 2008) General remarks --- 1. Section on distributing programs is missing: What is needed if you have created a product to distribute it to customers? (Either with or without sources) 2. Section on floating-point issues is missing: How do the compile options influence the floating-point behaviour? What is the treatment of special values such as Inf and Nan? What happens with atan2(0,0)? 3. POSIX-type extensions in the language reference: No particular information is given how the various functions (SYMLNK for instance or STAT) work (or do not work) on a non-POSIX system like MS Windows. Specific remarks Missing words indicated as _words_ Superfluous words indicated as /words/ Page 1. (bullet 2) because _it_ is easy to make ... (bullet 3) The Fortran 90 _standard_ requires Sentence: "When writing Fortran, it is easy to make big mistakes That is not a very encouraging statement, it is also not inherent to Fortran (but rather to programming in general) and it adds no information. Just remove it. Page 7. -Wall: I have seen at least one version of Gfortran that said (with --help) "This option lacks documentation" or similar words. Version "4.3.2-tdm-1 for MinGW" does not list it at all Page 8. -fall-intrinsics: The explanation is not very clear, in my opinion: it accepts all intrinsic procedures without regard to -std, but it is very useful with -std=f95? The next sentence I had to read it two or three times. Perhaps something like: This option causes all intrinsic procedures (including the GNU-specific extensions) to be accepted. Any user-defined procedures with the same name are ignored. -fd-lines-as-* What is the default? (-fd-lines-as-comments, I suppose) -fdefault-double-8 etc: Does this have any influence on selected_real_kind() or kind(1.0), etc.? Page 15. -Wextra: This flag does not appear in the documentation, other than under -Wunused-parameter Page 16. are likely to /to/ trigger Page 17. -static-libgfortran: When would you use this flag? Would it make distribution easier? Page 20. -founds-check: _Note:_ In the future Page 23. 3.5 GFORTRAN_TMPDIR On Windows I have had severe problems with temporary files opened from a C program (tmpfile()): Files were opened on the root directory of a network disk - which was prohibited, of course. How is that taken care of in Gfortran? Page 29. -fshort-enums should not be "hyphenated". Page 31. TYPESPEC(k): Please replace the sentence explaining k by something like the following, to stress that the _numerical_ value of k is platform-dependent: "where k is the kind parameter suitable for the intended precision. As kind parameters are implementation-dependent, use the kind(), selected_int_kind() and selected_real_kind() functions to retrieve the correct value, for instance: REAL*8 x can be replaced by: integer, parameter :: dbl = kind(1.0d0) real(dbl) :: x" Page 38. "to the existence of an important number of extensions:" Shouldn't that be: "to the existence of a number of important extensions" Page 39. (comment) manipulates -> manipulate Page 41. ABORT: produces a coredump even if -fno-dump-core is in effect? ABS: COMPLEX(8) return type - shouldn't that be REAL(8)? ACCESS: how is the executable flag determined on MS Windows? ACOS: that is less than _or equal to_ one ADJUSTL: the standard that introduced it is Fortran 90, but perhaps this is too detailed. ALLOCATED: if (allocated(x) .eqv. .false.) ... This is an ugly style and actually a misuse of .eqv., use instead: if (.not. allocated(x)) ... ASIN: see ACOS ASSOCIATED: Is it still possible that association status of a pointer is undefined? I thought Fortran 95 solved that monstrum? If I understand it correctly, the return value of associated(p,a) is always false if a is a zero-sized array? BIT_SIZE: ... by the type of I. _The result bit_size() is independent of the actual value of I._ BTEST: ... I is set. The counting of the bits starts at 0. CHDIR: does it change the disk drive on Windows automatically? So that CALL CHDIR( "C:/" ) succeeds? COSH: for real argument x, cosh(x) >= 1 COUNT: scaler -> scalar. The range formatting is wrong: 1/leqDIM/leqn Note: scaler occurs more often, and the range formatting too CSHIFT: range formatting wrong, "scaler" DIGITS: significant _binary_ digits DOT_PRODUCT: "scaler" EOSHIFT: "scaler" (2x) and range formatting EPSILON: replace by: EPSILON(X) returns the smallest number E of the same kind as X such that 1+E is not equal to 1. GET_COMMAND_ARGUMENT: Is LENGTH independent of the buffer used (so that you can use it to check that all of the argument was retrieved)? retrival -> retrieval positiv -> positive GMTIME: This is missing a reference to the standard routine DATE_AND_TIME (I think it would be good to mention the standard routi
[Bug target/37520] junk `(,%eax,4)' after expression / suffix or operands invalid for `lea' for libstdc++ deque/init-list.cc
--- Comment #5 from gerald at pfeifer dot com 2008-09-21 10:15 --- Uros, looking at this again, after manually changing leal$_48(,%eax,4), %eax to leal_48(,%eax,4), %eax things build again with the label being defined as .type $_48, @object .size $_48, 12 $_48: and used like cmpl$$_48+12, %eax without problems. Do you believe this is a bug for leal in the older version of binutils (2.15) FreeBSD ships? I am surprised that it works when I remove the $. I am not a gcc/config expert but can give NO_DOLLAR_IN_LABEL a try. However, will this change ABI? That is, if I know enable this in GCC, how will this interact with an existing (FreeBSD) system where libraries likely have been built with a system compiler that does not have this set? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37520
[Bug bootstrap/37606] New: builtins.c: 6 * set but not used
Hello there,
I just tried to bootstrap the most recent snapshot of gcc version
4.4, dated 20080919, with the Intel C compiler.
The Intel compiler said
../../src/gcc-4.4-20080919/gcc/builtins.c(1856): warning #593: variable
"before_call" was set but never used
../../src/gcc-4.4-20080919/gcc/builtins.c(2856): warning #593: variable "val"
was set but never used
../../src/gcc-4.4-20080919/gcc/builtins.c(5201): warning #593: variable "c" was
set but never used
../../src/gcc-4.4-20080919/gcc/builtins.c(11943): warning #593: variable "dest"
was set but never used
../../src/gcc-4.4-20080919/gcc/builtins.c(11943): warning #593: variable "flag"
was set but never used
../../src/gcc-4.4-20080919/gcc/builtins.c(1201): warning #593: variable
"apply_args_reg_offset" was set but never used
Here is a patch to shut up the compiler
--- gcc/builtins.c.sav 2008-09-21 09:28:51.0 +0100
+++ gcc/builtins.c 2008-09-21 09:32:03.0 +0100
@@ -1194,12 +1194,6 @@
INCOMING_REGNO gives the corresponding inbound register. */
static enum machine_mode apply_result_mode[FIRST_PSEUDO_REGISTER];
-/* For each register that may be used for calling a function, this
- gives the offset of that register into the block returned by
- __builtin_apply_args. 0 indicates that the register is not
- used for calling a function. */
-static int apply_args_reg_offset[FIRST_PSEUDO_REGISTER];
-
/* Return the size required for the block returned by __builtin_apply_args,
and initialize apply_args_mode. */
@@ -1232,14 +1226,12 @@
align = GET_MODE_ALIGNMENT (mode) / BITS_PER_UNIT;
if (size % align != 0)
size = CEIL (size, align) * align;
- apply_args_reg_offset[regno] = size;
size += GET_MODE_SIZE (mode);
apply_args_mode[regno] = mode;
}
else
{
apply_args_mode[regno] = VOIDmode;
- apply_args_reg_offset[regno] = 0;
}
}
return size;
@@ -1853,7 +1845,7 @@
expand_builtin_mathfn (tree exp, rtx target, rtx subtarget)
{
optab builtin_optab;
- rtx op0, insns, before_call;
+ rtx op0, insns;
tree fndecl = get_callee_fndecl (exp);
enum machine_mode mode;
bool errno_set = false;
@@ -1958,7 +1950,7 @@
end_sequence ();
}
- before_call = get_last_insn ();
+ get_last_insn ();
return expand_call (exp, target, target == const0_rtx);
}
@@ -2853,15 +2845,12 @@
static rtx
expand_powi (rtx x, enum machine_mode mode, HOST_WIDE_INT n)
{
- unsigned HOST_WIDE_INT val;
rtx cache[POWI_TABLE_SIZE];
rtx result;
if (n == 0)
return CONST1_RTX (mode);
- val = (n < 0) ? -n : n;
-
memset (cache, 0, sizeof (cache));
cache[1] = x;
@@ -5198,12 +5187,11 @@
static rtx
expand_builtin_expect (tree exp, rtx target)
{
- tree arg, c;
+ tree arg;
if (call_expr_nargs (exp) < 2)
return const0_rtx;
arg = CALL_EXPR_ARG (exp, 0);
- c = CALL_EXPR_ARG (exp, 1);
target = expand_expr (arg, target, VOIDmode, EXPAND_NORMAL);
/* When guessing was done, the hints should be already stripped away. */
@@ -11940,7 +11928,7 @@
static void
maybe_emit_sprintf_chk_warning (tree exp, enum built_in_function fcode)
{
- tree dest, size, len, fmt, flag;
+ tree size, len, fmt;
const char *fmt_str;
int nargs = call_expr_nargs (exp);
@@ -11948,8 +11936,6 @@
if (nargs < 4)
return;
- dest = CALL_EXPR_ARG (exp, 0);
- flag = CALL_EXPR_ARG (exp, 1);
size = CALL_EXPR_ARG (exp, 2);
fmt = CALL_EXPR_ARG (exp, 3);
--
Summary: builtins.c: 6 * set but not used
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
GCC host triplet: suse-linux-x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37606
[Bug fortran/37605] Remarks on user manual for Gfortran
--- Comment #1 from domob at gcc dot gnu dot org 2008-09-21 10:27 --- Hi, thanks for having a look at the manual! This is surely greatly appreciated! (In reply to comment #0) > General remarks > --- > 1. Section on distributing programs is missing: >What is needed if you have created a product to distribute it to >customers? (Either with or without sources) > 2. Section on floating-point issues is missing: >How do the compile options influence the floating-point behaviour? >What is the treatment of special values such as Inf and Nan? >What happens with atan2(0,0)? > 3. POSIX-type extensions in the language reference: >No particular information is given how the various functions >(SYMLNK for instance or STAT) work (or do not work) on a non-POSIX >system like MS Windows. All of those sound good to me (haven't read through your specific remarks, but those are most probably 'obvious' and ok as well). I'll confirm this PR. I'm sure both a patch fixing the missing/superfluous words (or a set of patches to split it up to managable sizes) and patches to add the new documentation mentioned above will be very welcomed. If you need assistance in figuring out the information needed, just ask at [EMAIL PROTECTED] and someone will hopefully help :) -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-21 10:27:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37605
[Bug fortran/37605] Remarks on user manual for Gfortran
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-21 10:31 --- Just one more comment: Thanks for the great list of typos and suggestions; if you want and need help, I can volunteer to fix some of them if I find some time to do so, as this should be trivially possible now with your preparation :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37605
[Bug fortran/37605] Remarks on user manual for Gfortran
--- Comment #3 from arjen dot markus at wldelft dot nl 2008-09-21 10:51 --- Subject: Re: Remarks on user manual for Gfortran > > > --- Comment #2 from domob at gcc dot gnu dot org 2008-09-21 10:31 > --- > Just one more comment: Thanks for the great list of typos and > suggestions; if > you want and need help, I can volunteer to fix some of them if I find some > time > to do so, as this should be trivially possible now with your preparation > :) > > Hi, if you can do that, that would be great - I am quite new to this process and submitting such remarks is much easier than providing the actual patch :). I can try and supply text describing what happens on the Windows platform (that would be merely a matter of writing a small program and checking the effects). Things regarding floating-point and distributing an application are slightly tougher, as they probably involve the properties of the various platforms. Regards, Arjen -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37605
[Bug c/37607] New: ICE in simplify_cond_and_lookup_avail_expr, at tree-ssa-dom.c:2111
gcc-4.1 -O2 -c xx.i xx.i: In function f: xx.i:12: internal compiler error: in simplify_cond_and_lookup_avail_expr, at tree-ssa-dom.c:2111 -- Summary: ICE in simplify_cond_and_lookup_avail_expr, at tree-ssa- dom.c:2111 Product: gcc Version: 4.1.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at jet dot franken dot de GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37607
[Bug c/37607] ICE in simplify_cond_and_lookup_avail_expr, at tree-ssa-dom.c:2111
--- Comment #1 from marcus at jet dot franken dot de 2008-09-21 11:04 --- Created an attachment (id=16371) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16371&action=view) xx.i gcc -O2 -c xx.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37607
[Bug c/37607] ICE in simplify_cond_and_lookup_avail_expr, at tree-ssa-dom.c:2111
--- Comment #2 from marcus at jet dot franken dot de 2008-09-21 11:06 --- Richi says "builtin_object_size emits a wrong -1" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37607
[Bug tree-optimization/37607] ICE in simplify_cond_and_lookup_avail_expr, at tree-ssa-dom.c:2111
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-21 11:30 --- In 4.2 the offending code was removed so we no longer ICE (the "wrong -1" problem remains - casting -1 to size_type_node causes the overflow flag to be set). So, fixed for 4.2.0 - the 4.1 branch is no longer maintained. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC|richard dot guenther at |rguenth at gcc dot gnu dot |gmail dot com |org Status|UNCONFIRMED |RESOLVED Component|c |tree-optimization Known to fail||4.1.3 Known to work||4.2.0 Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37607
[Bug ada/5911] Support for multilib in Ada
--- Comment #23 from guerby at gcc dot gnu dot org 2008-09-21 11:46 --- Subject: Bug 5911 Author: guerby Date: Sun Sep 21 11:45:23 2008 New Revision: 140525 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140525 Log: 2008-09-21 Laurent Guerby <[EMAIL PROTECTED]> PR ada/5911 * gcc-interface/Makefile.in: Add multilib handling for x86_64 and sparc. * system-linux-sparcv9.ads: New file. 2008-09-21 Laurent Guerby <[EMAIL PROTECTED]> Paolo Bonzini <[EMAIL PROTECTED]> PR ada/5911 * Makefile.in (all, install, mostlyclean, clean, distclean): Add multilib handling. * configure.ac: Add multilib handling. * configure: Regenerate. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Makefile.in trunk/libada/ChangeLog trunk/libada/Makefile.in trunk/libada/configure trunk/libada/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5911
[Bug ada/37604] Suboptimal code generation for volatile access
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-21 12:20 --- We don't try to optimize volatile accesses. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37604
[Bug bootstrap/37606] builtins.c: 6 * set but not used
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-21 12:22 --- Thanks for the patch. Please post it to gcc-patches@ with a changelog entry and state how you tested it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37606
[Bug ada/37604] Suboptimal code generation for volatile access
--- Comment #2 from sam at gcc dot gnu dot org 2008-09-21 12:23 --- Well, in the second example I give (variable declared in the same compilation unit), the access is optimized. What I don't get is the difference between both cases, while the compiler does have the same information at its disposal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37604
[Bug ada/5911] Support for multilib in Ada
--- Comment #24 from laurent at guerby dot net 2008-09-21 12:36 --- To use Ada multilib with gnatmake: export FLAGS="-m32"; gnatmake $FLAGS --RTS=$(gcc -print-multi-directory $FLAGS) -f main.adb -- laurent at guerby dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5911
[Bug middle-end/18071] [4.2/4.3/4.4 Regression] -Winline does not respect -fno-default-inline
--- Comment #38 from steven at gcc dot gnu dot org 2008-09-21 13:07 --- Fixed by Honza's patch. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug rtl-optimization/33828] Issues with code hoisting implementation in gcse.c
--- Comment #12 from steven at gcc dot gnu dot org 2008-09-21 13:13 --- . -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33828
[Bug rtl-optimization/33356] Incomplete documentation of REG_RETVAL and REG_LIBCALL notes
--- Comment #2 from steven at gcc dot gnu dot org 2008-09-21 13:13 --- libcall notes are no more... -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33356
[Bug rtl-optimization/16967] Iterating gcse.c CPROP and PRE does not reach a fixed point
--- Comment #14 from steven at gcc dot gnu dot org 2008-09-21 13:14 --- I can reproduce this on-and-off, but never with a reasonable test case. It's unlikely that anyone is interested in fixing this, esp. given that RTL PRE/CPROP are doing less and less these days as the tree optimizers improve. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
[Bug tree-optimization/37574] [4.4 Regression] ICE with the vectorizer and GC
-- dorit at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dorit at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-09-19 14:12:43 |2008-09-21 13:17:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37574
[Bug tree-optimization/37574] [4.4 Regression] ICE with the vectorizer and GC
--- Comment #3 from dorit at gcc dot gnu dot org 2008-09-21 13:18 --- happens during outer-loop vectorization. I'm looking into it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37574
[Bug middle-end/35413] [meta-bug] Remaining issues blocking the removal of libcall notes from the compiler
--- Comment #2 from steven at gcc dot gnu dot org 2008-09-21 13:19 --- Libcall blocks are no more. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35413
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
--- Comment #9 from steven at gcc dot gnu dot org 2008-09-21 13:21 --- Andreas, could you adopt the patch of comment #4 and see if it still fixes this bug? -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|kazu at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201
[Bug c++/37590] g++ should emit different debug info for variable's type
--- Comment #4 from dodji at gcc dot gnu dot org 2008-09-21 13:28 --- What if gcc always outputs the fully qualified type name ? Today's DWARF supports the DW_TAG_imported_module tag that should let the debugger know that a "using namespace std;" was present in the lexical block enclosing the variable declaration that we are considering. So with those two pieces of informations (fully qualified type name and the using directive), I believe the debugger should be able to display the correct thing to the user. Woud that make sense ? -- dodji at gcc dot gnu dot org changed: What|Removed |Added CC||dodji at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37590
[Bug ada/5911] Support for multilib in Ada
--- Comment #25 from ebotcazou at gcc dot gnu dot org 2008-09-21 13:31 --- > To use Ada multilib with gnatmake: > > export FLAGS="-m32"; gnatmake $FLAGS --RTS=$(gcc -print-multi-directory > $FLAGS) > -f main.adb We should try and eliminate one of the redundant $FLAGS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5911
[Bug fortran/23169] INTENT information not used in the middle-end for optimizations
--- Comment #5 from steven at gcc dot gnu dot org 2008-09-21 13:36 --- A C equivalent test case "works". Once the infamous multiple-decls-per-function issue in gfortran is fixed, this bug probably will disappear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169
[Bug target/12395] Suboptimal code with global variables
--- Comment #13 from steven at gcc dot gnu dot org 2008-09-21 13:49 --- Re. comment #12 I don't see how PRE for globals would make a difference here. In any case, AFAIU tree PRE for globals should now work, and we still don't produce any better code. The output of today (4.4.0 20080921) is still the same as that of comment #0. -- steven at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-02-11 00:52:36 |2008-09-21 13:49:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12395
[Bug target/12395] Suboptimal code with global variables
--- Comment #14 from steven at gcc dot gnu dot org 2008-09-21 13:52 ---
Here is the .final_cleanup dump, fwiw:
;; Function foo (foo)
foo ()
{
int a.1;
:
a.1 = a + 1;
a = a.1;
if (a.1 != 0)
goto ;
else
goto ;
:
a = [plus_expr] a.1 + 1;
:
return;
}
which translates (on Cygwin) to:
.file "t.c"
.text
.p2align 4,,15
.globl _foo
.def_foo; .scl2; .type 32; .endef
_foo:
movl_a, %edx
leal1(%edx), %eax
movl%eax, _a
testl %eax, %eax
je L3
addl$2, %edx
movl%edx, _a
L3:
rep
ret
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2008-09-21 13:49:47 |2008-09-21 13:52:33
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12395
[Bug tree-optimization/18046] Missed jump threading optimization
--- Comment #12 from steven at gcc dot gnu dot org 2008-09-21 13:58 ---
tree PRE now *does* handle the partially redundant global variable load. This
is the .final_cleanup dump:
;; Function bar (bar)
bar ()
{
int prephitmp.13;
:
prephitmp.13 = i;
switch (prephitmp.13) , case 0: >
:
foo ();
prephitmp.13 = i;
:
switch (prephitmp.13) , case 0: >
:
foo (); [tail call]
:
return;
}
But we still miss the jump threading opportunity.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18046
[Bug middle-end/37608] New: [4.4 Regression] libgcc2.c:1981: ICE: vector VEC(m em_ref_p,base) index domain error, in create_vop_ref_mapping_loop at tree-ssa-lo op-im.c:1519
The following error has occurred since I defined IRA_COVER_CLASSES on the hppa64-hp-hpux11.11: /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/g cc-4.4.0/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.4.0/hppa64-hp-hpux11.11 /lib/ -isystem /opt/gnu64/gcc/gcc-4.4.0/hppa64-hp-hpux11.11/include -isystem /op t/gnu64/gcc/gcc-4.4.0/hppa64-hp-hpux11.11/sys-include -g -O2 -O2 -g -O2 -DIN_GC C -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qua l -Wold-style-definition -isystem ./include -fPIC -Dpa64=1 -DELF=1 -mlong-call s -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.. /./gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gc c -I../../../gcc/libgcc/../include -DHAVE_CC_TLS -o __gcc_bcmp.o -MT __gcc_bcmp .o -MD -MP -MF __gcc_bcmp.dep -DL__gcc_bcmp -c ../../../gcc/libgcc/../gcc/libgcc 2.c \ -fvisibility=hidden -DHIDE_EXPORTS ../../../gcc/libgcc/../gcc/libgcc2.c: In function '__gcc_bcmp': ../../../gcc/libgcc/../gcc/libgcc2.c:1981: internal compiler error: vector VEC(m em_ref_p,base) index domain error, in create_vop_ref_mapping_loop at tree-ssa-lo op-im.c:1519 -bash-3.2$ ./xgcc -B./ -v Reading specs from ./specs Target: hppa64-hp-hpux11.11 Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu64/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --disable-nls --with-local-prefix=/opt/gnu64 --prefix=/opt/gnu64/gcc/gcc-4.4.0 --build=hppa64-hp-hpux11.11 --enable-threads=posix --disable-libmudflap --with-gmp=/opt/gnu64/gcc/gcc-4.4.0 --enable-languages=c Thread model: posix gcc version 4.4.0 20080921 (experimental) [trunk revision 140520] (GCC) I know that create_vop_ref_mapping_loop is miscompiled by the stage 1 compiler. Replacing the tree-ssa-loop-im.o objects generated in stage 2 and 3 with the stage 1 object allows bootstrap to complete. Also, changing the function create_vop_ref_mapping_loop from static to global allows a successful bootstrap. -- Summary: [4.4 Regression] libgcc2.c:1981: ICE: vector VEC(m em_ref_p,base) index domain error, in create_vop_ref_mapping_loop at tree-ssa-lo op-im.c:1519 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37608
[Bug middle-end/37608] [4.4 Regression] libgcc2.c:1981: ICE: vector VEC(m em_ref_p,base) index domain error, in create_vop_ref_mapping_loop at tree-ssa-lo op-im.c:1519
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37608
[Bug ada/5911] Support for multilib in Ada
--- Comment #26 from laurent at guerby dot net 2008-09-21 14:27 --- Paolo suggested: "Yes, you would basically take from gcc.c the code that turns "-m32" into "use multilib 32", and use it to make a --RTS option." I think Paolo said there might be some cleanup to do to gcc.c first but I can't find the reference. %I handling by gcc.c is also of interest and might be copied to gnat1 invocation. I believe you should open another PR about multilib and gnattools friendly command lines to follow up on this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5911
[Bug ada/5911] Support for multilib in Ada
--- Comment #27 from bonzini at gnu dot org 2008-09-21 14:46 --- Subject: Re: Support for multilib in Ada > I think Paolo said there might be some cleanup to do to gcc.c first but I > can't > find the reference. %I handling by gcc.c is also of interest and might be > copied to gnat1 invocation. Yes, there is code in gcc.c that understands multilib, and we should avoid duplicating it into gnat. Factoring it in a separate file would be nice. > I believe you should open another PR about multilib and gnattools friendly > command lines to follow up on this. Agreed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5911
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- Comment #22 from pepalogik at seznam dot cz 2008-09-21 15:02 --- I'm probably not the one who'll find the core of the bug but I'd like to mention two simple facts: 1: mingw-w64-bin_i686-mingw_20080707 WORKS 2: mingw-w64-bin_x86_64-mingw_20080724 DOESN'T WORK (Vista64 SP1) I don't use it currently so I haven't tried new versions. Btw. I think it's GCC v. 4.4.0 (experimental) instead of 4.3.0. -- pepalogik at seznam dot cz changed: What|Removed |Added CC||pepalogik at seznam dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
[Bug fortran/35846] ICE on nested character constructors
--- Comment #6 from domob at gcc dot gnu dot org 2008-09-21 15:35 --- Subject: Bug 35846 Author: domob Date: Sun Sep 21 15:33:37 2008 New Revision: 140529 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140529 Log: 2008-09-21 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/35846 * trans.h (gfc_conv_string_length): New argument `expr'. * trans-expr.c (flatten_array_ctors_without_strlen): New method. (gfc_conv_string_length): New argument `expr' that is used in a new special case handling if cl->length is NULL. (gfc_conv_subref_array_arg): Pass expr to gfc_conv_string_length. * trans-array.c (gfc_conv_expr_descriptor): Ditto. (gfc_trans_auto_array_allocation): Pass NULL as new expr. (gfc_trans_g77_array), (gfc_trans_dummy_array_bias): Ditto. (gfc_trans_deferred_array): Ditto. (gfc_trans_array_constructor): Save and restore old values of globals used for bounds checking. * trans-decl.c (gfc_trans_dummy_character): Ditto. (gfc_trans_auto_character_variable): Ditto. 2008-09-21 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/35846 * gfortran.dg/nested_array_constructor_1.f90: New test. * gfortran.dg/nested_array_constructor_2.f90: New test. * gfortran.dg/nested_array_constructor_3.f90: New test. * gfortran.dg/nested_array_constructor_4.f90: New test. * gfortran.dg/nested_array_constructor_5.f90: New test. * gfortran.dg/nested_array_constructor_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/nested_array_constructor_1.f90 trunk/gcc/testsuite/gfortran.dg/nested_array_constructor_2.f90 trunk/gcc/testsuite/gfortran.dg/nested_array_constructor_3.f90 trunk/gcc/testsuite/gfortran.dg/nested_array_constructor_4.f90 trunk/gcc/testsuite/gfortran.dg/nested_array_constructor_5.f90 trunk/gcc/testsuite/gfortran.dg/nested_array_constructor_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35846
[Bug fortran/35846] ICE on nested character constructors
--- Comment #7 from domob at gcc dot gnu dot org 2008-09-21 15:36 --- Fixed on trunk. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35846
[Bug c/37609] New: Pointer arithmetic yields strange result
An expression using ptr arithmetic yields an unusual result unless a cast is applied; The problematic expression; MaxTimings = ((EDIDDetailed *) &pExt->checksum) - pDTD; works only when cast as; MaxTimings = (((uintptr_t) &pExt->checksum) - ((uintptr_t) pDTD))/sizeof(*pDTD); This occurs on compilers back to 3.0.3 when testing on a x86. It's also present in a cross compiler built using 4.3.0 source Works on a Sun/Solaris compiler. A test program is attached -- Summary: Pointer arithmetic yields strange result Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: john dot spelis at 3dlabs dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37609
[Bug c/37609] Pointer arithmetic yields strange result
--- Comment #1 from john dot spelis at 3dlabs dot com 2008-09-21 16:01 --- Created an attachment (id=16372) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16372&action=view) A standalone program which illustrates the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37609
[Bug target/37610] New: [4.4 Regression] FAIL: g++.dg/eh/pr29166.C execution test
Executing on host: /home/dave/gcc-4.4/objdir/gcc/testsuite/g++/../../g++ -B/home /dave/gcc-4.4/objdir/gcc/testsuite/g++/../../ /home/dave/gcc-4.4/gcc/gcc/testsui te/g++.dg/eh/pr29166.C -nostdinc++ -I/home/dave/gcc-4.4/objdir/hppa-linux/libst dc++-v3/include/hppa-linux -I/home/dave/gcc-4.4/objdir/hppa-linux/libstdc++-v3/i nclude -I/home/dave/gcc-4.4/gcc/libstdc++-v3/libsupc++ -I/home/dave/gcc-4.4/gcc/ libstdc++-v3/include/backward -I/home/dave/gcc-4.4/gcc/libstdc++-v3/testsuite/ut il -fmessage-length=0 -ansi -pedantic-errors -Wno-long-long -L/home/dave/gc c-4.4/objdir/hppa-linux/./libstdc++-v3/src/.libs -L/home/dave/gcc-4.4/objdir/hp pa-linux/./libstdc++-v3/src/.libs -L/home/dave/gcc-4.4/objdir/hppa-linux/./libib erty -lm -o ./pr29166.exe(timeout = 300) PASS: g++.dg/eh/pr29166.C (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/dave/gcc-4.4/objdir/hppa-linux/./libstdc++-v3 /src/.libs:/home/dave/gcc-4.4/objdir/hppa-linux/./libstdc++-v3/src/.libs:/home/d ave/gcc-4.4/objdir/gcc:.:/home/dave/gcc-4.4/objdir/hppa-linux/./libstdc++-v3/src /.libs:/home/dave/gcc-4.4/objdir/hppa-linux/./libstdc++-v3/src/.libs:/home/dave/ gcc-4.4/objdir/gcc:/home/dave/gcc-4.4/objdir/hppa-linux/libstdc++-v3/.libs:/home /dave/gcc-4.4/objdir/hppa-linux/libmudflap/.libs:/home/dave/gcc-4.4/objdir/hppa- linux/libssp/.libs:/home/dave/gcc-4.4/objdir/hppa-linux/libgomp/.libs:/home/dave /gcc-4.4/objdir/./gcc:/home/dave/gcc-4.4/objdir/./prev-gcc FAIL: g++.dg/eh/pr29166.C execution test The program segvs: Breakpoint 2, 0x402afd30 in _Unwind_DeleteException (exc=) at ../../../gcc/libgcc/../gcc/unwind.inc:276 276 (*exc->exception_cleanup) (_URC_FOREIGN_EXCEPTION_CAUGHT, exc); Current language: auto; currently c (gdb) bt #0 0x402afd30 in _Unwind_DeleteException (exc=) at ../../../gcc/libgcc/../gcc/unwind.inc:276 #1 0x00012558 in test () at /home/dave/gcc-4.4/gcc/gcc/testsuite/g++.dg/eh/pr29166.C:86 #2 0x in ?? () (gdb) p/x $r22 $2 = 0x16098 (gdb) stepi 0x402afd34 276 (*exc->exception_cleanup) (_URC_FOREIGN_EXCEPTION_CAUGHT, exc); (gdb) $$dyncall () at ../../../gcc/libgcc/../gcc/config/pa/milli64.S:223 223 bb,>=,n %r22,30,LREF(1) ; branch if not plabel address Current language: auto; currently asm (gdb) 223 bb,>=,n %r22,30,LREF(1) ; branch if not plabel address (gdb) 229 bv %r0(%r22) ; branch to the real target (gdb) 235 stw %r2,-24(%r30) ; save return address into frame marker (gdb) 0x00016098 in ?? () (gdb) Program received signal SIGILL, Illegal instruction. 0x00016098 in ?? () This regression was probably introduced in the recent switch to using assembler CFI directives. -- Summary: [4.4 Regression] FAIL: g++.dg/eh/pr29166.C execution test Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37610
[Bug c/37267] [4.2/4.3/4.4 Regression] #pragma inside structure initialization causes error
--- Comment #5 from joseph at codesourcery dot com 2008-09-21 16:12 --- Subject: Re: [4.2/4.3/4.4 Regression] #pragma inside structure initialization causes error On Sat, 20 Sep 2008, rguenth at gcc dot gnu dot org wrote: > I agree with Jakub. Joseph - are you ok with closing this as invalid? Yes. I think back ends should be able to register non-deferred pragmas, which should be allowed everywhere (and wouldn't reach the parser at all), like the "ident" pragma of the motivating case for this PR, but it's for the person adding such a pragma to add the facilities required. #pragma weak is one I think it is entirely appropriate to allow only at limited places in the grammar rather than trying to define what it means in the middle of a declaration. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37267
[Bug target/37609] Pointer arithmetic yields strange result
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-21 16:29 --- Confirmed. This looks like a target issue to me, for bad we produce testPtrBad: pushl %ebp movl%esp, %ebp movl8(%ebp), %eax addl$127, %eax subl12(%ebp), %eax popl%ebp sarl%eax imull $954437177, %eax, %eax ret -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||uros at gcc dot gnu dot org Status|UNCONFIRMED |NEW Component|c |target Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||3.3.6 4.3.2 Last reconfirmed|-00-00 00:00:00 |2008-09-21 16:29:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37609
Re: [Bug c/37609] New: Pointer arithmetic yields strange result
Sent from my iPhone On Sep 21, 2008, at 9:00 AM, "john dot spelis at 3dlabs dot com" <[EMAIL PROTECTED] > wrote: An expression using ptr arithmetic yields an unusual result unless a cast is applied; The problematic expression; MaxTimings = ((EDIDDetailed *) &pExt->checksum) - pDTD; That is a signed division while the below is unsigned. works only when cast as; MaxTimings = (((uintptr_t) &pExt->checksum) - ((uintptr_t) pDTD))/sizeof(*pDTD); This occurs on compilers back to 3.0.3 when testing on a x86. It's also present in a cross compiler built using 4.3.0 source Works on a Sun/Solaris compiler. A test program is attached -- Summary: Pointer arithmetic yields strange result Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: john dot spelis at 3dlabs dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37609
[Bug target/37609] Pointer arithmetic yields strange result
--- Comment #3 from pinskia at gmail dot com 2008-09-21 16:36 --- Subject: Re: New: Pointer arithmetic yields strange result Sent from my iPhone On Sep 21, 2008, at 9:00 AM, "john dot spelis at 3dlabs dot com" <[EMAIL PROTECTED] > wrote: > An expression using ptr arithmetic yields an unusual result > unless a cast is applied; > The problematic expression; > MaxTimings = ((EDIDDetailed *) &pExt->checksum) - pDTD; That is a signed division while the below is unsigned. > > works only when cast as; > MaxTimings = (((uintptr_t) &pExt->checksum) - ((uintptr_t) > pDTD))/sizeof(*pDTD); > > This occurs on compilers back to 3.0.3 when testing on a x86. It's > also present > in a cross compiler built using 4.3.0 source > Works on a Sun/Solaris compiler. > A test program is attached > > > -- > Summary: Pointer arithmetic yields strange result > Product: gcc > Version: 4.3.0 >Status: UNCONFIRMED > Severity: normal > Priority: P3 > Component: c >AssignedTo: unassigned at gcc dot gnu dot org >ReportedBy: john dot spelis at 3dlabs dot com > GCC build triplet: i686-pc-linux-gnu > GCC host triplet: i686-pc-linux-gnu > GCC target triplet: i686-pc-linux-gnu > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37609 > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37609
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- Comment #23 from nightstrike at gmail dot com 2008-09-21 17:06 --- (In reply to comment #22) > I'm probably not the one who'll find the core of the bug but I'd like to > mention two simple facts: Thanks for your feedback! > 1: mingw-w64-bin_i686-mingw_20080707 WORKS > 2: mingw-w64-bin_x86_64-mingw_20080724 DOESN'T WORK > (Vista64 SP1) > > I don't use it currently so I haven't tried new versions. This is because the first one is a cross compiler, while the second is a native compiler. It just happens that you can run a cross compiler on the native system, since Win64 supports running Win32 code. > Btw. I think it's GCC v. 4.4.0 (experimental) instead of 4.3.0. The problem originated in version 4.3.0, and has stayed ever since. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
[Bug testsuite/37202] FAIL: gcc.dg/visibility-1[4-9].c
--- Comment #5 from danglin at gcc dot gnu dot org 2008-09-21 18:31 ---
This is also failing on hppa-unknown-linux-gnu. It uses the define in
elfos.h. assemble_external is not called. It looks like output_operand
is wrong:
output_operand (rtx x, int code ATTRIBUTE_UNUSED)
{
if (x && GET_CODE (x) == SUBREG)
x = alter_subreg (&x);
/* X must not be a pseudo reg. */
gcc_assert (!x || !REG_P (x) || REGNO (x) < FIRST_PSEUDO_REGISTER);
PRINT_OPERAND (asm_out_file, x, code);
if (x && MEM_P (x) && GET_CODE (XEXP (x, 0)) == SYMBOL_REF)
{
tree t;
x = XEXP (x, 0);
t = SYMBOL_REF_DECL (x);
if (t)
assemble_external (t);
}
}
Breakpoint 4, output_operand (x=0x40146480, code=72)
at ../../gcc/gcc/final.c:3365
3365 if (x && GET_CODE (x) == SUBREG)
(gdb) p debug_rtx (x)
(symbol_ref:SI ("foo") [flags 0x42] )
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37202
[Bug testsuite/37202] FAIL: gcc.dg/visibility-1[4-9].c
--- Comment #6 from danglin at gcc dot gnu dot org 2008-09-21 18:53 --- > This is also failing on hppa-unknown-linux-gnu. It uses the define in > elfos.h. assemble_external is not called. It looks like output_operand > is wrong: That rings a bell. I believe H-P's proposed patch fixes this. See http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00195.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37202
ANSI C, type composition, constant arrays in function arguments
According to the ANSI C standard, functions' respective arguments have to be compatible for the function types to be compatible (6.7.5.3). However, the following declarations void p(int p[30]); void p(int p[4]); do not yield a warning. -- Mikoláš Janota M. Sc. School of Computer Science and Informatics, University College Dublin, Belfield, Dublin 4, Ireland
[Bug testsuite/37202] FAIL: gcc.dg/visibility-1[4-9].c
--- Comment #7 from dominiq at lps dot ens dot fr 2008-09-21 19:11 --- On Darwin the patch refered to in comment #6 fixes the weak issues but not the visibility failures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37202
[Bug testsuite/37202] FAIL: gcc.dg/visibility-1[4-9].c
--- Comment #8 from pinskia at gmail dot com 2008-09-21 19:15 --- Subject: Re: FAIL: gcc.dg/visibility-1[4-9].c Sent from my iPhone On Sep 21, 2008, at 12:11 PM, "dominiq at lps dot ens dot fr" <[EMAIL PROTECTED] > wrote: > > > --- Comment #7 from dominiq at lps dot ens dot fr 2008-09-21 > 19:11 --- > On Darwin the patch refered to in comment #6 fixes the weak issues > but not the > visibility failures. As mentioned so many times. These testcases should be disabled for Darwin. > > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37202 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37202
[Bug testsuite/37202] FAIL: gcc.dg/visibility-1[4-9].c
--- Comment #9 from dominiq at lps dot ens dot fr 2008-09-21 19:37 --- > As mentioned so many times. These testcases should be disabled for Darwin. Then who is supposed to do it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37202
[Bug fortran/37597] internal procedure fails to access host-associated module procedure
-- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-21 19:38:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37597
[Bug rtl-optimization/37598] [ira-merge] FAIL: gcc.target/i386/asm-3.c execution test
--- Comment #2 from hjl at gcc dot gnu dot org 2008-09-21 19:56 --- Subject: Bug 37598 Author: hjl Date: Sun Sep 21 19:55:10 2008 New Revision: 140531 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140531 Log: 2008-09-21 H.J. Lu <[EMAIL PROTECTED]> PR rtl-optimization/37598 * ira-lives.c (mark_reg_live, mark_reg_dead): Revert revision 140504. (mark_ref_live, mark_ref_dead): Likewise. (def_conflicts_with_inputs_p): Likewise. (mark_early_clobbers): Likewise. (process_bb_node_lives): Likewise.. Modified: branches/ira-merge/gcc/ChangeLog.ira branches/ira-merge/gcc/ira-lives.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37598
[Bug fortran/37583] ICE "insert_bbt(): Duplicate key" for self-calling ENTRY subprogram
--- Comment #7 from pault at gcc dot gnu dot org 2008-09-21 19:59 --- Subject: Bug 37583 Author: pault Date: Sun Sep 21 19:58:23 2008 New Revision: 140532 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140532 Log: 2008-09-21 Paul Thomas <[EMAIL PROTECTED]> PR fortran/37583 * decl.c (scalarize_intrinsic_call): Both subroutines and functions can give a true for get_proc_mame's last argument so remove the &&gfc_current_ns->proc_name->attr.function. resolve.c (resolve_actual_arglist): Add check for recursion by reference to procedure as actual argument. 2008-09-21 Paul Thomas <[EMAIL PROTECTED]> PR fortran/37583 * gfortran.dg/entry_18.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/entry_18.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37583
[Bug middle-end/37535] [4.4 Regression] gcc/libgcc2.c:404: internal compiler error: Floating point exception
--- Comment #12 from hjl at gcc dot gnu dot org 2008-09-21 19:59 --- Subject: Bug 37535 Author: hjl Date: Sun Sep 21 19:58:24 2008 New Revision: 140533 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140533 Log: 2008-09-21 Richard Sandiford <[EMAIL PROTECTED]> PR rtl-optimization/37535 * ira-lives.c (mark_ref_live): Return bool. (process_bb_node_lives): Only mark the registers dead which have been marked live before without being already live at that point. Modified: branches/ira-merge/gcc/ChangeLog.ira branches/ira-merge/gcc/ira-lives.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37535
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #11 from esigra at gmail dot com 2008-09-21 20:38 --- I found that James' wish is already implemented in some cases: $ strings /usr/i686-pc-linux-gnu/gnat-gcc-bin/4.2/gnat|grep "RM " illegal use of remote access-to-class-wide type, see RM E.4(18) A user that gets that error message can look it up at for example [http://www.adacore.com/multimedia/Ada2005_RM_HTML/RM-E-4.html]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
[Bug fortran/37498] [4.4 Regression] Incorrect array value returned - 4.3 ABI Broken
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2008-09-21 21:18 --- Final patch submitted to list for approval: http://gcc.gnu.org/ml/fortran/2008-09/msg00364.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37498
[Bug testsuite/37202] FAIL: gcc.dg/visibility-1[4-9].c
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2008-09-21 21:45 --- Dominique, Just post a proposed patch to gcc-patches that disables these tests and cc the original author of the tests and one of the current Darwin maintainers such as Mike Stump. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37202
[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences
--- Comment #29 from kkojima at gcc dot gnu dot org 2008-09-21 22:38 --- Subject: Bug 33642 Author: kkojima Date: Sun Sep 21 22:37:16 2008 New Revision: 140534 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140534 Log: PR rtl-optimization/33642 * gcc.c-torture/compile/pr11832.c: XFAIL on sh*-*-*. * gcc.c-torture/compile/pr33009.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/compile/pr11832.c trunk/gcc/testsuite/gcc.c-torture/compile/pr33009.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
Re: ANSI C, type composition, constant arrays in function arguments
"Mikoláš Janota" <[EMAIL PROTECTED]> writes: > However, the following declarations > void p(int p[30]); > void p(int p[4]); > > do not yield a warning. See 6.7.5.3#7. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: ANSI C, type composition, constant arrays in function arguments
Thanks Andreas pointing me to part of the standard that I have missed. However, is it crystal clear in the following parts of the document we are talking about parameters and a return type *after adjustment*? To be honest, I would still vote for at least a warning. After all, what is the point of writing a constant size for an array parameter if the typechecker throws it away? mikolas 2008/9/22 Andreas Schwab <[EMAIL PROTECTED]>: > "Mikoláš Janota" <[EMAIL PROTECTED]> writes: > >> However, the following declarations >> void p(int p[30]); >> void p(int p[4]); >> >> do not yield a warning. > > See 6.7.5.3#7. > > Andreas. > > -- > Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] > SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany > PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different." > -- Mikoláš Janota M. Sc. School of Computer Science and Informatics, University College Dublin, Belfield, Dublin 4, Ireland
[Bug rtl-optimization/37598] [ira-merge] FAIL: gcc.target/i386/asm-3.c execution test
--- Comment #3 from hjl dot tools at gmail dot com 2008-09-22 00:25 --- Fixed. Revision 140533 is OK. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37598
[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c
--- Comment #81 from hp at gcc dot gnu dot org 2008-09-22 01:55 --- Subject: Bug 37170 Author: hp Date: Mon Sep 22 01:54:03 2008 New Revision: 140539 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140539 Log: PR middle-end/37170 PR middle-end/37280 * final.c (mark_symbol_ref_as_used): New helper function. (output_operand): Instead of just looking inside MEMs for SYMBOL_REFs, use new helper function and for_each_rtx. * varasm.c (assemble_external): Move #ifndef ASM_OUTPUT_EXTERNAL to after weak-handling. Don't mark decls with TREE_STATIC as weak. Make head comment more general. * config/darwin.c (machopic_output_indirection): Handle weak references here, like in assemble_external. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.c trunk/gcc/final.c trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
[Bug middle-end/37280] [4.4 Regression] weak symbol regression breaks linux kernel
--- Comment #11 from hp at gcc dot gnu dot org 2008-09-22 01:55 --- Subject: Bug 37280 Author: hp Date: Mon Sep 22 01:54:03 2008 New Revision: 140539 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140539 Log: PR middle-end/37170 PR middle-end/37280 * final.c (mark_symbol_ref_as_used): New helper function. (output_operand): Instead of just looking inside MEMs for SYMBOL_REFs, use new helper function and for_each_rtx. * varasm.c (assemble_external): Move #ifndef ASM_OUTPUT_EXTERNAL to after weak-handling. Don't mark decls with TREE_STATIC as weak. Make head comment more general. * config/darwin.c (machopic_output_indirection): Handle weak references here, like in assemble_external. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.c trunk/gcc/final.c trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37280
[Bug middle-end/37280] [4.4 Regression] weak symbol regression breaks linux kernel
--- Comment #12 from hp at gcc dot gnu dot org 2008-09-22 01:56 --- Subject: Bug 37280 Author: hp Date: Mon Sep 22 01:54:41 2008 New Revision: 140540 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140540 Log: PR middle-end/37170 PR middle-end/37280 * gcc.dg/weak/weak-15.c, gcc.dg/weak/weak-16.c, g++.dg/ext/inline1.C: New tests. Added: trunk/gcc/testsuite/g++.dg/ext/inline1.C trunk/gcc/testsuite/gcc.dg/weak/weak-15.c trunk/gcc/testsuite/gcc.dg/weak/weak-16.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37280
[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c
--- Comment #82 from hp at gcc dot gnu dot org 2008-09-22 01:56 --- Subject: Bug 37170 Author: hp Date: Mon Sep 22 01:54:41 2008 New Revision: 140540 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140540 Log: PR middle-end/37170 PR middle-end/37280 * gcc.dg/weak/weak-15.c, gcc.dg/weak/weak-16.c, g++.dg/ext/inline1.C: New tests. Added: trunk/gcc/testsuite/g++.dg/ext/inline1.C trunk/gcc/testsuite/gcc.dg/weak/weak-15.c trunk/gcc/testsuite/gcc.dg/weak/weak-16.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c
--- Comment #83 from hp at gcc dot gnu dot org 2008-09-22 02:06 --- committed -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
[Bug middle-end/37280] [4.4 Regression] weak symbol regression breaks linux kernel
--- Comment #13 from hp at gcc dot gnu dot org 2008-09-22 02:12 --- (In reply to comment #10) > (In reply to comment #9) > > ".weak symbol" can be emitted, but with two same lines. Thanks! > So that would bring you into the same situation as PR31537 is in (FE emits > duplicate asm directives, quick workaround in the BE for weakrefs is attached > to PR31537). Pre-existing wart. Better use a hashtable than a linked list (i.e. tree) for weak_decls. I suggest opening a separate PR for that; this one's now FIXED. -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37280
[Bug middle-end/37608] [4.4 Regression] libgcc2.c:1981: ICE: vector VEC(m em_ref_p,base) index domain error, in create_vop_ref_mapping_loop at tree-ssa-lo op-im.c:1519
--- Comment #1 from danglin at gcc dot gnu dot org 2008-09-22 02:52 ---
After looking at this a bit, the problem seems to be in the register
allocation for this bit of code:
0x405da2a8 : ldo 1(r4),ret0
0x405da2ac : extrd,u r17,62,63,r17
0x405da2b0 : b,l 0x405d9ee0
,r0
0x405da2b4 : extrd,u ret0,63,32,r4
After the last extrd,u, we have
(gdb) p/x $ret0
$5 = 0x8001000e7859
(gdb) p/x $r4
$7 = 0xe7859
The above code corresponds to
static inline void
bmp_iter_next (bitmap_iterator *bi, unsigned *bit_no)
{
bi->bits >>= 1;
*bit_no += 1;
}
The value in r4 is wrong. r4 is used to save and restore the PIC register
across function calls. The PIC register value is
(gdb) p/x $dp
$27 = 0x8001000e7858
Looking back, the last call which isn't inlined is to bitmap_set_bit in
record_vop_access.
0x405da034 : copy dp,r4
0x405da038 : ldd 8(ret0),r15
0x405da03c : copy r9,ret1
0x405da040 : b,l 0x402142c0
,rp
0x405da044 : ldd 10(r11),r26
0x405da048 : copy r4,dp
r4 doesn't change value from this point to the ICE.
I believe r4 is initialized, but it is clobbered by a multitude of calls
after initialization. So, the question is why r4 was used in the first
place. This would seem like another clobber related issue. The PIC
call patterns all use a clobber to reserve r4. However, Richard's patch,
, didn't resolve
the issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37608
[Bug target/37528] [4.4 Regression] boostrap failure due to configure problems
--- Comment #5 from dannysmith at gcc dot gnu dot org 2008-09-22 02:58 --- Subject: Bug 37528 Author: dannysmith Date: Mon Sep 22 02:56:50 2008 New Revision: 140541 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140541 Log: PR target/37528 * config/i386/t-cygming (SHLIB_LC): Remove. (SHLIB_LINK): Don't add static objects to SHLIB_IMPLIB * config/i386/t-cygwin (SHLIB_LC): Specify all required libraries. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/t-cygming trunk/gcc/config/i386/t-cygwin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37528
[Bug middle-end/37608] [4.4 Regression] libgcc2.c:1981: ICE: vector VEC(m em_ref_p,base) index domain error, in create_vop_ref_mapping_loop at tree-ssa-lo op-im.c:1519
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2008-09-22 03:01 --- Subject: Re: [4.4 Regression] libgcc2.c:1981: ICE: vector VEC(m em_ref_p,base) index domain error, in create_vop_ref_mapping_loop at tree-ssa-lo op-im.c:1519 Attached tree-ssa-loop-im.c.174r.ira.bz2. Dave --- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2008-09-22 03:01 --- Created an attachment (id=16373) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16373&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37608
[Bug middle-end/37608] [4.4 Regression] libgcc2.c:1981: ICE: vector VEC(m em_ref_p,base) index domain error, in create_vop_ref_mapping_loop at tree-ssa-lo op-im.c:1519
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2008-09-22 03:02 --- Subject: Re: [4.4 Regression] libgcc2.c:1981: ICE: vector VEC(m em_ref_p,base) index domain error, in create_vop_ref_mapping_loop at tree-ssa-lo op-im.c:1519 Attached tree-ssa-loop-im.s.bz2 generated with stage1 compiler. Dave --- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2008-09-22 03:02 --- Created an attachment (id=16374) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16374&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37608
[Bug target/37528] [4.4 Regression] boostrap failure due to configure problems
-- dannysmith at users dot sourceforge dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot |dot org |sourceforge dot net Status|NEW |ASSIGNED Last reconfirmed|2008-09-16 07:20:01 |2008-09-22 03:04:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37528
[Bug target/37528] [4.4 Regression] boostrap failure due to configure problems
--- Comment #6 from dannysmith at users dot sourceforge dot net 2008-09-22 03:09 --- Fixed at revision 140541. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37528
[Bug target/37584] -ftree-ch causes stack corruption on mingw32
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-09-22 03:23 --- I have run into what I believe is the same bug in build of of cc1plus.exe, with miscompilation of cp/pt.c When exercising cp/pt.c:process_partial_specialization (eg, when compiling libstdc++'s mt_allocator.cc) I get a segfault in cygwin.asm (used in w32 implementation of __builtin_alloca) Adding -fno-tree-ch to CFLAGS for pt.c fixes build of libstdc++ and testsuite results I will try to reduce a testcase when time permits. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-22 03:23:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37584
[Bug target/37381] [4.4 Regression] ICE in ia64_speculate_insn, at config/ia64/ia64.c:6902
--- Comment #7 from abel at gcc dot gnu dot org 2008-09-22 06:20 --- The patch implementing ia64 changes needed for the selective scheduler can be found at http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01669.html. [The first version of the patch with some summary is at http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00117.html. What is changed from that summary is that per Ian's suggestion we call compute_alignments from machine_reorg manually instead of rearranging the pass sequence.] I was going to ping them, but HJ did that first. It is important that we get that in for 4.4, because otherwise selective scheduler will be non-functional on ia64. However, I presume reviewing the changes will take some time, so it could make sense to fix this bug first. The patch for the bug is simple, and it is not a problem to revert it when committing the rest of sel-sched changes. On the sel-sched branch, I have restored the config/ia64/* files to be in line with mainline before merge. I will revert this on a branch in two-three days, so that the sel-sched branch will contain a fully functional selective scheduler on ia64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37381
