[Bug bootstrap/50697] New: gcc compile fails when gmp is in non-standard location
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50697 Bug #: 50697 Summary: gcc compile fails when gmp is in non-standard location Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: tre...@corevx.com head -1 /swadm/local/include/gmp.h /* Definitions for GNU multiple precision functions. -*- mode: c -*- ./configure --prefix=/swadm/local CFLAGS=-fPIC -I/swadm/local/include LDFLAGS=-L/swadm/local/lib --with-gmp-include=/swadm/local/include or ./configure --prefix=/swadm/local CFLAGS=-fPIC -I/swadm/local/include LDFLAGS=-L/swadm/local/lib --with-gmp-include=/swadm/local log: ---begin--- configure:5354: checking for the correct version of gmp.h configure:5374: gcc -c -fPIC -I/swadm/local/include -I/swadm/local conftest.c >&5 configure:5374: $? = 0 configure:5392: gcc -c -fPIC -I/swadm/local/include -I/swadm/local conftest.c >&5 configure:5392: $? = 0 configure:5393: result: yes ---end--- make error: ---begin--- gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -L/swadm/local/lib \ build/gcov-iov.o -o build/gcov-iov build/gcov-iov '4.6.1' '' \ > tmp-gcov-iov.h /bin/sh ../.././gcc/../move-if-change tmp-gcov-iov.h gcov-iov.h echo timestamp > s-iov gcc -c -DIN_GCC_FRONTEND -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid -I../libdecnumber../.././gcc/c-lang.c -o c-lang.o In file included from ../.././gcc/tree.h:31, from ../.././gcc/c-lang.c:27: ../.././gcc/double-int.h:24:17: error: gmp.h: No such file or directory In file included from ../.././gcc/tree.h:31, from ../.././gcc/c-lang.c:27: ../.././gcc/double-int.h:316: error: expected ‘)’ before ‘double_int’ ../.././gcc/double-int.h:317: error: expected declaration specifiers or ‘...’ before ‘mpz_t’ In file included from ../.././gcc/c-lang.c:27: ../.././gcc/tree.h:5190: error: expected declaration specifiers or ‘...’ before ‘mpz_t’ ../.././gcc/tree.h:5190: error: expected declaration specifiers or ‘...’ before ‘mpz_t’ make[3]: *** [c-lang.o] Error 1 make[3]: Leaving directory `/swadm/local/Gmowa/gcc-4.6.1/host-x86_64-unknown-linux-gnu/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/swadm/local/Gmowa/gcc-4.6.1' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/swadm/local/Gmowa/gcc-4.6.1' make: *** [all] Error 2 ---end---
[Bug c++/49777] for c++ code, without -g option, cannot generate PIC *.so library.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49777 Paolo Carlini changed: What|Removed |Added CC||pbrook at gcc dot gnu.org --- Comment #1 from Paolo Carlini 2011-10-11 23:56:15 UTC --- ARM maintainers, can you have a look to this? Does it make any sense to you?
[Bug c++/50346] Function call foils VRP/jump-threading of redundant predicate on struct member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346 --- Comment #2 from Paolo Carlini 2011-10-11 23:50:46 UTC --- So, is this a C++ front-end issue? tree-optimization?
[Bug c++/50594] Option -fwhole-program discards replaced new operator for std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594 --- Comment #22 from Paolo Carlini 2011-10-11 23:39:47 UTC --- ... because otherwise I'm not confident I'm changing cxx_init_decl_processing in the right way: I have a patchlet which fiddles with newattrs and newtype, I *think* adding the attribute, it doesn't ICE ;), but I don't know if the attribute is really alive.
[Bug c++/50594] Option -fwhole-program discards replaced new operator for std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594 Paolo Carlini changed: What|Removed |Added CC||jwakely.gcc at gmail dot ||com AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #21 from Paolo Carlini 2011-10-11 23:30:07 UTC --- I'm working on this. Indeed, the library bits at this point are more or less trivial (minor nit: __externally_visible__, not externally_visible). However, I guess we need a simple testcase for the 4 implicitly defined without included: can anybody figure out one?
[Bug rtl-optimization/50696] [x32] Unnecessary lea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50696
--- Comment #5 from H.J. Lu 2011-10-11 23:29:05
UTC ---
This patch changes combine not to generate:
(plus:DI (subreg:DI (mult:SI (reg/v:SI 85 [ i ])
(const_int 4 [0x4])) 0)
(subreg:DI (reg:SI 100) 0))
and changes const_32bit_mask to match what combine may generate:
diff --git a/gcc/combine.c b/gcc/combine.c
index 6c3b17c..147d158 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -6905,10 +6905,17 @@ expand_compound_operation (rtx x)
tem = gen_lowpart (mode, XEXP (x, 0));
if (!tem || GET_CODE (tem) == CLOBBER)
return x;
- tem = simplify_shift_const (NULL_RTX, ASHIFT, mode,
- tem, modewidth - pos - len);
- tem = simplify_shift_const (NULL_RTX, unsignedp ? LSHIFTRT : ASHIFTRT,
- mode, tem, modewidth - len);
+ if (GET_CODE (x) == ZERO_EXTEND)
+tem = gen_rtx_AND (mode, tem,
+ GEN_INT (GET_MODE_MASK (GET_MODE (XEXP (x, 0);
+ else
+{
+ tem = simplify_shift_const (NULL_RTX, ASHIFT, mode,
+ tem, modewidth - pos - len);
+ tem = simplify_shift_const (NULL_RTX,
+ unsignedp ? LSHIFTRT : ASHIFTRT,
+ mode, tem, modewidth - len);
+}
}
else if (unsignedp && len < HOST_BITS_PER_WIDE_INT)
tem = simplify_and_const_int (NULL_RTX, GET_MODE (x),
diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index 349f5b0..03da1fb 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -600,8 +600,8 @@
;; Match exactly 0x0 in anddi as a zero-extension operation
(define_predicate "const_32bit_mask"
(and (match_code "const_int")
- (match_test "trunc_int_for_mode (INTVAL (op), DImode)
-== (HOST_WIDE_INT) 0x")))
+ (match_test "(trunc_int_for_mode (INTVAL (op), DImode) &
(HOST_WIDE_INT)
0xff00)
+== (HOST_WIDE_INT) 0xff00")))
;; Match 2, 4, or 8. Used for leal multiplicands.
(define_predicate "const248_operand"
[Bug rtl-optimization/50696] [x32] Unnecessary lea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50696 --- Comment #4 from H.J. Lu 2011-10-11 22:13:47 UTC --- const_32bit_mask is incorrect since combine may optimize VAL in ADDR & VAL from 0x to 0xfffc. Even if we take this into account, we can't decompose (plus:DI (subreg:DI (mult:SI (reg/v:SI 85 [ i ]) (const_int 4 [0x4])) 0) (subreg:DI (reg:SI 100) 0))
[Bug middle-end/49629] [4.7 Regression] ICE: in df_refs_verify, at df-scan.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49629 Steven Bosscher changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #6 from Steven Bosscher 2011-10-11 22:12:25 UTC --- I cannot reproduce the power7 ICE with a cross-compiler (x86_64 X powerpc), with trunk revision r179665. Pat, is this problem still there for you? If so, can you look at the backtrace and confirm that this ICE occurs in df-scan after IRA?
[Bug target/49965] libgomp.c++/reduction-4.C and libgomp.c++/task-8.C FAIL on Solaris 11/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #16 from Eric Botcazou 2011-10-11 21:39:14 UTC --- The testsuite should be clean again.
[Bug target/49965] libgomp.c++/reduction-4.C and libgomp.c++/task-8.C FAIL on Solaris 11/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965 --- Comment #15 from Eric Botcazou 2011-10-11 21:34:48 UTC --- Author: ebotcazou Date: Tue Oct 11 21:34:42 2011 New Revision: 179829 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179829 Log: PR target/49965 * config/sparc/sparc.md (movcc): Do not save comparison code. (movcc): Likewise. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/sparc/sparc.md
[Bug target/49965] libgomp.c++/reduction-4.C and libgomp.c++/task-8.C FAIL on Solaris 11/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965 --- Comment #13 from Eric Botcazou 2011-10-11 21:33:28 UTC --- Author: ebotcazou Date: Tue Oct 11 21:33:24 2011 New Revision: 179827 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179827 Log: PR target/49965 * config/sparc/sparc.md (movcc): Do not save comparison code. (movcc): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.md
[Bug target/49965] libgomp.c++/reduction-4.C and libgomp.c++/task-8.C FAIL on Solaris 11/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965 --- Comment #14 from Eric Botcazou 2011-10-11 21:34:01 UTC --- Author: ebotcazou Date: Tue Oct 11 21:33:57 2011 New Revision: 179828 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179828 Log: PR target/49965 * config/sparc/sparc.md (movcc): Do not save comparison code. (movcc): Likewise. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/sparc/sparc.md
Spurious array bounds warnings from gfortran
Compiler version: (gfortran from ubuntu 11.04) $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/x86_64-linux-gnu --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) Symptoms: Compiling the file foo.F95 as shown below leads to the following warnings: $ gfortran -c -O -Wall foo.F95 foo.F95: In function 'fooallocate': foo.F95:8:0: warning: 'y.bar.dim[0].ubound' may be used uninitialized in this function foo.F95:8:0: warning: 'y.bar2.dim[0].ubound' may be used uninitialized in this function The code generated appears to be fine. I believe that the warnings are spurious given the initialization pattern. They're also rather brittle - for example, removing the definition and initialization of "junk" makes the warnings go away. Contents of foo.F95: $ cat foo.F95 MODULE x TYPE foo REAL, DIMENSION(:), POINTER :: bar => NULL() REAL, DIMENSION(:), POINTER :: bar2 => NULL() REAL :: junk = 75 END TYPE foo CONTAINS FUNCTION fooAllocate(n,r) RESULT(y) INTEGER, INTENT(IN) :: n INTEGER, INTENT(IN) :: r INTEGER len TYPE (foo) :: y len = 123 IF(r == 1) THEN len = 42 END IF SELECT CASE(r) CASE(1) ALLOCATE(y%bar(len)) CASE(5) ALLOCATE(y%bar2(n)) END SELECT RETURN END FUNCTION fooAllocate END MODULE x
[Bug ada/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678 Maxim Kuvyrkov changed: What|Removed |Added CC||mkuvyrkov at gcc dot ||gnu.org --- Comment #13 from Maxim Kuvyrkov 2011-10-11 20:41:35 UTC --- Dominique, Eric, Would you please try and reproduce the failure with a Linux target? [Setting up Darwin GCC development environment (especially with GNAT in it) is a very time-consuming task.] Thank you.
[Bug target/49826] [4.7 Regression] Symbols are not decorated with attribute stdcall and -mrtd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49826 Joseph S. Myers changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/50696] [x32] Unnecessary lea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50696
--- Comment #3 from H.J. Lu 2011-10-11 20:11:59
UTC ---
Does this patch
diff --git a/gcc/combine.c b/gcc/combine.c
index 6c3b17c..52259b6 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -5078,6 +5078,22 @@ subst (rtx x, rtx from, rtx to, int in_dest, int
in_cond, int unique_copy)
}
}
}
+#ifdef POINTERS_EXTEND_UNSIGNED
+ else if (POINTERS_EXTEND_UNSIGNED > 0
+ && code == MEM
+ && GET_MODE (XEXP (x, 0)) == Pmode
+ && GET_MODE (from) == ptr_mode
+ && GET_CODE (XEXP (x, 0)) == ZERO_EXTEND
+ && COMBINE_RTX_EQUAL_P (XEXP (XEXP (x, 0), 0), from))
+{
+ /* If an address is zero-extended from ptr_mode to
+ Pmode, replace FROM with TO. */
+ SUBST (XEXP (XEXP (x, 0), 0),
+ (unique_copy && n_occurrences
+ ? copy_rtx (to) : to));
+ n_occurrences++;
+}
+#endif
else
{
len = GET_RTX_LENGTH (code);
make any senses?
[Bug middle-end/49319] [4.7 regression] g++.dg/abi/thunk5.C FAILs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49319 Joseph S. Myers changed: What|Removed |Added Priority|P3 |P4
[Bug rtl-optimization/50696] [x32] Unnecessary lea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50696
H.J. Lu changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #2 from H.J. Lu 2011-10-11 20:09:10
UTC ---
For
(insn 37 35 39 3 (parallel [
(set (reg:SI 88)
(plus:SI (reg:SI 89)
(reg:SI 100)))
(clobber (reg:CC 17 flags))
]) x.i:12 253 {*addsi_1}
(expr_list:REG_DEAD (reg:SI 89)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 39 37 41 3 (set (mem:SI (zero_extend:DI (reg:SI 88)) [0 MEM[symbol: x,
index: D.2735_1, step: 4, offset: 4294967292B]+0 S4 A32])
(reg/v:SI 85 [ i ])) x.i:12 64 {*movsi_internal}
(expr_list:REG_DEAD (reg:DI 87)
(nil)))
combine replaces zero_extend with and. It may be a valid
option for normal computation. But it messes up the
POINTERS_EXTEND_UNSIGNED > 0 target where address is
zero-extendeded from ptr_mode to Pmode.
[Bug fortran/50690] [4.7 Regression] ICE with front end optimization and OMP workshare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690 Thomas Koenig changed: What|Removed |Added Attachment #25468|0 |1 is obsolete|| --- Comment #5 from Thomas Koenig 2011-10-11 19:51:02 UTC --- Created attachment 25470 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25470 A better patch ... because this one actually fixes the test case.
[Bug c++/49216] [4.6 regression][C++0x] ICE on compiling new-expression with braced-init-list for arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49216 Jason Merrill changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Target Milestone|4.7.0 |4.6.2 --- Comment #10 from Jason Merrill 2011-10-11 19:51:46 UTC --- ICE fixed for 4.6.2; value-initialization semantics fixed for 4.7.
[Bug c++/49216] [4.6 regression][C++0x] ICE on compiling new-expression with braced-init-list for arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49216
--- Comment #9 from Jason Merrill 2011-10-11
19:50:55 UTC ---
Author: jason
Date: Tue Oct 11 19:50:49 2011
New Revision: 179819
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179819
Log:
PR c++/49216
* init.c (build_vec_init): Avoid crash on new int[1]{}.
Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/initlist-49216.C
Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/init.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/50618] [4.4/4.5/4.6/4.7 Regression] Virtual inheritance segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50618 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c/50695] double comparison broken after computation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695 --- Comment #9 from rickyrockrat 2011-10-11 19:38:51 UTC --- One further note, with stdio.h, string.h and using strtod, I get the correct answer suggested by Andreas Schwab: Bug!!0.00E+00 If I put stdio.h, string.h, and stdlib.h, I get Nobug Something doesn't make sense.
[Bug other/39933] make clean fails in libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39933 schaiba at gmail dot com changed: What|Removed |Added CC||schaiba at gmail dot com --- Comment #2 from schaiba at gmail dot com 2011-10-11 19:35:21 UTC --- I am able to confirm this with gcc 4.5.1 on an i386 OpenBSD-current.
[Bug c/50695] double comparison broken after computation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695 --- Comment #8 from rickyrockrat 2011-10-11 19:33:47 UTC --- Created attachment 25469 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25469 stdlib.h Tar for string.h, stdlib.h, and stdio.h on the system.
[Bug c/50695] double comparison broken after computation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695 --- Comment #7 from rickyrockrat 2011-10-11 19:25:10 UTC --- I removed the ','at the beginning of the string (which was not there in the original test case), and I now get Bug!!4.074850E+05 In any case, it should return 0, if +1.xxE-6 is an invalid number. When I include these includes: #include #include #include my print looks like this: Bug!!1.00E-06 Which is what perplexed me in the first place. It seems if I include stdlib.h, I get Bug!!4.074850E+05 If I don't include it, I get: Bug!!1.00E-06, which is what prompted this bug report in the first place.
[Bug fortran/50690] [4.7 Regression] ICE with front end optimization and OMP workshare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-10-11 Ever Confirmed|0 |1 --- Comment #4 from Thomas Koenig 2011-10-11 19:24:38 UTC --- (In reply to comment #3) > Created attachment 25468 [details] > Proposed patch > > This patch fixes the test case and passes regression testing. No it doesn't :-)
[Bug fortran/50690] [4.7 Regression] ICE with front end optimization and OMP workshare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690 Thomas Koenig changed: What|Removed |Added AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org |gnu.org | --- Comment #3 from Thomas Koenig 2011-10-11 19:13:43 UTC --- Created attachment 25468 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25468 Proposed patch This patch fixes the test case and passes regression testing.
[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661 --- Comment #24 from Paolo Carlini 2011-10-11 19:10:12 UTC --- :) Sorry about the italian chattering between me and Vincenzo
[Bug c/50695] double comparison broken after computation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695 rickyrockrat changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #6 from rickyrockrat 2011-10-11 19:06:23 UTC --- Using strtod has the same problem.
[Bug c/50695] double comparison broken after computation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695
--- Comment #5 from rickyrockrat 2011-10-11
19:05:28 UTC ---
>+1.0E-06," does not start with a valid
>floating point number and will always be parsed as 0.
I don't know what 'always will be', nor who exactly is doing the parsing, but
strtof, at least, seems to parse it correctly, because a print of said variable
prints as 1.0E-06 Believe me, I checked.
Ok, here's a new test case, still broken:
#include
int main(int argc, char *argv){
double x,y;
x=strtod(",+1.0E-06,",NULL);
y=1000;
y*=1000;
if(x*y!=1)
printf("Bug!!%E\n",x);
else printf("Nobug\n");}
And the output is:
Bug!!4.40E+01
How is it resolved?
[Bug middle-end/50189] [4.5/4.6 Regression] Wrong code error in -O2 [-fstrict-enums] compile, target independent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189 --- Comment #10 from Paul Koning 2011-10-11 19:03:24 UTC --- Created attachment 25467 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25467 Tentative patch against 4.6.1 I chased the issue for a while, using 4.6.1 as the test version. The problem is in extract_range_from_assert. When processing < <= > >= assertions, it sets the min (for < <=) or max (for > >=) of the calculated range to be the type min or max of the right hand side. In the testcase, we have "m_timestamp > AT_END" where m_timestamp is unsigned int and AT_END is enum with value 2. The highest enum value of that enum type is 3, so if fstrict-enums is in effect, the type max is 3. Result: while the dump file shows the resulting range as [3,+INF] what that actually means is [3,3] because the upper bound of the enum is applied, *not* the upper bound of the variable being compared. The solution is for extract_range_from_assert to pick up type min or type max from the type of the left hand side (here m_timestamp, i.e., unsigned int). So the range still shows as [3,+INF] but now that represents [3,4294967295] and the resulting code is correct. The patch is just one line. The question I have is whether changing the way variable "type" is set is right, because it is also used in the != case and I don't fully understand that one.
[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661 --- Comment #23 from pcarlini at gmail dot com 2011-10-11 19:01:02 UTC --- > > that never made to mainline > http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01560.html > what about it? Eh, bisognerebbe ricostruire, ma mi sa che è stato proprio nel periodo nel quale Apple ha smesso di contribuire a GCC, un piccolo ritardo e addio! Adesso toccherà in caso riscriverla. Però sarebbe da capire se i maintainer in primo luogo LA VOGLIONO una roba del genere! Paolo
[Bug ada/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #12 from Iain Sandoe 2011-10-11 18:45:39
UTC ---
Created attachment 25466
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25466
test of -fstack-check
a simple test program for Darwin ..
.. AFAICT this DTRT under 'c' on {powerpc,i386}-darwin9 and also on
x86_64-darwin10.
If one bumps up the stack usage in stack_meltdown() then checks the tree dumps,
__builtin_alloca is being invoked - but still things seem to be as expected.
[Bug c++/49216] [4.6 regression][C++0x] ICE on compiling new-expression with braced-init-list for arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49216 Jason Merrill changed: What|Removed |Added CC||z0sh at sogetthis dot com --- Comment #8 from Jason Merrill 2011-10-11 18:33:12 UTC --- *** Bug 50458 has been marked as a duplicate of this bug. ***
[Bug fortran/50690] [4.7 Regression] ICE with front end optimization and OMP workshare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690 --- Comment #2 from Tobias Burnus 2011-10-11 18:34:01 UTC --- (In reply to comment #1) > To me, the right strategy appears to be to mark the temporary > variable as threadprivate if we are within an OMP block. To me it sounds like the right solution to the wrong problem. The issue is that WORKSHARE does not expect an EXPR_BLOCK. I think as long as there are only work-share allowed items in EXPR_BLOCK, one can continue to translate the OpenMP workshare as it - handling EXPR_BLOCK explicitly. Independent of that, one should check whether one has to put the temporary in thread-private memory. However, that applies then to all FE-optimization temporaries as one never knows whether on is in a parallel block or not. It might also affect other temporaries, gfortran generates. (Still, I was/am under the impression that it is not needed in that case to mark such variable as being thread local as they are just put on the stack. That's different for static/external variables.)
[Bug c++/50458] [4.6 Regression] ICE when using brace-initializer for new array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50458 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.5.4 Resolution||DUPLICATE Known to fail||4.6.0 --- Comment #4 from Jason Merrill 2011-10-11 18:33:12 UTC --- Dup. *** This bug has been marked as a duplicate of bug 49216 ***
[Bug c++/49216] [4.6 regression][C++0x] ICE on compiling new-expression with braced-init-list for arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49216 Jason Merrill changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|[C++0x][Regression] ICE on |[4.6 regression][C++0x] ICE |compiling new-expression|on compiling new-expression |with braced-init-list for |with braced-init-list for |arrays |arrays --- Comment #7 from Jason Merrill 2011-10-11 18:32:41 UTC --- Still a 4.6 regression.
[Bug target/50447] [avr] Better support of AND, OR, XOR and PLUS with constant integers for 16- and 32-bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50447 --- Comment #5 from Georg-Johann Lay 2011-10-11 18:28:52 UTC --- Author: gjl Date: Tue Oct 11 18:28:49 2011 New Revision: 179816 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179816 Log: PR target/50447 * config/avr/avr.md (cc): Add out_plus attribute alternative. (addsi3): Use it. Adapt avr_out_plus to new prototype. Use avr_out_plus for all CONST_INT addends. * config/avr/avr-protos.h (avr_out_plus): Change prototype. * config/avr/avr.c (notice_update_cc): Call avr_out_plus on CC_OUT_PLUS. (avr_out_plus_1): Change prototype and report effect on cc0. (avr_out_plus): Ditto. (adjust_insn_length): Adapt call to avr_out_plus to new prototype. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md
[Bug c++/49896] undefined reference to static const integral member whose address is not used, for some values of the constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49896 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.2 --- Comment #11 from Jason Merrill 2011-10-11 18:20:52 UTC --- Fixed for 4.6.2.
[Bug c++/49855] [4.6/4.7 Regression] internal compiler error: in fold_convert_const_int_from_real
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49855 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Jason Merrill 2011-10-11 18:21:00 UTC --- Fixed for 4.6.2.
[Bug c++/49855] [4.6/4.7 Regression] internal compiler error: in fold_convert_const_int_from_real
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49855 --- Comment #6 from Jason Merrill 2011-10-11 18:18:35 UTC --- Author: jason Date: Tue Oct 11 18:18:25 2011 New Revision: 179815 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179815 Log: PR c++/49855 PR c++/49896 * call.c (perform_implicit_conversion_flags): Do perform scalar conversions in templates. * pt.c (tsubst_copy, tsubst_copy_and_build): Handle CONVERT_EXPR. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/template/constant1.C branches/gcc-4_6-branch/gcc/testsuite/g++.dg/template/constant2.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/call.c branches/gcc-4_6-branch/gcc/cp/pt.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/49896] undefined reference to static const integral member whose address is not used, for some values of the constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49896 --- Comment #10 from Jason Merrill 2011-10-11 18:18:35 UTC --- Author: jason Date: Tue Oct 11 18:18:25 2011 New Revision: 179815 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179815 Log: PR c++/49855 PR c++/49896 * call.c (perform_implicit_conversion_flags): Do perform scalar conversions in templates. * pt.c (tsubst_copy, tsubst_copy_and_build): Handle CONVERT_EXPR. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/template/constant1.C branches/gcc-4_6-branch/gcc/testsuite/g++.dg/template/constant2.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/call.c branches/gcc-4_6-branch/gcc/cp/pt.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/50690] [4.7 Regression] ICE with front end optimization and OMP workshare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690 --- Comment #1 from tkoenig at netcologne dot de 2011-10-11 18:03:56 UTC --- To me, the right strategy appears to be to mark the temporary variable as threadprivate if we are within an OMP block. Does this sound right?
[Bug target/50696] [x32] Unnecessary lea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50696 --- Comment #1 from H.J. Lu 2011-10-11 17:59:50 UTC --- It is generated by expand_compound_operation.
[Bug c++/49896] undefined reference to static const integral member whose address is not used, for some values of the constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49896 --- Comment #9 from Jason Merrill 2011-10-11 17:53:20 UTC --- Author: jason Date: Tue Oct 11 17:53:07 2011 New Revision: 179813 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179813 Log: PR c++/49855 PR c++/49896 * cp-tree.def (IMPLICIT_CONV_EXPR): New. * call.c (perform_implicit_conversion_flags): Build it instead of NOP_EXPR. * cp-objcp-common.c (cp_common_init_ts): It's typed. * cxx-pretty-print.c (pp_cxx_cast_expression): Handle it. (pp_cxx_expression): Likewise. * error.c (dump_expr): Likewise. * semantics.c (potential_constant_expression_1): Likewise. * tree.c (cp_tree_equal): Likewise. (cp_walk_subtrees): Likewise. * pt.c (iterative_hash_template_arg): Likewise. (for_each_template_parm_r): Likewise. (type_dependent_expression_p): Likewise. (tsubst_copy, tsubst_copy_and_build): Handle IMPLICIT_CONV_EXPR and CONVERT_EXPR. * cp-tree.h (IMPLICIT_CONV_EXPR_DIRECT_INIT): New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-template3.C trunk/gcc/testsuite/g++.dg/template/constant1.C trunk/gcc/testsuite/g++.dg/template/constant2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-objcp-common.c trunk/gcc/cp/cp-tree.def trunk/gcc/cp/cp-tree.h trunk/gcc/cp/cxx-pretty-print.c trunk/gcc/cp/error.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog
[Bug c++/49855] [4.6/4.7 Regression] internal compiler error: in fold_convert_const_int_from_real
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49855 --- Comment #5 from Jason Merrill 2011-10-11 17:53:19 UTC --- Author: jason Date: Tue Oct 11 17:53:07 2011 New Revision: 179813 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179813 Log: PR c++/49855 PR c++/49896 * cp-tree.def (IMPLICIT_CONV_EXPR): New. * call.c (perform_implicit_conversion_flags): Build it instead of NOP_EXPR. * cp-objcp-common.c (cp_common_init_ts): It's typed. * cxx-pretty-print.c (pp_cxx_cast_expression): Handle it. (pp_cxx_expression): Likewise. * error.c (dump_expr): Likewise. * semantics.c (potential_constant_expression_1): Likewise. * tree.c (cp_tree_equal): Likewise. (cp_walk_subtrees): Likewise. * pt.c (iterative_hash_template_arg): Likewise. (for_each_template_parm_r): Likewise. (type_dependent_expression_p): Likewise. (tsubst_copy, tsubst_copy_and_build): Handle IMPLICIT_CONV_EXPR and CONVERT_EXPR. * cp-tree.h (IMPLICIT_CONV_EXPR_DIRECT_INIT): New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-template3.C trunk/gcc/testsuite/g++.dg/template/constant1.C trunk/gcc/testsuite/g++.dg/template/constant2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-objcp-common.c trunk/gcc/cp/cp-tree.def trunk/gcc/cp/cp-tree.h trunk/gcc/cp/cxx-pretty-print.c trunk/gcc/cp/error.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog
[Bug target/50696] New: [x32] Unnecessary lea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50696
Bug #: 50696
Summary: [x32] Unnecessary lea
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com
[hjl@gnu-mic-2 pr50633]$ cat x.i
struct s { int val[16]; };
extern double f (struct s pb, double pc);
int main ()
{
struct s x;
int i;
for (i = 0; i < 16; i++)
x.val[i] = i + 1;
if (f (x, 1.0L) != 10136.0L)
__builtin_abort ();
return 0;
}
[hjl@gnu-mic-2 pr50633]$ make x.s
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -mx32 -O -S x.i
[hjl@gnu-mic-2 pr50633]$ cat x.s
.file"x.i"
.text
.globlmain
.typemain, @function
main:
.LFB0:
.cfi_startproc
subq$136, %rsp
.cfi_def_cfa_offset 144
movl$0, %eax
movl%esp, %ecx
addl$60, %ecx
.L2:
addl$1, %eax
leal(%rcx,%rax,4), %edx
movl%eax, (%edx)
cmpl$16, %eax
jne.L2
movq64(%rsp), %rax
movq%rax, (%rsp)
movq72(%rsp), %rax
movq%rax, 8(%rsp)
movq80(%rsp), %rax
movq%rax, 16(%rsp)
movq88(%rsp), %rax
movq%rax, 24(%rsp)
movq96(%rsp), %rax
movq%rax, 32(%rsp)
movq104(%rsp), %rax
movq%rax, 40(%rsp)
movq112(%rsp), %rax
movq%rax, 48(%rsp)
movq120(%rsp), %rax
movq%rax, 56(%rsp)
movsd.LC0(%rip), %xmm0
callf
ucomisd.LC1(%rip), %xmm0
jp.L5
je.L7
.L5:
callabort
.L7:
movl$0, %eax
addq$136, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.sizemain, .-main
leal(%rcx,%rax,4), %edx
movl%eax, (%edx)
can be combined into
movl%eax, (%ecx,%eax,4)
[reply] [-] Comment 4 H.J. Lu 2011-10-06 19:19:23 UTC
Combine failed:
(set (mem:SI (and:DI (plus:DI (subreg:DI (mult:SI (reg/v:SI 84 [ i ])
(const_int 4 [0x4])) 0)
(subreg:DI (reg:SI 106) 0))
(const_int 4294967292 [0xfffc])) [3 MEM[symbol: x, index:
D.2741_12, step: 4, offset: 4294967292B]+0 S4 A32])
(reg/v:SI 84 [ i ]))
for
(insn 37 35 39 3 (set (reg:SI 90)
(plus:SI (mult:SI (reg/v:SI 84 [ i ])
(const_int 4 [0x4]))
(reg:SI 106))) x.i:11 247 {*leasi_2}
(nil))
(insn 39 37 41 3 (set (mem:SI (zero_extend:DI (reg:SI 90)) [3 MEM[symbol: x,
index: D.2741_12, step: 4, offset: 4294967292B]+0 S4 A32])
(reg/v:SI 84 [ i ])) x.i:11 64 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 90)
(nil)))
Since address is 32bit aligned, 0xfffc is the same as
0x. But we don't have this information.
why combine creates:
Failed to match this instruction:
(set (mem:SI (and:DI (plus:DI (subreg:DI (mult:SI (reg/v:SI 85 [ i ])
(const_int 4 [0x4])) 0)
(subreg:DI (reg:SI 106) 0))
(const_int 4294967292 [0xfffc])) [0 MEM[symbol: x, index:
D.2741_1, step: 4, offset: 4294967292B]+0 S4 A32])
(reg/v:SI 85 [ i ]))
Considering that this is in fact zero-extension, the "optimized" pattern is
worse than sticking subreg to the whole address, i.e.
(and:DI (subreg:DI (plus:SI (mult:SI (reg/v:SI 85 [ i ]) (const_int 4 [0x4]))
(reg:SI 106)) 0)
(const_int 4294967295 [0x]))
Please note that we have registers in two different modes in the former
pattern. The later pattern would be recognized by i386.c code.
[Bug c++/49855] [4.6/4.7 Regression] internal compiler error: in fold_convert_const_int_from_real
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49855 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/44473] iterators already defined for std::vector when using std::decimal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44473 --- Comment #19 from Peter Bergner 2011-10-11 17:24:39 UTC --- Author: bergner Date: Tue Oct 11 17:24:27 2011 New Revision: 179811 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179811 Log: gcc/ PR c++/44473 * mangle.c (write_type): Handle CV qualifiers for decimal classes. gcc/testsuite/ PR c++/44473 * g++.dg/dfp/44473-1.C: New test. * g++.dg/dfp/44473-2.C: New test. * g++.dg/dfp/mangle-1.C: New test. * g++.dg/dfp/mangle-2.C: New test. * g++.dg/dfp/mangle-3.C: New test. * g++.dg/dfp/mangle-4.C: New test. * g++.dg/dfp/mangle-5.C: New test. Added: branches/ibm/gcc-4_6-branch/gcc/testsuite/g++.dg/dfp/44473-1.C branches/ibm/gcc-4_6-branch/gcc/testsuite/g++.dg/dfp/44473-2.C branches/ibm/gcc-4_6-branch/gcc/testsuite/g++.dg/dfp/mangle-1.C branches/ibm/gcc-4_6-branch/gcc/testsuite/g++.dg/dfp/mangle-2.C branches/ibm/gcc-4_6-branch/gcc/testsuite/g++.dg/dfp/mangle-3.C branches/ibm/gcc-4_6-branch/gcc/testsuite/g++.dg/dfp/mangle-4.C branches/ibm/gcc-4_6-branch/gcc/testsuite/g++.dg/dfp/mangle-5.C Modified: branches/ibm/gcc-4_6-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_6-branch/gcc/cp/mangle.c branches/ibm/gcc-4_6-branch/gcc/testsuite/ChangeLog.ibm
[Bug c++/44473] iterators already defined for std::vector when using std::decimal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44473 --- Comment #18 from Peter Bergner 2011-10-11 17:17:49 UTC --- Author: bergner Date: Tue Oct 11 17:17:43 2011 New Revision: 179810 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179810 Log: gcc/ PR c++/44473 * mangle.c (write_type): Handle CV qualifiers for decimal classes. gcc/testsuite/ PR c++/44473 * g++.dg/dfp/44473-1.C: New test. * g++.dg/dfp/44473-2.C: New test. * g++.dg/dfp/mangle-1.C: New test. * g++.dg/dfp/mangle-2.C: New test. * g++.dg/dfp/mangle-3.C: New test. * g++.dg/dfp/mangle-4.C: New test. * g++.dg/dfp/mangle-5.C: New test. Added: branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/dfp/44473-1.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/dfp/44473-2.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/dfp/mangle-1.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/dfp/mangle-2.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/dfp/mangle-3.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/dfp/mangle-4.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/dfp/mangle-5.C Modified: branches/ibm/gcc-4_5-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_5-branch/gcc/cp/mangle.c branches/ibm/gcc-4_5-branch/gcc/testsuite/ChangeLog.ibm
[Bug c++/44473] iterators already defined for std::vector when using std::decimal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44473 --- Comment #17 from Peter Bergner 2011-10-11 17:02:51 UTC --- Author: bergner Date: Tue Oct 11 17:02:42 2011 New Revision: 179809 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179809 Log: gcc/ PR c++/44473 * mangle.c (write_type): Handle CV qualifiers for decimal classes. gcc/testsuite/ PR c++/44473 * g++.dg/dfp/44473-1.C: New test. * g++.dg/dfp/44473-2.C: New test. * g++.dg/dfp/mangle-1.C: New test. * g++.dg/dfp/mangle-2.C: New test. * g++.dg/dfp/mangle-3.C: New test. * g++.dg/dfp/mangle-4.C: New test. * g++.dg/dfp/mangle-5.C: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/dfp/44473-1.C branches/gcc-4_6-branch/gcc/testsuite/g++.dg/dfp/44473-2.C branches/gcc-4_6-branch/gcc/testsuite/g++.dg/dfp/mangle-1.C branches/gcc-4_6-branch/gcc/testsuite/g++.dg/dfp/mangle-2.C branches/gcc-4_6-branch/gcc/testsuite/g++.dg/dfp/mangle-3.C branches/gcc-4_6-branch/gcc/testsuite/g++.dg/dfp/mangle-4.C branches/gcc-4_6-branch/gcc/testsuite/g++.dg/dfp/mangle-5.C Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/cp/mangle.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/44473] iterators already defined for std::vector when using std::decimal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44473 --- Comment #16 from Peter Bergner 2011-10-11 16:59:09 UTC --- Author: bergner Date: Tue Oct 11 16:58:59 2011 New Revision: 179808 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179808 Log: gcc/ PR c++/44473 * mangle.c (write_type): Handle CV qualifiers for decimal classes. gcc/testsuite/ PR c++/44473 * g++.dg/dfp/44473-1.C: New test. * g++.dg/dfp/44473-2.C: New test. * g++.dg/dfp/mangle-1.C: New test. * g++.dg/dfp/mangle-2.C: New test. * g++.dg/dfp/mangle-3.C: New test. * g++.dg/dfp/mangle-4.C: New test. * g++.dg/dfp/mangle-5.C: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/dfp/44473-1.C branches/gcc-4_5-branch/gcc/testsuite/g++.dg/dfp/44473-2.C branches/gcc-4_5-branch/gcc/testsuite/g++.dg/dfp/mangle-1.C branches/gcc-4_5-branch/gcc/testsuite/g++.dg/dfp/mangle-2.C branches/gcc-4_5-branch/gcc/testsuite/g++.dg/dfp/mangle-3.C branches/gcc-4_5-branch/gcc/testsuite/g++.dg/dfp/mangle-4.C branches/gcc-4_5-branch/gcc/testsuite/g++.dg/dfp/mangle-5.C Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/cp/mangle.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427 Tobias Burnus changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |burnus at gcc dot gnu.org |gnu.org | --- Comment #27 from Tobias Burnus 2011-10-11 16:16:44 UTC --- Mine (again after 1.5 years). This time, I plan to finish the patch and make it read for inclusion in 4.7. The patch is essentially the one linked in comment 22 but with a couple of regressions fixed. (Current status: 15 GCC test-suite failures and one real-world failure [due to seemingly about 10 separate issues].) Draft patch and current status: https://userpage.physik.fu-berlin.de/~tburnus/tmp/constructor.diff
[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661 --- Comment #22 from vincenzo Innocente 2011-10-11 16:12:18 UTC --- in reference to jakub comment #8 actually there was this patch proposing a "ivdep macro" (identical to INTEL's one!) that never made to mainline http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01560.html what about it?
[Bug tree-optimization/50693] Loop optimization restricted by GOTOs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693 --- Comment #21 from Alex Gaynor 2011-10-11 16:02:56 UTC --- Given the concern for preserving labels for debugging, perhaps allowing the merging of basic blocks that eliminate labels could be conditional on either a new function attribute or command line flag?
[Bug ada/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678 --- Comment #11 from Iain Sandoe 2011-10-11 15:57:05 UTC --- Created attachment 25465 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25465 asm for c52104y changing the number of args doesn't seem to fix the problem (off a stage3 bubble + rebuild of libada). Attached asm - if there's a tree dump that would help then I can upload as wanted..
[Bug middle-end/50667] [4.7 Regression] FAIL: gcc.c-torture/execute/vshuf-* on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50667 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Dominique d'Humieres 2011-10-11 15:56:26 UTC --- This has been fixed between revisions 179754 (ICE) and 179779 (OK). Closing.
[Bug libgomp/49965] libgomp.c++/reduction-4.C and libgomp.c++/task-8.C FAIL on Solaris 11/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965 --- Comment #12 from Eric Botcazou 2011-10-11 15:37:29 UTC --- This is a fallout of the merge of the cond-optab branch in the 4.5 series.
[Bug c/50565] [4.5/4.6/4.7 Regression] initializer element is not computable at load time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50565 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-10-11 AssignedTo|unassigned at gcc dot |jsm28 at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Joseph S. Myers 2011-10-11 15:33:55 UTC --- Patch (to convert.c) submitted: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00894.html
[Bug tree-optimization/50693] Loop optimization restricted by GOTOs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693 --- Comment #20 from Jakub Jelinek 2011-10-11 14:50:51 UTC --- (In reply to comment #17) > LLVM appears to be able to recognize memset of any value, not just zero. And > apparently performs control flow simplification before attempting to recognize > the idiom, so it can expose the loop created by the convoluted GOTOs. Well, GCC also performs lots of control flow simplifications, just the bb's aren't merged here because that would mean the user label would be lost, couldn't be used by the user debugging the code at all. Vectorization restricts the cfg of the loop. In successfully vectorized loops it is unlikely user labels would be very helpful to the user, since multiple iterations of the loop are performed together. If we want to handle this obfuscated code, either we'd need to make debugging experience worse for all loops (say at -O3), no matter if they will be successfully vectorized or not, or lift up the restrictions in the vectorizer, so that it would accept multiple basic blocks with only fallthru edges in between and no phis or something similar, or temporarily merge the block and split it again after vectorization, readding the user labels.
[Bug ada/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678 vries at gcc dot gnu.org changed: What|Removed |Added Component|tree-optimization |ada --- Comment #10 from vries at gcc dot gnu.org 2011-10-11 14:47:34 UTC --- I don't know whether it's related, but while reviewing the code once more I found this problem in function.c. I forgot to update the number of arguments in build_call_expr to 2: ... t = built_in_decls[BUILT_IN_ALLOCA_WITH_ALIGN]; t = build_call_expr (t, 1, DECL_SIZE_UNIT (parm), size_int (DECL_ALIGN (parm))); ... I'll test and submit to gcc-patches.
[Bug tree-optimization/50693] Loop optimization restricted by GOTOs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693 --- Comment #19 from Richard Guenther 2011-10-11 14:45:22 UTC --- (In reply to comment #17) > LLVM appears to be able to recognize memset of any value, not just zero. And > apparently performs control flow simplification before attempting to recognize > the idiom, so it can expose the loop created by the convoluted GOTOs. I suppose you can no longer debug that though (break at the labels by name), even when disabling the memset pattern detection?
[Bug tree-optimization/50693] Loop optimization restricted by GOTOs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693 Richard Guenther changed: What|Removed |Added CC||aoliva at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #18 from Richard Guenther 2011-10-11 14:42:46 UTC --- (In reply to comment #15) > What probably causes this is that we don't merge the blocks > > # i_29 = PHI > copy_block: > D.3506_7 = v_20->chars; > D.3507_8 = D.3506_7 + i_29; > *D.3507_8 = c_9(D); > i_10 = i_29 + 1; > goto (loop_back); > > loop_back: > loop_cond_11 = i_10 < n_3(D); > if (loop_cond_11 != 0) > goto (copy_block); > else > goto (end); > > even though it's a fallthru edge. We don't do this to preserve user labels > for debugging (and mind, no code-gen differences between -g0 vs. -g). Yes. With Index: gcc/tree-cfg.c === --- gcc/tree-cfg.c (revision 179804) +++ gcc/tree-cfg.c (working copy) @@ -1456,7 +1460,7 @@ gimple_can_merge_blocks_p (basic_block a /* Do not remove user labels. */ if (!DECL_ARTIFICIAL (lab)) - return false; + ; } /* Protect the loop latches. */ we merge the blocks and vectorize both loops. The above patch is not acceptable though, which leaves making the vectorizer deal with trivial control-flow (or a new GIMPLE_DEBUG kind that would preserve the label?).
[Bug tree-optimization/50693] Loop optimization restricted by GOTOs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693 --- Comment #17 from David Edelsohn 2011-10-11 14:40:09 UTC --- LLVM appears to be able to recognize memset of any value, not just zero. And apparently performs control flow simplification before attempting to recognize the idiom, so it can expose the loop created by the convoluted GOTOs.
[Bug c++/27692] FAIL: g++.old-deja/g++.other/init5.C execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27692 --- Comment #12 from Jason Merrill 2011-10-11 14:38:42 UTC --- (In reply to comment #11) > what I'm suggesting is building the list of destructors dynamically for > executables and shared libraries. That sounds a lot like __cxa_atexit.
[Bug tree-optimization/50693] Loop optimization restricted by GOTOs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693 --- Comment #16 from Richard Guenther 2011-10-11 14:35:17 UTC --- (In reply to comment #14) > A memcmp too?!? (see also the discussion part of libstdc++/50661). No, only memset with zero.
[Bug tree-optimization/50693] Loop optimization restricted by GOTOs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #15 from Richard Guenther 2011-10-11
14:34:47 UTC ---
Note that it doesn't handle memset though, and the convoluted loop wouldn't be
easy to detect either.
size_t i = 0;
bool loop_cond = i < n;
while (loop_cond) {
goto copy_block;
loop_back:
loop_cond = i < n;
}
goto end;
copy_block:
v->chars[i] = c;
i++;
goto loop_back;
end:
v->chars[n] = '\0';
return v;
is simply trying to be too clever. I can't even understand that source ;)
What probably causes this is that we don't merge the blocks
# i_29 = PHI
copy_block:
D.3506_7 = v_20->chars;
D.3507_8 = D.3506_7 + i_29;
*D.3507_8 = c_9(D);
i_10 = i_29 + 1;
goto (loop_back);
loop_back:
loop_cond_11 = i_10 < n_3(D);
if (loop_cond_11 != 0)
goto (copy_block);
else
goto (end);
even though it's a fallthru edge. We don't do this to preserve user labels
for debugging (and mind, no code-gen differences between -g0 vs. -g).
[Bug c++/27692] FAIL: g++.old-deja/g++.other/init5.C execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27692 --- Comment #11 from dave.anglin at bell dot net 2011-10-11 14:18:52 UTC --- On 10/11/2011 9:08 AM, jason at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27692 > > --- Comment #10 from Jason Merrill 2011-10-11 > 13:08:19 UTC --- > Namespace-scope objects aren't the problem; we've always handled them fine. > The problem is with function-local statics, which aren't constructed until the > function is called, so we can't determine the order of construction at compile > time. We need to use atexit for them, and so for proper interleaving of > destructors we need to use atexit for namespace-scope objects as well, but > that > can cause trouble with dlclose, which is why we created __cxa_atexit. I understand this point. We don't use atexit on PA-RISC HP-UX for namespace-scope objects. On 32-bit HP-UX 11, we use a linker option to register initializer and finalizer routines for each executable and shared library. Thus, we don't have a problem with dlclose for namespace-scope objects. The problem is in using atexit for the function-local statics. Currently, collect2 builds a fixed list of destructors for namespace scope objects. Instead, what I'm suggesting is building the list of destructors dynamically for executables and shared libraries. The namespace-scope and function-local statics would be merged into one list that would be processed by the finalizer for the object. For systems that need to use atexit, I'm not sure whether this is worth the effort. The dlclose problem would remain. I'm not sure that destructor order would be deterministic in a multithreaded application. Dave
[Bug tree-optimization/50693] Loop optimization restricted by GOTOs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693 --- Comment #14 from Paolo Carlini 2011-10-11 14:14:24 UTC --- A memcmp too?!? (see also the discussion part of libstdc++/50661).
[Bug tree-optimization/50693] Loop optimization restricted by GOTOs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693 --- Comment #13 from Richard Guenther 2011-10-11 14:13:11 UTC --- (In reply to comment #12) > Because the vectorizer analysis occurs fairly early, I guess there is not a > lot > of opportunity to clean up the control flow. > > Should GCC have a memset peephole pass like LLVM? It does, ftree-loop-distribute-patterns, enabled by default.
[Bug tree-optimization/50693] Loop optimization restricted by GOTOs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693 --- Comment #12 from David Edelsohn 2011-10-11 14:06:34 UTC --- Because the vectorizer analysis occurs fairly early, I guess there is not a lot of opportunity to clean up the control flow. Should GCC have a memset peephole pass like LLVM?
[Bug middle-end/50074] [4.7 Regression] gcc.dg/sibcall-6.c execution test on x86_64 with -fPIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50074 Andreas Krebbel changed: What|Removed |Added CC||krebbel at gcc dot gnu.org --- Comment #9 from Andreas Krebbel 2011-10-11 13:16:16 UTC --- I see the same on s390x. gcc.dg/sibcall-6.c starts failing with r176042.
[Bug c++/50611] Error reporting routines re-entered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50611 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.2 --- Comment #9 from Paolo Carlini 2011-10-11 13:09:04 UTC --- Fixed mainline and 4.6.2.
[Bug c++/50611] Error reporting routines re-entered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50611 --- Comment #7 from paolo at gcc dot gnu.org 2011-10-11 13:07:55 UTC --- Author: paolo Date: Tue Oct 11 13:07:52 2011 New Revision: 179802 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179802 Log: 2011-10-11 Paolo Carlini PR c++/50611 * pt.c (tsubst_copy_and_build): If (complain & tf_error) is false do not call unqualified_name_lookup_error. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/50611] Error reporting routines re-entered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50611 --- Comment #8 from paolo at gcc dot gnu.org 2011-10-11 13:08:09 UTC --- Author: paolo Date: Tue Oct 11 13:08:05 2011 New Revision: 179803 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179803 Log: 2011-10-11 Paolo Carlini PR c++/50611 * pt.c (tsubst_copy_and_build): If (complain & tf_error) is false do not call unqualified_name_lookup_error. Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/pt.c
[Bug c++/27692] FAIL: g++.old-deja/g++.other/init5.C execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27692 --- Comment #10 from Jason Merrill 2011-10-11 13:08:19 UTC --- Namespace-scope objects aren't the problem; we've always handled them fine. The problem is with function-local statics, which aren't constructed until the function is called, so we can't determine the order of construction at compile time. We need to use atexit for them, and so for proper interleaving of destructors we need to use atexit for namespace-scope objects as well, but that can cause trouble with dlclose, which is why we created __cxa_atexit.
[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661 --- Comment #20 from paolo at gcc dot gnu.org 2011-10-11 12:39:23 UTC --- Author: paolo Date: Tue Oct 11 12:39:18 2011 New Revision: 179801 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179801 Log: 2011-10-11 Emil Wojak PR c++/50661 * include/bits/stl_algobase.h (equal): Compare arrays of pointers too with memcmp. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_algobase.h
[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #21 from Paolo Carlini 2011-10-11 12:40:00 UTC --- Applied.
[Bug fortran/50273] [4.5/4.6/4.7 Regression] -Walign-commons no longer effective
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50273 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Tobias Burnus 2011-10-11 12:34:36 UTC --- FIXED on the trunk (4.7) and on the 4.5 and 4.6 branches.
[Bug fortran/50273] [4.5/4.6/4.7 Regression] -Walign-commons no longer effective
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50273 --- Comment #5 from Tobias Burnus 2011-10-11 12:33:26 UTC --- Author: burnus Date: Tue Oct 11 12:33:22 2011 New Revision: 179800 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179800 Log: 2011-10-11 Tobias Burnus PR fortran/50273 * trans-common.c (translate_common): Fix -Walign-commons check. 2011-10-11 Tobias Burnus PR fortran/50273 * gfortran.dg/common_16.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/common_16.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/trans-common.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug c/50695] double comparison broken after computation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695 --- Comment #4 from Marc Glisse 2011-10-11 12:24:18 UTC --- And anyway 10^-6 is not representable exactly as a double.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #118 from Markus Trippelsdorf 2011-10-11 12:18:21 UTC --- Probably a Mozilla bug. See: https://bugzilla.mozilla.org/show_bug.cgi?id=693563
[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661 Paolo Carlini changed: What|Removed |Added CC|bernds at codesourcery dot | |com | --- Comment #19 from Paolo Carlini 2011-10-11 12:08:00 UTC --- Ok, thanks, let's go ahead and be done with it. Between now and the release of 4.7.0 target maintainers will have plenty of time to report back issues.
[Bug c++/27692] FAIL: g++.old-deja/g++.other/init5.C execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27692 --- Comment #9 from dave.anglin at bell dot net 2011-10-11 12:06:25 UTC --- On 10-Oct-11, at 5:45 PM, paolo.carlini at oracle dot com wrote: > I honestly don't understand how such a warning would look like: like > warning > for any snippet of code where destructors could run in an > unpredictable order? > I'm adding Jason in CC in case he can imagine something in this > area... > otherwise I guess I would ask you or Steve to just change those > testcases to be > skipped instead of xfailed and be done with this very old PR. In principle, I believe this could be fixed on 32-bit PA-RISC HP-UX. Initializer and finalizer routines are registered by collect2 for executables and shared objects. So, it should be possible to run all destructors in reverse order of construction even for dynamically loaded objects. It's using atexit that's the problem. 64-bit HP-UX is somewhat different. It uses .init_array/.fini_array but again this works for shared libraries, etc. Dave -- John David Anglindave.ang...@bell.net
[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661 Bernd Schmidt changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #18 from Bernd Schmidt 2011-10-11 12:03:09 UTC --- I think there are better people to answer ARM questions, but to the best of my knowledge, there is no problem on that target. I've tried to grep for something that might have an issue, and only found a (define_expand "canonicalize_funcptr_for_compare" and /* We need a libcall to canonicalize function pointers on TARGET_ELF32. */ #define CANONICALIZE_FUNCPTR_FOR_COMPARE_LIBCALL \ "__canonicalize_funcptr_for_compare" in config/pa.
[Bug lto/50687] Missing symbols with -flto -fvisibility=hidden on 4.6.x but not on 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50687 --- Comment #4 from Lassi Tuura 2011-10-11 12:00:47 UTC --- Right, as far as I can tell at the moment visibility option is somewhat peripheral to the issue. The main difference you see with LTO vs. no LTO appears to be whether code for the type is generated at all. As far as I can tell, once the compiler decides to generate code for 'bar', you get the same behaviour in all cases. The visibility controls only apply after that. Whether it's an issue that LTO in 4.6.x generates references to otherwise unreferenced types I can't say. I'd say it is not invalid, though perhaps undesirable. But once code is generated for types like 'bar', the app needs to make sure it uses correct visibility controls. As far as I understand, the actual upstream problem is that 'bar' really comes from a header file, from another package. The #include for that header is not using visibility push/pop to reset visibility to 'default', so the header inherits the 'hidden' visibility from command line. At the moment, without visibility directives, there's a side effect that 4.6.x LTO generates references to otherwise unused types from those headers, resulting in link errors. But I'd suggest this usage is quite fragile - the moment anything from those headers is actually referenced, the app needs to be fixed to reset visibility to 'default' around #includes anyway (because the module in question is being compiled with -fvisibility=hidden). Of course if 4.6.x can be amended to prune types from LTO more aggressively, it will help to avoid this particular issue. I'm just not sure it will actually fix all the upstream problems, I rather suspect some types coming from headers are actually referenced in ways which in the end will require full visibility management in the source code.
[Bug tree-optimization/50204] [4.5/4.6 Regression] Missed fully redundant load found in crafty (SPEC 2k)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50204 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.7.0 Resolution||FIXED Target Milestone|4.5.4 |4.7.0 Summary|[4.5/4.6/4.7 Regression]|[4.5/4.6 Regression] Missed |Missed fully redundant load |fully redundant load found |found in crafty (SPEC 2k) |in crafty (SPEC 2k) Known to fail|4.7.0 | --- Comment #11 from Richard Guenther 2011-10-11 11:58:09 UTC --- Fixed for 4.7, wontfix on release branches.
[Bug tree-optimization/50204] [4.5/4.6/4.7 Regression] Missed fully redundant load found in crafty (SPEC 2k)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50204 --- Comment #10 from Richard Guenther 2011-10-11 11:57:28 UTC --- Author: rguenth Date: Tue Oct 11 11:57:23 2011 New Revision: 179799 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179799 Log: 2011-10-11 Richard Guenther PR tree-optimization/50204 * tree-ssa-alias.c (get_continuation_for_phi_1): Split out two argument handling from ... (get_continuation_for_phi): ... here. Handle arbitrary number of PHI args. * gcc.dg/tree-ssa/ssa-fre-36.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-36.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-alias.c
[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-11 CC||bernds at codesourcery dot ||com Ever Confirmed|0 |1 --- Comment #17 from Paolo Carlini 2011-10-11 11:53:45 UTC --- Ah, thanks for the very complete information, Andreas. Thus, I say, let's add in CC also a person knowledgeable about ARM, and take a final decision whether we want to apply this change for 4.7.0 unconditionally. Bernd, can you tell us whether it would be safe to compare ARM pointers with memcmp?
[Bug debug/40713] Overlapping .debug_ranges (C++)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40713 --- Comment #6 from Paulo J. Matos 2011-10-11 11:48:08 UTC --- (In reply to comment #5) > As the home page says, 4.4.x is the oldest maintained branch.. Right! Sorry for the noise.
[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661 --- Comment #16 from Andreas Krebbel 2011-10-11 11:41:12 UTC --- (In reply to comment #15) > Andreas, can I have your feedback about this? Is it safe or not to compare > s390 > pointers with memcmp? On s390 with 31 bit addressing the uppermost bit indicates to the hardware that 31 bit addressing is used instead of just 24 bit. This indeed is a problem when creating pointers from integers, what is anyway not backed by the C standard, or when using __builtin_return_address without masking the bits. However GCC does *not* mask the bits when comparing two pointer values. So (void*)0x == (void*)0x8000 does *not* evaluate to true on s390. To my understanding using a memcmp would not break things for s390. If it is broken with memcmp it was broken before as well. I don't know how this works with ARM. I think they put their THUMB markers into the lower order bits of an address and perhaps we should better check how they implement a pointer compare.
[Bug c++/50611] Error reporting routines re-entered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50611 --- Comment #6 from Paolo Carlini 2011-10-11 11:40:38 UTC --- I mean, fixes the ICE both in mainline and in 4_6-branch. Indeed, the latter seems more serious, because otherwise for the original testcase we produce no useful diagnostics at all.
[Bug c++/50611] Error reporting routines re-entered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50611 --- Comment #5 from Paolo Carlini 2011-10-11 11:35:42 UTC --- I see. It does, anyway.
[Bug tree-optimization/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678 --- Comment #9 from Eric Botcazou 2011-10-11 11:20:41 UTC --- > It would be nice to know whether this particular FAIL is the failure > of some checking mechanism or a genuine wrong-code bug. I suppose > it's the former, and for -fstack-check we could simply disable alloca > folding. I'd rather not, -fstack-check should affect code generation as little as possible beyond the checking code itself. A conforming Ada compiler is supposed to do stack checking by default. I'll try to get my hands on a Darwin machine.
[Bug c++/50611] Error reporting routines re-entered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50611 --- Comment #4 from Jakub Jelinek 2011-10-11 11:20:47 UTC --- The reduced testcase yes. But please try the original testcase in 4.6, whether your patch fixes it.
[Bug c++/50611] Error reporting routines re-entered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50611 Paolo Carlini changed: What|Removed |Added Version|4.6.1 |4.7.0 --- Comment #3 from Paolo Carlini 2011-10-11 11:18:49 UTC --- By the way, I can see this only in mainline, Jakub. (which indeed makes sense given that my patchlet touches pt.c and the crash happens in the middle of "In instantiation...")
[Bug c++/50685] Compiler segmentation fault on AIX when constructors and destructors are implemented in the implementation file (non-inline).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50685 --- Comment #6 from Barry Matheney 2011-10-11 11:11:22 UTC --- Thanks David for all of your insight and info. I will forward this info to our sysadmins to further investigate this assembler issue. (In reply to comment #5) > AIX 5.3 TL10 (as well as AIX 6.1 TL05 and AIX 7.1 TL00) instroduced AIX > assembler changes with some bugs. An AIX iFix for AIX 5.3 is available (APAR > IZ98385 for AIX 5.3 TL10, APAR IZ98477 for AIX 5.3 TL11 and IZ98134 for AIX > 5.3 > TL12). I know the assembler fixes address another bug with the assembler > generating corrupt object files, but I do not know if it fixes this bug of the > assembler crashing. > > This is an AIX bug and you need to contact AIX Customer Support.
[Bug middle-end/50638] [4.7 Regression] emulated TLS fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638 Michael Matz changed: What|Removed |Added CC||jojelino at gmail dot com --- Comment #14 from Michael Matz 2011-10-11 11:08:17 UTC --- *** Bug 50658 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/50658] [4.7 regression] SIGSEGV in tree-flow-inline.h:562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50658 Michael Matz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Michael Matz 2011-10-11 11:08:17 UTC --- I'm pretty sure this is emutls too, at least I can't reproduce it anymore with a cross with r179745. Dup of PR50638. *** This bug has been marked as a duplicate of bug 50638 ***
