[Bug fortran/52347] New: -Wno-tabs -Wall -Wno-tabs still warns about tabs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52347 Bug #: 52347 Summary: -Wno-tabs -Wall -Wno-tabs still warns about tabs Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org With mosts flags, a flag which is implied by another flag can be overridden by the specific flag. For instance -f(no-)protect-parens overriddes the settings of -O0 (protected) or -Ofast (unprotected parentheses). However, for tab warnings -Wno-tabs cannot be used to turn off the warning, enabled by -Wall. I wouldn't be surprised if that also holds for other warnings, enabled by -Wall or -Wextra. Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/9942915c9c41b151
[Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52347 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez 2012-02-23 08:37:08 UTC --- (In reply to comment #0) > However, for tab warnings -Wno-tabs cannot be used to turn off the warning, > enabled by -Wall. > > I wouldn't be surprised if that also holds for other warnings, enabled by > -Wall > or -Wextra. > > Found at > http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/9942915c9c41b151 Sure, it happens with many flags in fact, not only in Fortran, since -Wall either does not check whether the flag was already initialized, or it sets the value too early. Ideally, flags that enable other flags should be checked last, and they should only touch flags that haven't been set already in the command-line. But this is only done on a case-by-case basis by using -1 as starting value (I did it mostly for -Wextra, -Wunused, and -Wimplicit). It would be nice that the options handling code would take care of this, by specifying the relations in *.opt files.
[Bug rtl-optimization/37516] ~(-2 - a) is not being optimized into a + 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37516 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-23 AssignedTo|unassigned at gcc dot |pinskia at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski 2012-02-23 08:42:01 UTC --- I have an idea on how to fix this. basically: ~(C - X) is the same as: ~ - (X - C) which then can be simplified to X - (C+1) This should be done on both the tree level (on the pinskia/treecombine branch in tree-ssa-fold.c) and the rtl level in simplify-rtx.c.
[Bug rtl-optimization/37516] ~(-2 - a) is not being optimized into a + 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37516
--- Comment #3 from rguenther at suse dot de
2012-02-23 08:47:55 UTC ---
On Thu, 23 Feb 2012, pinskia at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37516
>
> Andrew Pinski changed:
>
>What|Removed |Added
>
> Status|UNCONFIRMED |ASSIGNED
>Last reconfirmed||2012-02-23
> AssignedTo|unassigned at gcc dot |pinskia at gcc dot gnu.org
>|gnu.org |
> Ever Confirmed|0 |1
>
> --- Comment #2 from Andrew Pinski 2012-02-23
> 08:42:01 UTC ---
> I have an idea on how to fix this.
> basically:
> ~(C - X)
> is the same as:
> ~ - (X - C)
> which then can be simplified to
> X - (C+1)
>
> This should be done on both the tree level (on the pinskia/treecombine branch
> in tree-ssa-fold.c) and the rtl level in simplify-rtx.c.
Maybe get away with these old-stylish names ('tree' and 'fold') and
make it match reality, gimple-ssa-combine.c ;)
Still have to have a look at your branch - do you have a brief
overview documentation, for example on the wiki? What I'd like
to do is have an interface that I can re-use for VN combining,
basically replace its simplify_*_expression functions.
Richard.
[Bug libgomp/52348] New: [4.5/4.6] OpenMP incorrectly parallelizes loops (wrong iteration count)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52348 Bug #: 52348 Summary: [4.5/4.6] OpenMP incorrectly parallelizes loops (wrong iteration count) Classification: Unclassified Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassig...@gcc.gnu.org ReportedBy: ua_gcc_bugzi...@binary-island.eu Created attachment 26725 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26725 testcase with unsigned and signed integers (OpenMP >= 3.0 / < 3.0) The attached testcase shows actually two possible bugs: (1) Using the data type's maximum value range as the number of iterations, will result in less iterations if and only if more than 1 thread is used. Gradually increasing the number of threads and slowly decreasing the iteration count, will produce the right result. (2) Using a signed range for the loop counter (starting from the negative min to the positive max), will not work at all. No loop iteration is done. As long as the program is linked with openmp, this does not change. Recompiling without openmp support, produces the right result. This behavior has been reproduced with gcc 4.5.3, 4.6.2 and current 4.6 branch (aka the upcoming 4.6.3). Current gcc 4.7 trunk does work partially: it produces the right results for the unsigned range but still does not work for the signed range. The selected target (64bit / 32bit) or optimizations (Os up to O3) make no difference at all. The expected output would be: INT32_MAX: 65535 / 65535 UINT32_MAX: 65535 / 65535 The OpenMP < 3.0 part (signed integer range) works correctly with the path64 compiler and both parts also work correctly with the Intel C compiler. All tests were performed on a x86_64 (Core i7 860) Gentoo system with glibc 2.14.1(-r2) and binutils-2.22(-r1).
[Bug libgomp/52348] [4.5/4.6/4.7] OpenMP incorrectly parallelizes loops (wrong iteration count)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52348 --- Comment #1 from Matthias Dahl 2012-02-23 09:21:51 UTC --- Before this causes any confusion: The path64 compiler does currently only support OpenMP up to and including 2.5. That's why I stated only the OpenMP < 3.0 part works.
[Bug c++/52343] [C++11] alias-definition dont work in `template` params type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52343 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-23 Ever Confirmed|0 |1
[Bug go/52349] New: [4.7 Regression] go doesn't bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52349
Bug #: 52349
Summary: [4.7 Regression] go doesn't bootstrap
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: go
AssignedTo: i...@airs.com
ReportedBy: ja...@gcc.gnu.org
CC: i...@gcc.gnu.org
The http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184436 broke go bootstrap.
Simple testcase, even for -O0: ./go1 ice.go
package ice
type Ice interface { }
type M struct { f func(Ice) Ice }
func (m *M) foo(c Ice) Ice { return m.f(c) }
(distilled from color.go).
In create_tmp_from_val we have:
(gdb) p debug_tree (val->typed.type)
unit size
align 64 symtab 0 alias set -1 canonical type 0x713b2b28 fields
pointer_to_this >
QI
size
unit size
align 8 symtab 0 alias set -1 canonical type 0x713bebd0
arg-types
chain >>
pointer_to_this >
sizes-gimplified unsigned DI
size constant 64>
unit size constant 8>
align 64 symtab 0 alias set -1 canonical type 0x7138fc78>
$7 = void
(gdb) p debug_tree (val->typed.type->type_common.main_variant)
>
sizes-gimplified public unsigned DI
size constant 64>
unit size constant 8>
align 64 symtab 0 alias set -1 canonical type 0x7138fc78
pointer_to_this >
$8 = void
so it is obvious that it ICEs soon afterwards, the question is if this is a
latent FE bug that pointers to functions shouldn't have void * as its
TYPE_MAIN_VARIANT, but rather pointer to the same function type, just without
volatile/const/restrict on the POINTER_TYPE, or if the above change wasn't
correct. Richard, Ian?
[Bug libgomp/52348] OpenMP incorrectly parallelizes loops (wrong iteration count)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52348 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-23 Summary|[4.5/4.6/4.7] OpenMP|OpenMP incorrectly |incorrectly parallelizes|parallelizes loops (wrong |loops (wrong iteration |iteration count) |count) | Ever Confirmed|0 |1 Known to fail||4.3.6, 4.4.6, 4.5.3, 4.6.2, ||4.7.0 --- Comment #2 from Richard Guenther 2012-02-23 09:58:24 UTC --- With 4.3.x we warned testcase.c: In function 'main': testcase.c:26: warning: iteration variable 'x' is unsigned and up to 4.6.2 we produce INT32_MAX: 0 / 65535 UINT32_MAX: 32768 / 65535 but on trunk (4.7) we say INT32_MAX: 0 / 65535 UINT32_MAX: 65535 / 65535 Confirmed that ICC produces INT32_MAX: 65535 / 65535 UINT32_MAX: 65535 / 65535
[Bug go/52349] [4.7 Regression] go doesn't bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52349
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-02-23
Target Milestone|--- |4.7.0
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther 2012-02-23
10:07:44 UTC ---
(In reply to comment #0)
> The http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184436 broke go
> bootstrap.
> Simple testcase, even for -O0: ./go1 ice.go
> package ice
> type Ice interface { }
> type M struct { f func(Ice) Ice }
> func (m *M) foo(c Ice) Ice { return m.f(c) }
>
> (distilled from color.go).
> In create_tmp_from_val we have:
> (gdb) p debug_tree (val->typed.type)
> type type size
> unit size
> align 64 symtab 0 alias set -1 canonical type 0x713b2b28
> fields
>
> pointer_to_this >
> QI
> size
> unit size
> align 8 symtab 0 alias set -1 canonical type 0x713bebd0
> arg-types Ice>
> chain >>
> pointer_to_this >
> sizes-gimplified unsigned DI
> size bitsizetype> constant 64>
> unit size sizetype> constant 8>
> align 64 symtab 0 alias set -1 canonical type 0x7138fc78>
> $7 = void
> (gdb) p debug_tree (val->typed.type->type_common.main_variant)
> type align 8 symtab 0 alias set -1 canonical type 0x7138fbd0
> pointer_to_this >
> sizes-gimplified public unsigned DI
> size bitsizetype> constant 64>
> unit size sizetype> constant 8>
> align 64 symtab 0 alias set -1 canonical type 0x7138fc78
> pointer_to_this >
> $8 = void
>
> so it is obvious that it ICEs soon afterwards, the question is if this is a
> latent FE bug that pointers to functions shouldn't have void * as its
> TYPE_MAIN_VARIANT, but rather pointer to the same function type, just without
> volatile/const/restrict on the POINTER_TYPE, or if the above change wasn't
> correct. Richard, Ian?
Surely TYPE_MAIN_VARIANT has to be compatible with the type, void *
as TYPE_MAIN_VARIANT of anything not being a qualified void * is bogus.
Not sure how you got away with this - maybe it's only exposed for
function pointer types? A canonical main-variant is
build_qualified_type (type, 0).
[Bug c++/52350] New: Parse error calling a template method in a template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52350
Bug #: 52350
Summary: Parse error calling a template method in a template
class
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jos...@mirriad.com
The following code is self explanatory. Fails to compile as is, but succeeds if
you replace #if 1 with #if 0.
template
class Factory
{
public:
template
T constructT() { return T(); }
};
template
class FactoryClient
{
public:
T construct() {
#if 1
Factory factory; // fails
#else
Factory factory; // works
#endif
return factory.constructT();
}
};
int main()
{
}
[Bug libgomp/52348] OpenMP incorrectly parallelizes loops (wrong iteration count)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52348 --- Comment #3 from Matthias Dahl 2012-02-23 10:21:53 UTC --- The warning with gcc 4.3.x is correct because of the lack of support for OpenMP 3.0. Starting with 4.4, gcc supports OpenMP 3.0 which allows unsigned iteration variables.
[Bug c++/52350] Parse error calling a template method in a template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52350 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Jonathan Wakely 2012-02-23 10:28:48 UTC --- Not a bug, all conforming compilers will reject this code (e.g. try it at http://www.comeaucomputing.com/tryitout/ or http://llvm.org/demo to check) You need to say: return factory.template constructT(); because factory is a dependent name and the compiler doesn't know that factory.constructT is a template (it could be a data member being compared with less-than) See http://womble.decadent.org.uk/c++/template-faq.html#disambiguation
[Bug go/52349] [4.7 Regression] go doesn't bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52349
--- Comment #2 from Richard Guenther 2012-02-23
10:31:59 UTC ---
Type built in
// Create a placeholder for a pointer type.
Btype*
Gcc_backend::placeholder_pointer_type(const std::string& name,
Location location, bool)
{
tree ret = build_variant_type_copy(ptr_type_node);
if (!name.empty())
{
tree decl = build_decl(location.gcc_location(), TYPE_DECL,
get_identifier_from_string(name),
ret);
TYPE_NAME(ret) = decl;
}
return this->make_type(ret);
}
that's bogus. Consider using build_distinct_type_copy instead.
That fixes it for me.
[Bug libgomp/52348] [4.5/4.6/4.7] OpenMP incorrectly parallelizes loops (wrong iteration count)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52348 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Last reconfirmed|2012-02-23 00:00:00 | CC||jakub at gcc dot gnu.org Resolution||INVALID Summary|OpenMP incorrectly |[4.5/4.6/4.7] OpenMP |parallelizes loops (wrong |incorrectly parallelizes |iteration count)|loops (wrong iteration ||count) Known to fail|4.3.6, 4.4.6, 4.5.3, 4.6.2, | |4.7.0 | --- Comment #4 from Jakub Jelinek 2012-02-23 10:32:48 UTC --- The first case is not valid OpenMP code. See e.g. OpenMP 2.5, in section 2.5.1: "Note that the canonical form allows the number of loop iterations to be computed on entry to the loop. This computation is performed with values in the type of var, after integral promotions. In particular, if the value of b - lb + incr, or any intermediate result required to compute this value, cannot be represented in that type, the behavior is unspecified." The number of iterations here is (INT32_MAX - 1) - INT32_MIN + 1, but it and any of its temporaries are supposed to be computed in the int type. That is unspecified behavior, you just can't have more than INT32_MAX iterations in a valid OpenMP loop with int IV type.
[Bug libgomp/52348] [4.5/4.6/4.7] OpenMP incorrectly parallelizes loops (wrong iteration count)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52348 --- Comment #5 from Matthias Dahl 2012-02-23 10:38:51 UTC --- I am a bit short on time, so I cannot check on the OpenMP 2.5 related matter but closing this bug is a bit premature imho. There is still the issue with the OpenMP 3.0 part which has been confirmed by Richard Guenther in Comment 2 btw.
[Bug fortran/52351] New: Wrong bounds when passing an array section to an intent-in pointer dummy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52351 Bug #: 52351 Summary: Wrong bounds when passing an array section to an intent-in pointer dummy Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org The following program should print: 3 6 1 4 but it wrongly prints 3 6 3 6 The program uses the Fortran 2008 feature that one can pass a nonpointer to an intent(in) pointer argument. >From the standard: "12.5.2.7 Pointer dummy variables" "If the dummy argument does not have the INTENT (IN), the actual argument shall be a pointer. Otherwise, the actual argument shall be a pointer or a valid target for the dummy pointer in a pointer assignment statement. If the actual argument is not a pointer, the dummy pointer becomes pointer associated with the actual argument." "16.5.2 Pointer association" "If the pointer has deferred type parameters or shape, their values are assumed from the target." As lbound(a(:)) == 1 (always) and lbound(a) == 3 (in this example), the respective result should be obtained for lbound(x). integer, allocatable, target :: A(:) allocate(A(3:6)) call sub (a) call sub (a(:)) contains subroutine sub(x) integer, pointer, intent(in) :: x(:) print *, lbound(x), ubound(x) end subroutine sub end
[Bug fortran/52351] Wrong bounds when passing an array section to an intent-in pointer dummy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52351 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus 2012-02-23 10:49:22 UTC --- It works if one any other array section than "(:)" such as: call sub (a(4:)) ! gives: 1 3 or even call sub (a(3:)) ! gives: 1 4
[Bug libstdc++/43813] [DR1234] vector(3, NULL) fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org | --- Comment #11 from Paolo Carlini 2012-02-23 11:25:19 UTC --- At this point, it will be 4.8.0, I'm afraid.
[Bug target/52352] New: [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 Bug #: 52352 Summary: [x32] - Wrong code to access addresses 0x8000 to 0x using registers Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: steffen-schm...@siemens.com Created attachment 26727 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26727 C code resulting in wrong instructions when compiled with -mx32 and -O2 or higher The example C code defines a structure in memory at address 0xFEE0 Compilation of this example with -mx32 and -O2 or higher (seems to be related to -fgcse) results in faulty assembler instructions. For accessing several members of the structure loads the signed address of one member of the structure (-18874360 = 0xFEE8) into register %rax. This actually results in a 64bit negative address of 0xFEE8, which is incorrect when later using complete %rax register for memory access. // -mx32 -O3 movq$-18874360, %rax movl(%rax), %edx xorb%al, %al movl%edx, 4(%eax) When optimizing with -O1 register %eax is used instead of %rax which results in correct behaviour: // -mx32 -O1 movl$-18874368, %eax movl8(%eax), %edx movl%edx, 4(%eax) The x64 compiler produces correct code with -O1 and -O3 loading the address into %eax not %rax: // -m64 -O1 movl$4276092928, %eax movl8(%rax), %edx movl%edx, 4(%rax) // -m64 -O3 movl$4276092936, %eax movl(%rax), %edx xorb%al, %al movl%edx, 4(%rax)
[Bug tree-optimization/52019] [4.7 Regression] tree-ssa/ipa-split-5.c fails with -fno-tree-sra because of CLOBBERS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52019 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-23 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Jakub Jelinek 2012-02-23 11:36:43 UTC --- Created attachment 26726 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26726 gcc47-pr52019.patch Untested fix.
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #1 from Steffen Schmidt 2012-02-23 11:38:50 UTC --- Created attachment 26728 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26728 Generated -mx32 -O3 assembler
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #2 from Steffen Schmidt 2012-02-23 11:39:26 UTC --- Created attachment 26729 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26729 Generated -mx32 -O1 assembler
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #3 from Steffen Schmidt 2012-02-23 11:40:01 UTC --- Created attachment 26730 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26730 Generated -m64 -O3 assembler
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #4 from Steffen Schmidt 2012-02-23 11:40:41 UTC --- Created attachment 26731 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26731 Generated -m64 -O1 assembler
[Bug libstdc++/43813] [DR1234] vector(3, NULL) fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #12 from Paolo Carlini 2012-02-23 11:49:10 UTC --- Can do this.
[Bug libffi/52223] [4.5/4.6/4.7 Regression] libffi's man page install breaks with multilibs and overridden mandir
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52223 --- Comment #7 from Mikael Pettersson 2012-02-23 12:47:33 UTC --- Patch has been posted: http://gcc.gnu.org/ml/gcc-patches/2012-02/msg01173.html
[Bug middle-end/52353] New: -ftrapv -fnon-call-exceptions does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52353
Bug #: 52353
Summary: -ftrapv -fnon-call-exceptions does not work
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
The testcase from PR47086
void
foo ()
{
int n = 0;
while (1)
{
int i[n % 1];
n++;
}
}
reveals that while on the tree level n++ has an outgoing EH edge, RTL
expansion leaves us with
;; n_5 = n_1 + 1;
(insn 12 11 13 (set (reg:DI 67)
(sign_extend:DI (reg/v:SI 61 [ n ])))
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/pr47086.c:11 -1
(nil))
(insn 13 12 14 (set (reg:DI 4 si)
(const_int 1 [0x1]))
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/pr47086.c:11 -1
(nil))
(insn 14 13 15 (set (reg:DI 5 di)
(reg:DI 67))
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/pr47086.c:11 -1
(nil))
(call_insn/u 15 14 16 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:DI ("__addvdi3") [flags 0x41]) [0 S1 A8])
(const_int 0 [0])))
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/pr47086.c:11 -1
(expr_list:REG_EH_REGION (const_int -2147483648 [0x8000])
(nil))
(expr_list:REG_DEP_TRUE (use (reg:DI 4 si))
(expr_list:REG_DEP_TRUE (use (reg:DI 5 di))
(nil
(insn 16 15 17 (set (reg:DI 68)
(reg:DI 0 ax))
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/pr47086.c:11 -1
(expr_list:REG_EQUAL (plus:DI (reg:DI 67)
(const_int 1 [0x1]))
(nil)))
(insn 17 16 0 (set (reg/v:SI 63 [ n ])
(subreg:SI (reg:DI 68) 0))
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/pr47086.c:11 -1
(nil))
note that the call is marked CONST. The EH edge is simply thrown away:
;; Basic block 4 , prev 3, next 5, loop_depth 1, count 0, freq 1, maybe
hot, flags: new reachable rtl modified.
;; Predecessors: 3 [100.0%] (fallthru) 5 [100.0%] (dfs_back)
...
(call_insn/u 15 14 16 4 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:DI ("__addvdi3") [flags 0x41]) [0 S1 A8])
(const_int 0 [0])))
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/pr47086.c:11 -1
(expr_list:REG_EH_REGION (const_int -2147483648 [0x8000])
(nil))
(expr_list:REG_DEP_TRUE (use (reg:DI 4 si))
(expr_list:REG_DEP_TRUE (use (reg:DI 5 di))
(nil
(insn 16 15 17 4 (set (reg:DI 68)
(reg:DI 0 ax))
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/pr47086.c:11 -1
(expr_list:REG_EQUAL (plus:DI (reg:DI 67)
(const_int 1 [0x1]))
(nil)))
(insn 17 16 18 4 (set (reg/v:SI 63 [ n ])
(subreg:SI (reg:DI 68) 0))
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/pr47086.c:11 -1
(nil))
;; Successors: 5 [100.0%] (fallthru)
So we seem to leave around the libcall because of the EH side-effect
but do not consider that call as possibly throwing (as it is marked
nothrow on RTL) in find_many_sub_basic_blocks
(at least) and DCE it later, too (sounds similar to PR19020).
Currently generated assembly for gcc.dg/pr47086.c on x86_64 is
foo:
.LFB0:
.cfi_startproc
.cfi_personality 0x3,__gcc_personality_v0
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movl$0, %ebx
.L2:
addl$1, %ebx
jmp .L2
I'm running into this issue when removing unreachable blocks during
expansion, then the landing pad unwind info expansion ICEs because the landing
pad was removed.
We mark the call as not throwing via emit_libcall_block because we pass
it (plus (reg) 1) as EQUIV, which may not trap.
[Bug middle-end/52353] -ftrapv -fnon-call-exceptions does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52353
--- Comment #1 from Richard Guenther 2012-02-23
13:05:30 UTC ---
Created attachment 26732
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26732
patch
Patch that fixes my issue and works until rtl_dce, which still removes the
call,
even though it throws internally
(call_insn/u 15 13 36 3 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:DI ("__addvdi3") [flags 0x41]) [0 S1 A8])
(const_int 0 [0])))
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/pr47086.c:11 636
{*call_value}
(expr_list:REG_DEAD (reg:DI 5 di)
(expr_list:REG_DEAD (reg:DI 4 si)
(expr_list:REG_UNUSED (reg:DI 0 ax)
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil)
(expr_list:REG_DEP_TRUE (use (reg:DI 4 si))
(expr_list:REG_DEP_TRUE (use (reg:DI 5 di))
(nil
;; Successors: 5 (ab,abcall,eh,loop_exit) 4 [100.0%] (fallthru)
;; lr out 3 [bx] 6 [bp] 7 [sp] 16 [argp] 20 [frame] 41 [r12]
[Bug middle-end/52354] New: [4.7 regression] libgo fails to build (error: non-function in gimple call)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52354 Bug #: 52354 Summary: [4.7 regression] libgo fails to build (error: non-function in gimple call) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@gcc.gnu.org seen with r184500 from the trunk, building libgo: libtool: compile: /home/packages/gcc/4.7/gcc-4.7-4.7-20120223/build/./gcc/gccgo -B/home/packages/gcc/4.7/gcc-4.7-4.7-20120223/build/./gcc/ -B/usr/x86_64-linux-gnu/bin/ -B/usr/x86_64-linux-gnu/lib/ -isystem /usr/x86_64-linux-gnu/include -isystem /usr/x86_64-linux-gnu/sys-include -minline-all-stringops -O2 -g -I . -c -fgo-prefix=libgo_syscall ../../../src/libgo/go/syscall/env_unix.go ../../../src/libgo/go/syscall/syscall_errno.go ../../../src/libgo/go/syscall/libcall_support.go ../../../src/libgo/go/syscall/libcall_posix.go ../../../src/libgo/go/syscall/socket.go ../../../src/libgo/go/syscall/sockcmsg_unix.go ../../../src/libgo/go/syscall/str.go ../../../src/libgo/go/syscall/syscall.go ../../../src/libgo/go/syscall/sockcmsg_linux.go ../../../src/libgo/go/syscall/syscall_unix.go ../../../src/libgo/go/syscall/exec_unix.go ../../../src/libgo/go/syscall/exec_linux.go ../../../src/libgo/go/syscall/libcall_wait4.go ../../../src/libgo/go/syscall/sleep_select.go ../../../src/libgo/go/syscall/errstr_linux.go ../../../src/libgo/go/syscall/libcall_posix_largefile.go ../../../src/libgo/go/syscall/socket_linux.go epoll.go ../../../src/libgo/go/syscall/libcall_uname.go ../../../src/libgo/go/syscall/netlink_linux.go ../../../src/libgo/go/syscall/libcall_linux.go ../../../src/libgo/go/syscall/libcall_linux_amd64.go ../../../src/libgo/go/syscall/syscall_linux_amd64.go libcalls.go sysinfo.go syscall_arch.go -fPIC -o syscall/.libs/syscall.o ../../../src/libgo/go/syscall/syscall_unix.go: In function 'syscall.Mmap.pN29_libgo_syscall.syscall.mmapper': ../../../src/libgo/go/syscall/syscall_unix.go:102:1: error: non-function in gimple call D.5355 = D.5353 (0, D.5354, prot, flags, fd, offset); [return slot optimization] ../../../src/libgo/go/syscall/syscall_unix.go:102: confused by earlier errors, bailing out make[6]: *** [syscall/syscall.lo] Error 1
[Bug tree-optimization/23286] missed fully redundant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
--- Comment #40 from Bernhard Reutner-Fischer
2012-02-23 13:34:37 UTC ---
The ATTRIBUTE_UNUSED of do_hoist_insertion can be removed.
diff --git a/gcc/tree-ssa-pre.c b/gcc/tree-ssa-pre.c
index 0f777b4..bfc7a92 100644
--- a/gcc/tree-ssa-pre.c
+++ b/gcc/tree-ssa-pre.c
@@ -3865,7 +3865,7 @@ do_pre_partial_partial_insertion (basic_block block,
basic_block dom)
The caller has to make sure that BLOCK has at least two successors. */
static bool
-do_hoist_insertion (basic_block block ATTRIBUTE_UNUSED)
+do_hoist_insertion (basic_block block)
{
edge e;
edge_iterator ei;
@@ -3878,6 +3878,13 @@ do_hoist_insertion (basic_block block ATTRIBUTE_UNUSED)
/* At least two successors, or else... */
gcc_assert (EDGE_COUNT (block->succs) >= 2);
+ /* We cheat about AVAIL_OUT in the first block
+ so pretend we are done in the second iteration. */
+ if (block->prev_bb
+ && block->prev_bb->index == ENTRY_BLOCK
+ && pre_stats.hoist_insert)
+return false;
+
/* Check that all successors of BLOCK are dominated by block.
We could use dominated_by_p() for this, but actually there is a much
quicker check: any successor that is dominated by BLOCK can't have
@@ -3890,9 +3897,12 @@ do_hoist_insertion (basic_block block ATTRIBUTE_UNUSED)
availout_in_some = BITMAP_ALLOC (&grand_bitmap_obstack);
/* A hoistable value must be in ANTIC_IN(block)
- but not in AVAIL_OUT(BLOCK). */
+ but not in AVAIL_OUT(BLOCK).
+ To give more opportunity to hoisting,
+ cheat by disregarding AVAIL_OUT of the ENTRY_BLOCK. */
bitmap_set_copy (hoistable_set, ANTIC_IN (block));
- bitmap_set_subtract_values (hoistable_set, AVAIL_OUT (block));
+ if (block->prev_bb && block->prev_bb->index != ENTRY_BLOCK)
+bitmap_set_subtract_values (hoistable_set, AVAIL_OUT (block));
/* Short-cut for a common case: hoistable_set is empty. */
if (bitmap_empty_p (&hoistable_set->values))
so for a simplified PR5738
$ cat pr5738.c
struct foo
{
unsigned short *p;
};
#define foo_s s
void
func (struct foo *foo_s, unsigned int *coord, _Bool delta)
{
unsigned short change;
if (delta)
{
change = *((foo_s)->p++);
*coord += change;
}
else
{
change = *((foo_s)->p++);
*coord += change;
// *coord += *((foo_s)->p++) << 8;
}
}
we end up a little bit better, with something like
func (struct foo * sD.1705, unsigned intD.9 * coordD.1706, _BoolD.1685
deltaD.1707)
{
unsigned intD.9 pretmp.6D.1727;
short unsigned intD.16 * pretmp.5D.1726;
short unsigned intD.16 pretmp.4D.1725;
short unsigned intD.16 * pretmp.3D.1724;
short unsigned intD.16 changeD.1710;
unsigned intD.9 D.1718;
unsigned intD.9 D.1717;
unsigned intD.9 D.1716;
short unsigned intD.16 * D.1715;
short unsigned intD.16 * D.1714;
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru,exec)
# VUSE <.MEMD.1720_17(D)>
# PT = nonlocal escaped
pretmp.3D.1724_22 = sD.1705_2(D)->pD.1704;
# VUSE <.MEMD.1720_17(D)>
pretmp.4D.1725_23 = *pretmp.3D.1724_22;
# PT = nonlocal escaped
pretmp.5D.1726_24 = pretmp.3D.1724_22 + 2;
# VUSE <.MEMD.1720_17(D)>
pretmp.6D.1727_25 = *coordD.1706_6(D);
pretmp.6D.1727_26 = (unsigned intD.9) pretmp.4D.1725_23;
pretmp.6D.1727_27 = pretmp.6D.1727_25 + pretmp.6D.1727_26;
if (deltaD.1707_1(D) != 0)
goto ;
else
goto ;
# SUCC: 3 [39.0%] (true,exec) 4 [61.0%] (false,exec)
# BLOCK 3 freq:3900
# PRED: 2 [39.0%] (true,exec)
# .MEMD.1720_18 = VDEF <.MEMD.1720_17(D)>
sD.1705_2(D)->pD.1704 = pretmp.5D.1726_24;
# .MEMD.1720_19 = VDEF <.MEMD.1720_18>
*coordD.1706_6(D) = pretmp.6D.1727_27;
goto ;
# SUCC: 5 [100.0%] (fallthru,exec)
# BLOCK 4 freq:6100
# PRED: 2 [61.0%] (false,exec)
# .MEMD.1720_20 = VDEF <.MEMD.1720_17(D)>
sD.1705_2(D)->pD.1704 = pretmp.5D.1726_24;
# .MEMD.1720_21 = VDEF <.MEMD.1720_20>
*coordD.1706_6(D) = pretmp.6D.1727_27;
# SUCC: 5 [100.0%] (fallthru,exec)
# BLOCK 5 freq:1
# PRED: 3 [100.0%] (fallthru,exec) 4 [100.0%] (fallthru,exec)
# .MEMD.1720_16 = PHI <.MEMD.1720_19(3), .MEMD.1720_21(4)>
# VUSE <.MEMD.1720_16>
return;
# SUCC: EXIT [100.0%]
}
which translates to nearly proper code:
func:
.LFB0:
.cfi_startproc
movq(%rdi), %rax# sD.1705_2(D)->pD.1704, pretmp.3D.1724
leaq2(%rax), %rcx #, pretmp.5D.1726
movzwl (%rax), %eax# *pretmp.3D.1724_22, pretmp.6D.1727
addl(%rsi), %eax# *coordD.1706_6(D), pretmp.6D.1727
testb %dl, %dl# deltaD.1707
movq%rcx, (%rdi)# pretmp.5D.1726, sD.1705_2(D)->pD.1704
movl%eax, (%rsi)# pretmp.6D.1727, *coordD.1706_6(D)
je .L2 #,
ret
.L2:
ret
.cfi_endproc
where the expected code would be something like (i think):
func:
.LFB0:
.cfi_startproc
movq(%rdi), %rax# sD.1705_2(D)->pD.1704, D.1714
mov
[Bug c/52355] New: [4.7 regression] address difference between array elements is not considered to be a compile time constant anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52355
Bug #: 52355
Summary: [4.7 regression] address difference between array
elements is not considered to be a compile time
constant anymore
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: siarhei.siamas...@gmail.com
Created attachment 26733
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26733
test.c
gcc version 4.7.0 20120223 (experimental) (GCC)
$ cat test.c
void f(char a[16][16][16])
{
asm volatile ("" : : "i" (&a[1][0][0] - &a[0][0][0]));
}
int main(void)
{
char a[16][16][16];
f(a);
return 0;
}
$ gcc -O2 test.c
test.c: In function ‘f’:
test.c:3:5: warning: asm operand 0 probably doesn’t match constraints [enabled
by default]
test.c:3:5: error: impossible constraint in ‘asm’
[Bug middle-end/52354] [4.7 regression] libgo fails to build (error: non-function in gimple call)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52354 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #1 from Jakub Jelinek 2012-02-23 14:02:46 UTC --- Dup...
[Bug c/52355] [4.7 regression] address difference between array elements is not considered to be a compile time constant anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52355 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-23 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek 2012-02-23 14:11:08 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172958 Richard?
[Bug c/49748] char * const * cannot be assigned to char const * const *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49748
Tim Ruehsen changed:
What|Removed |Added
CC||tim.ruehsen at gmx dot de
--- Comment #3 from Tim Ruehsen 2012-02-23 14:12:00
UTC ---
Just to clarify it and to add a complete program.
x.c
void f(const char *const *args) {}
int main(int argc, char **argv) {
f(argv);
return 0;
}
Compiling with g++ (4.6.2) will do without warning.
Compiling with gcc (4.6.2) gives:
x.c: In function 'main':
x.c:4:2: warning: passing argument 1 of 'f' from incompatible pointer type
[enabled by default]
x.c:1:6: note: expected 'const char * const*' but argument is of type 'char **'
This is somewhat annoying when trying to harden older C sources with
-Wwrite-strings.
One has to insert (very) many casts to avoid the above warning.
This is much work that could be avoided by an apropriate -W option.
[Bug middle-end/52354] [4.7 regression] libgo fails to build (error: non-function in gimple call)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52354 Jakub Jelinek changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #2 from Jakub Jelinek 2012-02-23 14:13:00 UTC --- I meant dup of PR52349. *** This bug has been marked as a duplicate of bug 52349 ***
[Bug go/52349] [4.7 Regression] go doesn't bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52349 Jakub Jelinek changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #3 from Jakub Jelinek 2012-02-23 14:13:00 UTC --- *** Bug 52354 has been marked as a duplicate of this bug. ***
[Bug go/52349] [4.7 Regression] go doesn't bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52349 --- Comment #4 from Jakub Jelinek 2012-02-23 14:13:40 UTC --- The #c2 patch bootstrapped/regtested just fine on both x86_64-linux and i686-linux.
[Bug go/52349] [4.7 Regression] go doesn't bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52349 --- Comment #5 from Ian Lance Taylor 2012-02-23 14:16:41 UTC --- Richi's patch is approved (I'm testing it myself, but go ahead and commit if it looks fine to you). Thanks.
[Bug bootstrap/52287] [4.7 regression] ICE in ready_remove_first, at haifa-sched.c:1927
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287 Eric Botcazou changed: What|Removed |Added Attachment #26684|0 |1 is obsolete|| Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #7 from Eric Botcazou 2012-02-23 14:28:10 UTC --- Created attachment 26734 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26734 Reduced testcase Still reproducible on native only.
[Bug tree-optimization/52019] [4.7 Regression] tree-ssa/ipa-split-5.c fails with -fno-tree-sra because of CLOBBERS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52019 --- Comment #4 from Jakub Jelinek 2012-02-23 14:43:48 UTC --- Author: jakub Date: Thu Feb 23 14:43:43 2012 New Revision: 184508 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184508 Log: PR tree-optimization/52019 * ipa-split.c (find_return_bb, find_retval, visit_bb): Ignore CLOBBER stmts. * gcc.dg/tree-ssa/ipa-split-6.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ipa-split-6.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-split.c trunk/gcc/testsuite/ChangeLog
[Bug go/52349] [4.7 Regression] go doesn't bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52349 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Richard Guenther 2012-02-23 15:06:10 UTC --- Fixed.
[Bug c/52283] "error: case label does not reduce to an integer constant" for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 --- Comment #22 from chrbr at gcc dot gnu.org 2012-02-23 15:06:12 UTC --- thanks, no regression with your patch on the 4.6 and trunk branches. OK to commit on both ?
[Bug middle-end/52355] [4.7 regression] address difference between array elements is not considered to be a compile time constant anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52355 Richard Guenther changed: What|Removed |Added Status|NEW |ASSIGNED Component|c |middle-end AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 --- Comment #2 from Richard Guenther 2012-02-23 15:07:46 UTC --- I think we have a dup for this somewhere. But fixed. Mine.
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #12 from Jack Howarth 2012-02-23 15:07:17 UTC --- (In reply to comment #11) > Ah, the better way to do that would be to have: > > AC_CHECK_FUNCS([pthread_get_stackaddr_np]) > > in configure.ac, and then just have > > #ifdef HAVE_PTHREAD_GET_STACKADDR_NP > #define STACKBOTTOM (ptr_t)pthread_get_stackaddr_np(pthread_self()) > #endif > > This should cover all the issues with NO_PTHREAD... Where do you want the second change made? Should I place that in include/gc_config.h.in (which only contains #undefs right now) or in include/gc_config_macros.h or in os_dep.c? I notice that HAVE_PTHREAD_GETATTR_NP is only used in pthread_support.c. The rest of the patch looks like... Index: configure.ac === --- configure.ac(revision 184508) +++ configure.ac(working copy) @@ -380,6 +380,7 @@ esac oldLIBS="$LIBS" LIBS="$LIBS $THREADLIBS" AC_CHECK_FUNCS([pthread_getattr_np]) +AC_CHECK_FUNCS([pthread_get_stackaddr_np]) LIBS="$oldLIBS" # Configuration of machine-dependent code Index: include/gc_config.h.in === --- include/gc_config.h.in(revision 184508) +++ include/gc_config.h.in(working copy) @@ -87,6 +87,9 @@ /* Define to 1 if you have the `pthread_getattr_np' function. */ #undef HAVE_PTHREAD_GETATTR_NP +/* Define to 1 if you have the `pthread_get_stackaddr_np_np' function. */ +#undef HAVE_PTHREAD_GET_STACKADDR_NP + /* Define to 1 if you have the header file. */ #undef HAVE_STDINT_H Index: configure === --- configure(revision 184508) +++ configure(working copy) @@ -15141,6 +15141,17 @@ _ACEOF fi done +for ac_func in pthread_get_stackaddr_np +do : + ac_fn_c_check_func "$LINENO" "pthread_get_stackaddr_np" "ac_cv_func_pthread_get_stackaddr_np" +if test "x$ac_cv_func_pthread_get_stackaddr_np" = x""yes; then : + cat >>confdefs.h <<_ACEOF +#define HAVE_PTHREAD_GET_STACKADDR_NP 1 +_ACEOF + +fi +done + LIBS="$oldLIBS" # Configuration of machine-dependent code
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-23 Ever Confirmed|0 |1 --- Comment #13 from Iain Sandoe 2012-02-23 15:16:57 UTC --- (In reply to comment #9) > (In reply to comment #8) > but often the -m64 results show the failure... > > WARNING: program timed out. > FAIL: boehm-gc.c/thread_leak_test.c -O2 execution test > Running > /sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120222/boehm-gc/testsuite/boehm-gc.lib/lib.exp This (random) fail is also seen on x86-d9/d10 - so not something related to the pie shifts. I've not had time to investigate - but suspect it is related to operating close to stack limits -- if you try reducing the number of recursions (like PPC does) does this go away?
[Bug middle-end/52355] [4.7 regression] address difference between array elements is not considered to be a compile time constant anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52355 --- Comment #3 from Jakub Jelinek 2012-02-23 15:18:07 UTC --- I think PR51730 is similar, but there it wasn't about inline asm. Perhaps we want to fold harder for "i" or something.
[Bug tree-optimization/52019] [4.7 Regression] tree-ssa/ipa-split-5.c fails with -fno-tree-sra because of CLOBBERS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52019 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek 2012-02-23 15:19:58 UTC --- Fixed.
[Bug bootstrap/52287] [4.7 regression] ICE in ready_remove_first, at haifa-sched.c:1927
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287
--- Comment #8 from Eric Botcazou 2012-02-23
15:23:44 UTC ---
This reproduces only on Solaris 8 because the sort of the ready list isn't
stable in the presence of debug insns, given that rank_for_schedule isn't
anti-symmetrical:
if (MAY_HAVE_DEBUG_INSNS)
{
/* Schedule debug insns as early as possible. */
if (DEBUG_INSN_P (tmp) && !DEBUG_INSN_P (tmp2))
return -1;
else if (DEBUG_INSN_P (tmp2))
return 1;
}
The following patchlet is enough to get rid of the ICE:
Index: haifa-sched.c
===
--- haifa-sched.c (revision 184352)
+++ haifa-sched.c (working copy)
@@ -1647,7 +1647,7 @@ rank_for_schedule (const void *x, const
/* Schedule debug insns as early as possible. */
if (DEBUG_INSN_P (tmp) && !DEBUG_INSN_P (tmp2))
return -1;
- else if (DEBUG_INSN_P (tmp2))
+ else if (DEBUG_INSN_P (tmp2) && !DEBUG_INSN_P (tmp))
return 1;
}
as it makes the sort stable and equivalent to the non-Solaris 8 case.
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #14 from Patrick Marlier 2012-02-23 15:32:31 UTC --- (In reply to comment #9) > (In reply to comment #8) > > This change bootstraps fine with current gcc trunk on x86_64-apple-darwin11. > It > almost fixes the failures in the boehm-gc test suite. The -m32 results always > pass as... > > === boehm-gc Summary for unix/-m32 === > > # of expected passes12 > # of unsupported tests1 > > but often the -m64 results show the failure... > > WARNING: program timed out. > FAIL: boehm-gc.c/thread_leak_test.c -O2 execution test > Running > /sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120222/boehm-gc/testsuite/boehm-gc.lib/lib.exp > ... > > === boehm-gc Summary for unix/-m64 === > > # of expected passes11 > # of unexpected failures1 > # of unsupported tests1 > > Are there any other darwin related changes upstream? I also notice this failure on x86_64 linux. In my case, it is due to the redefinition of GC_LINUX_THREADS. ./boehm-gc/include/gc_config.h:44:0: warning: "GC_LINUX_THREADS" redefined [enabled by default]^M ./boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:1:0: note: this is the location of the previous definition What does the log tell you?
[Bug bootstrap/52287] [4.7 regression] ICE in ready_remove_first, at haifa-sched.c:1927
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287 --- Comment #9 from Bernd Schmidt 2012-02-23 15:41:49 UTC --- (In reply to comment #8) > This reproduces only on Solaris 8 because the sort of the ready list isn't > stable in the presence of debug insns, given that rank_for_schedule isn't > anti-symmetrical: Thanks for investigating this. > Index: haifa-sched.c > === > --- haifa-sched.c (revision 184352) > +++ haifa-sched.c (working copy) > @@ -1647,7 +1647,7 @@ rank_for_schedule (const void *x, const >/* Schedule debug insns as early as possible. */ >if (DEBUG_INSN_P (tmp) && !DEBUG_INSN_P (tmp2)) > return -1; > - else if (DEBUG_INSN_P (tmp2)) > + else if (DEBUG_INSN_P (tmp2) && !DEBUG_INSN_P (tmp)) > return 1; > } > > as it makes the sort stable and equivalent to the non-Solaris 8 case. Almost OK, but in the case of two debug insns, can you make it return the difference of the INSN_UIDs here? I'd rather not fall through into the other code for DEBUG_INSNs. Such a patch is preapproved.
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #16 from Patrick Marlier 2012-02-23 15:49:26 UTC --- Created attachment 26735 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26735 proposal fix I have also started a patch (not tested at all) but I am more extreme in the approach and confines the change to boehm-gc and darwin x86/x86_64 (Lion doesn't support PPC, right?). Does the change to x86 is required? I am not sure... This is a workaround for 4.7 but I think boehm-gc should be updated for 4.8? Jack/Iain/Mike, I think it is wise to let you fix it since I have no access to a darwin11. PR boehm-gc/52179 * include/private/gcconfig.h (DARWIN): Define STACKBOTTOM with pthread_get_stackaddr_np when available. * configure.ac (THREADS): Check availability of pthread_get_stackaddr_np on *-*-darwin*. * configure: Regenerate.
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #15 from Jack Howarth 2012-02-23 15:49:06 UTC --- I notice in boehm-gc/include/private/gcconfig.h we are already setting... # ifdef DARWIN # define OS_TYPE "DARWIN" # define DYNAMIC_LOADING # if defined(__ppc64__) # define ALIGNMENT 8 # define CPP_WORDSZ 64 # define STACKBOTTOM ((ptr_t) 0x7fff5fc0) # define CACHE_LINE_SIZE 64 # ifndef HBLKSIZE # define HBLKSIZE 4096 # endif # else # define ALIGNMENT 4 # define STACKBOTTOM ((ptr_t) 0xc000) # endif so I guess we just want to append #ifdef HAVE_PTHREAD_GET_STACKADDR_NP #define STACKBOTTOM (ptr_t)pthread_get_stackaddr_np(pthread_self()) #endif at the end of those lines
[Bug bootstrap/52287] [4.7 regression] ICE in ready_remove_first, at haifa-sched.c:1927
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287
--- Comment #10 from Jakub Jelinek 2012-02-23
15:52:23 UTC ---
I don't think INSN_UID is right for that, I think you want to preserve the
original order of debug insns in that case, and INSN_UID can jump up and down.
So what about
if (MAY_HAVE_DEBUG_INSNS)
{
/* Schedule debug insns as early as possible. */
if (DEBUG_INSN (tmp))
{
if (DEBUG_INSN (tmp2))
return INSN_LUID (tmp) - INSN_LUID (tmp2);
return -1;
}
else if (DEBUG_INSN (tmp2))
return 1;
}
?
[Bug middle-end/52355] [4.7 regression] address difference between array elements is not considered to be a compile time constant anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52355 --- Comment #4 from Siarhei Siamashka 2012-02-23 15:56:24 UTC --- Now I wonder if multidimensional array is still treated as the same array in "When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object; the result is the difference of the subscripts of the two array elements." https://groups.google.com/group/comp.lang.c/browse_thread/thread/3a16b9b33cb0cdd0/c16065f5189a0348
[Bug bootstrap/52287] [4.7 regression] ICE in ready_remove_first, at haifa-sched.c:1927
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287 --- Comment #11 from Eric Botcazou 2012-02-23 16:00:58 UTC --- Created attachment 26736 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26736 Tentative fix
[Bug c/52290] [4.4/4.5/4.6/4.7 Regression] internal compiler error: tree check: expected function_decl, have var_decl in start_function, at c-decl.c:7712
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52290 --- Comment #3 from uros at gcc dot gnu.org 2012-02-23 16:34:15 UTC --- Author: uros Date: Thu Feb 23 16:34:02 2012 New Revision: 184511 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184511 Log: PR c/52290 * c-decl.c (start_function): Exit early if decl1 is not FUNTION_DECL. testsuite/ChangeLog: PR c/52290 * gcc.dg/noncompile/pr52290.c: New test. Added: trunk/gcc/testsuite/gcc.dg/noncompile/pr52290.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/52356] New: expr.c:emit_move_multi_word() can overwrite address register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52356 Bug #: 52356 Summary: expr.c:emit_move_multi_word() can overwrite address register Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@beniston.com expr.c:emit_move_multi_word() can copy multiple words from an address specified by y to a sequence of registers starting at x However, it seems this code doesn't check to make sure that the register used for holding the address y, isn't in the destination registers, or if it is, reorder the sequence of moves, so that the write to this register is the last move performed.
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 Uros Bizjak changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #5 from Uros Bizjak 2012-02-23 16:43:16 UTC --- This works OK with gcc-4.7: // -mx32 -O3 movabsl 4276092936, %eax movabsl %eax, 4276092932 ret H.J. probably needs to backport a patch or two from mainline.
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #6 from Uros Bizjak 2012-02-23 16:47:00 UTC --- (In reply to comment #5) > H.J. probably needs to backport a patch or two from mainline. BTW: Please report problems with non-FSF branches directly to their respective authors. There is no -mx32 switch in official 4.6.x, so please try to trigger the x32 specific bug with gcc-4.7.x before reporting it in bugzilla.
[Bug c/51905] ICE at sysklogd compilation for powerpc-linux-gnuspe with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51905
Matt Ranostay changed:
What|Removed |Added
CC||mranostay at gmail dot com
--- Comment #1 from Matt Ranostay 2012-02-23
16:58:20 UTC ---
I can confirm this happens as well:
powerpc-poky-linux-gnuspe-gcc -m32 -mcpu=8548 -mabi=spe -mspe
--sysroot=/home1/mranostay/Work/poky/build/tmp/sysroots/mpc8544nvs_prototype
-O3 -DSYSV -fomit-frame-pointer -Wall -fno-strength-reduce -DSYSLOG_INET
-DSYSLOG_UNIXAF -DNO_SCCS -DFSSTND -DSYSLOGD_PIDNAME=\"syslogd.pid\" -c
syslogd.c
syslogd.c: In function 'main':
syslogd.c:1237:1: error: unrecognizable insn:
(insn 66 65 67 4 (set (subreg:SI (reg:V2SI 502) 0)
(lo_sum:SI (reg:SI 503)
(symbol_ref/f:SI ("*.LC98") [flags 0x82] ))) syslogd.c:885 -1
(nil))
syslogd.c:1237:1: internal compiler error: in extract_insn, at recog.c:2109
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make: *** [syslogd.o] Error 1
ERROR: oe_runmake failed
ERROR: Function 'do_compile' failed (see
/home1/mranostay/Work/poky/build/tmp/work/ppce500v2-poky-linux-gnuspe/sysklogd-1.5-r4/temp/log.do_compile.21411
for further information)
[Bug go/52357] New: 64bit-out.go and go.test/test/cmplxdivide.go time out on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52357 Bug #: 52357 Summary: 64bit-out.go and go.test/test/cmplxdivide.go time out on Solaris/SPARC Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: r...@gcc.gnu.org Host: sparc-sun-solaris2* Target: sparc-sun-solaris2* Build: sparc-sun-solaris2* The 64bit-out.go and go.test/test/cmplxdivide.go often time out on Solaris/SPARC: On unloaded machines, I find for cmplxdivide.go: Solaris 11, Sun Fire V890, 1.35 GHz UltraSPARC-IV: real1:07.33 user1:02.18 sys0.64 Solaris 8, Sun Enterprise T5220, 1.2 GHz UltraSPARC-T2: real 2:09.40 user 2:07.73 sys 0.63 The latter is too close to the default 5 min timeout. It's similar for 64bit-out.go: real1:13.68 user1:07.82 sys0.79 vs. real 2:17.81 user 2:16.11 sys 1.14 Rainer
[Bug go/52358] New: math FAILs on Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52358 Bug #: 52358 Summary: math FAILs on Solaris 8 and 9 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: r...@gcc.gnu.org Host: *-*-solaris2.[89] Target: *-*-solaris2.[89] Build: *-*-solaris2.[89] Thelibgo math test FAILs on Solaris 8 and 9, both SPARC and x86. The failure mode is different, though: * On SPARC, I get --- FAIL: math_test.TestLdexp (0.00 seconds) ???:1: Ldexp(-1, -1075) = 0, want -0 FAIL FAIL: math * On x86, I get this instead: Undefined first referenced symbol in file cosl_gotest_.o expl_gotest_.o logl_gotest_.o sinl_gotest_.o tanl_gotest_.o acosl _gotest_.o asinl _gotest_.o atanl _gotest_.o atan2l _gotest_.o expm1l _gotest_.o ldexpl _gotest_.o log10l _gotest_.o log1pl _gotest_.o ld: fatal: Symbol referencing errors. No output written to a.out collect2: error: ld returned 1 exit status FAIL: math Rainer
[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52146 --- Comment #18 from Andrew Pinski 2012-02-23 17:27:29 UTC --- *** Bug 52352 has been marked as a duplicate of this bug. ***
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #7 from Andrew Pinski 2012-02-23 17:27:29 UTC --- Since 4.6.x did not have -mx32 I am just going to close this as a dup of the one which was reported against 4.7. The branch you are using is not an officially supported branch and you should report bugs to HJL directly. *** This bug has been marked as a duplicate of bug 52146 ***
[Bug go/52359] New: time test is too load-sensitive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52359 Bug #: 52359 Summary: time test is too load-sensitive Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: r...@gcc.gnu.org Host: i386-pc-solaris2.10 Target: i386-pc-solaris2.10 Build: i386-pc-solaris2.10 It seems that the libgo time test is too load-sensitive: I've seen it fail several times like this: --- FAIL: time_test.TestTicker (1.43 seconds) ???:1: 10 100ms ticks took 1.432394s, expected [800ms,1.2s] FAIL FAIL: time --- FAIL: time_test.TestTicker (1.30 seconds) ???:1: 10 100ms ticks took 1.301332s, expected [800ms,1.2s] FAIL FAIL: time This happens more often on a Sun Fire X4450 (4 x 2.93 GHz Xeon X7350), where make check is run with -j<2 * ncore>. Rainer
[Bug c/52290] [4.4/4.5/4.6/4.7 Regression] internal compiler error: tree check: expected function_decl, have var_decl in start_function, at c-decl.c:7712
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52290 --- Comment #4 from uros at gcc dot gnu.org 2012-02-23 17:38:20 UTC --- Author: uros Date: Thu Feb 23 17:38:13 2012 New Revision: 184514 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184514 Log: PR c/52290 * c-decl.c (start_function): Exit early if decl1 is not FUNTION_DECL. testsuite/ChangeLog: PR c/52290 * gcc.dg/noncompile/pr52290.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/noncompile/pr52290.c - copied unchanged from r184511, trunk/gcc/testsuite/gcc.dg/noncompile/pr52290.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/c-decl.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug go/52360] New: time and net/http FAIL on Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52360 Bug #: 52360 Summary: time and net/http FAIL on Solaris 8 and 9 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: r...@gcc.gnu.org Host: *-*-solaris2.[89] Target: *-*-solaris2.[89] Build: *-*-solaris2.[89] The time and net/http libgo tests FAIL on Solaris 8 and 9 in every configuration (i.e. emutls as well as native TLS): > LD_LIBRARY_PATH=../.libs:../../libgcc ./a.out throw: free runtime_mlookup Rainer
[Bug testsuite/52297] [4.7 Regression] FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o link, -flto -fgnu-tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52297 --- Comment #8 from Eric Botcazou 2012-02-23 17:54:26 UTC --- > This looks like a regression brought about by: > > +2012-02-13 Eric Botcazou > + > + * gcc.c (LINK_COMMAND_SPEC): Deal with -fgnu-tm. > + (GTM_SELF_SPECS): Define if not already defined. > + (driver_self_specs): Add GTM_SELF_SPECS. > +* config/darwin.h (LINK_COMMAND_SPEC_A): Deal with -fgnu-tm. > +(GTM_SELF_SPECS): Define. > + * config/i386/cygwin.h (GTM_SELF_SPECS): Likewise. > + * config/i386/mingw32.h (GTM_SELF_SPECS): Likewise. Well, the existing linking scheme was totally broken, which allowed you to devise the gcc.dg/lto/trans-mem.h hack. Now that it has been fixed, the hack doesn't work anymore, which isn't very surprising... We need a proper fix instead.
[Bug c/52361] New: gcc.dg/pr48141.c times out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 Bug #: 52361 Summary: gcc.dg/pr48141.c times out Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org Host: sparc-sun-solaris2.[89] Target: sparc-sun-solaris2.[89] Build: sparc-sun-solaris2.[89] I often see the gcc.dg/pr48141.c test time out on an 1.2 GHz UltraSPARC-T2: on a completely unloaded machine, I find: real 1:36.81 user 1:34.87 sys 0.48 It's not much better on an 1.35 GHz UltraSPARC-IV: real 55.51 user 52.20 sys0.30 while on a 2.6 GHz Opteron 8128, I get real 17.39 user 13.45 sys0.35 instead. With -ftime-report, I find: Execution times (seconds) phase setup : 0.03 ( 0%) usr 0.01 ( 0%) sys 0.03 ( 0%) wall 532 kB ( 1%) ggc phase parsing : 6.38 ( 6%) usr 1.92 (68%) sys 8.31 ( 8%) wall 5212 kB ( 7%) ggc phase cgraph: 94.53 (94%) usr 0.89 (32%) sys 95.42 (92%) wall 73673 kB (93%) ggc phase generate : 94.53 (94%) usr 0.89 (32%) sys 95.42 (92%) wall 73673 kB (93%) ggc garbage collection : 2.10 ( 2%) usr 0.13 ( 5%) sys 2.22 ( 2%) wall 0 kB ( 0%) ggc callgraph construction : 0.22 ( 0%) usr 0.00 ( 0%) sys 0.23 ( 0%) wall 0 kB ( 0%) ggc callgraph optimization : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc ipa pure const : 0.25 ( 0%) usr 0.00 ( 0%) sys 0.25 ( 0%) wall 0 kB ( 0%) ggc cfg construction: 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc cfg cleanup : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc CFG verifier: 2.23 ( 2%) usr 0.00 ( 0%) sys 2.21 ( 2%) wall 0 kB ( 0%) ggc trivially dead code : 0.85 ( 1%) usr 0.00 ( 0%) sys 0.86 ( 1%) wall 0 kB ( 0%) ggc df scan insns : 0.29 ( 0%) usr 0.00 ( 0%) sys 0.30 ( 0%) wall 0 kB ( 0%) ggc df multiple defs: 0.06 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall 0 kB ( 0%) ggc df live regs: 0.78 ( 1%) usr 0.00 ( 0%) sys 0.78 ( 1%) wall 0 kB ( 0%) ggc df live&initialized regs: 0.14 ( 0%) usr 0.00 ( 0%) sys 0.12 ( 0%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 0.53 ( 1%) usr 0.00 ( 0%) sys 0.57 ( 1%) wall 0 kB ( 0%) ggc register information: 0.07 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 0 kB ( 0%) ggc alias analysis : 0.64 ( 1%) usr 0.00 ( 0%) sys 0.62 ( 1%) wall 1 kB ( 0%) ggc alias stmt walking : 2.29 ( 2%) usr 0.21 ( 7%) sys 2.57 ( 2%) wall 10312 kB (13%) ggc register scan : 0.09 ( 0%) usr 0.00 ( 0%) sys 0.09 ( 0%) wall 0 kB ( 0%) ggc rebuild jump labels : 0.21 ( 0%) usr 0.00 ( 0%) sys 0.20 ( 0%) wall 0 kB ( 0%) ggc preprocessing : 1.67 ( 2%) usr 0.49 (17%) sys 2.11 ( 2%) wall 1 kB ( 0%) ggc lexical analysis: 2.05 ( 2%) usr 0.90 (32%) sys 3.11 ( 3%) wall 0 kB ( 0%) ggc parser function body: 2.52 ( 2%) usr 0.53 (19%) sys 2.94 ( 3%) wall 5157 kB ( 6%) ggc inline heuristics : 0.80 ( 1%) usr 0.00 ( 0%) sys 0.80 ( 1%) wall 1 kB ( 0%) ggc tree gimplify : 0.54 ( 1%) usr 0.01 ( 0%) sys 0.55 ( 1%) wall 6875 kB ( 9%) ggc tree eh : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc tree CFG construction : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc tree copy propagation : 1.04 ( 1%) usr 0.00 ( 0%) sys 1.06 ( 1%) wall 0 kB ( 0%) ggc tree find ref. vars : 0.08 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall 0 kB ( 0%) ggc tree PTA: 1.26 ( 1%) usr 0.00 ( 0%) sys 1.26 ( 1%) wall 0 kB ( 0%) ggc tree SSA rewrite: 0.22 ( 0%) usr 0.00 ( 0%) sys 0.21 ( 0%) wall 6179 kB ( 8%) ggc tree SSA other : 0.22 ( 0%) usr 0.08 ( 3%) sys 0.46 ( 0%) wall 0 kB ( 0%) ggc tree SSA incremental: 0.17 ( 0%) usr 0.00 ( 0%) sys 0.17 ( 0%) wall 0 kB ( 0%) ggc tree operand scan : 0.42 ( 0%) usr 0.13 ( 5%) sys 0.39 ( 0%) wall 3013 kB ( 4%) ggc dominator optimization : 0.15 ( 0%) usr 0.00 ( 0%) sys 0.16 ( 0%) wall 0 kB ( 0%) ggc tree CCP: 0.74 ( 1%) usr 0.00 ( 0%) sys 0.74 ( 1%) wall 0 kB ( 0%) ggc tree reassociation : 0.12 ( 0%) usr 0.00 ( 0%) sys 0.12 ( 0%) wall 0 kB ( 0%) ggc tree FRE: 3.25 ( 3%) usr 0.23 ( 8%) sys 3.42 ( 3%) wall 10314 kB (13%) ggc tree linearize phis
[Bug c/52290] [4.4/4.5/4.6/4.7 Regression] internal compiler error: tree check: expected function_decl, have var_decl in start_function, at c-decl.c:7712
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52290 --- Comment #5 from uros at gcc dot gnu.org 2012-02-23 18:01:54 UTC --- Author: uros Date: Thu Feb 23 18:01:45 2012 New Revision: 184517 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184517 Log: PR c/52290 * c-decl.c (start_function): Exit early if decl1 is not FUNTION_DECL. testsuite/ChangeLog: PR c/52290 * gcc.dg/noncompile/pr52290.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/noncompile/pr52290.c - copied unchanged from r184511, trunk/gcc/testsuite/gcc.dg/noncompile/pr52290.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/c-decl.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/52361] gcc.dg/pr48141.c times out with checking enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 Andrew Pinski changed: What|Removed |Added Keywords||compile-time-hog Component|c |tree-optimization Summary|gcc.dg/pr48141.c times out |gcc.dg/pr48141.c times out ||with checking enabled --- Comment #1 from Andrew Pinski 2012-02-23 18:03:56 UTC --- Over 40% of the time is spent in the checking functions: tree SSA verifier : 19.82 (20%) usr 0.00 ( 0%) sys 19.92 (19%) wall 0 kB ( 0%) ggc tree STMT verifier : 23.03 (23%) usr 0.01 ( 0%) sys 22.98 (22%) wall 0 kB ( 0%) ggc
[Bug c/52290] [4.4/4.5/4.6/4.7 Regression] internal compiler error: tree check: expected function_decl, have var_decl in start_function, at c-decl.c:7712
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52290 --- Comment #6 from uros at gcc dot gnu.org 2012-02-23 18:03:47 UTC --- Author: uros Date: Thu Feb 23 18:03:33 2012 New Revision: 184518 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184518 Log: PR c/52290 * c-decl.c (start_function): Exit early if decl1 is not FUNTION_DECL. testsuite/ChangeLog: PR c/52290 * gcc.dg/noncompile/pr52290.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/noncompile/pr52290.c - copied unchanged from r184511, trunk/gcc/testsuite/gcc.dg/noncompile/pr52290.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/c-decl.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
[Bug c/52290] [4.4/4.5/4.6/4.7 Regression] internal compiler error: tree check: expected function_decl, have var_decl in start_function, at c-decl.c:7712
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52290 Uros Bizjak changed: What|Removed |Added Status|NEW |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-02/msg01168.htm ||l Resolution||FIXED AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | --- Comment #7 from Uros Bizjak 2012-02-23 18:05:34 UTC --- Fixed everywhere.
[Bug ada/52362] New: gnat.dg/lto8.adb FAILs with gas/gld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52362 Bug #: 52362 Summary: gnat.dg/lto8.adb FAILs with gas/gld Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org Host: *-*-solaris2*, x86_64-unknown-linux-gnu Target: *-*-solaris2*, x86_64-unknown-linux-gnu Build: *-*-solaris2*, x86_64-unknown-linux-gnu The gnat.dg/lto8.adb test FAILs for me when using gas and gld 2.22 on Solaris (both SPARC and x86): e.g. on i386-pc-solaris2.10: FAIL: gnat.dg/lto8.adb (test for excess errors) Excess errors: /var/gcc/regression/trunk/10-gcc-gas-gld/build/i386-pc-solaris2.10/amd64/libada/adainclude/ada.o:(.data+0x0): multiple definition of `ada_E' /var/gcc/regression/trunk/10-gcc-gas-gld/build/i386-pc-solaris2.10/amd64/libada/adainclude/ada.o:(.data+0x0): first defined here /var/gcc/regression/trunk/10-gcc-gas-gld/build/i386-pc-solaris2.10/amd64/libada/adainclude/interfac.o:(.data+0x0): multiple definition of `interfaces_E' /var/gcc/regression/trunk/10-gcc-gas-gld/build/i386-pc-solaris2.10/amd64/libada/adainclude/interfac.o:(.data+0x0): first defined here and many more, but on Solaris only the 64-bit test fails. The failure doesn't occur with as/ld, gas/ld, or as/gld. I see the same failure on Linux/amd64, but here both the 64-bit and 32-bit test are affected. Rainer
[Bug tree-optimization/52286] [4.6 Regression] wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52286 --- Comment #11 from Jakub Jelinek 2012-02-23 18:20:26 UTC --- Author: jakub Date: Thu Feb 23 18:20:19 2012 New Revision: 184520 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184520 Log: Backported from trunk 2012-02-20 Georg-Johann Lay * gcc.c-torture/execute/pr52286.c: Fix FAIL on 16-bit int platforms. 2012-02-20 Jakub Jelinek PR tree-optimization/52286 * fold-const.c (fold_binary_loc): For (X & C1) | C2 optimization use double_int_to_tree instead of build_int_cst_wide, rewrite to use double_int vars. * gcc.c-torture/execute/pr52286.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/pr52286.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/fold-const.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #17 from Jack Howarth 2012-02-23 18:24:16 UTC --- Created attachment 26737 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26737 reduced patch
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #18 from Jack Howarth 2012-02-23 18:31:10 UTC --- (In reply to comment #16) The reduced patch properly adds the.. /* Define to 1 if you have the `pthread_get_stackaddr_np_np' function. */ #undef HAVE_PTHREAD_GET_STACKADDR_NP to boehm-gc/include/gc_config.h.in . Since the remaining changes to boehm-gc/include/private/gcconfig.h are "# ifdef DARWIN" and HAVE_PTHREAD_GET_STACKADDR_NP exists no where else, this should be sufficient. The patch elimintes the failures at -m32/-m64 on x86_64-apple-datrwin11 but boehm-gc.c/thread_leak_test.c execution test still hangs on occasion at -m64. This appears as... Leaked composite object at 0x10a908fe0 (/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120223/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:12, sz=4, NORMAL) Leaked composite object at 0x10a908ec0 (/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120223/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:12, sz=4, NORMAL) Leaked composite object at 0x10a908f20 (/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120223/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:12, sz=4, NORMAL) Leaked composite object at start: 0x10a908f00, appr. length: 48
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #19 from Jack Howarth 2012-02-23 18:37:40 UTC --- (In reply to comment #13) > I've not had time to investigate - but suspect it is related to operating > close to stack limits -- if you try reducing the number of recursions (like > PPC > does) does this go away? This is a different test. On x86_64-apple-darwin11, it is thread_leak_test.c which fails the execution test, not gctest.c or leak_test.c. I'll try rebuilding gcc trunk with the reduced patch but without... r175182 | mrs | 2011-06-18 11:06:26 -0400 (Sat, 18 Jun 2011) | 4 lines PR target/49461 * libjava/configure.ac (SYSTEMSPEC): Pass -no_pie for darwin11. * libjava/configure: Regenerate. to see how the libjava tests behave now with -pie.
[Bug c++/52363] New: Presence/absence of -pedantic compilation affects run-time behavior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52363 Bug #: 52363 Summary: Presence/absence of -pedantic compilation affects run-time behavior Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: w...@fnal.gov Created attachment 26738 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26738 C++11 source program whose behavior differs w/ -pedantic. The run-time behavior of the attached C++11 program differs according to the presence or absence of -pedantic during compilation. MacPorts compiler version: g++-mp-4.7 (GCC) 4.7.0 20120218 (experimental) System: MacBook Pro with 2.8GHz Intel Core 2 Duo running OS X 10.6.8 Command line 1: g++-mp-4.7 -O3 -std=c++0x pedantic_t.cc Command line 2: g++-mp-4.7 -O3 -std=c++0x -pedantic pedantic_t.cc * Using command line 1, the program builds with no diagnostic and runs to successful completion. * Using command line 2, the program builds with no diagnostic, but the assertion fails during execution. The principal concern is the inconsistent run-time behavior.
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #20 from Mike Stump 2012-02-23 18:45:28 UTC --- > Where do you want the second change made? Let me repeat myself: the code is in boehm-gc/include/private/gcconfig.h, so the patch should change the ifdef DARWIN block there. In the code in the file I mentioned, as a replacement to the #define that exists today.
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #21 from Jack Howarth 2012-02-23 18:50:21 UTC --- (In reply to comment #20) > > Where do you want the second change made? > > Let me repeat myself: > > the code is in boehm-gc/include/private/gcconfig.h, so the patch should change > the ifdef > DARWIN block there. > > > In the code in the file I mentioned, as a replacement to the #define that > exists today. Yes, See the reduced patch I posted in comment 17. Also, if thread_leak_test.c is twitchy with -pie at -m64, we could also open a PR for that and just skip this test on darwin11+ at -m64 for now. Assuming that my proposed reversion of r175182 causes no regressions in libjava on darwin11+.
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #22 from Patrick Marlier 2012-02-23 18:52:56 UTC --- (In reply to comment #21) > (In reply to comment #20) > > > Where do you want the second change made? > > > > Let me repeat myself: > > > > the code is in boehm-gc/include/private/gcconfig.h, so the patch should > > change > > the ifdef > > DARWIN block there. > > > > > > In the code in the file I mentioned, as a replacement to the #define that > > exists today. > > Yes, See the reduced patch I posted in comment 17. Also, if thread_leak_test.c > is twitchy with -pie at -m64, we could also open a PR for that and just skip > this test on darwin11+ at -m64 for now. Assuming that my proposed reversion of > r175182 causes no regressions in libjava on darwin11+. It seems there is already a PR for thread_leak_test.c failure: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 Patrick.
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #23 from Mike Stump 2012-02-23 18:56:31 UTC --- I think the patch in 17 is Ok.
[Bug target/52364] New: The unnecessary second form in *movabs_[12]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52364
Bug #: 52364
Summary: The unnecessary second form in *movabs_[12]
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: hubi...@gcc.gnu.org, ubiz...@gmail.com
Target: x86_64
i386.md has
;; Stores and loads of ax to arbitrary constant address.
;; We fake an second form of instruction to force reload to load address
;; into register when rax is not available
(define_insn "*movabs_1"
[(set (mem:SWI1248x (match_operand:DI 0 "x86_64_movabs_operand" "i,r"))
(match_operand:SWI1248x 1 "nonmemory_operand" "a,er"))]
"TARGET_64BIT && ix86_check_movabs (insn, 0)"
"@
movabs{}\t{%1, %P0|%P0, %1}
mov{}\t{%1, %a0|%a0, %1}"
[(set_attr "type" "imov")
(set_attr "modrm" "0,*")
(set_attr "length_address" "8,0")
(set_attr "length_immediate" "0,*")
(set_attr "memory" "store")
(set_attr "mode" "")])
Isn't the second form redundant since it is just normal mov?
[Bug c++/52363] Presence/absence of -pedantic compilation affects run-time behavior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52363 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-23 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2012-02-23 19:08:28 UTC --- confirmed
[Bug target/52261] [avr] Add support for AVR Xmega cores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52261 --- Comment #6 from Georg-Johann Lay 2012-02-23 19:26:06 UTC --- Author: gjl Date: Thu Feb 23 19:26:00 2012 New Revision: 184522 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184522 Log: PR target/52261 * config/avr/lib1funcs.S (__AVR__XMEGA__): Fix tippo to __AVR_XMEGA__. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/avr/lib1funcs.S
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #24 from Jack Howarth 2012-02-23 20:13:06 UTC --- Created attachment 26739 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26739 fix both PR52179 and revert hack from PR49461 I propose the following patch which both fixes PR52179 and reverts r175182 since it is no longer need. This patch bootstraps on x86_64-apple-darwin11 and produces the expected darwin11 libjava results without passing -Wl,-no_pie to the linker in gcj on darwin11.
[Bug libffi/52221] [libffi] r183675,r184021 needs to be fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52221 --- Comment #15 from Kai Tietz 2012-02-23 21:02:32 UTC --- Author: ktietz Date: Thu Feb 23 21:02:27 2012 New Revision: 184526 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184526 Log: PR libffi/52221 * src/x86/ffi.c (ffi_closure_raw_THISCALL): New prototype. (ffi_prep_raw_closure_loc): Use ffi_closure_raw_THISCALL for thiscall-convention. (ffi_raw_call): Use ffi_prep_args_raw. * src/x86/win32.S (ffi_closure_raw_THISCALL): Add implementation for stub. Modified: trunk/libffi/ChangeLog trunk/libffi/src/x86/ffi.c trunk/libffi/src/x86/win32.S
[Bug libffi/52221] [libffi] r183675,r184021 needs to be fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52221 Kai Tietz changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #16 from Kai Tietz 2012-02-23 21:03:44 UTC --- Fixed
[Bug fortran/52365] New: Procedure interface wrongly imported into interface without IMPORT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52365 Bug #: 52365 Summary: Procedure interface wrongly imported into interface without IMPORT Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org The following program is wrongly accepted. Expected an error such as: FOO has an implicit interface, therefore it cannot be used as a proc-interface Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e01ca2e546ecf0fe# module m interface subroutine foo() end subroutine foo end interface interface subroutine bar(x) ! import foo procedure(foo) :: x end subroutine bar end interface end module
[Bug tree-optimization/52286] [4.6 Regression] wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52286 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Jakub Jelinek 2012-02-23 21:29:10 UTC --- Fixed.
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #25 from Mike Stump 2012-02-23 21:53:04 UTC --- Ok.
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #26 from Jack Howarth 2012-02-23 21:55:57 UTC --- Posted to gcc-patches as http://gcc.gnu.org/ml/gcc-patches/2012-02/msg01209.html.
[Bug c++/52366] New: [c++11] static constexpr function cant initialize static constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52366
Bug #: 52366
Summary: [c++11] static constexpr function cant initialize
static constexpr
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: trashyan...@wp.pl
gcc version 4.7.0 20120203 (experimental) (niXman build)
code:
---
---
class A
{
static constexpr int func() { return 0; }
static constexpr int i = func();
//^--- error: field initializer is not constant
};
---
---
[Bug rtl-optimization/37516] ~(-2 - a) is not being optimized into a + 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37516
--- Comment #4 from Andrew Pinski 2012-02-23
22:15:05 UTC ---
> Maybe get away with these old-stylish names ('tree' and 'fold') and
> make it match reality, gimple-ssa-combine.c ;)
That sounds like a good idea. I have done that.
>
> Still have to have a look at your branch - do you have a brief
> overview documentation, for example on the wiki? What I'd like
> to do is have an interface that I can re-use for VN combining,
> basically replace its simplify_*_expression functions.
I don't have one yet. But I hope to create one this weekend.
Right now replacing the VN combining with this new functionality will not work
as it scans the defs itself. Though I am moving all the def scanning to its
own function which should allow for the code to be more modular and allow for
the VN combining to work with it.
[Bug bootstrap/52287] [4.7 regression] ICE in ready_remove_first, at haifa-sched.c:1927
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287 --- Comment #12 from Eric Botcazou 2012-02-23 22:15:53 UTC --- Author: ebotcazou Date: Thu Feb 23 22:15:44 2012 New Revision: 184531 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184531 Log: PR bootstrap/52287 * haifa-sched.c (rank_for_schedule): Stabilize sort for debug insns. Modified: trunk/gcc/ChangeLog trunk/gcc/haifa-sched.c
[Bug bootstrap/52287] [4.7 regression] ICE in ready_remove_first, at haifa-sched.c:1927
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from Eric Botcazou 2012-02-23 22:17:45 UTC --- Patch applied.
[Bug fortran/52351] Wrong bounds when passing an array section to an intent-in pointer dummy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52351 --- Comment #2 from Tobias Burnus 2012-02-23 22:34:31 UTC --- The issue seems to be in gfc_conv_array_parameter - or rather in the called gfc_conv_expr_descriptor. There, one has: full = gfc_full_array_ref_p (info->ref, NULL); if (full && !transposed_dims (ss)) else if (se->want_pointer) se->expr = gfc_build_addr_expr (NULL_TREE, desc); return; However, that's wrong if one needs to modify the bounds. Thus, in this special case (fsym == pointer/class_pointer && fsym->attr.intent == INTENT_IN plus last ref != AR_FULL), one has to create a new descriptor.
[Bug fortran/52335] [4.4/4.5/4.6/4.7 Regression] I/O: -std=f95 rejects valid DELIM= in OPEN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52335 --- Comment #4 from Tobias Burnus 2012-02-23 22:53:58 UTC --- Author: burnus Date: Thu Feb 23 22:53:54 2012 New Revision: 184534 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184534 Log: 2012-02-23 Tobias Burnus PR fortran/52335 * io.c (gfc_match_open): Remove bogus F2003 DELIM= check. 2012-02-23 Tobias Burnus PR fortran/52335 * gfortran.dg/io_constraints_10.f90: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/io_constraints_10.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/io.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
