Graphite TODO tasks
Greetings! I would like to know if there are any TODO tasks that I can work on to get started with Graphite/GCC. I came across Tobias Grosser's post regarding Graphite development at: http://gcc.gnu.org/wiki/Graphite-4.8 If you have any suggestions, please do let me know. Thanks! SK -- Shakthi Kannan http://www.shakthimaan.com
Re: Graphite TODO tasks
On Tue, Jan 01, 2013 at 03:23:06PM +0530, Shakthi Kannan wrote:
Greetings!
I would like to know if there are any TODO tasks that I can work on to
get started with Graphite/GCC. I came across Tobias Grosser's post
regarding Graphite development at:
http://gcc.gnu.org/wiki/Graphite-4.8
In addition of that list, I would suggest adding plugin support hooks into
graphite.
For instance, it is currently not really possible to make the Graphite-OpenCL
hack
as a plugin to GCC 4.8 (or the next GCC), because
(that was at least true more than a year ago, when I looked in details):
* some internal data are not GTY-ed inside graphite. It is quite important
for plugins
that the data they manipulate is properly GTY-ed and handled by Ggc
(and deleted only by the Ggc, so that plugin passes could manipulate them
easily,
share them between several passes, etc).
* there is no plugin hooks at all in graphite, even for simple things like
dealing
with induction variables, SCOP, etc... A lot of information computed by
graphite
passes could be useful to plugins.
As a general hint, my suggestion would be to improve Graphite till the
Graphite-OpenCL hack
could be coded as a GCC plugin. (I don't think that Graphite-OpenCL should be a
core feature
of GCC, I do think it is a typical use case for plugins, but the current
Graphite infrastructure
does not allow that because of nasty details. Today, to make Grahpite-OpenCL as
a plugin,
one have to copy-paste the code of Graphite passes, patche them as
Graphite-OpenCL did,
and replace the core Graphite passes with their Graphite-OpenCL improvement;
this is messy, error-prone, ugly; it would be better if Graphite gave enough
plugin hooks to avoid that).
If you add plugin abilities to Graphite passes, please document that!
Happy new year 2013 to everyone.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Deprecate i386 for GCC 4.8?
On 12/12/2012 01:07 PM, David Brown wrote: I believe it has been a very long time since any manufacturers made a pure 386 chip. I believe embedded 386 production ceased in 2007. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
[Bug tree-optimization/55838] New: ICE in extract_insn (unrecognizable insn) with -O -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838
Bug #: 55838
Summary: ICE in extract_insn (unrecognizable insn) with -O
-funroll-loops
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antoine.balest...@gmail.com
Hi ! This very simple testcase makes GCC 4.8.0 as of 20121231 (and 4.7.2 as
well) crash with -O -funroll-loops.
I hope this is not a dup.
$ cat insn.c
int a;
unsigned char c;
void f(void)
{
while(c++ 2)
c = a += 129;
}
$ xgcc -O -funroll-loops -w insn.c
insn.c: In function ‘f’:
insn.c:8:1: error: unrecognizable insn:
}
^
(insn 93 92 94 3 (set (reg:QI 127)
(const_int 129 [0x81])) -1
(nil))
insn.c:8:1: internal compiler error: in extract_insn, at recog.c:2152
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
I wish you a happy new year !
[Bug rtl-optimization/55838] ICE in extract_insn (unrecognizable insn) with -O -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* i?86-*-* Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Last reconfirmed||2013-01-01 Component|tree-optimization |rtl-optimization Ever Confirmed|0 |1 Known to fail||4.3.5, 4.4.5, 4.7.2, 4.8.0 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-01 11:07:40 UTC --- Confirmed. Maybe a regression but I don't have any version before 4,3,5 installed. t88.c:8:1: internal compiler error: in extract_insn, at recog.c:2152 0x88987a _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc/rtl-error.c:110 0x8898a9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../gcc/rtl-error.c:118 0x85feda extract_insn(rtx_def*) ../../gcc/recog.c:2152 0xb0cd47 union_match_dups ../../gcc/web.c:102 0xb0cd47 web_main ../../gcc/web.c:380 Please submit a full bug report,
[Bug rtl-optimization/55838] ICE in extract_insn (unrecognizable insn) with -O -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-01-01 11:21:05 UTC --- ICEs 4.7.2 and 4.6.3 as described in comment #1. ICEs 4.5.4 down to 4.0.4 with: pr55838.c: In function 'f': pr55838.c:8:1: internal compiler error: in do_SUBST, at combine.c:681 Older releases (3.4.6, 3.3.6, 3.2.3, 2.95.3) don't ICE.
[Bug rtl-optimization/55838] [4.6/4.7/4.8 Regression] ICE in extract_insn (unrecognizable insn) with -O -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Known to work||3.4.6 Target Milestone|--- |4.6.4 Summary|ICE in extract_insn |[4.6/4.7/4.8 Regression] |(unrecognizable insn) with |ICE in extract_insn |-O -funroll-loops |(unrecognizable insn) with ||-O -funroll-loops
[Bug tree-optimization/55831] [4.8 Regression] ICE: verify_flow_info failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55831 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-01 13:59:00 UTC --- Fixed.
[Bug fortran/55763] Issues with some simpler CLASS(*) programs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55763 --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2013-01-01 14:09:09 UTC --- (In reply to comment #10) I have a simple case where CLASS(*) leads to an ICE. If it doesn't fit here, please feel free to move it elsewhere. The segfault occurs for comp == _extends in gfc_default_initializer. The problem is that comp-ts.type is BT_CLASS, which is not handled. As one has CLASS(*), ts.u.derived == NULL, which breaks the following check: if (comp-attr.allocatable || (comp-ts.type == BT_CLASS CLASS_DATA (comp)-attr.allocatable)) From class.c's gfc_find_intrinsic_vtab if (gfc_add_component (vtype, _extends, c) == FAILURE) ... /* Avoid segfaults because due to character length. */ c-ts.type = ts-type == BT_CHARACTER ? BT_VOID : ts-type; c-ts.kind = ts-kind; Thus, either BT_CLASS shouldn't be used - or ts.u.derived has to be used. By the way, class.c's gfc_find_derived_vtab uses the following if there is no parent - or for unlimited polymorphic: c-ts.type = BT_DERIVED; c-ts.u.derived = vtype; c-initializer = gfc_get_null_expr (NULL);
[Bug fortran/55789] [4.6/4.7/4.8 Regression] Needless realloc with array constructor.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55789 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Target Milestone|--- |4.6.4 Summary|Needless realloc|[4.6/4.7/4.8 Regression] ||Needless realloc with array ||constructor. --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-01 14:25:27 UTC --- Looks like a regression, then.
[Bug fortran/55839] New: Inefficiency with array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55839 Bug #: 55839 Summary: Inefficiency with array constructor Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org This idiom subroutine foo(a,b,c,n) integer, intent(in) :: n real, intent(in), dimension(n) :: a,b real, intent(out), dimension(2*n) :: c c(1:2*n) = [a(1:n), b(1:n)] end subroutine foo builds an array using malloc and copies the data two times. It would be better to express this as c(1:n) = a(1:n) c(n+1:2*n) = b(1:n) Looks like a job for front-end optimization; it would be a bit hard to expect the middle-end to optimize away all the calls to malloc etc.
[Bug objc/55840] New: valgrind errors in sparseset.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55840 Bug #: 55840 Summary: valgrind errors in sparseset.h Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org Created attachment 29068 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29068 valgrind errors from test case in initial comment Compiling the following test case with COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Ziel: x86_64-unknown-linux-gnu Konfiguriert mit: ../trunk/configure --prefix=/home/ig25 --enable-languages=c,fortran --with-mpfr=/usr/local --with-gmp=/usr/local --with-mpc=/usr/local Thread-Modell: posix gcc-Version 4.8.0 20121231 (experimental) (GCC) module m_task implicit none private public tad_elemen, gele, vecino ! integer, parameter :: ngl = 3, nca = 4 ! integer, dimension (nca) :: koe, koi, koj integer, dimension (2*nca) :: coe, coi, coj ! type tad_elemen integer, dimension (nca) :: iele end type tad_elemen type (tad_elemen), dimension (:), pointer :: gele ! contains ! subroutine vecino (gele) type (tad_elemen), dimension (:), intent (inout) :: gele call troubletask (gele) end subroutine vecino ! subroutine troubletask (gele) type (tad_elemen), dimension (:), intent (in):: gele integer :: nel, nci, ncj integer :: l1, l2, h1, h2 integer :: lado, i, j ! nel = size (gele,dim=1) do i = 1, (nel - 1) koi = gele (i) % iele (1:nca) nci = count (koi0) coi (1:2*nci) = [ koi(1:nci) , koi(1:nci) ] do j = (i+1), nel koj = gele (j) % iele (1:nca) ncj = count (koj 0) coj (1:2*ncj) = [ koj(1:ncj), koj(1:ncj) ] lado = 0 ! !problematic loops do h1 = 1, nci if (coi (h1) 1) cycle ! ICE if both are uncommented l1 = h1 + 1 do h2 = 1, ncj if (coj (h2) 1) cycle ! ICE if both are uncommented l2 = h2 + 1 if (coi (h1) == coj (l2) .and. coi (l1) == coj (h2)) then lado = 1 exit end if end do ! h1 if (lado == 1) exit end do ! h2 ! end do ! j end do ! i ! end subroutine troubletask ! end module m_task ! program test use m_task implicit none print *, trace 1 allocate (gele(10)) call vecino (gele) print *, trace 2 end program gets a lot of valgrind errors in sparseset.h, which are attached. A few samples: static-varAssembling functions: vecino==6337== Conditional jump or move depends on uninitialised value(s) ==6337==at 0xD70C6B: register_active_defs(df_ref_d**) (sparseset.h:147) ==6337==by 0xD70D02: _ZL14update_df_initP7rtx_defS0_.isra.15 (fwprop.c:895) ==6337==by 0xD71F1E: try_fwprop_subst(df_ref_d*, rtx_def**, rtx_def*, rtx_def*, bool) (fwprop.c:963) ==6337==by 0xD72388: forward_propagate_into(df_ref_d*) (fwprop.c:1337) ==6337==by 0xD728C7: fwprop() (fwprop.c:1474) ==6337==by 0x8C6D17: execute_one_pass(opt_pass*) (passes.c:2335) ==6337==by 0x8C7124: execute_pass_list(opt_pass*) (passes.c:2383) ==6337==by 0x8C7136: execute_pass_list(opt_pass*) (passes.c:2384) ==6337==by 0x696791: expand_function(cgraph_node*) (cgraphunit.c:1641) ==6337==by 0x698556: compile() (cgraphunit.c:1745) ==6337==by 0x698BF9: finalize_compilation_unit() (cgraphunit.c:2120) ==6337==by 0x861550: write_global_declarations() (langhooks.c:323) ==6337== ==6337== Use of uninitialised value of size 8 ==6337==at 0xD70C70: register_active_defs(df_ref_d**) (sparseset.h:147) ==6337==by 0xD70D02: _ZL14update_df_initP7rtx_defS0_.isra.15 (fwprop.c:895) ==6337==by 0xD71F1E: try_fwprop_subst(df_ref_d*, rtx_def**, rtx_def*, rtx_def*, bool) (fwprop.c:963) ==6337==by 0xD72388: forward_propagate_into(df_ref_d*) (fwprop.c:1337) ==6337==by 0xD728C7: fwprop() (fwprop.c:1474) ==6337==by 0x8C6D17: execute_one_pass(opt_pass*) (passes.c:2335) ==6337==by 0x8C7124: execute_pass_list(opt_pass*) (passes.c:2383) ==6337==by 0x8C7136: execute_pass_list(opt_pass*) (passes.c:2384) ==6337==by 0x696791: expand_function(cgraph_node*) (cgraphunit.c:1641) ==6337==by 0x698556: compile() (cgraphunit.c:1745) ==6337==by 0x698BF9: finalize_compilation_unit() (cgraphunit.c:2120) ==6337==by 0x861550: write_global_declarations() (langhooks.c:323)
[Bug other/55840] valgrind errors in sparseset.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55840 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Component|objc|other --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-01 15:02:43 UTC --- Reassigning to correct component.
[Bug libstdc++/55841] New: Unexpected behavior from STL's queue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55841
Bug #: 55841
Summary: Unexpected behavior from STL's queue
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: n...@math.technion.ac.il
Apparently, when a std::queue is empty, front() returns some bizarre output (a
zeroed object?), and pop() breaks the queue by making its size -1... For
example, this code, which pushes only one object on the queue, and pops 3,
gives the following output::
#include queue
#include iostream
main(){
std::queueint q;
q.push(2);
std::cerr size: q.size() '\n';
std::cerr popping element: q.front() '\n';
q.pop();
std::cerr size: q.size() '\n';
std::cerr popping element: q.front() '\n';
q.pop();
std::cerr size: q.size() '\n';
std::cerr popping element: q.front() '\n';
q.pop();
}
Gives the following output:
size: 1
popping element: 2
size: 0
popping element: 0
size: 18446744073709551615
popping element: 0
Why doesn't front() throw an exception when there's no element?
And why does pop() break the queue?
If I understand correctly, the standard doesn't define what to do in this case
(I don't understand why), but even so, libstdc++ can do something sensible in
this case...
Sure, I can always check empty() before calling front() or pop(), but isn't
that very anti-C++-like, as exceptions were invented exactly so that code
doesn't need to be littered with sanity checks like this, and rare cases of
insanity cause exceptions?
[Bug libgcc/55835] [TileGX] libgcc doesn't build.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55835 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-01-01 15:41:22 UTC --- You of course need target C library headers for building libgcc.
[Bug fortran/55818] Reading a REAL from a file which doesn't end in a new line fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55818 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2013-01-01 16:00:18 UTC --- (In reply to comment #6) I have submitted a revised patch for review that addresses character and complex. Namely, http://gcc.gnu.org/ml/fortran/2012-12/msg00197.html I think that this patch is OK, except that INF/INFINITY/NAN/NAN(0x123) does seem to suffer from similar issue.
[Bug c++/55842] New: C++11 ICE with boost multi-precision and boost variant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55842 Bug #: 55842 Summary: C++11 ICE with boost multi-precision and boost variant Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ko...@xs4all.nl Compiling the attached sample file leads to an internal compiler error. The problem only occurs with GCC-4.7 from Debian Unstable 4.7.2-1 and the upcoming 4.8 from Debian Experimental 4.8-20121218-1. Tested on an amd64 system. I'm using a checkout of the latest boost release tree. The command to reproduce the issue is: gcc-4.8 -std=c++11 -c -I/src/boost/release test.cpp This results in the following output: In file included from /src/boost/release/boost/config.hpp:57:0, from /src/boost/release/boost/variant/detail/config.hpp:16, from /src/boost/release/boost/variant/variant.hpp:23, from /src/boost/release/boost/variant.hpp:17, from test.cpp:2: /src/boost/release/boost/type_traits/has_nothrow_constructor.hpp: In instantiation of 'const bool boost::detail::has_nothrow_constructor_impboost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u ::value': /src/boost/release/boost/type_traits/has_nothrow_constructor.hpp:32:1: required from 'struct boost::has_nothrow_constructorboost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u ' /src/boost/release/boost/mpl/aux_/nested_type_wknd.hpp:26:31: required from 'struct boost::mpl::aux::nested_type_wkndboost::has_nothrow_constructorboost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u ' /src/boost/release/boost/mpl/not.hpp:39:8: required from 'struct boost::mpl::not_boost::has_nothrow_constructorboost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u ' /src/boost/release/boost/mpl/aux_/nested_type_wknd.hpp:26:31: required from 'struct boost::mpl::aux::nested_type_wkndboost::mpl::apply1boost::mpl::protectboost::detail::variant::find_fallback_type_pred, boost::mpl::l_iterboost::mpl::l_itemmpl_::long_1l, boost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u , boost::mpl::l_end ' /src/boost/release/boost/mpl/aux_/preprocessed/gcc/and.hpp:23:8: required from 'struct boost::mpl::aux::and_impltrue, boost::mpl::apply1boost::mpl::protectboost::detail::variant::find_fallback_type_pred, boost::mpl::l_iterboost::mpl::l_itemmpl_::long_1l, boost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u , boost::mpl::l_end , mpl_::bool_true, mpl_::bool_true, mpl_::bool_true ' /src/boost/release/boost/mpl/aux_/preprocessed/gcc/and.hpp:48:8: [ skipping 5 instantiation contexts, use -ftemplate-backtrace-limit=0 to disable ] /src/boost/release/boost/mpl/aux_/preprocessed/gcc/iter_fold_if_impl.hpp:101:135: required from 'struct boost::mpl::aux::iter_fold_if_implboost::mpl::l_iterboost::mpl::l_itemmpl_::long_1l, boost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u , boost::mpl::l_end , mpl_::int_0, boost::mpl::protectboost::mpl::nextmpl_::na , boost::mpl::protectboost::mpl::aux::iter_fold_if_predboost::mpl::protectboost::detail::variant::find_fallback_type_pred, boost::mpl::l_iterboost::mpl::l_end , 0, mpl_::na, boost::mpl::alwaysmpl_::bool_false ' /src/boost/release/boost/mpl/iter_fold_if.hpp:81:12: required from 'struct boost::mpl::iter_fold_ifboost::mpl::l_itemmpl_::long_1l, boost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u , boost::mpl::l_end, mpl_::int_0, boost::mpl::protectboost::mpl::nextmpl_::na , boost::mpl::protectboost::detail::variant::find_fallback_type_pred, mpl_::na, mpl_::na::result_' /src/boost/release/boost/mpl/iter_fold_if.hpp:104:11: required from 'struct boost::mpl::iter_fold_ifboost::mpl::l_itemmpl_::long_1l, boost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u , boost::mpl::l_end, mpl_::int_0, boost::mpl::protectboost::mpl::nextmpl_::na , boost::mpl::protectboost::detail::variant::find_fallback_type_pred, mpl_::na, mpl_::na' /src/boost/release/boost/variant/variant.hpp:189:17: required from 'struct boost::detail::variant::find_fallback_typeboost::mpl::l_itemmpl_::long_1l, boost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u , boost::mpl::l_end ' /src/boost/release/boost/variant/variant.hpp:1271:17: required from 'class boost::variantboost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u ' test.cpp:10:27: required from here /src/boost/release/boost/type_traits/has_nothrow_constructor.hpp:24:32: internal compiler error: in
[Bug c++/55842] C++11 ICE with boost multi-precision and boost variant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55842 --- Comment #1 from koraq at xs4all dot nl 2013-01-01 16:09:52 UTC --- Created attachment 29069 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29069 Preprocessed source The attachment failed the first time (compressed else it is too large).
[Bug c++/55842] C++11 ICE with boost multi-precision and boost variant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55842 --- Comment #2 from koraq at xs4all dot nl 2013-01-01 16:11:08 UTC --- Created attachment 29070 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29070 Sample code to reproduce the problem
[Bug other/55536] libbacktrace abort in backtrace_alloc at mmap.c:99 running btest
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55536 --- Comment #2 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2013-01-01 16:13:30 UTC --- Author: ian Date: Tue Jan 1 16:13:20 2013 New Revision: 194768 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194768 Log: PR other/55536 * mmap.c (backtrace_alloc): Don't call sync functions if not threaded. (backtrace_free): Likewise. Modified: trunk/libbacktrace/ChangeLog trunk/libbacktrace/mmap.c
[Bug other/55536] libbacktrace abort in backtrace_alloc at mmap.c:99 running btest
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55536 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Ian Lance Taylor ian at airs dot com 2013-01-01 16:15:37 UTC --- Should be fixed.
[Bug bootstrap/54834] bootstrap fails when building libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54834 --- Comment #8 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2013-01-01 16:23:11 UTC --- Author: ian Date: Tue Jan 1 16:23:03 2013 New Revision: 194770 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194770 Log: PR bootstrap/54834 * Makefile.am (AM_CPPFLAGS): Remove -I ../gcc/include and -I $(MULTIBUILDTOP)/../../gcc/include. * Makefile.in: Rebuild. Modified: trunk/libbacktrace/ChangeLog trunk/libbacktrace/Makefile.am trunk/libbacktrace/Makefile.in
[Bug bootstrap/54834] bootstrap fails when building libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54834 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #9 from Ian Lance Taylor ian at airs dot com 2013-01-01 16:23:54 UTC --- Should be fixed.
[Bug middle-end/55808] excessive memory usage from gcc 4.7.2 when compiling mame source code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55808 --- Comment #6 from Patrick mister.freeman at laposte dot net 2013-01-01 16:24:05 UTC --- Created attachment 29071 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29071 the preprocessed source when gcc fails to compile mame here is the preprocessed source when gcc 4.7.2 fails to compile mame, output : gcc: erreur interne du compilateur: Processus arrêté (program cc1plus) Veuillez soumettre un rapport complet d'anomalies, avec le source pré-traité si nécessaire. Consultez https://bugs.archlinux.org/ pour plus de détail. make: *** [obj/sdl/emu/cpu/tms57002/tms57002.o] Erreur 4 CFLAGS : -save-temps -pipe -O3 -Werror -fno-strict-aliasing -Wall -Wcast-align -Wundef -Wformat-security -Wwrite-strings -Wno-sign-compare -Wno-conversion -Wno-narrowing -Wno-attributes -D_GNU_SOURCE=1 -D_REENTRANT -pthread -pthread -Isrc/mame -Iobj/sdl/mame/layout -Isrc/emu -Iobj/sdl/emu -Iobj/sdl/emu/layout -Isrc/lib/util -Isrc/lib -Isrc/osd -Isrc/osd/sdl -Isrc/lib/expat -Isrc/lib/zlib -Isrc/lib/util -Isrc/lib/libjpeg -Isrc/debug -include src/osd/sdl/sdlprefix.h -I/usr/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/harfbuzz -I/usr/include/gconf/2 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/X11/include -I/usr/X11R6/include -I/usr/openwin/include -x c++ -std=gnu++98 -Woverloaded-virtual the problem seems to be related to low memory ( 1 Gb ram, 512 Mb swap )
[Bug other/54800] libiberty/simple-object-mach-o.c:704: possible optimisation ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54800 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added CC||ian at airs dot com --- Comment #2 from Ian Lance Taylor ian at airs dot com 2013-01-01 16:34:09 UTC --- I think the correct patch is the following, but I have no way to test it. Index: simple-object-mach-o.c === --- simple-object-mach-o.c(revision 194764) +++ simple-object-mach-o.c(working copy) @@ -701,12 +701,13 @@ simple_object_mach_o_segment (simple_obj /* Otherwise, make a name like __segment,__section as per the convention in mach-o asm. */ name = namebuf[0]; - memset (namebuf, 0, MACH_O_NAME_LEN * 2 + 2); memcpy (namebuf, (char *) sechdr + segname_offset, MACH_O_NAME_LEN); + namebuf[MACH_O_NAME_LEN] = '\0'; l = strlen (namebuf); namebuf[l] = ','; memcpy (namebuf + l + 1, (char *) sechdr + sectname_offset, MACH_O_NAME_LEN); + namebuf[l + 1 + MACH_O_NAME_LEN] = '\0'; } simple_object_mach_o_section_info (omr-is_big_endian, is_32, sechdr,
[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #28 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2013-01-01 17:13:39 UTC ---
(In reply to comment #26)
For config/linux/ptrlock the changes are:
[...]
Following your suggestions, I applied the following patch (mistakes are mine),
which allows me to run without warnings from libgomp:
Index: config/linux/wait.h
===
--- config/linux/wait.h (revision 194730)
+++ config/linux/wait.h (working copy)
@@ -51,7 +51,7 @@
if (__builtin_expect (gomp_managed_threads gomp_available_cpus, 0))
count = gomp_throttled_spin_count_var;
for (i = 0; i count; i++)
-if (__builtin_expect (*addr != val, 0))
+if (__builtin_expect (__atomic_load_n(addr,MEMMODEL_RELAXED) != val, 0))
return 0;
else
cpu_relax ();
Index: config/linux/ptrlock.c
===
--- config/linux/ptrlock.c (revision 194730)
+++ config/linux/ptrlock.c (working copy)
@@ -50,9 +50,9 @@
#endif
do
do_wait (intptr, 2);
- while (*intptr == 2);
+ while (__atomic_load_n(intptr, MEMMODEL_RELAXED) == 2);
__asm volatile ( : : : memory);
- return *ptrlock;
+ return (void*)__atomic_load_n(ptrlock, MEMMODEL_ACQUIRE);
}
void
Index: config/linux/ptrlock.h
===
--- config/linux/ptrlock.h (revision 194730)
+++ config/linux/ptrlock.h (working copy)
@@ -48,8 +48,9 @@
{
uintptr_t oldval;
- if ((uintptr_t) *ptrlock 2)
-return *ptrlock;
+ uintptr_t v = (uintptr_t)__atomic_load_n(ptrlock, MEMMODEL_ACQUIRE);
+ if (v 2)
+return (void*)v;
oldval = 0;
if (__atomic_compare_exchange_n (ptrlock, oldval, 1, false,
[Bug c++/48914] #pragma GCC diagnostic ignored -Wc++0x-compat doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48914 Roger Jarrett rjarrett at mathworks dot com changed: What|Removed |Added CC||rjarrett at mathworks dot ||com --- Comment #6 from Roger Jarrett rjarrett at mathworks dot com 2013-01-01 18:04:49 UTC --- Confirmed present in GCC 4.7.1 g++ foo.cpp -Wall -std=c++98 our use case is that we have a code base in transition to C++0x and have created our own nullptr_t for the platform that have not yet transitioned to C++0x we would like to acknowledge/suppress this warning in the file that implements the nullptr_t without resorting to -Wno-c++0x-compat on the commmand line. --Roger
[Bug rtl-optimization/55838] [4.6/4.7/4.8 Regression] ICE in extract_insn (unrecognizable insn) with -O -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2013-01-01 18:06:37 UTC --- (const_int 129 [0x81]) isn't considered as a valid const int for QImode.
[Bug c++/55842] C++11 ICE with boost multi-precision and boost variant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55842
--- Comment #3 from Marc Glisse glisse at gcc dot gnu.org 2013-01-01 18:30:52
UTC ---
template class=void struct number {
number() noexcept(noexcept(0)) { }
};
const int z=__has_nothrow_constructor(number);
[Bug rtl-optimization/55838] [4.6/4.7/4.8 Regression] ICE in extract_insn (unrecognizable insn) with -O -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2013-01-01 18:53:32 UTC --- The original regression was introduced by http://gcc.gnu.org/ml/gcc-cvs/2004-05/msg00653.html
[Bug fortran/55839] Inefficiency with array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55839 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #1 from Mikael Morin mikael at gcc dot gnu.org 2013-01-01 19:03:22 UTC --- This is a known deficiency of the handling of array constructors in gfortran. There are other bugs about them. For cases like: a(:) = [b(:)] the code generated does twice as much work as needed (initialization of the array constructor's content and copy from it).
[Bug fortran/55827] ICE with multiple fortran modules and character lenght determined by an interfaced pure function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55827 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |mikael at gcc dot gnu.org |gnu.org | --- Comment #7 from Mikael Morin mikael at gcc dot gnu.org 2013-01-01 19:14:17 UTC --- (In reply to comment #5) Although I agree with Mikael that gfortran should probably not have a NULL symtree by the time we reach gfc_conv_function_expr, the above patch regression tests cleanly. I will submit something inspired by your comment #2. It looks rock solid.
[Bug rtl-optimization/55838] [4.6/4.7/4.8 Regression] ICE in extract_insn (unrecognizable insn) with -O -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||steven at gcc dot gnu.org AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org | --- Comment #5 from Steven Bosscher steven at gcc dot gnu.org 2013-01-01 19:31:57 UTC --- Having a look...
[Bug rtl-optimization/55838] [4.6/4.7/4.8 Regression] ICE in extract_insn (unrecognizable insn) with -O -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838 --- Comment #6 from Steven Bosscher steven at gcc dot gnu.org 2013-01-01 19:51:12 UTC --- The nonsense set comes from force_operand: Breakpoint 7, unroll_loop_runtime_iterations (loop=0x76b46f68) at ../../trunk/gcc/loop-unroll.c:1041 1041 start_sequence (); (gdb) next 1042 old_niter = niter = gen_reg_rtx (desc-mode); (gdb) 1043 tmp = force_operand (copy_rtx (desc-niter_expr), niter); (gdb) p debug_rtx(niter) (reg:QI 124) $31 = void (gdb) next 1044 if (tmp != niter) (gdb) p debug_rtx_list (get_last_insn(), -99) (insn 91 0 92 (set (reg:QI 126) (const_int -126 [0xff82])) -1 (nil)) (insn 92 91 93 (parallel [ (set (reg:QI 125) (minus:QI (reg:QI 126) (subreg:QI (reg:SI 113 [ ivtmp.14 ]) 0))) (clobber (reg:CC 17 flags)) ]) -1 (nil)) (insn 93 92 94 (set (reg:QI 127) (const_int 129 [0x81])) -1 (nil)) (insn 94 93 95 (set (reg:CC 17 flags) (compare:CC (reg:QI 125) (reg:QI 127))) -1 (nil)) (insn 95 94 0 (set (reg:QI 128) (geu:QI (reg:CC 17 flags) (const_int 0 [0]))) -1 (expr_list:REG_EQUAL (udiv:QI (reg:QI 125) (const_int 129 [0x81])) (nil))) $32 = void (gdb)
[Bug rtl-optimization/55838] [4.6/4.7/4.8 Regression] ICE in extract_insn (unrecognizable insn) with -O -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838 --- Comment #7 from Steven Bosscher steven at gcc dot gnu.org 2013-01-01 19:52:48 UTC --- ... but actually it looks like it exists even before that: (gdb) p debug_rtx(desc-niter_expr) (udiv:QI (minus:QI (const_int -126 [0xff82]) (subreg:QI (reg:SI 113 [ ivtmp.14 ]) 0)) (const_int 129 [0x81])) That's a nonsense QImode udiv from loop-iv.
[Bug libstdc++/55841] Unexpected behavior from STL's queue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55841 Chris Jefferson chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot ||net --- Comment #1 from Chris Jefferson chris at bubblescope dot net 2013-01-01 20:21:13 UTC --- I agree this behaviour might be annoying, but but there is no chance of it being changed, for efficency reasons. You will hey the same behaviour on all standard containers. For debugging purposes, look at the libstdc++ debugging mode, which will catch these types of errors. However, I would not recommend using debug mode in released applications.
[Bug rtl-optimization/55838] [4.6/4.7/4.8 Regression] ICE in extract_insn (unrecognizable insn) with -O -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838 --- Comment #8 from Steven Bosscher steven at gcc dot gnu.org 2013-01-01 20:44:12 UTC --- I would expect the insn to match the movqi_internal insn: (define_insn *movqi_internal [(set (match_operand:QI 0 nonimmediate_operand =q,q ,q ,r,r ,?r,m) (match_operand:QI 1 general_operand q,qn,qm,q,rn,qm,qn))] !(MEM_P (operands[0]) MEM_P (operands[1])) But (const_int 129) isn't a general_operand: #3 0x00997327 in extract_insn (insn=0x76c85870) at ../../trunk/gcc/recog.c:2152 2152fatal_insn_not_found (insn); (gdb) p debug_rtx(insn) (insn 93 92 94 3 (set (reg:QI 127) (const_int 129 [0x81])) -1 (nil)) $34 = void (gdb) p debug_rtx(PATTERN(insn)) (set (reg:QI 127) (const_int 129 [0x81])) $35 = void (gdb) p debug_rtx(SET_DEST (PATTERN(insn))) (reg:QI 127) $36 = void (gdb) p debug_rtx(SET_SRC (PATTERN(insn))) (const_int 129 [0x81]) $37 = void (gdb) p nonimmediate_operand(SET_DEST (PATTERN(insn)),QImode) $38 = 1 (gdb) p general_operand(SET_SRC (PATTERN(insn)),QImode) $39 = 0 (gdb)
[Bug c++/54526] [C++11] :: is incorrectly treated as digraph : followed by colon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54526 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot ||com --- Comment #7 from Paul Pluzhnikov ppluzhnikov at google dot com 2013-01-01 20:59:58 UTC --- (In reply to comment #6) Follow up patch submitted as: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00337.html This patch does not appear to have actually been committed to trunk (yet). Paolo?
[Bug rtl-optimization/55838] [4.6/4.7/4.8 Regression] ICE in extract_insn (unrecognizable insn) with -O -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|NEW
AssignedTo|steven at gcc dot gnu.org |unassigned at gcc dot
||gnu.org
--- Comment #9 from Steven Bosscher steven at gcc dot gnu.org 2013-01-01
21:02:55 UTC ---
In general_operand, the following check fails:
951 if (CONST_INT_P (op)
952 mode != VOIDmode
953 trunc_int_for_mode (INTVAL (op), mode) != INTVAL (op))
954return 0;
with op=(const_int 129) and trunc_int_for_mode (129, QImode)=-127.
This happens because trunc_int_for_mode sign-extends 129 (0b1001):
65 if (width HOST_BITS_PER_WIDE_INT)
66{
67 HOST_WIDE_INT sign = 1;
68 sign = width - 1;
69 c = (sign 1) - 1;
70 c ^= sign;
71 c -= sign;
72}
with width=8 for QImode and HOST_BITS_PER_WIDE_INT is 64 in my case. So:
sign=128 (0b1000), c=129 (0b1001)
c = (sign 1) - 1 = 129
c ^= sign = 1
c -= sign = 1 - 128 = -127 (0b)
???
For someone with better RTL-fu than me...
[Bug libstdc++/55841] Unexpected behavior from STL's queue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55841 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-01 21:16:16 UTC --- N.B. std::queue is a very thin adaptor (i.e. wrapper) around another container, the behaviour you are reporting is actually the behaviour of std::deque, not std::queue. (In reply to comment #0) Apparently, when a std::queue is empty, front() returns some bizarre output Assuming you're using std::deque as the queue's container_type, it is undefined behaviour to call front() when it is empty, so any result is allowed. Why doesn't front() throw an exception when there's no element? It would be slower to check it on every use. If I push one hundred elements into the container then call pop() one hundred times there would be one hundred useless checks that I don't want. If you are not sure if it's safe to call pop() in your program then you should do the check in your own code, not force all users to pay for the checking on every call in every program. And why does pop() break the queue? Because calling pop() on an empty sequence is undefined behaviour. If I understand correctly, the standard doesn't define what to do in this case (I don't understand why), but even so, libstdc++ can do something sensible in this case... As Chris said, use the debug mode. Or write your own wrapper around std::deque that adds checking and then use that as the container_type for std::queue. Sure, I can always check empty() before calling front() or pop(), but isn't that very anti-C++-like, as exceptions were invented exactly so that code doesn't need to be littered with sanity checks like this, and rare cases of insanity cause exceptions? No, it's more C++-like to not pay for features you don't use. If I don't need to check the size on every call I shouldn't have to pay for that check. If you need to check it you should pay for the checking, by adding it yourself.
[Bug c++/54526] [C++11] :: is incorrectly treated as digraph : followed by colon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54526 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-01 22:24:03 UTC --- I don't have much to say, the patch is still awaiting approval. Frankly, I don't personally consider the issue very serious and definitely isn't a regression, at this point we could as well leave the lexer alone for 4.8.
[Bug rtl-optimization/55838] [4.6/4.7/4.8 Regression] ICE in extract_insn (unrecognizable insn) with -O -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838
--- Comment #10 from H.J. Lu hjl.tools at gmail dot com 2013-01-01 23:02:02
UTC ---
This patch avoids using (const_int 129 [0x81]) as step in QImode:
diff --git a/gcc/loop-iv.c b/gcc/loop-iv.c
index 50b7536..aafaae4 100644
--- a/gcc/loop-iv.c
+++ b/gcc/loop-iv.c
@@ -421,6 +421,8 @@ iv_constant (struct rtx_iv *iv, rtx cst, enum machine_mode
mode)
static bool
iv_subreg (struct rtx_iv *iv, enum machine_mode mode)
{
+ rtx step;
+
/* If iv is invariant, just calculate the new value. */
if (iv-step == const0_rtx
!iv-first_special)
@@ -442,13 +444,17 @@ iv_subreg (struct rtx_iv *iv, enum machine_mode mode)
if (GET_MODE_BITSIZE (mode) GET_MODE_BITSIZE (iv-mode))
return false;
+ step = simplify_gen_binary (MULT, iv-extend_mode, iv-step, iv-mult);
+ if (trunc_int_for_mode (INTVAL (step), mode) != INTVAL (step))
+ return false;
+
iv-extend = IV_UNKNOWN_EXTEND;
iv-mode = mode;
iv-base = simplify_gen_binary (PLUS, iv-extend_mode, iv-delta,
simplify_gen_binary (MULT, iv-extend_mode,
iv-base, iv-mult));
- iv-step = simplify_gen_binary (MULT, iv-extend_mode, iv-step, iv-mult);
+ iv-step = step;
iv-mult = const1_rtx;
iv-delta = const0_rtx;
iv-first_special = false;
Re: [Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270
This is the usual problem of devirt benefit predicting more devirtualization than inline-transform actually doing. This time it seems to be related to fact that we first clone the function and propagate m_paintdc but somehow fail to recognize the devirtualizatoin oppurtunities again... Honza
[Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55823 --- Comment #4 from Jan Hubicka hubicka at ucw dot cz 2013-01-01 23:32:27 UTC --- This is the usual problem of devirt benefit predicting more devirtualization than inline-transform actually doing. This time it seems to be related to fact that we first clone the function and propagate m_paintdc but somehow fail to recognize the devirtualizatoin oppurtunities again... Honza
Re: [Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270
ipa-cp is behaving funny here. It clones InitCommon so THIS pointer's binfo is known to enable devirtualization of SetLayoutDirection. It doesn't devirtualize GetLayoutDirection because it works on per-argument basis. This is stupid: obviously whenever THIS binfo is known also DC binfo is known, so we should propagate both into the clone. This is missed optimization relative to previous ipa-cp implementation and I think relatively serious one - it is very common that more than one argument is constant. Martin, can you take a look? Still don't know exactly why we miss the devirtualization after inlining. Honza
[Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55823 --- Comment #5 from Jan Hubicka hubicka at ucw dot cz 2013-01-02 00:10:52 UTC --- ipa-cp is behaving funny here. It clones InitCommon so THIS pointer's binfo is known to enable devirtualization of SetLayoutDirection. It doesn't devirtualize GetLayoutDirection because it works on per-argument basis. This is stupid: obviously whenever THIS binfo is known also DC binfo is known, so we should propagate both into the clone. This is missed optimization relative to previous ipa-cp implementation and I think relatively serious one - it is very common that more than one argument is constant. Martin, can you take a look? Still don't know exactly why we miss the devirtualization after inlining. Honza
[Bug c++/55843] New: ICE after exceeding template instantiation depth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55843
Bug #: 55843
Summary: ICE after exceeding template instantiation depth
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
Hello,
the following code, compiled without any option, makes cc1plus segfault.
g++-4.7 has a slightly nicer confused by earlier errors, bailing out.
template typename T struct type_wrapper {
};
typedef char (yes_tag)[2];
templatebool b struct if_c {
};
template typename T struct has_type {
struct gcc_3_2_wknd {
template typename U static yes_tag test( type_wrapperU const volatile*
, type_wrappertypename U::type* = 0 );
};
typedef type_wrapperT t_;
static const bool value = sizeof(gcc_3_2_wknd::test(static_castt_*(0))) ==
sizeof(yes_tag);
};
template class K, class T, class=void struct Get_type {
};
struct FT_tag {};
struct RT_tag {};
template class K struct Get_typeK, RT_tag, typename if_c
!has_typeGet_typeK, FT_tag ::value ::type { };
template class K struct Get_typeK, FT_tag, typename if_c
!has_typeGet_typeK, RT_tag ::value ::type { };
typedef Get_typeint, FT_tag::type P;
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679 Yogesh Gaur gauryogesh.nsit at gmail dot com changed: What|Removed |Added CC||gauryogesh.nsit at gmail ||dot com --- Comment #20 from Yogesh Gaur gauryogesh.nsit at gmail dot com 2013-01-02 01:41:19 UTC --- Hello Jakub and Jason, Did we get any solution for this reported bugzilla. Actually I also have faced similar issue while loading my library using dlopen by passing RTLD_DEEPBIND flag. When I didn't pass this flag, no issues occurs and program run fine. I am using glibc-2.14. output with LD_DEBUG=all for both (crash and working) case : == WITH RTLD_DEEPBIND flag Linux# LD_DEBUG=all ./main_db 21 | grep _ZSt4cerr 424: symbol=_ZSt4cerr; lookup in file=./main_db [0] 424: binding file /lib/libstdc++.so.6 [0] to ./main_db [0]: normal symbol `_ZSt4cerr' [GLIBCXX_3.4] 424: symbol=_ZSt4cerr; lookup in file=/lib/libdl.so.2 [0] 424: symbol=_ZSt4cerr; lookup in file=/lib/libstdc++.so.6 [0] 424: binding file ./main_db [0] to /lib/libstdc++.so.6 [0]: normal symbol `_ZSt4cerr' [GLIBCXX_3.4] 424: symbol=_ZSt4cerr; lookup in file=./library.so [0] 424: symbol=_ZSt4cerr; lookup in file=/lib/libstdc++.so.6 [0] 424: binding file ./library.so [0] to /lib/libstdc++.so.6 [0]: normal symbol `_ZSt4cerr' [GLIBCXX_3.4] //-- This is problematic scenario here as binding of this symbol is done with libstdc++.so.6 == WITHOUT RTLD_DEEPBIND flag Linux# LD_DEBUG=all ./main_ndb 21 | grep _ZSt4cerr 427: symbol=_ZSt4cerr; lookup in file=./main_ndb [0] 427: binding file /lib/libstdc++.so.6 [0] to ./main_ndb [0]: normal symbol `_ZSt4cerr' [GLIBCXX_3.4] 427: symbol=_ZSt4cerr; lookup in file=/lib/libdl.so.2 [0] 427: symbol=_ZSt4cerr; lookup in file=/lib/libstdc++.so.6 [0] 427: binding file ./main_ndb [0] to /lib/libstdc++.so.6 [0]: normal symbol `_ZSt4cerr' [GLIBCXX_3.4] 427: symbol=_ZSt4cerr; lookup in file=./main_ndb [0] 427: binding file ./library.so [0] to ./main_ndb [0]: normal symbol `_ZSt4cerr' [GLIBCXX_3.4] // -- Here proper binding happen and binding of library.so is done with main_ndb executable. == Please let me know if there is any solution for this long reported issue. I need to use RTLD_DEEPBIND flag.
[Bug sanitizer/55844] New: -fsanitize=address -Os -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55844
Bug #: 55844
Summary: -fsanitize=address -Os -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -m64 doesn't work
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org,
ja...@gcc.gnu.org, k...@gcc.gnu.org
c-c++-common/asan/null-deref-1.c fails with -m64 since
-fsanitize=address -Os -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-m64
still omit frame pointer:
[hjl@gnu-tools-1 gcc]$ cat /tmp/x.c
void
NullDeref(int *ptr)
{
ptr[10]++;
}
[hjl@gnu-tools-1 gcc]$
/export/build/gnu/gcc-x32-mx32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32-mx32/build-x86_64-linux/gcc/ /tmp/x.c -S -Os
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 -fsanitize=address
[hjl@gnu-tools-1 gcc]$ cat x.s
.filex.c
.text
.globlNullDeref
.typeNullDeref, @function
NullDeref:
.LFB0:
.cfi_startproc
movq%rdi, %rax
leaq40(%rdi), %rdi
movabsq$17592186044416, %rdx
movq%rdi, %rcx
shrq$3, %rcx
movb(%rcx,%rdx), %dl
movq%rdi, %rcx
andl$7, %ecx
addl$3, %ecx
cmpb%dl, %cl
jl.L2
testb%dl, %dl
je.L2
pushq%rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
call__asan_report_load4
.L2:
.cfi_def_cfa 7, 8
.cfi_restore 6
incl40(%rax)
ret
.cfi_endproc
.LFE0:
.sizeNullDeref, .-NullDeref
.section.text.startup,ax,@progbits
.type_GLOBAL__sub_I_00099_0_NullDeref, @function
_GLOBAL__sub_I_00099_0_NullDeref:
.LFB1:
.cfi_startproc
pushq%rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
popq%rbp
.cfi_def_cfa 7, 8
jmp__asan_init
.cfi_endproc
.LFE1:
.size_GLOBAL__sub_I_00099_0_NullDeref,
.-_GLOBAL__sub_I_00099_0_NullDeref
.section.init_array.00099,aw
.align 8
.quad_GLOBAL__sub_I_00099_0_NullDeref
.identGCC: (GNU) 4.8.0 20130101 (experimental)
.section.note.GNU-stack,,@progbits
[hjl@gnu-tools-1 gcc]$
/export/build/gnu/gcc-x32-mx32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32-mx32/build-x86_64-linux/gcc/ /tmp/x.c -S -Os
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64
[hjl@gnu-tools-1 gcc]$ cat x.s
.filex.c
.text
.globlNullDeref
.typeNullDeref, @function
NullDeref:
.LFB0:
.cfi_startproc
pushq%rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
incl40(%rdi)
movq%rsp, %rbp
.cfi_def_cfa_register 6
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.sizeNullDeref, .-NullDeref
.identGCC: (GNU) 4.8.0 20130101 (experimental)
.section.note.GNU-stack,,@progbits
[hjl@gnu-tools-1 gcc]$
[Bug sanitizer/55844] -fsanitize=address -Os -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55844 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-02 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-02 07:13:33 UTC --- It has a frame pointer: pushq%rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq%rsp, %rbp Right there. The issue is you also need to disable shrink wrapping (-fno-shrink-wrap). This again why we should just move over to using the dwarf unwdinder and forget about the manually unwinding the stack.
[Bug sanitizer/55844] -fsanitize=address -Os -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55844 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-02 07:30:55 UTC --- http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01179.html
Re: [PATCH, libbacktrace] Don't call __sync_lock_test_and_set if we don't have sync functions
On Sun, Dec 9, 2012 at 11:08 AM, John David Anglin d...@hiauly1.hia.nrc.ca wrote: On hppa*-*-hpux*, we don't have sync functions. However, __sync_lock_test_and_set is called in backtrace_alloc and backtrace_free. This causes an abort before ICE proccessing is fully complete. hppa64 is an ELF target and backtraces are nominally supported. The attached change avoids calling __sync_lock_test_and_set if we don't have sync functions. As a result, the memory is leaked. Sorry for the delay. I think it's better to fix this the same way we handle the other sync functions, as in this patch. Bootstrapped and ran libbacktrace and go testsuites on x86_64-unknown-linux-gnu. Committed to mainline. Ian 2013-01-01 Ian Lance Taylor i...@google.com PR other/55536 * mmap.c (backtrace_alloc): Don't call sync functions if not threaded. (backtrace_free): Likewise. foo.patch Description: Binary data
libbacktrace patch committed: Don't use -I ../gcc/include
There is no reason for libbacktrace to try to include files from ../gcc/include. All the required header files can now be found in libgcc. I'm not sure why I added the -I ../gcc/include in the first place; perhaps I was thinking of code from before the libgcc migration. Using -I ../gcc/include can in some unusual cases lead to the difficulties described in PR 54834. This patch fixes the problem. Bootstrapped and ran libbacktrace testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian 2013-01-01 Ian Lance Taylor i...@google.com PR bootstrap/54834 * Makefile.am (AM_CPPFLAGS): Remove -I ../gcc/include and -I $(MULTIBUILDTOP)/../../gcc/include. * Makefile.in: Rebuild. Index: Makefile.am === --- Makefile.am (revision 194764) +++ Makefile.am (working copy) @@ -32,7 +32,7 @@ ACLOCAL_AMFLAGS = -I .. -I ../config AM_CPPFLAGS = -I $(top_srcdir)/../include -I $(top_srcdir)/../libgcc \ - -I ../libgcc -I ../gcc/include -I $(MULTIBUILDTOP)../../gcc/include + -I ../libgcc AM_CFLAGS = $(EXTRA_FLAGS) $(WARN_FLAGS) $(PIC_FLAG)
[PATCH] libiberty simple object XCOFF support
The attached patch is a start at libiberty simple object support for AIX XCOFF file format. With this patch, the simple object API can read and write XCOFF files. I need to investigate a little more about the proper attributes for XCOFF sections written using sobj. There are open questions about how to wedge GCC LTO support into the AIX XCOFF file format. I am unsure if LTO can be an additional section in the XCOFF file or should be new CSECTs in an existing section. Maybe CSECTs in the XCOFF comment section. * simple-object-xcoff.c: New file. * Makefile.in: Add it to build machinery. * simple-object-common.h (simple_object_xcoff_functions): Declare. * simple-object. (format_functions): Add simple_object_xcoff_functions. Bootstrapped on powerpc-ibm-aix7.1.0.0 Thanks, David simple-object-xcoff.diff Description: Binary data
Re: [PATCH] libiberty simple object XCOFF support
On Tue, Jan 1, 2013 at 6:04 PM, David Edelsohn wrote: There are open questions about how to wedge GCC LTO support into the AIX XCOFF file format. I am unsure if LTO can be an additional section in the XCOFF file or should be new CSECTs in an existing section. Maybe CSECTs in the XCOFF comment section. Does XCOFF differ a lot from COFF? Otherwise you could take some ideas from simple-object-coff.c. Ciao! Steven
Re: [PATCH] libiberty simple object XCOFF support
On Tue, Jan 1, 2013 at 9:10 AM, Steven Bosscher stevenb@gmail.com wrote: Does XCOFF differ a lot from COFF? In a word, yes. While COFF and XCOFF share a distant ancestor, they are in effect completely different object file formats. Ian
[Patch, Darwin, ppc] constrain processor usage for m32.
Hi Iain, Mike and Andrew, I have been having issues compiling WebKit with mcpu=970 (or mcpu=G5) without afterwards passing mno-powerpc64 or m32 in to explicitly turn 64 bit instructions off. That was using Apple gcc 5666.3, which is Apples last published version and based on 4.2.1 . I also had another issue with ftree-vrp and found that in some later 4.2.x release a bug related to that was fixed, so I went ahead and merged 4.2.2 - 4.2.4 into Apple's gcc 4.2.1 sources. After that both issues are now gone! So, in gcc 4.2.4 I don't have anymore issues with usage of 64 bit instructions, hence this wasn't broken at that point point in time. Related bug report following: However I also tried to build the mozilla JavaScript library using gcc 4.7.2 as shared library optimized for the G5 explicitly. That works well and neither linker (ld64 97.17), nor mach-o binary tools nor compiler complain about anything. But OS X dyld throws an error complaining about unknown local relocation type when trying to load that library using dlopen(). Examining the library using otool does not show any incorrect local relocation, so I don't know what's going wrong. Might be a dyld bug but when I build with optimization turned off (- O0) the library loads and works fine. I tried to switch off as much optimizations turned on by -O1 as possible (building with -O1 does also cause the problem) but I can't get it working. I even explicitely disabled as much optimization passes as possible (using -fdisable-*) but to no avail. I could try debugging using gdb in order to find out the code that causes the problem. Or do you have any other ideas? Tobias
[patch, Fortran] PR 55806 - Inefficient ANY with array constructors
Hello world,
the attached patch replaces ANY(a, b, c) with a .or. b .or c,
leading to reduced execution time. It also handles ALL, PRODUCT
and SUM.
This fixes a bug noted by Michael Metcalf.
Regression-tested. OK for trunk?
Thomas
2013-01-01 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/55806
* frontend-passes.c (optimize_reduction): New function,
including prototype.
(callback_reduction): Likewise.
(gfc_run_passes): Also run optimize_reduction.
(copy_walk_reduction_arg): New function.
(dummy_code_callback): New function.
2013-01-01 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/55806
* gfortran.dg/array_constructor_40.f90: New test.
! { dg-do run }
! { dg-options -ffrontend-optimize -fdump-tree-original }
! PR 55806 - replace ANY intrinsic for array
! constructor with .or.
module mymod
implicit none
contains
subroutine bar(a,b,c, lo)
real, dimension(3,3), intent(in) :: a,b
logical, dimension(3,3), intent(in) :: lo
integer, intent(out) :: c
real, parameter :: acc = 1e-4
integer :: i,j
c = 0
do i=1,3
if (any([abs(a(i,1) - b(i,1)) acc,
abs(a(i,2) - b(i,2)) acc,
abs(a(i,3) - b(i,3)) acc, lo(i,:),
(j==i+1,j=3,8)])) cycle
c = c + i
end do
end subroutine bar
end module mymod
program main
use mymod
implicit none
real, dimension(3,3) :: a,b
integer :: c
logical lo(3,3)
data a/1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9/
b = a
b(2,2) = a(2,2) + 0.2
lo = .false.
lo(3,3) = .true.
call bar(a,b,c,lo)
if (c /= 1) call abort
end program main
! { dg-final { scan-tree-dump-times while 2 original } }
! { dg-final { cleanup-tree-dump original } }
Index: frontend-passes.c
===
--- frontend-passes.c (Revision 194760)
+++ frontend-passes.c (Arbeitskopie)
@@ -40,6 +40,8 @@ static bool optimize_lexical_comparison (gfc_expr
static void optimize_minmaxloc (gfc_expr **);
static bool is_empty_string (gfc_expr *e);
static void doloop_warn (gfc_namespace *);
+static void optimize_reduction (gfc_namespace *);
+static int callback_reduction (gfc_expr **, int *, void *);
/* How deep we are inside an argument list. */
@@ -107,6 +109,7 @@ gfc_run_passes (gfc_namespace *ns)
expr_array = XNEWVEC(gfc_expr **, expr_size);
optimize_namespace (ns);
+ optimize_reduction (ns);
if (gfc_option.dump_fortran_optimized)
gfc_dump_parse_tree (ns, stdout);
@@ -180,7 +183,172 @@ optimize_expr (gfc_expr **e, int *walk_subtrees AT
return 0;
}
+/* Auxiliary function to handle the arguments to reduction intrnisics.
+ If the function is a scalar, just copy it; otherwise Returns the new
+ element, the old one can be freed. */
+static gfc_expr *
+copy_walk_reduction_arg (gfc_expr *e, gfc_expr *fn)
+{
+ gfc_expr *fcn;
+ const char *new_name;
+ gfc_actual_arglist *actual_arglist;
+
+ if (e-rank == 0 || e-expr_type == EXPR_FUNCTION)
+fcn = gfc_copy_expr (e);
+ else
+{
+ fcn = gfc_get_expr ();
+ fcn-expr_type = EXPR_FUNCTION;
+ fcn-value.function.isym = fn-value.function.isym;
+ actual_arglist = gfc_get_actual_arglist ();
+ actual_arglist-expr = gfc_copy_expr (e);
+ actual_arglist-next = gfc_get_actual_arglist ();
+ fcn-value.function.actual = actual_arglist;
+ fcn-ts = fn-ts;
+
+ switch (fn-value.function.isym-id)
+ {
+ case GFC_ISYM_SUM:
+ new_name = __internal_sum;
+ break;
+
+ case GFC_ISYM_PRODUCT:
+ new_name = __internal_product;
+ break;
+
+ case GFC_ISYM_ANY:
+ new_name = __internal_any;
+ break;
+
+ case GFC_ISYM_ALL:
+ new_name = __internal_all;
+ break;
+
+ default:
+ abort ();
+ }
+
+ gfc_get_sym_tree (new_name, current_ns, fcn-symtree, false);
+ fcn-symtree-n.sym-attr.flavor = FL_PROCEDURE;
+ fcn-symtree-n.sym-attr.function = 1;
+ fcn-symtree-n.sym-attr.elemental = 1;
+ fcn-symtree-n.sym-attr.referenced = 1;
+ fcn-symtree-n.sym-attr.access = ACCESS_PRIVATE;
+ gfc_commit_symbol (fcn-symtree-n.sym);
+}
+
+ (void) gfc_expr_walker (fcn, callback_reduction, NULL);
+
+ return fcn;
+}
+
+/* Callback function for optimzation of reductions to scalars. Transform
+ ANY ([f1,f2,f3, ...]) to f1 .or. f2 .or. f3 .or. ..., with ANY,
+ SUM and PRODUCT correspondingly. Handly only the simple cases without
+ MASK and DIM. */
+
+static int
+callback_reduction (gfc_expr **e, int *walk_subtrees ATTRIBUTE_UNUSED,
+ void *data ATTRIBUTE_UNUSED)
+{
+ gfc_expr *fn, *arg;
+ gfc_intrinsic_op op;
+ gfc_isym_id id;
+ gfc_actual_arglist *a;
+ gfc_actual_arglist *dim;
+ gfc_constructor *c;
+ gfc_expr *res, *new_expr;
+
+ fn = *e;
+
+ if (fn-rank != 0 || fn-expr_type != EXPR_FUNCTION
+ || fn-value.function.isym == NULL)
+return 0;
+
+ id = fn-value.function.isym-id;
+
+ if (id != GFC_ISYM_SUM id
Re: [patch] std::unique_ptrT[], D improvements
On 12/28/12, Jonathan Wakely jwakely@gmail.com wrote:
On 28 December 2012 01:51, Lawrence Crowl wrote:
I'm not getting errors when converting from derived to base.
E.g. the following compiles, when it should not.
std::unique_ptrconst base [] acb_ad(new derived[3]);
I get an error:
shm$ cat up.cc
#include memory
struct base { };
struct derived : base { virtual ~derived() = default; };
std::unique_ptrconst base [] acb_ad(new derived[3]);
shm$
shm$ g++11 up.cc -c
up.cc:4:53: error: use of deleted function ‘std::unique_ptr_Tp [],
_Dp::unique_ptr(_Up*) [with _Up = derived; template-parameter-2-2 =
void; _Tp = const base; _Dp = std::default_deleteconst base []]’
std::unique_ptrconst base [] acb_ad(new derived[3]);
^
In file included from /home/redi/gcc/4.x/include/c++/4.8.0/memory:81:0,
from up.cc:1:
/home/redi/gcc/4.x/include/c++/4.8.0/bits/unique_ptr.h:343:2: error:
declared here
unique_ptr(_Up* __p) = delete;
^
That was pilot error on my part. However, I've been having trouble
when the argument to the constructor or reset has a conversion
operator. The code does distinquish between a safe conversion to
base and an unsafe conversion to derived.
Here is a simplified version of the problem. The code as is fails
to reject the last two calls to accept. The primary reason is that
is_convertable permits both the invocation of the conversion operator
and the derived to base conversion. At present, I see no way to
get a handle on the 'natural' return type of the conversion operator.
#include type_traits
struct base { };
struct derived : base { };
template typename T, typename F
typename std::enable_if
std::is_convertible F, T* ::value,
T*
::type
accept(F arg) { return arg; }
template typename T, typename F
typename std::enable_if
!std::is_convertible F(*)[], T(*)[] ::value,
T*
::type
accept(F* arg) = delete;
struct cvt_b {
operator base*() { return 0; }
};
struct cvt_d {
operator derived*() { return 0; }
};
int main()
{
// should PASS
accept base ( (base*)0 );
accept const base ( (base*)0 );
accept base ( cvt_b() );
accept const base ( cvt_b() );
// should FAIL
accept base ( (derived*)0 );
accept const base ( (derived*)0 );
accept base ( cvt_d() );
accept const base ( cvt_d() );
}
--
Lawrence Crowl
Re: [Patch, Darwin, ppc] constrain processor usage for m32.
On Jan 1, 2013, at 10:03 AM, Tobias Netzel tobias.net...@googlemail.com wrote: Or do you have any other ideas? I don't. I'd grab the .s files (compile with -save-temps) and start stripping things out til it loads, then then last thing stripped was the thing that broke it.
Re: [patch] std::unique_ptrT[], D improvements
On 1 January 2013 20:40, Lawrence Crowl wrote: That was pilot error on my part. However, I've been having trouble when the argument to the constructor or reset has a conversion operator. The code does distinquish between a safe conversion to base and an unsafe conversion to derived. Here is a simplified version of the problem. The code as is fails to reject the last two calls to accept. The primary reason is that is_convertable permits both the invocation of the conversion operator and the derived to base conversion. At present, I see no way to get a handle on the 'natural' return type of the conversion operator. Is the issue here that Geoffrey's proposed resolution allows any conversions (safe or not) if the source type is not a built-in pointer, i.e. is some user-defined type? So a user-defined type that refers an array of derived classes is allowed to be converted to an array of base, even though that's not safe. Howard has strongly objected to this part of the P/R.
Re: [patch] std::unique_ptrT[], D improvements
On 1/1/13, Jonathan Wakely jwakely@gmail.com wrote: On 1 January 2013 20:40, Lawrence Crowl wrote: That was pilot error on my part. However, I've been having trouble when the argument to the constructor or reset has a conversion operator. The code does distinquish between a safe conversion to base and an unsafe conversion to derived. Here is a simplified version of the problem. The code as is fails to reject the last two calls to accept. The primary reason is that is_convertable permits both the invocation of the conversion operator and the derived to base conversion. At present, I see no way to get a handle on the 'natural' return type of the conversion operator. Is the issue here that Geoffrey's proposed resolution allows any conversions (safe or not) if the source type is not a built-in pointer, i.e. is some user-defined type? So a user-defined type that refers an array of derived classes is allowed to be converted to an array of base, even though that's not safe. Howard has strongly objected to this part of the P/R. Yes. I see no way to distinguish between objects with safe conversion operators and unsafe conversion operators. -- Lawrence Crowl
Re: [PATCH] libiberty simple object XCOFF support
On Tue, Jan 1, 2013 at 12:31 PM, Ian Lance Taylor i...@google.com wrote: On Tue, Jan 1, 2013 at 9:10 AM, Steven Bosscher stevenb@gmail.com wrote: Does XCOFF differ a lot from COFF? In a word, yes. While COFF and XCOFF share a distant ancestor, they are in effect completely different object file formats. simple-object-xcoff.c is based on simple-object-coff.c, which is why I acknowledged Ian in the authorship. The file header and section support is very similar. The 64 bit AIX XCOFF format complicated the structure layouts a little. AIX XCOFF embedded / inserted another layout of control sections within sections. I need to investigate how much CSECT support is necessary in simple object for the way that GCC LTO utilizes simple object. The patch is a start with basic functionality. Thanks, David
Re: [PATCH] libiberty simple object XCOFF support
On Tue, Jan 1, 2013 at 9:04 AM, David Edelsohn dje@gmail.com wrote: The attached patch is a start at libiberty simple object support for AIX XCOFF file format. With this patch, the simple object API can read and write XCOFF files. I need to investigate a little more about the proper attributes for XCOFF sections written using sobj. There are open questions about how to wedge GCC LTO support into the AIX XCOFF file format. I am unsure if LTO can be an additional section in the XCOFF file or should be new CSECTs in an existing section. Maybe CSECTs in the XCOFF comment section. * simple-object-xcoff.c: New file. * Makefile.in: Add it to build machinery. * simple-object-common.h (simple_object_xcoff_functions): Declare. * simple-object. (format_functions): Add simple_object_xcoff_functions. + return COFF object format mismatch; Should say XCOFF. This patch is OK by me. Ian
Re: [patch, libgfortran] PR55818 Reading a REAL from a file which doesn't end in a new line fails
This updated patch addresses the issues with infinities, nans, characters, and
valid reals.
OK for trunk?
Test case attached.
Regards,
Jerry
Index: list_read.c
===
--- list_read.c (revision 194731)
+++ list_read.c (working copy)
@@ -697,6 +697,7 @@ read_logical (st_parameter_dt *dtp, int length)
break;
CASE_SEPARATORS:
+case EOF:
unget_char (dtp, c);
eat_separator (dtp);
return; /* Null value. */
@@ -951,6 +952,7 @@ read_character (st_parameter_dt *dtp, int length _
break;
CASE_SEPARATORS:
+case EOF:
unget_char (dtp, c); /* NULL value. */
eat_separator (dtp);
return;
@@ -975,8 +977,7 @@ read_character (st_parameter_dt *dtp, int length _
for (;;)
{
- if ((c = next_char (dtp)) == EOF)
- goto eof;
+ c = next_char (dtp);
switch (c)
{
CASE_DIGITS:
@@ -984,6 +985,7 @@ read_character (st_parameter_dt *dtp, int length _
break;
CASE_SEPARATORS:
+ case EOF:
unget_char (dtp, c);
goto done; /* String was only digits! */
@@ -1041,7 +1043,7 @@ read_character (st_parameter_dt *dtp, int length _
the string. */
if ((c = next_char (dtp)) == EOF)
- goto eof;
+ goto done_eof;
if (c == quote)
{
push_char (dtp, quote);
@@ -1167,6 +1169,7 @@ parse_real (st_parameter_dt *dtp, void *buffer, in
goto exp2;
CASE_SEPARATORS:
+ case EOF:
goto done;
default:
@@ -1202,6 +1205,7 @@ parse_real (st_parameter_dt *dtp, void *buffer, in
break;
CASE_SEPARATORS:
+ case EOF:
unget_char (dtp, c);
goto done;
@@ -1243,7 +1247,7 @@ parse_real (st_parameter_dt *dtp, void *buffer, in
((c = next_char (dtp)) == 'y' || c == 'Y')
(c = next_char (dtp
{
- if (is_separator (c))
+ if (is_separator (c) || (c == EOF))
unget_char (dtp, c);
push_char (dtp, 'i');
push_char (dtp, 'n');
@@ -1255,7 +1259,7 @@ parse_real (st_parameter_dt *dtp, void *buffer, in
((c = next_char (dtp)) == 'n' || c == 'N')
(c = next_char (dtp)))
{
- if (is_separator (c))
+ if (is_separator (c) || (c == EOF))
unget_char (dtp, c);
push_char (dtp, 'n');
push_char (dtp, 'a');
@@ -1269,7 +1273,7 @@ parse_real (st_parameter_dt *dtp, void *buffer, in
goto bad;
c = next_char (dtp);
- if (is_separator (c))
+ if (is_separator (c) || (c == EOF))
unget_char (dtp, c);
}
goto done_infnan;
@@ -1315,6 +1319,7 @@ read_complex (st_parameter_dt *dtp, void * dest, i
break;
CASE_SEPARATORS:
+case EOF:
unget_char (dtp, c);
eat_separator (dtp);
return;
@@ -1369,7 +1374,7 @@ eol_4:
goto bad_complex;
c = next_char (dtp);
- if (!is_separator (c))
+ if (!is_separator (c) (c != EOF))
goto bad_complex;
unget_char (dtp, c);
@@ -1429,6 +1434,7 @@ read_real (st_parameter_dt *dtp, void * dest, int
goto got_sign;
CASE_SEPARATORS:
+case EOF:
unget_char (dtp, c); /* Single null. */
eat_separator (dtp);
return;
@@ -1484,6 +1490,7 @@ read_real (st_parameter_dt *dtp, void * dest, int
goto got_repeat;
CASE_SEPARATORS:
+ case EOF:
if (c != '\n' c != ',' c != '\r' c != ';')
unget_char (dtp, c);
goto done;
@@ -1647,7 +1654,7 @@ read_real (st_parameter_dt *dtp, void * dest, int
goto unwind;
c = next_char (dtp);
l_push_char (dtp, c);
- if (!is_separator (c))
+ if (!is_separator (c) (c != EOF))
{
if (c != 'i' c != 'I')
goto unwind;
@@ -1700,7 +1707,7 @@ read_real (st_parameter_dt *dtp, void * dest, int
}
}
- if (!is_separator (c))
+ if (!is_separator (c) (c != EOF))
goto unwind;
if (dtp-u.p.namelist_mode)
@@ -2537,16 +2544,16 @@ nml_read_obj (st_parameter_dt *dtp, namelist_info
switch (nl-type)
{
case BT_INTEGER:
- read_integer (dtp, len);
- break;
+ read_integer (dtp, len);
+break;
case BT_LOGICAL:
- read_logical (dtp, len);
- break;
+ read_logical (dtp, len);
+ break;
case BT_CHARACTER:
- read_character (dtp, len);
- break;
+ read_character (dtp, len);
+ break;
case BT_REAL:
/* Need to copy data back from the real location to the temp in order
! { dg-do run }
! PR55818 Reading a REAL from a file which doesn't end in a new line fails
! Test case from PR reporter.
implicit none
integer :: stat
!integer :: var ! works
real:: var ! fails
character(len=10):: cvar ! fails
complex :: cval
open(99, file=test.dat, access=stream, form=unformatted, status=new)
write(99) 1, new_line()
write(99) 2, new_line()
write(99) 3
close(99)
! Test character kind
open(99, file=test.dat)
read (99,*, iostat=stat) cvar
if (stat /= 0 .or. cvar /= 1) call abort()
read (99,*, iostat=stat) cvar
if (stat /= 0 .or. cvar /= 2) call
[PATCH, committed] Update MAINTAINERS
I've checked in the following patch to update my email address in MAINTAINERS. -- Maxim Kuvyrkov MAINTAINERS-Update-my-email.ChangeLog Description: Binary data MAINTAINERS-Update-my-email.patch Description: Binary data
