[Bug c++/41533] ASM_PREFERRED_EH_DATA_FORMAT macros is not implemented for ARM
--- Comment #8 from kirill at shutemov dot name 2009-10-02 07:34 ---
(In reply to comment #6)
> (In reply to comment #5)
> > Ok. If .eh_frame should not be generated on ARM, we should to modify
> > dwarf2out_do_cfi_asm() to always return false on ARM. Right?
> >
>
> Look at this patch submitted here. Can you try this to see if it works for you
> ? http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00022.html
>
No, it doesn't help.
$ cat 1.cc
void m(){}
$ gcc-4.4 -S 1.cc
$ cat 1.s
.cpu arm9tdmi
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 6
.eabi_attribute 18, 4
.file "1.cc"
.text
.align 2
.global _Z1mv
.type _Z1mv, %function
_Z1mv:
.fnstart
.LFB0:
.cfi_startproc
.cfi_personality 0x0,__gxx_personality_v0
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 1, uses_anonymous_args = 0
@ link register save eliminated.
str fp, [sp, #-4]!
.cfi_def_cfa_offset 4
add fp, sp, #0
.cfi_offset 11, -4
.cfi_def_cfa_register 11
add sp, fp, #0
ldmfd sp!, {fp}
bx lr
.cfi_endproc
.LFE0:
.cantunwind
.fnend
.size _Z1mv, .-_Z1mv
.ident "GCC: (GNU) 4.4.1 20090725 (ALT Linux 4.4.1-alt1)"
.section.note.GNU-stack,"",%progbits
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41533
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #59 from developer at sandoe-acoustics dot co dot uk 2009-10-02 08:17 --- Created an attachment (id=18691) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18691&action=view) libext patch with ext on as default, debug flag removed and white space changes removed. This should, hopefully, be final. Reg-tests have completed successfully on i686-apple-darwin9 and x86_64-apple-darwin10 at m32 and m64. log: *libgcc/config/t-slibgcc-darwin: Fix embedded rpaths for --enable-version-specific-runtime-libs, build extension stub libs exposing newer features available from current libgcc_s. *gcc/config/darwin.h: Use the extension stub libraries to access newer libgcc_s features. Unfortunately, together that still makes changes amounting to 39 lines. However, I will post the reg test results and cross-reference them to here; I will post the patch and a changelog after that. Given that this issue was raised before the 4.4 branch - I assume that it should also be back-ported? (I'd imagine the patch would just apply, in fact) -- developer at sandoe-acoustics dot co dot uk changed: What|Removed |Added Attachment #17769|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug c++/41533] ASM_PREFERRED_EH_DATA_FORMAT macros is not implemented for ARM
--- Comment #9 from ramana at gcc dot gnu dot org 2009-10-02 08:26 --- (In reply to comment #8) Are you testing the correct compiler ? After building my 4.4 tree (though a cross compiler ) I see the code generated as below. The only reason why this might not work is if you are trying to build an arm-linux and not an arm-linux-gnueabi toolchain but your bug report indicates otherwise. As you can see there are no .cfi_* directives. .cpu arm10tdmi .fpu softvfp .eabi_attribute 20, 1 .eabi_attribute 21, 1 .eabi_attribute 23, 3 .eabi_attribute 24, 1 .eabi_attribute 25, 1 .eabi_attribute 26, 2 .eabi_attribute 30, 2 .eabi_attribute 18, 4 .file "1.cc" .text .align 2 .global main .type main, %function main: .fnstart .LFB0: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. mov r0, #0 bx lr .LFE0: .cantunwind .fnend .size main, .-main .ident "GCC: (GNU) 4.4.2 20091002 (prerelease) [trunk revision 152368]" .section.note.GNU-stack,"",%progbits -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41533
[Bug libstdc++/41448] std::sort on std::vector with certain values leads to segfault in the vector destructor
--- Comment #10 from 4ernov at gmail dot com 2009-10-02 08:41 --- Yeah, I see.. But anyway, thank you for discussing it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41448
[Bug fortran/41539] Calling function which takes CLASS: Rank comparison does not work
--- Comment #1 from burnus at gcc dot gnu dot org 2009-10-02 08:42 ---
I think the problem occurs in decl.c's
static gfc_try
encapsulate_class_symbol (gfc_typespec *ts, symbol_attribute *attr,
gfc_array_spec **as)
{
[...]
if (fclass == NULL)
{
[...]
c->attr.dimension = attr->dimension;
c->as = (*as);
}
[...]
attr->allocatable = attr->pointer = attr->dimension = 0;
(*as) = NULL; /* XXX */
[...]
}
which is called as:
if (sym->ts.type == BT_CLASS)
encapsulate_class_symbol (&sym->ts, &sym->attr, &sym->as);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41539
[Bug c++/41533] ASM_PREFERRED_EH_DATA_FORMAT macros is not implemented for ARM
--- Comment #10 from kirill at shutemov dot name 2009-10-02 09:06 --- (In reply to comment #9) > (In reply to comment #8) > > Are you testing the correct compiler ? Yes. > After building my 4.4 tree (though a > cross compiler ) I see the code generated as below. > > The only reason why this might not work is if you are trying to build an > arm-linux and not an arm-linux-gnueabi toolchain but your bug report indicates > otherwise. $ gcc-4.4 -dumpmachine arm-alt-linux-gnueabi > As you can see there are no .cfi_* directives. Do you use c++ compiler with enabled exception handling? Do you have TEXTRELs in libstdc++ from this compiler? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41533
[Bug fortran/41515] [4.3/4.4/4.5 Regression] PARAMETER statement in module subroutines
--- Comment #8 from ros at rzg dot mpg dot de 2009-10-02 09:43 --- Subject: Re: [4.3/4.4/4.5 Regression] PARAMETER statement in module subroutines Thanks for fixing the bug 41515. Where can I find a Linux binary of gfortran revision 152379, and how can I find out the revision number without downloading and installing a gfortran binary? +--+ | Roland Schilling Home-Office: +49(89)32929-670 | | Max-Planck-Institut für Gravitationsphysik | | -- Albert-Einstein-Institut -- | | D-85748 Garching E-mail: r...@rzg.mpg.de | | Germany http://www.aei-hannover.de | +--+ Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41515
[Bug preprocessor/41543] New: BUILTINS_LOCATION wrong with -fpreprocessed
With -fpreprocessed, expand_location (BUILTINS_LOCATION) yields the
preprocessed source file name (e.g. bar.ii), line 1, column 1, instead of
filename, line 0. So e.g. ./cc1 -g -dA -fpreprocessed bar.ii
where bar.ii is:
# 1 "foo.C"
# 1 ""
# 1 ""
# 1 "foo.C"
int
foo (__builtin_va_list ap)
{
return __builtin_va_arg (ap,int);
}
will have bar.ii in the filemap and e.g. on x86-64 va_list struct and its
fields will use that as location.
BUILTINS_LOCATION is 2, and for normal compilation without -fpreprocessed
there is just a:
cpp_read_main_file -> _cpp_stack_file -> _cpp_do_file_change -> linemap_add
call that bumps line_table->highest_location to 1, and then there is:
1491 if (!cpp_opts->preprocessed)
1492{
1493 size_t i;
1494
1495 cb_file_change (parse_in,
1496 linemap_add (line_table, LC_RENAME, 0,
1497 _(""), 0));
in c-opts.c which ensures that location 2 maps to .
But with -fpreprocessed cpp_read_main_file does additionally:
/* For foo.i, read the original filename foo.c now, for the benefit
of the front ends. */
if (CPP_OPTION (pfile, preprocessed))
{
read_original_filename (pfile);
fname = pfile->line_table->maps[pfile->line_table->used-1].to_file;
}
and read_original_filename during lexing of the first character already eats
some locations, bumping line_table->highest_location.
Not sure what would be best to fix it.
--- init.c.xx2009-06-30 13:10:43.0 +0200
+++ init.c2009-10-02 11:49:51.0 +0200
@@ -554,6 +554,13 @@ cpp_read_main_file (cpp_reader *pfile, c
of the front ends. */
if (CPP_OPTION (pfile, preprocessed))
{
+ /* Hack: GCC expects that (source_location) 2 is BUILTINS_LOCATION,
+ but after read_original_filename lexing it will be at the start of
+ the first line of the preprocessed file. */
+ linemap_add (pfile->line_table, LC_RENAME, 0, _(""), 0);
+ linemap_add (pfile->line_table, LC_RENAME, 0,
+ pfile->line_table->maps[pfile->line_table->used-2].to_file,
+ 1);
read_original_filename (pfile);
fname = pfile->line_table->maps[pfile->line_table->used-1].to_file;
}
cures this, but feels like a hack. As it is gcc specific, it would need to be
some libcpp callback or something. Changing BUILTINS_LOCATION to say
(source_location) -1, changing the places that check e.g. that location is <=
BUILTINS_LOCATION and special casing BUILTINS_LOCATION in expand_location could
perhaps work too.
Tom, what do you prefer?
--
Summary: BUILTINS_LOCATION wrong with -fpreprocessed
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41543
[Bug fortran/41479] [4.3/4.4/4.5 Regression] intent(out) for types with default initialization
--- Comment #8 from burnus at gcc dot gnu dot org 2009-10-02 09:54 --- (In reply to comment #7) > Checking the 4.2 branch and trans-expr.c in trunk, it appears that > this chunk of code in gfc_conv_function_call() has gone missing. It was removed with the following patch: Date: Tue Jul 24 19:16:36 2007 New Revision: 126885 / 126886 URL: http://gcc.gnu.org/viewcvs?view=revision&revision=126885 http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126886 Log: 2007-07-24 Paul Thomas PR fortran/31205 PR fortran/32842 * trans-expr.c (gfc_conv_function_call): Remove the default initialization of intent(out) derived types. >From http://gcc.gnu.org/ml/gcc-patches/2007-06/msg02151.html: (ii) Remove the initialization of derived types with a default initializer from the caller to the callee. The reasons for doing this are discussed in the PR (PR31205). It has a gratifying effect on passing derived types with allocatable components, in that the amount of generated code goes down (see alloc_comp_basics_1.f90). Thus I think that part is OK. (Doing the default initialization in the caller leads to wrong code if the caller does not know the interface of called procedure.) However, some callee initialization is now missing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41479
[Bug testsuite/41542] [4.5 Regression] gcc.dg/tree-ssa/ipa-cp-1.c failed
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |testsuite Summary|gcc.dg/tree-ssa/ipa-cp-1.c |[4.5 Regression] |failed |gcc.dg/tree-ssa/ipa-cp-1.c ||failed Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41542
[Bug fortran/41515] [4.3/4.4/4.5 Regression] PARAMETER statement in module subroutines
--- Comment #9 from mikael at gcc dot gnu dot org 2009-10-02 10:17 --- (In reply to comment #8) > Where can I find a Linux binary > of gfortran revision 152379, and how can I find out the revision > number without downloading and installing a gfortran binary? See the gfortran wiki http://gcc.gnu.org/wiki/GFortran -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41515
[Bug fortran/41515] [4.3/4.4/4.5 Regression] PARAMETER statement in module subroutines
--- Comment #10 from ros at rzg dot mpg dot de 2009-10-02 10:25 --- Subject: Re: [4.3/4.4/4.5 Regression] PARAMETER statement in module subroutines On Fri, 2 Oct 2009, mikael at gcc dot gnu dot org wrote: > --- Comment #9 from mikael at gcc dot gnu dot org 2009-10-02 10:17 > --- > (In reply to comment #8) >> Where can I find a Linux binary >> of gfortran revision 152379, and how can I find out the revision >> number without downloading and installing a gfortran binary? > > See the gfortran wiki > http://gcc.gnu.org/wiki/GFortran That's where I looked all the time, but this does not tell me the revision number :-( +--+ | Roland Schilling Home-Office: +49(89)32929-670 | | Max-Planck-Institut für Gravitationsphysik | | -- Albert-Einstein-Institut -- | | D-85748 Garching E-mail: r...@rzg.mpg.de | | Germany http://www.aei-hannover.de | +--+ Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41515
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #60 from developer at sandoe-acoustics dot co dot uk 2009-10-02 10:39 --- Reg test results: powerpc-apple darwin8 : http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg00141.html i686-apple-darwin9: http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg00142.html compare without patch : http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg00144.html [show no new fails and a considerable number of extra passes] x86_64-apple-darwin10: http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg00143.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug c++/41544] New: unqualified member function reference is or not valid in constant expression depending on class being a template or not
This is related to bug #35167 in: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35167 The attached test case compiles if the preprocessor symbol MAKE_IT_WORK is defined. Otherwise fails with: main.cpp: In static member function 'static const X& A::getIt2() [with Q = X]': main.cpp:34: instantiated from here main.cpp:28: error: 'static const X& A::getIt() [with Q = X]' cannot appear in a constant-expression This has hit us with 4.4.1 on sparc-sun-solaris2.10, and reproduced in 3.3.1 on x86_64-linux-gnu. The referred bug seems to imply that this behaviour is a non-bug, but then I don't understand why the same explanation (based on the requirement of a qualified-id for the address-of (&) operator) doesn't apply to the case in which the class defining the scope (A in the test case when MAKE_IT_WORK is defined), making it compile fine. It seems to be a total inconsistency, unless the phrase "in the current context" of Comment #2 refers specifically to "being compiling code". In any case, about the referred paragraph in the other bug: 5.19/4 An address constant expression is a pointer to an lvalue designating an object of static storage duration, a string literal (_lex.string_), or a function. The pointer shall be created explicitly, using the unary & operator, or implicitly using a non-type template parameter of pointer type, or using an expression of array (_conv.array_) or function (_conv.func_) type. Creating the pointer implicitly from a function type doesn't explicitly (no pun intended) require that creation to use an expression with the unary & operator. I mean, if the function type named by a unqualified-id has no ambiguity (as it's the case, since the unqualified-id has been declared at the current template class and not hidden at the current function scope), I don't see the point in forcing usage of the class qualifier, moreover if the case works ok for a non-template class. The thing is this will force us to update some macros to take also the name of the enclosing class to generate a qualified static member function identifier, while it's not needed for the other compilers we use. So, I would request the compiler to be fixed to treat both cases (A being a template class or not) equally, seeming the most sensible option not requiring a explicit A::getIt() in the IndirectCaller template parameter for the code to compile. -- Summary: unqualified member function reference is or not valid in constant expression depending on class being a template or not Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: skandalfo at gmail dot com GCC build triplet: sparc-sun-solaris2.10 GCC host triplet: sparc-sun-solaris2.10 GCC target triplet: sparc-sun-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41544
[Bug c++/41544] unqualified member function reference is or not valid in constant expression depending on class being a template or not
--- Comment #1 from skandalfo at gmail dot com 2009-10-02 10:52 --- Created an attachment (id=18692) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18692&action=view) Test case Compiles with -DMAKE_IT_WORK. Doesn't compile otherwise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41544
[Bug c++/41544] unqualified member function reference is or not valid in constant expression depending on class being a template or not
--- Comment #2 from skandalfo at gmail dot com 2009-10-02 10:53 --- Excuse me, the confirmation of the issue WAS NOT DONE ON "3.3.1 on x86_64-linux-gnu"m but in 4.3.3 on x86_64-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41544
[Bug c++/41503] function_parameter_expanded_from_pack_p segfaults when passed a PARM_DECL created by IPA-SRA
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-10-02 11:39 --- Fixed -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41503
[Bug fortran/41515] [4.3/4.4/4.5 Regression] PARAMETER statement in module subroutines
--- Comment #11 from burnus at gcc dot gnu dot org 2009-10-02 11:58 --- (In reply to comment #8) > Thanks for fixing the bug 41515. Where can I find a Linux binary > of gfortran revision 152379, and how can I find out the revision > number without downloading and installing a gfortran binary? Depends where you download the binary from. For my x86-64 builds, one can find it in the file name (click on "Download page." or go directly to http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/ ) Otherwise, looking at the file modification date is usually a good indication. Example for the i386-linux build on http://gcc.gnu.org/wiki/GFortranBinaries $ curl -I http://quatramaran.ens.fr/~coudert/gfortran/gfortran-4.5-linux-i686.tar.gz [...] Last-Modified: Thu, 01 Oct 2009 20:21:58 GMT It also depends on the packager whether (s)he has only the latest 4.5-experimental "trunk" packages or also 4.4- and 4.3-branch builds - or whether the build also includes C++ or has Graphite and/or MPC enabled. (I have both, 4.4 and 4.3, with MPC and Graphite enabled for x86-64-linux; disadvantage of those x86-64-linux builds is that one needs recent enough GLIBC and binutils.) If you have a recent enough GMP and MPFR, building GCC is also not difficult, cf. bottom of http://gcc.gnu.org/wiki/GFortranBinaries). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41515
[Bug c++/41545] New: [4.5 Regression] ICE tree check: expected var_decl or function_decl, have error_mark in grokdeclarator, at cp/decl.c:9305
On *-apple-darwin* several tests in the g++ suite fail (see http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg00143.html) with: /opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/template/memfriend7.C:20:26: internal compiler error: tree check: expected var_decl or function_decl, have template_decl in grokdeclarator, at cp/decl.c:9305 Revisions 152257 (see http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02620.html) and before do not fail. -- Summary: [4.5 Regression] ICE tree check: expected var_decl or function_decl, have error_mark in grokdeclarator, at cp/decl.c:9305 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: *-apple-darwin* GCC host triplet: *-apple-darwin* GCC target triplet: *-apple-darwin* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41545
[Bug fortran/41515] [4.3/4.4/4.5 Regression] PARAMETER statement in module subroutines
--- Comment #12 from ros at rzg dot mpg dot de 2009-10-02 12:35 --- Subject: Re: [4.3/4.4/4.5 Regression] PARAMETER statement in module subroutines On Fri, 2 Oct 2009, burnus at gcc dot gnu dot org wrote: > Depends where you download the binary from. For my x86-64 builds, one can find > it in the file name (click on "Download page." or go directly to > http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/ ) Thanks, but unfortunately I need a 32-bit version. > Otherwise, looking at the file modification date is usually a good indication. > Example for the i386-linux build on http://gcc.gnu.org/wiki/GFortranBinaries The point is that in the section 'GNU/Linux' there is no date at all! I think, it would be a good idea to add there the modification date and the revision number. +--+ | Roland Schilling Home-Office: +49(89)32929-670 | | Max-Planck-Institut für Gravitationsphysik | | -- Albert-Einstein-Institut -- | | D-85748 Garching E-mail: r...@rzg.mpg.de | | Germany http://www.aei-hannover.de | +--+ Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41515
[Bug testsuite/41546] New: Revision 152389 breaks gcc.target/i386/ifcvt-onecmpl-abs-1.c
Revision 152389: http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00038.html breaks gcc.target/i386/ifcvt-onecmpl-abs-1.c on x86-64 since -mtune=i586 is invalid for x86-64. I think we should use -mtune=generic. -- Summary: Revision 152389 breaks gcc.target/i386/ifcvt-onecmpl- abs-1.c Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41546
[Bug testsuite/41546] Revision 152389 breaks gcc.target/i386/ifcvt-onecmpl-abs-1.c
--- Comment #1 from hjl at gcc dot gnu dot org 2009-10-02 13:28 --- Subject: Bug 41546 Author: hjl Date: Fri Oct 2 13:28:17 2009 New Revision: 152400 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152400 Log: 2009-10-02 H.J. Lu PR testsuite/41546 * gcc.target/i386/ifcvt-onecmpl-abs-1.c: Change -mtune=i586 to -mtune=generic. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/ifcvt-onecmpl-abs-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41546
[Bug testsuite/41546] Revision 152389 breaks gcc.target/i386/ifcvt-onecmpl-abs-1.c
--- Comment #2 from hjl dot tools at gmail dot com 2009-10-02 13:30 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41546
Re: [Bug fortran/41515] [4.3/4.4/4.5 Regression] PARAMETER statement in module subroutines
On 10/02/2009 05:35 AM, ros at rzg dot mpg dot de wrote: --- Comment #12 from ros at rzg dot mpg dot de 2009-10-02 12:35 --- Subject: Re: [4.3/4.4/4.5 Regression] PARAMETER statement in module subroutines On Fri, 2 Oct 2009, burnus at gcc dot gnu dot org wrote: Depends where you download the binary from. For my x86-64 builds, one can find it in the file name (click on "Download page." or go directly to http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/ ) Thanks, but unfortunately I need a 32-bit version. The build Tobias mentioned is a nightly update to latest 4.5 trunk version. http://quatramaran.ens.fr/~coudert/gfortran/gfortran-4.5-linux-i686.tar.gz The update starts at about 11:00 PM PST every day and is uploaded several hours later. Jerry
[Bug fortran/41515] [4.3/4.4/4.5 Regression] PARAMETER statement in module subroutines
--- Comment #13 from jvdelisle at verizon dot net 2009-10-02 13:57 --- Subject: Re: [4.3/4.4/4.5 Regression] PARAMETER statement in module subroutines On 10/02/2009 05:35 AM, ros at rzg dot mpg dot de wrote: > > > --- Comment #12 from ros at rzg dot mpg dot de 2009-10-02 12:35 --- > Subject: Re: [4.3/4.4/4.5 Regression] PARAMETER statement > in module subroutines > > On Fri, 2 Oct 2009, burnus at gcc dot gnu dot org wrote: > >> Depends where you download the binary from. For my x86-64 builds, one can >> find >> it in the file name (click on "Download page." or go directly to >> http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/ ) > > Thanks, but unfortunately I need a 32-bit version. The build Tobias mentioned is a nightly update to latest 4.5 trunk version. http://quatramaran.ens.fr/~coudert/gfortran/gfortran-4.5-linux-i686.tar.gz The update starts at about 11:00 PM PST every day and is uploaded several hours later. Jerry -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41515
[Bug c++/41313] r150553 causes g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*
--- Comment #28 from howarth at nitro dot med dot uc dot edu 2009-10-02 14:08 --- On reflection, I think the change Mike proposed for darwin.c in Comment 13 fails because it flag_reorder_blocks never gets set to 1 by that patch. I don't know how I could implement the three variations of setting that which occur in opts.c from within the overrides of darwin.c. Those cases in opts.c are listed as... /* The optimization to partition hot and cold basic blocks into separate sections of the .o and executable files does not work (currently) with exception handling. This is because there is no support for generating unwind info. If flag_exceptions is turned on we need to turn off the partitioning optimization. */ /* If user requested unwind info, then turn off the partitioning optimization. */ /* If the target requested unwind info, then turn off the partitioning optimization with a different message. Likewise, if the target does not support named sections. */ Would it be as simple as duplicating those three variations of the conditional within the overrides of darwin.c to duplicate their behavior? It seem much better to fix the breakage in opts.c caused by r150553. -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Summary|g++.dg/tree-|r150553 causes g++.dg/tree- |prof/partition1.C |prof/partition1.C |compilation and execution |compilation and execution |test failures on *-apple- |test failures on *-apple- |darwin* |darwin* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41313
[Bug lto/41547] New: ICEs in lto_symtab_merge_decl, at lto-symtab.c:577
template < class T >
class DataArray {
int max() const { }
};
class Name { };
class DataHashTable {
template < class ElemHashItem > class Element { };
DataArray < Element < Name > > m_elem;
};
DataHashTable p;
./g++ -B. -nostdlib -fPIC -shared spxgeneralsm.3.ii -flto
lto1: internal compiler error: in lto_symtab_merge_decl, at lto-symtab.c:577
DataArray<>::max is not mangled.
--
Summary: ICEs in lto_symtab_merge_decl, at lto-symtab.c:577
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41547
[Bug lto/41548] New: ICE: tree code 'lang_type' is not supported in gimple streams
class DataArray {
int max() const{ }
};
template < class HashItem >
class DataHashTable {
template < class ElemHashItem >
class Element{ };
typedef Element< HashItem > Elem;
DataArray m_elem;
};
class Name{ };
class NameSet {
DataHashTable < Name > hashtab;
};
NameSet p;
./g++ -B. -nostdlib -fPIC -shared spxgeneralsm.3.2.ii -flto
spxgeneralsm.3.2.ii:15:10: internal compiler error: tree code 'lang_type' is
not supported in gimple streams
--
Summary: ICE: tree code 'lang_type' is not supported in gimple
streams
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41548
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #24 from jakub at gcc dot gnu dot org 2009-10-02 15:01 --- Subject: Bug 41404 Author: jakub Date: Fri Oct 2 15:01:22 2009 New Revision: 152403 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152403 Log: PR debug/41404 PR debug/41353 * cfgexpand.c (expand_debug_expr) : Don't create CONST_STRING if STRING_CST contains embedded '\0's or doesn't end with '\0'. (expand_debug_expr) : For TREE_STATIC !DECL_EXTERNAL vars use DECL_RTL with resetting it back to NULL afterwards. * dwarf2out.c (same_dw_val_p): For dw_val_class_addr compare with rtx_equal_p instead of asserting it is a SYMBOL_REF. (value_format): For dw_val_class_addr only use DW_FORM_addr if the attribute type allows it, otherwise use DW_FORM_dataN. (mem_loc_descriptor): Handle CONST_STRING. (add_const_value_attribute): Handle CONST_STRING using add_AT_addr. Handle MEM with CONST_STRING address using add_AT_string. (rtl_for_decl_init): Return MEM with CONST_STRING address instead of CONST_STRING for const arrays initialized with a string literal. (resolve_one_addr, resolve_addr_in_expr, resolve_addr): New functions. (dwarf2out_finish): Call resolve_addr. * gcc.dg/guality/pr41404-1.c: New test. * gcc.dg/guality/pr41353-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/guality/pr41353-2.c trunk/gcc/testsuite/gcc.dg/guality/pr41404-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug debug/41353] VTA missed-debug issues
--- Comment #13 from jakub at gcc dot gnu dot org 2009-10-02 15:01 --- Subject: Bug 41353 Author: jakub Date: Fri Oct 2 15:01:22 2009 New Revision: 152403 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152403 Log: PR debug/41404 PR debug/41353 * cfgexpand.c (expand_debug_expr) : Don't create CONST_STRING if STRING_CST contains embedded '\0's or doesn't end with '\0'. (expand_debug_expr) : For TREE_STATIC !DECL_EXTERNAL vars use DECL_RTL with resetting it back to NULL afterwards. * dwarf2out.c (same_dw_val_p): For dw_val_class_addr compare with rtx_equal_p instead of asserting it is a SYMBOL_REF. (value_format): For dw_val_class_addr only use DW_FORM_addr if the attribute type allows it, otherwise use DW_FORM_dataN. (mem_loc_descriptor): Handle CONST_STRING. (add_const_value_attribute): Handle CONST_STRING using add_AT_addr. Handle MEM with CONST_STRING address using add_AT_string. (rtl_for_decl_init): Return MEM with CONST_STRING address instead of CONST_STRING for const arrays initialized with a string literal. (resolve_one_addr, resolve_addr_in_expr, resolve_addr): New functions. (dwarf2out_finish): Call resolve_addr. * gcc.dg/guality/pr41404-1.c: New test. * gcc.dg/guality/pr41353-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/guality/pr41353-2.c trunk/gcc/testsuite/gcc.dg/guality/pr41404-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41353
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #25 from jakub at gcc dot gnu dot org 2009-10-02 15:03 --- Should be fixed now. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug fortran/41408] Segmentation fault calling DGETRF from gfortran
--- Comment #5 from lanceb at ksu dot edu 2009-10-02 15:29 --- Subject: Re: Segmentation fault calling DGETRF from gfortran I have not figured out what is going on. I've been using G95 because it works correctly with G95. When I have more time (things are very busy right now) I will look at it again. kargl at gcc dot gnu dot org wrote: > --- Comment #4 from kargl at gcc dot gnu dot org 2009-10-01 17:30 --- > (In reply to comment #2) >> Subject: Re: Segmentation fault calling DGETRF from >> gfortran >> >> Well, that's an embarrassing mistake. My apologies. For some reason the >> example >> code does run correctly for G95. >> >> In my (much larger) program I do call DGETRF correctly, and get a >> segmentation >> fault when using gfortran but not G95. I will continue to look at it. >> Obviously >> I have not isolated the problem. >> >> Sorry for the trouble. >> > > Have you made any progress on this issue? Trying compiling everything > with -Wall and -fbounds-check > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41408
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #26 from davek at gcc dot gnu dot org 2009-10-02 15:35 --- Thanks Jakub, I'll try and verify that in the next ~24hrs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug java/41549] New: [jni] very slow jni code callbacks
See mailing list: http://gcc.gnu.org/ml/java/2009-09/msg00030.html I have a problem with jni code callbacks. I have attached some code that shows the problem. The result of this code is: # results on fedora 11 # gcc/gcj 4.4.1 # kernel 2.6.30.5-43.fc11.x86_64 # openjdk fedora-29.b16.fc11-x86_64 # # open jdkgcj # no_jni 1.48 7.46( 5 times slower) # jni 66.70 17140.00(257 times slower) So when not using jni in this case gcj is 5 times slower. I suspect the jit compiler does a good for this small sample. The code with jni calls is however 257 timer slower. I really did not expect that. I also tried other java vm and they all have much better performance. So I expect a problem in the gcj library. When I use oprofile I see at lot of calls to execute_cfa_program and _Unwind_IteratePhdrCallback. -- Summary: [jni] very slow jni code callbacks Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hermantenbrugge at home dot nl GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41549
[Bug preprocessor/41540] -dM -E doesn't #define __FILE__
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-10-02 16:21 --- __FILE__ is dependent on # markers and #line markers in the preprocessed source so this is invalid. __LINE__ is also dependent too. If you look at the preprocessed source you will notice still some # in there. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41540
[Bug fortran/41408] Segmentation fault calling DGETRF from gfortran
--- Comment #6 from kargl at gcc dot gnu dot org 2009-10-02 16:25 --- Works for me. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41408
[Bug fortran/41479] [4.3/4.4/4.5 Regression] intent(out) for types with default initialization
--- Comment #9 from burnus at gcc dot gnu dot org 2009-10-02 16:26 --- Subject: Bug 41479 Author: burnus Date: Fri Oct 2 16:25:50 2009 New Revision: 152407 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152407 Log: 2009-10-02 Tobias Burnus PR fortran/41479 * trans-decl.c (gfc_init_default_dt): Check for presence of the argument only if it is optional or in entry master. (init_intent_out_dt): Ditto; call gfc_init_default_dt for all derived types with initializers. 2009-10-02 Tobias Burnus PR fortran/41479 * gfortran.dg/intent_out_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/intent_out_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41479
[Bug fortran/41403] [4.3/4.4/4.5 Regression] miscompilation of goto/label using code
--- Comment #13 from domob at gcc dot gnu dot org 2009-10-02 16:26 --- I'll work on this. -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-09-19 18:27:18 |2009-10-02 16:26:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41403
[Bug rtl-optimization/41511] [4.5 Regression] combine behaves differently with/without -g
--- Comment #3 from jakub at gcc dot gnu dot org 2009-10-02 16:35 --- Created an attachment (id=18693) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18693&action=view) gcc45-pr41511.patch Agreed. Patch I'm going to bootstrap/regtested on x86_64-linux and i686-linux now, fixes this -fcompare-debug issue on the testcase in x86_64-linux -> sh4-linux cross. The zero extension is indeed unneeded in this case, perhaps reg_num_sign_bit_copies_for_combine could try harder. The thing is that if get_last_value before the final validation finds it is MEM and only the validation changes it into a clobber because it is unknown what value will the memory have, if LOAD_EXTEND_OP is SIGN_EXTEND for the mode, it doesn't really matter what value the memory has for num_sign_bit_copies. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41511
[Bug preprocessor/41540] -dM -E doesn't #define __FILE__
--- Comment #2 from msebor at gmail dot com 2009-10-02 16:39 --- I don't have a strong objection to not including __FILE__ and the rest of standard predefined macros (e.g., __LINE__, __DATE__ and __TIME__) in the output if that's by design but I would expect the documentation to mention that some macros are deliberately left out. As it stands, it states that all macros are defined, which is clearly not the case. I suggest clarifying the documentation by changing the paragraph quoted above to read: "Instead of the normal output, generate a list of `#define' directives for the majority of macros defined during the execution of the preprocessor, including predefined macros (the standard macros __DATE__, __FILE__, __LINE__, and __TIME__ are excluded from this list). This gives you a way of finding out what is predefined in your version of the preprocessor." I'm not familiar with the process for updating gcc docs but if you point me in the right direction I would be happy to submit a patch. -- msebor at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41540
[Bug preprocessor/41540] -dM -E doesn't #define __FILE__
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-10-02 16:57 --- Hmm, considering the C99 standard has a footnote about __FILE__ (149) 149) The presumed source file name and line number can be changed by the #line directive. So of course it is hard to define these in the preprocessed source. I really don't think there should be a note about these predefined macro names based on what is mentioned in the standard. Since they are dependent on the file that is being compiled (not preprocessed). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41540
[Bug bootstrap/41500] [4.4 Regression] ARM: 4.4 compiler segfault when compiling gcc
--- Comment #11 from armin76 at gentoo dot org 2009-10-02 17:08 --- Created an attachment (id=18694) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18694&action=view) backtrace.log and the backtrace using gdb with the following command: gdb --args /root/build/./gcc/cc1 conftest.c conftest.c being what attachment 18688 has as conftest.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41500
[Bug target/41081] redundant ZERO_EXTENDs
--- Comment #12 from bergner at gcc dot gnu dot org 2009-10-02 17:12 --- Subject: Bug 41081 Author: bergner Date: Fri Oct 2 17:12:31 2009 New Revision: 152411 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152411 Log: Backport from mainline: 2009-08-23 Alan Modra PR target/41081 * config/rs6000/rs6000.md (rotlsi3_64, ashlsi3_64, lshrsi3_64, ashrsi3_64): New. Backport from 4.3 branch: 2009-09-25 Alan Modra * config/rs6000/rs6000.md (load_toc_v4_PIC_3c): Correct POWER form of instruction. 2009-09-23 Alan Modra PR target/40473 * config/rs6000/rs6000.c (rs6000_output_function_prologue): Don't call final to emit non-scheduled prologue, instead insert at entry. Modified: branches/ibm/gcc-4_3-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_3-branch/gcc/config/rs6000/rs6000.c branches/ibm/gcc-4_3-branch/gcc/config/rs6000/rs6000.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41081
[Bug target/40473] -mno-sched-prolog breaks function parameter debug location lists
--- Comment #8 from bergner at gcc dot gnu dot org 2009-10-02 17:12 --- Subject: Bug 40473 Author: bergner Date: Fri Oct 2 17:12:31 2009 New Revision: 152411 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152411 Log: Backport from mainline: 2009-08-23 Alan Modra PR target/41081 * config/rs6000/rs6000.md (rotlsi3_64, ashlsi3_64, lshrsi3_64, ashrsi3_64): New. Backport from 4.3 branch: 2009-09-25 Alan Modra * config/rs6000/rs6000.md (load_toc_v4_PIC_3c): Correct POWER form of instruction. 2009-09-23 Alan Modra PR target/40473 * config/rs6000/rs6000.c (rs6000_output_function_prologue): Don't call final to emit non-scheduled prologue, instead insert at entry. Modified: branches/ibm/gcc-4_3-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_3-branch/gcc/config/rs6000/rs6000.c branches/ibm/gcc-4_3-branch/gcc/config/rs6000/rs6000.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40473
[Bug lto/41550] New: Fix security and portability issues in lto-plugin
>From http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02151.html
> +static void
> +write_resolution (void)
> +{
> + unsigned int i;
> + FILE *f;
> + /* FIXME: Disabled for now since we are not using the resolution file. */
> + return;
> +
> +
> + /* FIXME: This should be a temporary file. */
> + f = fopen ("resolution", "w");
Fixed filenames like this are typically security holes. The return above
means this isn't, but it might be best to remove this function altogether
until you are ready to add a version that actually does something.
> +/* Pass files generated by the lto-wrapper to the linker. FD is lto-wrapper's
> + stdout. */
> +
> +static void
> +add_output_files (FILE *f)
> +{
> + char fname[1000]; /* FIXME: Is this big enough? */
I don't know what sort of strings go there, but if they can be filenames
with user-controlled components then the GNU Coding Standards say to avoid
arbitrary limits.
> + output_files = realloc (output_files, num_output_files * sizeof (char
> *));
> + output_files[num_output_files - 1] = strdup (s);
Use xrealloc and xstrdup. Other places have the same issue with realloc
or calloc or strdup.
> + /* Write argv to a file to avoid a command line that is too long. */
> + t = asprintf (&at_args, "@%s/arguments", temp_obj_dir_name);
> + assert (t >= 0);
This is an example of inappropriate use of assert for things that may be
valid error conditions not a program bug. It looks like there are others
in this plugin. Some cleanup work is needed.
--
Summary: Fix security and portability issues in lto-plugin
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: espindola at google dot com
ReportedBy: dnovillo at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41550
[Bug libstdc++/41495] libstdc++ --enable-clocale=ieee_1003.1-2001 fails
--- Comment #2 from ro at gcc dot gnu dot org 2009-10-02 17:45 --- Initial patch to get it to compile here: http://gcc.gnu.org/ml/libstdc++/2009-10/msg8.html -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-02 17:45:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41495
[Bug libstdc++/41495] libstdc++ --enable-clocale=ieee_1003.1-2001 fails
--- Comment #3 from ro at gcc dot gnu dot org 2009-10-02 17:47 --- Created an attachment (id=18695) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18695&action=view) libstdc++ testsuite log (both 32 and 64 bit) on Solaris 10/x86 with initial patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41495
[Bug preprocessor/41540] -dM -E doesn't #define __FILE__
--- Comment #4 from msebor at gmail dot com 2009-10-02 18:00 --- I understand that the values of __FILE__ and __LINE__ change within the same translation unit and thus may not be meaningful in the output of -dM -E. But the values of __DATE__ and __TIME__ do not change within a translation unit and so they could and IMO should be included in the output. In any case, since the preprocessed output contains all the standard macros expanded, I think it's reasonable to either see them all in the output of -dM -E or the discrepancies between the two kinds of output to be mentioned in the docs. I don't insist on including an exhaustive list of all macros excluded from the output if this list is large or changes depending on compiler options etc. but I do think that the docs ought to be clarified so as not to state that *all* macros are output. Here's a small test program to show the discrepancies: $ cat u.c && gcc -E u.c && gcc -E -dM u.c | grep -e__DATE__ -e__FILE__ -e__LINE__ -e__STDC__ -e__STDC_HOSTED__ -e__STDC_VERSION__ -e__TIME__ char date[] = __DATE__; int line = __LINE__; char file[] = __FILE__; char time[] = __TIME__; int stdc = __STDC__; int stdc_hosted = __STDC_HOSTED__; # 1 "u.c" # 1 "" # 1 "" # 1 "u.c" char date[] = "Oct 2 2009"; int line = 2; char file[] = "u.c"; char time[] = "11:52:51"; int stdc = 1; int stdc_hosted = 1; #define __STDC_HOSTED__ 1 #define __STDC__ 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41540
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #6 from jakub at gcc dot gnu dot org 2009-10-02 18:52 --- Subject: Bug 40521 Author: jakub Date: Fri Oct 2 18:52:15 2009 New Revision: 152414 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152414 Log: PR debug/40521 * configure.ac (HAVE_GAS_CFI_SECTIONS_DIRECTIVE): New test. * configure: Regenerated. * config.in: Regenerated. * dwarf2out.c (dwarf2out_do_cfi_asm): Return false if !HAVE_GAS_CFI_SECTIONS_DIRECTIVE and not emitting .eh_frame. (dwarf2out_init): If HAVE_GAS_CFI_SECTIONS_DIRECTIVE and not emitting .eh_frame, emit .cfi_sections .debug_frame directive. Modified: trunk/gcc/ChangeLog trunk/gcc/config.in trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug target/41551] New: ia64: ICE: in instantiate_virtual_regs_in_insn, at function.c:1630
ICE on ia64 at -O1 and higher, seen with gcc 4.3 and 4.4 but not 4.2.
% gcc -O -c t.c
t.c: In function 'main':
t.c:5:1: error: unrecognizable insn:
(insn 5 4 6 3 t.c:3 (set (reg:DF 344)
(unsigned_float:DF (reg/f:DI 328 sfp))) -1 (nil))
t.c:5:1: internal compiler error: in instantiate_virtual_regs_in_insn, at
function.c:1630
Environment:
System: Linux merulo 2.6.30.4-dsa-mckinley #1 SMP Sat Aug 15 18:22:08 UTC 2009
ia64 GNU/Linux
host: ia64-unknown-linux-gnu
build: ia64-unknown-linux-gnu
target: ia64-unknown-linux-gnu
configured with: ../src/configure -v --with-pkgversion='Debian 20090821-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --disable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --disable-libssp --enable-mpfr --enable-java-awt=gtk
--enable-gtk-cairo --disable-plugin
--with-java-home=/usr/lib/gcc-snapshot/java-1.5.0-gcj-4.5/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/gcc-snapshot/java-1.5.0-gcj-4.5
--with-arch-directory=ia64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --with-system-libunwind --disable-werror
--build=ia64-linux-gnu --host=ia64-linux-gnu --target=ia64-linux-gnu
How-To-Repeat:
% cat t.c
int main(void)
{
int var, *p = &var;
return (double)(unsigned long)(p);
}
--- Comment #1 from ntyni at debian dot org 2009-10-02 19:22 ---
Fix:
downgrade to -O0
--
Summary: ia64: ICE: in instantiate_virtual_regs_in_insn, at
function.c:1630
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ntyni at debian dot org
GCC build triplet: ia64-unknown-linux-gnu
GCC host triplet: ia64-unknown-linux-gnu
GCC target triplet: ia64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41551
[Bug fortran/40996] [F03] ALLOCATABLE scalars
--- Comment #9 from burnus at gcc dot gnu dot org 2009-10-02 19:33 --- Can this be closed as FIXED? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40996
[Bug preprocessor/41543] BUILTINS_LOCATION wrong with -fpreprocessed
--- Comment #1 from manu at gcc dot gnu dot org 2009-10-02 20:36 --- Shouldn't location 0, location 1 and location 2 be reserved and allocated as soon as the line_table is created? I think this was already in my patch moving all location stuff to its own library. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41543
[Bug ada/41383] Timing_Events: Event time not cleared after Cancel_Handler
-- sam at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-02 20:48:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41383
[Bug ada/39944] Incorrect expected file name encoding
--- Comment #2 from sam at gcc dot gnu dot org 2009-10-02 21:04 --- Indeed. Closing as invalid, thanks Pierre-Nicolas. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39944
[Bug target/41551] ia64: ICE: in instantiate_virtual_regs_in_insn, at function.c:1630
--- Comment #2 from jakub at gcc dot gnu dot org 2009-10-02 21:04 ---
Perhaps better don't do something as non-sensical as this.
Anyway, we shouldn't ICE on it.
--- function.c.jj2009-09-29 15:10:43.0 +0200
+++ function.c2009-10-02 23:01:49.0 +0200
@@ -1598,7 +1598,10 @@ instantiate_virtual_regs_in_insn (rtx in
if (!safe_insn_predicate (insn_code, i, x))
{
start_sequence ();
- x = force_reg (insn_data[insn_code].operand[i].mode, x);
+ if (REG_P (x))
+x = copy_to_reg (x);
+ else
+x = force_reg (insn_data[insn_code].operand[i].mode, x);
seq = get_insns ();
end_sequence ();
if (seq)
should fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41551
[Bug ada/9535] Datagram socket semantics are wrong
--- Comment #7 from sam at gcc dot gnu dot org 2009-10-02 21:16 --- The problem is still present in the trunk: datagram based streams are meaningless in most cases. The more I think about it, the more I think they should be removed from GNAT.Sockets completely instead of half-fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9535
[Bug ada/34290] Problem with procedure visibility at the prefixed view call
--- Comment #5 from sam at gcc dot gnu dot org 2009-10-02 21:19 --- Reconfirmed on SVN trunk +===GNAT BUG DETECTED==+ | 4.5.0 20090930 (experimental) (x86_64-unknown-linux-gnu) Assert_Failure exp_disp.adb:1363| | Error detected at main_windows-constructors.adb:10:57| -- sam at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-12-06 19:03:20 |2009-10-02 21:19:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34290
[Bug ada/34290] Problem with procedure visibility at the prefixed view call
-- sam at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|sam at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34290
[Bug ada/35919] Primitive renaming a predefined operation
--- Comment #1 from sam at gcc dot gnu dot org 2009-10-02 21:25 --- Reconfirmed on SVN trunk: GNAT 4.5.0 20090930 (experimental) Copyright 1992-2009, Free Software Foundation, Inc. Compiling: p1.ads (source file time stamp: 2009-10-02 21:23:50) 2.type T1 is tagged null record; | >>> prefix of "Unrestricted_Access" attribute cannot be intrinsic 5 lines: 1 error -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-02 21:25:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35919
[Bug ada/35920] Overriding primitive with a predefined operation renaming
--- Comment #1 from sam at gcc dot gnu dot org 2009-10-02 21:26 --- Reconfirmed on SVN trunk. +===GNAT BUG DETECTED==+ | 4.5.0 20090930 (experimental) (x86_64-unknown-linux-gnu) Program_Error exp_disp.adb:7340 explicit raise| | Error detected at p1.ads:5:50| -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35920
[Bug ada/35920] Overriding primitive with a predefined operation renaming
-- sam at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-02 21:27:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35920
[Bug lto/41547] ICEs in lto_symtab_merge_decl, at lto-symtab.c:577
--- Comment #1 from dnovillo at gcc dot gnu dot org 2009-10-02 21:31 --- Subject: Bug 41547 Author: dnovillo Date: Fri Oct 2 21:31:43 2009 New Revision: 152422 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152422 Log: 2009-10-02 Diego Novillo * sourcebuild.texi: Document lto-plugin. * invoke.texi: Add documentation for -use-linker-plugin and complete documentation for -flto. * install.texi: Document --enable-gold. 2009-10-02 Richard Guenther PR lto/41547 PR lto/41548 * tree.h (is_lang_specific): Include LANG_TYPE. * tree.c (find_decls_types_r): Manually add interesting parts of TYPE_FIELDS. Walk BINFO_VIRTUALS. Do not walk TYPE_METHODS. testsuite/ChangeLog.lto * g++.dg/lto/20091002-1_0.C: New testcase. * g++.dg/lto/20091002-2_0.C: Likewise.. * g++.dg/lto/20091002-3_0.C: Likewise.. 2009-10-02 Diego Novillo * gcc.c-torture/execute/builtins/builtins.exp: Re-enable LTO testing. 2009-10-02 Diego Novillo * lto-symtab.h: Update copyright boilerplate. * plugin-api.h: Likewise. 2009-10-02 Diego Novillo * Makefile.am (AM_CPPFLAGS): Remove -D_LARGEFILE_SOURCE and -D_FILE_OFFSET_BITS=64. * configure.ac: Add AC_SYS_LARGEFILE. * configure: Regenerate. * Makefile.in: Regenerate. * lto-plugin.c: Fix copyright boilerplate. 2009-10-02 Diego Novillo * Makefile.am (ACLOCAL_AMFLAGS): Define. * aclocal.m4: Regenerate with aclocal-2.64 * acinclude.m4: Remove. * Makefile.in: Regenerate with automake-1.11 * configure.ac (AC_PREREQ): Update to 2.64. * configure: Regenerate. Added: branches/lto/gcc/testsuite/g++.dg/lto/20091002-1_0.C branches/lto/gcc/testsuite/g++.dg/lto/20091002-2_0.C branches/lto/gcc/testsuite/g++.dg/lto/20091002-3_0.C Removed: branches/lto/lto-plugin/acinclude.m4 Modified: branches/lto/gcc/ChangeLog.lto branches/lto/gcc/doc/install.texi branches/lto/gcc/doc/invoke.texi branches/lto/gcc/doc/sourcebuild.texi branches/lto/gcc/testsuite/ChangeLog.lto branches/lto/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp branches/lto/gcc/tree.c branches/lto/gcc/tree.h branches/lto/include/ChangeLog.lto branches/lto/include/lto-symtab.h branches/lto/include/plugin-api.h branches/lto/lto-plugin/ChangeLog branches/lto/lto-plugin/Makefile.am branches/lto/lto-plugin/Makefile.in branches/lto/lto-plugin/aclocal.m4 branches/lto/lto-plugin/configure branches/lto/lto-plugin/configure.ac branches/lto/lto-plugin/lto-plugin.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41547
[Bug lto/41548] ICE: tree code 'lang_type' is not supported in gimple streams
--- Comment #1 from dnovillo at gcc dot gnu dot org 2009-10-02 21:31 --- Subject: Bug 41548 Author: dnovillo Date: Fri Oct 2 21:31:43 2009 New Revision: 152422 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152422 Log: 2009-10-02 Diego Novillo * sourcebuild.texi: Document lto-plugin. * invoke.texi: Add documentation for -use-linker-plugin and complete documentation for -flto. * install.texi: Document --enable-gold. 2009-10-02 Richard Guenther PR lto/41547 PR lto/41548 * tree.h (is_lang_specific): Include LANG_TYPE. * tree.c (find_decls_types_r): Manually add interesting parts of TYPE_FIELDS. Walk BINFO_VIRTUALS. Do not walk TYPE_METHODS. testsuite/ChangeLog.lto * g++.dg/lto/20091002-1_0.C: New testcase. * g++.dg/lto/20091002-2_0.C: Likewise.. * g++.dg/lto/20091002-3_0.C: Likewise.. 2009-10-02 Diego Novillo * gcc.c-torture/execute/builtins/builtins.exp: Re-enable LTO testing. 2009-10-02 Diego Novillo * lto-symtab.h: Update copyright boilerplate. * plugin-api.h: Likewise. 2009-10-02 Diego Novillo * Makefile.am (AM_CPPFLAGS): Remove -D_LARGEFILE_SOURCE and -D_FILE_OFFSET_BITS=64. * configure.ac: Add AC_SYS_LARGEFILE. * configure: Regenerate. * Makefile.in: Regenerate. * lto-plugin.c: Fix copyright boilerplate. 2009-10-02 Diego Novillo * Makefile.am (ACLOCAL_AMFLAGS): Define. * aclocal.m4: Regenerate with aclocal-2.64 * acinclude.m4: Remove. * Makefile.in: Regenerate with automake-1.11 * configure.ac (AC_PREREQ): Update to 2.64. * configure: Regenerate. Added: branches/lto/gcc/testsuite/g++.dg/lto/20091002-1_0.C branches/lto/gcc/testsuite/g++.dg/lto/20091002-2_0.C branches/lto/gcc/testsuite/g++.dg/lto/20091002-3_0.C Removed: branches/lto/lto-plugin/acinclude.m4 Modified: branches/lto/gcc/ChangeLog.lto branches/lto/gcc/doc/install.texi branches/lto/gcc/doc/invoke.texi branches/lto/gcc/doc/sourcebuild.texi branches/lto/gcc/testsuite/ChangeLog.lto branches/lto/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp branches/lto/gcc/tree.c branches/lto/gcc/tree.h branches/lto/include/ChangeLog.lto branches/lto/include/lto-symtab.h branches/lto/include/plugin-api.h branches/lto/lto-plugin/ChangeLog branches/lto/lto-plugin/Makefile.am branches/lto/lto-plugin/Makefile.in branches/lto/lto-plugin/aclocal.m4 branches/lto/lto-plugin/configure branches/lto/lto-plugin/configure.ac branches/lto/lto-plugin/lto-plugin.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41548
[Bug ada/37602] Renaming of volatile causes variable access
--- Comment #1 from sam at gcc dot gnu dot org 2009-10-02 21:36 --- Still present in GCC trunk (4.5.0 20090930) -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-02 21:36:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37602
[Bug c++/37775] Templated private class visible through friend declaration
--- Comment #2 from sam at gcc dot gnu dot org 2009-10-02 21:38 --- Reconfirmed on SVN trunk: gcc (GCC) 4.5.0 20090930 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37775
[Bug c++/41313] r150553 causes g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2009-10-02 22:09 --- Jakub, Is there any reason why we can't have... Index: opts.c === --- opts.c (revision 152346) +++ opts.c (working copy) @@ -1039,7 +1039,7 @@ if (flag_exceptions && flag_reorder_blocks_and_partition && (USING_SJLJ_EXCEPTIONS -#ifdef TARGET_UNWIND_INFO +#if defined (TARGET_UNWIND_INFO) || defined (DWARF2_UNWIND_INFO) || 1 #endif )) @@ -1056,7 +1056,7 @@ if (flag_unwind_tables && ! targetm.unwind_tables_default && flag_reorder_blocks_and_partition && (USING_SJLJ_EXCEPTIONS -#ifdef TARGET_UNWIND_INFO +#if defined (TARGET_UNWIND_INFO) || defined (DWARF2_UNWIND_INFO) || 1 #endif )) @@ -1075,7 +1075,7 @@ && (!targetm.have_named_sections || (flag_unwind_tables && targetm.unwind_tables_default && (USING_SJLJ_EXCEPTIONS -#ifdef TARGET_UNWIND_INFO +#if defined (TARGET_UNWIND_INFO) || defined (DWARF2_UNWIND_INFO) || 1 #endif I suspect this should unbreak darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41313
[Bug lto/41547] ICEs in lto_symtab_merge_decl, at lto-symtab.c:577
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-02 22:18 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41547
[Bug lto/41548] ICE: tree code 'lang_type' is not supported in gimple streams
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-02 22:19 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41548
[Bug fortran/40996] [F03] ALLOCATABLE scalars
--- Comment #10 from janus at gcc dot gnu dot org 2009-10-02 22:24 --- (In reply to comment #9) > Can this be closed as FIXED? I think so. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40996
[Bug target/41081] redundant ZERO_EXTENDs
--- Comment #13 from bergner at gcc dot gnu dot org 2009-10-03 01:39 --- Subject: Bug 41081 Author: bergner Date: Sat Oct 3 01:39:14 2009 New Revision: 152430 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152430 Log: Backport from mainline. 2009-08-30 Alan Modra PR target/41081 * fwprop.c (get_reg_use_in): Delete. (free_load_extend): New function. (forward_propagate_subreg): Use it. 2009-08-23 Alan Modra PR target/41081 * fwprop.c (try_fwprop_subst): Allow multiple sets. (get_reg_use_in): New function. (forward_propagate_subreg): Propagate through subreg of zero_extend or sign_extend. 2009-05-08 Paolo Bonzini PR rtl-optimization/33928 PR 26854 * fwprop.c (use_def_ref, get_def_for_use, bitmap_only_bit_bitween, process_uses, build_single_def_use_links): New. (update_df): Update use_def_ref. (forward_propagate_into): Use get_def_for_use instead of use-def chains. (fwprop_init): Call build_single_def_use_links and let it initialize dataflow. (fwprop_done): Free use_def_ref. (fwprop_addr): Eliminate duplicate call to df_set_flags. * df-problems.c (df_rd_simulate_artificial_defs_at_top, df_rd_simulate_one_insn): New. (df_rd_bb_local_compute_process_def): Update head comment. (df_chain_create_bb): Use the new RD simulation functions. * df.h (df_rd_simulate_artificial_defs_at_top, df_rd_simulate_one_insn): New. * opts.c (decode_options): Enable fwprop at -O1. * doc/invoke.texi (-fforward-propagate): Document this. Modified: branches/ibm/gcc-4_3-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_3-branch/gcc/REVISION branches/ibm/gcc-4_3-branch/gcc/df-problems.c branches/ibm/gcc-4_3-branch/gcc/df.h branches/ibm/gcc-4_3-branch/gcc/doc/invoke.texi branches/ibm/gcc-4_3-branch/gcc/fwprop.c branches/ibm/gcc-4_3-branch/gcc/opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41081
[Bug tree-optimization/26854] [4.3/4.4/4.5 Regression] Inordinate compile times on large routines
--- Comment #111 from bergner at gcc dot gnu dot org 2009-10-03 01:39 --- Subject: Bug 26854 Author: bergner Date: Sat Oct 3 01:39:14 2009 New Revision: 152430 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152430 Log: Backport from mainline. 2009-08-30 Alan Modra PR target/41081 * fwprop.c (get_reg_use_in): Delete. (free_load_extend): New function. (forward_propagate_subreg): Use it. 2009-08-23 Alan Modra PR target/41081 * fwprop.c (try_fwprop_subst): Allow multiple sets. (get_reg_use_in): New function. (forward_propagate_subreg): Propagate through subreg of zero_extend or sign_extend. 2009-05-08 Paolo Bonzini PR rtl-optimization/33928 PR 26854 * fwprop.c (use_def_ref, get_def_for_use, bitmap_only_bit_bitween, process_uses, build_single_def_use_links): New. (update_df): Update use_def_ref. (forward_propagate_into): Use get_def_for_use instead of use-def chains. (fwprop_init): Call build_single_def_use_links and let it initialize dataflow. (fwprop_done): Free use_def_ref. (fwprop_addr): Eliminate duplicate call to df_set_flags. * df-problems.c (df_rd_simulate_artificial_defs_at_top, df_rd_simulate_one_insn): New. (df_rd_bb_local_compute_process_def): Update head comment. (df_chain_create_bb): Use the new RD simulation functions. * df.h (df_rd_simulate_artificial_defs_at_top, df_rd_simulate_one_insn): New. * opts.c (decode_options): Enable fwprop at -O1. * doc/invoke.texi (-fforward-propagate): Document this. Modified: branches/ibm/gcc-4_3-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_3-branch/gcc/REVISION branches/ibm/gcc-4_3-branch/gcc/df-problems.c branches/ibm/gcc-4_3-branch/gcc/df.h branches/ibm/gcc-4_3-branch/gcc/doc/invoke.texi branches/ibm/gcc-4_3-branch/gcc/fwprop.c branches/ibm/gcc-4_3-branch/gcc/opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #112 from bergner at gcc dot gnu dot org 2009-10-03 01:39 --- Subject: Bug 33928 Author: bergner Date: Sat Oct 3 01:39:14 2009 New Revision: 152430 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152430 Log: Backport from mainline. 2009-08-30 Alan Modra PR target/41081 * fwprop.c (get_reg_use_in): Delete. (free_load_extend): New function. (forward_propagate_subreg): Use it. 2009-08-23 Alan Modra PR target/41081 * fwprop.c (try_fwprop_subst): Allow multiple sets. (get_reg_use_in): New function. (forward_propagate_subreg): Propagate through subreg of zero_extend or sign_extend. 2009-05-08 Paolo Bonzini PR rtl-optimization/33928 PR 26854 * fwprop.c (use_def_ref, get_def_for_use, bitmap_only_bit_bitween, process_uses, build_single_def_use_links): New. (update_df): Update use_def_ref. (forward_propagate_into): Use get_def_for_use instead of use-def chains. (fwprop_init): Call build_single_def_use_links and let it initialize dataflow. (fwprop_done): Free use_def_ref. (fwprop_addr): Eliminate duplicate call to df_set_flags. * df-problems.c (df_rd_simulate_artificial_defs_at_top, df_rd_simulate_one_insn): New. (df_rd_bb_local_compute_process_def): Update head comment. (df_chain_create_bb): Use the new RD simulation functions. * df.h (df_rd_simulate_artificial_defs_at_top, df_rd_simulate_one_insn): New. * opts.c (decode_options): Enable fwprop at -O1. * doc/invoke.texi (-fforward-propagate): Document this. Modified: branches/ibm/gcc-4_3-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_3-branch/gcc/REVISION branches/ibm/gcc-4_3-branch/gcc/df-problems.c branches/ibm/gcc-4_3-branch/gcc/df.h branches/ibm/gcc-4_3-branch/gcc/doc/invoke.texi branches/ibm/gcc-4_3-branch/gcc/fwprop.c branches/ibm/gcc-4_3-branch/gcc/opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug rtl-optimization/41511] [4.5 Regression] combine behaves differently with/without -g
--- Comment #4 from kkojima at gcc dot gnu dot org 2009-10-03 04:00 --- With the patch, native sh4-linux stage2 compiler generates the same codes with and without -g for cfgexpand.c/omp-low.c. I believe that it restores the bootstrap on sh. Thanks for taking a look at this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41511
