[wwwdocs] search.html -- replace usage of
Replace the usage of (in favor of CSS and two design changes). This makes this page validate as HTML 5 with a few unrelated warnings around table cells. Committed. Gerald Index: search.html === RCS file: /cvs/gcc/wwwdocs/htdocs/search.html,v retrieving revision 1.196 diff -u -r1.196 search.html --- search.html 2 Sep 2018 20:43:09 - 1.196 +++ search.html 16 Sep 2018 08:25:03 - @@ -10,7 +10,6 @@ GCC detailed search https://gcc.gnu.org/cgi-bin/htsearch";> - Match: Boolean expression All words @@ -33,7 +32,7 @@ Title Z-A Search-syntax - + @@ -75,9 +74,7 @@ -Web page areas: - - +Web page areas: "Main" GCC @@ -85,37 +82,36 @@ Documentation - - + Mailing lists, including those for the old egcs project. Ticking a box is like marking all dates for that list: - + - gcc + gcc - ...-bugs + ...-bugs - ...-patches + ...-patches - ...-help + ...-help - ...-cvs + ...-cvs - ...-testresults + ...-testresults @@ -1209,23 +1205,23 @@ - ...-regression + ...-regression - ...-prs + ...-prs - ...-announce + ...-announce - ...-cvs-wwwdocs + ...-cvs-wwwdocs - fortran + fortran @@ -1606,15 +1602,15 @@ - libstdc++ + libstdc++ - ...-cvs + ...-cvs - ...-prs + ...-prs @@ -1901,19 +1897,19 @@ - java + java - ...-patches + ...-patches - ...-prs + ...-prs - ...-announce + ...-announce
Re: [PATCH] Fix extra parens in config/tls.m4
ping. I can provide a less scary patch to correct the typo if people are afraid of the cleanup changes.
Re: bootstrap -O3 failure libgo on x64_86
Ian A simple bootstrap using gcc 8 as host compiler works with default configuration all langs+ada. Now trying using gcc 9 host from a week ago Will tty elimate which configue opts cause problem Graham Original message From: Ian Lance Taylor via gcc-patches Date: 15/09/2018 16:01 (GMT+00:00) To: graham stott Cc: gcc-patches Subject: Re: bootstrap -O3 failure libgo on x64_86 On Sat, Sep 15, 2018 at 7:12 AM, graham stott via gcc-patches wrote: > Hi > Fails due to undefind symbols runtime.* > O2 works I tried my best guess at recreating the problem, and everything worked fine. Please tell us exactly what you did and exactly what happened. Thanks. Ian
Re: [PATCH] Fix extra parens in config/tls.m4
On Sep 03 2018, co...@sdf.org wrote: > config/tls.m4: Remove extra parentheses There are no extra parentheses. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
[libgcc] Use v2 map syntax in libgcc-unwind.map if Solaris ld supports it
Currently, the libgcc-unwind.map file generated for use with Solaris ld
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01088.html
uses the v1 linker map file syntax because both that's supported
everywhere. However, with ld -z guidance, newer versions of ld warn
about this:
ld: guidance: version 2 mapfile syntax recommended: ./libgcc-unwind.map
Since it is easy to detect if ld supports v2 map syntax (introduced in
Solaris 11 and later backported to some Solaris 10 patches) and the
mapfile is generated at build time, the following patch performs this
check and generates a v2 mapfile if ld supports it.
While testing the patch, I found that the arg to AC_TRY_COMMAND needed
quoting to avoid the embedded commas in -Wl,-M,... ended the command.
Shouldn't the other uses of AC_TRY_COMMAND receive the same quoting for
safety and consistency?
Bootstrapped on i386-pc-solaris2.10 (with older v1-only ld) and
i386-pc-solaris2.11 without regressions.
Ok for mainline?
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
2018-09-14 Rainer Orth
* configure.ac (solaris_ld_v2_maps): New test.
* configure: Regenerate.
* Makefile.in (solaris_ld_v2_maps): New variable.
* config/t-slibgcc-sld (libgcc-unwind.map): Emit v2 mapfile syntax
if supported.
# HG changeset patch
# Parent 6e22c7ec2252ccb001d91cccbacc5378de003e7c
Use v2 map syntax in libgcc-unwind.map if Solaris ld supports it
diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -44,6 +44,7 @@ enable_vtable_verify = @enable_vtable_ve
enable_decimal_float = @enable_decimal_float@
fixed_point = @fixed_point@
with_aix_soname = @with_aix_soname@
+solaris_ld_v2_maps = @solaris_ld_v2_maps@
enable_execute_stack = @enable_execute_stack@
unwind_header = @unwind_header@
md_unwind_header = @md_unwind_header@
diff --git a/libgcc/config/t-slibgcc-sld b/libgcc/config/t-slibgcc-sld
--- a/libgcc/config/t-slibgcc-sld
+++ b/libgcc/config/t-slibgcc-sld
@@ -8,12 +8,23 @@ ifeq ($(enable_shared),yes)
# Linker mapfile to enforce direct binding to libgcc_s unwinder
# (PR target/59788).
+# Emit v2 mapfile syntax if possible, otherwise ld -z guidance complains
+# every time the mapfile is used.
libgcc-unwind.map: libgcc-std.ver
+ifeq ($(solaris_ld_v2_maps),yes)
+ @(echo '$$mapfile_version 2'; \
+ echo "SYMBOL_SCOPE {"; \
+ for f in `grep _Unwind_ $< | sort`; do \
+ echo " $$f { FLAGS = EXTERN DIRECT };"; \
+ done; \
+ echo "};" ) > $@
+else
@(echo "{";\
for f in `grep _Unwind_ $< | sort`; do \
echo " $$f = EXTERN DIRECT;"; \
done; \
echo "};" ) > $@
+endif
# Copy libgcc-unwind.map to the place where gcc will look for it at build-time.
install-libgcc-unwind-map-forbuild: libgcc-unwind.map
diff --git a/libgcc/configure.ac b/libgcc/configure.ac
--- a/libgcc/configure.ac
+++ b/libgcc/configure.ac
@@ -459,6 +459,21 @@ EOF
;;
esac
+# Check if Solaris linker support v2 linker mapfile syntax.
+# Link with -nostartfiles -nodefaultlibs since neither are present while
+# building libgcc.
+case ${host} in
+*-*-solaris2*)
+ solaris_ld_v2_maps=no
+ echo 'int main(void) {return 0;}' > conftest.c
+ echo '$mapfile_version 2' > conftest.map
+ if AC_TRY_COMMAND([${CC-cc} -nostartfiles -nodefaultlibs -Wl,-M,conftest.map -o conftest conftest.c 1>&AS_MESSAGE_LOG_FD]); then
+ solaris_ld_v2_maps=yes
+ fi
+ ;;
+esac
+AC_SUBST(solaris_ld_v2_maps)
+
# Check if xtensa target is configured for windowed ABI and thus needs to use
# custom unwind code.
# This is after config.host so we can augment tmake_file.
Re: [PATCH] Fix extra parens in config/tls.m4
On Sun, Sep 16, 2018 at 01:00:21PM +0200, Andreas Schwab wrote:
> On Sep 03 2018, co...@sdf.org wrote:
>
> > config/tls.m4: Remove extra parentheses
>
> There are no extra parentheses.
>
For the benefit of the discussion, I've added the more minimal version
of the patch.
This is a weird configure test because of the parens. It's not wrong
because its wrongness is compensated for later. So maybe it's a matter
of opinion.
But probably this is the intended generated autoconf output.
diff --git a/config/tls.m4 b/config/tls.m4
index 4e170c8d6ae..b9b363d8a80 100644
--- a/config/tls.m4
+++ b/config/tls.m4
@@ -104,7 +104,7 @@ AC_DEFUN([GCC_CHECK_CC_TLS], [
gcc_cv_have_cc_tls, [
AC_COMPILE_IFELSE([__thread int a; int b; int main() { return a = b; }],
[gcc_cv_have_cc_tls=yes], [gcc_cv_have_cc_tls=no])]
-)])
+)
if test "$enable_tls $gcc_cv_have_cc_tls" = "yes yes"; then
AC_DEFINE(HAVE_CC_TLS, 1,
[Define to 1 if the target assembler supports thread-local
storage.])
diff --git a/libgcc/configure b/libgcc/configure
index 79068536175..8ccb700da0f 100644
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -5304,6 +5304,11 @@ rm -f core conftest.err conftest.$ac_objext
conftest.$ac_ext
fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_have_cc_tls" >&5
$as_echo "$gcc_cv_have_cc_tls" >&6; }
+ if test "$enable_tls $gcc_cv_have_cc_tls" = "yes yes"; then
+
+$as_echo "#define HAVE_CC_TLS 1" >>confdefs.h
+
+ fi
set_have_cc_tls=
if test "$enable_tls $gcc_cv_have_cc_tls" = "yes yes"; then
set_have_cc_tls="-DHAVE_CC_TLS"
[Patch, fortran] PR85954 - [8/9 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:266
I spent far more time on this PR because I was focusing on entirely
the wrong place in the code. Or, rather the clue that was needed for
the fix was elswhere. The type declarations for the deferred character
length dummies were not being generated. Rather than being a problem
in the associate block, as I thought initially, it turned out to be
the cast in print *, allocated(x),. that was throwing the
gimplifier in its attempt to inline the subroutine. The fix is clear
from the ChangeLog.
It did turn out that there was something wrong with the associate
block: The associate name was ending up with no charlen and so winding
up with a descriptor appropriate to a bind(C) function result.
Bootstraps and regtests on FC28/x86_64 - OK for trunk and 8-branch?
Paul
2018-09-16 Paul Thomas
PR fortran/85954
* resolve.c (resolve_assoc_var): If the target expression is a
deferred charlen dummy and the associate name shares the
charlen, generate a new one. Make sure that new charlens are in
the namespace list so that they get cleaned up.
* trans-array.c (gfc_is_reallocatable_lhs): Associate names are
not reallocatable.
* trans-decl.c (gfc_get_symbol_decl): Put deferred character
length dummy and result arrays on the deferred initialization
list so that the variable length arrays can be correctly dealt
with.
* trans-expr.c (gfc_conv_string_length): Return if 'expr' is
NULL rather than ICEing..
2018-09-16 Paul Thomas
PR fortran/85954
* gfortran.dg/deferred_character_21.f90 : New test.
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (revision 264288)
--- gcc/fortran/resolve.c (working copy)
*** resolve_assoc_var (gfc_symbol* sym, bool
*** 8744,8749
--- 8744,8757
if (!sym->ts.u.cl)
sym->ts.u.cl = target->ts.u.cl;
+ if (sym->ts.deferred && target->expr_type == EXPR_VARIABLE
+ && target->symtree->n.sym->attr.dummy
+ && sym->ts.u.cl == target->ts.u.cl)
+ {
+ sym->ts.u.cl = gfc_new_charlen (sym->ns, NULL);
+ sym->ts.deferred = 1;
+ }
+
if (!sym->ts.u.cl->length
&& !sym->ts.deferred
&& target->expr_type == EXPR_CONSTANT)
*** resolve_assoc_var (gfc_symbol* sym, bool
*** 8756,8762
|| sym->ts.u.cl->length->expr_type != EXPR_CONSTANT)
&& target->expr_type != EXPR_VARIABLE)
{
! sym->ts.u.cl = gfc_get_charlen();
sym->ts.deferred = 1;
/* This is reset in trans-stmt.c after the assignment
--- 8764,8770
|| sym->ts.u.cl->length->expr_type != EXPR_CONSTANT)
&& target->expr_type != EXPR_VARIABLE)
{
! sym->ts.u.cl = gfc_new_charlen (sym->ns, NULL);
sym->ts.deferred = 1;
/* This is reset in trans-stmt.c after the assignment
Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c (revision 264288)
--- gcc/fortran/trans-array.c (working copy)
*** gfc_is_reallocatable_lhs (gfc_expr *expr
*** 9520,9525
--- 9520,9528
sym = expr->symtree->n.sym;
+ if (sym->attr.associate_var)
+ return false;
+
/* An allocatable class variable with no reference. */
if (sym->ts.type == BT_CLASS
&& CLASS_DATA (sym)->attr.allocatable
Index: gcc/fortran/trans-decl.c
===
*** gcc/fortran/trans-decl.c (revision 264288)
--- gcc/fortran/trans-decl.c (working copy)
*** gfc_get_symbol_decl (gfc_symbol * sym)
*** 1510,1515
--- 1510,1522
/* Dummy variables should already have been created. */
gcc_assert (sym->backend_decl);
+ /* However, the string length of deferred arrays must be set. */
+ if (sym->ts.type == BT_CHARACTER
+ && sym->ts.deferred
+ && sym->attr.dimension
+ && sym->attr.allocatable)
+ gfc_defer_symbol_init (sym);
+
if (sym->attr.pointer && sym->attr.dimension && sym->ts.type != BT_CLASS)
GFC_DECL_PTR_ARRAY_P (sym->backend_decl) = 1;
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c (revision 264288)
--- gcc/fortran/trans-expr.c (working copy)
*** gfc_conv_string_length (gfc_charlen * cl
*** 2237,2243
if (!cl->length)
{
gfc_expr* expr_flat;
! gcc_assert (expr);
expr_flat = gfc_copy_expr (expr);
flatten_array_ctors_without_strlen (expr_flat);
gfc_resolve_expr (expr_flat);
--- 2237,2244
if (!cl->length)
{
gfc_expr* expr_flat;
! if (!expr)
! return;
expr_flat = gfc_copy_expr (expr);
flatten_array_ctors_without_strlen (expr_flat);
gfc_resolve_expr (expr_flat);
Index: gcc/testsuite/gfortran.dg/deferred_character_21.f90
===
*** gcc/testsuite/gfortran
Re: Fold more boolean expressions
Hi, I have bootstrapped and make check'd my final patch on latest trunk. Is it OK? Could you please push it if possible? The patch can be found here, but please update the commit message date: https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00803.html Test result: Native configuration is x86_64-pc-linux-gnu === gcc tests === Running target unix === gcc Summary === # of expected passes134514 # of expected failures 462 # of unsupported tests 2109 /home/usr/Desktop/gcc-build/gcc/xgcc version 9.0.0 20180916 (experimental) (GCC) === g++ tests === Running target unix FAIL: g++.dg/pr80481.C -std=gnu++98 scan-assembler-not vmovaps FAIL: g++.dg/pr80481.C -std=gnu++11 scan-assembler-not vmovaps FAIL: g++.dg/pr80481.C -std=gnu++14 scan-assembler-not vmovaps FAIL: g++.dg/pr83239.C -std=gnu++98 (test for excess errors) === g++ Summary === # of expected passes127011 # of unexpected failures4 # of expected failures 532 # of unsupported tests 5028 /home/usr/Desktop/gcc-build/gcc/xg++ version 9.0.0 20180916 (experimental) (GCC) === libatomic tests === Running target unix === libatomic Summary === # of expected passes54 === libgomp tests === Running target unix === libgomp Summary === # of expected passes2031 # of expected failures 1 # of unsupported tests 188 === libitm tests === Running target unix === libitm Summary === # of expected passes42 # of expected failures 3 # of unsupported tests 1 === libstdc++ tests === Running target unix === libstdc++ Summary === # of expected passes12667 # of expected failures 77 # of unsupported tests 589 Compiler version: 9.0.020180916(experimental)(GCC) Platform: x86_64-pc-linux-gnu configure flags: --enable-languages=c,c++ --prefix=/home/usr/Desktop/gcc-out --with-system-zlib --enable-checking=release --disable-multilib --with-abi=m64
[PATCH] Fix ms-sysv generator with gcc-4.8 host-g++
Hi,
this prevents test failures when gcc-4.8 is used as host-g++ tool, since this
version does
understand -std=c++11 but not -fno-diagnostics-show-line-numbers and
-fdiagnostics-color=never.
With slightly newer gcc tools like gcc-5 everything works fine.
Apparently the following commit added those options to TEST_ALWAYS_FLAGS.
2018-08-09 David Malcolm
PR other/84889
* gcc.dg/plugin/diagnostic-test-show-locus-bw-line-numbers.c: New
test.
* gcc.dg/plugin/diagnostic-test-show-locus-color-line-numbers.c:
New test.
* gcc.dg/plugin/plugin.exp (plugin_test_list): Add the new tests.
* lib/prune.exp: Add -fno-diagnostics-show-line-numbers to
TEST_ALWAYS_FLAGS.
Work around is not using TEST_ALWAYS_FLAGS in the host tool invocation.
Bootstrapped and reg-tested with gcc-4.8 and gcc-5 host tools.
Is it OK for trunk?
Thanks
Bernd.
2018-09-16 Bernd Edlinger
* gcc.target/x86_64/abi/ms-sysv/ms-sysv.exp: Don't pass
TEST_ALWAYS_FLAGS to HOSTCXX.
Index: gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.exp
===
--- gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.exp (revision 264342)
+++ gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.exp (working copy)
@@ -109,7 +109,7 @@
< [file mtime "$src"]) } {
# Temporarily switch to the environment for the host compiler.
restore_ld_library_path_env_vars
- set cxx "$HOSTCXX $HOSTCXXFLAGS $TEST_ALWAYS_FLAGS $warn_flags -std=c++11"
+ set cxx "$HOSTCXX $HOSTCXXFLAGS $warn_flags -std=c++11"
set status [remote_exec host "$cxx -o $generator $src"]
set status [lindex $status 0]
set_ld_library_path_env_vars
Re: [Patch, fortran] PR85954 - [8/9 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:266
Hi Paul, Bootstraps and regtests on FC28/x86_64 - OK for trunk and 8-branch? Ok. Thanks for the patch! Regards Thomas
Re: [patch, fortran] Unify / fix error messages for matmul
On Sun, Sep 16, 2018 at 6:55 PM Thomas Koenig wrote: > Hello world, > > looking through the code for run-time checking of matmul, I found that > a) the code was not very clear, and b) due to this, at least one case > was not checked correctly. > > So, here is a rewrite of that section. I have also made sure that > the error messages now agree between library and compiler-generated > error messages. The macros for error messages also contain the > _ magic, so I hope that translation will be easier. > > I may also have fixed other bugs in that section, I didn't check > very thoroughly. > > There was one suggestion in PR 37802. For code like > > c = matmul(a,b) > > where the boundaries of c were not correct, this is actually an error > in the assignment, so I have made the error message match what we emit > for normal array access out of bounds (like a(1:3) = b(1:2)). > > Regression-tested. OK for trunk? > Ok, thanks. -- Janne Blomqvist
[PATCH] Cleanup strcpy/stpcpy no nul warning code
Hi,
this is a cleanup of the recently added strlen/strcpy/stpcpy
no nul warning code.
Most importantly it moves the SSA_NAME handling from
unterminated_array to string_constant, thereby fixing
another round of xfails in the strlen and stpcpy test cases.
I need to say that the fix for bug 86622 is relying in
type info on the pointer which is probably not safe in
GIMPLE in the light of the recent discussion.
I had to add two further exceptions, which should
be safe in general: that is a pointer arithmentic on a string
literal is okay, and arithmetic on a string constant
that is exactly the size of the whole DECL, cannot
access an adjacent member.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
gcc:
2018-09-16 Bernd Edlinger
* builtins.h (unterminated_array): Remove prototype.
* builtins.c (unterminated_array): Simplify. Make static.
(expand_builtin_strcpy_args): Don't use TREE_NO_WARNING here.
(expand_builtin_stpcpy_1): Remove warn_string_no_nul without effect.
* expr.c (string_constant): Handle SSA_NAME. Add more exceptions
where pointer arithmetic is safe.
* gimple-fold.c (get_range_strlen): Handle nonstr like in c_strlen.
(get_max_strlen): Remove the unnecessary mynonstr handling.
(gimple_fold_builtin_strcpy): Simplify.
(gimple_fold_builtin_stpcpy): Simplify.
(gimple_fold_builtin_sprintf): Remove NO_WARNING propagation
without effect.
(gimple_fold_builtin_strlen): Simplify.
testsuite:
2018-09-16 Bernd Edlinger
* gcc.dg/warn-stpcpy-no-nul.c: Remove xfails.
* gcc.dg/warn-strlen-no-nul.c: Remove xfails.
Index: gcc/builtins.c
===
--- gcc/builtins.c (revision 264342)
+++ gcc/builtins.c (working copy)
@@ -567,31 +567,12 @@ warn_string_no_nul (location_t loc, const char *fn
the declaration of the object of which the array is a member or
element. Otherwise return null. */
-tree
+static tree
unterminated_array (tree exp)
{
- if (TREE_CODE (exp) == SSA_NAME)
-{
- gimple *stmt = SSA_NAME_DEF_STMT (exp);
- if (!is_gimple_assign (stmt))
- return NULL_TREE;
-
- tree rhs1 = gimple_assign_rhs1 (stmt);
- tree_code code = gimple_assign_rhs_code (stmt);
- if (code == ADDR_EXPR
- && TREE_CODE (TREE_OPERAND (rhs1, 0)) == ARRAY_REF)
- rhs1 = rhs1;
- else if (code != POINTER_PLUS_EXPR)
- return NULL_TREE;
-
- exp = rhs1;
-}
-
tree nonstr = NULL;
- if (c_strlen (exp, 1, &nonstr, 1) == NULL && nonstr)
-return nonstr;
-
- return NULL_TREE;
+ c_strlen (exp, 1, &nonstr);
+ return nonstr;
}
/* Compute the length of a null-terminated character string or wide
@@ -3936,8 +3917,7 @@ expand_builtin_strcpy_args (tree exp, tree dest, t
if (tree nonstr = unterminated_array (src))
{
/* NONSTR refers to the non-nul terminated constant array. */
- if (!TREE_NO_WARNING (exp))
- warn_string_no_nul (EXPR_LOCATION (exp), "strcpy", src, nonstr);
+ warn_string_no_nul (EXPR_LOCATION (exp), "strcpy", src, nonstr);
return NULL_RTX;
}
@@ -3984,14 +3964,10 @@ expand_builtin_stpcpy_1 (tree exp, rtx target, mac
compile-time, not an expression containing a string. This is
because the latter will potentially produce pessimized code
when used to produce the return value. */
- tree nonstr = NULL_TREE;
if (!c_getstr (src, NULL)
- || !(len = c_strlen (src, 0, &nonstr, 1)))
+ || !(len = c_strlen (src, 0)))
return expand_movstr (dst, src, target, /*endp=*/2);
- if (nonstr && !TREE_NO_WARNING (exp))
- warn_string_no_nul (EXPR_LOCATION (exp), "stpcpy", src, nonstr);
-
lenp1 = size_binop_loc (loc, PLUS_EXPR, len, ssize_int (1));
ret = expand_builtin_mempcpy_args (dst, src, lenp1,
target, exp, /*endp=*/2);
Index: gcc/builtins.h
===
--- gcc/builtins.h (revision 264342)
+++ gcc/builtins.h (working copy)
@@ -104,7 +104,6 @@ extern internal_fn associated_internal_fn (tree);
extern internal_fn replacement_internal_fn (gcall *);
extern void warn_string_no_nul (location_t, const char *, tree, tree);
-extern tree unterminated_array (tree);
extern tree max_object_size ();
#endif /* GCC_BUILTINS_H */
Index: gcc/expr.c
===
--- gcc/expr.c (revision 264342)
+++ gcc/expr.c (working copy)
@@ -11372,7 +11372,10 @@ string_constant (tree arg, tree *ptr_offset, tree
/* Avoid pointers to arrays (see bug 86622). */
if (POINTER_TYPE_P (TREE_TYPE (arg))
&& TREE_CODE (TREE_TYPE (TREE_TYPE (arg))) == ARRAY_TYPE
- && TREE_CODE (TREE_OPERAND (arg0, 0)) == ARRAY_REF)
+ && !(decl && !*decl)
+ && !(decl && tree_fits_uhwi_p (DECL_SIZE_UNIT (*decl))
+ && mem_size && tree_fits_uhwi_p (*mem_size)
+ && tree_int_cst_equal (*mem_size, DECL_SIZE_UNIT (*decl
return NULL_TREE;
tree type = TREE_TYPE (
[Patch, Fortran, committed] PR 86484 & 84543
Hi all, I have just committed as obvious a small patch that fixes two very related PRs concerning polymorphic assignments, by making sure that the relevant vtabs (including copy procedures) are generated: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=264350 Cheers, Janus
[wwwdocs] search.html -- complete missing/empty table cells
Committed. Gerald Index: search.html === RCS file: /cvs/gcc/wwwdocs/htdocs/search.html,v retrieving revision 1.197 retrieving revision 1.199 diff -u -r1.197 -r1.199 --- search.html 16 Sep 2018 08:26:36 - 1.197 +++ search.html 16 Sep 2018 08:59:01 - 1.199 @@ -1223,7 +1223,9 @@ fortran + + @@ -1597,6 +1599,7 @@ Nov 2003 Oct 2003 + @@ -1612,7 +1615,11 @@ ...-prs + + + + @@ -1892,6 +1899,9 @@ Oct-Dec 1999 Jul-Sep 1999 + + + @@ -1911,7 +1921,10 @@ ...-announce + + + @@ -2216,11 +2229,12 @@ 2000 1999 + + - - - + +
Committed, PR target/85666
I've back-ported these two patches to the gcc-8-branch to restore buildability. Tested at r264184, committed r264351. PR target/85666 * config/mmix/mmix.c (mmix_assemble_integer): Handle byte-size non-CONST_INT rtx:es using assemble_integer_with_op ".byte". (MMIX_CFUN_NEEDS_SAVED_EH_RETURN_ADDRESS): Don't call leaf_function_p, instead use has_hard_reg_initial_val. brgds, H-P
