[Bug fortran/40167] wrong initialization of local variable in a recursive subroutine
--- Comment #2 from burnus at gcc dot gnu dot org 2009-05-18 06:41 --- I can reproduce the problem with GCC 4.2.1, but it works with 4.3.3 [gcc-4_3-branch revision 144878]. Thus it seems to be fixed in newer 4.3 versions than your 4.3.0 2008-03-05. And it works in 4.4.x and 4.5. Please update to 4.3.4, 4.4.0 or 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40167
[Bug other/40159] [4.5 regression] make all ignores build failures
--- Comment #1 from aoliva at gcc dot gnu dot org 2009-05-18 06:54 --- I (and the automated regression testers) can't seem to duplicate this. May I have a bit more detail as to the circumstances in which the problem occurs, please? -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40159
[Bug target/40129] M16C invalid shift count used by pack_d - ashldi3
--- Comment #2 from eightdot at hotmail dot com 2009-05-18 07:13 --- mm it apreas to be fixed somewhere between 4.1.1 and 4.4.2 (revision 109661 and 109987 seams to be good candidates afaik in viewcvs but i cant find which release this is corresponding to..) input main.c: output /usr/libexec/gcc/m32c-unknown-elf/4.1.1/cc1 -mcpu=m16c main.c: enter #13 mov.w r1,-10[fb] mov.w #4660,-6[fb] mov.w #22136,-8[fb] mov.w -10[fb],r0 mov.w r0,-13[fb] mov.w -6[fb],r2 mov.w -8[fb],r0 mov.b -13[fb],r1l neg.b r1l mov.b r1l,-11[fb] mov.b -11[fb],r1l mov.b r1l,r1h sha.l r1h,r2r0 mov.w r2,-2[fb] mov.w r0,-4[fb] mov.w -4[fb],r0 exitd output /usr/src/cross/m32c/build/gcc-4.4.0/gcc/cc1 -mcpu=m16c main.c _main: enter #15-2 mov.w r1,-10[fb] mov.w #4660,-6[fb] mov.w #22136,-8[fb] mov.w -10[fb],r0 mov.w r0,-13[fb] mov.w -6[fb],r2 mov.w -8[fb],r0 mov.b -13[fb],r1l neg.b r1l mov.b r1l,-11[fb] cmp.b #-16,-11[fb] jge .L2 sha.l #-8,r2r0 sha.l #-8,r2r0 add.b #16,-11[fb] .L2: mov.b -11[fb],r1h sha.l r1h,r2r0 mov.w r2,-2[fb] mov.w r0,-4[fb] mov.w -4[fb],r0 exitd so it works ok for 4.4.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40129
[Bug target/40129] M16C invalid shift count used by pack_d - ashldi3
--- Comment #3 from eightdot at hotmail dot com 2009-05-18 07:15 ---
input:
int main(int argc)
{
long a=0x12345678;
long b;
b=aargc;
return (b);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40129
[Bug libgcj/36658] Building gcj for arm linux from trunk (gcc 4.4.0): libjava/gcj/array.h:24: internal compiler error: verify_gimple failed
--- Comment #2 from debian-gcc at lists dot debian dot org 2009-05-18 07:33 --- a native build for arm-linux-gnueabi works fine in 4.4.0, e.g. https://buildd.debian.org/fetch.cgi?pkg=gcj-4.4ver=4.4.0-2arch=armelstamp=1241854512file=log Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36658
[Bug bootstrap/38867] [Regression] gcc 4.4.0 20090114 - libjava/configure sets NONE/share/python, need ${prefix}/share/python
--- Comment #3 from debian-gcc at lists dot debian dot org 2009-05-18 07:39 --- looks much like an expansion issue in automake, which was fixed for automake-1.11, but I fail to see how it gets wrongly expanded in the current 4.4.0 release. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524176 Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38867
[Bug ada/40166] [4.4/4.5 regression] Ada compiler unable to build libraries
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2009-05-18 07:42 --- Thanks for reporting and fixing this. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED GCC build triplet|all | GCC host triplet|all | GCC target triplet|all | Resolution||FIXED Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40166
[Bug libgcj/35367] Linux x86 build (with --enable-targets=all, so also building with cross-to-x64 multilib configuration) fails in libjava (prims.cc)
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-05-18 07:44 --- debian doesn't have all libraries needed as build dependencies as 64bit versions, so it's clear that the build fails. IMO not a GCC issue. Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35367
[Bug fortran/40168] missing unrolling/scalarization/reassoc/free
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-05-18 08:53 --- I'm now testing the one-liner. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168
[Bug fortran/36947] Attributes not fully checked comparing actual vs dummy procedure
--- Comment #6 from janus at gcc dot gnu dot org 2009-05-18 09:19 --- Subject: Bug 36947 Author: janus Date: Mon May 18 09:19:20 2009 New Revision: 147655 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147655 Log: 2009-05-18 Janus Weil ja...@gcc.gnu.org PR fortran/36947 PR fortran/40039 * expr.c (gfc_check_pointer_assign): Check intents when comparing interfaces. * gfortran.h (typedef struct gfc_intrinsic_arg): Add 'intent' member. (gfc_compare_interfaces): Additional argument. * interface.c (operator_correspondence): Add check for equality of intents, and new argument 'intent_check'. (gfc_compare_interfaces): New argument 'intent_check', which is passed on to operator_correspondence. (check_interface1): Don't check intents when comparing interfaces. (compare_parameter): Do check intents when comparing interfaces. * intrinsic.c (add_sym): Add intents for arguments of intrinsic procedures. (add_sym_1,add_sym_1s,add_sym_1m,add_sym_2,add_sym_2s,add_sym_3, add_sym_3ml,add_sym_3red,add_sym_3s,add_sym_4): Use INTENT_IN by default. (add_sym_1_intent,add_sym_1s_intent,add_sym_2s_intent,add_sym_3s_intent) : New functions to add intrinsic symbols, specifying custom intents. (add_sym_4s,add_sym_5s): Add new arguments to specify intents. (add_functions,add_subroutines): Add intents for various intrinsics. * resolve.c (check_generic_tbp_ambiguity): Don't check intents when comparing interfaces. * symbol.c (gfc_copy_formal_args_intr): Copy intent. 2009-05-18 Janus Weil ja...@gcc.gnu.org PR fortran/36947 PR fortran/40039 * gfortran.dg/interface_27.f90: New. * gfortran.dg/interface_28.f90: New. * gfortran.dg/proc_ptr_11.f90: Fixing invalid test case. * gfortran.dg/proc_ptr_result_1.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/interface_27.f90 trunk/gcc/testsuite/gfortran.dg/interface_28.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/proc_ptr_11.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_result_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36947
[Bug fortran/40039] Procedures as actual arguments: Check intent of arguments
--- Comment #4 from janus at gcc dot gnu dot org 2009-05-18 09:19 --- Subject: Bug 40039 Author: janus Date: Mon May 18 09:19:20 2009 New Revision: 147655 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147655 Log: 2009-05-18 Janus Weil ja...@gcc.gnu.org PR fortran/36947 PR fortran/40039 * expr.c (gfc_check_pointer_assign): Check intents when comparing interfaces. * gfortran.h (typedef struct gfc_intrinsic_arg): Add 'intent' member. (gfc_compare_interfaces): Additional argument. * interface.c (operator_correspondence): Add check for equality of intents, and new argument 'intent_check'. (gfc_compare_interfaces): New argument 'intent_check', which is passed on to operator_correspondence. (check_interface1): Don't check intents when comparing interfaces. (compare_parameter): Do check intents when comparing interfaces. * intrinsic.c (add_sym): Add intents for arguments of intrinsic procedures. (add_sym_1,add_sym_1s,add_sym_1m,add_sym_2,add_sym_2s,add_sym_3, add_sym_3ml,add_sym_3red,add_sym_3s,add_sym_4): Use INTENT_IN by default. (add_sym_1_intent,add_sym_1s_intent,add_sym_2s_intent,add_sym_3s_intent) : New functions to add intrinsic symbols, specifying custom intents. (add_sym_4s,add_sym_5s): Add new arguments to specify intents. (add_functions,add_subroutines): Add intents for various intrinsics. * resolve.c (check_generic_tbp_ambiguity): Don't check intents when comparing interfaces. * symbol.c (gfc_copy_formal_args_intr): Copy intent. 2009-05-18 Janus Weil ja...@gcc.gnu.org PR fortran/36947 PR fortran/40039 * gfortran.dg/interface_27.f90: New. * gfortran.dg/interface_28.f90: New. * gfortran.dg/proc_ptr_11.f90: Fixing invalid test case. * gfortran.dg/proc_ptr_result_1.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/interface_27.f90 trunk/gcc/testsuite/gfortran.dg/interface_28.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/proc_ptr_11.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_result_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40039
[Bug fortran/40039] Procedures as actual arguments: Check intent of arguments
--- Comment #5 from janus at gcc dot gnu dot org 2009-05-18 09:28 --- The commit in comment #4 implements the basic checking of the intents. ToDo: * Improve the error message, which is currently just Type/rank mismatch in argument Should specify exactly what is not matching, and in which argument. * Fix the intents of non-std intrinsics (which are currently all intent(in)). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40039
[Bug fortran/36947] Attributes not fully checked comparing actual vs dummy procedure
--- Comment #7 from janus at gcc dot gnu dot org 2009-05-18 09:36 --- The commit in comment #6 implements the checking for intents. ToDo: * check for OPTIONAL * better error messages * recursive check (see comment #2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36947
[Bug other/40159] [4.5 regression] make all ignores build failures
--- Comment #2 from schwab at linux-m68k dot org 2009-05-18 09:37 ---
The last command in the all rule is : which is always successfull:
# The target built for a native non-bootstrap build.
.PHONY: all
all:
@if gcc-bootstrap
[ -f stage_final ] || echo stage3 stage_final
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
$(MAKE) $(RECURSE_FLAGS_TO_PASS) `cat stage_final`-bubble
@endif gcc-bootstrap
@: $(MAKE); $(unstage)
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
@if gcc-bootstrap
if [ -f stage_last ]; then : ; \
TFLAGS=$(STAGE$(shell sed s,^stage,, stage_last)_TFLAGS); \
$(MAKE) $(TARGET_FLAGS_TO_PASS) all-host all-target; \
else \
@endif gcc-bootstrap
$(MAKE) $(RECURSE_FLAGS_TO_PASS) all-host all-target; \
@if gcc-bootstrap
fi; \
@endif gcc-bootstrap
:
--
schwab at linux-m68k dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |schwab at linux-m68k dot org
|dot org |
Status|WAITING |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-05-18 09:37:41
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40159
[Bug libstdc++/40160] -fno-rtti vs _GLIBCXX_DEBUG
--- Comment #8 from jay dot foad at gmail dot com 2009-05-18 09:46 --- Thanks Paolo! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40160
[Bug tree-optimization/39907] Aligned access to unaligned address
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-18 10:03 --- The bug is that snapshot_ret: movq%rdi, rdi(%rip) call*callthis(%rip) does not preserve stack alignment. But we assume that correct alignment is preserved over the indirect function call(?). HJ? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hjl at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-18 10:03:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39907
[Bug c++/40183] New: g++.dg/tls/static-1.C, execution abort
# g++ static-1.C static-1a.cc -O2 # export LD_LIBRARY_PATH=/import/dr3/s10/gcc-4.4.0/lib/ # ./a.out Abort (core dumped) The error would be gone if /usr/sfw/lib/libstdc++.so.6 is linked. so I assume the error lives in the library libstdc++.so.6 that gcc 4.4 provides. Any information that you need, please let me know. # g++ -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: /import/iropt5/lijuan/plain-gcc/gcc-git/configure --prefix=/import/dr3/s10/gcc-4.4.0 --enable-languages=c,c++,fortran --disable-gnattools --enable-shared --disable-static --with-system-zlib --enable-checking=release --disable-gnattools --enable-tls --disable-bootstrap Thread model: posix gcc version 4.4.0 20090421 (prerelease) (GCC) # uname -a SunOS clpt-v490-1 5.10 Generic_118833-33 sun4u sparc SUNW,Sun-Fire-V490 -- Summary: g++.dg/tls/static-1.C, execution abort Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hailijuan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40183
[Bug tree-optimization/39999] [4.4 Regression] gcc 4.4.0 compiles in infinite loop
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-05-18 10:13 --- Subject: Bug 3 Author: rguenth Date: Mon May 18 10:13:43 2009 New Revision: 147657 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147657 Log: 2009-05-18 Richard Guenther rguent...@suse.de PR tree-optimization/3 * gimple.h (gimple_expr_type): Use the expression type looking through useless conversions. * tree-ssa-sccvn.c (vn_nary_op_lookup_stmt): Use gimple_expr_type. (vn_nary_op_insert_stmt): Likewise. (simplify_binary_expression): Likewise. * gcc.c-torture/compile/pr3.c: New testcase. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr3.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/gimple.h branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
[Bug tree-optimization/39999] [4.4 Regression] gcc 4.4.0 compiles in infinite loop
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-05-18 10:14 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
[Bug c++/40183] g++.dg/tls/static-1.C, execution abort
--- Comment #1 from hailijuan at gmail dot com 2009-05-18 10:07 --- Created an attachment (id=17885) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17885action=view) static-1.C and static-1a.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40183
[Bug fortran/40168] missing unrolling/scalarization/reassoc/free
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-05-18 10:24 --- Subject: Bug 40168 Author: rguenth Date: Mon May 18 10:24:34 2009 New Revision: 147659 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147659 Log: 2009-05-18 Richard Guenther rguent...@suse.de PR fortran/40168 * trans-expr.c (gfc_trans_zero_assign): For local array destinations use an assignment from an empty constructor. * gfortran.dg/array_memset_2.f90: Adjust. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/array_memset_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168
[Bug libstdc++/40184] New: locale(const char* std_name) can create invalid facets for nonuniform locale
Constructor locale(const char* std_name), when called with name of nonuniform
locale (like LC_CTYPE=...;LC_COLLATE=...;...), can create locale with
incorrect content of some its facets: these facets differ from facets of
locale, created via locale(const locale other, const char* std_name, category)
with subsequent replacing of categories. While this locale has same name as
argument of locale(const char* std_name).
This behaviour contradicts description of member-function name() (22.1.1.3,
p5):
If *this has a name, then locale(name().c_str()) is equivalent to *this.
Example below demonstrates contradiction of this statement on curr_symbol()
property of moneypunctwchar_t facet:
#include locale
#include cassert
int main()
{
using namespace std;
locale loc(locale(C), en_GB.utf8, locale::monetary);
const moneypunctwchar_t mp =
use_facetmoneypunctwchar_t (loc);
locale loc_copy(loc.name().c_str());
const moneypunctwchar_t mp_copy =
use_facetmoneypunctwchar_t (loc_copy);
assert(mp.curr_symbol() == mp_copy.curr_symbol());
return 0;
}
It seems, the source of the problem is a method of filling properties of named
locale. E.g., for moneypunctwchar_t facet, the method performs the following:
1)sets the current POSIX locale with given name,
2)sets some properties of C++ locale, using __nl_langinfo_l() function call,
3)the rest properties of C++ locale are obtained from char-versions of them
using mbsrtowcs()-like functions.
But mbsrtowcs() use current LC_CTYPE category, which name may differ from the
name of LC_MONETARY category in nonuniform locale. So mbsrtowcs() assumes that
string, passed to it, belongs to one charset(according to LC_TYPE category
name), while it belongs to the another (according to LC_MONETARY category
name).
This fact entails wrong property value, obtained via such call to mbsrtowcs().
Up to garbage, because implementation doesn't verify result of mbsrtowcs(),
which doesn't set terminating '\0' in case of error.
The fact, that the implementation doest't verify result of mbsrtowcs(), also
seems strange - absence of terminating '\0' may lead to SIGFAULT.
--
Summary: locale(const char* std_name) can create invalid facets
for nonuniform locale
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsyvarev at ispras dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40184
[Bug fortran/40168] missing unrolling/scalarization/reassoc/free
--- Comment #14 from jv244 at cam dot ac dot uk 2009-05-18 12:19 --- Created an attachment (id=17886) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17886action=view) simplified testcase for common subexpressions. Richard, thanks very much for the first patch. I tried to get a better testcase for the issue with the number of multiplies being too large (compile with gfortran -O3 -march=native -ffast-math -cpp test.f90). This is the newly attached test_reassoc.f90. The module contains two equivalent subroutines S1 and S2. In S1, gcc manages to reduce the multiplies nearly to the optimal one (I believe optimal is 81+81+9+9=180, gcc finds 198). In S2, which introduces a temporary array somewhat like in the original, this doesn't happen, and the number of multiplies is 324. Looks like the introduction of the temporary array blocks some optimisation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168
[Bug fortran/40176] Fortran 2003: Procedure pointers with array return value
--- Comment #2 from janus at gcc dot gnu dot org 2009-05-18 12:28 --- This test case with 'dynamic' array size produces a gimplification error: PROGRAM test_prog ABSTRACT INTERFACE FUNCTION fn_template(n,x) RESULT(y) INTEGER, INTENT(in) :: n REAL, INTENT(in) :: x(n) REAL :: y(n) END FUNCTION fn_template END INTERFACE TYPE ProcPointerArray PROCEDURE(fn_template), POINTER, NOPASS :: f END TYPE ProcPointerArray TYPE (ProcPointerArray) :: f_array(1) PROCEDURE(fn_template), POINTER :: f REAL :: tre(2) f_array(1)%f = triple ! gimplification error f = f_array(1)%f tre = f(2,[2.,4.]) PRINT*, tre CONTAINS FUNCTION triple(n,x) RESULT(tre) INTEGER, INTENT(in) :: n REAL, INTENT(in) :: x(n) REAL :: tre(n) tre = 3.*x END FUNCTION triple END PROGRAM test_prog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40176
[Bug ada/40185] New: Segmentation fault on legal program
(Debian bug #519336) The following illegal program causes gnat1 to crash with a segmentation fault: with Ada.Unchecked_Conversion; package Essai is type Attributed_Character is record I : Integer; end record; type Video_Array is array (Integer range 0 .. 1) of Attributed_Character; type Video_Access is access Video_Array; function To_VA is new Ada.Unchecked_Conversion (Integer, Video_Access); Video : Video_Access := To_VA (0); -- line 9 end Essai; /usr/lib/gcc/x86_64-linux-gnu/4.3.3/gnat1 -quiet -dumpbase essai.ads - -mtune=generic essai.ads -o tutu.s segmentation fault Removing line 9 causes GNAT not to segfault. Also confirmed on GNAT GPL 2008 on x86_64-linux-gnu and with GCC 4.3.3 on powerpc-linux-gnu. -- Summary: Segmentation fault on legal program Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40185
[Bug libstdc++/40184] locale(const char* std_name) can create invalid facets for nonuniform locale
--- Comment #1 from paolo dot carlini at oracle dot com 2009-05-18 12:40 --- Ok. Then, what do you think, would it be at least an improvement, constructing on the fly a uniform locale corresponding to the LC_MONETARY category and switching to it instead, before calling mbsrtowcs? Performance-wise, should not be a big issue, because of caching. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo dot carlini at oracle ||dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-18 12:40:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40184
[Bug c++/40186] New: floating point comparision works wrong ( !(a b) (b a) is true )
When comparing the return value of two functions (which both return double and do always return the same value), I have the case that (a b) (b a) (whereby they should be equal) in a real world application. I tried to reproduce it, though in the test case, I have a slightly different case, which should be also wrong: !(a b) (b a) is true (whereby it should be a == b). Probably both problems are related. The behaviour pretty much depend on the optimisation. With -O0 and -Os, I am hitting the problem, but not so with -O1, -O2 and -O3. -- Summary: floating point comparision works wrong ( !(a b) (b a) is true ) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ich at az2000 dot de GCC build triplet: tried with GCC 4.1.2, 4.3.2 and 4.4.0 GCC host triplet: Gentoo Linux i386 GCC target triplet: Linux i386 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40186
[Bug c++/40186] floating point comparision works wrong ( !(a b) (b a) is true )
--- Comment #1 from ich at az2000 dot de 2009-05-18 13:11 --- Created an attachment (id=17887) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17887action=view) testcase (c++) This is the test code. I am hitting the wrong ordering 2 code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40186
[Bug c++/40186] floating point comparision works wrong ( !(a b) (b a) is true )
--- Comment #2 from ich at az2000 dot de 2009-05-18 13:16 ---
This is a real problem, because in my real application, I tried to use a very
similar order in a std::settmp*,CustomOrder, defined like this:
struct CustomOrder {
bool operator()(const Tmp* a, const Tmp* b) const {
return a-get() b-get();
}
};
STLport gives this assertion when inserting Tmp pointers with equal values
(returned by get() function):
/usr/include/stlport/stl/debug/_tree.h(63): STL error : Invalid strict weak
ordering predicate, if pred(a, b) then we should have !pred(b, a)
/usr/include/stlport/stl/debug/_tree.h(63): STL assertion failure:
!_M_non_dbg_cmp(__rhs, __lhs)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40186
[Bug c++/40186] floating point comparision works wrong ( !(a b) (b a) is true )
--- Comment #3 from ich at az2000 dot de 2009-05-18 13:17 --- Some compiler information: a...@acompneu ~/Programmierung $ g++ -Os -v -ggdb test_order.cpp -o test_order ./test_order Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.4.0/work/gcc-4.4.0/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.4.0 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --enable-java-awt=gtk --with-arch=i686 --enable-languages=c,c++,java,objc,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.0' Thread model: posix gcc version 4.4.0 (Gentoo 4.4.0) COLLECT_GCC_OPTIONS='-Os' '-v' '-ggdb' '-o' 'test_order' '-shared-libgcc' '-mtune=generic' '-march=i686' /usr/libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1plus -quiet -v -D_GNU_SOURCE test_order.cpp -quiet -dumpbase test_order.cpp -mtune=generic -march=i686 -auxbase test_order -ggdb -Os -version -o /tmp/cc2REzjQ.s ignoring nonexistent directory /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/include/g++-v4 /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/include/g++-v4/i686-pc-linux-gnu /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/include/g++-v4/backward /usr/local/include /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/include /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/include-fixed /usr/include End of search list. GNU C++ (Gentoo 4.4.0) version 4.4.0 (i686-pc-linux-gnu) compiled by GNU C version 4.4.0, GMP version 4.2.4, MPFR version 2.4.1-p1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 13a3af7fd37a02ca6104ed29e33fcca6 COLLECT_GCC_OPTIONS='-Os' '-v' '-ggdb' '-o' 'test_order' '-shared-libgcc' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/bin/as -V -Qy -o /tmp/cc5XznpU.o /tmp/cc2REzjQ.s GNU assembler version 2.18 (i686-pc-linux-gnu) using BFD version (GNU Binutils) 2.18 COMPILER_PATH=/usr/libexec/gcc/i686-pc-linux-gnu/4.4.0/:/usr/libexec/gcc/i686-pc-linux-gnu/4.4.0/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/libexec/gcc/i686-pc-linux-gnu/4.4.0/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/bin/ LIBRARY_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/lib/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-Os' '-v' '-ggdb' '-o' 'test_order' '-shared-libgcc' '-mtune=generic' '-march=i686' /usr/libexec/gcc/i686-pc-linux-gnu/4.4.0/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test_order /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../crt1.o /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../crti.o /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/crtbegin.o -L/usr/lib/gcc/i686-pc-linux-gnu/4.4.0 -L/usr/lib/gcc/i686-pc-linux-gnu/4.4.0 -L/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/lib -L/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../.. /tmp/cc5XznpU.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/crtend.o /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../crtn.o wrong ordering 2! 993.747, 993.747 d = 990.91854039579629898 v1 = 1600861594,1600861595 v2 = 1600861596,1600861593 8 chars: 3c7f1bcaf90d8f40 d = 990.91854039579629898 v1 = 5f6b359a,5f6b359b v2 = 5f6b359c,5f6b3599 8 chars: 3c7f1bcaf90d8f40 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40186
Re: [Bug c/38286] configure: error: cannot compute suffix of object files - cannot find as
Hi, I'm trying to install gcc to get gcj on a mac. I found that I have to put in an excessive amount of flags to even get a start on compiling gcc. For example: export CC='gcc -arch x86_64';export GXX='g++ -arch x86_64';CFLAGS='-arch x86_64';export CXXFLAGS='-arch x86_64';export CPPFLAGS='-arch x86_64' ./configure GXX='g++ -arch x86_64' CC='gcc -arch x86_64' CFLAGS='-arch x86_64' CXXFLAGS='-arch x86_64' CPPFLAGS='-arch x86_64' Then I get the error of checking for i386-apple-darwin9.5.0-gcc... /Users/smcguffee/WHITEHOUSE_LAB/PROGRAMS/GCC/SVN/GCJ/host-i386-apple-darwin9.5.0/gcc/xgcc -B/Users/smcguffee/WHITEHOUSE_LAB/PROGRAMS/GCC/SVN/GCJ/host-i386-apple-darwin9.5.0/gcc/ -B/usr/local/i386-apple-darwin9.5.0/bin/ -B/usr/local/i386-apple-darwin9.5.0/lib/ -isystem /usr/local/i386-apple-darwin9.5.0/include -isystem /usr/local/i386-apple-darwin9.5.0/sys-include checking for suffix of object files... configure: error: in `/Users/smcguffee/WHITEHOUSE_LAB/PROGRAMS/GCC/SVN/GCJ/i386-apple-darwin9.5.0/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage1-target-libgcc] Error 1 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 as described above. If I understand it correctly, you are saying that there is something called bin-utils that I need to get in addition to the gnu downloads? Can you please give me more information about this? I couldn't find anything called bin-utils and I don't know where to look. Thanks, Sean Bugzilla from gcc-bugzi...@gcc.gnu.org wrote: --- Comment #1 from brian at dessent dot net 2008-11-27 11:29 --- Subject: Re: New: configure: error: cannot compute suffix of object files - cannot find as The assembler is not part of gcc. You need to build and install binutils for your target (which will result in the cross-assembler and cross-linker) before attempting to build the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38286 -- View this message in context: http://www.nabble.com/-Bug-c-38286---New%3A-configure%3A-error%3A-cannot-compute-suffix-of-object-files---cannot-find-as-tp20717408p23595885.html Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug c++/40186] floating point comparison is wrong ( !(a b) (b a) is true )
--- Comment #4 from ich at az2000 dot de 2009-05-18 13:38 --- Created an attachment (id=17888) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17888action=view) simpler test case (now for wrong ordering case 1) I was able to reproduce the first case now (wrong ordering 1). I also removed some parts from the test case, it's much shorter now. This occurs only with -Os now, in all other cases, I don't hit the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40186
[Bug target/25249] inconsistent code for template function calls
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-18 14:10 --- I can't see this with 4.3, 4.4 or trunk today. Can you provide a more recent reference to this problem ? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25249
[Bug c++/40186] floating point comparison is wrong ( !(a b) (b a) is true )
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-05-18 14:11 --- *** This bug has been marked as a duplicate of 323 *** -- 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=40186
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #128 from pinskia at gcc dot gnu dot org 2009-05-18 14:11 --- *** Bug 40186 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ich at az2000 dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug tree-optimization/39907] Aligned access to unaligned address
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-05-18 14:25 --- (In reply to comment #3) The bug is that snapshot_ret: movq%rdi, rdi(%rip) call*callthis(%rip) does not preserve stack alignment. But we assume that correct alignment is preserved over the indirect function call(?). Are you sure that this is not an inline-asm? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39907
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #129 from ich at az2000 dot de 2009-05-18 14:24 --- I am a bit wondering if this bug is also for the case (a b) (b a) == true. Is it? Because if so, this becomes way more serious, as for example std::setdouble is broken then (and depending on the STL implementation, it will throw assertions then). If not, I guess my bug #40186 is not a duplicate of this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug libstdc++/40184] locale(const char* std_name) can create invalid facets for nonuniform locale
--- Comment #2 from tsyvarev at ispras dot ru 2009-05-18 14:37 --- Yes, this seems reasonably. I also thought about smth. similar to this. Only it is need to take into account using mbsrtowcs for other locale properties(if they exist in others categories). Anyway, checking of mbsrtowcs result could be usefull, at least for terminate resulting string with '\0' if mbsrtowcs cannot convert input string for some reason. E.g., there is a system where mbsrtowcs() cannot convert every non-ASCII character, but all other locale features work correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40184
[Bug fortran/40164] Fortran 2003: Arrays of procedure pointers (using PPCs)
--- Comment #3 from janus at gcc dot gnu dot org 2009-05-18 14:45 --- Subject: Bug 40164 Author: janus Date: Mon May 18 14:44:55 2009 New Revision: 147663 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147663 Log: 2009-05-18 Janus Weil ja...@gcc.gnu.org PR fortran/40164 * primary.c (gfc_match_rvalue): Handle procedure pointer components in arrays. * resolve.c (resolve_ppc_call,resolve_expr_ppc): Resolve component and array references. (resolve_fl_derived): Procedure pointer components are not required to have constant array bounds in their return value. 2009-05-18 Janus Weil ja...@gcc.gnu.org PR fortran/40164 * gfortran.dg/proc_ptr_comp_8.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40164
[Bug fortran/40164] Fortran 2003: Arrays of procedure pointers (using PPCs)
--- Comment #4 from janus at gcc dot gnu dot org 2009-05-18 14:47 --- Fixed with r147663. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40164
[Bug c++/40186] floating point comparison is wrong ( !(a b) (b a) is true )
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-05-18 14:49 --- Either use -ffloat-store or -mfpmath=sse . The issue comes from excessive precision. It is not or which is causing the problem but keeping one of a or b in the fp stack register but putting the other one on the normal memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40186
[Bug c++/40186] floating point comparison is wrong ( !(a b) (b a) is true )
--- Comment #7 from sliwa at cft dot edu dot pl 2009-05-18 14:52 --- The case (a b) (b a) shows that not discarding the extra precision before performing a comparison leads to serious problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40186
[Bug c++/40186] floating point comparison is wrong ( !(a b) (b a) is true )
--- Comment #8 from vincent at vinc17 dot org 2009-05-18 14:56 --- Are you sure that this comes from the extended precision? This would mean that GCC does implicit extended - double conversions in an asymmetric way, and IIRC, I've never seen that. I can't reproduce the problem with g++-4.4 -mfpmath=387 -Os on an x86_64 machine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40186
[Bug libstdc++/40184] locale(const char* std_name) can create invalid facets for nonuniform locale
--- Comment #3 from paolo dot carlini at oracle dot com 2009-05-18 15:03 --- Ok, thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC|paolo dot carlini at oracle | |dot com | AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40184
[Bug other/40159] [4.5 regression] make all ignores build failures
--- Comment #3 from aoliva at gcc dot gnu dot org 2009-05-18 15:34 --- Uhh... This shouldn't matter when commands are run in a shell with set -e, like make does, no? Anyhow, thanks for the analysis. I suppose replacing the final : for exit $$? should fix this, right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40159
[Bug target/39531] m68k gcc does not convert andil to bclr when compiled on a 64bit host
--- Comment #2 from schwab at gcc dot gnu dot org 2009-05-18 15:36 --- Subject: Bug 39531 Author: schwab Date: Mon May 18 15:36:18 2009 New Revision: 147664 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147664 Log: PR target/39531 * config/m68k/m68k.c (output_andsi3): Mask off sign bit copies before calling exact_log2. (output_iorsi3): Likewise. (output_xorsi3): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68k/m68k.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39531
[Bug fortran/36947] Attributes not fully checked comparing actual vs dummy procedure
--- Comment #8 from w6ws at earthlink dot net 2009-05-18 15:36 --- Subject: Re: Attributes not fully checked comparing actual vs dummy procedure Janus, janus at gcc dot gnu dot org wrote: --- Comment #7 from janus at gcc dot gnu dot org 2009-05-18 09:36 --- The commit in comment #6 implements the checking for intents. ToDo: * check for OPTIONAL * better error messages * recursive check (see comment #2) I was going to comment that OPTIONAL should be checked too, but you beat me to it. We have been having problems with both OPTIONAL and INTENT not being checked by various compilers. NAG, of course, does a better job than most in this area. It is good to see gfortran learn about this checking too. Thank you for your hard work on this! Walter -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36947
[Bug target/39531] m68k gcc does not convert andil to bclr when compiled on a 64bit host
--- Comment #3 from schwab at linux-m68k dot org 2009-05-18 15:40 --- The same problem existed in output_iorsi3 and output_xorsi3. Fixed in 4.5. -- schwab at linux-m68k dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39531
[Bug other/40159] [4.5 regression] make all ignores build failures
--- Comment #4 from schwab at linux-m68k dot org 2009-05-18 15:48 --- GNU make does not use sh -e. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40159
[Bug target/40105] SH: 4.3/4.4 compilers segfault when recompiling itself on gentoo system
--- Comment #6 from armin76 at gentoo dot org 2009-05-18 16:29 --- Sorry for taking a while, but i'm pretty sure you know sh machines are kinda of slow :) Yes! it works! Thank you for investigating it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40105
[Bug testsuite/40130] using RUNTESTFLAGS=--target_board 'foo{-mxyz,-mjkl,}' screws up ieee.exp (and possibly others?)
--- Comment #9 from ubizjak at gmail dot com 2009-05-18 16:37 --- (In reply to comment #8) No, it's just i686-pc-linux-gnu. Without --target_board etc. it works; with I got this spurious failure. But it's not a wrong code, so I think we can close as invalid. BTW: Since you are looking in this area, can you add __attribute__((noinline)) to the tests? Some of them are too easy to optimize for recent optimizing passes ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40130
[Bug testsuite/39907] Aligned access to unaligned address
--- Comment #5 from hjl dot tools at gmail dot com 2009-05-18 16:39 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01156.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||05/msg01156.html Component|tree-optimization |testsuite Keywords|wrong-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39907
[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols
--- Comment #7 from burnus at gcc dot gnu dot org 2009-05-18 16:52 --- Issue brought up by Jakub: do you require all equivalenced vars to be either threadprivate or non-threadprivate? or, does a single threadprivate var make all vars equivalenced somehow to it threadprivate? Issues brought up by those creating the patch: There is a problem for saved variables - there the equivalence does not work. One has two options: 1. Remove the equivalence statements and replace the aliases in the code. 2. Create a local common block with the saved variables. If the variables were initialized via data statements one has to take care of that at the first entry into the routine. Thus, Jakob wants to have a full specification first. I looked at other compilers and while IBM does not seem to allow it [1], Intel does not write anything about it [2] and for sun I couldn't find anything. (Still, several compilers support it: Intel's ifort, SUN's sunf95, Open64's openf95, Pathscale's pathf95 and Portland's pgf95; maybe even IBM although it is not mentioned at [1].) [1] http://publib.boulder.ibm.com/infocenter/lnxpcomp/v101v121/topic/com.ibm.xlf121.linux.doc/proguide/threadprivate.html [2] http://www.intel.com/software/products/compilers/docs/flin/main_for/lref_for/source_files/rfthred.htm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979
[Bug testsuite/39907] Aligned access to unaligned address
--- Comment #6 from hjl at gcc dot gnu dot org 2009-05-18 16:53 --- Subject: Bug 39907 Author: hjl Date: Mon May 18 16:53:25 2009 New Revision: 147667 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147667 Log: 2009-05-18 H.J. Lu hongjiu...@intel.com PR testsuite/39907 * gcc.target/x86_64/abi/asm-support.S (snapshot_ret): Preserve stack alignment. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/x86_64/abi/asm-support.S -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39907
[Bug testsuite/39907] Aligned access to unaligned address
--- Comment #7 from hjl at gcc dot gnu dot org 2009-05-18 16:54 --- Subject: Bug 39907 Author: hjl Date: Mon May 18 16:54:31 2009 New Revision: 147668 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147668 Log: 2009-05-18 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-05-18 H.J. Lu hongjiu...@intel.com PR testsuite/39907 * gcc.target/x86_64/abi/asm-support.S (snapshot_ret): Preserve stack alignment. Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gcc.target/x86_64/abi/asm-support.S -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39907
[Bug testsuite/39907] Aligned access to unaligned address
--- Comment #8 from hjl at gcc dot gnu dot org 2009-05-18 16:56 --- Subject: Bug 39907 Author: hjl Date: Mon May 18 16:56:42 2009 New Revision: 147669 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147669 Log: 2009-05-18 H.J. Lu hongjiu...@intel.com PR testsuite/39907 * gcc.target/x86_64/abi/asm-support.s (snapshot_ret): Preserve stack alignment. Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gcc.target/x86_64/abi/asm-support.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39907
[Bug testsuite/39907] Aligned access to unaligned address
--- Comment #9 from hjl dot tools at gmail dot com 2009-05-18 16:58 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39907
[Bug fortran/40176] Fortran 2003: Procedure pointers with array return value
--- Comment #3 from janus at gcc dot gnu dot org 2009-05-18 16:59 ---
Comment #0 is fixed by the following one-liner patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 147663)
+++ gcc/fortran/resolve.c (working copy)
@@ -9414,6 +9414,7 @@
|| sym-ts.interface-attr.intrinsic)
{
gfc_symbol *ifc = sym-ts.interface;
+ resolve_symbol (ifc);
if (ifc-attr.intrinsic)
resolve_intrinsic (ifc, ifc-declared_at);
However this does nothing about the gimplification failure in comment #2.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-05-18 16:59:25
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40176
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #48 from hjl at gcc dot gnu dot org 2009-05-18 17:21 --- Subject: Bug 39942 Author: hjl Date: Mon May 18 17:21:13 2009 New Revision: 147671 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147671 Log: 2009-05-18 H.J. Lu hongjiu...@intel.com PR target/39942 * config/i386/i386.c (ix86_avoid_jump_misspredicts): Replace gen_align with gen_pad. (ix86_reorg): Check ASM_OUTPUT_MAX_SKIP_PAD instead of #ifdef ASM_OUTPUT_MAX_SKIP_ALIGN. * config/i386/i386.h (ASM_OUTPUT_MAX_SKIP_PAD): New. * config/i386/x86-64.h (ASM_OUTPUT_MAX_SKIP_PAD): Likewise. * config/i386/i386.md (align): Renamed to ... (pad): This. Replace ASM_OUTPUT_MAX_SKIP_ALIGN with ASM_OUTPUT_MAX_SKIP_PAD. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/i386.md trunk/gcc/config/i386/x86-64.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug middle-end/40028] RFE - Add GPU acceleration library to gcc
--- Comment #2 from rob1weld at aol dot com 2009-05-18 17:36 --- (In reply to comment #1) Yes GPU libraries would be nice but this needs a lot of work to begin with. First you have to support the GPUs. This also amounts to doubling the support. If you really want them, since this is open source, start contributing. I'm planning a full hardware upgrade in the coming months. I plan to get an expensive Graphics Card to try this. Some of the newest cards will run at over a PetaFLOP (only for embarrassingly parallel code - http://en.wikipedia.org/wiki/Embarrassingly_parallel ). Some of the newest Motherboards will accept _FOUR_ Graphics Cards. It seems less expensive to use GPUs and recompile a few apps than trying to purchase a Motherboard with multiple CPUs or trying to find a chip faster than the 'i7'. If we could only double our Computer's speed this endeavor would be well worth doing. I suspect that Fortran's vector math could be easily converted and benefit greatly. Look for this feature in gcc in a few years (Sooner with everyone's help). Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40028
[Bug target/39079] MIPS: __builtin___clear_cache() broken on SMP ISA_HAS_SYNCI systems.
--- Comment #1 from daney at gcc dot gnu dot org 2009-05-18 17:39 --- I am working on a patch. -- daney at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |daney at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-18 17:39:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39079
[Bug libfortran/40187] New: c_f_pointer with stride in SHAPE
Using a SHAPE with stride doesn't work with c_f_pointer doesn't work (modified test case from the testsuite): $ diff -u c_f_pointer_shape_tests_4.f03 ~/gcc/trunk/gcc/testsuite/gfortran.dg/c_f_pointer_shape_tests_2.f03 --- c_f_pointer_shape_tests_4.f03 2009-05-18 19:55:36.0 +0200 +++ /home/ig25/gcc/trunk/gcc/testsuite/gfortran.dg/c_f_pointer_shape_tests_2.f03 2007-11-17 17:27:32.0 +0100 @@ -29,13 +29,12 @@ integer(c_int), value :: num_rows integer(c_int), value :: num_cols integer, dimension(:,:), pointer :: myArrayPtr -integer(c_long_long), dimension(3) :: shape +integer(c_long_long), dimension(2) :: shape integer :: i,j shape(1) = num_rows -shape(2) = -3; -shape(3) = num_cols -call c_f_pointer(cPtr, myArrayPtr, shape(1:3:2)) +shape(2) = num_cols +call c_f_pointer(cPtr, myArrayPtr, shape) do j = 1, num_cols do i = 1, num_rows if(myArrayPtr(i,j) /= ((j-1)*num_rows)+(i-1)) call abort () $ gfortran ~/gcc/trunk/gcc/testsuite/gfortran.dg/c_f_pointer_shape_tests_2_driver.c c_f_pointer_shape_tests_4.f03 $ ./a.out Aborted -- Summary: c_f_pointer with stride in SHAPE Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40187
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
-- pthaugen at gcc dot gnu dot org changed: What|Removed |Added CC||pthaugen at gcc dot gnu dot ||org Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug target/40129] M16C invalid shift count used by pack_d - ashldi3
--- Comment #4 from dj at redhat dot com 2009-05-18 19:16 --- Yes, those two changes are the fix you need. However, those fixes were over three years ago, so I consider this bug already fixed. If you agree, please close this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40129
[Bug debug/40109] Incorrect debug info nesting for typedef statements within namespaces
--- Comment #3 from dodji at gcc dot gnu dot org 2009-05-18 19:20 --- Subject: Bug 40109 Author: dodji Date: Mon May 18 19:19:52 2009 New Revision: 147674 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147674 Log: Fix for PR debug/40109 gcc/ChangeLog: PR debug/40109 * dwarf2out.c (gen_type_die_with_usage): Generate the DIE as a child of the containing namespace's DIE. gcc/testsuite/ChangeLog: PR debug/40109 * g++.dg/debug/dwarf2/nested-1.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/nested-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40109
[Bug debug/40109] Incorrect debug info nesting for typedef statements within namespaces
--- Comment #4 from dodji at gcc dot gnu dot org 2009-05-18 19:24 --- Subject: Bug 40109 Author: dodji Date: Mon May 18 19:24:17 2009 New Revision: 147675 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147675 Log: Candidate Fix for PR debug/40109 gcc/ChangeLog: PR debug/40109 * dwarf2out.c (gen_type_die_with_usage): Generate the DIE as a child of the containing namespace's DIE. gcc/testsuite/ChangeLog: PR debug/40109 * g++.dg/debug/dwarf2/nested-1.C: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/debug/dwarf2/nested-1.C Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/dwarf2out.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40109
[Bug debug/40109] Incorrect debug info nesting for typedef statements within namespaces
--- Comment #5 from dodji at gcc dot gnu dot org 2009-05-18 19:26 --- Subject: Bug 40109 Author: dodji Date: Mon May 18 19:26:41 2009 New Revision: 147676 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147676 Log: Fix for PR debug/40109 gcc/ChangeLog: PR debug/40109 * dwarf2out.c (gen_type_die_with_usage): Generate the DIE as a child of the containing namespace's DIE. gcc/testsuite/ChangeLog: PR debug/40109 * g++.dg/debug/dwarf2/nested-1.C: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/debug/dwarf2/nested-1.C Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/dwarf2out.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40109
[Bug debug/40109] Incorrect debug info nesting for typedef statements within namespaces
--- Comment #6 from dodji at gcc dot gnu dot org 2009-05-18 19:29 --- Fixed in 4.5, 4.4 and 4.3. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40109
[Bug c/40189] New: gcc 4.4.0 incorrectly folds add-as-comparison
This code:
int
foo(int arg0)
{
if ((-2147483647 - 1) + arg0)
return 20;
else
return 11;
}
when compiled with gcc-4.4.0 at -O2 or higher, simply returns 20
unconditionally:
$ ~/x86-gcc4/bin/gcc -m32 -O2 -S ~/baz.c -o /dev/tty
.file baz.c
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
pushl %ebp
movl$20, %eax
movl%esp, %ebp
popl%ebp
ret
.size foo, .-foo
.ident GCC: (GNU) 4.4.0
.section.note.GNU-stack,,@progbits
This bug appears to be architecture-independent (I've seen it on x86,
x86_64, and another chip).
The bug did not happen in gcc-4.0.2.
Here is some information about my system:
$ ~/x86-gcc4/bin/gcc --version
gcc (GCC) 4.4.0
Copyright (C) 2009 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.
$ uname -a
Linux ld-1 2.6.9-42.0.8.ELsmp #1 SMP Tue Jan 30 12:18:01 EST 2007 x86_64 x86_64
x86_64 GNU/Linux
$ file bin/gcc
bin/gcc: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux
2.4.0, dynamically linked (uses shared libs), not stripped
--
Summary: gcc 4.4.0 incorrectly folds add-as-comparison
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mat at lcs dot mit dot edu
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40189
[Bug c/40189] gcc 4.4.0 incorrectly folds add-as-comparison
--- Comment #1 from schwab at linux-m68k dot org 2009-05-18 19:47 --- Not a bug. If arg0 is negative you get undefined behavior due to overflow. Use -fwrapv to get wrapping semantics. -- schwab at linux-m68k dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40189
[Bug c/40189] gcc 4.4.0 incorrectly folds add-as-comparison
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-18 19:48 --- INT_MIN + any number is never going to be zero because INT_MIN = - INT_MAX -1. Also signed integer overflow is undefined which gives that the above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40189
[Bug fortran/40190] New: DATE_AND_TIME returns GMT hour sometimes with OpenMP
Test case: program testhour use omp_lib integer :: h(1000), h1(1000), bins(0:23), v(8) call omp_set_num_threads(4) print *, Running on,omp_get_max_threads(),threads and,omp_get_num_procs(),procs. !$omp parallel do schedule(STATIC,250) do i=1,1000 call date_and_time(values=v) h(i) = v(5) end do !$omp end parallel do print *, date_and_time hour: bins = 0 do i=1,1000 bins(h(i)) = bins(h(i)) + 1 end do do i=0,23 if (bins(i) 0) print *, For,bins(i),calls, hour =,i end do end program testhour Compile with -fopenmp, and run on 4 threads: aprun -n1 -d4 ./dattest Running on 4 threads and 1 procs. date_and_time hour: For 707 calls, hour = 13 For 293 calls, hour = 18 Application 2721423 resources: utime 0, stime 0 This was run in US Central Daylight time zone. Most of the time, the correct hour (13) was returned, but a sizable number of times, the hour correct for GMT was returned instead. It looks like the conversion from GMT to the local time zone sometimes fails when the routine is concurrently called from more that one thread. I wrote a similar program that called the system localtime() routine instead, as well as localtime_r(), and both consistently returned the correct hour. The same code compiled with either the Cray or PGI compiler consistently returns the same hour for every iteration. -- Summary: DATE_AND_TIME returns GMT hour sometimes with OpenMP Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: longb at cray dot com GCC host triplet: Linux, x86-64 GCC target triplet: Linux, x86-64 (quad-core Opteron) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40190
[Bug c/40191] New: fails to build a cross-compiler in-tree
I found this when building a i586-mingw32 cross-compiler directly in srcdir.
Build fails with:
make[2]: Entering directory `/tmp/trunk/i586-mingw32msvc/libgcc'
Makefile:143: ../.././gcc/libgcc.mvars: No such file or directory
make[2]: *** No rule to make target `../.././gcc/libgcc.mvars'. Stop.
This happens because ${host_subdir} gets the wrong path (fallbacks to .).
The check in acx.m4 doesn't take into account that ${host_noncanonical} changes
its meaning when we switched from gcc/ to libgcc/.
Patch attached.
--
Summary: fails to build a cross-compiler in-tree
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: build, patch
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmh at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40191
[Bug target/40191] fails to build a cross-compiler in-tree
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-18 20:43 --- I don't know that many folks who build in the source directory :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40191
[Bug target/40191] fails to build a cross-compiler in-tree
--- Comment #2 from rmh at gcc dot gnu dot org 2009-05-18 20:45 ---
Created an attachment (id=17889)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17889action=view)
patch
2009-05-18 Robert Millan rmh@aybabtu.com
* acx.m4: Fix ${host_subdir} initialization for libgcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40191
[Bug c/40189] gcc 4.4.0 incorrectly folds add-as-comparison
--- Comment #3 from mat at lcs dot mit dot edu 2009-05-18 20:53 --- Fair enough, thanks (this came up running a compiler test suite that checks even undefined edge cases). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40189
[Bug c++/40192] New: Unable to use std::vector with typedef'd array types
The following code will not compile in gcc 4.3.2 on Ubuntu 8.10
#include vector
typedef float float4[4];
int main()
{
std::vectorfloat4 vals;
}
I get the following compilation error:
/usr/include/c++/4.3/bits/stl_construct.h: In function void
std::_Destroy(_Tp*) [with _Tp = float [4]]:
/usr/include/c++/4.3/bits/stl_construct.h:103: instantiated from void
std::_Destroy(_ForwardIterator, _ForwardIterator) [with _ForwardIterator =
float (*)[4]]
/usr/include/c++/4.3/bits/stl_construct.h:128: instantiated from void
std::_Destroy(_ForwardIterator, _ForwardIterator, std::allocator_T2) [with
_ForwardIterator = float (*)[4], _Tp = float [4]]
/usr/include/c++/4.3/bits/stl_vector.h:300: instantiated from
std::vector_Tp, _Alloc::~vector() [with _Tp = float [4], _Alloc =
std::allocatorfloat [4]]
test_float4.cpp:7: instantiated from here
/usr/include/c++/4.3/bits/stl_construct.h:88: error: request for member ~float
[4] in * __pointer, which is of non-class type float [4]
The code does compile in gcc 3.4 and gcc 4.1.
--
Summary: Unable to use std::vector with typedef'd array types
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: coleb at eyesopen dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40192
[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap
--- Comment #14 from daney at gcc dot gnu dot org 2009-05-18 21:10 --- For the record: This affects mips64-linux as well. -- daney at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-05-17 17:11:44 |2009-05-18 21:10:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40172
[Bug fortran/40190] DATE_AND_TIME returns GMT hour sometimes with OpenMP
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-18 21:12 --- Confirm. I looked at the source code, but I don't see why it can happen, but it does. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2009-05-18 21:12:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40190
[Bug libfortran/40187] c_f_pointer with stride in SHAPE
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-18 21:20 --- Can you attach a working example? I failed to apply your patch and figure out which diffed file is what. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40187
[Bug c++/40193] New: No built-in comparison operators for scoped enums (C++0x)
On trunk (also seen in gcc-4.4.0), gcc doesn't compile this snippet:
enum class E { A };
bool foo() { return E::A == E::A; }
in C++0x mode (cc1plus -quiet -std=c++0x enumtest.cpp -o /tmp/enumtest.s),
giving this error:
enumtest.cpp: In function 'bool foo()':
enumtest.cpp:2: error: invalid operands of types 'E' and 'E' to binary
'operator=='
I think this snippet is valid, since my interpretation of N2857's
[over.built]/15:
For every T, where T is an enumeration type or pointer to effective
object type, there exist candidate operator functions of the form
bool operator(T , T );
bool operator(T , T );
bool operator=(T , T );
bool operator=(T , T );
bool operator==(T , T );
bool operator!=(T , T );
is that type E should have a built-in operator==.
This is confirmed by the expected error message when compiling this snippet:
enum class E { A };
enum class F { B };
bool foo() { return E::A == F::B; }
which is:
enumtest2.cpp: In function 'bool foo()':
enumtest2.cpp:3: error: no match for 'operator==' in '(E)0 == (F)0'
enumtest2.cpp:3: note: candidates are: operator==(F, F) built-in
enumtest2.cpp:3: note: operator==(E, E) built-in
enumtest2.cpp:3: note: operator==(int, int) built-in
This message says there is indeed a built-in 'operator==(E, E)'. Shouldn't it
be found when compiling the first snippet?
This creates failures in Boost regression tests for runners using gcc-4.4.0 in
C++0x mode (as scoped enums have been enabled on that configuration recently).
--
Summary: No built-in comparison operators for scoped enums
(C++0x)
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: frabar666 at gmail 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=40193
[Bug libfortran/40190] DATE_AND_TIME returns GMT hour sometimes with OpenMP
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-18 22:11 --- date_and_time isn't thread-safe. It should use gmtime_r and localtime_r if they are available. -- hjl dot tools at gmail dot com changed: What|Removed |Added Component|fortran |libfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40190
[Bug c++/40193] No built-in comparison operators for scoped enums (C++0x)
--- Comment #1 from paolo dot carlini at oracle dot com 2009-05-18 22:12 --- *** This bug has been marked as a duplicate of 38064 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40193
[Bug c++/38064] [c++0x] operator== doesn't work for enum classes
--- Comment #4 from paolo dot carlini at oracle dot com 2009-05-18 22:12 --- *** Bug 40193 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||frabar666 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38064
[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types
--- Comment #1 from paolo dot carlini at oracle dot com 2009-05-18 22:34 --- I'll fix it momentarily. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-18 22:34:29 date|| Summary|Unable to use std::vector |[4.4/4.5 Regression] Unable |with typedef'd array types |to use std::vector with ||typedef'd array types Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40192
[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap
--- Comment #15 from daney at gcc dot gnu dot org 2009-05-18 22:35 --- And yet another place: ../../trunk/gcc/config/mips/sb1.md:159: error: logical or of collectively exhaustive tests is always true ../../trunk/gcc/config/mips/sb1.md:159: error: logical or of collectively exhaustive tests is always true ../../trunk/gcc/config/mips/sb1.md:159: error: logical or of collectively exhaustive tests is always true ../../trunk/gcc/config/mips/sb1.md:159: error: logical or of collectively exhaustive tests is always true Can we either get the patch reverted, or move it out of -Wextra? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40172
[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap
--- Comment #16 from meissner at linux dot vnet dot ibm dot com 2009-05-18 22:56 --- Just to chime in, the warning is a useful warning, but the way rs6000 and mips define FRAME_GROWS_DOWNWARD, the test in toplev.c will never succeed. I can see a couple of ways to fix this: 1) Revert the patch that moves this warning to -Wextra. I think this is a bad idea, since the warning does seem to be useful. 2) Disable the check in toplev.c. Again, I think this is useful in general, but as an immediate palative, it can be useful. 3) Add a new macro to say not to do the test in #2, and define it in mips and rs6000. This is doable, but in general it is not a good idea to add new global macros like this. 4) Change mips and rs6000 to have a global variable that is what FRAME_GROWS_DOWNWARD should be. This is certainly doable. The test will be tested at runtime, but never invoke the error message. 5) Move FRAME_GROWS_DOWNWARD (and STACK_GROWS_DOWNWARD, etc.) into the target structure, and set the field in the target structure from the macro. I tend to like this (and eventually move backends to set the field directly and get rid of the macros). I tend to like this idea best. -- meissner at linux dot vnet dot ibm dot com changed: What|Removed |Added CC||meissner at linux dot vnet ||dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40172
[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap
--- Comment #17 from hjl dot tools at gmail dot com 2009-05-18 23:03
---
(In reply to comment #16)
Just to chime in, the warning is a useful warning, but the way rs6000 and mips
define FRAME_GROWS_DOWNWARD, the test in toplev.c will never succeed.
5) Move FRAME_GROWS_DOWNWARD (and STACK_GROWS_DOWNWARD, etc.) into the target
structure, and set the field in the target structure from the macro. I tend
to
Can't we change it to
if (!FRAME_GROWS_DOWNWARD)
{
if (flag_stack_protect)
{
warning (0, -fstack-protector not supported for this target);
flag_stack_protect = 0;
}
}
with a comment?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40172
[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap
--- Comment #18 from manu at gcc dot gnu dot org 2009-05-18 23:13 ---
The following patch moves the warning out of Wextra. I haven't tested it,
though.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 147679)
+++ gcc/doc/invoke.texi (working copy)
@@ -2806,7 +2806,6 @@
@gccoptlist{-Wclobbered @gol
-Wempty-body @gol
-Wignored-qualifiers @gol
--Wlogical-op @gol
-Wmissing-field-initializers @gol
-Wmissing-parameter-type @r{(C only)} @gol
-Wold-style-declaration @r{(C only)} @gol
@@ -3793,8 +3792,7 @@
@opindex Wno-logical-op
Warn about suspicious uses of logical operators in expressions.
This includes using logical operators in contexts where a
-bit-wise operator is likely to be expected. This warning is enabled by
-...@option{-wextra}.
+bit-wise operator is likely to be expected.
@item -Waggregate-return
@opindex Waggregate-return
Index: gcc/c-opts.c
===
--- gcc/c-opts.c(revision 147679)
+++ gcc/c-opts.c(working copy)
@@ -1073,8 +1073,6 @@
warn_override_init = extra_warnings;
if (warn_ignored_qualifiers == -1)
warn_ignored_qualifiers = extra_warnings;
- if (warn_logical_op == -1)
-warn_logical_op = extra_warnings;
/* -Wpointer-sign is disabled by default, but it is enabled if any
of -Wall or -pedantic are given. */
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2009-05-18 21:10:16 |2009-05-18 23:13:34
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40172
[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types
--- Comment #2 from paolo at gcc dot gnu dot org 2009-05-18 23:16 --- Subject: Bug 40192 Author: paolo Date: Mon May 18 23:16:20 2009 New Revision: 147680 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147680 Log: 2009-05-18 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/40192 * include/bits/stl_construct.h (struct _Destroy_aux): Add. (_Destroy(_ForwardIterator, _ForwardIterator)): Use the latter. * testsuite/23_containers/vector/40192.cc: New. Added: trunk/libstdc++-v3/testsuite/23_containers/vector/40192.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_construct.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40192
[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types
--- Comment #3 from paolo at gcc dot gnu dot org 2009-05-18 23:17 --- Subject: Bug 40192 Author: paolo Date: Mon May 18 23:16:48 2009 New Revision: 147681 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147681 Log: 2009-05-18 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/40192 * include/bits/stl_construct.h (struct _Destroy_aux): Add. (_Destroy(_ForwardIterator, _ForwardIterator)): Use the latter. * testsuite/23_containers/vector/40192.cc: New. Added: branches/gcc-4_4-branch/libstdc++-v3/testsuite/23_containers/vector/40192.cc Modified: branches/gcc-4_4-branch/libstdc++-v3/ChangeLog branches/gcc-4_4-branch/libstdc++-v3/include/bits/stl_construct.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40192
[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types
--- Comment #4 from paolo dot carlini at oracle dot com 2009-05-18 23:18 --- Fixed for 4.4.1. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40192
[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap
--- Comment #19 from daney at gcc dot gnu dot org 2009-05-18 23:32 --- Created an attachment (id=17890) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17890action=view) Proposed fix. I am testing this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40172
[Bug rtl-optimization/40105] [4.3/4.4 Regression] SH: 4.3/4.4 compilers segfault when recompiling itself on gentoo system
--- Comment #7 from kkojima at gcc dot gnu dot org 2009-05-18 23:41 --- Thanks for confirmation! I'll ask if the r146829 patch is safe to backport for 4.[34] branches in the gcc list, after the tests on x86 and powerpc. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Component|target |rtl-optimization Keywords||wrong-code Known to work|4.1.2 |4.1.2 4.5.0 Summary|SH: 4.3/4.4 compilers |[4.3/4.4 Regression] SH: |segfault when recompiling |4.3/4.4 compilers segfault |itself on gentoo system |when recompiling itself on ||gentoo system http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40105
[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap
--- Comment #20 from meissner at linux dot vnet dot ibm dot com 2009-05-18 23:48 --- David, as I said in my message, this patch is just papering over the problem. While we might want to install this patch temporarily, to get the mips and rs6000 building again, I think a better solution is to change the circular dependency between FRAME_GROWS_DOWNWARD and flag_stack_protect, so at the point of the test in toplev.c the compiler won't give this warning. H. J. the problem with your patch is it that the compiler is likely to still issue the warning, since it will be discovered by the dataflow or SSA parts of the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40172
[Bug other/40159] [4.5 regression] make all ignores build failures
--- Comment #5 from aoliva at gcc dot gnu dot org 2009-05-19 00:01 --- Subject: Bug 40159 Author: aoliva Date: Tue May 19 00:01:17 2009 New Revision: 147683 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147683 Log: PR other/40159 * Makefile.tpl (all): Don't end with unconditional success. * Makefile.in: Rebuilt. Modified: trunk/ChangeLog trunk/Makefile.in trunk/Makefile.tpl -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40159
[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap
--- Comment #21 from pinskia at gcc dot gnu dot org 2009-05-19 00:02 --- (In reply to comment #16) Just to chime in, the warning is a useful warning, but the way rs6000 and mips define FRAME_GROWS_DOWNWARD, the test in toplev.c will never succeed. Yes and that is correct because we don't want that code to be involved at all. The whole if statement becomes false (which is a good thing we can detect it as being always false). I can see a couple of ways to fix this: 1) Revert the patch that moves this warning to -Wextra. I think this is a bad idea, since the warning does seem to be useful. 2) Disable the check in toplev.c. Again, I think this is useful in general, but as an immediate palative, it can be useful. 3) Add a new macro to say not to do the test in #2, and define it in mips and rs6000. This is doable, but in general it is not a good idea to add new global macros like this. This is not a good option at all. a seperate option which I mentioned in an email rather than this bug report. So the current issue here is that we have: if (!DEFINED x != 0) Where DEFINED is a macro which says (x != 0). This gets expanded as: if (!(x!=0) x!=0) Obviously to the trained eye this would be a good warning but guess what DEFINED just happens to be based on x, it does not have to be. It would be nice to say only warn for x1 !x2 if (obviously x1 == x2) : if either x1 or !x2 is from a macro but not both Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40172
[Bug other/40159] [4.5 regression] make all ignores build failures
--- Comment #6 from aoliva at gcc dot gnu dot org 2009-05-19 00:04 --- Subject: Bug 40159 Author: aoliva Date: Tue May 19 00:04:17 2009 New Revision: 147684 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147684 Log: PR other/40159 * Makefile.tpl (all): Don't end with unconditional success. * Makefile.in: Rebuilt. Modified: branches/var-tracking-assignments-branch/ChangeLog branches/var-tracking-assignments-branch/Makefile.in branches/var-tracking-assignments-branch/Makefile.tpl -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40159
[Bug other/40159] [4.5 regression] make all ignores build failures
--- Comment #7 from aoliva at gcc dot gnu dot org 2009-05-19 00:05 --- Subject: Bug 40159 Author: aoliva Date: Tue May 19 00:04:57 2009 New Revision: 147685 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147685 Log: PR other/40159 * Makefile.tpl (all): Don't end with unconditional success. * Makefile.in: Rebuilt. Modified: branches/var-tracking-assignments-4_4-branch/ChangeLog branches/var-tracking-assignments-4_4-branch/Makefile.in branches/var-tracking-assignments-4_4-branch/Makefile.tpl -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40159
[Bug other/40159] [4.5 regression] make all ignores build failures
--- Comment #8 from aoliva at gcc dot gnu dot org 2009-05-19 00:07 --- Fixed. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40159
