Re: wide-int, i386
On Sat, Nov 23, 2013 at 8:22 PM, Mike Stump mikest...@comcast.net wrote: Richi has asked the we break the wide-int patch so that the individual port and front end maintainers can review their parts without have to go through the entire patch.This patch covers the i386 port. Should this patch also address construction of 128bit immediates? One example is in ix86_build_signbit_mask, where we have to use special tricks to create them. You can find other interesting places by grepping config/i386/* sources for HOST_BITS_PER_WIDE_INT checks. These remains from times when wide_int was 32 for i686 host, and IMO should be addressed by wide-int patch. Thanks, Uros.
Re: PR37132 – RFC patch for generation of DWARF symbol for Fortran's namelists (DW_TAG_namelist)
Hi all, attached is an updated version of the patch. Change: Tobias Burnus wrote: But for USE mod_name, only: nml, one is supposed to generate a DW_TAG_imported_declaration. And there I am stuck. For normal variables, the DW_TAG_imported_declaration refers to a DW_TAG_variable die. Analogously, for a namelist one would have to refer to a DW_TAG_namelist die. But such DW_TAG_namelist comes with a DW_TAG_namelist_item list. And for the latter, one needs to have the die of all variables in the namelist. But with use-only the symbols aren't use associate and no decl or die exists. (Failing call tree with the patch: gfc_trans_use_stmts - dwarf2out_imported_module_or_decl_1 - force_decl_die.) With the attached patch, one now generates DW_TAG_namelist with no DW_TAG_namelist_item and sets DW_AT_declaration. Thus, for (first file) module mm integer :: ii real :: rr namelist /nml/ ii, rr end module mm and (second file): subroutine test use mm, only: nml write(*,nml) end subroutine test One now generates (first file): 11e: Abbrev Number: 2 (DW_TAG_module) 1f DW_AT_name: mm 22 DW_AT_decl_file : 1 23 DW_AT_decl_line : 1 24 DW_AT_sibling : 0x59 228: Abbrev Number: 3 (DW_TAG_variable) 29 DW_AT_name: ii 2c DW_AT_decl_file : 1 2d DW_AT_decl_line : 2 2e DW_AT_linkage_name: (indirect string, offset: 0x15): __mm_MOD_ii 32 DW_AT_type: 0x59 36 DW_AT_external: 1 36 DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0) 240: Abbrev Number: 3 (DW_TAG_variable) 41 DW_AT_name: rr 44 DW_AT_decl_file : 1 45 DW_AT_decl_line : 2 46 DW_AT_linkage_name: (indirect string, offset: 0x9): __mm_MOD_rr 4a DW_AT_type: 0x60 4e DW_AT_external: 1 4e DW_AT_location: 9 byte block: 3 4 0 0 0 0 0 0 0 (DW_OP_addr: 4) 258: Abbrev Number: 0 159: Abbrev Number: 4 (DW_TAG_base_type) 5a DW_AT_byte_size : 4 5b DW_AT_encoding: 5(signed) 5c DW_AT_name: (indirect string, offset: 0x29): integer(kind=4) 160: Abbrev Number: 4 (DW_TAG_base_type) 61 DW_AT_byte_size : 4 62 DW_AT_encoding: 4(float) 63 DW_AT_name: (indirect string, offset: 0x12c): real(kind=4) 167: Abbrev Number: 5 (DW_TAG_namelist) 68 DW_AT_name: nml 26c: Abbrev Number: 6 (DW_TAG_namelist_item) 6d DW_AT_namelist_items: 0x28 271: Abbrev Number: 6 (DW_TAG_namelist_item) 72 DW_AT_namelist_items: 0x40 Second file: 24f: Abbrev Number: 3 (DW_TAG_imported_declaration) 50 DW_AT_decl_file : 1 51 DW_AT_decl_line : 2 52 DW_AT_import : 0x70 [Abbrev Number: 6 (DW_TAG_namelist)] 256: Abbrev Number: 4 (DW_TAG_lexical_block) 57 DW_AT_low_pc : 0xb 5f DW_AT_high_pc : 0xb0 267: Abbrev Number: 0 168: Abbrev Number: 5 (DW_TAG_module) 69 DW_AT_name: mm 6c DW_AT_declaration : 1 6c DW_AT_sibling : 0x76 270: Abbrev Number: 6 (DW_TAG_namelist) 71 DW_AT_name: nml 75 DW_AT_declaration : 1 275: Abbrev Number: 0 Does the dumps look okay? For the first file, DW_TAG_namelist doesn't come directly after DW_TAG_module but after its sibling 0x59; does one still see that nml belongs to that module? (On dwarf2out level, context die should point to the module tag, but I don't understand the readelf/eu-readelf output well enough to see whether that's also the case for the generated dwarf.) I assume that the compiler can see from the DWARF of the second file that nml comes from module mm and doesn't search the value elsewhere. (It is possible to have multiple namelist with the same name in different modules.) For previous version, I did an all-language bootstrap + regtesting; for this one, I only build and tested Fortran. I will do a now a full all language bootstrap regtesting. Assuming that it is successful: OK for the trunk? Tobias gcc/ 2013-11-24 Tobias Burnus bur...@net-b.de PR debug/37132 * lto-streamer.h (LTO_tags): Add LTO_namelist_decl_ref. * tree.def (NAMELIST_DECL): Add. * tree.h (NAMELIST_DECL_ASSOCIATED_DECL): New macro. * tree.c (initialize_tree_contains_struct): Add asserts for it. * dwarf2out.c (gen_namelist_decl): New function. (gen_decl_die, dwarf2out_decl): Call it. (dwarf2out_imported_module_or_decl_1): Handle NAMELIST_DECL. * lto-streamer-in.c (lto_input_tree_ref): Handle NAMELIST_DECL. (lto_input_tree_ref, lto_input_tree_1): Update lto_tag_check_range call. * lto-streamer-out.c (lto_output_tree_ref): Handle NAMELIST_DECL. gcc/fortran 2013-11-24 Tobias Burnus bur...@net-b.de PR debug/37132 * trans-decl.c (generate_namelist_decl, create_module_nml_decl): New static functions. (gfc_generate_module_vars, generate_local_vars): Call them. (gfc_trans_use_stmts): Handle namelists for debug genertion. diff --git
[PATCH, testsuite]: Fix gcc.dg/float-exact-1.c
Hello!
Attached patch fixes compile failure and adds ieee options due to
denormal values in the testcase.
2013-11-23 Uros Bizjak ubiz...@gmail.com
* gcc.dg/float-exact-1.c: Use dg-add-options ieee.
[LDBL_MANT_DIG == 113]: Fix wrong variable name.
Tested on alphaev68-linux-gnu and committed to mainline SVN.
Uros.
Index: ChangeLog
===
--- ChangeLog (revision 205306)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2013-11-23 Uros Bizjak ubiz...@gmail.com
+
+ * gcc.dg/float-exact-1.c: Use dg-add-options ieee.
+ [LDBL_MANT_DIG == 113]: Fix wrong variable name.
+
2013-11-23 Janus Weil ja...@gcc.gnu.org
PR fortran/59228
@@ -24,8 +29,8 @@
2013-11-22 Martin Jambor mjam...@suse.cz
* gcc.dg/pr10474.c: Also test ppc64.
- * gcc.dg/ira-shrinkwrap-prep-1.c: Also tes ppc64, changed all ints
-to longs.
+ * gcc.dg/ira-shrinkwrap-prep-1.c: Also test ppc64, chang all ints
+ to longs.
* gcc.dg/ira-shrinkwrap-prep-2.c: Likewise.
2013-11-22 Michael Meissner meiss...@linux.vnet.ibm.com
Index: gcc.dg/float-exact-1.c
===
--- gcc.dg/float-exact-1.c (revision 205306)
+++ gcc.dg/float-exact-1.c (working copy)
@@ -2,6 +2,7 @@
floating-point contents expressed in decimal. PR 21718. */
/* { dg-do run } */
/* { dg-options -w } */
+/* { dg-add-options ieee } */
/* For float (if IEEE binary32), double (if IEEE binary64) and long
double (if IEEE binary64, x86 extended or IEEE binary128) we test
@@ -2292,7 +2293,7 @@ static const long double ld1c =
182358152808745703724362178773168996492870519432472065091133\
11767578125001e-4966L;
/* 0x1.8p-16494 */
-static const long double ld2ae = 0x1p-16494L, ld2be = 0x2p-16494L, ld1ce =
0x2p-16494L;
+static const long double ld2ae = 0x1p-16494L, ld2be = 0x2p-16494L, ld2ce =
0x2p-16494L;
static const long double ld2a =
9.7127626791570376663866584373414698287493540070520215145348\
265837955593101861790565265072369149749103838172122152721795\
Re: wide-int, fortran
On Nov 23 2013, Andrew Pinski wrote: On Sat, Nov 23, 2013 at 12:16 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sat, Nov 23, 2013 at 11:21:21AM -0800, Mike Stump wrote: Richi has asked the we break the wide-int patch so that the individual port and front end maintainers can review their parts without have to go through the entire patch. This patch covers the fortran front end. Ok? + *logical = wi::eq_p (t, 0) ? 0 : 1; I can't find the meaning of :: in n1256.pdf. What does this do? wi:: eq_p means the function eq_p inside the wi struct. But you can't tell that from the code - wi might be a namespace, and eq_p might be a class. If there is a clear description of the subset of C++ that the front-end is allowed to use, a pointer to it for the benefit of Fortran/C/Ada/whatever people would be useful. But that's an aside from this thread. Also, given the complete lack of a description of what this patch does and no pointer to a discussion of what this patch does, and no description of its benefit to gfortran, I vote no. The general description was in a different email: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02877.html The main benefit is it allows for targets to support wider integer than two times HOST_WIDE_INT. So gfortran, is that it connects to the rest of the middle-end of GCC. Hmm. Looking at that makes me none the wiser, and even a web search doesn't do more than tell me the same aspects. Given that Fortran has somewhat different constraints on type widths than C, it would be very useful to know exactly what you mean by that. C++ is almost entirely irrelevant here. Now, obviously to an implementor, it doesn't mean unlimited-width types, but does it (a) allow implementations to use hardware/firmware/emulated built-in types however wide they are, (b) allow arbitrary-width types, or (c) something else? In all cases, I can see implementation issues in gfortran that do not arise in gcc, but they are different between those models. So I agree that some clarification would be a good idea, to avoid introducing secondary problems by accident. Quite likely there will be none, but it's hard to tell. Regards, Nick Maclaren.
Re: wide-int, i386
We did not do this kind of transformation for any port beyond the minimum of having the port use wide-int rather than double-int. we did do a lot of this in the common code, especially in the code that was just not correct for types beyond 64 bits. Our motivation was that this is already a huge patch and going down that road for some of the crusty old ports would have made the patch just bigger. so we limited ourselves to the places in the common code that were obstructions to port writers to make large types work. I should point out that there are even a lot of places in the common code where we left the old code alone as long as it was correct for larger types. For testing purposes, we made no changes that were not bit for bit compatible for code of 64 bits or shorter. There are some places where the right transformation would yield better code, but we left those for later so we could test this patch in a sane way. Kenny On Nov 24, 2013, at 3:34 AM, Uros Bizjak ubiz...@gmail.com wrote: On Sat, Nov 23, 2013 at 8:22 PM, Mike Stump mikest...@comcast.net wrote: Richi has asked the we break the wide-int patch so that the individual port and front end maintainers can review their parts without have to go through the entire patch.This patch covers the i386 port. Should this patch also address construction of 128bit immediates? One example is in ix86_build_signbit_mask, where we have to use special tricks to create them. You can find other interesting places by grepping config/i386/* sources for HOST_BITS_PER_WIDE_INT checks. These remains from times when wide_int was 32 for i686 host, and IMO should be addressed by wide-int patch. Thanks, Uros.
Re: gcc/invoke.texi: Add missing @opindex
Tobias Burnus wrote:
While looking at the index for -fsanitize=, I found out that it – and
many other options – lack the @opindex. Attached is an attempted to
add the missing ones.
Updated patch: I also observed some odd *-fsanitize=null output in
the man page; Manuel suggested a fix which indeed works (using
@gcctabopt), which I now also include.
OK for the trunk?
Tobias
2013-11-24 Tobias Burnus bur...@net-b.de
Manuel López-Ibáñez m...@gcc.gnu.org
PR middle-end/59257
* doc/invoke.texi: Add missing @opindex.
(-fsanitize=): Use @gcctabopt instead of @itemize.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 0708836..f00bbf2 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1500,6 +1500,7 @@ This invokes all subprograms of @command{gcc} under
@samp{gdb --args cc1 @dots{}}.
@item -fplugin=@var{name}.so
+@opindex fplugin
Load the plugin code in file @var{name}.so, assumed to be a
shared object to be dlopen'd by the compiler. The base name of
the shared object file is used to identify the plugin for the
@@ -1509,15 +1510,18 @@ Each plugin should define the callback functions specified in the
Plugins API.
@item -fplugin-arg-@var{name}-@var{key}=@var{value}
+@opindex fplugin-arg
Define an argument called @var{key} with a value of @var{value}
for the plugin called @var{name}.
@item -fdump-ada-spec@r{[}-slim@r{]}
+@opindex fdump-ada-spec
For C and C++ source and include files, generate corresponding Ada
specs. @xref{Generating Ada Bindings for C and C++ headers,,, gnat_ugn,
GNAT User's Guide}, which provides detailed documentation on this feature.
@item -fdump-go-spec=@var{file}
+@opindex fdump-go-spec
For input files in any language, generate corresponding Go
declarations in @var{file}. This generates Go @code{const},
@code{type}, @code{var}, and @code{func} declarations which may be a
@@ -1751,6 +1755,7 @@ arguments followed by their declarations is also provided, inside
comments, after the declaration.
@item -fallow-parameterless-variadic-functions
+@opindex fallow-parameterless-variadic-functions
Accept variadic functions without named parameters.
Although it is possible to define such a function, this is not very
@@ -2392,7 +2397,7 @@ Note: This feature APPENDS data to the log file. If you want a fresh log
file, be sure to delete any existing one.
@item -fvtv-counts
-@opindex (fvtv-counts)
+@opindex fvtv-counts
This is a debugging flag. When used in conjunction with
@option{-fvtable-verify=std} or @option{-fvtable-verify=preinit}, this
causes the compiler to keep track of the total number of virtual calls
@@ -3490,6 +3495,8 @@ Options,,Options Controlling C Dialect}.
@table @gcctabopt
@item -Wformat=1
@itemx -Wformat
+@opindex Wformat
+@opindex Wformat=1
Option @option{-Wformat} is equivalent to @option{-Wformat=1}, and
@option{-Wno-format} is equivalent to @option{-Wformat=0}. Since
@option{-Wformat} also checks for null format arguments for several
@@ -3528,6 +3535,7 @@ The C standard specifies that zero-length formats are allowed.
@item -Wformat=2
+@opindex Wformat=2
Enable @option{-Wformat} plus additional format checks. Currently
equivalent to @option{-Wformat -Wformat-nonliteral -Wformat-security
-Wformat-y2k}.
@@ -5258,18 +5266,21 @@ many times it is given. This is mainly intended to be used with
@option{-fcompare-debug}.
@item -fsanitize=address
+@opindex fsanitize=address
Enable AddressSanitizer, a fast memory error detector.
Memory access instructions will be instrumented to detect
out-of-bounds and use-after-free bugs.
See @uref{http://code.google.com/p/address-sanitizer/} for more details.
@item -fsanitize=thread
+@opindex fsanitize=thread
Enable ThreadSanitizer, a fast data race detector.
Memory access instructions will be instrumented to detect
data race bugs.
See @uref{http://code.google.com/p/data-race-test/wiki/ThreadSanitizer} for more details.
@item -fsanitize=leak
+@opindex fsanitize=leak
Enable LeakSanitizer, a memory leak detector.
This option only matters for linking of executables and if neither
@option{-fsanitize=address} nor @option{-fsanitize=thread} is used. In that
@@ -5277,43 +5288,49 @@ case it will link the executable against a library that overrides @code{malloc}
and other allocator functions.
@item -fsanitize=undefined
+@opindex fsanitize=undefined
Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector.
Various computations will be instrumented to detect undefined behavior
at runtime. Current suboptions are:
-@itemize @bullet
+@table @gcctabopt
-@item @option{-fsanitize=shift}
+@item -fsanitize=shift
+@opindex fsanitize=shift
This option enables checking that the result of a shift operation is
not undefined. Note that what exactly is considered undefined differs
slightly between C and C++, as well as between ISO C90 and C99, etc.
-@item @option{-fsanitize=integer-divide-by-zero}
+@item
Re: wide-int, i386
On Sun, Nov 24, 2013 at 11:23 AM, Kenneth Zadeck zad...@naturalbridge.com wrote: We did not do this kind of transformation for any port beyond the minimum of having the port use wide-int rather than double-int. we did do a lot of this in the common code, especially in the code that was just not correct for types beyond 64 bits. Our motivation was that this is already a huge patch and going down that road for some of the crusty old ports would have made the patch just bigger. so we limited ourselves to the places in the common code that were obstructions to port writers to make large types work. I should point out that there are even a lot of places in the common code where we left the old code alone as long as it was correct for larger types. For testing purposes, we made no changes that were not bit for bit compatible for code of 64 bits or shorter. There are some places where the right transformation would yield better code, but we left those for later so we could test this patch in a sane way. I see. I was just wondering about those obvious places. The patch is fairly mechanical (BTW: there are some unnecessary whitespace changes that obscure real change), so it looks OK to me. Thanks, Uros.
Re: wide-int, fortran
Mike Stump wrote:
Richi has asked the we break the wide-int patch so that the individual port and
front end maintainers can review their parts without have to go through the
entire patch.This patch covers the fortran front end.
Nice clean up. The new class looks much cleaner as it avoids the LO/HI
handling.
- hi = TREE_INT_CST_HIGH (bound);
- low = TREE_INT_CST_LOW (bound);
- if (hi || low 0
- || ((!as || as-type != AS_ASSUMED_RANK)
- low = GFC_TYPE_ARRAY_RANK (TREE_TYPE (desc)))
- || low GFC_MAX_DIMENSIONS)
+ if (((!as || as-type != AS_ASSUMED_RANK)
+ wi::geu_p (bound, GFC_TYPE_ARRAY_RANK (TREE_TYPE (desc
+ || wi::gtu_p (bound, GFC_MAX_DIMENSIONS))
gfc_error ('dim' argument of %s intrinsic at %L is not a valid
dimension index, upper ? UBOUND : LBOUND,
expr-where);
I don't see what happened to the low 0 check. (Ditto for the next chunk in
conv_intrinsic_cobound).
Otherwise, it looks okay to me.
Tobias
Re: [wwwdocs] Announce Build Robot
On Sat, 23 Nov 2013, Jan-Benedict Glaw wrote: Now that it's nicely working, I'd like to publically announce the Build Robot. As suggested, here's a patch adding it to GCC's homepage's Development section as well as to the News: Agreed. +dtspanToolchain Build Robot/span +span class=date[2013-11-23]/span/dt +ddThe a href=http://toolchain.lug-owl.de/buildbot/;Build Robot/a is + mass-compiling GCC (stage1 only) using contrib/config-list.mk and a + custom script on different build slaves./dd On this announcement, I'd focus on why this is important/cool (using... - regularly, catching... or something like that, less the technical details). Ok? Yes, modulo the above. Thanks! Gerald
Re: wide-int, arc
On 24 November 2013 02:57, Kenneth Zadeck zad...@naturalbridge.com wrote: if the compiler produced an error message about not finding something, we added the include. If you can't tell what you need/should include by what you use, that leads to fragile design. It is possible that some of these may be redundant as things have moved around, but safety is not an issue. I mean safe as in robust design. If the only way to tell if you need the include is if you get an error message otherwise, things might break when other includes are removed / moved around in the including file, or if an implementation in the included files changes.
Re: wide-int, i386
On 11/24/2013 05:47 AM, Uros Bizjak wrote: On Sun, Nov 24, 2013 at 11:23 AM, Kenneth Zadeck zad...@naturalbridge.com wrote: We did not do this kind of transformation for any port beyond the minimum of having the port use wide-int rather than double-int. we did do a lot of this in the common code, especially in the code that was just not correct for types beyond 64 bits. Our motivation was that this is already a huge patch and going down that road for some of the crusty old ports would have made the patch just bigger. so we limited ourselves to the places in the common code that were obstructions to port writers to make large types work. I should point out that there are even a lot of places in the common code where we left the old code alone as long as it was correct for larger types. For testing purposes, we made no changes that were not bit for bit compatible for code of 64 bits or shorter. There are some places where the right transformation would yield better code, but we left those for later so we could test this patch in a sane way. I see. I was just wondering about those obvious places. The patch is fairly mechanical (BTW: there are some unnecessary whitespace changes that obscure real change), so it looks OK to me. thanks. Thanks, Uros.
Re: wide-int, fortran
On 11/24/2013 05:16 AM, N.M. Maclaren wrote: On Nov 23 2013, Andrew Pinski wrote: On Sat, Nov 23, 2013 at 12:16 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sat, Nov 23, 2013 at 11:21:21AM -0800, Mike Stump wrote: Richi has asked the we break the wide-int patch so that the individual port and front end maintainers can review their parts without have to go through the entire patch. This patch covers the fortran front end. Ok? + *logical = wi::eq_p (t, 0) ? 0 : 1; I can't find the meaning of :: in n1256.pdf. What does this do? wi:: eq_p means the function eq_p inside the wi struct. But you can't tell that from the code - wi might be a namespace, and eq_p might be a class. If there is a clear description of the subset of C++ that the front-end is allowed to use, a pointer to it for the benefit of Fortran/C/Ada/whatever people would be useful. But that's an aside from this thread. There is a saying in the US that you can always tell the pioneers because they are the ones with the arrows in their back. I feel this way with respect to C++. When this branch first went public several months ago, the wide-int class made very modest use of C++. It has publicly evolved away from that and i would now describe the usage as somewhat aggressive. I do not know if i think that this is good or bad, but i expect that because we are the first big patch to use C++ aggressively , that we are going to take some arrows. Also, given the complete lack of a description of what this patch does and no pointer to a discussion of what this patch does, and no description of its benefit to gfortran, I vote no. The general description was in a different email: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02877.html The main benefit is it allows for targets to support wider integer than two times HOST_WIDE_INT. So gfortran, is that it connects to the rest of the middle-end of GCC. Hmm. Looking at that makes me none the wiser, and even a web search doesn't do more than tell me the same aspects. Given that Fortran has somewhat different constraints on type widths than C, it would be very useful to know exactly what you mean by that. C++ is almost entirely irrelevant here. A useful way to think about this patch is that it is nothing but plumbing.Gcc has had a painful and long evolution from being a 32 bit compiler to a 64 bit compiler and beyond.The primary goal of this patch is change the underlying data structures used to represent integer constants from being either single host wide ints (that were limited to 64 bits) and double-int (that worked reliably for 127 bits and mostly ok for 128 bits) to a data structure that would just work reliably for any precision integer that a back end supported. But at both ends of the compiler there are still limits.It is expected that with this patch in place, that a back end maintainer can now, for the first time, support architectures that support integers wider than 128 bits. We have several public ports that appear to have tried to support some operations on 256 bits but when we tried this on our private port, we found an intolerable number of ices and incorrect code issues.They are now gone. To the extent that this patch touches the front ends, this patch is strictly plumbing. The front ends now use the new wide-int class, or the new int-cst to pass integer constants around and do constant prop on them.Beyond that, it is up to the front end maintainers to decide how or even if they will expose this to the users of the language. C and C++ currently allow the back end to tell it that they can use wider types but actually specifying a large integer constant is at best painful. Now, obviously to an implementor, it doesn't mean unlimited-width types, but does it (a) allow implementations to use hardware/firmware/emulated built-in types however wide they are, (b) allow arbitrary-width types, or (c) something else? In all cases, I can see implementation issues in gfortran that do not arise in gcc, but they are different between those models. the patch sniffs the port (in particular, it looks at the extra modes specified by the port), and allows integers that are some multiple of size of the largest mode specified by the back end. In this way ports for small machines pay less of price than the big ports will. One could imagine that this is not good enough if a front end wanted to say that it supports everything up to 256 bits no matter what the hardware can do natively, much the way that java said that every host had to do 64 bit math, even if it was just a 32 bit host. However, that would require a lot more work than was done here. In particular, at some level someone would have to sniff the port and break the math into pieces that could be implemented on the port. So I agree that some clarification would be a good idea, to avoid introducing secondary problems by
Re: wide-int, fortran
On 11/24/2013 05:50 AM, Tobias Burnus wrote:
Mike Stump wrote:
Richi has asked the we break the wide-int patch so that the
individual port and front end maintainers can review their parts
without have to go through the entire patch.This patch covers the
fortran front end.
Nice clean up. The new class looks much cleaner as it avoids the LO/HI
handling.
- hi = TREE_INT_CST_HIGH (bound);
- low = TREE_INT_CST_LOW (bound);
- if (hi || low 0
- || ((!as || as-type != AS_ASSUMED_RANK)
- low = GFC_TYPE_ARRAY_RANK (TREE_TYPE (desc)))
- || low GFC_MAX_DIMENSIONS)
+ if (((!as || as-type != AS_ASSUMED_RANK)
+wi::geu_p (bound, GFC_TYPE_ARRAY_RANK (TREE_TYPE (desc
+ || wi::gtu_p (bound, GFC_MAX_DIMENSIONS))
gfc_error ('dim' argument of %s intrinsic at %L is not a valid
dimension index, upper ? UBOUND : LBOUND,
expr-where);
I don't see what happened to the low 0 check. (Ditto for the next
chunk in conv_intrinsic_cobound).
Otherwise, it looks okay to me.
Tobias
This is the magic of using the correct representation. All this code
really wanted to check is that bound is a small positive integer.
Re: [RFC] replace malloc with a decl on the stack
On 11/12/2013 04:22 PM, Marc Glisse wrote: On Tue, 12 Nov 2013, Ondřej Bílka wrote: Anyway you need a better analysis to determine if user called realloc on converted pointer. Note that I am checking if the argument of free is the same as the return value of malloc by looking at the SSA_NAME, not the C variable. If the user called realloc on this value and then calls free on the same value on all paths (including those where realloc returned a different value), that's a broken program to start with. But indeed my current patch fails on: p=malloc(12); q=realloc(p,16); if(p==q)free(p); exit(0); because I (wrongly apparently) considered exit as safe as free :-( Strictly speaking, this code is equivalent to: p=malloc(12); q=realloc(p,16); free(p); exit(0); So I don't see how your optimization breaks it if it is applied to it. :) p==q is undefined if the realloc call returned a different pointer. Past-realloc pointer uses are fairly common, though, and often used to adjust interior pointers. Empirically, this seem to work, although I wouldn't be surprised if we already have optimizations which make past-realloc pointer use undefined. (I don't think C provides a safe way to update interior pointers in place, FWIW.) -- Florian Weimer / Red Hat Product Security Team
Re: [PATCH] C++-ify and simplify loop iterators
On Tue, Nov 19, 2013 at 7:19 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Nov 19, 2013 at 7:01 AM, Richard Biener rguent...@suse.de wrote:
$subject - the following turns
loop_iterator li;
FOR_EACH_LOOP (li, loop, LI_ONLY_INNERMOST)
{
...
if ()
FOR_EACH_LOOP_BREAK;
}
into
FOR_EACH_LOOP (loop, LI_ONLY_INNERMOST)
{
...
if ()
break;
}
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2013-11-19 Richard Biener rguent...@suse.de
* cfgloop.h (struct loop_iterator): C++-ify, add constructor
and destructor and make fel_next a member function.
(fel_next): Transform into ...
(loop_iterator::next): ... this.
(fel_init): Transform into ...
(loop_iterator::loop_iterator): ... this.
(loop_iterator::~loop_iterator): New.
(FOR_EACH_LOOP): Remove loop-iterator argument.
(FOR_EACH_LOOP_BREAK): Remove no longer necessary macro.
* cfgloop.c, cfgloopmanip.c, config/mn10300/mn10300.c,
graphite-clast-to-gimple.c, graphite-scop-detection.c,
graphite-sese-to-poly.c, ipa-inline-analysis.c, ipa-pure-const.c,
loop-init.c, loop-invariant.c, loop-unroll.c, loop-unswitch.c,
modulo-sched.c, predict.c, sel-sched-ir.c, tree-cfg.c,
tree-data-ref.c,
tree-if-conv.c, tree-loop-distribution.c, tree-parloops.c,
tree-predcom.c, tree-scalar-evolution.c, tree-ssa-dce.c,
tree-ssa-loop-ch.c, tree-ssa-loop-im.c, tree-ssa-loop-ivcanon.c,
tree-ssa-loop-ivopts.c, tree-ssa-loop-manip.c, tree-ssa-loop-niter.c,
tree-ssa-loop-prefetch.c, tree-ssa-loop-unswitch.c,
tree-ssa-threadupdate.c, tree-vectorizer.c, tree-vrp.c: Adjust
uses of FOR_EACH_LOOP and remove loop_iterator variables. Replace
FOR_EACH_LOOP_BREAK with break.
This caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59199
H.J.
The checkin contains:
--- trunk/gcc/graphite-sese-to-poly.c 2013/11/19 15:02:27 205031
+++ trunk/gcc/graphite-sese-to-poly.c 2013/11/19 15:19:09 205032
@@ -56,6 +56,7 @@
#include domwalk.h
#include sese.h
#include tree-ssa-propagate.h
+#include expr.h
#ifdef HAVE_cloog
#include expr.h
which isn't in the patch and isn't necessary. I am checking
a patch to remove it.
--
H.J.
Re: wide-int, fortran
On Nov 24 2013, Kenneth Zadeck wrote: Thank you for your posting. That certainly clears up my understanding. If there is a clear description of the subset of C++ that the front-end is allowed to use, a pointer to it for the benefit of Fortran/C/Ada/whatever people would be useful. But that's an aside from this thread. There is a saying in the US that you can always tell the pioneers because they are the ones with the arrows in their back. I feel this way with respect to C++. When this branch first went public several months ago, the wide-int class made very modest use of C++. It has publicly evolved away from that and i would now describe the usage as somewhat aggressive. I do not know if i think that this is good or bad, but i expect that because we are the first big patch to use C++ aggressively , that we are going to take some arrows. I think that using C++ even slightly aggressively without first deciding the grounds rules is a seriously bad idea. The trouble about following random pioneers is that they are very likely to lead you into a swamp, with the loss of the whole expedition. And, with C++, that is more than just likely if you follow an adventurous pioneer rather than a cautious one - it's damn-near certain :-( A useful way to think about this patch is that it is nothing but plumbing.Gcc has had a painful and long evolution from being a 32 bit compiler to a 64 bit compiler and beyond. ... Yes, but that's not my point. The main problem is that integer constant expressions in C are limited to the built-in operators, of which the only tricky ones are division and remainder (and, occasionally, multiplication) - see C11 6.6#3. Fortran is not so limited, and there are much wider requirements for expression evaluation at compile time. But at both ends of the compiler there are still limits. And my point is that this is NOT an area that separates cleanly into front and back end! However, from your description, this is one component of any solution for gfortran, and it doesn't sound as if it will cause trouble until and unless someone wants to extend gfortran to wider types. They will then have to implement the other components Regards, Nick Maclaren.
Re: wide-int, dwarf
On 11/23/2013 09:55 PM, Kenneth Zadeck wrote: On 11/23/2013 08:47 PM, Jason Merrill wrote: So if the target supports wide ints you'll always use the scalar float code? Why does that do the right thing? if TARGET_SUPPORTS_WIDE_INT != 0, then integers are NEVER placed in const-doubles. large integers go into CONST_WIDE_INTS so this case always represents a floating point constant and nothing else. So yes. I think that you could argue that the comment above this frag needs to be rewritten because it is wrong if TARGET_SUPPORTS_WIDE_INT != 0. Please. OK with that change. Jason
Re: wide-int, fortran
Hi, On 2013-11-24 22:38, N.M. Maclaren wrote: The main problem is that integer constant expressions in C are limited to the built-in operators, of which the only tricky ones are division and remainder (and, occasionally, multiplication) - see C11 6.6#3. Fortran is not so limited, and there are much wider requirements for expression evaluation at compile time. please note that the standard-mandated compile-time evaluation is handled almost [*] entirely inside the Fortran frontend, viz. arith.c, resolve.c, simplify.c, intrinsic.c, maybe others, whereas the wide-int changes deal with the middle-end interface and touches none of these files. Cheers, - Tobi [*] TRANSFER the a special case because it needs to know memory layouts But at both ends of the compiler there are still limits. And my point is that this is NOT an area that separates cleanly into front and back end! However, from your description, this is one component of any solution for gfortran, and it doesn't sound as if it will cause trouble until and unless someone wants to extend gfortran to wider types. They will then have to implement the other components Regards, Nick Maclaren.
Re: [PATCH] C++-ify and simplify loop iterators
On Sun, Nov 24, 2013 at 5:29 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Nov 19, 2013 at 7:19 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Nov 19, 2013 at 7:01 AM, Richard Biener rguent...@suse.de wrote:
$subject - the following turns
loop_iterator li;
FOR_EACH_LOOP (li, loop, LI_ONLY_INNERMOST)
{
...
if ()
FOR_EACH_LOOP_BREAK;
}
into
FOR_EACH_LOOP (loop, LI_ONLY_INNERMOST)
{
...
if ()
break;
}
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2013-11-19 Richard Biener rguent...@suse.de
* cfgloop.h (struct loop_iterator): C++-ify, add constructor
and destructor and make fel_next a member function.
(fel_next): Transform into ...
(loop_iterator::next): ... this.
(fel_init): Transform into ...
(loop_iterator::loop_iterator): ... this.
(loop_iterator::~loop_iterator): New.
(FOR_EACH_LOOP): Remove loop-iterator argument.
(FOR_EACH_LOOP_BREAK): Remove no longer necessary macro.
* cfgloop.c, cfgloopmanip.c, config/mn10300/mn10300.c,
graphite-clast-to-gimple.c, graphite-scop-detection.c,
graphite-sese-to-poly.c, ipa-inline-analysis.c, ipa-pure-const.c,
loop-init.c, loop-invariant.c, loop-unroll.c, loop-unswitch.c,
modulo-sched.c, predict.c, sel-sched-ir.c, tree-cfg.c,
tree-data-ref.c,
tree-if-conv.c, tree-loop-distribution.c, tree-parloops.c,
tree-predcom.c, tree-scalar-evolution.c, tree-ssa-dce.c,
tree-ssa-loop-ch.c, tree-ssa-loop-im.c, tree-ssa-loop-ivcanon.c,
tree-ssa-loop-ivopts.c, tree-ssa-loop-manip.c,
tree-ssa-loop-niter.c,
tree-ssa-loop-prefetch.c, tree-ssa-loop-unswitch.c,
tree-ssa-threadupdate.c, tree-vectorizer.c, tree-vrp.c: Adjust
uses of FOR_EACH_LOOP and remove loop_iterator variables. Replace
FOR_EACH_LOOP_BREAK with break.
This caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59199
H.J.
The checkin contains:
--- trunk/gcc/graphite-sese-to-poly.c 2013/11/19 15:02:27 205031
+++ trunk/gcc/graphite-sese-to-poly.c 2013/11/19 15:19:09 205032
@@ -56,6 +56,7 @@
#include domwalk.h
#include sese.h
#include tree-ssa-propagate.h
+#include expr.h
#ifdef HAVE_cloog
#include expr.h
which isn't in the patch and isn't necessary. I am checking
a patch to remove it.
This is the patch I checked in.
--
H.J.
---
Index: ChangeLog
===
--- ChangeLog(revision 205331)
+++ ChangeLog(working copy)
@@ -1,3 +1,7 @@
+2013-11-24 H.J. Lu hongjiu...@intel.com
+
+* graphite-sese-to-poly.c: Don't include extra expr.h.
+
2013-11-23 Eric Botcazou ebotca...@adacore.com
* cilk-common.c (expand_builtin_cilk_detach): Dereference worker.
Index: graphite-sese-to-poly.c
===
--- graphite-sese-to-poly.c(revision 205331)
+++ graphite-sese-to-poly.c(working copy)
@@ -61,7 +61,6 @@ along with GCC; see the file COPYING3.
#include domwalk.h
#include sese.h
#include tree-ssa-propagate.h
-#include expr.h
#ifdef HAVE_cloog
#include expr.h
Re: [fortran,patch] Remove unused gfc_open_intrinsic_module()
Hi FX, A quick grep through the front-end indicates that gfc_open_intrinsic_module() is never used. Should it have been removed when module file reading/writing was overhauled? I suspect the answer is yes”. Here’s a patch that removes it. It buils fine. OK to commit? OK. Thanks for the patch! Thomas
Re: [Patch, Fortran, OOP] PR 59143: Bogus warning with array-valued type-bound procedure
ping! 2013/11/18 Janus Weil ja...@gcc.gnu.org: Hi all, here is a straightforward patch to teach 'get_expr_storage_size' about type-bound procedures (which are handled internally as procedure-pointer components of the corresponding vtab). In that sense the patch should handle both TBPs as well as PPCs. Regtested on x86_64-unknown-linux-gnu. Ok for trunk? Cheers, Janus 2013-11-18 Janus Weil ja...@gcc.gnu.org PR fortran/59143 * interface.c (get_expr_storage_size): Handle array-valued type-bound procedures. 2013-11-18 Janus Weil ja...@gcc.gnu.org PR fortran/59143 * gfortran.dg/typebound_proc_30.f90: New.
Re: [fortran,patch] Remove unused gfc_open_intrinsic_module()
OK. Thanks for the patch! Committed as rev. 205335.
[Google] Increase max-lipo-mem default to 4000000
The current default is 300, but increasing to 4M gives better performance on internal applications and benchmarks. Passes regression testing. Ok for google/4_8? Thanks, Teresa 2013-11-24 Teresa Johnson tejohn...@google.com * params.def (PARAM_MAX_LIPO_MEMORY): Increase default to 4M. Index: params.def === --- params.def (revision 205234) +++ params.def (working copy) @@ -972,7 +972,7 @@ DEFPARAM (PARAM_MAX_LIPO_GROUP, DEFPARAM (PARAM_MAX_LIPO_MEMORY, max-lipo-mem, don't import aux files if memory consumption exceeds this value, - 300, 0, 0) + 400, 0, 0) /* In LIPO profile-gen, use this parameter to record the cutoff value used at profile collection runtime. */ -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
Re: [PATCH] RTEMS: Add LEON3/SPARC multilibs
Everything is clean on SPARC/Solaris and SPARC64/Solaris as well so I have no objections to backporting the whole set from a SPARC maintainership viewpoint (and we have been using something equivalent at AdaCore for some time without any problems so far). But we need the blessing of the RMs I guess here. Applied on the 4.8 branch after full testing on x86-64/Linux, SPARC/Solaris and SPARC64/Solaris. Thanks for the patches. -- Eric Botcazou
Re: [PATCH] Improve { x, x + 3, x + 6, x + 9 } expansion (take 2)
On Thu, Nov 21, 2013 at 11:37 AM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Nov 21, 2013 at 07:43:35AM +1000, Richard Henderson wrote:
On 11/20/2013 07:44 PM, Jakub Jelinek wrote:
On Wed, Nov 20, 2013 at 10:31:38AM +0100, Richard Biener wrote:
Aww ;) Nice improvement. Generally when I see this I always wonder
whether we want to do this kind of stuff pre RTL expansion.
1st to not rely on being able to TER, 2nd to finally eventually
get rid of TER.
These patches are unfortunately a step backward for #2.
As of the patch, do we have a way to query whether the target
can efficiently broadcast? If so this IMHO belongs in generic
We don't. Perhaps if we'd add optab for vec_dupmode and mentioned
clearly in the documentation that it should be used only if it is
reasonably
efficient. But still, even with optab, it would probably better to do it
in the veclower* passes than in the vectorizer itself.
I think we can assume that broadcast is relatively efficient, whether or not
vec_dup is present. I'd lean to making the transformation generic to start
with, so that you don't need extra handling in the i386 backend.
Ok, here is a generic veclower implementation without looking at any optabs,
so far only handles PLUS_EXPR, what operation other than MULT_EXPR would
make sense here? Though, handling MULT_EXPR also would complicate the code
slightly (it would need to handle say:
_2 = _1(D) + 1;
_3 = _2 + 2;
_4 = _3 * 2;
_5 = _4 * 3;
_6 = { _3, _4, _5, _4 };
where we could start thinking first the operation is PLUS_EXPR, but it
actually is MULT_EXPR with _3 as base). Also, for MULT_EXPR, supposedly
we could handle some values to be constant 0, like in:
_2 = _1(D) * 5;
_3 = _2 * 2;
_4 = _1(D) * 10;
_5 = { _3, 0, _4, _2, _1(D), 0, _4, _2 };
Bootstrap/regtest pending, ok at least for this for the start and can be
improved later on?
2013-11-21 Jakub Jelinek ja...@redhat.com
* tree-vect-generic.c (optimize_vector_constructor): New function.
(expand_vector_operations_1): Call it.
* gcc.dg/vect/vect-124.c: New test.
--- gcc/tree-vect-generic.c.jj 2013-11-19 21:56:40.0 +0100
+++ gcc/tree-vect-generic.c 2013-11-21 11:17:55.146118161 +0100
@@ -988,6 +988,84 @@ expand_vector_operation (gimple_stmt_ite
gimple_assign_rhs1 (assign),
gimple_assign_rhs2 (assign), code);
This patch caused PR 59273 [1] on alpha-linux-gnu.
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59273
Uros.
[PATCH] Use DW_LANG_D for D
Hi,
This patches gen_compile_unit_die to use the DW_LANG_D DWARF language
code for D. Is in relation to some other D language fixes that are
going to be submitted to gdb.
Regards
Iain.
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 3448ec4..ddbf5de 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -19257,6 +19257,8 @@ gen_compile_unit_die (const char *filename)
{
if (strcmp (language_string, GNU Ada) == 0)
language = DW_LANG_Ada95;
+ else if (strcmp (language_string, GNU D) == 0)
+ language = DW_LANG_D;
else if (strcmp (language_string, GNU Fortran) == 0)
language = DW_LANG_Fortran95;
else if (strcmp (language_string, GNU Java) == 0)
Re: wide-int, fortran
Am 24.11.2013 13:56, schrieb Kenneth Zadeck:
On 11/24/2013 05:50 AM, Tobias Burnus wrote:
- if (hi || low 0
...
+ if (((!as || as-type != AS_ASSUMED_RANK)
+ wi::geu_p (bound, GFC_TYPE_ARRAY_RANK (TREE_TYPE (desc
+ || wi::gtu_p (bound, GFC_MAX_DIMENSIONS))
gfc_error ('dim' argument of %s intrinsic at %L is not a valid
dimension index, upper ? UBOUND : LBOUND,
expr-where);
I don't see what happened to the low 0 check. (Ditto for the next
chunk in conv_intrinsic_cobound).
Otherwise, it looks okay to me.
This is the magic of using the correct representation. All this code
really wanted to check is that bound is a small positive integer.
I think one of the problems I had with reviewing the patch – as others –
that there is no documentation for the functions provided by the patch
itself. I found the bits in the patch wide-int-wide.diffs.txt.bz2. (The
.bz2 successfully prevents that it is found by search engines, but
admittedly, I haven't tried to find it.)
Nice – albeit a bit intransparent – use of two's complement numbers and
casting to an unsigned number.
+/* Return true if X Y when both are treated as unsigned values. */
+template typename T1, typename T2
+inline bool
+wi::gtu_p (const T1 x, const T2 y)
+{
+ return ltu_p (y, x);
Thus, the patch is okay from my side.
* * *
+ *logical = wi::eq_p (t, 0) ? 0 : 1;
I can't find the meaning of :: in n1256.pdf. What does this do?
wi:: eq_p means the function eq_p inside the wi struct.
I have to admit that I didn't quite understand the discussion about ISO
C/ISO C++11 as my impression is that wide-int-wide.diffs.txt.bz2 and not
the ISO standards matter here.
Also the discussion about unlimited-width types seems to be a bit off as
it is only about the use within the compiler (when the host lacks an
integer type the target has) and not about support for compiled code on
the target.
But maybe I have missed some fine print.
But at both ends of the compiler there are still limits. It is
expected that with this patch in place, that a back end maintainer can
now, for the first time, support architectures that support integers
wider than 128 bits. We have several public ports that appear to have
tried to support some operations on 256 bits but when we tried this on
our private port, we found an intolerable number of ices and incorrect
code issues. They are now gone.
To the extent that this patch touches the front ends, this patch is
strictly plumbing. The front ends now use the new wide-int class, or
the new int-cst to pass integer constants around and do constant prop
on them. Beyond that, it is up to the front end maintainers to decide
how or even if they will expose this to the users of the language. C
and C++ currently allow the back end to tell it that they can use
wider types but actually specifying a large integer constant is at
best painful.
I think the gfortran code currently implicitly assumes that the largest
integer is 128bits wide; adding basic support for larger integer kinds
is probably not difficult. However, the real work is to fully support it
with all intrinsics. Already for 128bit integers, some work is needed as
there for some of the intrinsics, a suitable builtin is lacking. (I
think gfortran is the only Fortran compiler which supports
128-bits/16-byte integers; at least all compilers I tried do not support
it.) – I think when GCC starts to get some better support for 256-bit
integers, gfortran will follow suite. (Or when someone explicitly
demands it.)
One could imagine that this is not good enough if a front end wanted
to say that it supports everything up to 256 bits no matter what the
hardware can do natively, much the way that java said that every host
had to do 64 bit math, even if it was just a 32 bit host. However,
that would require a lot more work than was done here. In particular,
at some level someone would have to sniff the port and break the math
into pieces that could be implemented on the port.
In particular, that requires some run-time support – probably both in
libgcc and in the handling of the backend itself. On x86-64, __float128
support already works that way. (And requires libquadmath to be fully
usable; for integers, it should be somewhat easier.)
Tobias
Re: [RFC] replace malloc with a decl on the stack
On Sun, 24 Nov 2013, Florian Weimer wrote:
On 11/12/2013 04:22 PM, Marc Glisse wrote:
On Tue, 12 Nov 2013, Ondřej Bílka wrote:
Anyway you need a better analysis to determine if user called realloc on
converted pointer.
Note that I am checking if the argument of free is the same as the
return value of malloc by looking at the SSA_NAME, not the C variable.
If the user called realloc on this value and then calls free on the same
value on all paths (including those where realloc returned a different
value), that's a broken program to start with. But indeed my current
patch fails on:
p=malloc(12);
q=realloc(p,16);
if(p==q)free(p);
exit(0);
because I (wrongly apparently) considered exit as safe as free :-(
Strictly speaking, this code is equivalent to:
p=malloc(12);
q=realloc(p,16);
free(p);
exit(0);
So I don't see how your optimization breaks it if it is applied to it. :)
p==q is undefined if the realloc call returned a different pointer.
Past-realloc pointer uses are fairly common, though, and often used to adjust
interior pointers. Empirically, this seem to work, although I wouldn't be
surprised if we already have optimizations which make past-realloc pointer
use undefined.
(I don't think C provides a safe way to update interior pointers in place,
FWIW.)
Hmm, true, though I wouldn't feel very comfortable breaking code that
checks if the return value of realloc differs from its argument (I may
have used this myself once or twice, and I am not aware of existing
optimizations that would break it).
I can also change the example to this more valid code:
p=malloc(12);
if(whatever)
free(p);
else
{
q=copy(p); // copy just returns its argument
free(q);
exit(0);
}
where if I considered exit as safe, I would turn it into:
unsigned char tab[12]__attribute__((aligned(16)));
p=tab;
if(!whatever)
{
q=copy(p);
free(q);
exit(0);
}
which is clearly wrong. __builtin_unreachable might still be ok though.
To counter this, it may help to maintain a property of whether the program
may have freed a possibly aliasing pointer sometime between the relevant
malloc and here.
Other painful cases:
p=malloc(12);
secretly_free(p);
while(true){...} // infinite loop
free(p);
which I would turn into:
p=tab;
secretly_free(p);
while(true){...}
which would crash before even starting the infinite loop.
Raising a signal (say by dereferencing a null pointer) and catching it
elsewhere is another way to avoid reaching the call to free that I am
using to prove the transformation is ok.
I am attaching a more recent version of the patch that shouldn't ICE as
much.
--
Marc GlisseIndex: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 205333)
+++ gcc/c-family/c-common.c (working copy)
@@ -371,20 +371,21 @@ static tree handle_warn_unused_result_at
static tree handle_sentinel_attribute (tree *, tree, tree, int, bool *);
static tree handle_type_generic_attribute (tree *, tree, tree, int, bool *);
static tree handle_alloc_size_attribute (tree *, tree, tree, int, bool *);
static tree handle_target_attribute (tree *, tree, tree, int, bool *);
static tree handle_optimize_attribute (tree *, tree, tree, int, bool *);
static tree ignore_attribute (tree *, tree, tree, int, bool *);
static tree handle_no_split_stack_attribute (tree *, tree, tree, int, bool *);
static tree handle_fnspec_attribute (tree *, tree, tree, int, bool *);
static tree handle_warn_unused_attribute (tree *, tree, tree, int, bool *);
static tree handle_returns_nonnull_attribute (tree *, tree, tree, int, bool *);
+static tree handle_attribute_default (tree *, tree, tree, int, bool *);
static tree handle_omp_declare_simd_attribute (tree *, tree, tree, int,
bool *);
static tree handle_omp_declare_target_attribute (tree *, tree, tree, int,
bool *);
static tree handle_bnd_variable_size_attribute (tree *, tree, tree, int, bool
*);
static tree handle_bnd_legacy (tree *, tree, tree, int, bool *);
static void check_function_nonnull (tree, int, tree *);
static void check_nonnull_arg (void *, tree, unsigned HOST_WIDE_INT);
static bool nonnull_check_p (tree, unsigned HOST_WIDE_INT);
@@ -760,20 +761,22 @@ const struct attribute_spec c_common_att
{ no_split_stack,0, 0, true, false, false,
handle_no_split_stack_attribute, false },
/* For internal use (marking of builtins and runtime functions) only.
The name contains space to prevent its usage in source code. */
{ fn spec, 1, 1, false, true, true,
handle_fnspec_attribute, false },
{ warn_unused,0, 0, false, false, false,
handle_warn_unused_attribute, false },
{ returns_nonnull,0, 0, false, true, true,
Re: [Patch, Fortran, OOP] PR 59143: Bogus warning with array-valued type-bound procedure
Janus Weil wrote:
here is a straightforward patch to teach 'get_expr_storage_size' about
type-bound procedures (which are handled internally as
procedure-pointer components of the corresponding vtab). In that sense
the patch should handle both TBPs as well as PPCs.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
The patch is NOT okay:
+ else if (ref-type == REF_COMPONENT ref-u.c.component-attr.function
+ ref-u.c.component-attr.proc_pointer
+ ref-u.c.component-attr.dimension)
+ {
+ /* Array-valued procedure-pointer components. */
+ gfc_array_spec *as = ref-u.c.component-as;
+ for (i = 0; i as-rank; i++)
+ elements = elements
+ * (mpz_get_si (as-upper[i]-value.integer)
+ - mpz_get_si (as-lower[i]-value.integer) + 1L);
You cannot assume that the function returns an explicit size array with
constant bounds. The code simply breaks (ICE) if you use, e.g.,
call func1 (phs%decay_p (2))
with
function decay_p (n)
real :: decay_p(n)
decay_p = 1.
end function
or for instance
function decay_p (n)
real, allocatable :: decay_p(:)
decay_p = [1.]
end function
Tobias
Re: wide-int, fortran
On Sun, Nov 24, 2013 at 2:38 PM, N.M. Maclaren wrote: The main problem is that integer constant expressions in C are limited to the built-in operators, of which the only tricky ones are division and remainder (and, occasionally, multiplication) - see C11 6.6#3. Fortran is not so limited, and there are much wider requirements for expression evaluation at compile time. In gfortran there's been effectively no limit on the size of integers since the beginning, because all integers are represented as mpz (i.e. GMP integers) values. In fact, I'm a bit surprised that the wide_int stuff isn't also based on GMP's integer representation, but oh well... Point is, this wide_int stuff is for the interface between gfortran as a front end on one side, and the rest of gcc (middle end) on the other. At the hand-over point, gfortran will already have handled more complex integer constant expressions as much as possible. Ciao! Steven
[committed] invoke.texi: For -fsanitize=leak link to https://code.google.com/p/address-sanitizer/wiki/LeakSanitizer
Committed as obvious: Rev. 205336.
Tobias
2013-11-24 Tobias Burnus bur...@net-b.de
* doc/invoke.texi (-fsanitize=leak): Add link to the wiki page.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index f00bbf2..1afc9e3 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -5279,3 +5279,4 @@ Memory access instructions will be instrumented to detect
data race bugs.
-See @uref{http://code.google.com/p/data-race-test/wiki/ThreadSanitizer} for more details.
+See @uref{http://code.google.com/p/data-race-test/wiki/ThreadSanitizer} for
+more details.
@@ -5287,3 +5288,5 @@ This option only matters for linking of executables and if neither
case it will link the executable against a library that overrides @code{malloc}
-and other allocator functions.
+and other allocator functions. See
+@uref{https://code.google.com/p/address-sanitizer/wiki/LeakSanitizer} for more
+details.
invoke.texi: Sanitizer – update link, mention environment variables and link to wiki page with the flags
As the subject says.
OK for the trunk?
Tobias
2013-11-24 Tobias Burnus bur...@net-b.de
PR sanitizer/59275
* doc/invoke.texi (-fsanitize=address,leak): Mention the associated
environment variable and link to a list with flags.
(-fsanitize=thread): Ditto and update link.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 568c90d..fbf111c 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -5261,14 +5261,20 @@ many times it is given. This is mainly intended to be used with
Enable AddressSanitizer, a fast memory error detector.
Memory access instructions will be instrumented to detect
out-of-bounds and use-after-free bugs.
-See @uref{http://code.google.com/p/address-sanitizer/} for more details.
+See @uref{http://code.google.com/p/address-sanitizer/} for
+more details. The run-time behavior can be influenced using the
+@env{ASAN_OPTIONS} environment variable; see
+@url{https://code.google.com/p/address-sanitizer/wiki/Flags#Run-time_flags} for
+a list of supported options.
@item -fsanitize=thread
Enable ThreadSanitizer, a fast data race detector.
Memory access instructions will be instrumented to detect
-data race bugs.
-See @uref{http://code.google.com/p/data-race-test/wiki/ThreadSanitizer} for
-more details.
+data race bugs. See @uref{http://code.google.com/p/thread-sanitizer/} for more
+details. The run-time behavior can be influenced using the @env{TSAN_OPTIONS}
+environment variable; see
+@url{https://code.google.com/p/thread-sanitizer/wiki/Flags} for a list of
+supported options.
@item -fsanitize=leak
Enable LeakSanitizer, a memory leak detector.
@@ -5277,7 +5283,9 @@ This option only matters for linking of executables and if neither
case it will link the executable against a library that overrides @code{malloc}
and other allocator functions. See
@uref{https://code.google.com/p/address-sanitizer/wiki/LeakSanitizer} for more
-details.
+details. The run-time behavior can be influenced using the
+@env{LSAN_OPTIONS} environment variable; see @option{-fsanitize=address}
+for the supported options.
@item -fsanitize=undefined
Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector.
Re: invoke.texi: Sanitizer – update link, mention environment variables and link to wiki page with the flags
I am not sure about the lsan part. Sergey? The rest looks good. On Sun, Nov 24, 2013 at 8:44 PM, Tobias Burnus bur...@net-b.de wrote: As the subject says. OK for the trunk? Tobias
Re: [wwwdocs] Announce Build Robot
On Sun, 2013-11-24 12:14:19 +0100, Gerald Pfeifer ger...@pfeifer.com wrote: On Sat, 23 Nov 2013, Jan-Benedict Glaw wrote: +dtspanToolchain Build Robot/span +span class=date[2013-11-23]/span/dt +ddThe a href=http://toolchain.lug-owl.de/buildbot/;Build Robot/a is + mass-compiling GCC (stage1 only) using contrib/config-list.mk and a + custom script on different build slaves./dd On this announcement, I'd focus on why this is important/cool (using... - regularly, catching... or something like that, less the technical details). Ok? Yes, modulo the above. Thanks! Thanks, I just committed this: Index: htdocs/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.898 diff -u -p -r1.898 index.html --- htdocs/index.html 22 Nov 2013 11:50:45 - 1.898 +++ htdocs/index.html 24 Nov 2013 17:14:47 - @@ -53,6 +53,11 @@ mission statement/a./p dl class=news +dtspanToolchain Build Robot/span +span class=date[2013-11-24]/span/dt +ddThe a href=http://toolchain.lug-owl.de/buildbot/;Build Robot/a is + mass-compiling GCC (stage1 only) regularly, catching build errors early./dd + dtspanAndes NDS32 support/span span class=date[2013-10-31]/span/dt ddA port for nds32, the 32-bit architecture of AndesCore families, Index: htdocs/style.mhtml === RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v retrieving revision 1.122 diff -u -p -r1.122 style.mhtml --- htdocs/style.mhtml 27 Aug 2013 20:46:29 - 1.122 +++ htdocs/style.mhtml 24 Nov 2013 17:14:47 - @@ -214,6 +214,7 @@ a href=get-var BACKPATHbackends.htmlBack ends/abr / a href=get-var BACKPATHextensions.htmlExtensions/abr / a href=get-var BACKPATHbenchmarks/Benchmarks/abr / + a href=http://toolchain.lug-owl.de/buildbot/;Build Robot/abr / a href=get-var BACKPATHtranslation.htmlTranslations/abr / /td/tr /table/td/tr MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of:Don't believe in miracles: Rely on them! the second : signature.asc Description: Digital signature
[SH] Pass --isa to assembler
Hello,
Currently GCC doesn't pass the --isa parameter to the assembler for SH
targets other than SH2A and SH5. This makes the assembler accept any
kind of ISA and happily produce e.g. SH2A code even though the target is
SH4, which will then fail to link.
The attach patch fixes this by passing the --isa parameter also for -m1,
-m2*, -m3*, and -m4*.
It also caught a mistake in libgcc/crt1.S, where the SH3 / SH4 VBR setup
code was compiled for SH2E.
Tested with
make -k -j4 check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
and no new failures.
OK for trunk?
Cheers,
Oleg
gcc/ChangeLog:
* config/sh/sh.h (SH_ASM_SPEC): Handle m1, m2*, m3* and m4*
cases.
libgcc/ChangeLog:
* config/sh/crt1.S (start): Don't do VBR_SETUP for SH2E.
Index: gcc/config/sh/sh.h
===
--- gcc/config/sh/sh.h (revision 205315)
+++ gcc/config/sh/sh.h (working copy)
@@ -267,9 +267,25 @@
#define SUBTARGET_ASM_RELAX_SPEC %{m4*:-isa=sh4-up}
#endif
+/* Define which ISA type to pass to the assembler.
+ For SH4 we pass SH4A to allow using some instructions that are available
+ on some SH4 variants, but officially are part of the SH4A ISA. */
#define SH_ASM_SPEC \
%(subtarget_asm_endian_spec) %{mrelax:-relax %(subtarget_asm_relax_spec)} \
%(subtarget_asm_isa_spec) %(subtarget_asm_spec) \
+%{m1:--isa=sh} \
+%{m2:--isa=sh2} \
+%{m2e:--isa=sh2e} \
+%{m3:--isa=sh3} \
+%{m3e:--isa=sh3e} \
+%{m4:--isa=sh4a} \
+%{m4-single:--isa=sh4a} \
+%{m4-single-only:--isa=sh4a} \
+%{m4-nofpu:--isa=sh4a-nofpu} \
+%{m4a:--isa=sh4a} \
+%{m4a-single:--isa=sh4a} \
+%{m4a-single-only:--isa=sh4a} \
+%{m4a-nofpu:--isa=sh4a-nofpu} \
%{m2a:--isa=sh2a} \
%{m2a-single:--isa=sh2a} \
%{m2a-single-only:--isa=sh2a} \
Index: libgcc/config/sh/crt1.S
===
--- libgcc/config/sh/crt1.S (revision 205315)
+++ libgcc/config/sh/crt1.S (working copy)
@@ -697,8 +697,9 @@
start:
mov.l stack_k,r15
-#if defined (__SH3__) || (defined (__SH_FPU_ANY__) ! defined (__SH2A__)) || defined (__SH4_NOFPU__)
+#if defined (__SH3__) || (defined (__SH_FPU_ANY__) ! defined (__SH2E__) ! defined (__SH2A__)) || defined (__SH4_NOFPU__)
#define VBR_SETUP
+
! before zeroing the bss ...
! if the vbr is already set to vbr_start then the program has been restarted
! (i.e. it is not the first time the program has been run since reset)
[PATCH] Fix c++/59112 and c++/59113: Disallow implicit function templates in local functions unless defining a lambda.
gcc/cp/
PR c++/59112
PR c++/59113
* parser.c (cp_parser_parameter_declaration_clause): Disallow implicit
function templates in local functions unless defining a lambda.
gcc/testsuite/
PR c++/59112
PR c++/59113
g++.dg/cpp1y/pr58533.C: Updated testcase.
g++.dg/cpp1y/pr59112.C: New testcase.
g++.dg/cpp1y/pr59113.C: New testcase.
---
gcc/cp/parser.c | 4 +++-
gcc/testsuite/g++.dg/cpp1y/pr58533.C | 2 +-
gcc/testsuite/g++.dg/cpp1y/pr59112.C | 12
gcc/testsuite/g++.dg/cpp1y/pr59113.C | 11 +++
4 files changed, 27 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr59112.C
create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr59113.C
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index eaad8e4..1a26811 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -18026,7 +18026,9 @@ cp_parser_parameter_declaration_clause (cp_parser*
parser)
(void) cleanup;
if (!processing_specialization)
-parser-auto_is_implicit_function_template_parm_p = true;
+if (!current_function_decl
+ || (current_class_type LAMBDA_TYPE_P (current_class_type)))
+ parser-auto_is_implicit_function_template_parm_p = true;
/* Peek at the next token. */
token = cp_lexer_peek_token (parser-lexer);
diff --git a/gcc/testsuite/g++.dg/cpp1y/pr58533.C
b/gcc/testsuite/g++.dg/cpp1y/pr58533.C
index e1855d7..9bcd771 100644
--- a/gcc/testsuite/g++.dg/cpp1y/pr58533.C
+++ b/gcc/testsuite/g++.dg/cpp1y/pr58533.C
@@ -3,5 +3,5 @@
void foo()
{
- void (*fp)(auto); // { dg-error template }
+ void (*fp)(auto); // { dg-error auto|not permitted }
}
diff --git a/gcc/testsuite/g++.dg/cpp1y/pr59112.C
b/gcc/testsuite/g++.dg/cpp1y/pr59112.C
new file mode 100644
index 000..e7326ac
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/pr59112.C
@@ -0,0 +1,12 @@
+// { dg-do compile }
+// { dg-options -std=gnu++1y }
+
+// PR c++/59112
+
+void foo()
+{
+ struct A
+ {
+A(auto) {} // { dg-error auto|not permitted }
+ };
+}
diff --git a/gcc/testsuite/g++.dg/cpp1y/pr59113.C
b/gcc/testsuite/g++.dg/cpp1y/pr59113.C
new file mode 100644
index 000..f909a76
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/pr59113.C
@@ -0,0 +1,11 @@
+// { dg-do compile }
+// { dg-options -std=gnu++1y }
+
+// PR c++/59113
+
+void foo()
+{
+ void bar(auto) {} // { dg-error function-definition|auto|not permitted }
+}
+
+auto i = 0;
--
1.8.4
Re: [Google] Increase max-lipo-mem default to 4000000
Ok. David On Sun, Nov 24, 2013 at 6:50 AM, Teresa Johnson tejohn...@google.com wrote: The current default is 300, but increasing to 4M gives better performance on internal applications and benchmarks. Passes regression testing. Ok for google/4_8? Thanks, Teresa 2013-11-24 Teresa Johnson tejohn...@google.com * params.def (PARAM_MAX_LIPO_MEMORY): Increase default to 4M. Index: params.def === --- params.def (revision 205234) +++ params.def (working copy) @@ -972,7 +972,7 @@ DEFPARAM (PARAM_MAX_LIPO_GROUP, DEFPARAM (PARAM_MAX_LIPO_MEMORY, max-lipo-mem, don't import aux files if memory consumption exceeds this value, - 300, 0, 0) + 400, 0, 0) /* In LIPO profile-gen, use this parameter to record the cutoff value used at profile collection runtime. */ -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
PATCH: PR sanitizer/59136: llvm-symbolizer shouldn't be started always
Hi,
This patch adds --enable-llvm-symbolizer and disables llvm-symbolizer by
default. Without it, GCC sanitizer is unusable on systems with
unsupported /bin/llvm-symbolizer. OK to install?
Thanks.
H.J.
2013-11-24 H.J. Lu hongjiu...@intel.com
PR sanitizer/59136
* configure.ac: Add --enable-llvm-symbolizer. Disable
llvm-symbolizer by default. AC_SUBST disable_llvm_symbolizer.
* sanitizer_common/Makefile.am (DEFS): Add @disable_llvm_symbolizer@.
* configure: Regenerated.
* sanitizer_common/Makefile.in: Likewise.
* sanitizer_common/sanitizer_symbolizer_posix_libcdep.cc
(Symbolizer::InitializeExternal): Return false if
DISABLE_LLVM_SYMBOLIZER is defined.
diff --git a/libsanitizer/configure b/libsanitizer/configure
index 22f7fee..e360915 100755
--- a/libsanitizer/configure
+++ b/libsanitizer/configure
@@ -703,6 +703,7 @@ build_os
build_vendor
build_cpu
build
+disable_llvm_symbolizer
target_alias
host_alias
build_alias
@@ -745,6 +746,7 @@ ac_subst_files=''
ac_user_opts='
enable_option_checking
enable_version_specific_runtime_libs
+enable_llvm_symbolizer
enable_multilib
enable_maintainer_mode
enable_dependency_tracking
@@ -1391,6 +1393,7 @@ Optional Features:
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
--enable-version-specific-runtime-libsSpecify that runtime libraries
should be installed in a compiler-specific directory
+ --enable-llvm-symbolizer Enable llvm-symbolizer
--enable-multilib build many library versions (default)
--enable-maintainer-mode enable make rules and dependencies not useful
(and sometimes confusing) to the casual installer
@@ -2435,6 +2438,28 @@ fi
{ $as_echo $as_me:${as_lineno-$LINENO}: result: $version_specific_libs 5
$as_echo $version_specific_libs 6; }
+{ $as_echo $as_me:${as_lineno-$LINENO}: checking for
--enable-llvm-symbolizer 5
+$as_echo_n checking for --enable-llvm-symbolizer... 6; }
+# Check whether --enable-llvm-symbolizer was given.
+if test ${enable_llvm_symbolizer+set} = set; then :
+ enableval=$enable_llvm_symbolizer; case $enableval in
+ yes) enable_llvm_symbolizer=yes ;;
+ no) enable_llvm_symbolizer=no ;;
+ *) enable_llvm_symbolizer=no;;
+ esac
+else
+ enable_llvm_symbolizer=no
+fi
+
+{ $as_echo $as_me:${as_lineno-$LINENO}: result: $enable_llvm_symbolizer 5
+$as_echo $enable_llvm_symbolizer 6; }
+if test $enable_llvm_symbolizer = no; then
+ disable_llvm_symbolizer=-DDISABLE_LLVM_SYMBOLIZER
+else
+ disable_llvm_symbolizer=
+fi
+
+
# Do not delete or change the following two lines. For why, see
# http://gcc.gnu.org/ml/libstdc++/2003-07/msg00451.html
ac_aux_dir=
@@ -9,7 +11144,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat conftest.$ac_ext _LT_EOF
-#line 11122 configure
+#line 11147 configure
#include confdefs.h
#if HAVE_DLFCN_H
@@ -11225,7 +11250,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat conftest.$ac_ext _LT_EOF
-#line 11228 configure
+#line 11253 configure
#include confdefs.h
#if HAVE_DLFCN_H
diff --git a/libsanitizer/configure.ac b/libsanitizer/configure.ac
index f769fdb..492a5e2 100644
--- a/libsanitizer/configure.ac
+++ b/libsanitizer/configure.ac
@@ -16,6 +16,23 @@ AC_ARG_ENABLE(version-specific-runtime-libs,
[version_specific_libs=no])
AC_MSG_RESULT($version_specific_libs)
+AC_MSG_CHECKING([for --enable-llvm-symbolizer])
+AC_ARG_ENABLE(llvm-symbolizer,
+[ --enable-llvm-symbolizer Enable llvm-symbolizer],
+[case $enableval in
+ yes) enable_llvm_symbolizer=yes ;;
+ no) enable_llvm_symbolizer=no ;;
+ *) enable_llvm_symbolizer=no;;
+ esac],
+[enable_llvm_symbolizer=no])
+AC_MSG_RESULT($enable_llvm_symbolizer)
+if test $enable_llvm_symbolizer = no; then
+ disable_llvm_symbolizer=-DDISABLE_LLVM_SYMBOLIZER
+else
+ disable_llvm_symbolizer=
+fi
+AC_SUBST(disable_llvm_symbolizer)
+
# Do not delete or change the following two lines. For why, see
# http://gcc.gnu.org/ml/libstdc++/2003-07/msg00451.html
AC_CANONICAL_SYSTEM
diff --git a/libsanitizer/sanitizer_common/Makefile.am
b/libsanitizer/sanitizer_common/Makefile.am
index c4c3c5e..713b129 100644
--- a/libsanitizer/sanitizer_common/Makefile.am
+++ b/libsanitizer/sanitizer_common/Makefile.am
@@ -3,7 +3,7 @@ AM_CPPFLAGS = -I $(top_srcdir)/include
# May be used by toolexeclibdir.
gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER)
-DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS
+DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS @disable_llvm_symbolizer@
AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic
-Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti
-fomit-frame-pointer -funwind-tables
Re: PATCH: PR sanitizer/59136: llvm-symbolizer shouldn't be started always
On Sun, Nov 24, 2013 at 10:20:18AM -0800, H.J. Lu wrote: Hi, This patch adds --enable-llvm-symbolizer and disables llvm-symbolizer by default. Without it, GCC sanitizer is unusable on systems with unsupported /bin/llvm-symbolizer. OK to install? See http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02055.html and following thread, I hope in a week or so we will just use libbacktrace in GCC for symbolization. Jakub
Re: PATCH: PR sanitizer/59136: llvm-symbolizer shouldn't be started always
Besides all changes to .cc/.h files in libsanitizer should go thorough the upstream repo first and I generally dislike the change in libsanitizer/sanitizer_common/sanitizer_symbolizer_posix_libcdep.cc, we'll need to find another solution (using libbacktrace could be one; I am not so enthusiastic about it being easy, but will be glad to be wrong). --kcc On Sun, Nov 24, 2013 at 10:42 PM, Jakub Jelinek ja...@redhat.com wrote: On Sun, Nov 24, 2013 at 10:20:18AM -0800, H.J. Lu wrote: Hi, This patch adds --enable-llvm-symbolizer and disables llvm-symbolizer by default. Without it, GCC sanitizer is unusable on systems with unsupported /bin/llvm-symbolizer. OK to install? See http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02055.html and following thread, I hope in a week or so we will just use libbacktrace in GCC for symbolization. Jakub
[patch] contrib/config-list.mk: Allow to build all targets individually
Hi! For my Build Robot, I'd like to change contrib/config-list.mk to be more generally useable. This patch allows to override the defaults for $(host_options), which currently mentions mpc's location. The second change allows to print the list of buildable targets, which saves me the need to to a crude parsing of this make file. Finally, the patch changes the list of targets so that they don't contain the = character any more. You can use this make file to build individual targets like this: make -f ../gcc/contrib/config-list.mk log/targetname-make.out However, this does not work for target names with = in them (ie. arc-elf32OPT-with-cpu=arc600), because the output log filename would be parsed as a variable assignment. 2013-11-24 Jan-Benedict Glaw jbg...@lug-owl.de * config-list.mk (host_options): Allow to override it. (LIST): Change = to EQUAL. (list): New target listing all configurations. ($(LIST)): Substitute EQUAL back to =. diff --git a/contrib/config-list.mk b/contrib/config-list.mk index 23d6e4a..a4b8d6a 100644 --- a/contrib/config-list.mk +++ b/contrib/config-list.mk @@ -1,5 +1,5 @@ # Run tests covering all config.gcc cases. -host_options='--with-mpc=/opt/cfarm/mpc' # gcc10 +host_options ?= '--with-mpc=/opt/cfarm/mpc' # gcc10 TEST=all-gcc # Make sure you have a recent enough gcc (with ada support) in your path so # that --enable-werror-always will work. @@ -14,18 +14,18 @@ TEST=all-gcc LIST = aarch64-elf aarch64-linux-gnu \ alpha-linux-gnu alpha-freebsd6 alpha-netbsd alpha-openbsd \ alpha64-dec-vms alpha-dec-vms am33_2.0-linux \ - arc-elf32OPT-with-cpu=arc600 arc-elf32OPT-with-cpu=arc700 \ - arc-linux-uclibcOPT-with-cpu=arc700 arceb-linux-uclibcOPT-with-cpu=arc700 \ + arc-elf32OPT-with-cpuEQUALarc600 arc-elf32OPT-with-cpuEQUALarc700 \ + arc-linux-uclibcOPT-with-cpuEQUALarc700 arceb-linux-uclibcOPT-with-cpuEQUALarc700 \ arm-wrs-vxworks arm-netbsdelf \ arm-linux-androideabi arm-uclinux_eabi arm-eabi \ arm-symbianelf avr-rtems avr-elf \ bfin-elf bfin-uclinux bfin-linux-uclibc bfin-rtems bfin-openbsd \ c6x-elf c6x-uclinux cr16-elf cris-elf cris-linux crisv32-elf crisv32-linux \ - epiphany-elf epiphany-elfOPT-with-stack-offset=16 fido-elf \ + epiphany-elf epiphany-elfOPT-with-stack-offsetEQUAL16 fido-elf \ fr30-elf frv-elf frv-linux h8300-elf h8300-rtems hppa-linux-gnu \ - hppa-linux-gnuOPT-enable-sjlj-exceptions=yes hppa64-linux-gnu \ + hppa-linux-gnuOPT-enable-sjlj-exceptionsEQUALyes hppa64-linux-gnu \ hppa2.0-hpux10.1 hppa64-hpux11.3 \ - hppa64-hpux11.0OPT-enable-sjlj-exceptions=yes hppa2.0-hpux11.9 \ + hppa64-hpux11.0OPT-enable-sjlj-exceptionsEQUALyes hppa2.0-hpux11.9 \ i686-pc-linux-gnu i686-apple-darwin i686-apple-darwin9 i686-apple-darwin10 \ i486-freebsd4 i686-freebsd6 i686-kfreebsd-gnu \ i686-netbsdelf9 i686-knetbsd-gnu i686-openbsd i686-openbsd3.0 \ @@ -33,7 +33,7 @@ LIST = aarch64-elf aarch64-linux-gnu \ i686-lynxos i686-nto-qnx \ i686-rtems i686-solaris2.10 i686-wrs-vxworks \ i686-wrs-vxworksae \ - i686-cygwinOPT-enable-threads=yes i686-mingw32crt ia64-elf \ + i686-cygwinOPT-enable-threadsEQUALyes i686-mingw32crt ia64-elf \ ia64-freebsd6 ia64-linux ia64-hpux ia64-hp-vms iq2000-elf lm32-elf \ lm32-rtems lm32-uclinux m32c-rtems m32c-elf m32r-elf m32rle-elf m32r-rtems \ m32r-linux m32rle-linux m68k-elf m68k-netbsdelf \ @@ -52,7 +52,7 @@ LIST = aarch64-elf aarch64-linux-gnu \ powerpc-darwin7 powerpc64-darwin powerpc-freebsd6 powerpc-netbsd \ powerpc-eabispe powerpc-eabisimaltivec powerpc-eabisim ppc-elf \ powerpc-eabialtivec powerpc-xilinx-eabi powerpc-eabi \ - powerpc-rtems4.11OPT-enable-threads=yes powerpc-linux_spe \ + powerpc-rtems4.11OPT-enable-threadsEQUALyes powerpc-linux_spe \ powerpc-linux_paired powerpc64-linux_altivec \ powerpc-wrs-vxworks powerpc-wrs-vxworksae powerpc-lynxos powerpcle-elf \ powerpcle-eabisim powerpcle-eabi rs6000-ibm-aix4.3 rs6000-ibm-aix5.1.0 \ @@ -61,16 +61,16 @@ LIST = aarch64-elf aarch64-linux-gnu \ shle-linux sh-netbsdelf sh-superh-elf sh5el-netbsd sh64-netbsd sh64-linux \ sh64-elfOPT-with-newlib sh-rtems sh-wrs-vxworks sparc-elf \ sparc-leon-elf sparc-rtems sparc-linux-gnu \ - sparc-leon3-linux-gnuOPT-enable-target=all sparc-netbsdelf \ - sparc64-sun-solaris2.10OPT-with-gnu-ldOPT-with-gnu-asOPT-enable-threads=posix \ + sparc-leon3-linux-gnuOPT-enable-targetEQUALall sparc-netbsdelf \ + sparc64-sun-solaris2.10OPT-with-gnu-ldOPT-with-gnu-asOPT-enable-threadsEQUALposix \ sparc-wrs-vxworks sparc64-elf sparc64-rtems sparc64-linux sparc64-freebsd6 \ sparc64-netbsd sparc64-openbsd spu-elf tilegx-linux-gnu tilepro-linux-gnu \ v850e-elf v850-elf vax-linux-gnu \ vax-netbsdelf vax-openbsd x86_64-apple-darwin \ - x86_64-pc-linux-gnuOPT-with-fpmath=avx \ - x86_64-elfOPT-with-fpmath=sse x86_64-freebsd6 x86_64-netbsd \ + x86_64-pc-linux-gnuOPT-with-fpmathEQUALavx \ +
Re: [patch, mips] Fix for PR target/56942
On Sat, 2013-04-27 at 08:56 +0100, Richard Sandiford wrote:
Yeah, I think so. If = mean accepts more than, then there used
to be a nice total order:
next_insn
= next_nonnote_insn
= next_real_insn
= next_active_insn
Hi Richard,
This (plus inevitable fixes in back-end code, tbd) is the final step
in making JUMP_TABLE_DATA a non-active insn, as discussed way back in
April. I'm sorry I haven't had the time to address this before the end
of stage 1. I'm posting this now to make sure the patch isn't lost. To
be queued for the next stage 1...
Ciao!
Steven
* emit-rtl.c (active_insn_p): Make JUMP_TABLE_DATA a non-active insn.
(emit_pattern_after_setloc): Set location on any nondebug insn.
(emit_pattern_before_setloc): Likewise.
* final.c (reemit_insn_block_notes): Remove now-redundant test.
* function.c (active_insns_between): Rename to ...
(active_insns_in_bb_p): ... this. Use FOR_BB_INSNS_REVERSE. Walk
insns from last to first in the basic block, speculating active insns
are likely found quicker in this order.
(thread_prologue_and_epilogue_insns): Fix active_insns_between users.
* reorg.c (dbr_next_active_insn, dbr_prev_active_insn): New functions.
(first_active_target_insn, optimize_skip, try_merge_delay_insns,
own_thread_p, fill_simple_delay_slots, follow_jumps,
fill_slots_from_thread, fill_eager_delay_slots, label_before_next_insn,
relax_delay_slots, dbr_schedule): Use dbr_next_active_insn instead of
next_active_insn, or dbr_prev_active_insn instead of prev_active_insn.
* config/ia64/ia64.c (emit_all_insn_group_barriers): Remove
now-redundant test.
(final_emit_insn_group_barriers): Likewise.
Index: emit-rtl.c
===
--- emit-rtl.c (revision 205336)
+++ emit-rtl.c (working copy)
@@ -3298,7 +3298,6 @@ int
active_insn_p (const_rtx insn)
{
return (CALL_P (insn) || JUMP_P (insn)
- || JUMP_TABLE_DATA_P (insn) /* FIXME */
|| (NONJUMP_INSN_P (insn)
(! reload_completed
|| (GET_CODE (PATTERN (insn)) != USE
@@ -4487,7 +4486,7 @@ emit_pattern_after_setloc (rtx pattern, rtx after,
after = NEXT_INSN (after);
while (1)
{
- if (active_insn_p (after) !INSN_LOCATION (after))
+ if (NONDEBUG_INSN_P (after) !INSN_LOCATION (after))
INSN_LOCATION (after) = loc;
if (after == last)
break;
@@ -4596,7 +4595,7 @@ emit_pattern_before_setloc (rtx pattern, rtx befor
first = NEXT_INSN (first);
while (1)
{
- if (active_insn_p (first) !INSN_LOCATION (first))
+ if (NONDEBUG_INSN_P (first) !INSN_LOCATION (first))
INSN_LOCATION (first) = loc;
if (first == last)
break;
Index: final.c
===
--- final.c (revision 205336)
+++ final.c (working copy)
@@ -1672,10 +1672,6 @@ reemit_insn_block_notes (void)
}
if (!active_insn_p (insn))
-continue;
-
- /* Avoid putting scope notes between jump table and its label. */
- if (JUMP_TABLE_DATA_P (insn))
continue;
this_block = insn_scope (insn);
Index: function.c
===
--- function.c (revision 205336)
+++ function.c (working copy)
@@ -5693,18 +5693,14 @@ dup_block_and_redirect (basic_block bb, basic_bloc
#endif
#if defined (HAVE_return) || defined (HAVE_simple_return)
-/* Return true if there are any active insns between HEAD and TAIL. */
+/* Return true if there are any active insns in BB. */
static bool
-active_insn_between (rtx head, rtx tail)
+active_insns_in_bb_p (basic_block bb)
{
- while (tail)
-{
- if (active_insn_p (tail))
- return true;
- if (tail == head)
- return false;
- tail = PREV_INSN (tail);
-}
+ rtx insn;
+ FOR_BB_INSNS_REVERSE (bb, insn)
+if (active_insn_p (insn))
+ return true;
return false;
}
@@ -6354,7 +6350,7 @@ thread_prologue_and_epilogue_insns (void)
e = EDGE_I (EXIT_BLOCK_PTR_FOR_FN (cfun)-preds, i);
if (LABEL_P (BB_HEAD (e-src))
!bitmap_bit_p (bb_flags, e-src-index)
- !active_insn_between (BB_HEAD (e-src), BB_END (e-src)))
+ !active_insns_in_bb_p (e-src))
unconverted_simple_returns
= convert_jumps_to_returns (e-src, true,
unconverted_simple_returns);
@@ -6384,7 +6380,7 @@ thread_prologue_and_epilogue_insns (void)
basic_block last_bb = exit_fallthru_edge-src;
if (LABEL_P (BB_HEAD (last_bb))
- !active_insn_between (BB_HEAD (last_bb), BB_END (last_bb)))
+ !active_insns_in_bb_p (last_bb))
convert_jumps_to_returns (last_bb, false, vNULL);
Re: [PATCH] Fix c++/59112 and c++/59113: Disallow implicit function templates in local functions unless defining a lambda.
OK. Jason
Re: [patch, fortran, docs] Unformatted sequential and special files
Thomas, what's actually the status of this patch? I think it was half-complete in September. Tobias On September 4, 2013 12:40, Janne Blomqvist wrote: On Tue, Sep 3, 2013 at 3:04 PM, Thomas Koenig tkoe...@netcologne.de wrote: Hello world, here is a rewrite, which I hope make things more clear. Unformatted sequential files are now made up of subrecords, where a logical record may only have one. Looks ok. Regarding block devices: I don't know anybody who ever used them from gfortran, so I tried to be as vague as possible. Any more suggestions? OK for trunk otherwise? I'm still not comfortable with the wording. As I've argued before, special files are special in different ways, and can behave differently on different systems, so it's difficult to say anything definitive about their behavior in general. Maybe being more explicit about what is supported for a limited subset would help. E.g. starting the section with something like For terminal devices, pipes, FIFO's and sockets the following file modes are supported: - ... For other special files and other file modes, the result is undefined. (undefined rather than not supported, as we're not going out of our way to prevent it if somebody wants to do it either) - Wrt the POS= specifier with INQUIRE, even it it works (as in, does not generate an error), there is no sensible concept of file position for a stream file anyway, so perhaps we shouldn't explicitly say it's supported either. - Wrt. block devices, perhaps remove that section and cover it just with the ...implementation defined sentence above.
Re: Delete dead jump tables in cfglayout mode
On Sun, Nov 24, 2013 at 12:26 PM, H.J. Lu hjl.to...@gmail.com wrote: On Wed, Nov 20, 2013 at 12:59 PM, Steven Bosscher stevenb@gmail.com wrote: Hello, With the attached patch, dead jump tables are deleted if a CLEANUP_EXPENSIVE is performed in cfglayout mode. This helps remove labels and merge basic blocks, and brings the CFG out of cfglayout mode more cleanly. It also fixes bugs in LABEL_NUSES updating, which was broken for cfglayout, and which was done in the wrong place for IRA. Bootstrappedtested on powerpc64-unknown-linux-gnu. The patch needs patching for the EXIT_BLOCK_PTR/ENTRY_BLOCK_PTR changes but what's attached is what I tested. If the patch is OK, I'll make the necessary changes and re-test before committing. OK for trunk? It breaks bootstrap on x86 with java enabled: /export/gnu/import/git/gcc-test-intel64/src-trunk/libjava/classpath/gnu/xml/aelfred2/XmlParser.java: In class 'gnu.xml.aelfred2.XmlParser': /export/gnu/import/git/gcc-test-intel64/src-trunk/libjava/classpath/gnu/xml/aelfred2/XmlParser.java: In method 'gnu.xml.aelfred2.XmlParser.parseXMLDecl(boolean)': In file included from /export/gnu/import/git/gcc-test-intel64/src-trunk/libjava/classpath/gnu/xml/aelfred2/XmlParser.java:5804:0, from /export/gnu/import/git/gcc-test-intel64/src-trunk/libjava/classpath/gnu/xml/aelfred2/SAXDriver.java:1509, from /export/gnu/import/git/gcc-test-intel64/src-trunk/libjava/classpath/gnu/xml/aelfred2/XmlParser.java:5793, from /export/gnu/import/git/gcc-test-intel64/src-trunk/libjava/classpath/gnu/xml/aelfred2/SAXDriver.java:1605, from /export/gnu/import/git/gcc-test-intel64/src-trunk/libjava/classpath/gnu/xml/aelfred2/XmlParser.java:5813, from built-in:14: /export/gnu/import/git/gcc-test-intel64/src-trunk/libjava/classpath/gnu/xml/aelfred2/XmlParser.java:844:0: internal compiler error: in remove_insn, at emit-rtl.c:3981 return encodingName; ^ 0x66b1f3 remove_insn(rtx_def*) ../../src-trunk/gcc/emit-rtl.c:3981 0x5cf31b delete_insn(rtx_def*) ../../src-trunk/gcc/cfgrtl.c:170 0xd5d7ae delete_dead_jump_tables_between ../../src-trunk/gcc/cfgcleanup.c:2971 0xd60511 delete_dead_jumptables() ../../src-trunk/gcc/cfgcleanup.c:2997 0xd617a2 cleanup_cfg(int) ../../src-trunk/gcc/cfgcleanup.c:3084 0xdbd15a rest_of_handle_if_conversion ../../src-trunk/gcc/ifcvt.c:4482 0xdbd15a execute ../../src-trunk/gcc/ifcvt.c:4516 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[8]: *** [gnu-xml-aelfred2.lo] Error 1 I opened: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59279 -- H.J.
Re: [Patch, Fortran, OOP] PR 59143: Bogus warning with array-valued type-bound procedure
Hi Tobias,
here is a straightforward patch to teach 'get_expr_storage_size' about
type-bound procedures (which are handled internally as
procedure-pointer components of the corresponding vtab). In that sense
the patch should handle both TBPs as well as PPCs.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
The patch is NOT okay:
+ else if (ref-type == REF_COMPONENT
ref-u.c.component-attr.function
+ ref-u.c.component-attr.proc_pointer
+ ref-u.c.component-attr.dimension)
+ {
+ /* Array-valued procedure-pointer components. */
+ gfc_array_spec *as = ref-u.c.component-as;
+ for (i = 0; i as-rank; i++)
+ elements = elements
+ * (mpz_get_si (as-upper[i]-value.integer)
+ - mpz_get_si (as-lower[i]-value.integer) +
1L);
You cannot assume that the function returns an explicit size array with
constant bounds.
ouch, sorry for missing that.
A new version is attached, and I have added one of your examples to
the test case. Ok now?
Cheers,
Janus
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 205304)
+++ gcc/fortran/interface.c (working copy)
@@ -2426,6 +2426,24 @@ get_expr_storage_size (gfc_expr *e)
- mpz_get_si (ref-u.ar.as-lower[i]-value.integer));
}
}
+ else if (ref-type == REF_COMPONENT ref-u.c.component-attr.function
+ ref-u.c.component-attr.proc_pointer
+ ref-u.c.component-attr.dimension)
+ {
+ /* Array-valued procedure-pointer components. */
+ gfc_array_spec *as = ref-u.c.component-as;
+ for (i = 0; i as-rank; i++)
+ {
+ if (!as-upper[i] || !as-lower[i]
+ || as-upper[i]-expr_type != EXPR_CONSTANT
+ || as-lower[i]-expr_type != EXPR_CONSTANT)
+ return 0;
+
+ elements = elements
+* (mpz_get_si (as-upper[i]-value.integer)
+ - mpz_get_si (as-lower[i]-value.integer) + 1L);
+ }
+ }
}
if (substrlen)
! { dg-do compile }
!
! PR 59143: [OOP] Bogus warning with array-valued type-bound procedure
!
! Contributed by Jürgen Reuter juergen.reu...@desy.de
module phs_single
type :: phs_single_t
contains
procedure, nopass :: d1, d2
end type
contains
subroutine evaluate (phs)
class(phs_single_t) :: phs
call func1 (phs%d1 ())
call func1 (phs%d2 (2))
end subroutine
subroutine func1 (p)
real :: p(2)
end subroutine
function d1 ()
real :: d1(2)
d1 = 1.
end function
function d2 (n)
real :: d2(n)
d2 = 1.
end function
end module
! { dg-final { cleanup-modules phs_single } }
Re: Delete dead jump tables in cfglayout mode
On Sun, Nov 24, 2013 at 9:39 PM, H.J. Lu wrote: I opened: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59279 Thanks for the report. I can't reproduce it on powerpc64. This isn't the time to leave the trunk broken, so I've reverted the patch for now. Ciao! Steven
[SH] - Remove ROUND_REG, PASS_IN_REG, ROUND_ADVANCE macros
Hello,
This is a small SH cleanup patch. No functional changes -- at least not
intended.
The ROUND_ADVANCE macro can be replaced with CEIL from system.h, which
makes it a bit clearer towards what something is rounded in the places
where it's used.
The ROUND_REG and PASS_IN_REG_P macros (originally defined in sh.h) are
used in sh.c only, and thus are good candidates for static functions in
sh.c. The original logic and formatting of the macros is left unchanged
for now, but being functions they can be deciphered later if needed.
Tested with make all-gcc.
OK for trunk?
Cheers,
Oleg
gcc/ChangeLog:
* config/sh/sh.h (ROUND_ADVANCE): Delete macro.
(ROUND_REG, PASS_IN_REG_P): Move and rename macros to ...
* config/sh/sh.c (sh_round_reg, sh_pass_in_reg_p): ... these
new functions.
(sh_arg_partial_bytes, sh_function_arg,
sh_function_arg_advance, sh_setup_incoming_varargs): Replace
usage of PASS_IN_REG_P with sh_pass_in_reg_p. Replace usage of
ROUND_REG with sh_round_reg. Use CEIL instead of ROUND_ADVANCE.
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c (revision 205315)
+++ gcc/config/sh/sh.c (working copy)
@@ -8806,7 +8806,55 @@
% SH_MIN_ALIGN_FOR_CALLEE_COPY == 0));
}
+/* Round a register number up to a proper boundary for an arg of mode
+ MODE.
+ The SH doesn't care about double alignment, so we only
+ round doubles to even regs when asked to explicitly. */
static int
+sh_round_reg (const CUMULATIVE_ARGS cum, machine_mode mode)
+{
+ /* FIXME: This used to be a macro and has been copy pasted into this
+ function as is. Make this more readable. */
+ return
+ (((TARGET_ALIGN_DOUBLE
+ || ((TARGET_SH4 || TARGET_SH2A_DOUBLE)
+ (mode == DFmode || mode == DCmode)
+ cum.arg_count[(int) SH_ARG_FLOAT] NPARM_REGS (mode)))
+ GET_MODE_UNIT_SIZE (mode) UNITS_PER_WORD)
+? (cum.arg_count[(int) GET_SH_ARG_CLASS (mode)]
+ + (cum.arg_count[(int) GET_SH_ARG_CLASS (mode)] 1))
+: cum.arg_count[(int) GET_SH_ARG_CLASS (mode)]);
+}
+
+/* Return true if arg of the specified mode should be be passed in a register
+ or false otherwise. */
+static bool
+sh_pass_in_reg_p (const CUMULATIVE_ARGS cum, machine_mode mode,
+ const_tree type)
+{
+ /* FIXME: This used to be a macro and has been copy pasted into this
+ function as is. Make this more readable. */
+ return
+ ((type == 0
+|| (! TREE_ADDRESSABLE (type)
+ (! (TARGET_HITACHI || cum.renesas_abi)
+ || ! (AGGREGATE_TYPE_P (type)
+ || (!TARGET_FPU_ANY
+ (GET_MODE_CLASS (mode) == MODE_FLOAT
+ GET_MODE_SIZE (mode) GET_MODE_SIZE (SFmode)))
+! cum.force_mem
+(TARGET_SH2E
+ ? ((mode) == BLKmode
+ ? ((cum.arg_count[(int) SH_ARG_INT] * UNITS_PER_WORD
+ + int_size_in_bytes (type))
+ = NPARM_REGS (SImode) * UNITS_PER_WORD)
+ : ((sh_round_reg (cum, mode)
+ + HARD_REGNO_NREGS (BASE_ARG_REG (mode), mode))
+ = NPARM_REGS (mode)))
+ : sh_round_reg (cum, mode) NPARM_REGS (mode)));
+}
+
+static int
sh_arg_partial_bytes (cumulative_args_t cum_v, enum machine_mode mode,
tree type, bool named ATTRIBUTE_UNUSED)
{
@@ -8814,14 +8862,14 @@
int words = 0;
if (!TARGET_SH5
- PASS_IN_REG_P (*cum, mode, type)
+ sh_pass_in_reg_p (*cum, mode, type)
!(TARGET_SH4 || TARGET_SH2A_DOUBLE)
- (ROUND_REG (*cum, mode)
+ (sh_round_reg (*cum, mode)
+ (mode != BLKmode
- ? ROUND_ADVANCE (GET_MODE_SIZE (mode))
- : ROUND_ADVANCE (int_size_in_bytes (type)))
+ ? CEIL (GET_MODE_SIZE (mode), UNITS_PER_WORD)
+ : CEIL (int_size_in_bytes (type), UNITS_PER_WORD))
NPARM_REGS (mode)))
-words = NPARM_REGS (mode) - ROUND_REG (*cum, mode);
+words = NPARM_REGS (mode) - sh_round_reg (*cum, mode);
else if (!TARGET_SHCOMPACT
SH5_WOULD_BE_PARTIAL_NREGS (*cum, mode, type, named))
@@ -8858,23 +8906,23 @@
return GEN_INT (ca-renesas_abi ? 1 : 0);
if (! TARGET_SH5
- PASS_IN_REG_P (*ca, mode, type)
+ sh_pass_in_reg_p (*ca, mode, type)
(named || ! (TARGET_HITACHI || ca-renesas_abi)))
{
int regno;
if (mode == SCmode TARGET_SH4 TARGET_LITTLE_ENDIAN
- (! FUNCTION_ARG_SCmode_WART || (ROUND_REG (*ca, mode) 1)))
+ (! FUNCTION_ARG_SCmode_WART || (sh_round_reg (*ca, mode) 1)))
{
rtx r1 = gen_rtx_EXPR_LIST (VOIDmode,
gen_rtx_REG (SFmode,
BASE_ARG_REG (mode)
- + (ROUND_REG (*ca, mode) ^ 1)),
+ + (sh_round_reg (*ca, mode) ^ 1)),
const0_rtx);
rtx r2 = gen_rtx_EXPR_LIST (VOIDmode,
gen_rtx_REG (SFmode,
BASE_ARG_REG (mode)
- + ((ROUND_REG (*ca, mode) + 1) ^ 1)),
+ + ((sh_round_reg (*ca, mode) + 1) ^ 1)),
GEN_INT (4));
return gen_rtx_PARALLEL(SCmode, gen_rtvec(2, r1, r2));
}
@@ -8887,7 +8935,7 @@
mode == SFmode)
Re: [Patch, Fortran, OOP] PR 59143: Bogus warning with array-valued type-bound procedure
Hi Janus, Janus Weil wrote: + else if (ref-type == REF_COMPONENT ref-u.c.component-attr.function + ref-u.c.component-attr.proc_pointer + ref-u.c.component-attr.dimension) I wonder whether one should take care of functions returning BT_CLASS, but I think one doesn't need to. You cannot assume that the function returns an explicit size array with constant bounds. A new version is attached, and I have added one of your examples to the test case. Ok now? OK. Thanks for the patch! Tobias
Re: wide-int, fortran
On 11/24/2013 08:38 AM, N.M. Maclaren wrote: On Nov 24 2013, Kenneth Zadeck wrote: Thank you for your posting. That certainly clears up my understanding. If there is a clear description of the subset of C++ that the front-end is allowed to use, a pointer to it for the benefit of Fortran/C/Ada/whatever people would be useful. But that's an aside from this thread. There is a saying in the US that you can always tell the pioneers because they are the ones with the arrows in their back. I feel this way with respect to C++. When this branch first went public several months ago, the wide-int class made very modest use of C++. It has publicly evolved away from that and i would now describe the usage as somewhat aggressive. I do not know if i think that this is good or bad, but i expect that because we are the first big patch to use C++ aggressively , that we are going to take some arrows. I think that using C++ even slightly aggressively without first deciding the grounds rules is a seriously bad idea. The trouble about following random pioneers is that they are very likely to lead you into a swamp, with the loss of the whole expedition. And, with C++, that is more than just likely if you follow an adventurous pioneer rather than a cautious one - it's damn-near certain :-( i do not actually disagree with you.my point is that this was all done in the open. A useful way to think about this patch is that it is nothing but plumbing.Gcc has had a painful and long evolution from being a 32 bit compiler to a 64 bit compiler and beyond. ... Yes, but that's not my point. The main problem is that integer constant expressions in C are limited to the built-in operators, of which the only tricky ones are division and remainder (and, occasionally, multiplication) - see C11 6.6#3. Fortran is not so limited, and there are much wider requirements for expression evaluation at compile time. But at both ends of the compiler there are still limits. And my point is that this is NOT an area that separates cleanly into front and back end! However, from your description, this is one component of any solution for gfortran, and it doesn't sound as if it will cause trouble until and unless someone wants to extend gfortran to wider types. They will then have to implement the other components In any event, the problem is not with making the math work correctly, which is really the primary point of this patch. It is as you say how the various front ends decide how they wish to exploit that power. Regards, Nick Maclaren.
Re: [SH] Pass --isa to assembler
Oleg Endo oleg.e...@t-online.de wrote:
Currently GCC doesn't pass the --isa parameter to the assembler for SH
targets other than SH2A and SH5. This makes the assembler accept any
kind of ISA and happily produce e.g. SH2A code even though the target is
SH4, which will then fail to link.
The attach patch fixes this by passing the --isa parameter also for -m1,
-m2*, -m3*, and -m4*.
It also caught a mistake in libgcc/crt1.S, where the SH3 / SH4 VBR setup
code was compiled for SH2E.
Tested with
make -k -j4 check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
and no new failures.
OK for trunk?
libgcc fix should be an independent patch and is OK for trunk
as an obvious fix. --isa part looks fine but is a new feature.
It's OK when trunk goes back to stage1.
Regards,
kaz
Re: [SH] - Remove ROUND_REG, PASS_IN_REG, ROUND_ADVANCE macros
Oleg Endo oleg.e...@t-online.de wrote: This is a small SH cleanup patch. No functional changes -- at least not intended. The ROUND_ADVANCE macro can be replaced with CEIL from system.h, which makes it a bit clearer towards what something is rounded in the places where it's used. The ROUND_REG and PASS_IN_REG_P macros (originally defined in sh.h) are used in sh.c only, and thus are good candidates for static functions in sh.c. The original logic and formatting of the macros is left unchanged for now, but being functions they can be deciphered later if needed. Tested with make all-gcc. OK for trunk? OK when trunk goes back to stage1. Regards, kaz
[PATCH] output.h (get_named_text_section): Fix typo in comment: s/SECITON/SECTION/
--- ChangeLog entry: 2013-11-24 Josh Triplett j...@joshtriplett.org * output.h (get_named_text_section): Fix typo in comment: s/SECITON/SECTION/ gcc/output.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/output.h b/gcc/output.h index 7b26256..3a86e1b 100644 --- a/gcc/output.h +++ b/gcc/output.h @@ -259,7 +259,7 @@ extern bool default_assemble_integer (rtx, unsigned int, int); be outputable. */ extern bool assemble_integer (rtx, unsigned, unsigned, int); -/* Return section for TEXT_SECITON_NAME if DECL or DECL_SECTION_NAME (DECL) +/* Return section for TEXT_SECTION_NAME if DECL or DECL_SECTION_NAME (DECL) is NULL. */ extern section *get_named_text_section (tree, const char *, const char *); -- 1.8.4.4
Re: A GGC related question
On 11/22/2013, 8:04 PM, dxq wrote: fixing SMS, do you mean that we only modify the SMS pass? You don't need loop unrolling when you have a good software pipelining and loop vectorization. A good software pipelining can see through any number of iterations and has no problems with code cache locality in comparison with unrolling. A good SFP is a perfect SFP (e.g. resource constraints software piplening) which can deal with any loop bodies. Unfortunately modulo scheduling deals with one BB loop body only (still it covers most cases after if-conversion, it is easy and can be good for supporting hardware with rotating regs file). Even if the current SMS implementation pitfalls are fixed, there are still cases when unrolling could be beneficial. So probably your approach is the best what can be done for now. Also if you manage to implement the infrastructure with copying/backup, it could be useful for a perfect SFP implementation. Still I think we need long-term strategy for SFP in GCC. if so, the problem we have to solve: * how to make unroll and sms work together? calling unroll pass in sms, but it would be needed more passes such as web, and it's perfect to rerun all the passes between unroll and sms. * unroll and web pass exsit in gcc, however gcc's passes only work for a compilation unit, function, rather than a smaller unit we expect, loop. that's why we copy all global information, and rerun the passes between the unroll and sms sevral times. * if we need try more unroll factors, copying is also needed. the backup exsits in single pass, so it would not be purged by GGC. but, if memory consuming is huge, is there any risk for the other passes? from my experience, when disable GGC between unroll and sms, with ggc_min_expand = 100 ggc_min_heap = 20480, and compile a big file, gcc crashes down. That's what I can think of. you know, it's a very big and hard work. do you have any suggestions about our current solution?
Re: wide-int, nds32
2013/11/24 Mike Stump mikest...@comcast.net: Richi has asked the we break the wide-int patch so that the individual port and front end maintainers can review their parts without have to go through the entire patch.This patch covers the nds32 port. Ok? OK. The changes are straightforward on using wide-int interface. Thanks for the patch! :-) Best regards, jasonwucj
