[Bug c++/32688] New: Dynamic linking cause static Dtor and Ctor to ran twice on same instance
When two separate Dynamic Shared Objects (DSO's) are using the same static object with the same name and each of them keeps a local copy of that object. When the application gets loaded that objects constructor is called twice for the same instance and the destructor is also called twice when the main application exits. The Ctor is called for each load of the shared object and the Dtor for each close of the library. Regardless that the linker has optimized the instance so there would be one instance and not two. When applying the static prefix the problem is solved but the code is merged and the second linked shared object gets to execute the code of the first one! -- Summary: Dynamic linking cause static Dtor and Ctor to ran twice on same instance Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ranc at mobixell dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32688
[Bug c++/32688] Dynamic linking cause static Dtor and Ctor to ran twice on same instance
--- Comment #1 from ranc at mobixell dot com 2007-07-09 07:07 --- Created an attachment (id=13874) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13874&action=view) gzipped tar ball of a sample code The is the sample code problem, execute from bash the compile.bash script: . compile.bash then execute: ./main -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32688
[Bug c++/32688] Dynamic linking cause static Dtor and Ctor to ran twice on same instance
--- Comment #2 from ranc at mobixell dot com 2007-07-09 07:08 --- Attached is a gzipped tag ball with a sample problem. just execute from bash the compile.bash script and execute ./main . (I use RHEL 4.0) [EMAIL PROTECTED] test]$ g++ --version g++ (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED] test]$ ld --version GNU ld version 2.15.92.0.2 20040927 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32688
[Bug c++/32688] Dynamic linking cause static Dtor and Ctor to ran twice on same instance
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-09 07:12 --- This is not a bug in GCC, you are violating the One Definition Rule which does not need any diagnostic. Actually there are two violations, first the class Common are different between the TUs. Second you have two definitions of cmn which is a global. If you use 4.2.0 and above you can use the attribute hidden applied to classes and objects to get the effect of having a local class/variable to that DSO. Also by the way you forgot to compile the libraries with PIC which could also be causing an issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32688
[Bug c++/32687] Invalid code generation for reading signed negative bitfield value (g++ optimization)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 07:17 --- Works on the trunk correctly. Related to PR 31136. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||31136 Keywords||wrong-code Known to work|3.4.6 |3.4.6 4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32687
[Bug tree-optimization/28920] vectorizer produces vector long long on powerpc-linux-gnu (and vector long on powerpc64)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 07:35 --- Actually the RTL issue was fixed up by subreg2 pass. So closing as fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28920
[Bug middle-end/19452] Not detecting a function does not throw
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-09 07:40 --- Fixed at -O2 but not at -O1 and the code looks worse there too (I think because we disable tail call optimization at -O1). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-09-18 05:13:55 |2007-07-09 07:40:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19452
[Bug fortran/32689] New: [4.3 regression] with SIZE or TRANSFER
Hi, the following snippet program gfcbug67 implicit none type mytype integer, pointer :: i(:) => NULL () end type mytype type(mytype) :: t print *, size (transfer (1, t% i)) end program gfcbug67 fails to compile with: gfcbug67.f90:9.17: print *, size (transfer (1, t% i)) 1 Error: 'array' argument of 'size' intrinsic at (1) must be an array Cheers, -ha -- Summary: [4.3 regression] with SIZE or TRANSFER Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32689
[Bug target/29541] Enable IBM long double format in PowerPC Linux soft float
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-09 08:03 --- This was all fixed in 4.3.0 by a couple of patches, I forget if it was backported to 4.2.x or not. Closing as fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29541
[Bug fortran/22210] gfc_conv_array_initializer weirdness
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-07-09 08:06 --- Ok, I guess I blew looking at this for a year. Too busy with work really :). Anyways maybe next weekend. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22210
[Bug fortran/32682] [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2007-07-09 08:15 --- Note: The program fails with "call sub(c+f())" where c is a parameter and dimensions of c and f are (2,2). If one has dimension(2) it works. Working with 2007-05-08-r124539, failing with 2007-05-09-r124566. The follwing has been checked in during that time: r124550 | pault | 2007-05-08 16:40:58 +0200 (Tue, 08 May 2007) | 7 lines PR 31630 * resolve.c (resolve_symbol): Remove the flagging mechanism from the... r124546 | pault | 2007-05-08 14:45:31 +0200 (Tue, 08 May 2007) | 11 lines PR 31692 * trans-array.c (gfc_conv_array_parameter): Convert full array references to the result of the procedure enclusing the call. r124541 | pault | 2007-05-08 13:58:25 +0200 (Tue, 08 May 2007) | 18 lines PR 29397, PR 29400 * decl.c (add_init_expr_to_sym): Expand a scalar initializer for a parameter array into an array expression with the right shape. * array.c (spec_dimen_size): Remove static attribute. * gfortran.h : Prototype for spec_dimen_size. http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00406.html I think the last-shown commit caused the regression. -- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added CC||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32682
[Bug c/30428] vector float | vector float is accepted
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 08:19 --- Here is a patch for the C front-end: Index: c-typeck.c === --- c-typeck.c (revision 126424) +++ c-typeck.c (working copy) @@ -7881,7 +7898,9 @@ case BIT_XOR_EXPR: if (code0 == INTEGER_TYPE && code1 == INTEGER_TYPE) shorten = -1; - else if (code0 == VECTOR_TYPE && code1 == VECTOR_TYPE) + else if (code0 == VECTOR_TYPE && code1 == VECTOR_TYPE + && !VECTOR_FLOAT_TYPE_P (type0) + && !VECTOR_FLOAT_TYPE_P (type1)) common = 1; break; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30428
[Bug c/30428] vector float | vector float is accepted
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-09 08:24 --- And one for the C++ front-end: Index: typeck.c === --- typeck.c(revision 126424) +++ typeck.c(working copy) @@ -3213,7 +3213,9 @@ case BIT_IOR_EXPR: case BIT_XOR_EXPR: if ((code0 == INTEGER_TYPE && code1 == INTEGER_TYPE) - || (code0 == VECTOR_TYPE && code1 == VECTOR_TYPE)) + || (code0 == VECTOR_TYPE && code1 == VECTOR_TYPE + && !VECTOR_FLOAT_TYPE_P (type0) + && !VECTOR_FLOAT_TYPE_P (type1))) shorten = -1; break; -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-09 08:24:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30428
[Bug c/30427] ~ vector float is accepted
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 08:31 ---
Patch (which needs testing):
Index: c-typeck.c
===
--- c-typeck.c (revision 126424)
+++ c-typeck.c (working copy)
@@ -2825,7 +2825,9 @@
break;
case BIT_NOT_EXPR:
- if (typecode == INTEGER_TYPE || typecode == VECTOR_TYPE)
+ if (typecode == INTEGER_TYPE
+ || (typecode == VECTOR_TYPE
+ && !VECTOR_FLOAT_TYPE_P (TREE_TYPE (arg
{
if (!noconvert)
arg = default_conversion (arg);
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-07-09 08:31:08
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30427
[Bug other/12411] GCC depends on undefined ISO C behavior (order of execution)
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-07-09 08:34 --- >This should be warned by -Wsequence-points. It is kinda of hard to know if the two function calls will be invoked and modify the global state. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12411
[Bug libstdc++/32683] Compiling HPCToolkit causes many errors and warnings using GCC 4.3 (but not prior versions)
--- Comment #3 from pcarlini at suse dot de 2007-07-09 08:43 --- Note that in 4.3 the header dependencies have been streamlined and it's well possible that some projects around are failing to include required headers. Please double check in this light, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32683
[Bug target/31568] ICE with invalid %y operand (inline-asm)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 08:50 --- I have a patch for this when I get back in August. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-09 08:50:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31568
[Bug other/31569] Install's web page has 0.n when it should be either 4.n or 5.n
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 08:51 --- This is still true as of today. -- pinskia 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-07-09 08:51:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31569
[Bug target/31558] ICE with __builtin_vec_splat
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 09:00 ---
Mine, patch (which needs full testing):
Index: config/rs6000/rs6000-c.c
===
--- config/rs6000/rs6000-c.c(revision 126424)
+++ config/rs6000/rs6000-c.c(working copy)
@@ -2417,6 +2417,8 @@
{
tree builtin_type;
builtin_type = rs6000_builtin_type (id);
+ if (t == error_mark_node)
+return false;
if (INTEGRAL_TYPE_P (t) && INTEGRAL_TYPE_P (builtin_type))
return true;
else
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-07-09 09:00:26
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31558
[Bug bootstrap/32690] New: 4.2.1 Bootstrap fails - gcc-4_2-branch/boehm-gc/ltconfig: No such file or directory
gcc version 4.2.1 20070628 make profiledbootstrap ... Configuring in i686-pc-linux-gnu/boehm-gc ... checking for i686-pc-linux-gnu-strip... strip updating cache ./config.cache /bin/sh: /root/downloads/gcc-4_2-branch/boehm-gc/ltconfig: No such file or directory configure: error: libtool configure failed make[1]: *** [configure-target-boehm-gc] Error 1 make[1]: Leaving directory `/opt/gcc-4_2_1-build' make: *** [profiledbootstrap] Error 2 A similar problem existed here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28609 This is what I did: # ls /root/downloads/gcc-4_2-branch/boehm-gc/ltconfig ls: /root/downloads/gcc-4_2-branch/boehm-gc/ltconfig: No such file or directory pwd /opt/gcc-4_2_1-build cd /root/downloads/gcc-4_2-branch/ cp ltconfig boehm-gc cd /opt/gcc-4_2_1-build make profiledbootstrap The configure scripts run and print this a few times (since I changed NOTHING!): /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged ... Then this annoyance: ... make[3]: Entering directory `/opt/gcc-4_2_1-build/libcpp' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/opt/gcc-4_2_1-build/libcpp' make[3]: Entering directory `/opt/gcc-4_2_1-build/libdecnumber' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/opt/gcc-4_2_1-build/libdecnumber' make[3]: Entering directory `/opt/gcc-4_2_1-build/gcc' make[3]: Leaving directory `/opt/gcc-4_2_1-build/gcc' make[2]: Leaving directory `/opt/gcc-4_2_1-build' make[2]: Entering directory `/opt/gcc-4_2_1-build' make[3]: Entering directory `/opt/gcc-4_2_1-build' rm -f stage_current make distclean-stagefeedback make[4]: Entering directory `/opt/gcc-4_2_1-build' rm -rf stagefeedback-* make[4]: Leaving directory `/opt/gcc-4_2_1-build' make[3]: Leaving directory `/opt/gcc-4_2_1-build' So it will be a few hours until I know my fix worked. What is with this "rm -f stage_current" "make distclean-stagefeedback" stuff. Why not just continue where I left off! -- Summary: 4.2.1 Bootstrap fails - gcc-4_2-branch/boehm- gc/ltconfig: No such file or directory Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol 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=32690
[Bug debug/31690] ICE with const __uint128_t and C++ front-end
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 09:03 --- Still happens today: t3.cc:1: internal compiler error: in add_const_value_attribute, at dwarf2out.c:10119 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- pinskia 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-07-09 09:03:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31690
[Bug fortran/32689] [4.3 regression] TRANSFER returns scalar, even if MOLD is an array
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-09 09:10 --- >From docs: RESULT = TRANSFER(SOURCE, MOLD[, SIZE]) The result has the same type as MOLD, with the bit level representation of SOURCE. If SIZE is present, the result is a one-dimensional array of length SIZE. If SIZE is absent but MOLD is an array (of any size or shape), the result is a one- dimensional array of the minimum length needed to contain the entirety of the bitwise representation of SOURCE. If SIZE is absent and MOLD is a scalar, the result is a scalar. Obviously, in this case TRANSFER does not return an "one- dimensional array of the minimum length" but a scalar. Reduced testcase: $> cat pr32689.f90 program gfcbug67 integer :: i(3) print *, size (transfer (1, i)) end program gfcbug67 -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org OtherBugsDependingO||31237 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|i686-pc-linux-gnu | Known to fail||4.3.0 Known to work||4.2.1 Last reconfirmed|-00-00 00:00:00 |2007-07-09 09:10:41 date|| Summary|[4.3 regression] with SIZE |[4.3 regression] TRANSFER |or TRANSFER |returns scalar, even if MOLD ||is an array http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32689
[Bug middle-end/22156] [4.0/4.1/4.2/4.3 Regression] bit-field copying regressed
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-07-09 09:15
---
Here is a new testcase which shows the problem on the trunk on powerpc-darwin:
struct s
{
int i1:1;
int i2:1;
};
void f(struct s *x, struct s *y) { *x = *y; }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22156
[Bug tree-optimization/31996] can't determine dependence between p->a[x+i] and *((int *)p + x + i + 8)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 09:18 --- Confirmed, this is now on the trunk. http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00395.html FAIL: gcc.dg/vect/vect-103.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-103.c scan-tree-dump-times dependence distance modulo vf == 0 1 -- pinskia 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-07-09 09:18:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31996
[Bug tree-optimization/32691] New: fold *(float*)(&complex_float_var) into REALPART_EXPR in when &cfv is in a different statement
Testcase:
float
quantum_real(float _Complex a)
{
float *p = (float *) &a;
return p[0];
}
float
quantum_imag(float _Complex a)
{
float *p = (float *) &a;
return p[1];
}
--- CUT -
Even though the above are optimized at the RTL level, it would be nice if we
could get them optimized at the TREE level also.
We already optimize ((float *) &a)[0] and ((float *) &a)[1] via PR 26134.
This should help libquantum in SPEC 2k6 also.
--
Summary: fold *(float*)(&complex_float_var) into
REALPART_EXPR in when &cfv is in a
different statement
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization, TREE
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
OtherBugsDependingO 26163
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32691
[Bug tree-optimization/32684] Missed tail call with sin/cos and sincos pass
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-09 09:34 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-09 09:34:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32684
[Bug tree-optimization/32685] Missed changing of sin into sinf (likewise for cos to cosf)
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-09 09:36 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-09 09:36:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32685
[Bug tree-optimization/32691] fold *(float*)(&complex_float_var) into REALPART_EXPR in when &cfv is in a different statement
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-09 09:38 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-09 09:38:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32691
[Bug middle-end/32680] unneeded movsbl
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-09 09:50 --- It does: function2: .LFB3: callfunction1 movsbl %al,%eax ret because this is what the C ABI specifies. Now, the stack adjustments are indeed superfluous. And we fail to tailcall as well. The latter is fixed with a patch of mine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32680
[Bug middle-end/32680] fails to tailcall, useless stack adjustment
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-09 09:54 --- So I just applied it and now we get function1: .LFB2: movl$10, %eax ret function2: .LFB3: movqpfunc(%rip), %r11 jmp *%r11 for the indirect call. Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |RESOLVED GCC target triplet||x86_64-*-*, i?86-*-* Keywords||missed-optimization Resolution||FIXED Summary|unneeded movsbl |fails to tailcall, useless ||stack adjustment Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32680
[Bug tree-optimization/32681] ice for legal C code with flags -ffast-math -O3 -ftree-vectorize
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-09 10:00 --- It builds a TRUTH_AND_EXPR with second operand NULL_TREE ... in #1 0x008a3d96 in find_phi_replacement_condition (loop=0x2ac838a04320, bb=0x2ac8389a7480, cond=0x7fff72b2f308, bsi=0x7fff72b2f2f0) at /space/rguenther/src/svn/pointer_plus/gcc/tree-if-conv.c:753 753 *cond = build2 (TRUTH_AND_EXPR, boolean_type_node, 754 *cond, first_edge->aux); where first_edge->aux is NULL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32681
[Bug tree-optimization/32681] ice for legal C code with flags -ffast-math -O3 -ftree-vectorize
--- Comment #4 from ubizjak at gmail dot com 2007-07-09 10:15 ---
(In reply to comment #3)
> where first_edge->aux is NULL.
Looking into it.
Reduced testcase is:
--cut here--
int aa_renderpalette (int p)
{
int y = 42;
int i;
for (i = 0; i < 256; i++)
{
if (y > 255)
y = 255;
if (y < 0)
y = 0;
if (p)
y = (y < p ? 0 : (y > p) * 255 / (255 - 2 * p));
}
return y;
}
--cut here--
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32681
[Bug fortran/31129] No warning on unused parameters
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-09 10:18 ---
Emit a warning if an unused parameter is found (-Wunused/-Wall), currently
regtesting:
Index: trans-decl.c
===
--- trans-decl.c(revision 126478)
+++ trans-decl.c(working copy)
@@ -3035,6 +3035,12 @@
if (sym->attr.dummy && sym->backend_decl != NULL_TREE)
TREE_NO_WARNING(sym->backend_decl) = 1;
}
+ else if (sym->attr.flavor == FL_PARAMETER)
+{
+ if (warn_unused_variable && !sym->attr.referenced)
+ gfc_warning ("unused parameter '%s' declared at %L", sym->name,
+&sym->declared_at);
+}
if (sym->attr.dummy == 1)
{
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
CC||dfranke at gcc dot gnu dot
||org
AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2007-03-17 11:40:46 |2007-07-09 10:18:26
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31129
[Bug tree-optimization/32681] ice for legal C code with flags -ffast-math -O3 -ftree-vectorize
--- Comment #5 from ubizjak at gmail dot com 2007-07-09 10:23 --- It's a copy'n'pasto. Attached patch fixes the failure: Index: tree-if-conv.c === --- tree-if-conv.c (revision 126478) +++ tree-if-conv.c (working copy) @@ -751,7 +751,7 @@ find_phi_replacement_condition (struct l AND it with the incoming bb predicate. */ if (second_edge->aux) *cond = build2 (TRUTH_AND_EXPR, boolean_type_node, - *cond, first_edge->aux); + *cond, second_edge->aux); if (TREE_CODE (*cond) == TRUTH_NOT_EXPR) /* We can be smart here and choose inverted -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-07-09 06:22:52 |2007-07-09 10:23:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32681
[Bug c/32415] libgcc_s not found in library search path with --enable-version-specific-runtime-libs
--- Comment #2 from jwakely dot gcc at gmail dot com 2007-07-09 10:30
---
I'm seeing the same with this configuration:
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: $SRCS/gcc/gcc-4.1.1/configure --prefix=$DEST/gcc/4.1.1-64bit
--with-gnu-as --with-as=$DEST/binutils/2.16.1-64bit/bin/as64 --with-gnu-ld
--with-ld=$DEST/binutils/2.16.1-64bit/bin/ld64 --enable-shared
--enable-threads=posix --enable-languages=c,c++ --disable-checking
--with-system-zlib --enable-__cxa_atexit --enable-version-specific-runtime-libs
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.1
(very long paths substituted for SRCS/DEST for brevity)
libgcc_s cannot be found for either 32-bit (-m32) or 64-bit (-m64) builds,
because the appropriate one of $PREFIX/lib/gcc/x86_64-redhat-linux/{lib,lib64}
isn't in the linker's list of library paths.
This only happens for multi-libbed compilers; for a 32-bit-only compiler on the
same machine there is no problem, because libgcc_s is in the
$PREFIX/lib/gcc/x86_64-redhat-linux/4.1.1 directory, which is always in the
linker's search path.
Exactly the same problem happens with a multi-libbed 4.1.1 with target
sparc64-sun-solaris2.8
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
CC||jwakely dot gcc at gmail dot
||com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32415
[Bug c/32415] libgcc_s not found in library search path with --enable-version-specific-runtime-libs
--- Comment #3 from jwakely dot gcc at gmail dot com 2007-07-09 10:35 --- In reply to comment #2: actually, the sparc64-sun-solaris2.8 problem could be slightly different and I can't confirm it now -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32415
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #6 from aph at gcc dot gnu dot org 2007-07-09 10:36 --- _ZN4java4lang12PosixProcess9queueLockE is defined in the assembly source: .globl _ZN4java4lang12PosixProcess9queueLockE .bss .align 4 .type _ZN4java4lang12PosixProcess9queueLockE, @object .size _ZN4java4lang12PosixProcess9queueLockE, 4 _ZN4java4lang12PosixProcess9queueLockE: .zero 4 So, the question is why the linker is complaining that "a GOT relative relocation must reference a local symbol" since it is defined locally and it should be possible to calculate its offset from the GOT. -- aph at gcc dot gnu dot org changed: What|Removed |Added CC||aph at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug c/32692] New: Inconsistent warning/error with static and non-static declarations
The attached testcase just produces warning or errors (depending on gcc version) for func1, func3 and func5: testwarning.c:5: error: static declaration of func1 follows non-static declaration testwarning.c:3: error: previous declaration of func1 was here testwarning.c:25: error: static declaration of func3 follows non-static declaration testwarning.c:23: error: previous declaration of func3 was here testwarning.c:46: error: static declaration of func5 follows non-static declaration testwarning.c:43: error: previous declaration of func5 was here I'm not sure about any C standard implications here, but now that 'static follows non-static' is an error in newer gcc, I believe the other way round deserves at least a warning to. Noticed this while compiling source code with HP's A.10.32.03 compiler, which warns about all 6 functions on the testcase like this: cc: "testwarning.c", line 53: warning 562: Redeclaration of "func6" with a different storage class specifier: "func6" will have internal linkage. Hope this helps, Franz -- Summary: Inconsistent warning/error with static and non-static declarations Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sirl at gcc dot gnu dot org GCC build triplet: i586-suse-linux GCC host triplet: i586-suse-linux GCC target triplet: i586-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32692
[Bug fortran/31129] No warning on unused parameters
--- Comment #2 from patchapp at dberlin dot org 2007-07-09 12:10 --- Subject: Bug number PR31129 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-07/msg00776.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31129
[Bug c/32693] New: [H8] : ICE: in gen_rtx_SUBREG, at emit-rtl.c:693
Hi,
Compiling following testcase for "h8sx" target with optimization (-O1
onwards), gives ICE (internal compiler error) . The testcase works fine
for other H8 targets.
// Start Of Testcase
===
#include
typedef union
{
unsigned long LONG;
struct
{
unsigned long Year : 14,
Month : 18;
} Bit;
} test;
typedef struct
{
unsigned int year ;
} Date;
unsigned int foo(Date *ptr_Date)
{
Date obj_Date;
test obj_test;
obj_test.LONG = 2000;
obj_Date.year = (unsigned int)obj_test.Bit.Year;
if(ptr_Date!=NULL) *ptr_Date=obj_Date;
return(0);
}
===
// End Of Testcase
--
Summary: [H8] : ICE: in gen_rtx_SUBREG, at emit-rtl.c:693
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Sushil dot Kothawade at kpitcummins dot com
GCC build triplet: i686-pc-linux
GCC host triplet: i686-pc-linux
GCC target triplet: h8300-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32693
[Bug c/32692] Inconsistent warning/error with static and non-static declarations
--- Comment #1 from sirl at gcc dot gnu dot org 2007-07-09 12:15 ---
Since attaching files doesn't seem to work right now, here a copy'n'paste:
extern int func1 (int);
static int func1 (int);
static int func1 (int in)
{
return in;
}
static int func2 (int);
extern int func2 (int);
static int func2 (int in)
{
return in;
}
extern int func3 (int);
static int func3 (int);
int func3 (int in)
{
return in;
}
static int func4 (int);
extern int func4 (int);
int func4 (int in)
{
return in;
}
extern int func5 (int);
static int func5 (int in)
{
return in;
}
static int func6 (int);
int func6 (int in)
{
return in;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32692
[Bug c/32692] Inconsistent warning/error with static and non-static declarations
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-09 12:16 --- I thought we already decided the other way around should not error or warn. >From gcc.dg/local1.c which is testing this exactly: C90 6.1.2.2 [as corrected by TC1], C99 6.2.2: For an identifier declared with the storage-class specifier extern in a scope in which a prior declaration of that identifier is visible, if the prior declaration specifies internal or external linkage, the linkage of the identifier at the later daclaration is the same as the linkage specified at the prior declaration. If no prior declaration is visible, or if the prior declaration specifies no linkage, then the identifer has external linkage. *** This bug has been marked as a duplicate of 14366 *** *** This bug has been marked as a duplicate of 14366 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32692
[Bug c/14366] variable previously declared `static' redeclared `extern' is valid ISO C - 3.4 and 4.0 regression
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-07-09 12:16 --- *** Bug 32692 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||sirl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14366
[Bug other/32499] libstdc++ testsuite fails on platforms without ranlib
--- Comment #12 from pcarlini at suse dot de 2007-07-09 12:35 --- Paolo agreed in private email to work on it (many thanks again!) -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED Component|libstdc++ |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32499
[Bug tree-optimization/32694] New: [4.1/4.2 Regression] ICE in chain_of_csts_start
typedef signed long long int WordS64;
typedef unsigned long long int Word64;
int
foo (Word64 *p)
{
while (1)
{
WordS64 c = 0x1llu;
WordS64 x = *p;
if (c >= 0)
{
if (x > (WordS64) 0x7FFFll - c)
return 6;
}
else if (x < (WordS64) 0x8000ll - c)
return 7;
p++;
}
}
ICEs at -O1 or -O2 in chain_of_csts_start, which is called on
unit size
align 64 symtab 0 alias set 3 precision 64 min max
pointer_to_this >
arg 0 unit size
align 64 symtab 0 alias set -1 precision 64 min max >
var def_stmt
version 6>>
but assumes the argument is SSA_NAME.
--
Summary: [4.1/4.2 Regression] ICE in chain_of_csts_start
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32694
[Bug c++/32658] Supposedly illegal conversion compiles without errors
--- Comment #4 from aribrei at arcor dot de 2007-07-09 12:39 --- I should note that I do NOT want to see this bug fixed. I would prefer to hear that you won't "fix" it at all. So I can exploit this behavior as there is no standards-compliant way of achieving the same results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32658
[Bug tree-optimization/32694] [4.1/4.2 Regression] ICE in chain_of_csts_start
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32694
[Bug tree-optimization/32694] [4.1/4.2 Regression] ICE in chain_of_csts_start
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-09 12:46 --- which target? I cannot reproduce this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32694
[Bug tree-optimization/32695] New: [4.1/4.2 Regression] ICE in chain_of_csts_start
typedef signed long long int WordS64;
typedef unsigned long long int Word64;
int
foo (Word64 *p)
{
while (1)
{
WordS64 c = 0x1llu;
WordS64 x = *p;
if (c >= 0)
{
if (x > (WordS64) 0x7FFFll - c)
return 6;
}
else if (x < (WordS64) 0x8000ll - c)
return 7;
p++;
}
}
ICEs at -O1 or -O2 in chain_of_csts_start, which is called on
unit size
align 64 symtab 0 alias set 3 precision 64 min max
pointer_to_this >
arg 0 unit size
align 64 symtab 0 alias set -1 precision 64 min max >
var def_stmt
version 6>>
but assumes the argument is SSA_NAME.
--
Summary: [4.1/4.2 Regression] ICE in chain_of_csts_start
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32695
[Bug tree-optimization/32696] New: [4.1/4.2 Regression] ICE in chain_of_csts_start
typedef signed long long int WordS64;
typedef unsigned long long int Word64;
int
foo (Word64 *p)
{
while (1)
{
WordS64 c = 0x1llu;
WordS64 x = *p;
if (c >= 0)
{
if (x > (WordS64) 0x7FFFll - c)
return 6;
}
else if (x < (WordS64) 0x8000ll - c)
return 7;
p++;
}
}
ICEs at -O1 or -O2 in chain_of_csts_start, which is called on
unit size
align 64 symtab 0 alias set 3 precision 64 min max
pointer_to_this >
arg 0 unit size
align 64 symtab 0 alias set -1 precision 64 min max >
var def_stmt
version 6>>
but assumes the argument is SSA_NAME.
--
Summary: [4.1/4.2 Regression] ICE in chain_of_csts_start
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32696
[Bug tree-optimization/32694] [4.1/4.2 Regression] ICE in chain_of_csts_start
--- Comment #2 from jakub at gcc dot gnu dot org 2007-07-09 12:52 --- x86_64-linux. Rebuilding gcc 4.2 with --enable-checking yields a verify_stmt failure already after ccp, which changes WordS64D.1870 xD.1876; long long intD.5 D.1879; ... D.1879_7 = 9223372036854775807 - cD.1875_4; if (D.1879_7 < xD.1876_6) goto ; else goto ; into: WordS64D.1870 xD.1876; if ((long long intD.5) xD.1876_6 == 9223372036854775807) goto ; else goto ; which is invalid gimple. But the operands of the comparison had different types of arguments already before. Guess the gimple type system patches cured this on the trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32694
[Bug tree-optimization/32694] [4.1/4.2 Regression] ICE in chain_of_csts_start
--- Comment #3 from jakub at gcc dot gnu dot org 2007-07-09 12:53 --- *** Bug 32695 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32694
[Bug tree-optimization/32695] [4.1/4.2 Regression] ICE in chain_of_csts_start
--- Comment #1 from jakub at gcc dot gnu dot org 2007-07-09 12:53 --- Oops, sorry. *** This bug has been marked as a duplicate of 32694 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32695
[Bug tree-optimization/32696] [4.1/4.2 Regression] ICE in chain_of_csts_start
--- Comment #1 from jakub at gcc dot gnu dot org 2007-07-09 12:54 --- Oops, sorry. *** This bug has been marked as a duplicate of 32694 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32696
[Bug tree-optimization/32694] [4.1/4.2 Regression] ICE in chain_of_csts_start
--- Comment #4 from jakub at gcc dot gnu dot org 2007-07-09 12:54 --- *** Bug 32696 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32694
[Bug fortran/28004] Warn if intent(out) dummy variable is used before being defined
--- Comment #10 from dfranke at gcc dot gnu dot org 2007-07-09 12:56 --- Related: PR31447 - "set intent(out) arguments to uninitialized" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28004
[Bug fortran/31447] set intent(out) arguments to uninitialized
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-09 12:56 --- Related: PR28004 - "Warn if intent(out) dummy variable is used before being defined" -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31447
[Bug tree-optimization/32681] ice for legal C code with flags -ffast-math -O3 -ftree-vectorize
--- Comment #6 from uros at gcc dot gnu dot org 2007-07-09 13:00 --- Subject: Bug 32681 Author: uros Date: Mon Jul 9 13:00:19 2007 New Revision: 126482 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126482 Log: PR tree-optimization/32681 * tree-if-conv.c (find_phi_replacement_condition): Use the condition saved in second_edge->aux when first_bb is a loop header. testsuite/ChangeLog: PR tree-optimization/32681 * gcc.dg/tree-ssa/pr32681.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr32681.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32681
[Bug tree-optimization/32681] ice for legal C code with flags -ffast-math -O3 -ftree-vectorize
--- Comment #7 from uros at gcc dot gnu dot org 2007-07-09 13:11 --- Subject: Bug 32681 Author: uros Date: Mon Jul 9 13:11:22 2007 New Revision: 126483 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126483 Log: PR tree-optimization/32681 * tree-if-conv.c (find_phi_replacement_condition): Use the condition saved in second_edge->aux when first_bb is a loop header. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/tree-if-conv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32681
[Bug c/32692] Inconsistent warning/error with static and non-static declarations
--- Comment #3 from sirl at gcc dot gnu dot org 2007-07-09 13:15 --- Sorry, apparently I forgot to search 'All' bugs instead of just the 'Open' ones yesterday. One question though, how does the func6() part of the testcase relate to all this? For this one there is no 'extern' specifier anywhere, so shouldn't sub-clause 7 of 6.2.2 apply here and thus a warning is justified? 7 If, within a translation unit, the same identifier appears with both internal and external linkage, the behavior is undefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32692
[Bug c++/32697] New: O2 optimizes away assignment
Hi,
I'm using SWIG to combine Java and C++ code. At some point, SWIG generates a
method like this :
1SWIGEXPORT jlong JNICALL Java_com_excentis_products_X_XUpcast(JNIEnv *jenv,
jclass jcls, jlong jarg1) {
jlong baseptr = 0;
(void)jenv;
(void)jcls;
*(Flow **)&baseptr = *(TcpFlow **)&jarg1;
return baseptr;
}
The problem is that the assignment is not executed and the return value is
always zero, when using -O2 optimization. When I disable O2, or add a debug
statement, the value is ok.
I don't like the generated code, but it should work fine.
--
Summary: O2 optimizes away assignment
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Dries dot Decock at excentis dot com
GCC build triplet: i686-pc-linux
GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux i686-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32697
[Bug tree-optimization/32698] New: [4.3 regression] inefficient pointer expression
Taking this example:
int foo(int *p, unsigned int i)
{
return p[i + 1] + p[i + 2] + p[i + 3];
}
produces inefficient code. The problem already starts at tree level, where for
"p[i+1]" an expression like *(p + (i + 1) * 4)) is generated, which is not a
common pointer expression.
Also since this is different from the other generated pointer expression, the
common index expression isn't completely replaced.
An initial discussion about this can be found here:
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00418.html
--
Summary: [4.3 regression] inefficient pointer expression
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zippel at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug tree-optimization/32681] ice for legal C code with flags -ffast-math -O3 -ftree-vectorize
--- Comment #8 from uros at gcc dot gnu dot org 2007-07-09 13:32 --- Subject: Bug 32681 Author: uros Date: Mon Jul 9 13:31:46 2007 New Revision: 126484 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126484 Log: PR tree-optimization/32681 * tree-if-conv.c (find_phi_replacement_condition): Use the condition saved in second_edge->aux when first_bb is a loop header. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/tree-if-conv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32681
[Bug c++/32697] O2 optimizes away assignment
--- Comment #1 from schwab at suse dot de 2007-07-09 13:35 --- Report this to the SWIG maintainers. This is violating the C/C++ aliasing rules. *** This bug has been marked as a duplicate of 21920 *** -- schwab at suse dot de changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32697
[Bug c/21920] aliasing violations
--- Comment #117 from schwab at suse dot de 2007-07-09 13:35 --- *** Bug 32697 has been marked as a duplicate of this bug. *** -- schwab at suse dot de changed: What|Removed |Added CC||Dries dot Decock at excentis ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug tree-optimization/32681] ice for legal C code with flags -ffast-math -O3 -ftree-vectorize
--- Comment #9 from ubizjak at gmail dot com 2007-07-09 13:36 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32681
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-09 13:39 --- With 2.95, 3.3.6 and 3.4.6 I get (for 32bit): foo: pushl %ebp movl %esp,%ebp movl 8(%ebp),%edx movl 12(%ebp),%eax movl %ebp,%esp popl %ebp movl 8(%edx,%eax,4),%ecx addl 4(%edx,%eax,4),%ecx addl 12(%edx,%eax,4),%ecx movl %ecx,%eax ret 4.0.3 and 4.1.2 generate: foo: pushl %ebp movl%esp, %ebp movl12(%ebp), %edx sall$2, %edx addl8(%ebp), %edx movl8(%edx), %eax addl4(%edx), %eax addl12(%edx), %eax leave ret 4.2.0 generates foo: pushl %ebp movl%esp, %ebp movl12(%ebp), %ecx movl8(%ebp), %edx popl%ebp sall$2, %ecx movl4(%ecx,%edx), %eax addl8(%ecx,%edx), %eax addl12(%ecx,%edx), %eax ret while mainline generates foo: pushl %ebp movl%esp, %ebp movl12(%ebp), %ecx movl8(%ebp), %edx pushl %ebx leal0(,%ecx,4), %ebx movl8(%ebx,%edx), %eax addl4(%edx,%ecx,4), %eax addl12(%ebx,%edx), %eax popl%ebx popl%ebp ret 64bit variants of all of the above create foo: .LFB2: leal1(%rsi), %edx leal2(%rsi), %eax addl$3, %esi movl(%rdi,%rax,4), %eax addl(%rdi,%rdx,4), %eax addl(%rdi,%rsi,4), %eax ret Tree dumps (of mainline) 64bit vs. 32bit are: return (*(p + (long unsigned int) (i + 2) * 4) + *(p + (long unsigned int) (i + 1) * 4)) + *(p + (long unsigned int) (i + 3) * 4); unsigned int D.1660; D.1660 = i * 4; return (*(p + (D.1660 + 8)) + *(p + (i + 1) * 4)) + *(p + (D.1660 + 12)); -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|i686-pc-linux-gnu | GCC target triplet||i686-*-* Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2007-07-09 13:39:51 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-09 13:41 --- Created an attachment (id=13875) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13875&action=view) patch With the proposed patch mainline generates again foo: pushl %ebp movl%esp, %ebp movl8(%ebp), %ecx movl12(%ebp), %edx popl%ebp movl8(%ecx,%edx,4), %eax addl4(%ecx,%edx,4), %eax addl12(%ecx,%edx,4), %eax ret and return (*(p + (i + 2) * 4) + *(p + (i + 1) * 4)) + *(p + (i + 3) * 4); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-09 13:42 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-09 13:39:51 |2007-07-09 13:42:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug fortran/32699] New: Global name 'len' at (1) is already being used as a FUNCTION at (2)
When I compile the program listed below I get the message:
al1.f90:4.17:
SUBROUTINE len(i)
1
al1.f90:2.4:
i = len(" ")
2
Error: Global name 'len' at (1) is already being used as a FUNCTION at (2)
For what it's worth:
1. g95, Compaq, and Lahey Fortran do not consider it an error.
2. Declaring len to be INTRINSIC has no effect.
PROGRAM VAL
i = len(" ")
END
SUBROUTINE len(i)
END
--
Summary: Global name 'len' at (1) is already being used as a
FUNCTION at (2)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot a dot richmond at nasa dot gov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32699
[Bug c++/32697] O2 optimizes away assignment
--- Comment #2 from sorenj at us dot ibm dot com 2007-07-09 13:55 --- Please refer to https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1560993&group_id=1645 Long story short - as it stands today: C++ standards team won't change the spec to allow type punning, gcc team won't "fix" code generation if it involves type punning, swig team won't rewrite the code generators to generate ANSI spec compliant code. (The only way to do this by current ANSI spec rules is to memcpy the contents of the pointers themselves from a pointer of one type to a pointer of another type.) Your only solution at this time is to use -fno-strict-aliasing when compiling swig wrapper code. This has been a major headache mainly for package maintainers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32697
[Bug c++/32700] New: O2 optimizes away assignment
Hi,
I'm using SWIG to combine Java and C++ code. At some point, SWIG generates a
method like this :
1SWIGEXPORT jlong JNICALL Java_com_excentis_products_X_XUpcast(JNIEnv *jenv,
jclass jcls, jlong jarg1) {
jlong baseptr = 0;
(void)jenv;
(void)jcls;
*(Flow **)&baseptr = *(TcpFlow **)&jarg1;
return baseptr;
}
The problem is that the assignment is not executed and the return value is
always zero, when using -O2 optimization. When I disable O2, or add a debug
statement, the value is ok.
I don't like the generated code, but it should work fine.
--
Summary: O2 optimizes away assignment
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Dries dot Decock at excentis dot com
GCC build triplet: i686-pc-linux
GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux i686-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32700
[Bug c++/32700] O2 optimizes away assignment
--- Comment #1 from Dries dot Decock at excentis dot com 2007-07-09 14:06 --- Sorry, dup -- Dries dot Decock at excentis dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32700
[Bug c++/32697] O2 optimizes away assignment
--- Comment #3 from Dries dot Decock at excentis dot com 2007-07-09 14:07 --- Thanks for the reply. I will use the -fno-strict-aliasing for now, and hope that the SWIG maintainers will fix this problem in the near future. Thanks again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32697
[Bug tree-optimization/32377] can't determine dependence (source/destination overlap without more than size)
--- Comment #15 from sebpop at gmail dot com 2007-07-09 14:19 --- Subject: Re: can't determine dependence (source/destination overlap without more than size) > I was going to submit the attached patch, but now the analysis fails with > "affine-affine test failed: missing iteration counts" and distance vector is > not built (so the loop in this PR cannot be vectorized even with the addition > of DDR_REVERSED_P). This was caused by your patch to PR 32457 > http://gcc.gnu.org/viewcvs?view=rev&revision=126305. Is there any way to > restore the previous behaviour for this case? > I'll try to fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
[Bug fortran/32157] intrinsic function name conflicts with subroutine if present in the same file
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-07-09 14:25 --- *** Bug 32699 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32157
[Bug fortran/32699] Global name 'len' at (1) is already being used as a FUNCTION at (2)
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-09 14:25 --- *** This bug has been marked as a duplicate of 32157 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32699
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #4 from zippel at gcc dot gnu dot org 2007-07-09 14:40 --- IMHO something like this should be generated: p2 = p + (i * 4); return (*(p2 + 4) + *(p2 + 8) + *(p2 + 12)); Right now not even the (i*4) expression is removed from the last instruction anymore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug fortran/32702] New: crash when printing big character variable
For the code program main character (len=1) :: word word = "dog" print*,"word =",word end program main compiled with U:\vrao\fortran>gfortran -v xbug.f90 Driving: gfortran -v xbug.f90 -lgfortranbegin -lgfortran Using built-in specs. Target: i386-pc-mingw32 Configured with: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --build=i386-pc-mingw32 --disable-shared --enable-libgomp Thread model: win32 gcc version 4.3.0 20070706 (experimental) c:/programs/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/f951.exe xbug.f90 -quiet -dumpbase xbug.f90 -mtune=i386 -auxbase xbug -version -fintrinsic-modules-path c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/finclude -o C:\DOCUME~1\vrao\LOCALS~1\Temp/ccfHwMra.s GNU F95 version 4.3.0 20070706 (experimental) (i386-pc-mingw32) compiled by GNU C version 4.3.0 20070706 (experimental), GMP version 4.2.1, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 as -o C:\DOCUME~1\vrao\LOCALS~1\Temp/cc1pIAXq.o C:\DOCUME~1\vrao\LOCALS~1\Temp/ccfHwMra.s c:/programs/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/collect2.exe -Bdynamic c:/programs/g95/lib/crt2.o c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/crtbegin.o -Lc:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0 -Lc:/programs/gfortran/bin/../lib/gcc -Lc:/programs/g95/lib -Lc:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/../../.. C:\DOCUME~1\vrao\LOCALS~1\Temp/cc1pIAXq.o -lgfortranbegin -lgfortran -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/crtend.o the program on Windows XP prints "word =dog" but then crashes with a pop-up message "a.exe has encountered a problem and needs to close". The program runs fine with the LEN is reduced to 8000. -- Summary: crash when printing big character variable Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32702
[Bug fortran/31129] No warning on unused parameters
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-09 14:57 --- Subject: Bug 31129 Author: dfranke Date: Mon Jul 9 14:56:49 2007 New Revision: 126486 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126486 Log: gcc/fortran: 2007-07-09 Daniel Franke <[EMAIL PROTECTED]> PR fortran/31129 * trans-decl.c (generate_local_decl) Emit a warning if an unused parameter is found. gcc/testsuite: 2007-07-09 Daniel Franke <[EMAIL PROTECTED]> PR fortran/31129 * gfortran.dg/parameter_unused.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/parameter_unused.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31129
[Bug fortran/31129] No warning on unused parameters
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-07-09 14:58 --- Fixed in trunk. Not a regression, no backport. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31129
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-09 15:00 ---
Note that we don't hoist the i*4 or the addition to p to help addressing mode
selection which likes to see the "whole" address.
Of course it shouldn't matter in which form we see the addresses and the same
code should be generated for all, still canonicalization to the same form
makes a difference.
In fact, canonicalizing to
unsigned int D.1656;
:
D.1656 = i * 4;
return (*(p + (D.1656 + 8)) + *(p + (D.1656 + 4))) + *(p + (D.1656 + 12));
as you suggest creates worse assembly (look at the extra shift)
foo:
pushl %ebp
movl%esp, %ebp
movl12(%ebp), %ecx
movl8(%ebp), %edx
popl%ebp
sall$2, %ecx
movl8(%ecx,%edx), %eax
addl4(%ecx,%edx), %eax
addl12(%ecx,%edx), %eax
ret
in fact the above shows that the proper fix would be in the backend (if
there is anything to fix) and making sure we consistently canonicalize
is good enough. Consider the related testcase
int foo(int *p, short *q, char *r, unsigned int i)
{
return p[i + 1] + q[i + 1] + r[i + 1];
}
which in one case is canonicalized to
unsigned int D.1658;
:
D.1658 = i + 1;
return ((int) *(r + D.1658) + *(p + D.1658 * 4)) + (int) *(q + D.1658 * 2);
in the other to
return ((int) *(r + (i + 1)) + *(p + (i * 4 + 4))) + (int) *(q + (i * 2 +
2));
so there is no form that is clearly better to canonicalize to. But the
correct "form" depends on the context (whether it is profitable to either
CSE i * 4 or i + 1).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug fortran/31129] No warning on unused parameters
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-07-09 15:00 --- Closing again. This time, I mean it. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31129
[Bug libfortran/32702] crash when printing big character variable
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-09 15:08 --- Confirmed. Presumely a buffer overflow in the library. If len==8192, valgrind does not report any errors. If len > 8192: ===30988== Invalid write of size 1 ==30988==at 0x4022D8E: memcpy (mc_replace_strmem.c:406) ==30988==by 0x40A26C3: write_character (write.c:1412) ==30988==by 0x40A462B: _gfortrani_list_formatted_write (write.c:1533) ==30988==by 0x409A885: _gfortran_transfer_character (transfer.c:1416) ==30988==by 0x80486FB: MAIN__ (pr32702.f90:4) ==30988==by 0x8048748: main (fmain.c:22) ==30988== Address 0x4229340 is 0 bytes after a block of size 8,296 alloc'd ==30988==at 0x40213D0: malloc (vg_replace_malloc.c:149) ==30988==by 0x40342CC: _gfortrani_get_mem (memory.c:53) ==30988==by 0x40A0BE4: fd_to_stream (unix.c:1048) ==30988==by 0x409F509: _gfortrani_init_units (unit.c:525) ==30988==by 0x4033F73: init (main.c:152) ==30988==by 0x40307DC: (within /h/franke/packages/i686-pc-linux-gnu/gcc/lib/gcc/i686-pc-linux-gnu/4.3.0/libgfortran.so.3.0.0) ==30988==by 0x400D762: call_init (in /lib/ld-2.4.so) ==30988==by 0x400D872: _dl_init (in /lib/ld-2.4.so) ==30988==by 0x400087E: (within /lib/ld-2.4.so) Moving to libfortran, adding Jerry to CC. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org, jvdelisle at gcc dot ||gnu dot org Component|fortran |libfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32702
[Bug libfortran/32702] crash when printing big character variable
-- dfranke 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-07-09 15:10:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32702
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #6 from zippel at gcc dot gnu dot org 2007-07-09 15:27 --- (In reply to comment #5) > as you suggest creates worse assembly (look at the extra shift) > > foo: > pushl %ebp > movl%esp, %ebp > movl12(%ebp), %ecx > movl8(%ebp), %edx > popl%ebp > sall$2, %ecx > movl8(%ecx,%edx), %eax > addl4(%ecx,%edx), %eax > addl12(%ecx,%edx), %eax > ret The cost of this is dependent on the target, so IMO the shift could be propagated back into the address at RTL level. > so there is no form that is clearly better to canonicalize to. Your example is rather artificial and depends on that (i + x) * y is completely eliminated. My main point is still that such expression are far more difficult to translate into proper address operations. To generate addresses targeting a form of (i * x) + y is clearly better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug fortran/32703] New: ICE with [trim(character_variable)]
For the program program array_char implicit none character (len=1) :: x x = "a" print*,[trim(x)] end program array_char compiling on Windows XP with gfortran -v xconcat.f90 produces an ICE: Driving: gfortran -v xconcat.f90 -lgfortranbegin -lgfortran Using built-in specs. Target: i386-pc-mingw32 Configured with: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --build=i386-pc-mingw32 --disable-shared --enable-libgomp Thread model: win32 gcc version 4.3.0 20070706 (experimental) c:/programs/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/f951.exe xconcat.f90 -quiet -dumpbase xconcat.f90 -mtune=i386 -auxbase xconcat -version -fintrinsic-modules-path c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/finclude -o C:\DOCUME~1\vrao\LOCALS~1\Temp/cc8grzTr.s GNU F95 version 4.3.0 20070706 (experimental) (i386-pc-mingw32) compiled by GNU C version 4.3.0 20070706 (experimental), GMP version 4.2.1, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 xconcat.f90: In function 'MAIN__': xconcat.f90:4: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. The program works if the line print*,[trim(x)] is replaced with print*,[x] or print*,trim(x) -- Summary: ICE with [trim(character_variable)] Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32703
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #7 from rguenther at suse dot de 2007-07-09 15:37 --- Subject: Re: [4.3 regression] inefficient pointer expression On Mon, 9 Jul 2007, zippel at gcc dot gnu dot org wrote: > (In reply to comment #5) > > as you suggest creates worse assembly (look at the extra shift) > > > > foo: > > pushl %ebp > > movl%esp, %ebp > > movl12(%ebp), %ecx > > movl8(%ebp), %edx > > popl%ebp > > sall$2, %ecx > > movl8(%ecx,%edx), %eax > > addl4(%ecx,%edx), %eax > > addl12(%ecx,%edx), %eax > > ret > > The cost of this is dependent on the target, so IMO the shift could be > propagated back into the address at RTL level. Or the other way around. > > so there is no form that is clearly better to canonicalize to. > > Your example is rather artificial and depends on that (i + x) * y is > completely > eliminated. My main point is still that such expression are far more difficult > to translate into proper address operations. > To generate addresses targeting a form of (i * x) + y is clearly better. My example is not artificial. It is quite common to have loops that stream data from one type to another. Also it's not 'clearly' better to me. Anyway, fold () is certainly not able to decide this and both value numbering and re-association can improve the IL by taking into account context. On the backend side we have the fwprop pass which is supposed to do addressing mode selection and the backend which is supposed to provide accurate costs for them. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug middle-end/32004] [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #30 from bonzini at gnu dot org 2007-07-09 15:37 --- Subject: Bug 32004 Author: bonzini Date: Mon Jul 9 15:37:32 2007 New Revision: 126487 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126487 Log: 2007-07-09 Paolo Bonzini <[EMAIL PROTECTED]> PR middle-end/32004 * function.c (rest_of_match_asm_constraints): Pass PROP_REG_INFO. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/function.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug middle-end/32004] [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #31 from bonzini at gnu dot org 2007-07-09 15:38 --- Subject: Bug 32004 Author: bonzini Date: Mon Jul 9 15:37:56 2007 New Revision: 126488 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126488 Log: 2007-07-09 Paolo Bonzini <[EMAIL PROTECTED]> PR middle-end/32004 * function.c (rest_of_match_asm_constraints): Pass PROP_REG_INFO. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/function.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug middle-end/32004] [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #32 from bonzini at gnu dot org 2007-07-09 15:38 --- additional fix committed. -- bonzini at gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug fortran/32704] New: -static-libgfortran is undocumented
PR 31400 added -static-libgfortran, but a documentation is missing. (One should probably also update http://gcc.gnu.org/wiki/GFortranGettingStarted) -- Summary: -static-libgfortran is undocumented Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32704
[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile
--- Comment #15 from bonzini at gnu dot org 2007-07-09 16:31 --- Note that this: > Before the dataflow merge, the argument pointer was always included > in "Registers live at start". ... was because uninitialized registers always showed up as live at start before DF merge. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
[Bug tree-optimization/32705] New: [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
=== acats Summary === # of expected passes2269 # of unexpected failures46 *** FAILURES: ae2113a ae2113b c38202a c85014b c87b26b c910001 c930001 c93008b c94002b c94002d c94002e c94002f c94002g c94008c c95012a c95085a c954015 c954019 c954022 c954026 c954a03 c97113a c97201g c97201h c97201x c97202a c97205a c97205b c97305a c97305b c97305c c97305d c974002 c974003 c974008 c974009 c974010 c974011 cc1207b cc3019c cd92001 ce2103a ce2201l ce2202a ce3815a cxh1001 nearly all of them are of the form +===GNAT BUG DETECTED==+ | 4.3.0 20070709 (experimental) (x86_64-unknown-linux-gnu) GCC error: | | in set_ssa_val_to, at tree-ssa-sccvn.c:1022 | | Error detected around ae2113b.adb:33 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ -- Summary: [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa- sccvn.c:1022 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705
[Bug c++/32106] [4.3 regression] ICE after name-clash between struct and namespace
--- Comment #1 from pcarlini at suse dot de 2007-07-09 17:07 --- Cannot be reproduced anymore. If people want me to add the testcase to be safe, just let me know. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32106
[Bug tree-optimization/32705] [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-07-09 17:36 --- Confirmed on platforms where the Ada compiler bootstraps at all. :-) I plan to look at them once I've found something plausible for PR 32589. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-09 17:36:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #8 from zippel at gcc dot gnu dot org 2007-07-09 17:42 --- (In reply to comment #7) > On the backend side we have the fwprop pass which is supposed to do > addressing mode selection and the backend which is supposed to provide > accurate costs for them. Let's take your proposed form: return (*(p + (i + 2) * 4) + *(p + (i + 1) * 4)) + *(p + (i + 3) * 4); After initial RTL expansion something like this is generated: t1 = i + 2; r = *(p + t1 * 4); t2 = i + 1; r += *(p + t2 * 4); t3 = i + 3; r += *(p + t3 * 4); The problem is now that it takes until combine until this is generated: r = *(p + i * 4 + 8); r += *(p + i * 4 + 4); r += *(p + i * 4 + 12); and at this point it's too late. It's easy to blame the back end, but at this point it's IMHO unrealistic to undo this mess at RTL level. The proper address form should be generated as early as possible, so that at the time RTL is generated, it's as close as possible to the final form. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #7 from ro at techfak dot uni-bielefeld dot de 2007-07-09 17:48 --- Subject: Re: [4.3 regression] Linking libgcj.so fails on Solaris 10/x86 aph at gcc dot gnu dot org writes: > So, the question is why the linker is complaining that "a GOT relative > relocation must reference a local symbol" since it is defined locally and it > should be possible to calculate its offset from the GOT. I've looked up the message in the OpenSolaris ld sources: they are from http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/sgs/libld/common/relocate.c (ld_process_sym_reloc), l. 1187 - 1198 (the message is MSG_REL_BADGOTBASED). On l. 1116.. there's a description of which symbols are considered local. I must confess that I don't fully understand what is going on there ;-) Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug c++/32560] [4.3 regression] ICE on invalid declaration in template
--- Comment #1 from pcarlini at suse dot de 2007-07-09 17:52 --- I can fix this... -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-09 17:52:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32560
[Bug fortran/32704] -static-libgfortran is undocumented
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-09 18:10 --- I asked for it, seems to be me who is going to document it :) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-09 18:10:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32704
