[PATCH] internalize a driver fn
I discovered pfatal_with_name is only used inside gcc.c. Making it static as obvious. nathan -- Nathan Sidwell 2018-09-09 Nathan Sidwell * gcc.h (pfatal_with_name): Don't declare here. * gcc.c (pfatal_with_name): Make static. Index: gcc.c === --- gcc.c (revision 264172) +++ gcc.c (working copy) @@ -373,6 +373,7 @@ static int default_arg (const char *, in static void set_multilib_dir (void); static void print_multilib_info (void); static void perror_with_name (const char *); +static void pfatal_with_name (const char *) ATTRIBUTE_NORETURN; static void display_help (void); static void add_preprocessor_option (const char *, int); static void add_assembler_option (const char *, int); Index: gcc.h === --- gcc.h (revision 264172) +++ gcc.h (working copy) @@ -71,7 +71,6 @@ struct spec_function /* These are exported by gcc.c. */ extern int do_spec (const char *); extern void record_temp_file (const char *, int, int); -extern void pfatal_with_name (const char *) ATTRIBUTE_NORETURN; extern void set_input (const char *); /* Spec files linked with gcc.c must provide definitions for these. */
Re: [ARM/FDPIC v2 02/21] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts
On Fri, 31 Aug 2018 at 16:13, Christophe Lyon
wrote:
>
> On Wed, 29 Aug 2018 at 12:46, Kyrill Tkachov
> wrote:
> >
> >
> > On 13/07/18 17:10, christophe.l...@st.com wrote:
> > > From: Christophe Lyon
> > >
> > > The new arm-uclinuxfdpiceabi target behaves pretty much like
> > > arm-linux-gnueabi. In order the enable the same set of features, we
> > > have to update several configure scripts that generally match targets
> > > like *-*-linux*: in most places, we add *-uclinux* where there is
> > > already *-linux*, or uclinux* when there is already linux*.
> > >
> > > In gcc/config.gcc and libgcc/config.host we use *-*-uclinuxfdpiceabi
> > > because there is already a different behaviour for *-*uclinux* target.
> > >
> > > In libtool.m4, we use uclinuxfdpiceabi in cases where ELF shared
> > > libraries support is required, as uclinux does not guarantee that.
> > >
> > > 2018-XX-XX Christophe Lyon
> > >
> > > * config/futex.m4: Handle *-uclinux*.
> > > * config/tls.m4 (GCC_CHECK_TLS): Likewise.
> > > * gcc/config.gcc: Handle *-*-uclinuxfdpiceabi.
> > > * libatomic/configure.tgt: Handle arm*-*-uclinux*.
> > > * libgcc/config.host: Handle *-*-uclinuxfdpiceabi.
> > > * libitm/configure.tgt: Handle *-*-uclinux*.
> > > * libatomic/configure: Regenerate.
> > > * libitm/configure: Regenerate.
> > > * libstdc++-v3/acinclude.m4: Handle uclinux*.
> > > * libstdc++-v3/configure: Regenerate.
> > > * libstdc++-v3/configure.host: Handle uclinux*
> > > * libtool.m4: Handle uclinux*.
> > >
> >
> > Most of these sub-directories have their own ChangeLogs (just for the
> > record).
> > What happens if a user tries to configure armeb-*-linuxfdpiceabi. Is this
> > an unsupported configuration?
> > Will this error out? I think some regexes here will allow such a target.
>
> Yes. I wondered about that. I must admit I haven't tested it, but
> since I don't think anything in the patch series is
> endianness-dependent, I thought I should include armeb.
> Do you prefer I remove it?
> >
> > Is the target triplet set in stone now?
> I think it is part of binutils-2.31, but we can probably still change
> it, since the whole toolchain isn't available yet, no product should
> rely on the target name.
>
> It will be just painful to adjust the testsuite again
>
> > I think Richard had some thoughts on the naming...
For reference, here is what Joseph said when I first submitted the
binutils patch series:
https://sourceware.org/ml/binutils/2018-03/msg00324.html
> >
> > Thanks,
> > Kyrill
> >
> > > Change-Id: I6a1fdcd9847d8a82179a214612a3474c1f492916
> > >
> > > diff --git a/config/futex.m4 b/config/futex.m4
> > > index e95144d..4dffe15 100644
> > > --- a/config/futex.m4
> > > +++ b/config/futex.m4
> > > @@ -9,7 +9,7 @@ AC_DEFUN([GCC_LINUX_FUTEX],[dnl
> > > GCC_ENABLE(linux-futex,default, ,[use the Linux futex system call],
> > > permit yes|no|default)
> > > case "$target" in
> > > - *-linux*)
> > > + *-linux* | *-uclinux*)
> > > case "$enable_linux_futex" in
> > >default)
> > > # If headers don't have gettid/futex syscalls definition, then
> > > diff --git a/config/tls.m4 b/config/tls.m4
> > > index 4e170c8..5a8676e 100644
> > > --- a/config/tls.m4
> > > +++ b/config/tls.m4
> > > @@ -76,7 +76,7 @@ AC_DEFUN([GCC_CHECK_TLS], [
> > >dnl Shared library options may depend on the host; this check
> > >dnl is only known to be needed for GNU/Linux.
> > >case $host in
> > > - *-*-linux*)
> > > + *-*-linux* | -*-uclinux*)
> > >LDFLAGS="-shared -Wl,--no-undefined $LDFLAGS"
> > >;;
> > >esac
> > > diff --git a/gcc/config.gcc b/gcc/config.gcc
> > > index ef67c88..808ff82 100644
> > > --- a/gcc/config.gcc
> > > +++ b/gcc/config.gcc
> > > @@ -759,7 +759,7 @@ case ${target} in
> > > *-*-fuchsia*)
> > >native_system_header_dir=/include
> > >;;
> > > -*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-gnu* |
> > > *-*-kopensolaris*-gnu)
> > > +*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-gnu* |
> > > *-*-kopensolaris*-gnu | *-*-uclinuxfdpiceabi)
> > >extra_options="$extra_options gnu-user.opt"
> > >gas=yes
> > >gnu_ld=yes
> > > @@ -768,7 +768,7 @@ case ${target} in
> > >esac
> > >tmake_file="t-slibgcc"
> > >case $target in
> > > -*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu |
> > > *-*-kopensolaris*-gnu)
> > > +*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu |
> > > *-*-kopensolaris*-gnu | *-*-uclinuxfdpiceabi)
> > >:;;
> > > *-*-gnu*)
> > >native_system_header_dir=/include
> > > @@ -788,7 +788,7 @@ case ${target} in
> > > *-*-*android*)
> > >tm_defines="$tm_defines DEFAULT_LIBC=LIBC_BIONIC"
> > >;;
> > > -*-*-*uclibc*)
> > > +*-*-*uclibc* | *-*-uclinuxfdpiceabi)
> > >tm_defines="$tm_defines DEFAULT_LIBC=LIBC
Re: [PATCH 2/6] detect unterminated const arrays in strlen calls (PR 86552)
On 09/09/18 01:47, Jeff Law wrote:
> On 9/8/18 3:47 PM, Bernd Edlinger wrote:
>> Hi,
>>
>>
>>> -fold_builtin_strlen (location_t loc, tree type, tree arg)
>>> +fold_builtin_strlen (location_t loc, tree fndecl, tree type, tree arg)
>>> {
>>> if (!validate_arg (arg, POINTER_TYPE))
>>> return NULL_TREE;
>>> else
>>> {
>>> - tree len = c_strlen (arg, 0);
>>> -
>>> + tree nonstr = NULL_TREE;
>>> + tree len = c_strlen (arg, 0, &nonstr);
>>> if (len)
>>> - return fold_convert_loc (loc, type, len);
>>> + {
>>> + if (loc == UNKNOWN_LOCATION && EXPR_HAS_LOCATION (arg))
>>> + loc = EXPR_LOCATION (arg);
>>> +
>>> + /* To avoid warning multiple times about unterminated
>>> +arrays only warn if its length has been determined
>>> +and is being folded to a constant. */
>>> + if (nonstr)
>>> + warn_string_no_nul (loc, NULL_TREE, fndecl, nonstr);
>>> +
>>> + return fold_convert_loc (loc, type, len);
>>> + }
>>>
>>> return NULL_TREE;
>>
>> If I see that right, this will do a wrong folding,
>> just to suppress duplicate warnings.
>>
>> But it will re-introduce a path to PR87053, since c_strlen
>> is supposed to return the wrong value because nonstr
>> suggests the caller is able to handle this.
>>
>> I think c_strlen should never return anything that is invalid.
>> Returning len and nonstr should be mutually exclusive events.
> Conceptually I agree and have already been looking at this. But in
> practice I'm still on the fence.
>
> I'm fairly unhappy with the APIs we're using here and the inconsistency
> in what nonstr means in terms of the return value from various
> functions. We see this when we start layering the warnings on top of
> the trunk (which has the 87053 fix). In some cases we want nonstr to
> force the function to return an "I don't know value, typically
> NULL_TREE", but in other cases we really want the function to still
> return the length and let the caller decide what to do about the
> termination problem.
>
> It doesn't help that we also have memsize as well.
>
> Rationalizing the APIs here is likely going to be a prereq to move forward.
>
Yes, I agree. The API is trying to solve everything at once, that is not good.
I have given Martin's part 2/6 patch a little massage tonight,
and reached this nice result:
XPASS: gcc.dg/warn-strlen-no-nul.c pr? (test for warnings, line 91)
XPASS: gcc.dg/warn-strlen-no-nul.c pr? (test for warnings, line 95)
XPASS: gcc.dg/warn-strlen-no-nul.c pr? (test for warnings, line 98)
XPASS: gcc.dg/warn-strlen-no-nul.c pr? (test for warnings, line 100)
XPASS: gcc.dg/warn-strlen-no-nul.c pr? (test for warnings, line 107)
XPASS: gcc.dg/warn-strlen-no-nul.c pr? (test for warnings, line 109)
XPASS: gcc.dg/warn-strlen-no-nul.c pr? (test for warnings, line 110)
XPASS: gcc.dg/warn-strlen-no-nul.c pr? (test for warnings, line 118)
XPASS: gcc.dg/warn-strlen-no-nul.c bug (test for warnings, line 122)
XPASS: gcc.dg/warn-strlen-no-nul.c bug (test for warnings, line 123)
I left the test case as-is, just removed the ugly
"Prune out warnings with no location (pr?)."
at the end of the test.
How do you like that?
Bernd.
Index: gcc/builtins.c
===
--- gcc/builtins.c (revision 264167)
+++ gcc/builtins.c (working copy)
@@ -513,7 +513,7 @@ get_pointer_alignment (tree exp)
[ PTR, PTR + MAXELTS ) where each element's size is ELTSIZE bytes.
ELTSIZE must be a power of 2 less than 8. Used by c_strlen. */
-unsigned
+static unsigned
string_length (const void *ptr, unsigned eltsize, unsigned maxelts)
{
gcc_checking_assert (eltsize == 1 || eltsize == 2 || eltsize == 4);
@@ -542,6 +542,27 @@ string_length (const void *ptr, unsigned eltsize,
return n;
}
+/* For a call at LOC to a function FN that expects a string in the argument
+ ARG, issue a diagnostic due to it being a called with an argument
+ declared at NONSTR that is a character array with no terminating NUL. */
+
+void
+warn_string_no_nul (location_t loc, const char *fn, tree arg, tree decl)
+{
+ if (TREE_NO_WARNING (arg))
+return;
+
+ loc = expansion_point_location_if_in_system_header (loc);
+
+ if (warning_at (loc, OPT_Wstringop_overflow_,
+ "%qs argument missing terminating nul", fn))
+{
+ inform (DECL_SOURCE_LOCATION (decl),
+ "referenced argument declared here");
+ TREE_NO_WARNING (arg) = 1;
+}
+}
+
/* Compute the length of a null-terminated character string or wide
character string handling character sizes of 1, 2, and 4 bytes.
TREE_STRING_LENGTH is not the right way because it evaluates to
@@ -559,6 +580,11 @@ string_length (const void *ptr, unsigned eltsize,
accesses. Note that this implies the result is not going to be emitted
into the instruction stream.
+ If a not zero-terminated string value is encounter
[wwwdocs] Avoid widths for tables used for design of our main page
This does not actually make a real difference (visually); tested with a couple of browsers to make sure. Committed. Gerald Index: style.mhtml === RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v retrieving revision 1.153 diff -u -r1.153 style.mhtml --- style.mhtml 8 Sep 2018 20:47:46 - 1.153 +++ style.mhtml 9 Sep 2018 09:37:48 - @@ -73,7 +73,7 @@ - + > > @@ -84,7 +84,7 @@ - + About GCC
[wwwdocs] Use CSS to format gcc-3.1/criteria.html
This was the last regular page (outside our main page, where I also
nearly completed the conversion) that wasn't HTML 5 but used deprecated
elements.
Committed.
Gerald
Generalize the "center" class to also center non-text elements such
as tables. Use that for gcc-3.1/criteria.html.
Index: gcc.css
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v
retrieving revision 1.64
diff -u -r1.64 gcc.css
--- gcc.css 3 Sep 2018 19:43:07 - 1.64
+++ gcc.css 9 Sep 2018 10:21:59 -
@@ -17,7 +17,7 @@
.left { text-align:left; }
.right{ text-align:right; }
-.center { text-align:center; }
+.center { text-align:center; margin-left:auto; margin-right:auto; }
.top { vertical-align:top; }
.width33 { width:33%; }
Index: gcc-3.1/criteria.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.1/criteria.html,v
retrieving revision 1.39
diff -u -r1.39 criteria.html
--- gcc-3.1/criteria.html 1 Sep 2018 23:42:03 - 1.39
+++ gcc-3.1/criteria.html 9 Sep 2018 10:21:59 -
@@ -70,7 +70,7 @@
systems and the most popular microprocessors. Of course, where
possible, the release will support other targets as well.
-
+
Primary Evaluation Platforms
Chip OS
Triplet
@@ -123,7 +123,7 @@
team, will make reasonable efforts to assist these volunteers by
answering questions and reviewing patches as time permits.
-
+
Secondary Evaluation Platforms
Chip OS
Triplet
@@ -197,7 +197,7 @@
to general information about a package and a source URL. Versions
shown here are used for GCC 3.1 integration testing.
-
+
Integration Tests
Name
Language
@@ -309,7 +309,7 @@
Therefore, we will use the following benchmarks for measuring code
quality:
-
+
Name
Language
Source URL
@@ -351,7 +351,7 @@
In order to measure compile-time performance, we will use the
following unit tests:
-
+
Name
Language
Source
Re: [wwwdocs] gcc-3.0/criteria.html -- fix up to HTML 5
On Sun, 2 Sep 2018, Gerald Pfeifer wrote: > ...by stripping use of some obsolete features and adding missing > table cells (). Thinking about it again, this centers the tables as I just did with gcc-3.1/criteria.html. Applied. Gerald Index: gcc-3.0/criteria.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.0/criteria.html,v retrieving revision 1.35 diff -u -r1.35 criteria.html --- gcc-3.0/criteria.html 2 Sep 2018 16:56:44 - 1.35 +++ gcc-3.0/criteria.html 9 Sep 2018 10:29:10 - @@ -113,7 +113,7 @@ systems and the most popular microprocessors. Of course, where possible, the release will support other targets as well. - + Primary Evaluation Platforms Chip OS Triplet AlphaRed Hat Linux 6.2 @@ -150,7 +150,7 @@ team, will make reasonable efforts to assist these volunteers by answering questions and reviewing patches as time permits. - + Secondary Evaluation Platforms Chip OS Triplet Tester @@ -218,7 +218,7 @@ and high-level code, of numerical and logical programs, and of different programming languages. - + Integration Tests Name Language @@ -296,7 +296,7 @@ previous releases. Therefore, we will use the following benchmarks for measuring code quality: - + Name Language Source URL @@ -346,7 +346,8 @@ In order to measure compile-time performance, we will use the following unit tests: - + + Name Language Source
Go patch committed: put type descriptor initializers in .rodata
This patch to the Go frontend by Than McIntosh puts type descriptor initializers in the .rodata section. When creating type descriptor variables, the frontend (specifically Type::make_type_descriptor_var) invokes the immutable_struct() and immutable_struct_set_init() back end methods, so as to insure that these items go into the .rodata section of the generate object file. The expression initializers for these variables can contain nested subexpressions, however, and these subexpressions were not always being placed into .rodata. This patch changes the backend-gen code for slice initializers to emit implicit variables into .rodata if those initializers are part of a type descriptor init. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian Index: gcc/go/gofrontend/MERGE === --- gcc/go/gofrontend/MERGE (revision 264163) +++ gcc/go/gofrontend/MERGE (working copy) @@ -1,4 +1,4 @@ -da249ffd264154cc992e76ff03f91f700d3bf53e +06e688ff6d829c8de3735e9f59b61b373afc596f The first line of this file holds the git revision number of the last merge done from the gofrontend repository. Index: gcc/go/gofrontend/expressions.cc === --- gcc/go/gofrontend/expressions.cc(revision 264163) +++ gcc/go/gofrontend/expressions.cc(working copy) @@ -4453,7 +4453,8 @@ Unary_expression::do_get_backend(Transla // initialize the value once, so we can use this directly // rather than copying it. In that case we can't make it // read-only, because the program is permitted to change it. - copy_to_heap = context->function() != NULL; + copy_to_heap = (context->function() != NULL + || context->is_const()); } std::string asm_name(go_selectively_encode_id(var_name)); Bvariable* implicit =
[Patch, Fortran, F03] PR 85395: private clause contained in derived type acquires spurious scope
Hi all,
the attached patch fixes a problem with the accessibility of procedure
pointer components (private/public attribute). It is rather
straightforward and regtest cleanly on x86_64-linux-gnu (for further
details see the PR). Ok for trunk?
Cheers,
Janus
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index 7cfb94ee115..11adc5d13d5 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,3 +1,9 @@
+2018-09-09 Janus Weil
+
+ PR fortran/85395
+ * decl.c (match_binding_attributes): Use correct default accessibility
+ for procedure pointer components.
+
2018-09-03 Jerry DeLisle
* simplify.c (gfc_simplify_modulo): Re-arrange code to test whether
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 03298833c98..3d19ad479e5 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -10570,7 +10570,8 @@ match_binding_attributes (gfc_typebound_proc* ba, bool generic, bool ppc)
done:
if (ba->access == ACCESS_UNKNOWN)
-ba->access = gfc_typebound_default_access;
+ba->access = ppc ? gfc_current_block()->component_access
+ : gfc_typebound_default_access;
if (ppc && !seen_ptr)
{
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 0c038441a8c..118c03f17f7 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2018-09-09 Janus Weil
+
+ PR fortran/85395
+ * gfortran.dg/proc_ptr_comp_52.f90: New test case.
+
2018-09-08 Marek Polacek
PR c++/87150 - wrong ctor with maybe-rvalue semantics.
diff --git a/gcc/testsuite/gfortran.dg/proc_ptr_comp_52.f90 b/gcc/testsuite/gfortran.dg/proc_ptr_comp_52.f90
new file mode 100644
index 000..631c0180753
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/proc_ptr_comp_52.f90
@@ -0,0 +1,33 @@
+! { dg-do compile }
+!
+! PR 85395: [F03] private clause contained in derived type acquires spurious scope
+!
+! Contributed by
+
+module defs
+ implicit none
+
+ type :: base
+ contains
+ private
+ end type
+
+ type :: options
+ procedure(), pointer, nopass :: ptr
+ end type
+
+ type :: t
+ private
+ procedure(), pointer, nopass, public :: ptr
+ end type
+end module
+
+
+program p
+ use defs
+ implicit none
+ type(options) :: self
+ type(t) :: dt
+ self%ptr => null()
+ dt%ptr => null()
+end
Committed, PR target/85666 1/2, MMIX: Don't call leaf_function_p
It's IMO never a good idea to call leaf_function_p in port-specific code. Sooner or later, you'll need that information in a context where calling leaf_function_p is either a bad idea (it does a linear walk over all emitted insns in a function) or invalid (called when global context is within a sequence), like here. I kind of knew that, just bad judgement. :) Better find out leaffunctionness some other way, and/or stash it in a field in cfun->machine. There's one more patch needed for PR85666, to bring back mmix-knuth-mmixware to a buildable state. gcc: PR target/85666 * config/mmix/mmix.c (MMIX_CFUN_NEEDS_SAVED_EH_RETURN_ADDRESS): Don't call leaf_function_p, instead use has_hard_reg_initial_val. Index: gcc/config/mmix/mmix.c === --- gcc/config/mmix/mmix.c (revision 264163) +++ gcc/config/mmix/mmix.c (working copy) @@ -60,19 +60,16 @@ /* We have no means to tell DWARF 2 about the register stack, so we need to store the return address on the stack if an exception can get into - this function. FIXME: Narrow condition. Before any whole-function - analysis, df_regs_ever_live_p () isn't initialized. We know it's up-to-date - after reload_completed; it may contain incorrect information some time - before that. Within a RTL sequence (after a call to start_sequence, - such as in RTL expanders), leaf_function_p doesn't see all insns - (perhaps any insn). But regs_ever_live is up-to-date when - leaf_function_p () isn't, so we "or" them together to get accurate - information. FIXME: Some tweak to leaf_function_p might be - preferable. */ + this function. We'll have an "initial value" recorded for the + return-register if we've seen a call instruction emitted. This note + will be inaccurate before instructions are emitted, but the only caller + at that time is looking for modulo from stack-boundary, to which the + return-address does not contribute, and which is always 0 for MMIX + anyway. Beware of calling leaf_function_p here, as it'll abort if + called within a sequence. */ #define MMIX_CFUN_NEEDS_SAVED_EH_RETURN_ADDRESS\ (flag_exceptions \ - && ((reload_completed && df_regs_ever_live_p (MMIX_rJ_REGNUM)) \ - || !leaf_function_p ())) + && has_hard_reg_initial_val (Pmode, MMIX_INCOMING_RETURN_ADDRESS_REGNUM)) #define IS_MMIX_EH_RETURN_DATA_REG(REGNO) \ (crtl->calls_eh_return\ brgds, H-P
Committed, PR target/85666 2/2, MMIX: Handle emitting data bytes as non-literals
Until location views (in gcc-8), there apparently was no need to
emit single bytes of data as anything but bare CONST_INTs,
neither actual data nor dwarf2 debug. With location views,
there's a field within dwarf2 records for inlined subroutines
that as assembly code looks as follows in context (cutout of
assembly output with -dA for the failing libgcc/unwind-c.c):
.uleb128 0x1c !# (DIE (0x3b1) DW_TAG_inlined_subroutine)
.4byte 0x95e !# DW_AT_abstract_origin
.8byte LBI:49 !# DW_AT_entry_pc
.byte LVU:281
!# DW_AT_GNU_entry_view
.4byte Ldebug_ranges:0+0x50!# DW_AT_ranges
BYTE2
!# DW_AT_call_file (/home/hp/x/libgcc/unwind-c.c)
BYTE200
!# DW_AT_call_line
BYTE11
!# DW_AT_call_column
.4byte 0x489 !# DW_AT_sibling
Note the ".byte LVU:281". The value of LVU:281 is (IIUC) set in a
preceding line that says
.loc 1 279 1 view LVU:281
so it's defined at the time it's used; no relocs or second-pass fixups
needed in the assembler. The preferable "BYTE" pseudodirective
(preferable because it's the same pseudo as "mmixal"), handles only
literal values. There may supposedly exist other assemblers with
similar issues, but I guess we'd have heard from them by now.
This is the second patch of two needed to bring back
mmix-knuth-mmixware to a buildable state. I'll backport both to
gcc-8.
Still, I see lots of test-suite failures, both due to LTO
problems (linking ELF input to mmo format, with non-code
non-data wrapped, but being mishandled by the linker) and to
what appears to be another binutils-bug, so no test-results will
be posted until I can trim the FAILs down to a level where the
sheer volume does not get rejected by the gcc-testresults
mailing list; say to the level of the cris-elf results recently
posted there.
gcc:
PR target/85666
* config/mmix/mmix.c (mmix_assemble_integer): Handle byte-size
non-CONST_INT rtx:es using assemble_integer_with_op ".byte".
Index: gcc/config/mmix/mmix.c
===
--- gcc/config/mmix/mmix.c (revision 264163)
+++ gcc/config/mmix/mmix.c (working copy)
@@ -1373,8 +1373,14 @@
case 1:
if (GET_CODE (x) != CONST_INT)
{
- aligned_p = 0;
- break;
+ /* There is no "unaligned byte" op or generic function to
+ which we can punt, so we have to handle this here. As
+ the expression isn't a plain literal, the generated
+ assembly-code can't be mmixal-equivalent (i.e. "BYTE"
+ won't work) and thus it's ok to emit the default op
+ ".byte". */
+ assemble_integer_with_op ("\t.byte\t", x);
+ return true;
}
fputs ("\tBYTE\t", asm_out_file);
mmix_print_operand (asm_out_file, x, 'B');
brgds, H-P
Committed, PR target/86794, MMIX TARGET_HAVE_SPECULATION_SAFE_VALUE: Not needed.
The mythical MMIX hardware engineers have wisely understood the need to automatically disable speculation when a speculated execution path transitions to kernel mode. There might be mythical talk about using a bit in a configuration register to enable even that, but that's just speculation and some say allowing speculation over such mode transitions would be unresponsible and bad engineering. gcc: PR target/86794 * config/mmix/mmix.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Redefine to speculation_safe_value_not_needed. Index: gcc/config/mmix/mmix.c === --- gcc/config/mmix/mmix.c (revision 264163) +++ gcc/config/mmix/mmix.c (working copy) @@ -227,6 +224,9 @@ #undef TARGET_CONDITIONAL_REGISTER_USAGE #define TARGET_CONDITIONAL_REGISTER_USAGE mmix_conditional_register_usage +#undef TARGET_HAVE_SPECULATION_SAFE_VALUE +#define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed + #undef TARGET_RTX_COSTS #define TARGET_RTX_COSTS mmix_rtx_costs #undef TARGET_ADDRESS_COST brgds, H-P
Re: Prune TYPE_NEXT_VARIANT lists in free_lang_data
On September 8, 2018 10:49:02 AM GMT+01:00, Jan Hubicka wrote:
>Hi
>while working on path to replace type variant by first compatible one I
>run
>into issue that the first vairant was not seen by free_lang_data. I
>think this
>is a bug becuase nothing prevents middle-end from looking up a variant
>there
>and using it when it needs to do so.
>
>I tried to walk the variant lists and free lang data on them but that
>crahses
>because not all types in variant list passes verify_type (C++ puts
>there
>incomplete type variants whose canonical type is complete and thus they
>are
>considered bogus). So pruning those lists seems to be better variant.
>
>Bootstrapped/regtested x86_64-linux, OK?
But if they are still reachable by GC they are now bogously unlinked. We
already do not stream unused variants, so what does this achieve? Maybe we
should make the variant list GCable somehow?
>Honza
>
> * tree.c (free_lang_data_in_cgraph): Prune TYPE_NEXT_VARIANT lists.
>Index: tree.c
>===
>--- tree.c (revision 263989)
>+++ tree.c (working copy)
>@@ -5845,7 +5845,12 @@ free_lang_data_in_cgraph (void)
>
> /* Traverse every type found freeing its language data. */
> FOR_EACH_VEC_ELT (fld.types, i, t)
>-free_lang_data_in_type (t);
>+{
>+ free_lang_data_in_type (t);
>+ while (TYPE_NEXT_VARIANT (t)
>+ && !fld.pset.contains (TYPE_NEXT_VARIANT (t)))
>+ TYPE_NEXT_VARIANT (t) = TYPE_NEXT_VARIANT (TYPE_NEXT_VARIANT (t));
>+}
> if (flag_checking)
> {
> FOR_EACH_VEC_ELT (fld.types, i, t)
Re: [wwwdocs] gcc-3.3/criteria.html - simplify
On Sun, 2 Sep 2018, Gerald Pfeifer wrote: > Similar changes as for gcc-3.4/criteria.html, now HTML 5. And similar to what I did with gcc-3.1/criteria.html earlier today, now again with centered tables (and avoiding the border="1" attribute). Committed. Gerald Index: gcc-3.3/criteria.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.3/criteria.html,v retrieving revision 1.16 diff -u -r1.16 criteria.html --- gcc-3.3/criteria.html 2 Sep 2018 21:41:07 - 1.16 +++ gcc-3.3/criteria.html 9 Sep 2018 18:43:25 - @@ -64,7 +64,7 @@ systems and the most popular microprocessors. Of course, where possible, the release will support other targets as well. - + Primary Evaluation Platforms Chip OS Triplet @@ -123,7 +123,7 @@ team, will make reasonable efforts to assist these volunteers by answering questions and reviewing patches as time permits. - + Secondary Evaluation Platforms Chip OS Triplet @@ -200,7 +200,7 @@ to general information about a package and a source URL. Versions shown here are used for GCC 3.3 integration testing. - + Integration Tests Name Language @@ -313,7 +313,7 @@ Therefore, we will use the following benchmarks for measuring code quality: - + Name Language Source URL @@ -356,7 +356,8 @@ In order to measure compile-time performance, we will use the following unit tests: - + + Name Language Source
[wwwdocs] Continue CSSification, introducing table.border and updating gcc-4.3/porting.html
Introduce a new style table.border that approaches the classic
, just with a bit less use of borders. Use
this in gcc-4.3/porting.html.
Applied.
Gerald
Index: gcc.css
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v
retrieving revision 1.65
diff -u -r1.65 gcc.css
--- gcc.css 9 Sep 2018 10:25:42 - 1.65
+++ gcc.css 9 Sep 2018 19:53:26 -
@@ -97,6 +97,9 @@
/* Quote an e-mail. The first has the sender, the second the quote. */
blockquote.mail div:nth-child(2) { border-left: solid blue; padding-left: 4pt;
}
+/* This comes close to , alas a bit less bordersome. */
+table.borderth { border:2px solid; }
+
/* C++ status tables. */
table.cxxstatus th, table.cxxstatus td { border: 1px solid gray; }
table.cxxstatus td:nth-child(3) { text-align:center; }
Index: gcc-4.3/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.3/porting_to.html,v
retrieving revision 1.17
diff -u -r1.17 porting_to.html
--- gcc-4.3/porting_to.html 1 Sep 2018 23:42:04 - 1.17
+++ gcc-4.3/porting_to.html 9 Sep 2018 19:53:26 -
@@ -124,7 +125,7 @@
succeed.
-
+
If missing
Then include this header
@@ -177,7 +178,7 @@
-
+
If missing
Then include this header
[wwwdocs] Mirror the recent gcc-4.3/porting_to.html change to gcc-4.4
Applied. Gerald Index: gcc-4.4/porting_to.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.4/porting_to.html,v retrieving revision 1.12 diff -u -r1.12 porting_to.html --- gcc-4.4/porting_to.html 1 Sep 2018 23:42:04 - 1.12 +++ gcc-4.4/porting_to.html 9 Sep 2018 20:15:51 - @@ -143,7 +143,7 @@ The table below shows the functions and files that have been changed. - + Header Functions
Re: [wwwdocs] projects/prefetch.html -- replace direct formatting of tables with CSS
On Sun, 2 Sep 2018, Gerald Pfeifer wrote: > Committed. Buiding on my changes last Sunday, this uses the new class "border" I introduced earlier today, thus avoiding validation warnings. Committed. Gerald Index: projects/prefetch.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/prefetch.html,v retrieving revision 1.37 diff -u -r1.37 prefetch.html --- projects/prefetch.html 2 Sep 2018 15:11:38 - 1.37 +++ projects/prefetch.html 9 Sep 2018 20:20:40 - @@ -208,7 +208,7 @@ Summary - + Target Prefetch amount @@ -333,7 +333,7 @@ Instruction LDS with a destination of register F31 prefetches for a store. - + LDBU, LDF, LDG, LDL, LDT, LDWU @@ -358,7 +358,7 @@ The Alpha architecture also defines the following instructions [2]: - + FETCH Prefetch Data @@ -380,7 +380,7 @@ data stream made up of the following elements [4].: - + EA the effective address of the first unit in the sequence; @@ -405,7 +405,7 @@ The instructions that operate on these data streams are: - + dst (Data Stream Touch); data marked as most recently used @@ -474,7 +474,7 @@ The SSE prefetch instruction has the following variants: - + prefetcht0 Temporal data; prefetch data into all cache levels. @@ -508,7 +508,7 @@ The possible values for the locality hint are: - + none Temporal locality for cache level 1 and higher (all levels). @@ -545,7 +545,7 @@ [9] and MIPS64 [10], takes a hint with one of the following values: - + load data is expected to be read, not modified @@ -598,7 +598,7 @@ MMIX has the following data prefetch instructions [11][12]: - + PRELD preload a specified number of bytes of data @@ -626,7 +626,7 @@ A normal load to register GR0 prefetches data. The data prefetch instructions are [13]: - + LDWPrefetch cache line for read. LDDPrefetch cache line for write. @@ -652,7 +652,7 @@ The PowerPC provides the following data prefetch instructions [14]: - + dcbt Data Cache Block Touch @@ -685,7 +685,7 @@ [15] instructions, whose variants are specified by the fcn field: - + 0 prefetch for several reads
[Patch, Fortran] PR 86830: [8/9 Regression] Contiguous array pointer function result not recognized as contiguous
Hi all,
the attached patch fixes a rejects-valid regression, where a
type-bound procedure call was not correctly detected to have a
contiguous result. The patch is functionally identical with comment #2
in the PR, with a little bit of cleanup on top of it. It regtests
cleanly on x86_64-linux-gnu. Ok for trunk and gcc-8-branch?
Cheers,
Janus
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index 7cfb94ee115..7e2d6445237 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,3 +1,9 @@
+2018-09-09 Janus Weil
+
+ PR fortran/86830
+ * expr.c (gfc_is_simply_contiguous): Handle type-bound procedure calls
+ with non-polymorphic objects.
+
2018-09-03 Jerry DeLisle
* simplify.c (gfc_simplify_modulo): Re-arrange code to test whether
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index c5bf822cd24..97792fe32a7 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -5385,16 +5385,13 @@ gfc_is_simply_contiguous (gfc_expr *expr, bool strict, bool permit_element)
return expr->value.function.esym->result->attr.contiguous;
else
{
- /* We have to jump through some hoops if this is a vtab entry. */
- gfc_symbol *s;
- gfc_ref *r, *rc;
-
- s = expr->symtree->n.sym;
- if (s->ts.type != BT_CLASS)
+ /* Type-bound procedures. */
+ gfc_symbol *s = expr->symtree->n.sym;
+ if (s->ts.type != BT_CLASS && s->ts.type != BT_DERIVED)
return false;
- rc = NULL;
- for (r = expr->ref; r; r = r->next)
+ gfc_ref *rc = NULL;
+ for (gfc_ref *r = expr->ref; r; r = r->next)
if (r->type == REF_COMPONENT)
rc = r;
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 0c038441a8c..9e1ab44144f 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2018-09-09 Janus Weil
+
+ PR fortran/86830
+ * gfortran.dg/typebound_call_30.f90: New test case.
+
2018-09-08 Marek Polacek
PR c++/87150 - wrong ctor with maybe-rvalue semantics.
diff --git a/gcc/testsuite/gfortran.dg/typebound_call_30.f90 b/gcc/testsuite/gfortran.dg/typebound_call_30.f90
new file mode 100644
index 000..3ca63bd2a95
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/typebound_call_30.f90
@@ -0,0 +1,32 @@
+! { dg-do compile }
+!
+! PR 86830: [8/9 Regression] Contiguous array pointer function result not recognized as contiguous
+!
+! Contributed by
+
+module m
+ implicit none
+
+ type :: t1
+ contains
+ procedure :: get_ptr
+ end type
+
+ type :: t2
+ class(t1), allocatable :: c
+ end type
+
+contains
+
+ function get_ptr(this)
+class(t1) :: this
+real, dimension(:), contiguous, pointer :: get_ptr
+ end function
+
+ subroutine test()
+real, dimension(:), contiguous, pointer:: ptr
+type(t2) :: x
+ptr => x%c%get_ptr()
+ end subroutine
+
+end module
[wwwdocs] testing/index.html -- move to full use of CSS
Committed. (Also removes an unnecessary and makes source formatting a bit clearer.) Committed. Gerald Index: testing/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/testing/index.html,v retrieving revision 1.41 diff -u -r1.41 index.html --- testing/index.html 2 Sep 2018 11:18:24 - 1.41 +++ testing/index.html 9 Sep 2018 20:36:26 - @@ -72,8 +72,7 @@ are incomplete for your target, update them. Additions to this list (accompanied with build and test guides) are welcome. - - + Name Language Build and test guide @@ -102,7 +101,8 @@ C++ testing-qt - + + If the operating system kernel you use is normally compiled with GCC, try building it with the current sources. Make sure it boots.
Re: Prune TYPE_NEXT_VARIANT lists in free_lang_data
> On September 8, 2018 10:49:02 AM GMT+01:00, Jan Hubicka
> wrote:
> >Hi
> >while working on path to replace type variant by first compatible one I
> >run
> >into issue that the first vairant was not seen by free_lang_data. I
> >think this
> >is a bug becuase nothing prevents middle-end from looking up a variant
> >there
> >and using it when it needs to do so.
> >
> >I tried to walk the variant lists and free lang data on them but that
> >crahses
> >because not all types in variant list passes verify_type (C++ puts
> >there
> >incomplete type variants whose canonical type is complete and thus they
> >are
> >considered bogus). So pruning those lists seems to be better variant.
> >
> >Bootstrapped/regtested x86_64-linux, OK?
>
> But if they are still reachable by GC they are now bogously unlinked. We
> already do not stream unused variants, so what does this achieve? Maybe we
> should make the variant list GCable somehow?
Main goal is to prevent middle end to walk the TYPE_NEXT_VARIANT list (for
example by get_qualified_variant)
and pick up a variant that was not seen by free_lang_data and put it into the
IL.
I know that if we end up referring to some type variant in a way not seen
by free lang data then the type won't be reachable from the list, but why that
would be a problem?
Honza
>
> >Honza
> >
> > * tree.c (free_lang_data_in_cgraph): Prune TYPE_NEXT_VARIANT lists.
> >Index: tree.c
> >===
> >--- tree.c (revision 263989)
> >+++ tree.c (working copy)
> >@@ -5845,7 +5845,12 @@ free_lang_data_in_cgraph (void)
> >
> > /* Traverse every type found freeing its language data. */
> > FOR_EACH_VEC_ELT (fld.types, i, t)
> >-free_lang_data_in_type (t);
> >+{
> >+ free_lang_data_in_type (t);
> >+ while (TYPE_NEXT_VARIANT (t)
> >+ && !fld.pset.contains (TYPE_NEXT_VARIANT (t)))
> >+TYPE_NEXT_VARIANT (t) = TYPE_NEXT_VARIANT (TYPE_NEXT_VARIANT (t));
> >+}
> > if (flag_checking)
> > {
> > FOR_EACH_VEC_ELT (fld.types, i, t)
>
[wwwdocs] Completely switch navigation bar to CSS
Introduce a new CSS class "middle". Use that for the icons in the
navigation bar instead of align="middle" (except one case where it
is not necessary at all).
Applied, and I also regenerated the pages on gcc.gnu.org.
As a side note, this actually looks better now!
Gerald
Index: gcc.css
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v
retrieving revision 1.66
diff -u -r1.66 gcc.css
--- gcc.css 9 Sep 2018 20:14:10 - 1.66
+++ gcc.css 9 Sep 2018 21:16:35 -
@@ -19,6 +19,7 @@
.right{ text-align:right; }
.center { text-align:center; margin-left:auto; margin-right:auto; }
.top { vertical-align:top; }
+.middle { vertical-align:middle; }
.width33 { width:33%; }
.border0 { border-width:0; }
Index: style.mhtml
===
RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v
retrieving revision 1.154
diff -u -r1.154 style.mhtml
--- style.mhtml 9 Sep 2018 09:39:18 - 1.154
+++ style.mhtml 9 Sep 2018 21:16:35 -
@@ -97,19 +97,19 @@
https://twitter.com/gnutools";>
@gnutools
https://plus.google.com/108467477471815191158";>
gnutools
https://my.fsf.org/civicrm/contribute/transact?reset=1&id=57";>
[wwwdocs] Avoid empty headings in gcc-5/changes.html
Not sure why those were added (probably out of unawareness of the option to put an id on a list), but it doesn't make sense; fixed thusly. Gerald Index: gcc-5/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.153 diff -u -r1.153 changes.html --- gcc-5/changes.html 1 Sep 2018 23:42:06 - 1.153 +++ gcc-5/changes.html 9 Sep 2018 21:24:03 - @@ -972,14 +972,12 @@ Other significant improvements - - + The gcc-ar, gcc-nm, gcc-ranlib wrappers now understand a -B option to set the compiler to use. - - + When the new command-line option -freport-bug is used, GCC automatically generates a developer-friendly reproducer whenever an internal compiler error is encountered.
[wwwdocs] Add a few missing s to egcs-1.1/regress.html
Not strictly speaking an HTML 5 compliance issue, but the validator issued warnings, so I had to look into it and went ahead and addressed it. Applied. Gerald Index: egcs-1.1/regress.html === RCS file: /cvs/gcc/wwwdocs/htdocs/egcs-1.1/regress.html,v retrieving revision 1.11 diff -u -r1.11 regress.html --- egcs-1.1/regress.html 1 Sep 2018 23:42:02 - 1.11 +++ egcs-1.1/regress.html 9 Sep 2018 21:54:25 - @@ -149,6 +149,7 @@ OK + i386-pc-freebsd2.1.6 @@ -165,6 +166,7 @@ NONE + @@ -288,6 +290,7 @@ Otherwise OK + m68k-sun-sunos4.1 @@ -304,7 +307,9 @@ NONE + + mips-sgi-irix5.2 @@ -321,7 +326,9 @@ NONE + + mips-sgi-irix5.3 @@ -409,6 +416,7 @@ Otherwise OK + powerpc-ibm-linux-gnu @@ -423,7 +431,9 @@ + + sparc-sun-solaris2.5 @@ -484,6 +494,7 @@ OK + sparc-sun-linux-gnu @@ -500,6 +511,7 @@ NONE +
[C++ PATCH] PR c++/87093
Tested manually on Linux-x64, running full suite on Linux-PPC64. This
seems half-obvious. OK for trunk? Backports?
2018-09-10 Ville Voutilainen
gcc/cp
PR c++/87093
* method.c (constructible_expr): We're in an unevaluated context
in all cases, not just for class targets.
testsuite/
PR c++/87093
* g++.dg/ext/is_constructible2.C: New.
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index 0b208a8..d75dacb 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1144,11 +1144,11 @@ static tree
constructible_expr (tree to, tree from)
{
tree expr;
+ cp_unevaluated cp_uneval_guard;
if (CLASS_TYPE_P (to))
{
tree ctype = to;
vec *args = NULL;
- cp_unevaluated cp_uneval_guard;
if (!TYPE_REF_P (to))
to = cp_build_reference_type (to, /*rval*/false);
tree ob = build_stub_object (to);
diff --git a/gcc/testsuite/g++.dg/ext/is_constructible2.C b/gcc/testsuite/g++.dg/ext/is_constructible2.C
new file mode 100644
index 000..8f25e7e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/is_constructible2.C
@@ -0,0 +1,12 @@
+// { dg-do compile { target c++11 } }
+
+#include
+
+template struct x {
+ operator bool() {
+static_assert(!std::is_same::value, "");
+return false;
+ }
+};
+
+static constexpr auto a = __is_constructible(bool, x);
Re: [C++ PATCH] PR c++/87093
OK for trunk and branches. On Sun, Sep 9, 2018 at 11:02 PM, Ville Voutilainen wrote: > Tested manually on Linux-x64, running full suite on Linux-PPC64. This > seems half-obvious. OK for trunk? Backports? > > 2018-09-10 Ville Voutilainen > > gcc/cp > > PR c++/87093 > * method.c (constructible_expr): We're in an unevaluated context > in all cases, not just for class targets. > > testsuite/ > > PR c++/87093 > * g++.dg/ext/is_constructible2.C: New.
C++ PATCH to tidy up build_vtbl_ref
The wrapper for build_vtbl_ref_1 doesn't seem to do anything useful.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2018-09-09 Marek Polacek
* class.c (build_vtbl_ref): Remove.
(build_vtbl_ref_1): Rename to build_vtbl_ref.
(build_vfn_ref): Call build_vtbl_ref instead of build_vtbl_ref_1.
diff --git gcc/cp/class.c gcc/cp/class.c
index e11173d2e59..e950a7423f7 100644
--- gcc/cp/class.c
+++ gcc/cp/class.c
@@ -133,7 +133,6 @@ static void maybe_warn_about_overly_private_class (tree);
static void add_implicitly_declared_members (tree, tree*, int, int);
static tree fixed_type_or_null (tree, int *, int *);
static tree build_simple_base_path (tree expr, tree binfo);
-static tree build_vtbl_ref_1 (tree, tree);
static void build_vtbl_initializer (tree, tree, tree, tree, int *,
vec **);
static bool check_bitfield_decl (tree);
@@ -699,8 +698,8 @@ build_vfield_ref (tree datum, tree type)
cases for INSTANCE which we take care of here, mainly to avoid
creating extra tree nodes when we don't have to. */
-static tree
-build_vtbl_ref_1 (tree instance, tree idx)
+tree
+build_vtbl_ref (tree instance, tree idx)
{
tree aref;
tree vtbl = NULL_TREE;
@@ -730,14 +729,6 @@ build_vtbl_ref_1 (tree instance, tree idx)
return aref;
}
-tree
-build_vtbl_ref (tree instance, tree idx)
-{
- tree aref = build_vtbl_ref_1 (instance, idx);
-
- return aref;
-}
-
/* Given a stable object pointer INSTANCE_PTR, return an expression which
yields a function pointer corresponding to vtable element INDEX. */
@@ -746,8 +737,7 @@ build_vfn_ref (tree instance_ptr, tree idx)
{
tree aref;
- aref = build_vtbl_ref_1 (cp_build_fold_indirect_ref (instance_ptr),
- idx);
+ aref = build_vtbl_ref (cp_build_fold_indirect_ref (instance_ptr), idx);
/* When using function descriptors, the address of the
vtable entry is treated as a function pointer. */
[PATCH, OpenACC] C++ reference mapping (PR middle-end/86336)
This patch (by Cesar) changes the way C++ references are mapped in
OpenACC regions, fixing an ICE in the non-scalar-data.C testcase.
Post-patch, references are mapped like this (from the omplower dump):
map(force_present:*x [len: 4]) map(firstprivate ref:x [pointer assign, bias: 0])
Tested with offloading to NVPTX and bootstrapped. OK for trunk?
Thanks,
Julian
ChangeLog
2018-09-09 Cesar Philippidis
Julian Brown
PR middle-end/86336
gcc/cp/
* semantics.c (finish_omp_clauses): Map C++ references by value and
FIRSTPRIVATE_REFERENCE.
* gimplify.c (gimplify_scan_omp_clauses): Remove FIRSTPRIVATE_REFERENCE
mappings in OpenACC data regions.
(gimplify_adjust_omp_clauses_1): Update handling of mapping of C++
references.
libgomp/
* testsuite/libgomp.oacc-c++/non-scalar-data.C: Remove XFAIL.
commit fed5f1044b3d7add83065b3bbe2ba2a95a1e95ce
Author: Julian Brown
Date: Thu Sep 6 15:32:50 2018 -0700
[OpenACC] C++ reference mapping
2018-09-09 Cesar Philippidis
Julian Brown
gcc/cp/
* semantics.c (finish_omp_clauses): Map C++ references by value and
FIRSTPRIVATE_REFERENCE.
* gimplify.c (gimplify_scan_omp_clauses): Remove FIRSTPRIVATE_REFERENCE
mappings in OpenACC data regions.
(gimplify_adjust_omp_clauses_1): Update handling of mapping of C++
references.
libgomp/
* testsuite/libgomp.oacc-c++/non-scalar-data.C: Remove XFAIL.
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 676de01..707f054 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -6877,7 +6877,8 @@ finish_omp_clauses (tree clauses, enum c_omp_region_type ort)
handle_map_references:
if (!remove
&& !processing_template_decl
- && (ort & C_ORT_OMP_DECLARE_SIMD) == C_ORT_OMP
+ && ((ort & C_ORT_OMP_DECLARE_SIMD) == C_ORT_OMP
+ || ort == C_ORT_ACC)
&& TYPE_REF_P (TREE_TYPE (OMP_CLAUSE_DECL (c
{
t = OMP_CLAUSE_DECL (c);
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index dbd0f0e..4011cb2 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -8556,7 +8556,8 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq *pre_p,
if (code == OACC_DATA
&& OMP_CLAUSE_CODE (c) == OMP_CLAUSE_MAP
- && OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_FIRSTPRIVATE_POINTER)
+ && (OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_FIRSTPRIVATE_POINTER
+ || OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_FIRSTPRIVATE_REFERENCE))
remove = true;
if (remove)
*list_p = OMP_CLAUSE_CHAIN (c);
@@ -8872,7 +8873,9 @@ gimplify_adjust_omp_clauses_1 (splay_tree_node n, void *data)
OMP_CLAUSE_CHAIN (nc) = OMP_CLAUSE_CHAIN (clause);
OMP_CLAUSE_CHAIN (clause) = nc;
}
- else if (gimplify_omp_ctxp->target_firstprivatize_array_bases
+ else if gimplify_omp_ctxp->region_type & ORT_ACC)
+ && lang_GNU_CXX ())
+ || gimplify_omp_ctxp->target_firstprivatize_array_bases)
&& lang_hooks.decls.omp_privatize_by_reference (decl))
{
OMP_CLAUSE_DECL (clause) = build_simple_mem_ref (decl);
diff --git a/libgomp/testsuite/libgomp.oacc-c++/non-scalar-data.C b/libgomp/testsuite/libgomp.oacc-c++/non-scalar-data.C
index 8e4b296..e5f8707 100644
--- a/libgomp/testsuite/libgomp.oacc-c++/non-scalar-data.C
+++ b/libgomp/testsuite/libgomp.oacc-c++/non-scalar-data.C
@@ -1,8 +1,7 @@
// Ensure that a non-scalar dummy arguments which are implicitly used inside
// offloaded regions are properly mapped using present_or_copy semantics.
-// { dg-xfail-if "TODO" { *-*-* } }
-// { dg-excess-errors "ICE" }
+// { dg-do run }
#include
Re: [Patch, Fortran] PR 86830: [8/9 Regression] Contiguous array pointer function result not recognized as contiguous
Hi Janus, That's fine - OK for both branches. Thanks Paul On 9 September 2018 at 21:34, Janus Weil wrote: > Hi all, > > the attached patch fixes a rejects-valid regression, where a > type-bound procedure call was not correctly detected to have a > contiguous result. The patch is functionally identical with comment #2 > in the PR, with a little bit of cleanup on top of it. It regtests > cleanly on x86_64-linux-gnu. Ok for trunk and gcc-8-branch? > > Cheers, > Janus -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [Patch, Fortran, F03] PR 85395: private clause contained in derived type acquires spurious scope
Hi Janus, That's OK for trunk and, I would suggest 8-branch. Thanks for the patch. Paul On 9 September 2018 at 17:31, Janus Weil wrote: > Hi all, > > the attached patch fixes a problem with the accessibility of procedure > pointer components (private/public attribute). It is rather > straightforward and regtest cleanly on x86_64-linux-gnu (for further > details see the PR). Ok for trunk? > > Cheers, > Janus -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
