Re: [C++ RFC / Patch] PR 51213 ("access control under SFINAE")
Hi, and, first, thanks a lot for all the nice work and help on these issues! On 07/13/2012 12:55 AM, Jason Merrill wrote: diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index fec88eb..95c6464 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -8334,7 +8334,7 @@ apply_late_template_attributes (tree *decl_p, tree attributes, int attr_flags, /* Perform (or defer) access check for typedefs that were referenced from within the template TMPL code. - This is a subroutine of instantiate_template and instantiate_class_template. + This is a subroutine of instantiate_decl and instantiate_class_template. TMPL is the template to consider and TARGS is the list of arguments of that template. */ @@ -14380,12 +14380,6 @@ instantiate_template_1 (tree tmpl, tree orig_args, tsubst_flags_t complain) /* Now we know the specialization, compute access previously deferred. */ push_access_scope (fndecl); - - /* Some typedefs referenced from within the template code need to be access - checked at template instantiation time, i.e now. These types were - added to the template at parsing time. Let's get those and perfom - the acces checks then. */ - perform_typedefs_access_check (DECL_TEMPLATE_RESULT (tmpl), targ_ptr); perform_deferred_access_checks (); pop_access_scope (fndecl); pop_deferring_access_checks (); @@ -18395,6 +18389,13 @@ instantiate_decl (tree d, int defer_ok, /* Set up context. */ start_preparsed_function (d, NULL_TREE, SF_PRE_PARSED); + /* Some typedefs referenced from within the template code need to be +access checked at template instantiation time, i.e now. These +types were added to the template at parsing time. Let's get those +and perform the access checks then. */ + perform_typedefs_access_check (DECL_TEMPLATE_RESULT (gen_tmpl), +gen_args); + I'm working on integrating again my work. The above change of yours appear to imply that, at variance with what I had in my first draft, perform_typedefs_access_check shouldn't really gain a tsubst_flags_t argument, because now it's called by instantiate_decl and instantiate_class_template_1 (from which I was passing a true / tf_error). Makes sense? Thanks! Paolo.
Re: __int256
On 14/07/12 04:21, Mike Stump wrote: > On Jul 13, 2012, at 11:28 AM, Steven Bosscher wrote: >> On Fri, Jul 13, 2012 at 8:21 PM, Nathan Froyd wrote: >>> On Fri, Jul 13, 2012 at 10:36:35AM -0700, Mike Stump wrote: I just checked all in tree gcc targets, and none claim OImode support. >>> >>> ./s390/s390-modes.def:23:INT_MODE (OI, 32); >>> ./spu/spu-modes.def:29:INT_MODE (OI, 32); >>> ./ia64/ia64-modes.def:68:INT_MODE (OI, 32); >>> ./i386/i386-modes.def:88:INT_MODE (OI, 32); >>> ./arm/arm-modes.def:82:INT_MODE (OI, 32); >>> >>> At least for ARM, OImode gets used for Neon intrinsics. Can't speak for >>> the other ports, though. >> >> On x86_64-unknown-linux-gnu: >> >> $ cat t.c >> int __attribute__((__mode__(DI))) di; >> int __attribute__((__mode__(TI))) ti; >> int __attribute__((__mode__(OI))) oi; >> >> $ ./xgcc -B. t.c >> t.c:3:1: error: unable to emulate ‘OI’ >> int __attribute__((__mode__(OI))) oi; >> ^ >> >> This is trunk r189365. > > Yup, exactly as I expected. The arm folks I suspect will discover the same. > OImode on ARM only exists to support vector copying operations and the other guff that the compiler can't handle internally without it. It is /not/ intended to be available as a type to the user, in particular, it is not intended to be available for arithmetic. The same is also true of TI mode and any other xImode larger than DImode. R.
Re: [Patch, Fortran] PR 51758 - fix ICE with null() in elemental procedures
On 09/01/2012 15:45, Tobias Burnus wrote: > On 01/09/2012 03:34 PM, Mikael Morin wrote: >> The issue is that the code handling NULL() doesn't consume the gfc_ss >> struct created for it. Your fix, which advances to the next one anyway >> would work just well, but I think it is slightly cleaner to not create >> the struct in the first place, as it is unused. >> >> I'm currently regtesting the following patch. The testcase is the same >> as your. OK for 4.7/4.6? > > OK. > > For the test case, either take mine or don't forget to enable all "if() > abort"s and to change in the last "! print *,a" the "a" into a "b". > > + if (!arg->expr > + || arg->expr->expr_type == EXPR_NULL) > continue; > > (I'd prefer to have no line break before the "||".) > > Tobias As this patch was approved for 4.6, I will now backport it and then close the bug, unless someone complains. Mikael
Re: [patch][fortran] Include coretypes.h in .c files, not in gfortran.h
Steven Bosscher wrote: On Thu, Jul 12, 2012 at 11:29 AM, Tobias Burnus wrote: On 07/07/2012 11:28 PM, Steven Bosscher wrote: I must say, I am surprised that gfortran.h includes coretypes.h. The idea always was to try and keep the front end and the back end as much separated as possible, and including coretypes.h in the most important front-end header doesn't fit in that picture. I initially tried to just stop including flags.h in e.g. fortran/arith.c because I couldn't think of anything that arith.h should know from flags.h, but that breaks the build because arith.c looks at 'pedantic' from the generated file options.h. Well, those are much more intertwined: If one changes "pedantic" to "gfc_option.gfc_pedantic" and does not include "coretypes.h", gfortran.h fails because "tree" is not defined. Addtionally, I get some failures because of "tls_model". If one now includes "tree.h" in gfortran.h, it fails because "tree.h" includes "vecir.h", which has at the top: #ifndef GCC_CORETYPES_H #error "vecir.h must be included after coretypes.h" #endif I think the old version was cleaner. Hence, I would really like to revert your patch, http://gcc.gnu.org/ml/fortran/2012-07/msg00019/fortran_coretypes.diff Comments? Suggestions? Tobias
Re: [Patch, Fortran] Add parsing support for assumed-rank array
Hello,
I somehow was reading this in the standard:
"An assumed-rank variable name shall not appear in a designator or
expression except as an actual
argument corresponding to a dummy argument that is assumed-rank..."
with "...except in..." instead of "...except as...".
Some of my comments were plain misunderstanding/misinterpretation on my
side.
The next comment iteration is below.
Mikael
On 13/07/2012 09:50, Tobias Burnus wrote:
>>> @@ -5067,13 +5097,26 @@ resolve_variable (gfc_expr *e)
>>>/* TS 29113, 407b. */
>>> - if (e->ts.type == BT_ASSUMED && !assumed_type_expr_allowed)
>>> + if (e->ts.type == BT_ASSUMED && !assumed_rank_type_expr_allowed)
>>> {
>>>gfc_error ("Invalid expression with assumed-type variable %s
>>> at %L",
>>> sym->name, &e->where);
>>>return FAILURE;
>>> }
>>
>> I'm not sure I understand the logic with the mixed assumed rank/type
>> flag. According to C407c, shouldn't we check that e is assumed
>> rank/shape?
>
> No, that check is not for assumed-rank arrays but for (e.g. scalar)
> assumed type, TYPE(*). The check handles cases like:
>
> type(*) :: x
> print *, ubound(array, dim=x)
>
> where "x" is not allowed, contrary to, e.g.,
>
> type(*) :: x(:)
> print *, ubound(x)
>
> Thus, one needs to keep track whether "x" is allowed or is not allowed
> in an expression. As that's the same for assumed type and for assumed
> rank, I am using the same tracking variable, called
> assumed_rank_type_expr_allowed. A better name would be:
> assumed_rank_or_assumed_type_expr_allowed (or s/or/and/), however, I
> found my version clear enough and while it is already long, that variant
> would be even longer.
What about naming the flag in_actual_arg and moving the inquiry_argument
condition to the error condition?
>
>>>
>>> + /* TS 29113, C535b. */
>>> + if (((sym->ts.type == BT_CLASS && sym->attr.class_ok
>>> +&& CLASS_DATA (sym)->as
>>> +&& CLASS_DATA (sym)->as->type == AS_ASSUMED_RANK)
>>> + || (sym->ts.type != BT_CLASS && sym->as
>>> + && sym->as->type == AS_ASSUMED_RANK))
>>> + && !assumed_rank_type_expr_allowed)
>>> +{
>>> + gfc_error ("Invalid expression with assumed-rank variable %s
>>> at %L",
>>> + sym->name, &e->where);
>>
>> The error message could be made more helpful. ;-)
>
> Suggestions welcome. Example use would be:
>
> x = x +1
> call foo(x+1)
> call sin(x) ! Though that probably triggers elsewhere
>
> I don't think the wording is that bad.
Well, my problem with it is that it doesn't tell what is invalid.
What do you think about "Assumed rank variable %s at %L can only be used
as an actual argument." ?
I think that currently your foo(x+1) case doesn't trigger an error.
It's not in your testcases at least.
>
>>> @@ -5084,6 +5127,22 @@ resolve_variable (gfc_expr *e)
>>>return FAILURE;
>>> }
>>>
>>> + /* TS 29113, C535b. */
>>> + if (((sym->ts.type == BT_CLASS && sym->attr.class_ok
>>> +&& CLASS_DATA (sym)->as
>>> +&& CLASS_DATA (sym)->as->type == AS_ASSUMED_RANK)
>>> + || (sym->ts.type != BT_CLASS && sym->as
>>> + && sym->as->type == AS_ASSUMED_RANK))
>>> + && e->ref
>>> + && !(e->ref->type == REF_ARRAY && e->ref->u.ar.type == AR_FULL
>>> + && e->ref->next == NULL))
>>> +{
>>> + gfc_error ("Assumed-rank variable %s with designator at %L",
>>> + sym->name, &e->ref->u.ar.where);
>>
>> Ditto here. And I think that C535b is more about the context of the
>> expression rather than the expression itself.
>
> Here, I am lost. The check is that
> ubound(x(:))
> call bar (x(1))
> call bar2(x([1,3,5])
> call bar3(x(1:5:2))
> or similar does not occur if "x" is assumed rank. That "(:)" is an
> (array) designator. Do you have a better suggestion? I could add the
> word "array" before "designator", but I would like to avoid to list all
> possible combinations.
This one error is better as it tries to hint what's wrong. However, ...
>
> From TS29113:
> "C407b An assumed-type variable name shall not appear in a designator or
> ..."
>
> From Fortran 2008:
>
> "1.3.59 designator
> name followed by zero or more component selectors, complex part
> selectors, array section selectors, array element selectors, image
> selectors, and substring selectors (6.1)"
... according to this, a bare variable name is also a designator, and it
is valid. So issuing errors because the variable is/has a designator
seems confusing at best. I'm almost satisfied with this (maybe
s/with/in/ or s/be used with/???/) :
"Assumed-rank variable %s at %L cannot be used with a subobject reference."
Re: [patch][fortran] Include coretypes.h in .c files, not in gfortran.h
On Sat, Jul 14, 2012 at 3:23 PM, Tobias Burnus wrote: > Steven Bosscher wrote: >> >> On Thu, Jul 12, 2012 at 11:29 AM, Tobias Burnus wrote: >>> >>> On 07/07/2012 11:28 PM, Steven Bosscher wrote: I must say, I am surprised that gfortran.h includes coretypes.h. The idea always was to try and keep the front end and the back end as much separated as possible, and including coretypes.h in the most important front-end header doesn't fit in that picture. I initially tried to just stop including flags.h in e.g. fortran/arith.c because I couldn't think of anything that arith.h should know from flags.h, but that breaks the build because arith.c looks at 'pedantic' from the generated file options.h. > > > Well, those are much more intertwined: > > If one changes "pedantic" to "gfc_option.gfc_pedantic" and does not include > "coretypes.h", gfortran.h fails because "tree" is not defined. > > Addtionally, I get some failures because of "tls_model". > > If one now includes "tree.h" in gfortran.h, it fails because "tree.h" > includes "vecir.h", which has at the top: > #ifndef GCC_CORETYPES_H > #error "vecir.h must be included after coretypes.h" > #endif > > > I think the old version was cleaner. Hence, I would really like to revert > your patch, > http://gcc.gnu.org/ml/fortran/2012-07/msg00019/fortran_coretypes.diff > > Comments? If you revert it, the build fails. > Suggestions? Give me some time to look into this, and I'll fix things. Ciao! Steven
Re: [patch] PR web/53919 - Add note to install.texi
Oops, this was meant for gcc-patches not gcc-bugs On 14 July 2012 14:45, Jonathan Wakely wrote: > PR c++/53919 > * doc/install.texi (Installing GCC): Refer to instructions for > released versions. Fix hyphenation. > > Whether or not we want the release-specific installation instructions > online, I don't think it hurts to point out that the docs at > http://gcc.gnu.org/install/ refer to the SVN trunk. > > OK for trunk?
Re: [patch] PR web/53919 - Add note to install.texi
On 14 July 2012 14:46, Jonathan Wakely wrote:
> Oops, this was meant for gcc-patches not gcc-bugs
Gah, and then I didn't forward the patch, I seem to have forgotten how
to use gmail's UI :-\
Attached this time, here's the original mail again:
PR c++/53919
* doc/install.texi (Installing GCC): Refer to instructions for
released versions. Fix hyphenation.
Whether or not we want the release-specific installation instructions
online, I don't think it hurts to point out that the docs at
http://gcc.gnu.org/install/ refer to the SVN trunk.
OK for trunk?
commit 8a2c697641369c9448a605101d65be7d3ccd6630
Author: Jonathan Wakely
Date: Fri Jul 13 10:06:09 2012 +0100
PR c++/53919
* doc/install.texi (Installing GCC): Refer to instructions for
released versions. Fix hypenation.
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index b35d803..95fa247 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -149,13 +149,15 @@ Free Documentation License}''.
The latest version of this document is always available at
@uref{http://gcc.gnu.org/install/,,http://gcc.gnu.org/install/}.
+The latest version refers to the SVN development sources, instructions for
+specific released versions are included with the sources.
This document describes the generic installation procedure for GCC as well
as detailing some target specific installation instructions.
GCC includes several components that previously were separate distributions
with their own installation instructions. This document supersedes all
-package specific installation instructions.
+package-specific installation instructions.
@emph{Before} starting the build/install procedure please check the
@ifnothtml
Re: [patch][fortran] Include coretypes.h in .c files, not in gfortran.h
On 14/07/2012 15:45, Steven Bosscher wrote: > On Sat, Jul 14, 2012 at 3:23 PM, Tobias Burnus wrote: >> Steven Bosscher wrote: >>> >>> On Thu, Jul 12, 2012 at 11:29 AM, Tobias Burnus wrote: On 07/07/2012 11:28 PM, Steven Bosscher wrote: > > I must say, I am surprised that gfortran.h includes coretypes.h. The > idea always was to try and keep the front end and the back end as much > separated as possible, and including coretypes.h in the most important > front-end header doesn't fit in that picture. Well it makes sense to me, actually. The frontend has internal structures to represent symbols, expressions etc, and it attaches the corresponding backend representations in those structures. And the backend representation has type tree, so it needs this from coretypes.h: union tree_node; typedef union tree_node *tree; It's a black box type, as the type definition is not in coretypes.h (at least in my few days old trunk). So the backend is kept separated from the frontend. What's wrong with that? [...] >> If one now includes "tree.h" in gfortran.h, it fails because "tree.h" >> includes "vecir.h", which has at the top: >> #ifndef GCC_CORETYPES_H >> #error "vecir.h must be included after coretypes.h" >> #endif >> Silly question: why don't they just include coretypes.h here? Mikael
Re: [patch][fortran] Include coretypes.h in .c files, not in gfortran.h
On Sat, Jul 14, 2012 at 4:06 PM, Mikael Morin wrote: > On 14/07/2012 15:45, Steven Bosscher wrote: >> On Sat, Jul 14, 2012 at 3:23 PM, Tobias Burnus wrote: >>> Steven Bosscher wrote: On Thu, Jul 12, 2012 at 11:29 AM, Tobias Burnus wrote: > > On 07/07/2012 11:28 PM, Steven Bosscher wrote: >> >> I must say, I am surprised that gfortran.h includes coretypes.h. The >> idea always was to try and keep the front end and the back end as much >> separated as possible, and including coretypes.h in the most important >> front-end header doesn't fit in that picture. > > Well it makes sense to me, actually. > The frontend has internal structures to represent symbols, expressions > etc, and it attaches the corresponding backend representations in those > structures. And the backend representation has type tree, so it needs > this from coretypes.h: > > union tree_node; > typedef union tree_node *tree; > > It's a black box type, as the type definition is not in coretypes.h (at > least in my few days old trunk). So the backend is kept separated from > the frontend. What's wrong with that? Nothing per se, in GCC. But let's say someone wants to glue gfortran to another back end, or make a stand-alone parser for a code checker, then you wouldn't want to include coretypes.h. You'd want to just cut off all trans-* files and use gfortran's internal data structures, or perhaps the dumped version of it. I don't see it as a big problem, though. >>> If one now includes "tree.h" in gfortran.h, it fails because "tree.h" >>> includes "vecir.h", which has at the top: >>> #ifndef GCC_CORETYPES_H >>> #error "vecir.h must be included after coretypes.h" >>> #endif >>> > Silly question: why don't they just include coretypes.h here? This is not a silly question at all, although arguably it should be. There is no convention in GCC for including headers within headers. Some headers include everything they need, others do not. For example, my dumpfile.h patch from yesterday makes tree-pass.h include dumpfile.h and timevar.h because tree-pass.h uses symbols from those headers, but your vecir.h example shows that this header uses a different approach (#error). In gfortran, gfortran.h is the One Header To Rule Them All. What is done where seems to depend on the taste of the individual developer. I think that for this particular case, vecir.h, the #error is there to make sure that coretypes.h is explicitly included. Ciao! Steven
Re: [PATCH] Make LTO type merging cheaper
On Fri, Jul 13, 2012 at 1:11 AM, Richard Guenther wrote:
>
> A patch that's in my local tree for quite some time. This removes
> redundant tests.
>
> LTO bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
>
> Richard.
>
> 2012-07-13 Richard Guenther
>
> * gimple.c (gimple_types_compatible_p_1): Remove redundant
> type attribute comparisons.
> (gimple_canonical_types_compatible_p): Likewise.
>
> Index: gcc/gimple.c
> ===
> --- gcc/gimple.c(revision 189311)
> +++ gcc/gimple.c(working copy)
> @@ -3422,10 +3422,6 @@ gimple_types_compatible_p_1 (tree t1, tr
> goto different_types;
> }
>
> - /* If their attributes are not the same they can't be the same type. */
> - if (!attribute_list_equal (TYPE_ATTRIBUTES (t1), TYPE_ATTRIBUTES (t2)))
> -goto different_types;
> -
>/* Do type-specific comparisons. */
>switch (TREE_CODE (t1))
> {
I don't see why this is redundant since attributes aren't checked anywhere
else. Revert this part fixes:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53959
--
H.J.
[Fortran-dev] Merge from the trunk / C_F_Pointer cleanup
Dear all, I have now merged the trunk into the fortran-dev branch (Rev. 189481). In particular, that brings c_f_pointer support to the branch and fixes some issues. Tobias
Re: [patch] Make asm_out_file a text write-only file again
On Fri, Jul 13, 2012 at 12:30 PM, Steven Bosscher wrote: > > gcc/ > * toplev.c (init_asm_output): Open asm_out_file in 'w' mode. > > c-family/ > * c-pch.c (CHECK_NO_ASM_OUT_DURING_PCH): Do not define. > Remove code conditional on it. This is OK. Thanks. Ian
Re: [PATCH] Make LTO type merging cheaper
Hello! >> A patch that's in my local tree for quite some time. This removes >> redundant tests. >> >> LTO bootstrapped and tested on x86_64-unknown-linux-gnu, applied. >> >> Richard. >> >> 2012-07-13 Richard Guenther >> >> * gimple.c (gimple_types_compatible_p_1): Remove redundant >> type attribute comparisons. >> (gimple_canonical_types_compatible_p): Likewise. >> > > I don't see why this is redundant since attributes aren't checked anywhere > else. Revert this part fixes: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53959 This patch also breaks LTO profiledbootstrap [1]. Even simple hello world compilation breaks at: Starting program: /home/uros/gcc-build-fast/gcc/cc1 -O2 hello.c Program received signal SIGSEGV, Segmentation fault. update_path (path=path@entry=0xe8f775 "/usr/local/include", key=0x0) at ../../gcc-svn/trunk/gcc/prefix.c:260 260 if (key[0] != '$') Missing separate debuginfos, use: debuginfo-install gmp-5.0.2-6.fc17.x86_64 libmpc-0.9-2.fc17.2.x86_64 mpfr-3.1.0-2.fc17.x86_64 (gdb) bt #0 update_path (path=path@entry=0xe8f775 "/usr/local/include", key=0x0) at ../../gcc-svn/trunk/gcc/prefix.c:260 #1 0x00cb1545 in add_standard_paths (cxx_stdinc=0, imultilib=0x0, iprefix=0x0, sysroot=0x0) at ../../gcc-svn/trunk/gcc/incpath.c:204 #2 register_include_chains (pfile=0x13cce70, sysroot=, iprefix=0x0, imultilib=0x0, stdinc=1, cxx_stdinc=0, verbose=0) at ../../gcc-svn/trunk/gcc/incpath.c:462 #3 0x00ba9a30 in c_common_post_options (pfilename=0x138e130) at ../../gcc-svn/trunk/gcc/c-family/c-opts.c:894 #4 0x00c5dd52 in process_options () at ../../gcc-svn/trunk/gcc/toplev.c:1212 #5 do_compile () at ../../gcc-svn/trunk/gcc/toplev.c:1832 #6 toplev_main(int, char**) (argc=3, argv=0x7fffddd8) at ../../gcc-svn/trunk/gcc/toplev.c:1939 #7 0x00330bc21735 in __libc_start_main (main=0x74be10 , argc=3, ubp_av=0x7fffddd8, init=, fini=, rtld_fini=, stack_end=0x7fffddc8) at libc-start.c:226 #8 0x00a76075 in _start () The guard "&& key != 0" above the segfault is simply ignored. [1] http://gcc.gnu.org/ml/gcc-regression/2012-07/msg00067.html Uros.
Re: [PATCH] Make LTO type merging cheaper
On Sat, Jul 14, 2012 at 9:27 AM, Uros Bizjak wrote: > Hello! > > >>> A patch that's in my local tree for quite some time. This removes >>> redundant tests. >>> >>> LTO bootstrapped and tested on x86_64-unknown-linux-gnu, applied. >>> >>> Richard. >>> >>> 2012-07-13 Richard Guenther >>> >>> * gimple.c (gimple_types_compatible_p_1): Remove redundant >>> type attribute comparisons. >>> (gimple_canonical_types_compatible_p): Likewise. >>> >> >> I don't see why this is redundant since attributes aren't checked anywhere >> else. Revert this part fixes: >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53959 > > This patch also breaks LTO profiledbootstrap [1]. > > Even simple hello world compilation breaks at: > > Starting program: /home/uros/gcc-build-fast/gcc/cc1 -O2 hello.c > > Program received signal SIGSEGV, Segmentation fault. > update_path (path=path@entry=0xe8f775 "/usr/local/include", key=0x0) > at ../../gcc-svn/trunk/gcc/prefix.c:260 > 260 if (key[0] != '$') > Missing separate debuginfos, use: debuginfo-install See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53963 -- H.J.
[patch] Remove expand_expr_stmt
Hello,
This patch removes expand_expr_stmt and inlines+folds it into its only user.
This relies on TARGET_STACK_PROTECT_FAIL being a CALL_EXPR. The
documentation only says "a tree expression that (...) should involve a
call to a @code{noreturn} function". I've changed this to explicitly
state that the hook must return a CALL_EXPR.
Bootstrapped and tested on powerpc64-unknown-linux-gnu.
OK for trunk?
Ciao!
Steven
* function.c (stack_protect_epilogue): Use expand_call to expand
targetm.stack_protect_fail.
* stmt.c (expand_expr_stmt): Remove now-unused function.
* tree.h (expand_expr_stmt): Remove prototype.
* doc/tm.texi.in (TARGET_STACK_PROTECT_FAIL): Document that this
hook must return a CALL_EXPR.
* doc/tm.texi: Regenerate.
remove_expand_expr_stmt.diff
Description: Binary data
PATCH: PR bootstrap/53963: [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
Hi,
Revision 189453:
http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00357.html
removes type attribute comparison in gimple_types_compatible_p_1 and
caused PR middle-end/53959 and PR bootstrap/53963. This restores type
attribute comparison. Tested on Linux/x86-64. OK to install?
Thanks.
H.J.
---
2012-07-14 H.J. Lu
PR middle-end/53959
PR bootstrap/53963
* gimple.c (gimple_types_compatible_p_1): Restore type attribute
comparison.
diff --git a/gcc/gimple.c b/gcc/gimple.c
index b419591..4d2a0f5 100644
--- a/gcc/gimple.c
+++ b/gcc/gimple.c
@@ -3422,6 +3422,10 @@ gimple_types_compatible_p_1 (tree t1, tree t2,
type_pair_t p,
goto different_types;
}
+ /* If their attributes are not the same they can't be the same type. */
+ if (!attribute_list_equal (TYPE_ATTRIBUTES (t1), TYPE_ATTRIBUTES (t2)))
+goto different_types;
+
/* Do type-specific comparisons. */
switch (TREE_CODE (t1))
{
Re: PATCH: PR bootstrap/53963: [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
On Sat, Jul 14, 2012 at 8:49 PM, H.J. Lu wrote: > Hi, > > Revision 189453: > > http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00357.html > > removes type attribute comparison in gimple_types_compatible_p_1 and > caused PR middle-end/53959 and PR bootstrap/53963. This restores type > attribute comparison. Tested on Linux/x86-64. OK to install? > > Thanks. > > > H.J. > --- > 2012-07-14 H.J. Lu > > PR middle-end/53959 > PR bootstrap/53963 > * gimple.c (gimple_types_compatible_p_1): Restore type attribute > comparison. I think this deserves a bit more understanding of the problem before reverting. Which type attributes survive up to this point? Ciao! Steven
[patch] Move 'tree' accessor macros from flags.h to tree.h
Hello, tree.h can depend on flags.h (and includes it) but flags.h should not depend on tree.h. The attached patch moves some macros from flags.h to tree.h because they use tree accessor macros. Looks quite obvious to me. Bootstrapped&tested on powerpc64-unknown-linux-gnu and on x86_64-unknown-linux-gnu. Will commit in a few days if no-one objects. Ciao! Steven * flags.h (TYPE_OVERFLOW_WRAPS, TYPE_OVERFLOW_UNDEFINED, TYPE_OVERFLOW_TRAPS, POINTER_TYPE_OVERFLOW_UNDEFINED): Move to tree.h. * tree.h (TYPE_OVERFLOW_WRAPS, TYPE_OVERFLOW_UNDEFINED, TYPE_OVERFLOW_TRAPS, POINTER_TYPE_OVERFLOW_UNDEFINED): New home. Index: flags.h === --- flags.h (revision 189482) +++ flags.h (working copy) @@ -106,30 +106,6 @@ #define abi_version_at_least(N) \ (flag_abi_version == 0 || flag_abi_version >= (N)) -/* True if overflow wraps around for the given integral type. That - is, TYPE_MAX + 1 == TYPE_MIN. */ -#define TYPE_OVERFLOW_WRAPS(TYPE) \ - (TYPE_UNSIGNED (TYPE) || flag_wrapv) - -/* True if overflow is undefined for the given integral type. We may - optimize on the assumption that values in the type never overflow. - - IMPORTANT NOTE: Any optimization based on TYPE_OVERFLOW_UNDEFINED - must issue a warning based on warn_strict_overflow. In some cases - it will be appropriate to issue the warning immediately, and in - other cases it will be appropriate to simply set a flag and let the - caller decide whether a warning is appropriate or not. */ -#define TYPE_OVERFLOW_UNDEFINED(TYPE) \ - (!TYPE_UNSIGNED (TYPE) && !flag_wrapv && !flag_trapv && flag_strict_overflow) - -/* True if overflow for the given integral type should issue a - trap. */ -#define TYPE_OVERFLOW_TRAPS(TYPE) \ - (!TYPE_UNSIGNED (TYPE) && flag_trapv) - -/* True if pointer types have undefined overflow. */ -#define POINTER_TYPE_OVERFLOW_UNDEFINED (flag_strict_overflow) - /* Whether to emit an overflow warning whose code is C. */ #define issue_strict_overflow_warning(c) (warn_strict_overflow >= (int) (c)) Index: tree.h === --- tree.h (revision 189482) +++ tree.h (working copy) @@ -1,4 +1,4 @@ -/* Front-end tree definitions for GNU compiler. +/* Definiitions for the ubiquitous 'tree' type for GNU compiler. Copyright (C) 1989, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 Free Software Foundation, Inc. @@ -1348,6 +1348,30 @@ /* In integral and pointer types, means an unsigned type. */ #define TYPE_UNSIGNED(NODE) (TYPE_CHECK (NODE)->base.unsigned_flag) +/* True if overflow wraps around for the given integral type. That + is, TYPE_MAX + 1 == TYPE_MIN. */ +#define TYPE_OVERFLOW_WRAPS(TYPE) \ + (TYPE_UNSIGNED (TYPE) || flag_wrapv) + +/* True if overflow is undefined for the given integral type. We may + optimize on the assumption that values in the type never overflow. + + IMPORTANT NOTE: Any optimization based on TYPE_OVERFLOW_UNDEFINED + must issue a warning based on warn_strict_overflow. In some cases + it will be appropriate to issue the warning immediately, and in + other cases it will be appropriate to simply set a flag and let the + caller decide whether a warning is appropriate or not. */ +#define TYPE_OVERFLOW_UNDEFINED(TYPE) \ + (!TYPE_UNSIGNED (TYPE) && !flag_wrapv && !flag_trapv && flag_strict_overflow) + +/* True if overflow for the given integral type should issue a + trap. */ +#define TYPE_OVERFLOW_TRAPS(TYPE) \ + (!TYPE_UNSIGNED (TYPE) && flag_trapv) + +/* True if pointer types have undefined overflow. */ +#define POINTER_TYPE_OVERFLOW_UNDEFINED (flag_strict_overflow) + /* Nonzero in a VAR_DECL or STRING_CST means assembler code has been written. Nonzero in a FUNCTION_DECL means that the function has been compiled. This is interesting in an inline function, since it might not need
[patch][rft] Don't mess with debug_hooks in objc
Hello,
There is code in objc-act.c to save and restore debug hooks to work
around a problem with the C front end.
The C front end calls debug hooks before they have been initialized.
This is a problem for dbxout, so there is code in dbxout.c to handle
the problem, see dbxout.c:preinit_symbols. This work-around code was
introduced in r77730.
In parallel, Apple was working on the big ObjC/ObjC++ merge (r87168),
and apparently they worked around the same problem all over again.
That look unnecessary to me.
Bootstrapped and tested on x86_64-unknown-linux-gnu. OK for trunk?
Ciao!
Steven
objc/
* objc-act.c: Do not include debug.h.
(synth_module_prologue): Do not save/restore write_symbols
and debug_hooks.
Index: objc/objc-act.c
===
--- objc/objc-act.c (revision 189469)
+++ objc/objc-act.c (working copy)
@@ -45,7 +45,6 @@ along with GCC; see the file COPYING3.
#include "function.h"
#include "toplev.h"
#include "ggc.h"
-#include "debug.h"
#include "c-family/c-target.h"
#include "diagnostic-core.h"
#include "intl.h"
@@ -2904,13 +2903,6 @@ static void
synth_module_prologue (void)
{
tree type;
- enum debug_info_type save_write_symbols = write_symbols;
- const struct gcc_debug_hooks *const save_hooks = debug_hooks;
-
- /* Suppress outputting debug symbols, because
- dbxout_init hasn't been called yet. */
- write_symbols = NO_DEBUG;
- debug_hooks = &do_nothing_debug_hooks;
#ifdef OBJCPLUS
push_lang_context (lang_name_c); /* extern "C" */
@@ -2997,9 +2989,6 @@ synth_module_prologue (void)
#ifdef OBJCPLUS
pop_lang_context ();
#endif
-
- write_symbols = save_write_symbols;
- debug_hooks = save_hooks;
}
/* --- const strings --- */
[patch] Bail out if the same label is emitted twice
Hello,
Just another small cleanup. This probably made sense before
function-at-a-time became the norm, 10 years ago.
Bootstrapped&tested on powerpc64-unknown-linux-gnu and x86_64-unknown-linux-gnu.
OK for trunk?
Ciao!
Steven
* emit-rtl.c (emit_label_before): Do not allow the same label
to be emitted twice.
(emit_label_after): Likewise.
(emit_label): Likewise.
Index: emit-rtl.c
===
--- emit-rtl.c (revision 189482)
+++ emit-rtl.c (working copy)
@@ -4221,14 +4221,9 @@ emit_barrier_before (rtx before)
rtx
emit_label_before (rtx label, rtx before)
{
- /* This can be called twice for the same label as a result of the
- confusion that follows a syntax error! So make it harmless. */
- if (INSN_UID (label) == 0)
-{
- INSN_UID (label) = cur_insn_uid++;
- add_insn_before (label, before, NULL);
-}
-
+ gcc_checking_assert (INSN_UID (label) == 0);
+ INSN_UID (label) = cur_insn_uid++;
+ add_insn_before (label, before, NULL);
return label;
}
@@ -4387,15 +4382,9 @@ emit_barrier_after (rtx after)
rtx
emit_label_after (rtx label, rtx after)
{
- /* This can be called twice for the same label
- as a result of the confusion that follows a syntax error!
- So make it harmless. */
- if (INSN_UID (label) == 0)
-{
- INSN_UID (label) = cur_insn_uid++;
- add_insn_after (label, after, NULL);
-}
-
+ gcc_checking_assert (INSN_UID (label) == 0);
+ INSN_UID (label) = cur_insn_uid++;
+ add_insn_after (label, after, NULL);
return label;
}
@@ -4811,14 +4800,9 @@ emit_call_insn (rtx x)
rtx
emit_label (rtx label)
{
- /* This can be called twice for the same label
- as a result of the confusion that follows a syntax error!
- So make it harmless. */
- if (INSN_UID (label) == 0)
-{
- INSN_UID (label) = cur_insn_uid++;
- add_insn (label);
-}
+ gcc_checking_assert (INSN_UID (label) == 0);
+ INSN_UID (label) = cur_insn_uid++;
+ add_insn (label);
return label;
}
[PATCH, i386]: Fix ix86_set_reg_reg_cost w.r.t. TFmode
Hello!
Recently, gcc was switched to enable TFmode moves in XMM registers
also for TARGET_SSE. Sync reg-reg move cost calculation.
2012-07-14 Uros Bizjak
* config/i386/i386.c (ix86_set_reg_reg_cost): Enable TFmode/TCmode
for TARGET_SSE.
Tested on x86_64-pc-linux-gnu {,-m32}, committed to mainline SVN.
Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 189478)
+++ config/i386/i386.c (working copy)
@@ -31962,7 +31962,7 @@ ix86_set_reg_reg_cost (enum machine_mode mode)
break;
case MODE_FLOAT:
- if ((TARGET_SSE2 && mode == TFmode)
+ if ((TARGET_SSE && mode == TFmode)
|| (TARGET_80387 && mode == XFmode)
|| ((TARGET_80387 || TARGET_SSE2) && mode == DFmode)
|| ((TARGET_80387 || TARGET_SSE) && mode == SFmode))
@@ -31970,7 +31970,7 @@ ix86_set_reg_reg_cost (enum machine_mode mode)
break;
case MODE_COMPLEX_FLOAT:
- if ((TARGET_SSE2 && mode == TCmode)
+ if ((TARGET_SSE && mode == TCmode)
|| (TARGET_80387 && mode == XCmode)
|| ((TARGET_80387 || TARGET_SSE2) && mode == DCmode)
|| ((TARGET_80387 || TARGET_SSE) && mode == SCmode))
Re: __int256
On Fri, 13 Jul 2012, Mike Stump wrote: > I don't have time to re-implement __int128 support in the compiler for > you. > > So, are there any other specific actionable things I can do for you to > make the patch acceptable? No. The right way to make __int256 support - the feature, not the present patch at all - acceptable for me is a series of incremental patches converting the existing __int128 support to use hooks for the target to define what __intN types it has without the architecture-independent compiler needing to hardcode the details of those types. You might push on whoever added __int128 support to add testcases for it - tests that __int128 works as expected including execution of all the usual C integer operations as well as __int128 being accecpted and rejected in the right contexts - since such tests are unfortunately missing. Having such tests would both help validate that a reworking of __int128 support does not cause regressions, as well as being a possible basis to add tests of __int256. -- Joseph S. Myers jos...@codesourcery.com
Re: PATCH: PR bootstrap/53963: [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
On Sat, Jul 14, 2012 at 11:54 AM, Steven Bosscher wrote: > On Sat, Jul 14, 2012 at 8:49 PM, H.J. Lu wrote: >> Hi, >> >> Revision 189453: >> >> http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00357.html >> >> removes type attribute comparison in gimple_types_compatible_p_1 and >> caused PR middle-end/53959 and PR bootstrap/53963. This restores type >> attribute comparison. Tested on Linux/x86-64. OK to install? >> >> Thanks. >> >> >> H.J. >> --- >> 2012-07-14 H.J. Lu >> >> PR middle-end/53959 >> PR bootstrap/53963 >> * gimple.c (gimple_types_compatible_p_1): Restore type attribute >> comparison. > > I think this deserves a bit more understanding of the problem before > reverting. Which type attributes survive up to this point? > Here they are: (gdb) call debug_tree (t1) > QI size constant 8> unit size constant 1> align 8 symtab 0 alias set -1 canonical type 0x71affbd0 attributes value >> arg-types unsigned DI size unit size align 64 symtab 0 alias set -1 canonical type 0x71aff738> chain chain chain > (gdb) call debug_tree (t2) > QI size constant 8> unit size constant 1> align 8 symtab 0 alias set -1 structural equality attributes value >> arg-types unsigned DI size unit size align 64 symtab 0 alias set -1 canonical type 0x71aff738> chain chain chain > (gdb) -- H.J.
Re: PATCH: PR bootstrap/53963: [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
On Sat, Jul 14, 2012 at 1:23 PM, H.J. Lu wrote: > On Sat, Jul 14, 2012 at 11:54 AM, Steven Bosscher > wrote: >> On Sat, Jul 14, 2012 at 8:49 PM, H.J. Lu wrote: >>> Hi, >>> >>> Revision 189453: >>> >>> http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00357.html >>> >>> removes type attribute comparison in gimple_types_compatible_p_1 and >>> caused PR middle-end/53959 and PR bootstrap/53963. This restores type >>> attribute comparison. Tested on Linux/x86-64. OK to install? >>> >>> Thanks. >>> >>> >>> H.J. >>> --- >>> 2012-07-14 H.J. Lu >>> >>> PR middle-end/53959 >>> PR bootstrap/53963 >>> * gimple.c (gimple_types_compatible_p_1): Restore type attribute >>> comparison. >> >> I think this deserves a bit more understanding of the problem before >> reverting. Which type attributes survive up to this point? >> > > Here they are: > > (gdb) call debug_tree (t1) > type align 8 symtab 0 alias set -1 canonical type 0x719babd0 > pointer_to_this > > QI > size bitsizetype> constant 8> > unit size 0x719ba000 sizetype> constant 1> > align 8 symtab 0 alias set -1 canonical type 0x71affbd0 > attributes purpose > value value >> > arg-types value 0x71aff7e0 __st_parameter_dt> > unsigned DI > size > unit size > align 64 symtab 0 alias set -1 canonical type 0x71aff738> > chain > chain 0x719ba5e8 int> > chain 0x719babd0 void>> > (gdb) call debug_tree (t2) > type align 8 symtab 0 alias set -1 canonical type 0x719babd0 > pointer_to_this > > QI > size bitsizetype> constant 8> > unit size 0x719ba000 sizetype> constant 1> > align 8 symtab 0 alias set -1 structural equality > attributes purpose > value value >> > arg-types value 0x71aff7e0 __st_parameter_dt> > unsigned DI > size > unit size > align 64 symtab 0 alias set -1 canonical type 0x71aff738> > chain > chain 0x719ba5e8 int> > chain 0x719babd0 void>> > (gdb) > > > -- > H.J. I updated a testcase to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53959 -- H.J.
Re: PATCH: PR bootstrap/53963: [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
On Sat, Jul 14, 2012 at 10:23 PM, H.J. Lu wrote: > On Sat, Jul 14, 2012 at 11:54 AM, Steven Bosscher > wrote: >> On Sat, Jul 14, 2012 at 8:49 PM, H.J. Lu wrote: >>> Hi, >>> >>> Revision 189453: >>> >>> http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00357.html >>> >>> removes type attribute comparison in gimple_types_compatible_p_1 and >>> caused PR middle-end/53959 and PR bootstrap/53963. This restores type >>> attribute comparison. Tested on Linux/x86-64. OK to install? >>> >>> Thanks. >>> >>> >>> H.J. >>> --- >>> 2012-07-14 H.J. Lu >>> >>> PR middle-end/53959 >>> PR bootstrap/53963 >>> * gimple.c (gimple_types_compatible_p_1): Restore type attribute >>> comparison. >> >> I think this deserves a bit more understanding of the problem before >> reverting. Which type attributes survive up to this point? >> > > Here they are: > > (gdb) call debug_tree (t1) > type align 8 symtab 0 alias set -1 canonical type 0x719babd0 > pointer_to_this > > QI > size bitsizetype> constant 8> > unit size 0x719ba000 sizetype> constant 1> > align 8 symtab 0 alias set -1 canonical type 0x71affbd0 > attributes purpose > value value >> > arg-types value 0x71aff7e0 __st_parameter_dt> > unsigned DI > size > unit size > align 64 symtab 0 alias set -1 canonical type 0x71aff738> > chain > chain 0x719ba5e8 int> > chain 0x719babd0 void>> > (gdb) call debug_tree (t2) > type align 8 symtab 0 alias set -1 canonical type 0x719babd0 > pointer_to_this > > QI > size bitsizetype> constant 8> > unit size 0x719ba000 sizetype> constant 1> > align 8 symtab 0 alias set -1 structural equality > attributes purpose > value value >> > arg-types value 0x71aff7e0 __st_parameter_dt> > unsigned DI > size > unit size > align 64 symtab 0 alias set -1 canonical type 0x71aff738> > chain > chain 0x719ba5e8 int> > chain 0x719babd0 void>> > (gdb) > You only have different ATTR_FNSPEC attributes. I don't know whether that should result in the types being incompatible, but I don't think so. How does this lead to failure? Is one of the types chosen as prevailing so that one of the functions ends up with the wrong ATTR_FNSPEC? Ciao! Steven
Re: PATCH: PR bootstrap/53963: [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
On Sat, Jul 14, 2012 at 1:41 PM, Steven Bosscher wrote:
> On Sat, Jul 14, 2012 at 10:23 PM, H.J. Lu wrote:
>> On Sat, Jul 14, 2012 at 11:54 AM, Steven Bosscher
>> wrote:
>>> On Sat, Jul 14, 2012 at 8:49 PM, H.J. Lu wrote:
Hi,
Revision 189453:
http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00357.html
removes type attribute comparison in gimple_types_compatible_p_1 and
caused PR middle-end/53959 and PR bootstrap/53963. This restores type
attribute comparison. Tested on Linux/x86-64. OK to install?
Thanks.
H.J.
---
2012-07-14 H.J. Lu
PR middle-end/53959
PR bootstrap/53963
* gimple.c (gimple_types_compatible_p_1): Restore type attribute
comparison.
>>>
>>> I think this deserves a bit more understanding of the problem before
>>> reverting. Which type attributes survive up to this point?
>>>
>>
>> Here they are:
>>
>> (gdb) call debug_tree (t1)
>> > type > align 8 symtab 0 alias set -1 canonical type 0x719babd0
>> pointer_to_this >
>> QI
>> size > bitsizetype> constant 8>
>> unit size > 0x719ba000 sizetype> constant 1>
>> align 8 symtab 0 alias set -1 canonical type 0x71affbd0
>> attributes > purpose
>> value > value >>
>> arg-types > value > 0x71aff7e0 __st_parameter_dt>
>> unsigned DI
>> size
>> unit size
>> align 64 symtab 0 alias set -1 canonical type 0x71aff738>
>> chain
>> chain > 0x719ba5e8 int>
>> chain > 0x719babd0 void>>
>> (gdb) call debug_tree (t2)
>> > type > align 8 symtab 0 alias set -1 canonical type 0x719babd0
>> pointer_to_this >
>> QI
>> size > bitsizetype> constant 8>
>> unit size > 0x719ba000 sizetype> constant 1>
>> align 8 symtab 0 alias set -1 structural equality
>> attributes > purpose
>> value > value >>
>> arg-types > value > 0x71aff7e0 __st_parameter_dt>
>> unsigned DI
>> size
>> unit size
>> align 64 symtab 0 alias set -1 canonical type 0x71aff738>
>> chain
>> chain > 0x719ba5e8 int>
>> chain > 0x719babd0 void>>
>> (gdb)
>>
>
> You only have different ATTR_FNSPEC attributes. I don't know whether
> that should result in the types being incompatible, but I don't think
> so.
>
> How does this lead to failure? Is one of the types chosen as
> prevailing so that one of the functions ends up with the wrong
> ATTR_FNSPEC?
>
I don't believe .wR attribute is compatible with .wW attribute:
[hjl@gnu-32 fortran]$ grep "wR" *
trans-decl.c: get_identifier (PREFIX("internal_unpack")), ".wR",
trans-io.c: get_identifier (PREFIX("transfer_integer_write")), ".wR",
trans-io.c: get_identifier (PREFIX("transfer_logical_write")), ".wR",
trans-io.c: get_identifier (PREFIX("transfer_character_write")), ".wR",
trans-io.c: get_identifier (PREFIX("transfer_character_wide_write")), ".wR",
trans-io.c: get_identifier (PREFIX("transfer_real_write")), ".wR",
trans-io.c: get_identifier (PREFIX("transfer_complex_write")), ".wR",
trans-io.c: get_identifier (PREFIX("transfer_real128_write")), ".wR",
trans-io.c: get_identifier (PREFIX("transfer_complex128_write")), ".wR",
[hjl@gnu-32 fortran]$ grep "wW" *
trans-io.c: get_identifier (PREFIX("transfer_integer")), ".wW",
trans-io.c: get_identifier (PREFIX("transfer_logical")), ".wW",
trans-io.c: get_identifier (PREFIX("transfer_character")), ".wW",
trans-io.c: get_identifier (PREFIX("transfer_character_wide")), ".wW",
trans-io.c: get_identifier (PREFIX("transfer_real")), ".wW",
trans-io.c: get_identifier (PREFIX("transfer_complex")), ".wW",
trans-io.c: get_identifier (PREFIX("transfer_real128")), ".wW",
trans-io.c: get_identifier (PREFIX("transfer_complex128")), ".wW",
[hjl@gnu-32 fortran]$
--
H.J.
[patch] Remove useless sets/clears of EDGE_CAN_FALLTHRU
Hello,
EDGE_CAN_FALLTHRU is internal to bb-reorder.c,
set_edge_can_fallthru_flag() clears it on all edges and computes it
fresh for bb-reorder.
The test in rtl_verify_flow_info_1 has to stay because bb-reorder
doesn't clean up the flag after it's done.
Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK?
Ciao!
Steven
* haifa-sched.c (init_before_recovery): Do not set EDGE_CAN_FALLTHRU.
* cfgrtl.c (force_nonfallthru_and_redirect): Likewise.
Index: haifa-sched.c
===
--- haifa-sched.c (revision 189478)
+++ haifa-sched.c (working copy)
@@ -7193,8 +7193,7 @@ init_before_recovery (basic_block *before_recovery
redirect_edge_succ (e, single);
make_single_succ_edge (single, empty, 0);
- make_single_succ_edge (empty, EXIT_BLOCK_PTR,
-EDGE_FALLTHRU | EDGE_CAN_FALLTHRU);
+ make_single_succ_edge (empty, EXIT_BLOCK_PTR, EDGE_FALLTHRU);
label = block_label (empty);
x = emit_jump_insn_after (gen_jump (label), BB_END (single));
Index: cfgrtl.c
===
--- cfgrtl.c(revision 189478)
+++ cfgrtl.c(working copy)
@@ -1365,8 +1365,8 @@ force_nonfallthru_and_redirect (edge e, basic_bloc
one and create separate abnormal edge to original destination.
This allows bb-reorder to make such edge non-fallthru. */
gcc_assert (e->dest == target);
- abnormal_edge_flags = e->flags & ~(EDGE_FALLTHRU | EDGE_CAN_FALLTHRU);
- e->flags &= EDGE_FALLTHRU | EDGE_CAN_FALLTHRU;
+ abnormal_edge_flags = e->flags & ~EDGE_FALLTHRU;
+ e->flags &= EDGE_FALLTHRU;
}
else
{
fix gcc.dg/pr53849.c
This test requires pthreads, so, I've copied bits from another testcase that
uses -pthreads in the same way.
Checked it in.
diff --git a/gcc/testsuite/gcc.dg/pr53849.c b/gcc/testsuite/gcc.dg/pr53849.c
index 3b67010..eddc45f 100644
--- a/gcc/testsuite/gcc.dg/pr53849.c
+++ b/gcc/testsuite/gcc.dg/pr53849.c
@@ -1,4 +1,5 @@
/* { dg-do compile } */
+/* { dg-require-effective-target pthread } */
/* { dg-options "-O2 -ftree-parallelize-loops=2 -fno-tree-loop-im" } */
extern int *b, *e[8], d;
Re: [PATCH] Improve andq $0xffffffff, %reg handling (PR target/53110)
On Wed, Apr 25, 2012 at 12:14 PM, Jakub Jelinek wrote:
> Hi!
>
> We have a splitter for reg1 = reg2 & 0x, but only if regnums
> are different. But movl %edi, %edi is a cheaper variant of
> andq $0x, %rdi even with the same register and doesn't clobber
> flags, so this patch attempts to expand it as a zero extension early.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2012-04-25 Jakub Jelinek
>
> PR target/53110
> * config/i386/i386.md (and3): For andq $0x, reg
> instead expand it as zero extension.
>
> --- gcc/config/i386/i386.md.jj 2012-04-25 12:14:54.0 +0200
> +++ gcc/config/i386/i386.md 2012-04-25 14:50:48.708925963 +0200
> @@ -7694,7 +7694,17 @@ (define_expand "and3"
> (and:SWIM (match_operand:SWIM 1 "nonimmediate_operand")
> (match_operand:SWIM 2 "")))]
>""
> - "ix86_expand_binary_operator (AND, mode, operands); DONE;")
> +{
> + if (mode == DImode
> + && GET_CODE (operands[2]) == CONST_INT
> + && INTVAL (operands[2]) == (HOST_WIDE_INT) 0x
> + && REG_P (operands[1]))
> +emit_insn (gen_zero_extendsidi2 (operands[0],
> +gen_lowpart (SImode, operands[1])));
> + else
> +ix86_expand_binary_operator (AND, mode, operands);
> + DONE;
> +})
>
> (define_insn "*anddi_1"
>[(set (match_operand:DI 0 "nonimmediate_operand" "=r,rm,r,r")
>
> Jakub
Can it be backported to 4.7 branch? It also fixed:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53961
on hjl/x32/gcc-4_7-branch.
Thanks.
--
H.J.
PATCH: fix typos in SH_ASM_SPEC
We've had this patch to add missing whitespace to the assembler spec
string in the SH back end in our local tree for a couple of years. I
think it's obvious enough that I've gone ahead and checked it in on
mainline too.
-Sandra
2012-07-14 Andrew Stubbs
Sandra Loosemore
gcc/
* config/sh/sh.h (SH_ASM_SPEC): Add spaces between options.
Index: gcc/config/sh/sh.h
===
--- gcc/config/sh/sh.h (revision 189485)
+++ gcc/config/sh/sh.h (working copy)
@@ -338,8 +338,8 @@ do { \
#endif
#define SH_ASM_SPEC \
- "%(subtarget_asm_endian_spec) %{mrelax:-relax %(subtarget_asm_relax_spec)}\
-%(subtarget_asm_isa_spec) %(subtarget_asm_spec)\
+ "%(subtarget_asm_endian_spec) %{mrelax:-relax %(subtarget_asm_relax_spec)} \
+%(subtarget_asm_isa_spec) %(subtarget_asm_spec) \
%{m2a:--isa=sh2a} \
%{m2a-single:--isa=sh2a} \
%{m2a-single-only:--isa=sh2a} \
Re: [RFA libiberty, gdb] Add hashtab support to filename_ncmp.c and use it in gdb.
> "Eli" == Eli Zaretskii writes: Eli> I understand all that, but why would the eq_f function need to be an Eli> external function on its own? It is just to avoid other users having to write their own. Eli> E.g., if we were to write a qsort replacement, would we have a Eli> suitable string comparison function declared extern, when it is a Eli> trivial wrapper around strcmp? Yes. We have streq for this, for use in hash tables and elsewhere. It would have been better if this were in libiberty, since currently there is a copy of this function in gdb and like 3 or 4 in gcc. Tom
[Fortran-dev][Patch, Fortran] C_F_Pointer cleanup
Dear all,
that's a follow up cleanup to the patch, which has just been merged.
Most parts should be really obvious and nice, however, the offset part
isn't. As the offset is not part of the descriptor defined at DTS
29113:2012's "8.2 C descriptors" (p. 17), we will have to drop it at
some point. Hence, I used the less readable name "tmp" and an integer
divide, instead of multiplying "stride" by "tmp" when setting the "sm"
and changing "tmp" to, e.g., "size".
Bootstrapped (with C) and regtested on x86-64-linux.
OK for the branch?
Currently failing are the following 14 (13) test cases:
gfortran.dg/optional_dim_3.f90 (I have a patch)
gfortran.dg/associated_2.f90
gfortran.dg/auto_char_dummy_array_1.f90
gfortran.dg/auto_char_len_3.f90
gfortran.dg/class_array_1.f03
gfortran.dg/class_array_2.f03
gfortran.dg/class_array_3.f03
gfortran.dg/class_to_type_1.f03
gfortran.dg/proc_decl_23.f90
gfortran.dg/select_type_26.f03
gfortran.dg/select_type_27.f03
gfortran.dg/read_eof_all.f90
gfortran.dg/transfer_intrinsic_3.f90
gfortran.dg/subref_array_pointer_2.f90
(Plus gfortran.dg/lto/pr45586 and gfortran.dg/realloc_on_assign_5.f03,
but those also fail on the trunk.)
Tobias
2012-07-15 Tobias Burnus
* trans-expr.c (conv_isocbinding_procedure): For C_F_Pointer,
directly set extent and sm instead of using ubound and stride.
2012-07-15 Tobias Burnus
* gfortran.dg/c_f_pointer_tests_3.f90: Update scan-tree-dump
pattern.
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c (Revision 189481)
+++ gcc/fortran/trans-expr.c (Arbeitskopie)
@@ -3315,7 +3315,7 @@ conv_isocbinding_procedure (gfc_se * se, gfc_symbo
gfc_se fptrse;
gfc_se shapese;
gfc_ss *ss, *shape_ss;
- tree desc, dim, tmp, stride, offset;
+ tree desc, dim, tmp, sm, offset;
stmtblock_t body, block;
gfc_loopinfo loop;
@@ -3378,9 +3378,10 @@ conv_isocbinding_procedure (gfc_se * se, gfc_symbo
gfc_copy_loopinfo_to_se (&shapese, &loop);
shapese.ss = shape_ss;
- stride = gfc_create_var (gfc_array_index_type, "stride");
+ sm = gfc_create_var (gfc_array_index_type, "sm");
offset = gfc_create_var (gfc_array_index_type, "offset");
- gfc_add_modify (&block, stride, gfc_index_one_node);
+ tmp = size_in_bytes (gfc_get_element_type (TREE_TYPE (desc)));
+ gfc_add_modify (&block, sm, fold_convert (TREE_TYPE (sm), tmp));
gfc_add_modify (&block, offset, gfc_index_zero_node);
/* Loop body. */
@@ -3389,23 +3390,27 @@ conv_isocbinding_procedure (gfc_se * se, gfc_symbo
dim = fold_build2_loc (input_location, MINUS_EXPR, gfc_array_index_type,
loop.loopvar[0], loop.from[0]);
- /* Set bounds and stride. */
+ /* Set bounds and stride multiplier. */
gfc_conv_descriptor_lbound_set (&body, desc, dim, gfc_index_one_node);
- gfc_conv_descriptor_stride_set (&body, desc, dim, stride);
+ gfc_conv_descriptor_sm_set (&body, desc, dim, sm);
gfc_conv_expr (&shapese, arg->next->next->expr);
gfc_add_block_to_block (&body, &shapese.pre);
- gfc_conv_descriptor_ubound_set (&body, desc, dim, shapese.expr);
+ gfc_conv_descriptor_extent_set (&body, desc, dim, shapese.expr);
gfc_add_block_to_block (&body, &shapese.post);
- /* Calculate offset. */
+ /* Calculate offset. Change from the stride multiplier back to the
+ stride. */
+ tmp = fold_build2_loc (input_location, TRUNC_DIV_EXPR,
+ gfc_array_index_type, sm,
+ fold_convert (TREE_TYPE (sm), tmp));
gfc_add_modify (&body, offset,
fold_build2_loc (input_location, PLUS_EXPR,
- gfc_array_index_type, offset, stride));
+ gfc_array_index_type, offset, tmp));
/* Update stride. */
- gfc_add_modify (&body, stride,
+ gfc_add_modify (&body, sm,
fold_build2_loc (input_location, MULT_EXPR,
- gfc_array_index_type, stride,
+ gfc_array_index_type, sm,
fold_convert (gfc_array_index_type,
shapese.expr)));
/* Finish scalarization loop. */
Index: gcc/testsuite/gfortran.dg/c_f_pointer_tests_3.f90
===
--- gcc/testsuite/gfortran.dg/c_f_pointer_tests_3.f90 (Revision 189481)
+++ gcc/testsuite/gfortran.dg/c_f_pointer_tests_3.f90 (Arbeitskopie)
@@ -31,10 +31,10 @@ end program test
!
! Array c_f_pointer:
!
-! { dg-final { scan-tree-dump-times " fptr_array.data = cptr;" 1 "original" } }
-! { dg-final { scan-tree-dump-times " fptr_array.dim\\\[S..\\\].lbound = 1;" 1 "original" } }
-! { dg-final { scan-tree-dump-times " fptr_array.dim\\\[S..\\\].ubound = " 1 "original" } }
-! { dg-final { scan-tree-dump-times " fptr_array.dim\\\[S..\\\].stride = " 1 "original" } }
+! { dg-final { scan-tree-dump-times " fptr_array.base_addr = cptr;" 1 "original" } }
+! { dg-final { scan-tree-dump-times " fptr_array.dim\\
