[Bug tree-optimization/51246] [4.7 Regression] ICE in replace_ref_with, at tree-predcom.c:1309
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51246
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-24
08:25:40 UTC ---
Created attachment 25907
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25907
gcc47-pr51246.patch
I wonder whether we can't just adjust the assert here to also allow clobber on
the rhs.
Then
bb 2:
bb 3:
c.0_1 = c;
a = c.0_1;
b = c;
c ={v} {CLOBBER};
bb 4:
goto bb 3;
is transformed into:
bb 2:
c.5_10 = c;
bb 3:
# c_lsm0.4_8 = PHI c.5_10(2), c_lsm0.4_9(4)
c.0_1 = c_lsm0.4_8;
a = c.0_1;
b = c;
c ={v} {CLOBBER};
c_lsm0.4_9 ={v} {CLOBBER};
bb 4:
goto bb 3;
That makes it clear that we use uninitialized variable in the next iteration
too.
[Bug bootstrap/50888] Bootstrap failure in libjava against latest git glibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50888 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-24 08:41:17 UTC --- Fixed for 4.4+.
[Bug tree-optimization/51247] [4.7 Regression] ICE in set_value_range, at tree-vrp.c:417
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51247
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milestone|--- |4.7.0
Summary|ICE in set_value_range, at |[4.7 Regression] ICE in
|tree-vrp.c:417 |set_value_range, at
||tree-vrp.c:417
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-24
09:22:23 UTC ---
Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=172871
Shorter testcase at -O2:
struct S { int s : 1; };
int a;
void
foo (int x, int y)
{
struct S s;
s.s = !!y;
while (1)
{
unsigned l = 94967295;
a = x || (s.s = l);
}
}
[Bug tree-optimization/51247] [4.7 Regression] ICE in set_value_range, at tree-vrp.c:417
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51247 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-24 Ever Confirmed|0 |1
[Bug rtl-optimization/43491] Unnecessary temporary for global register variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43491
--- Comment #3 from amker.cheng amker.cheng at gmail dot com 2011-11-24
09:24:37 UTC ---
(In reply to comment #1)
I'm thinking that this is perfectly normal thing to do, and that the redundant
move is meant to disappear in a later pass. My guess is that IRA is choosing
not to assign the pseudo to r4, but I do not know why at the moment.
As dump in 191r.shed1:
--
(insn 5 7 6 2 (set (reg/f:SI 135 [ reg.0 ])
(reg/v:SI 4 r4 [ reg ])) pr43491.c:16 709 {*thumb2_movsi_insn}
(expr_list:REG_DEAD (reg/v:SI 4 r4 [ reg ])
(nil)))
(insn 6 5 8 2 (set (reg:SI 137 [ MEM[(unsigned int *)reg.0_12 + 8B] ])
(mem:SI (plus:SI (reg/f:SI 135 [ reg.0 ])
(const_int 8 [0x8])) [2 MEM[(unsigned int *)reg.0_12 + 8B]+0 S4
A32])) pr43491.c:16 709 {*thumb2_movsi_insn}
(nil))
(jump_insn 8 6 49 2 (parallel [
(set (pc)
(if_then_else (eq (reg:SI 137 [ MEM[(unsigned int *)reg.0_12 +
8B] ])
(const_int 0 [0]))
(label_ref:SI 22)
(pc)))
(clobber (reg:CC 24 cc))
]) pr43491.c:16 747 {*thumb2_cbz}
(expr_list:REG_DEAD (reg:SI 137 [ MEM[(unsigned int *)reg.0_12 + 8B] ])
(expr_list:REG_UNUSED (reg:CC 24 cc)
(expr_list:REG_BR_PROB (const_int 900 [0x384])
(nil
- 22)
(code_label 49 8 48 3 4 [1 uses])
(note 48 49 16 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(note 16 48 14 3 NOTE_INSN_DELETED)
(call_insn 14 16 15 3 (parallel [
(call (mem:SI (symbol_ref:SI (c) [flags 0x41] function_decl
0xb76c3b80 c) [0 c S4 A32])
(const_int 0 [0]))
(use (const_int 0 [0]))
(clobber (reg:SI 14 lr))
]) pr43491.c:17 247 {*call_symbol}
(nil)
(nil))
(insn 15 14 17 3 (set (reg:SI 138 [ MEM[(unsigned int *)reg.0_12 + 8B] ])
(mem:SI (plus:SI (reg/f:SI 135 [ reg.0 ])
(const_int 8 [0x8])) [2 MEM[(unsigned int *)reg.0_12 + 8B]+0 S4
A32])) pr43491.c:16 709 {*thumb2_movsi_insn}
(nil))
--
Since reg is manually declared in r4, function globalize_reg sets r4 in
fixed_reg_set/call_used_reg_set/call_fixed_reg_set. IRA then add r4 into
allocno(r135)'s conflict_hard_regs. That's why IRA not assigns the pseudo(r135)
to r4. I guess it's natural unless we can make IRA aware of constant register.
[Bug middle-end/51291] ICE: SIGSEGV in ix86_init_builtins (i386.c:27691) with -fgnu-tm and any fortran code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51291 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||burnus at gcc dot gnu.org Component|fortran |middle-end Target Milestone|--- |4.7.0 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-24 09:52:37 UTC --- The crash happens at config/i386/i386.c's ix86_init_tm_builtins: decl = builtin_decl_explicit (BUILT_IN_TM_LOAD_1); attrs_load = DECL_ATTRIBUTES (decl); The problem is that builtin_decl_explicit returns NULL - or in other words: builtin_info.decl[(size_t) BUILT_IN_TM_LOAD_1] is NULL. The problem is that gtm-builtins.def is included in builtins.def which is included in c-common.c. However, builtins.def is not included in fortran/*. Ideas?
[Bug c++/51290] Bogus warning: zero as null pointer constant with static_cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51290 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-11-24 10:20:49 UTC --- Author: paolo Date: Thu Nov 24 10:20:43 2011 New Revision: 181690 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181690 Log: /cp 2011-11-24 Paolo Carlini paolo.carl...@oracle.com PR c++/51290 * class.c (build_base_path): For the null pointer check use nullptr_node instead of integer_zero_node. /testsuite 2011-11-24 Paolo Carlini paolo.carl...@oracle.com PR c++/51290 * g++.dg/warn/Wzero-as-null-pointer-constant-3.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51290] Bogus warning: zero as null pointer constant with static_cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51290 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-24 10:21:46 UTC --- Fixed.
[Bug tree-optimization/51247] [4.7 Regression] ICE in set_value_range, at tree-vrp.c:417
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51247 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-24 10:32:02 UTC --- Created attachment 25908 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25908 gcc47-pr51247.patch Untested fix.
[Bug fortran/51292] New: RESULT var with -finit-local-zero -fno-automatic results in error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51292 Bug #: 51292 Summary: RESULT var with -finit-local-zero -fno-automatic results in error Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: bur...@gcc.gnu.org function foo (a) integer :: foo foo = 1 end function foo function bar (a) result (h) integer :: h h = 1 end function bar fails to compile with -finit-local-zero -fno-automatic. H variable is in that case TREE_STATIC (should it really be?) and -finit-local-zero adds initializer for it, on which then the FE errors out.
[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941 --- Comment #6 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-11-24 11:00:46 UTC --- (In reply to comment #5) How strongly do you object? I think the benefits are worth any compatibility drawbacks in this case. It would be a nice to have, but I'm not going to lose any sleep over it.
[Bug fortran/51293] New: [OOP] ICE on ANY with overloaded == operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51293 Bug #: 51293 Summary: [OOP] ICE on ANY with overloaded == operator Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: bur...@gcc.gnu.org module stuff implicit none type a integer :: i, j end type a interface operator (==) module procedure equal_a end interface operator (==) contains elemental function equal_a (x,y) result (same) class (a), intent(in) :: x, y logical :: same if ( x%i == y%i .and. x%j == y%j ) then same = .TRUE. else same = .FALSE. end if end function equal_a end module stuff program bugtest use stuff type (a), dimension(10) :: h type (a) :: g integer :: i if ( any(h == g) ) then write (*,*) end if end program bugtest ICEs on the trunk as well as 4.6 branch.
[Bug c/51294] New: spurious warning from -Wconversion in C and C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294
Bug #: 51294
Summary: spurious warning from -Wconversion in C and C++
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tortoise...@yahoo.co.uk
The code below produces a spurious warning when compiled with -Wconversion.
0 is a const so the compiler should be able to choose the correct type. This
works with gcc 4.1 on redhat 5 but not the latest snapshot of gcc 4.7 (which I
am trialing for its c++11 support).
I do not have any intermediate compiler versions to test with.
spurious.cpp:
class foo
{
char bar;
foo(bool haveBar, char bar_):
bar(haveBar?bar_:0)
{
}
};
##
test.sh
#!/bin/sh
gcc --version
gcc -Wconversion -c spurious.cpp
export LD_LIBRARY_PATH=/opt/gcc4.7/lib:$LD_LIBRARY_PATH
export PATH=/opt/gcc4.7/bin:$PATH
/opt/gcc4.7/bin/gcc --version
/opt/gcc4.7/bin/gcc -Werror -Wconversion -c spurious.cpp
##
brucea@:home/brucea/spurious./test.sh
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51)
Copyright (C) 2006 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.
gcc (GCC) 4.7.0 2019 (experimental)
Copyright (C) 2011 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.
spurious.cpp: In constructor ‘foo::foo(bool, char)’:
spurious.cpp:8:25: error: conversion to ‘char’ from ‘int’ may alter its value
[-Werror=conversion]
cc1plus: all warnings being treated as errors
##
The workaround is either to disable the warning with -Wno-conversion or add
unecessary constants as below. I don't think this is acceptable.
class foo2
{
static const char zero = 0;
char bar;
foo2(bool haveBar, char bar_):
bar(haveBar?bar_:zero)
{
}
};
This is also a bug in the C front-end:
void foo(int haveBar, char bar_)
{
char zuul = haveBar?bar_:0;
}
[Bug c/51294] spurious warning from -Wconversion in C and C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294 --- Comment #1 from Bruce Adams tortoise_74 at yahoo dot co.uk 2011-11-24 11:35:24 UTC --- Probably unncessary but the OS is RHEL5 on a 32bit machine. brucea@:home/brucea/spuriouslsb_release -a LSB Version: :core-4.0-ia32:core-4.0-noarch:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-ia32:printing-4.0-noarch Distributor ID: RedHatEnterpriseClient Description:Red Hat Enterprise Linux Client release 5.7 (Tikanga) Release:5.7 Codename: Tikanga
[Bug c++/51210] [C++11][DR 295] std::type_info works incorrectly with function types with cv-qualifier-seq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51210 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-24 11:41:19 UTC --- Let's resolve as dup, then. *** This bug has been marked as a duplicate of bug 48665 ***
[Bug c++/48665] type of const member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48665 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-24 11:41:19 UTC --- *** Bug 51210 has been marked as a duplicate of this bug. ***
[Bug c++/51227] [c++0x] ICE with invalid parameter in lambda expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51227 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-24 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-24 11:50:46 UTC --- In instantiate_class_template_1 we do: instantiate_decl (lambda_function (type), false, false); but lambda_function can definitely return NULL_TREE and instantiate_decl cannot cope with it.
[Bug c/51294] spurious warning from -Wconversion in C and C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-24 12:01:49 UTC --- (In reply to comment #0) 0 is a const so the compiler should be able to choose the correct type. 0 is an int, so the compiler is required by the standard to make the conditional expression (haveBar?bar_:0) have type int. It shouldn't warn though, as the conversion from int to char won't alter the value. The workaround is either to disable the warning with -Wno-conversion or add unecessary constants as below. I don't think this is acceptable. Or (haveBar?bar_:(char)0)
[Bug c++/51290] Bogus warning: zero as null pointer constant with static_cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51290 --- Comment #4 from Udo Steinberg us15 at os dot inf.tu-dresden.de 2011-11-24 12:04:58 UTC --- Confirmed to be fixed.
[Bug middle-end/50628] [4.7 Regression] gfortran.fortran-torture/execute/entry_4.f90 fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50628 --- Comment #12 from Martin Jambor jamborm at gcc dot gnu.org 2011-11-24 12:18:46 UTC --- Created attachment 25909 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25909 Fix This is the fix I wrote about yesterday. It bootstraps and tests fine on x86_64 and we should want to have it because it always avoids unnecessary work, even though I find it difficult to see it as a correctness check. Well...
[Bug rtl-optimization/50290] [4.7 Regression] ICE: in distribute_notes, at combine.c:13282 with -O2 -fwhole-program -fno-tree-loop-optimize -fno-tree-vrp -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50290 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-24 12:44:40 UTC --- Fixed by http://gcc.gnu.org/viewcvs?root=gccview=revrev=180058 Testing the testcase for the testsuite now, will commit if it succeeds and close this.
[Bug fortran/51268] [Regression] A subroutine can not know anymore its own interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51268 --- Comment #6 from Sebastien Bardeau bardeau at iram dot fr 2011-11-24 13:23:18 UTC --- (In reply to comment #5) It should be buried in 16 Scope, association, and definition, but I need some time to extract it. Ok, so did I. Here is what I can read section 16.2, p.406 (shortened): Within a scoping unit, identifiers of entities in the following classes: (1) ..., abstract interfaces, generic interfaces, ... are local identifiers in that scoping unit. Within a scoping unit, a local identifier of an entity of class (1) shall not be the same as a global identifier used in that scoping unit. There is no explicit rule regarding the specific interfaces which we are interested in since the beginning. Furthermore, section 12.3.2.1, p.260 + corrigendum 5: A procedure shall not have more than one explicit specific interface in a given scoping unit, except that if the interface is accessed by use association, there may be more than one local name for the procedure. As far as I understand, specific interface names accessed by use-association do not conflict with the procedure name itself. Isn't it a key point in our discussion? You could also ask at the comp.lang.fortran newsgroup where (among others) the editor of the Fortran 2003 standard answers such questions. Yes it will be interesting to have their point of view depending on how we finally agree on the standard interpretation. Thanks for your other explanations and examples, I keep them in mind for further discussions, here or on the comp.lang.fortran newsgroup .
[Bug fortran/51292] RESULT var with -finit-local-zero -fno-automatic results in error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51292 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-24 13:46:37 UTC --- (In reply to comment #0) fails to compile with -finit-local-zero -fno-automatic. H variable is in that case TREE_STATIC (should it really be?) Difficult question: -fno-automatic overrides the Fortran defaults to be backward compatible with some nonstandard code. Thus, one cannot say what is correct. Test case: function f() real :: f ! = 0 due to default initialization f = f + 1 end print *, f() ! Should print 1 print *, f() ! should print 1 or 2 with -fno-automatic? end That prints 1.0/1.0 with gfortran, gfortran -fno-automatic and ifort -save. If one replaces f() by g() result(f), gfortran and ifort -save also print 1.0/1.0 and only gfortran -fno-automatic prints 1.0/2.0. Thus, for consistency and for compatibility with the non RESULT version and with other compilers, I agree that the TREE_STATIC does not make sense. (Additionally, Fortran also does not allow SAVE to be specified for the result value.) There are two issues: a) The compile-time check which already complains in resolve.c: function g() result(f) 1 Error: Function result 'f' at (1) cannot have an initializer b) The tree-generation issue, which can be fixed with the following patch. However, I wonder whether one needs to exclude more, the check looks very narrow - and I wouldn't rule out that, e.g., host associated variables or dummy arguments get through that check as well - ditto for use-associated ones, though they should be already static. Untested patch: --- trans-decl.c(revision 181690) +++ trans-decl.c(working copy) @@ -600,7 +601,8 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym) || sym-as-type != AS_EXPLICIT || sym-attr.pointer || sym-attr.allocatable) - !DECL_ARTIFICIAL (decl)) + !DECL_ARTIFICIAL (decl) + !sym-attr.result) TREE_STATIC (decl) = 1; /* Handle threadprivate variables. */
[Bug fortran/51268] [Regression] A subroutine can not know anymore its own interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51268 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-24 14:04:20 UTC --- (In reply to comment #6) Within a scoping unit, identifiers of entities in the following classes: (1) ..., abstract interfaces, generic interfaces, ... are local identifiers in that scoping unit. Within a scoping unit, a local identifier of an entity of class (1) shall not be the same as a global identifier used in that scoping unit. There is no explicit rule regarding the specific interfaces which we are interested in since the beginning. Well, there is: external procedures accessed via USE, which should apply as 1.3.112.2 external procedure -- procedure defined [...] by means other than Fortran (12.6.3), namely (12.6.3): The interface of a procedure defined by means other than Fortran may be specified by an interface body or procedure declaration statement. A procedure shall not have more than one explicit specific interface in a given scoping unit, except that if the interface is accessed by use association, there may be more than one local name for the procedure. As far as I understand, specific interface names accessed by use-association do not conflict with the procedure name itself. Isn't it a key point in our discussion? Well, it is the key point of the discussion. However, the quote is about: USE m, func1 = f, func2 = f where func1 and func2 both are different local names for the same procedure and where the USE statement does not make f a class-1 identifier. And there is also: use m1, only: f use m2, only: f which is OK if m2 use-associates f from m1 (or vice versa).
[Bug fortran/51293] [OOP] ICE on ANY with overloaded == operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51293 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-24 14:13:39 UTC --- This usage requires support for polymorphic arrays - or at least the scalarizer needs to be able to handle this, which is part of the work Paul did. Latest publicly available version of Paul's patch: http://gcc.gnu.org/ml/fortran/2011-11/msg00147.html At least with the version I have, it works. The patch will be submitted in soon; there are still some small issues which should be fixed before it is submitted.
[Bug target/51162] [Regression] ICE: segfault in dump_gimple_call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51162 Sameera sameera.deshpande at arm dot com changed: What|Removed |Added CC||sameera.deshpande at arm ||dot com --- Comment #1 from Sameera sameera.deshpande at arm dot com 2011-11-24 14:31:05 UTC --- The patch for this bug is sent for review http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02350.html. - Sameera
[Bug debug/48150] [4.7 Regression] gcc.dg/guality/sra-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48150
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-24
14:44:57 UTC ---
Yeah, can't reproduce -O2/-O3/-Os issues, but can reproduce
FAIL: gcc.dg/guality/sra-1.c -O1 line 43 a.i == 4
FAIL: gcc.dg/guality/sra-1.c -O1 line 43 a.j == 14
with gdb-7.3.50.20110722-10.fc16.x86_64.
With
GUALITY_GDB_NAME=/usr/src/gdb/obj/gdb/gdb \
make check-gcc RUNTESTFLAGS='guality.exp=sra-1.c'
where that gdb is current trunk gdb I can't reproduce it though, entry_value
works for that case well.
line 43 a.i == 4 test I'd assume it would work fine with latest trunk gdb even
if no entry_value could be looked up:
4004fb: e8 74 ff ff ff callq 400474 bar
400500: c1 e3 04shl$0x4,%ebx
400503: 83 c3 70add$0x70,%ebx
400506: 66 c1 fb 04 sar$0x4,%bx
40050a: 0f bf dbmovswl %bx,%ebx
40050d: 89 df mov%ebx,%edi
40050f: e8 60 ff ff ff callq 400474 bar
with
02c2 004004fb 004004ff (DW_OP_bit_piece: size: 4
offset: 0 ; DW_OP_reg0 (rax); DW_OP_bit_piece: size: 12 offset: 0 ; DW_OP_breg3
(rbx): 7; DW_OP_stack_value; DW_OP_bit_piece: size: 12 offset: 0 ;
DW_OP_bit_piece: size: 4 offset: 0 )
02c2 004004ff 00400503 (DW_OP_bit_piece: size: 4
offset: 0 ; DW_OP_reg6 (rbp); DW_OP_bit_piece: size: 12 offset: 0 ; DW_OP_breg3
(rbx): 7; DW_OP_stack_value; DW_OP_bit_piece: size: 12 offset: 0 ;
DW_OP_bit_piece: size: 4 offset: 0 )
02c2 00400503 00400521 (DW_OP_bit_piece: size: 4
offset: 0 ; DW_OP_reg6 (rbp); DW_OP_bit_piece: size: 12 offset: 0 ;
DW_OP_GNU_entry_value: (DW_OP_reg5 (rdi)); DW_OP_plus_uconst: 7;
DW_OP_stack_value; DW_OP_bit_piece: size: 12 offset: 0 ; DW_OP_bit_piece: size:
4 offset: 0 )
02c2 00400521 00400526 (DW_OP_piece: 2;
DW_OP_GNU_entry_value: (DW_OP_reg5 (rdi)); DW_OP_plus_uconst: 7;
DW_OP_stack_value; DW_OP_bit_piece: size: 12 offset: 0 ; DW_OP_bit_piece: size:
4 offset: 0 )
02c2 End of list
doesn't work with older gdb just because there is the unhandled
DW_OP_GNU_entry_value in the expression and gdb gives up even when it doesn't
affect the a.i bitfield part which lives properly in low bits of $rbp.
The line 43 a.j == 14 case is much more complicated at -O1. The problem is
that
we have 12-bit precision arithmetics done for -O1 and thus we end up with:
(debug_insn 14 13 15 2 (var_location:HI a$j (plus:HI (subreg:HI (reg/v:SI 3 bx
[orig:69 k ] [69]) 0)
(const_int 7 [0x7]))) sra-1.c:41 -1
(nil))
...
(insn 40 18 20 2 (parallel [
(set (reg:SI 3 bx [73])
(ashift:SI (reg:SI 3 bx [orig:69 k ] [69])
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) sra-1.c:39 499 {*ashlsi3_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
...
(insn 41 21 23 2 (parallel [
(set (reg:SI 3 bx [76])
(plus:SI (reg:SI 3 bx [73])
(const_int 112 [0x70])))
(clobber (reg:CC 17 flags))
]) sra-1.c:41 253 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 23 41 24 2 (parallel [
(set (reg:HI 3 bx [77])
(ashiftrt:HI (reg:HI 3 bx [76])
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) sra-1.c:41 543 {*ashrhi3_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 24 23 25 2 (set (reg:SI 3 bx [orig:65 D.2953 ] [65])
(sign_extend:SI (reg:HI 3 bx [77]))) sra-1.c:43 128 {extendhisi2}
(nil))
And var-tracking works on VALUEs with modes, not on weirdo precision types.
If var-tracking would track somehow that it is only interested in low 12 bits
of the value, then it could throgh the above insns figure out that those 12
bits
are first shifted up by 4, then 112 added and then shifted down by 4, thus
low 12 bits of bx in the end contain the right 12 bits with 7 added to it.
[Bug bootstrap/50709] [4.7 Regression] stage3 bootstrap comparison failure with --disable-checking config option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50709 --- Comment #8 from Diego Novillo dnovillo at gcc dot gnu.org 2011-11-24 14:51:02 UTC --- Author: dnovillo Date: Thu Nov 24 14:50:56 2011 New Revision: 181692 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181692 Log: Revert PR bootstrap/50709 * ipa-inline.c (inline_small_functions): Fix checking code to not make effect on fibheap stability. Modified: branches/pph/gcc/ChangeLog branches/pph/gcc/ChangeLog.pph branches/pph/gcc/ipa-inline.c
[Bug debug/48150] [4.7 Regression] gcc.dg/guality/sra-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48150 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-24 14:58:30 UTC --- Perhaps we could use as value of a$j SIGN_EXTRACT from the provided VALUE, i.e. when a$j is 12-bit, assume (debug_insn 14 13 15 2 (var_location:HI a$j (plus:HI (sign_extract:HI (reg/v:SI 3 bx [orig:69 k ] [69]) (const_int 12) (const_int 0)) (const_int 7 [0x7]))) sra-1.c:41 -1 (nil)) instead of (debug_insn 14 13 15 2 (var_location:HI a$j (plus:HI (subreg:HI (reg/v:SI 3 bx [orig:69 k ] [69]) 0) (const_int 7 [0x7]))) sra-1.c:41 -1 (nil)) and then on shift left, reversable operation and shift right note that the value for the sign_extract would live in (sign_extract:HI (value of bx after shift left) (const_int 12) (const_int 4)) after the left shift, etc. I guess it would be pretty difficult and for not very common case though.
[Bug c++/51295] New: [C++11][noexcept] Wrong c'tor exception-specification with non-trivial d'tor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51295
Bug #: 51295
Summary: [C++11][noexcept] Wrong c'tor exception-specification
with non-trivial d'tor
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@gcc.gnu.org
I became aware of the following problem, when attempting to create something
like boost::optional with all the C++11 bells and whistles.
gcc 4.7.0 2019 (experimental) in C++11 mode with -Wall rejects the
following code:
//---
struct B {
~B() {}
};
static_assert(noexcept(B{}), Error); // Line 5
struct B2 {
B2() noexcept {}
~B2() {}
};
static_assert(noexcept(B2{}), Error); // Line 12
struct D : B2 {
D() noexcept = default; // Line 15
};
//---
main.cpp|5|error: static assertion failed: Error|
main.cpp|12|error: static assertion failed: Error|
main.cpp|15|error: function 'D::D()' defaulted on its first declaration with an
exception-specification that differs from the implicit declaration 'D::D()'
It seems that in some situations the compiler-deduced exception-specification
of special members gives incorrect values not following FDIS rules. The root of
the problem seems to be located when there exist user-provided destructors
without exception-specification, even though these should behave as if they
where declared as noexcept(true). In addition to that such destructors can
influence the deduced exception-specification of constructors, as shown for
type D.
A current workaround is to mark the destructors with noexcept as well. None the
less this is a rather huge problem, because due to the popular existence of
destructors without exception-specification this can lead to large number of
failures in test cases.
[Bug rtl-optimization/50290] [4.7 Regression] ICE: in distribute_notes, at combine.c:13282 with -O2 -fwhole-program -fno-tree-loop-optimize -fno-tree-vrp -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50290 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-24 15:23:22 UTC --- Author: jakub Date: Thu Nov 24 15:23:18 2011 New Revision: 181694 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181694 Log: PR rtl-optimization/50290 * gcc.dg/pr50290.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr50290.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/50290] [4.7 Regression] ICE: in distribute_notes, at combine.c:13282 with -O2 -fwhole-program -fno-tree-loop-optimize -fno-tree-vrp -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50290 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-24 15:28:23 UTC --- Fixed.
[Bug c++/51248] [4.6/4.7 Regression] ICE with pointer to enum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51248 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-24 15:34:32 UTC --- Introduced with http://gcc.gnu.org/viewcvs?root=gccview=revrev=165935
[Bug tree-optimization/51058] [4.7 Regression] ICE: gimple check: expected gimple_assign(error_mark), have gimple_call() in gimple_assign_rhs_code, at gimple.h:1992
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51058 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-24 15:35:31 UTC --- Assuming this is fixed.
[Bug c/51294] spurious warning from -Wconversion in C and C++ in conditional expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic CC||manu at gcc dot gnu.org Summary|spurious warning from |spurious warning from |-Wconversion in C and C++ |-Wconversion in C and C++ ||in conditional expressions --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-11-24 15:46:16 UTC --- (In reply to comment #2) (In reply to comment #0) 0 is a const so the compiler should be able to choose the correct type. 0 is an int, so the compiler is required by the standard to make the conditional expression (haveBar?bar_:0) have type int. It shouldn't warn though, as the conversion from int to char won't alter the value. This was implemented in this patch: http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00582.html which was rejected. Perhaps a cut-down version that addresses only this issue would be accepted. But perhaps no. Feel free to take it. BTW, clang does not warn for this case, while it does if bar_ is an int: pr51294.c:3:23: warning: implicit conversion loses integer precision: 'int' to 'char' [-Wconversion] char zuul = haveBar?bar_:0; ~^~~~ 1 warning generated. It also points to the correct location of the issue, whereas GCC doesn't.
[Bug fortran/51268] [Regression] A subroutine can not know anymore its own interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51268 --- Comment #8 from Sebastien Bardeau bardeau at iram dot fr 2011-11-24 15:58:31 UTC --- (In reply to comment #7) (In reply to comment #6) Within a scoping unit, identifiers of entities in the following classes: (1) ..., abstract interfaces, generic interfaces, ... are local identifiers in that scoping unit. Within a scoping unit, a local identifier of an entity of class (1) shall not be the same as a global identifier used in that scoping unit. There is no explicit rule regarding the specific interfaces which we are interested in since the beginning. Well, there is: external procedures accessed via USE, which should apply as 1.3.112.2 external procedure -- procedure defined [...] by means other than Fortran (12.6.3), namely (12.6.3): The interface of a procedure defined by means other than Fortran may be specified by an interface body or procedure declaration statement. So I think at this stage we disagree on the standard interpretation. External procedures are just external procedures declared with the EXTERNAL statement. If their interface is provided thanks to a specific interface, then the rules regarding the specific interfaces must apply, if such rules exist. Furthermore in our case we are discussing Fortran-based subroutines and their interfaces, so there are no external procedures defined by other means than Fortran to be considered here. A procedure shall not have more than one explicit specific interface in a given scoping unit, except that if the interface is accessed by use association, there may be more than one local name for the procedure. As far as I understand, specific interface names accessed by use-association do not conflict with the procedure name itself. Isn't it a key point in our discussion? Well, it is the key point of the discussion. However, the quote is about: USE m, func1 = f, func2 = f where func1 and func2 both are different local names for the same procedure and where the USE statement does not make f a class-1 identifier. And there is also: use m1, only: f use m2, only: f which is OK if m2 use-associates f from m1 (or vice versa). Well, by reading again and again the corrigendum added here, I would have said that it corrects on purpose the problem we are facing. We must not be the only ones trying to write and share among files the specific interfaces to Fortran77-based procedures...
[Bug c++/51009] [4.7 Regression] ICE in verify_gimple_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51009 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-24 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Component|middle-end |c++ Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-24 16:06:07 UTC --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=180267
[Bug testsuite/50885] [4.7 Regression] FAIL: gcc.dg/strlenopt-22.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50885 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-24 16:08:45 UTC --- http://gcc.gnu.org/viewcvs?root=gccview=revrev=181010 http://gcc.gnu.org/viewcvs?root=gccview=revrev=181009 should fix this.
[Bug testsuite/51258] 64-bit gcc.dg/atomic-compare-exchange-5.c link failure on 32-bit Solaris/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51258 --- Comment #10 from Rainer Orth ro at gcc dot gnu.org 2011-11-24 16:34:16 UTC --- Author: ro Date: Thu Nov 24 16:34:09 2011 New Revision: 181697 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181697 Log: Fix several atomic tests on 32-bit x86 (PR testsuite/51258) PR testsuite/51258 * gcc.dg/atomic-compare-exchange-5.c: Add -mcx16 on i?86-*-*. * gcc.dg/atomic-exchange-5.c: Likewise. * gcc.dg/atomic-load-5.c: Likewise. * gcc.dg/atomic-op-5.c: Likewise. * gcc.dg/atomic-store-5.c: Likewise. * gcc.dg/simulate-thread/atomic-other-int128.c: Fix typo. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/atomic-compare-exchange-5.c trunk/gcc/testsuite/gcc.dg/atomic-exchange-5.c trunk/gcc/testsuite/gcc.dg/atomic-load-5.c trunk/gcc/testsuite/gcc.dg/atomic-op-5.c trunk/gcc/testsuite/gcc.dg/atomic-store-5.c trunk/gcc/testsuite/gcc.dg/simulate-thread/atomic-other-int128.c
[Bug fortran/46371] [Coarray] [OOP] SELECT TYPE: scalar coarray variable is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46371 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-24 16:41:54 UTC --- Polymorphic array example: Todo check for validity and fix. program p use m class(foo), allocatable :: o_bar(:)[:] integer :: j allocate(foo :: o_bar(5)[*]) select type(o_bar) type is(foo) j = o_bar(2)[1]%i end select !! FIXME: type if (foo) fails with: !! Associate-name '__tmp_type_foo' at (1) is used as array select type(a = o_bar) type is (foo) j = a(1)[1]%i end select !! FIXME: a should be a rank 0 not a rank 1 !!array select type(a = o_bar(1)) type is (foo) j = a[2]%i end select end program p
[Bug target/49865] [4.7 Regression] Unnecessary reload causes small bloat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49865 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-24 16:59:03 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=171649
[Bug c/51294] spurious warning from -Wconversion in C and C++ in conditional expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294 --- Comment #4 from Bruce Adams tortoise_74 at yahoo dot co.uk 2011-11-24 17:09:56 UTC --- Shouldn't integral conversion rules apply if the types of the second and third arguments to a conditional expression differ. So zero should be converted from the default int to a char as presumably the older version of gcc did. Perhaps a language lawyer could explain why this is or isn't a bug. Though obviously warnings are not covered by the standard. Note: (haveBar?bar_:(char)0) is not an acceptable workaround for C++ if -Wold-style-cast is used (which is in my experience typical). It would have to be (haveBar?bar_:static_castchar(0)) which is a notch higher in annoyingness.
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-24 17:44:03 UTC --- This test uses the run-time test to check if .ctors and .init_array input sections can be mixed. Separate tests don't make much sense. Would you care to elaborate why checking the versions resp. features of the prerequisite components is not enough? Btw., what libc is required? I've successfully built and tested with --enable-init-fini-array on Solaris 11 (with no glibc in sight), provided I run a make bootstrap4 and ignore the comparison failure in stage3. Rainer
[Bug libstdc++/51296] New: Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 Bug #: 51296 Summary: Several 30_threads tests FAIL on Tru64 UNIX Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: r...@gcc.gnu.org Host: alpha-dec-osf5.1b Target: alpha-dec-osf5.1b Build: alpha-dec-osf5.1b Between 20111021 (r180287) and 2028 (r180617), several 30_threads tests started to FAIL on Tru64 UNIX: FAIL: 30_threads/async/async.cc execution test terminate called after throwing an instance of 'std::system_error' what(): Invalid argument FAIL: 30_threads/condition_variable/members/1.cc execution test Assertion failed: false, file /vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/30_threads/condition_variable/members/1.cc, line 49 FAIL: 30_threads/condition_variable/members/2.cc execution test Assertion failed: false, file /vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/30_threads/condition_variable/members/2.cc, line 49 FAIL: 30_threads/condition_variable_any/members/1.cc execution test FAIL: 30_threads/condition_variable_any/members/2.cc execution test FAIL: 30_threads/future/cons/constexpr.cc scan-assembler-not _ZNSt6futureIvEC2Ev FAIL: 30_threads/future/cons/constexpr.cc scan-assembler-not _ZNSt6futureIiEC2Ev FAIL: 30_threads/lock/1.cc execution test FAIL: 30_threads/lock/3.cc execution test FAIL: 30_threads/lock/4.cc execution test FAIL: 30_threads/mutex/lock/1.cc execution test FAIL: 30_threads/mutex/try_lock/1.cc execution test FAIL: 30_threads/mutex/try_lock/2.cc execution test FAIL: 30_threads/shared_future/cons/constexpr.cc scan-assembler-not _ZNSt13shared_futureIvEC2Ev FAIL: 30_threads/shared_future/cons/constexpr.cc scan-assembler-not _ZNSt13shared_futureIiEC2Ev FAIL: 30_threads/thread/native_handle/typesizes.cc execution test FAIL: 30_threads/try_lock/1.cc execution test FAIL: 30_threads/try_lock/2.cc execution test FAIL: 30_threads/try_lock/3.cc execution test FAIL: 30_threads/try_lock/4.cc execution test FAIL: 30_threads/unique_lock/cons/2.cc execution test FAIL: 30_threads/unique_lock/cons/4.cc execution test FAIL: 30_threads/unique_lock/locking/1.cc execution test FAIL: 30_threads/unique_lock/locking/2.cc execution test FAIL: 30_threads/unique_lock/modifiers/1.cc execution test FAIL: 30_threads/unique_lock/modifiers/2.cc execution test This may be due to this change: 2011-10-22 Jonathan Wakely jwakely@gmail.com PR libstdc++/50196 * acinclude.m4 (GLIBCXX_HAS_GTHREADS): Don't depend on _POSIX_TIMEOUTS. * configure: Regenerate. * include/std/mutex (timed_mutex, recursive_timed_mutex): Define On this platform, _POSIX_TIMEOUTS is missing in unistd.h. I find that those tests are UNSUPPORTED on the 4.6 branch. Rainer
[Bug fortran/51218] [4.6/4.7 Regression] Potential optimization bug due to implicit_pure?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51218 --- Comment #21 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-24 17:57:45 UTC --- Author: burnus Date: Thu Nov 24 17:57:41 2011 New Revision: 181698 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181698 Log: 2011-11-24 Tobias Burnus bur...@net-b.de PR fortran/51218 * resolve.c (pure_subroutine): If called subroutine is impure, unset implicit_pure. (resolve_function): Move impure check to simplify code. 2011-11-24 Tobias Burnus bur...@net-b.de PR fortran/51218 * gfortran.dg/implicit_pure_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/implicit_pure_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/51285] [4.7 Regression] internal compiler error: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51285 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-24 18:07:14 UTC --- (In reply to comment #2) In that range there is the following commit http://gcc.gnu.org/viewcvs/trunk/gcc/fortran/trans-decl.c?r1=172307r2=172604pathrev=172604 It could be a coincidence, but this thing - /* Do not use procedures that have a procedure argument because this - can result in problems of multiple decls during inlining. */ seems to hold. The ICE is removed with gfortran -O3 -fno-inline-functions bug.f90 I think it can well be that that commit exposes the bug as it removed a double declaration for the same function. The removal should allow inlining. Thus, that's in line with -fno-inline-functions fixing the issue on the trunk. However, I doubt that the commit causes the bug.
[Bug gcov-profile/51297] New: [4.7 regressions] Many gcov tests FAIL on Tru64 UNIX, Solaris 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297 Bug #: 51297 Summary: [4.7 regressions] Many gcov tests FAIL on Tru64 UNIX, Solaris 8 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: nat...@gcc.gnu.org Host: alpha-dec-osf5.1b, *-*-solaris2.8 Target: alpha-dec-osf5.1b, *-*-solaris2.8 Build: alpha-dec-osf5.1b, *-*-solaris2.8 Between 2010 (r181259) and 2014 (r181350), many gcov tests started to FAIL on Solaris 8 (SPARC and x86) and Tru64 UNIX V5.1B: FAIL: g++.dg/gcov/gcov-1.C gcov failed: FAIL: g++.dg/gcov/gcov-1.C gcov failed: FAIL: g++.dg/gcov/gcov-10.C gcov failed: FAIL: g++.dg/gcov/gcov-10.C gcov failed: FAIL: g++.dg/gcov/gcov-11.C gcov failed: FAIL: g++.dg/gcov/gcov-11.C gcov failed: FAIL: g++.dg/gcov/gcov-2.C gcov failed: FAIL: g++.dg/gcov/gcov-2.C gcov failed: FAIL: g++.dg/gcov/gcov-3.C gcov failed: FAIL: g++.dg/gcov/gcov-3.C gcov failed: FAIL: g++.dg/gcov/gcov-4.C gcov failed: FAIL: g++.dg/gcov/gcov-4.C gcov failed: FAIL: g++.dg/gcov/gcov-5.C gcov failed: FAIL: g++.dg/gcov/gcov-5.C gcov failed: FAIL: g++.dg/gcov/gcov-7.C gcov failed: FAIL: g++.dg/gcov/gcov-7.C gcov failed: FAIL: gcc.misc-tests/gcov-1.c gcov failed: FAIL: gcc.misc-tests/gcov-10.c gcov failed: FAIL: gcc.misc-tests/gcov-10b.c gcov failed: FAIL: gcc.misc-tests/gcov-11.c gcov failed: FAIL: gcc.misc-tests/gcov-12.c gcov failed: FAIL: gcc.misc-tests/gcov-13.c gcov failed: FAIL: gcc.misc-tests/gcovpart-13b.c gcov failed: FAIL: gcc.misc-tests/gcov-14.c (test for excess errors) WARNING: gcc.misc-tests/gcov-14.c compilation failed to produce executable FAIL: gcc.misc-tests/gcov-14.c gcov failed: FAIL: gcc.misc-tests/gcov-15.c gcov failed: FAIL: gcc.misc-tests/gcov-2.c gcov failed: FAIL: gcc.misc-tests/gcov-3.c gcov failed: FAIL: gcc.misc-tests/gcov-4.c gcov failed: FAIL: gcc.misc-tests/gcov-4b.c gcov failed: FAIL: gcc.misc-tests/gcov-5b.c gcov failed: FAIL: gcc.misc-tests/gcov-6.c gcov failed: FAIL: gcc.misc-tests/gcov-7.c gcov failed: FAIL: gcc.misc-tests/gcov-8.c gcov failed: FAIL: gcc.misc-tests/gcov-9.c gcov failed: The message is pretty useless since it states no reason. The problem is that gcov dies with a SEGV: /var/gcc/regression/trunk/8-gcc-gas/build/gcc/gcov gcov-1.c Segmentation Fault Program received signal SIGSEGV, Segmentation fault. 0x08056d17 in name_search (a_=0x80a2f70, b_=0x7ff8) at /vol/gcc/src/hg/trunk/local/gcc/gcov.c:838 838 return strcmp (a, b-name); (gdb) where #0 0x08056d17 in name_search (a_=0x80a2f70, b_=0x7ff8) at /vol/gcc/src/hg/trunk/local/gcc/gcov.c:838 #1 0xbf6fc6ae in bsearch () from /usr/lib/libc.so.1 #2 0x08056d88 in find_source (file_name=0x80a2f70 error reading variable) at /vol/gcc/src/hg/trunk/local/gcc/gcov.c:866 #3 0x0808066e in read_graph_file (argc=2, argv=0x80479f4) at /vol/gcc/src/hg/trunk/local/gcc/gcov.c:1017 #4 process_file (argc=2, argv=0x80479f4) at /vol/gcc/src/hg/trunk/local/gcc/gcov.c:571 #5 main (argc=2, argv=0x80479f4) at /vol/gcc/src/hg/trunk/local/gcc/gcov.c:423 The second argument to name_search is invalid, it seems. Rainer
[Bug gcov-profile/51297] [4.7 regressions] Many gcov tests FAIL on Tru64 UNIX, Solaris 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297 --- Comment #1 from Nathan Sidwell nathan at gcc dot gnu.org 2011-11-24 18:30:40 UTC --- The line numbers in the backtrace don't seem to correspond to current sources. for instance line 866 is the definition of find_source, not the location of one of the two bsearch calls. which of the two bsearch calls is blowing up? this one: name_map = (name_map_t *)bsearch (file_name, names, n_names, sizeof (*names), name_search); or this one: name_map = (name_map_t *)bsearch (canon, names, n_names, sizeof (*names), name_search); What are the values being passed to the bsearch call? Oh, I see that it appears the string being passed to 'find_source' is unreadable: #2 0x08056d88 in find_source (file_name=0x80a2f70 error reading variable) at /vol/gcc/src/hg/trunk/local/gcc/gcov.c:866 What does gcov-dump -lo tell you about the gcno file?
[Bug gcov-profile/51297] [4.7 regression] Many gcov tests FAIL on Tru64, Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Target|alpha-dec-osf5.1b, |alpha-dec-osf5.1b, |*-*-solaris2.8 |*-*-solaris2.[89] Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-24 CC||ebotcazou at gcc dot ||gnu.org Host|alpha-dec-osf5.1b, |alpha-dec-osf5.1b, |*-*-solaris2.8 |*-*-solaris2.[89] Target Milestone|--- |4.7.0 Summary|[4.7 regressions] Many gcov |[4.7 regression] Many gcov |tests FAIL on Tru64 UNIX, |tests FAIL on Tru64, |Solaris 8 |Solaris 8 and 9 Ever Confirmed|0 |1 Build|alpha-dec-osf5.1b, |alpha-dec-osf5.1b, |*-*-solaris2.8 |*-*-solaris2.[89] --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-24 18:36:36 UTC --- I have them on SPARC/Solaris 8 and 9.
[Bug c/51294] spurious warning from -Wconversion in C and C++ in conditional expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-24 18:37:31 UTC --- (In reply to comment #4) Shouldn't integral conversion rules apply if the types of the second and third arguments to a conditional expression differ. Yes. So zero should be converted from the default int to a char No, the char is converted to int. Hence the warning. as presumably the older version of gcc did. Nope. Perhaps a language lawyer could explain why this is or isn't a bug. I did ;) Though obviously warnings are not covered by the standard. Note: (haveBar?bar_:(char)0) is not an acceptable workaround for C++ if -Wold-style-cast is used (which is in my experience typical). It would have to be (haveBar?bar_:static_castchar(0)) which is a notch higher in annoyingness. OK then: (haveBar?bar_:char())
[Bug gcov-profile/51297] [4.7 regression] Many gcov tests FAIL on Tru64, Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-24 18:40:43 UTC --- What are the values being passed to the bsearch call? Very likely the problem indeed. qsort is known to be very picky on Solaris 8 and 9, in the sense that the comparer function must impose a total order on the array or else the function crashes. I presume it's the same for bsearch.
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-11-24 CC|redi at gcc dot gnu.org | AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-24 18:53:29 UTC --- The point of that change was to enable C++11 threading on platforms that support Pthreads without the Timeouts option, so the fact the tests now run instead of being UNSUPPORTED is intended. We could always take alpha*-*-osf* out of the target list, but I'll try to figure out how to make them work on Tru64
[Bug gcov-profile/51297] [4.7 regression] Many gcov tests FAIL on Tru64, Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297 --- Comment #4 from Nathan Sidwell nathan at gcc dot gnu.org 2011-11-24 19:08:24 UTC --- the names being entered into the array are unique, so there is a total ordering -- I think that's a red herring. I think the problem is the string read from the data file is corrupted in some way. Is that clueful enough?
[Bug middle-end/51285] [4.7 Regression] internal compiler error: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51285 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2011-11-24 19:25:06 UTC --- Simplified testcase showing Tobias patch is unrelated. Is this still triggered by the same range ? SUBROUTINE smm_dnn_4_10_10_1_1_2_1(A,B,C) REAL :: C(4,10), B(10,10), A(4,10) DO j= 1 , 10 , 2 DO i= 1 , 4 , 1 DO l= 1 , 10 , 1 C(i+0,j+0)=C(i+0,j+0)+A(i+0,l+0)*B(l+0,j+0) C(i+0,j+1)=C(i+0,j+1)+A(i+0,l+0)*B(l+0,j+1) ENDDO ENDDO ENDDO END SUBROUTINE SUBROUTINE smm_dnn_4_10_10_6_4_1_1(A,B,C) REAL :: C(4,10), B(10,10), A(4,10) DO l= 1 , 10 , 1 DO j= 1 , 10 , 1 C(i+0,j+0)=C(i+0,j+0)+A(i+0,l+0)*B(l+0,j+0) ENDDO ENDDO END SUBROUTINE SUBROUTINE S(A,B,C) INTEGER :: Nmin=2,Niter=100 REAL, DIMENSION(:,:), ALLOCATABLE :: A,B,C DO imin=1,Nmin DO i=1,Niter CALL smm_dnn_4_10_10_1_1_2_1(A,B,C) ENDDO DO i=1,Niter CALL smm_dnn_4_10_10_6_4_1_1(A,B,C) ENDDO CALL foo() ENDDO END SUBROUTINE
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-24 19:26:23 UTC --- (In reply to comment #0) FAIL: 30_threads/thread/native_handle/typesizes.cc execution test This one should definitely not run on Tru64, disabling that is pre-approved. Is -pthread all that's needed for this platform?
[Bug middle-end/51279] xplor-nih-2.27/nmrPot/solnScatPot.cc ICEs on -O1 -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51279 --- Comment #5 from Jack Howarth howarth at nitro dot med.uc.edu 2011-11-24 19:32:52 UTC --- This ICE also can be reproduced at r181697 on x86_64-unknown-linux-gnu (x86_64 Fedora 15).
[Bug gcov-profile/51297] [4.7 regression] Many gcov tests FAIL on Tru64, Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-24 19:46:20 UTC --- the names being entered into the array are unique, so there is a total ordering -- I think that's a red herring. I think the problem is the string read from the data file is corrupted in some way. Is that clueful enough? Very likely a debugging artifact. Here's my backtrace: #0 name_search (a_=0x554a0, b_=0x0) at /nile.build/botcazou/gcc-head/src/gcc/gcov.c:838 #1 0xff2360e0 in bsearch () from /usr/lib/libc.so.1 #2 0x00015f34 in find_source (file_name=0x554a0 gcov-1.c) at /nile.build/botcazou/gcc-head/src/gcc/gcov.c:866 #3 0x0003a828 in read_graph_file () at /nile.build/botcazou/gcc-head/src/gcc/gcov.c:1017 #4 process_file (file_name=optimized out) at /nile.build/botcazou/gcc-head/src/gcc/gcov.c:571 #5 main (argc=-1814981296, argv=0xffbefbe4) at /nile.build/botcazou/gcc-head/src/gcc/gcov.c:423 In fact the array is empty: (gdb) p n_names $1 = 0 (gdb) p names $2 = (name_map_t *) 0x0
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-24
20:30:43 UTC ---
What does this program do, compiled with -std=c++11 -pthread ?
#include mutex
#include system_error
#include assert.h
#define VERIFY assert
int main()
{
typedef std::mutex mutex_type;
typedef std::unique_lockmutex_type lock_type;
try
{
mutex_type m;
lock_type lock(m);
VERIFY( lock.owns_lock() );
VERIFY( (bool)lock );
}
catch (const std::system_error e)
{
VERIFY( false );
}
catch (...)
{
VERIFY( false );
}
return 0;
}
[Bug fortran/51218] [4.6/4.7 Regression] Potential optimization bug due to implicit_pure?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51218 --- Comment #22 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-24 20:44:32 UTC --- Author: burnus Date: Thu Nov 24 20:44:28 2011 New Revision: 181699 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181699 Log: 2011-11-24 Tobias Burnus bur...@net-b.de PR fortran/51218 * resolve.c (pure_subroutine): If called subroutine is impure, unset implicit_pure. (resolve_function): Move impure check to simplify code. 2011-11-24 Tobias Burnus bur...@net-b.de PR fortran/51218 * gfortran.dg/implicit_pure_1.f90: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/implicit_pure_1.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/resolve.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/51218] [4.6/4.7 Regression] Potential optimization bug due to implicit_pure?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51218 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #23 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-24 20:51:25 UTC --- FIXED - hopefully completely. Thanks for the bugreport and the (valid) testcase.
[Bug gcov-profile/51297] [4.7 regression] Many gcov tests FAIL on Tru64, Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297 --- Comment #6 from Nathan Sidwell nathan at acm dot org 2011-11-24 21:36:20 UTC --- On 11/24/11 19:46, ebotcazou at gcc dot gnu.org wrote: In fact the array is empty: (gdb) p n_names $1 = 0 (gdb) p names $2 = (name_map_t *) 0x0 d'oh! A fix will be right up.
[Bug gcov-profile/51297] [4.7 regression] Many gcov tests FAIL on Tru64, Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-24 21:54:15 UTC --- d'oh! A fix will be right up. Thanks. I confirm that adding if (n_names 0) in the right places works fine.
[Bug target/43745] [avr] g++ puts VTABLES in SRAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745
--- Comment #5 from Tomasz Francuz tfrancuz at mp dot pl 2011-11-24 21:56:17
UTC ---
Ok, here is the code:
class test
{
public:
test() {};
virtual void vfunction();
};
void test::vfunction()
{
}
int main()
{
}
After compilation 6 bytes of SRAM is occupied by test object vtable. Here is a
resulting part of map file:
*(.data)
.data 0x008001000x0
c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr51/crtm128.o
.data 0x008001000x6 gpp.o
0x00800100vtable for test
.data 0x008001060x0
c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/avr51\libgcc.a(_exit.o)
*(.data*)
[Bug target/51134] [4.7 Regression] x86 memset/memcpy expansion is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51134 --- Comment #13 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-11-24 22:11:16 UTC --- Author: hjl Date: Thu Nov 24 22:11:12 2011 New Revision: 181701 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181701 Log: Revert revision 181357. gcc/ 2011-11-24 H.J. Lu hongjiu...@intel.com PR target/51134 * config/i386/i386.h (processor_costs): Revert revision 181357. * config/i386/i386.c (cost models): Likewise. (core_cost): Likewise. (promote_duplicated_reg): Likewise. (promote_duplicated_reg_to_size): Likewise. (processor_target): Likewise. (expand_set_or_movmem_via_loop_with_iter): Likewise. (expand_set_or_movmem_via_loop): Likewise. (emit_strset): Likewise. (expand_movmem_epilogue): Likewise. (expand_setmem_epilogue): Likewise. (expand_movmem_prologue): Likewise. (expand_setmem_prologue): Likewise. (expand_constant_movmem_prologue): Likewise. (expand_constant_setmem_prologue): Likewise. (decide_alg): Likewise. (decide_alignment): Likewise. (ix86_expand_movmem): Likewise. (ix86_expand_setmem): Likewise. (ix86_slow_unaligned_access): Likewise. * config/i386/i386.md (strset): Likewise. * config/i386/sse.md (vec_dupv4si): Likewise. (vec_dupv2di): Likewise. gcc/testsuite/ 2011-11-24 H.J. Lu hongjiu...@intel.com PR target/51134 * gcc.target/i386/sw-1.c: Revert revision 181357. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-opts.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/i386.opt trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/sw-1.c
[Bug fortran/50408] [4.6/4.7 regression] ICE in transfer_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50408
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-24
22:13:06 UTC ---
That a -fwhole-file regression, which became the default in 4.6. The work
around is -fno-whole-file.
The problem is in gfc_get_extern_function_decl:
gfc_find_symbol (sym-name, gsym-ns, 0, s);
if (s s-backend_decl)
{
sym-backend_decl = s-backend_decl;
return sym-backend_decl;
}
The problem is that this does not set
sym-ts.u.derived{,-components{,-next}}-backend_decl
for BT_DERIVED/BT_CLASS; one might also need to update
sym-ts.u.cl...
for BT_CHARACTER.
Note: There are more places in trans*.c which call gfc_find_gsymbol
[Bug gcov-profile/51297] [4.7 regression] Many gcov tests FAIL on Tru64, Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297 --- Comment #8 from Nathan Sidwell nathan at acm dot org 2011-11-24 22:12:11 UTC --- On 11/24/11 21:54, ebotcazou at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297 --- Comment #7 from Eric Botcazouebotcazou at gcc dot gnu.org 2011-11-24 21:54:15 UTC --- d'oh! A fix will be right up. Thanks. I confirm that adding if (n_names 0) in the right places works fine. Hm, can you try the attached patch? It avoids passing a null pointer, which is not permitted. Passing zero as nmemb is permitted (7.20.5 para 1 of c99). So I'm a little puzzled as to why bsearch managed to call the comparison function at all. I'd like to understand if we're dealing with a weird, but legal, implementation, or one that's got a bug.
[Bug fortran/50408] [4.6/4.7 regression] ICE in transfer_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50408
--- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-24
22:20:55 UTC ---
Patch for this issue - note that there are more places which have to be checked
and potentially fixed. The second part is just a performance/algorithmic
optimization, which occurs in real code.
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1671,6 +1671,9 @@ gfc_get_extern_function_decl (gfc_symbol * sym)
if (s s-backend_decl)
{
sym-backend_decl = s-backend_decl;
+ if ((sym-ts.type == BT_DERIVED || sym-ts.type == BT_CLASS)
+ sym-ts.u.derived-backend_decl == NULL)
+ gfc_get_derived_type (sym-ts.u.derived);
return sym-backend_decl;
}
}
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -2188,6 +2188,9 @@ gfc_copy_dt_decls_ifequal (gfc_symbol *from, gfc_symbol
*to,
gfc_component *to_cm;
gfc_component *from_cm;
+ if (from == to)
+return 1;
+
if (from-backend_decl == NULL
|| !gfc_compare_derived_types (from, to))
return 0;
[Bug fortran/51250] [4.7 Regression] Bug with SUM(,dim,mask)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51250 --- Comment #5 from Harald Anlauf anlauf at gmx dot de 2011-11-24 22:39:10 UTC --- (In reply to comment #4) The patch in comment #4 works for me without regressions! Thanks, Harald
[Bug libgomp/51298] New: libgomp team_barrier locking failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51298
Bug #: 51298
Summary: libgomp team_barrier locking failures
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amo...@gmail.com
There seems to be a locking related failure in the linux barrier
implementation, because libgomp testcases hang on power7. This is both before
and after the fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51249
Here's a dump of some info from one of the hung tests that might help pin down
the problem. Then again, it might not. power7 quite aggressively speculates
reads, so I suspect a missing read barrier somewhere.
(gdb) bt
#0 0x0fff91ebf36c in sys_futex0 (val=0, op=optimized out,
addr=0x100210d4) at
/home/amodra/src/gcc-current/libgomp/config/linux/powerpc/futex.h:48
#1 futex_wait (val=0, addr=0x100210d4) at
/home/amodra/src/gcc-current/libgomp/config/linux/powerpc/futex.h:61
#2 do_wait (val=0, addr=optimized out) at
/home/amodra/src/gcc-current/libgomp/config/linux/wait.h:64
#3 gomp_team_barrier_wait_end (bar=0x100210d0, state=0) at
/home/amodra/src/gcc-current/libgomp/config/linux/bar.c:109
#4 0x0fff91eb7540 in GOMP_barrier () at
/home/amodra/src/gcc-current/libgomp/barrier.c:40
#5 0x1f10 in .test_barrier.822._omp_fn.2 () at
/home/amodra/src/gcc-current/libgomp/testsuite/libgomp.fortran/omp_parse2.f90:59
#6 0x1b90 in test_barrier () at
/home/amodra/src/gcc-current/libgomp/testsuite/libgomp.fortran/omp_parse2.f90:56
#7 MAIN__ () at
/home/amodra/src/gcc-current/libgomp/testsuite/libgomp.fortran/omp_parse2.f90:5
#8 main (argc=optimized out, argv=optimized out) at
/home/amodra/src/gcc-current/libgomp/testsuite/libgomp.fortran/omp_parse2.f90:2
#9 0x0fff91ccf05c in .generic_start_main () from /lib64/power7/libc.so.6
#10 0x0fff91ccf27c in .__libc_start_main () from /lib64/power7/libc.so.6
#11 0x in ?? ()
(gdb) up 3
#3 gomp_team_barrier_wait_end (bar=0x100210d0, state=0) at
/home/amodra/src/gcc-current/libgomp/config/linux/bar.c:109
(gdb) p *bar
$1 = {total = 4, generation = 0, awaited = 1}
(gdb) p state
$2 = 0
(gdb) p generation
$3 = 0
(gdb) p gomp_tls_data
$4 = {fn = 0, data = 0x0, ts = {team = 0x10021050, work_share = 0x10021150,
last_work_share = 0x0, team_id = 0, level = 1, active_level = 1, single_count =
0, static_trip = 0}, task = 0x10021568, release = {count = 0}, thread_pool =
0x10021760}
(gdb) p *gomp_tls_data.ts.team
$5 = {nthreads = 4, work_share_chunk = 8, prev_ts = {team = 0x0, work_share =
0x0, last_work_share = 0x0, team_id = 0, level = 0, active_level = 0,
single_count = 0, static_trip = 0}, master_release = {count = 0},
ordered_release = 0x10021708, work_share_list_alloc = 0x100211d0,
work_share_list_free = 0x0, single_count = 0, barrier = {total = 4, generation
= 0, awaited = 1}, work_shares = {{sched = GFS_RUNTIME, mode = 0, {{chunk_size
= 0, end = 0, incr = 0}, {chunk_size_ull = 0, end_ull = 0, incr_ull = 0}},
ordered_team_ids = 0x0, ordered_num_used = 0, ordered_owner = 0, ordered_cur =
0, next_alloc = 0x0, lock = {flag = 0}, threads_completed = 0, {next = 0,
next_ull = 0, copyprivate = 0x0}, {next_ws = 0x0, next_free = 0x0},
inline_ordered_team_ids = 0x100211a8}, {sched = GFS_RUNTIME, mode = 0,
{{chunk_size = 0, end = 0, incr = 0}, {chunk_size_ull = 0, end_ull = 0,
incr_ull = 0}}, ordered_team_ids = 0x0, ordered_num_used = 0, ordered_owner =
0, ordered_cur = 0, next_alloc = 0x0, lock = {flag = 0}, threads_completed = 0,
{next = 0, next_ull = 0, copyprivate = 0x0}, {next_ws = 0x10021250, next_free =
0x10021250}, inline_ordered_team_ids = 0x10021228}, {sched = GFS_RUNTIME, mode
= 0, {{chunk_size = 0, end = 0, incr = 0}, {chunk_size_ull = 0, end_ull = 0,
incr_ull = 0}}, ordered_team_ids = 0x0, ordered_num_used = 0, ordered_owner =
0, ordered_cur = 0, next_alloc = 0x0, lock = {flag = 0}, threads_completed = 0,
{next = 0, next_ull = 0, copyprivate = 0x0}, {next_ws = 0x100212d0, next_free =
0x100212d0}, inline_ordered_team_ids = 0x100212a8}, {sched = GFS_RUNTIME, mode
= 0, {{chunk_size = 0, end = 0, incr = 0}, {chunk_size_ull = 0, end_ull = 0,
incr_ull = 0}}, ordered_team_ids = 0x0, ordered_num_used = 0, ordered_owner =
0, ordered_cur = 0, next_alloc = 0x0, lock = {flag = 0}, threads_completed = 0,
{next = 0, next_ull = 0, copyprivate = 0x0}, {next_ws = 0x10021350, next_free =
0x10021350}, inline_ordered_team_ids = 0x10021328}, {sched = GFS_RUNTIME, mode
= 0, {{chunk_size = 0, end = 0, incr = 0}, {chunk_size_ull = 0, end_ull = 0,
incr_ull = 0}}, ordered_team_ids = 0x0, ordered_num_used = 0, ordered_owner =
0, ordered_cur = 0, next_alloc = 0x0, lock = {flag = 0}, threads_completed = 0,
{next = 0, next_ull = 0, copyprivate = 0x0}, {next_ws = 0x100213d0, next_free =
0x100213d0}, inline_ordered_team_ids = 0x100213a8},
[Bug gcov-profile/51297] [4.7 regression] Many gcov tests FAIL on Tru64, Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297 --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-24 23:31:06 UTC --- Hm, can you try the attached patch? It avoids passing a null pointer, which is not permitted. Passing zero as nmemb is permitted (7.20.5 para 1 of c99). So I'm a little puzzled as to why bsearch managed to call the comparison function at all. I'd like to understand if we're dealing with a weird, but legal, implementation, or one that's got a bug. The patch solves the problem for me.
[Bug target/50797] [x32] Use 32bit Pmode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50797 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-11-25 00:58:51 UTC --- It is implemented on hjl/x32/addr32 branch at http://gcc.gnu.org/git/?p=gcc.git;a=summary
[Bug c++/51227] [c++0x] ICE with invalid parameter in lambda expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51227 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-11-25 01:00:51 UTC --- Author: paolo Date: Fri Nov 25 01:00:44 2011 New Revision: 181707 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181707 Log: /cp 2011-11-24 Paolo Carlini paolo.carl...@oracle.com PR c++/51227 * pt.c (instantiate_class_template_1): If lambda_function (type) is NULL_TREE do not instantiate_decl. /testsuite 2011-11-24 Paolo Carlini paolo.carl...@oracle.com PR c++/51227 * g++.dg/cpp0x/lambda/lambda-ice5.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51227] [c++0x] ICE with invalid parameter in lambda expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51227 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.7.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-25 01:02:23 UTC --- Fixed for 4.7.0.
[Bug target/51134] [4.7 Regression] x86 memset/memcpy expansion is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51134 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #14 from H.J. Lu hjl.tools at gmail dot com 2011-11-25 01:04:37 UTC --- Fixed.
[Bug c++/51299] New: [C++11] erroneous nullptr warning on dynamic cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51299
Bug #: 51299
Summary: [C++11] erroneous nullptr warning on dynamic cast
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jarr...@cse.unsw.edu.au
The below code compiled with -Wzero-as-null-pointer-constant produces an
erroneous warning on a dynamic cast.
g++ -std=gnu++11 nullcast.cpp -c -Wzero-as-null-pointer-constant
nullcast.cpp: In function ‘void foo(Base*)’:
nullcast.cpp:13:40: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
nullcast.cpp:13:40: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
class Base
{
public:
virtual ~Base() = default;
};
class Derived : public Base
{
};
void foo(Base *b)
{
Derived *d = dynamic_castDerived*(b);
}
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/jarrydb/current/soft/install-latest/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/jarrydb/current/soft/src/gcc-git/configure
--prefix=/home/jarrydb/current/soft/install-latest --disable-multilib
--enable-languages=c,c++
Thread model: posix
gcc version 4.7.0 2025 (experimental) (GCC)
[Bug c++/51184] Abstract class in function return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51184 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-25 CC||paolo.carlini at oracle dot ||com AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-25 01:24:33 UTC --- On it.
[Bug c++/51299] [C++11] erroneous nullptr warning on dynamic cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51299 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-25 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-25 02:02:41 UTC --- On it.
[Bug c/51256] ICE with invalid parameter for __atomic builtin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51256 --- Comment #1 from Andrew Macleod amacleod at redhat dot com 2011-11-25 03:00:44 UTC --- Author: amacleod Date: Fri Nov 25 03:00:38 2011 New Revision: 181709 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181709 Log: 2011-11-24 Andrew MacLeod amacl...@redhat.com PR c/51256 * c-common.c (get_atomic_generic_size): Check for various error conditions (resolve_overloaded_atomic_exchange, resolve_overloaded_atomic_compare_exchange, resolve_overloaded_atomic_load, resolve_overloaded_atomic_store): Return error_mark_node for error conditions. * gcc.dg/atomic-pr51256.c: New. Test error conditions. Added: trunk/gcc/testsuite/gcc.dg/atomic-pr51256.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/testsuite/ChangeLog
[Bug lto/51300] New: Internal error when using -flto with -O0 in the linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51300 Bug #: 51300 Summary: Internal error when using -flto with -O0 in the linker Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: miku...@artax.karlin.mff.cuni.cz Host: hppa-linux-gnu Target: hppa-linux-gnu Build: hppa-linux-gnu I get an internal error in gcc. Steps to reproduce: Use gcc 4.6.2 on Linux Debian 5 on PA-RISC Get Links browser 2.4 from http://links.twibright.com/download/ Compile it with -flto so that individual modules are compiled with an optimization, but the whole program is compiled without optimization: CFLAGS=-O -flto LDFLAGS=-O0 ./configure make The result is a gcc internal error: gcc -O -flto -O0 -o links af_unix.o auth.o beos.o bfu.o block.o bookmarks.o cache.o charsets.o connect.o cookies.o default.o dip.o directfb.o dither.o dns.o drivers.o error.o file.o finger.o font_include.o framebuffer.o ftp.o gif.o html.o html_gr.o html_r.o html_tbl.o http.o https.o img.o imgcache.o jpeg.o jsint.o kbd.o language.o links_icon.o listedit.o lru.o mailto.o main.o memory.o menu.o objreq.o os_dep.o pmshell.o png.o sched.o select.o session.o smb.o svgalib.o terminal.o tiff.o types.o url.o view.o view_gr.o x.o xbm.o -lbz2 -lz -lssl -lcrypto session.o: In function `continue_download': (.text+0x4f30): warning: the use of `tempnam' is dangerous, better use `mkstemp'In file included from :76:0: session.c: In function 'get_file_by_term': session.c:1937:12: internal compiler error: in insert_value_copy_on_edge, at tree-outof-ssa.c:242 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: gcc returned 1 exit status collect2: lto-wrapper returned 1 exit status
