Re: [C++ Patch] PR 84636 ("internal compiler error: Segmentation fault (identifier_p()/grokdeclarator())")
On 11/21/18 7:03 PM, Paolo Carlini wrote:
... in fact I'm thinking that the below - which directly checks for
unqualified_id to be non-null in both places - may be a better variant:
among other things it means that for related testcases like:
typedef void a();
struct A
{ a a1: 1; };
we get the location of a1 right (we could also change the diagnostics in
grokbitfield to use DECL_SOURCE_LOCATION and exploit it), and the
testsuite doesn't need adjustments. Tested x86_64-linux.
- else if (TREE_CODE (type) == FUNCTION_TYPE
-|| TREE_CODE (type) == METHOD_TYPE)
+ else if (FUNC_OR_METHOD_TYPE_P (type) && unqualified_id)
Maybe change this to
else if (funcdecl_p)
?
OK either way.
Jason
Re: RFA/RFC: Add stack recursion limit to libiberty's demangler
> That section is "Writing Robust Programs." Robustness guarantees have > to be different for utilities and servers. A robust server doesn't > crash because of arbitrary user input, but there are servers that > demangle names that are provided by the user. So we need two modes for > the demangler: one that takes anything and sometimes crashes, for > utilities like c++filt, and one that doesn't crash, for servers. And it > seems like that is what Nick is suggesting. In order to handle arbitrary user input without crashing, perhaps the demangler should switch from recursive descent parsing to a state machine, where exhaustion of resources can be handled gracefully. -cary
Re: [C++ PATCH] Fix xvalue COND_EXPR handling (PR c++/88103)
On 11/29/18 4:52 PM, Jakub Jelinek wrote:
Hi!
On the following testcase, build_conditional_expr_1 tries hard to make sure
that if both arguments are xvalue_p (or one is and the other throw) the
result is still xvalue_p. But, later on we call unary_complex_lvalue,
which does rationalize_conditional_expr which changes it from
cond ? x : y to *(cond ? : ) and that change turns something formerly
xvalue_p into newly lvalue_p.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2018-11-29 Jakub Jelinek
PR c++/88103
* typeck.c (unary_complex_lvalue): If a COND_EXPR is xvalue_p, make
sure the result is as well.
* g++.dg/cpp0x/rv-cond3.C: New test.
--- gcc/cp/typeck.c.jj 2018-11-27 09:48:58.506103668 +0100
+++ gcc/cp/typeck.c 2018-11-29 21:00:33.900636750 +0100
@@ -6503,7 +6503,16 @@ unary_complex_lvalue (enum tree_code cod
/* Handle (a ? b : c) used as an "lvalue". */
if (TREE_CODE (arg) == COND_EXPR
|| TREE_CODE (arg) == MIN_EXPR || TREE_CODE (arg) == MAX_EXPR)
-return rationalize_conditional_expr (code, arg, tf_warning_or_error);
+{
+ tree ret = rationalize_conditional_expr (code, arg, tf_warning_or_error);
+ /* Preserve xvalue kind. */
+ if (xvalue_p (arg))
+ {
+ tree reftype = cp_build_reference_type (TREE_TYPE (arg), true);
+ ret = cp_convert (reftype, ret, tf_warning_or_error);
Is there a reason not to use the 'move' function here?
Jason
Re: [C++ PATCH] Fix C++ parser endless diagnostics on CPP_PRAGMA_EOL (PR c++/88258)
On 11/30/18 3:54 PM, Jakub Jelinek wrote: Hi! The following testcase endlessly diagnoses a syntax error. The problem is that the various C++ parser routines to skip tokens until something happily skip over CPP_PRAGMA that starts a pragma line, but always stop at CPP_PRAGMA_EOL, but the caller expect them to stop at something different. The fix is similar to what the C FE already does, treat CPP_PRAGMA_EOL as CPP_EOF only if in_pragma flag is set. Otherwise we didn't really parse CPP_PRAGMA normally and should skip everything until we find whatever we are looking for. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK. Jason
[committed] C++ PATCH to add test for c++/79629
Tested x86_64-linux, applying to trunk.
2018-12-01 Marek Polacek
PR c++/79629
* g++.dg/other/error35.C: New test.
diff --git gcc/testsuite/g++.dg/other/error35.C
gcc/testsuite/g++.dg/other/error35.C
new file mode 100644
index 000..e9c8371f18b
--- /dev/null
+++ gcc/testsuite/g++.dg/other/error35.C
@@ -0,0 +1,14 @@
+// PR c++/79629
+// { dg-do compile { target c++14 } }
+// { dg-options "-w" }
+
+template struct S {
+ enum E : int;
+ constexpr int g() const;
+};
+enum S::E;
+template enum S::E : int { b };
+template
+constexpr int S::g() const { b; } // { dg-error "not declared" }
+static_assert(S().g() == 1, ""); // { dg-error "" }
+// { dg-message "in .constexpr. expansion of" "" { target *-*-* } .-1 }
[committed] C++ PATCH to add test for c++/83856
Tested x86_64-linux, applying to trunk.
2018-12-01 Marek Polacek
PR c++/83856
* g++.dg/cpp1y/lambda-generic-83856.C: New test.
diff --git gcc/testsuite/g++.dg/cpp1y/lambda-generic-83856.C
gcc/testsuite/g++.dg/cpp1y/lambda-generic-83856.C
new file mode 100644
index 000..ab82b6241aa
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp1y/lambda-generic-83856.C
@@ -0,0 +1,30 @@
+// PR c++/83856
+// { dg-do compile { target c++14 } }
+
+namespace std {
+template _Tp declval();
+template class initializer_list {
+ _E *_M_len;
+
+public:
+ unsigned long size;
+ _E begin();
+};
+template struct array { void operator[](long); };
+} // namespace std
+
+template struct simd {
+ static int size();
+ template simd(F, decltype(std::declval()(0)) * = nullptr) {}
+};
+template
+void test_tuples(std::initializer_list> data,
+ F... fun_pack) {
+ auto it = data.begin();
+ const int remaining = V::size();
+ [](...) {}((fun_pack([&](auto) { it[remaining]; }), 0)...);
+}
+
+void f() {
+ test_tuples>({}, [](simd) {});
+}
[committed] C++ PATCH to add test for c++/87523
Tested x86_64-linux, applying to trunk.
2018-12-01 Marek Polacek
PR c++/87523
* g++.dg/cpp1y/lambda-generic-87523.C: New test.
diff --git gcc/testsuite/g++.dg/cpp1y/lambda-generic-87523.C
gcc/testsuite/g++.dg/cpp1y/lambda-generic-87523.C
new file mode 100644
index 000..ecba1cfc322
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp1y/lambda-generic-87523.C
@@ -0,0 +1,32 @@
+// PR c++/87523
+// { dg-do compile { target c++14 } }
+
+template
+struct my_integer_constant {
+constexpr my_integer_constant() {}
+constexpr operator T() const { return v; }
+constexpr T operator()() const { return v; }
+};
+
+template
+struct constant_call {
+template
+static void call(T v, Callback f) {
+char dummy[sizeof...(u)] = { ( (v == u) ? (f(my_integer_constant{}), static_cast(0)) : static_cast(0))... };
+(void)dummy;
+}
+};
+
+void f(bool reverse_in, bool other_bool_in) {
+auto helper = [&] (auto reverse_t) {
+bool constexpr reverse_v = reverse_t;
+(void)reverse_v;
+constant_call::call(other_bool_in,
+ [&] (auto newb) {
+ bool reverse_v_dyn =
reverse_v;
+ });
+};
+constant_call::call(reverse_in, [&] (auto reverse_t) {
+helper(reverse_t);
+});
+}
[PATCH, libphobos] Committed add support for riscv to glibc bindings
Hi,
This patch is backported from druntime master, which adds support for
riscv to the core D runtime library.
Tested on x86_64-linux-gnu targeting riscv64-linux-gnu, and ran
unittests under qemu.
Committed to trunk as r266713
--
Iain
commit b24441f388f2c75ba56ea2b00056dfd8c12b3456
Author: Iain Buclaw
Date: Sat Dec 1 22:29:31 2018 +0100
libphobos: Add support for RISCV to glibc bindings
Backported from upstream druntime master.
Reviewed-on: https://github.com/dlang/druntime/pull/2355
diff --git a/libphobos/libdruntime/core/stdc/fenv.d b/libphobos/libdruntime/core/stdc/fenv.d
index 3bcbd65009d..00b99af97a2 100644
--- a/libphobos/libdruntime/core/stdc/fenv.d
+++ b/libphobos/libdruntime/core/stdc/fenv.d
@@ -34,6 +34,8 @@ version (MIPS32) version = MIPS_Any;
version (MIPS64) version = MIPS_Any;
version (PPC) version = PPC_Any;
version (PPC64) version = PPC_Any;
+version (RISCV32) version = RISCV_Any;
+version (RISCV64) version = RISCV_Any;
version (S390)version = IBMZ_Any;
version (SPARC) version = SPARC_Any;
version (SPARC64) version = SPARC_Any;
@@ -128,6 +130,12 @@ version (GNUFP)
alias fenv_t = double;
alias fexcept_t = uint;
}
+// https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/riscv/bits/fenv.h
+else version (RISCV_Any)
+{
+alias fenv_t = uint;
+alias fexcept_t = uint;
+}
// https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/sparc/fpu/bits/fenv.h
else version (SPARC64)
{
@@ -573,6 +581,28 @@ else
FE_DOWNWARD = 3, ///
}
}
+else version (RISCV_Any)
+{
+// Define bits representing exceptions in the FPSR status word.
+enum
+{
+FE_INEXACT = 0x01, ///
+FE_UNDERFLOW= 0x02, ///
+FE_OVERFLOW = 0x04, ///
+FE_DIVBYZERO= 0x08, ///
+FE_INVALID = 0x10, ///
+FE_ALL_EXCEPT = 0x1f, ///
+}
+
+// Define bits representing rounding modes in the FPCR Rmode field.
+enum
+{
+FE_TONEAREST= 0x0, ///
+FE_TOWARDZERO = 0x1, ///
+FE_DOWNWARD = 0x2, ///
+FE_UPWARD = 0x3, ///
+}
+}
else version (SPARC_Any)
{
// Define bits representing the exception.
diff --git a/libphobos/libdruntime/core/stdc/math.d b/libphobos/libdruntime/core/stdc/math.d
index 8052ff7f344..b121f050747 100644
--- a/libphobos/libdruntime/core/stdc/math.d
+++ b/libphobos/libdruntime/core/stdc/math.d
@@ -30,6 +30,8 @@ version (MIPS32) version = MIPS_Any;
version (MIPS64) version = MIPS_Any;
version (PPC) version = PPC_Any;
version (PPC64) version = PPC_Any;
+version (RISCV32) version = RISCV_Any;
+version (RISCV64) version = RISCV_Any;
version (S390)version = IBMZ_Any;
version (SPARC) version = SPARC_Any;
version (SPARC64) version = SPARC_Any;
@@ -159,6 +161,13 @@ else version (CRuntime_Glibc)
///
enum int FP_ILOGBNAN = int.max;
}
+else version (RISCV_Any)
+{
+///
+enum int FP_ILOGB0= -int.max;
+///
+enum int FP_ILOGBNAN = int.max;
+}
else version (SPARC_Any)
{
///
diff --git a/libphobos/libdruntime/core/sys/linux/dlfcn.d b/libphobos/libdruntime/core/sys/linux/dlfcn.d
index 26e5b409253..4f0e66201fb 100644
--- a/libphobos/libdruntime/core/sys/linux/dlfcn.d
+++ b/libphobos/libdruntime/core/sys/linux/dlfcn.d
@@ -16,6 +16,8 @@ version (MIPS32) version = MIPS_Any;
version (MIPS64) version = MIPS_Any;
version (PPC) version = PPC_Any;
version (PPC64) version = PPC_Any;
+version (RISCV32) version = RISCV_Any;
+version (RISCV64) version = RISCV_Any;
version (S390)version = IBMZ_Any;
version (SPARC) version = SPARC_Any;
version (SPARC64) version = SPARC_Any;
@@ -123,6 +125,30 @@ else version (ARM_Any)
void _dl_mcount_wrapper_check(void* __selfpc);
}
}
+else version (RISCV_Any)
+{
+// http://sourceware.org/git/?p=glibc.git;a=blob;f=bits/dlfcn.h
+// enum RTLD_LAZY = 0x0001; // POSIX
+// enum RTLD_NOW = 0x0002; // POSIX
+enum RTLD_BINDING_MASK = 0x3;
+enum RTLD_NOLOAD = 0x4;
+enum RTLD_DEEPBIND = 0x8;
+
+// enum RTLD_GLOBAL = 0x00100; // POSIX
+// enum RTLD_LOCAL = 0; // POSIX
+enum RTLD_NODELETE = 0x01000;
+
+static if (__USE_GNU)
+{
+RT DL_CALL_FCT(RT, Args...)(RT function(Args) fctp, auto ref Args args)
+{
+_dl_mcount_wrapper_check(cast(void*)fctp);
+return fctp(args);
+}
+
+void _dl_mcount_wrapper_check(void* __selfpc);
+}
+}
else version (SPARC_Any)
{
// http://sourceware.org/git/?p=glibc.git;a=blob;f=bits/dlfcn.h
diff --git a/libphobos/libdruntime/core/sys/linux/epoll.d b/libphobos/libdruntime/core/sys/linux/epoll.d
index e77cde4fcf7..c6ee2204815 100644
---
[PATCH,Fortran] RFC: Setup locale for Fortran programs
This patch initializes the locale system when using a Fortran main
program. For non-Fortran main programs that link to libgfortran this
is not done, as such programs are expeced to handle locales
themselves. Following the approach used by python
(https://www.python.org/dev/peps/pep-0538/ ), if the user environment
uses the default C locale, it tries a few fallback options (C.UTF-8,
C.utf8, UTF-8) to set the LC_CTYPE to a UTF-8 locale.
This enables localized error messages for OS errors (strerror() etc.).
Currently this is done unconditionally when set_options() is called,
which is done by the Fortran main(). This should perhaps be handled
through the options array, in order to enable users to disable it,
e.g. for non-Fortran main programs that still want to properly
initialize libgfortran?
Regtested on x86_64-pc-linux-gnu, Ok for trunk?
libgfortran/ChangeLog:
2018-12-01 Janne Blomqvist
* runtime/compile_options.c (set_options): Initialize locale.
---
libgfortran/runtime/compile_options.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/libgfortran/runtime/compile_options.c
b/libgfortran/runtime/compile_options.c
index 1d37e7709df..02274c8251a 100644
--- a/libgfortran/runtime/compile_options.c
+++ b/libgfortran/runtime/compile_options.c
@@ -24,7 +24,8 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
#include "libgfortran.h"
#include
-
+#include
+#include
/* Useful compile-time options will be stored in here. */
compile_options_t compile_options;
@@ -161,6 +162,28 @@ set_options (int num, int options[])
compile_options.fpe_summary = options[6];
#ifndef LIBGFOR_MINIMAL
+
+ /* Set the locale. This is not selectable by a compile option, but
+ this should be setup only when using a Fortran main program, not
+ when loading libgfortran. */
+ setlocale (LC_ALL, "");
+ char *ctype_loc = setlocale (LC_CTYPE, NULL);
+ if (ctype_loc && strcmp (ctype_loc, "C") == 0)
+{
+ /* Try to set the LC_CTYPE to a locale supporting UTF-8 even if
+the environment specifies the default C locale. This is
+similar to e.g. python (see PEP 538). */
+ setlocale (LC_CTYPE, "C.UTF-8");
+ ctype_loc = setlocale (LC_CTYPE, NULL);
+ if (ctype_loc && strcmp (ctype_loc, "C") == 0)
+ {
+ setlocale (LC_CTYPE, "C.utf8");
+ ctype_loc = setlocale (LC_CTYPE, NULL);
+ if (ctype_loc && strcmp (ctype_loc, "C") == 0)
+ setlocale (LC_CTYPE, "UTF-8");
+ }
+}
+
/* If backtrace is required, we set signal handlers on the POSIX
2001 signals with core action. */
if (compile_options.backtrace)
--
2.17.1
Re: [doc, rfc] document __builtin_setjmp and __builtin_longjmp
On 12/1/18 2:27 AM, Andreas Schwab wrote:
On Nov 30 2018, Sandra Loosemore wrote:
+@code{__builtin_setjmp} and @code{__builtin_longjmp} use GCC's normal
Please avoid starting the sentence with a non-capital.
OK, I can fix that easily enough. I was really looking more for
comments on focus, correctness, terminology, etc though. :-)
-Sandra
[wwwdocs] readings.html -- two broken z/Architecture links
I've been getting "A possible equivalent for dz9zr002 was not found." (or similar) for these two pages for a while. If you have suitable links to cover these, please go ahead and add them; for the time being I committed the patch below. Gerald Index: readings.html === RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.306 diff -u -r1.306 readings.html --- readings.html 1 Nov 2018 21:42:00 - 1.306 +++ readings.html 1 Dec 2018 19:03:31 - @@ -309,8 +309,6 @@ z/Architecture (S/390) Manufacturer: IBM - http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dz9ar008/CCONTENTS;>ESA/390 Principles of Operation - http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dz9zr002/CCONTENTS;>z/Architecture Principles of Operation http://refspecs.linuxbase.org/ELF/zSeries/lzsabi0_zSeries.html;>Linux for z Systems ABI
Re: [PATCH] v4: C/C++: add fix-it hints for missing '&' and '*' (PR c++/87850)
On 11/30/18 6:48 PM, David Malcolm wrote:
On Tue, 2018-11-20 at 22:23 +, Joseph Myers wrote:
On Tue, 20 Nov 2018, David Malcolm wrote:
Should I do:
You should do whatever is appropriate for the warning in question. But if
what's appropriate for the warning in question includes types that are
compatible but not the same, the comments need to avoid saying it's about
the types being the same.
Thanks.
Here's an updated version of the patch. I added a new
compatible_types_for_indirection_note_p
specifically for use by maybe_emit_indirection_note, and provided
implementations for C and C++.
+/* C implementation of compatible_types_for_indirection_note_p. */
+
+bool
+compatible_types_for_indirection_note_p (tree type1, tree type2)
+{
+ return comptypes (type1, type2) == 1;
+}
Hmm, it looks like the C front-end comptypes will return 1 for e.g. enum
and int. It seems to me that what you want for this warning is actually
to check for the same type. Perhaps you want to use
comptypes_check_different_types? Joseph would know better what's
correct for the C front-end.
Jason
Re: [testsuite] Require ucn support in gdc.test/compilable/ddoc12.d (PR d/88039)
On Thu, 29 Nov 2018 at 15:12, Rainer Orth wrote:
>
> Hi Iain,
>
> > On Tue, 27 Nov 2018 at 20:32, Rainer Orth
> > wrote:
> >>
> >> Hi Mike,
> >>
> >> > On Nov 27, 2018, at 2:18 AM, Rainer Orth
> >> > wrote:
> >> >>
> >> >> Some assemblers, including the Solaris one, don't support UTF-8
> >> >> identifiers, which breaks the gdc.test/compilable/ddoc12.d testcase as
> >> >> reported in the PR.
> >> >
> >> > So, another style of fix, would be to change the binding from the
> >> > language
> >> > front-end to encode unsupported symbols using a fixed, documented, abi
> >> > defined technique.
> >>
> >> there's been some discussion on this in the PR. Joseph's suggestion was
> >> to follow the system compilers if this were done, and indeed they do
> >> encode UTF-8 identifiers in some way which could either be
> >> reverse-engineered or a spec obtained. However, given Iain's stance
> >> towards UTF-8 identifiers in D, I very much doubt this is worth the
> >> effort. Ultimately, it's his call, of course.
> >>
> >
> > Not only my stance, but as a whole just how those maintaining the core
> > language generally agree on. Encoding UTF8 characters in symbols is
> > not part of the D ABI, so that is something that needs convincing
> > upstream.
> >
> > There is a third way however, all compilable/ddoc* tests don't
> > actually require us to compile the module all the way down to object
> > code, the only thing that really needs to be tested is the Ddoc
> > generator itself. Which would be setting 'dg-do-what compile' and
> > build with the compiler option -fdoc, then dg-final checks for the
> > presence of the file ddoc12.html is the minimum that needs to be done
> > for these tests to be considered passed.
> >
> > I'll have a look into doing it that way tomorrow.
>
> that would be even better of course, also saving some testing time.
>
Hi Rainer,
Attached patch for it, I've checked that and it does the right thing
and passes on x86_64.
There's a couple more changes than just testsuite files, as compiling
with -fdoc unearthed bug fixes not backported from the D version of
the compiler. These I'll apply separately.
--
Iain
---
diff --git a/gcc/d/dmd/doc.c b/gcc/d/dmd/doc.c
index d35ca7b2522..797991ee2c4 100644
--- a/gcc/d/dmd/doc.c
+++ b/gcc/d/dmd/doc.c
@@ -133,6 +133,25 @@ bool isCVariadicParameter(Dsymbols *a, const utf8_t *p, size_t len)
return false;
}
+/
+ */
+static Parameter *isFunctionParameter(Dsymbol *s, const utf8_t *p, size_t len)
+{
+TypeFunction *tf = isTypeFunction(s);
+if (tf && tf->parameters)
+{
+for (size_t k = 0; k < tf->parameters->dim; k++)
+{
+Parameter *fparam = (*tf->parameters)[k];
+if (fparam->ident && cmp(fparam->ident->toChars(), p, len) == 0)
+{
+return fparam;
+}
+}
+}
+return NULL;
+}
+
static Dsymbol *getEponymousMember(TemplateDeclaration *td)
{
if (!td->onemember)
@@ -150,6 +169,54 @@ static Dsymbol *getEponymousMember(TemplateDeclaration *td)
return NULL;
}
+/
+ */
+static Parameter *isEponymousFunctionParameter(Dsymbols *a, const utf8_t *p, size_t len)
+{
+for (size_t i = 0; i < a->dim; i++)
+{
+TemplateDeclaration *td = (*a)[i]->isTemplateDeclaration();
+if (td && td->onemember)
+{
+/* Case 1: we refer to a template declaration inside the template
+
+ /// ...ddoc...
+ template case1(T) {
+ void case1(R)() {}
+ }
+ */
+td = td->onemember->isTemplateDeclaration();
+}
+if (!td)
+{
+/* Case 2: we're an alias to a template declaration
+
+ /// ...ddoc...
+ alias case2 = case1!int;
+ */
+AliasDeclaration *ad = (*a)[i]->isAliasDeclaration();
+if (ad && ad->aliassym)
+{
+td = ad->aliassym->isTemplateDeclaration();
+}
+}
+while (td)
+{
+Dsymbol *sym = getEponymousMember(td);
+if (sym)
+{
+Parameter *fparam = isFunctionParameter(sym, p, len);
+if (fparam)
+{
+return fparam;
+}
+}
+td = td->overnext;
+}
+}
+return NULL;
+}
+
static TemplateDeclaration *getEponymousParent(Dsymbol *s)
{
if (!s->parent)
@@ -1590,6 +1657,12 @@ void ParamSection::write(Loc loc, DocComment *, Scope *sc, Dsymbols *a, OutBuffe
{
size_t o = buf->offset;
Parameter *fparam = isFunctionParameter(a, namestart, namelen);
+if (!fparam)
+{
+// Comments on a template might refer to function parameters within.
+
Re: [committed] Trivial testsuite fix to cope with Indu's recent change
This regression slipped in because my testing was a week old. The predict-22.c is a commit of Nov 28. Thanks Jeff. I saw this regression yesterday and was about to send the patch shortly. I should have kept the patch tested proactively. Thanks Indu On 12/01/2018 08:56 AM, Jeff Law wrote: Indu's change to clean up some profiling dumps clearly wasn't regression tested as it fails on every target. We have an edge to a block with a call to an explicitly marked cold function in it. We consider that a precise prediction. Indu's change reflects that information into the dump file, changing it from "count 0," to "count 0 (precise),". This change fixes the test. Indu, please do a regression test on your changes. That's standard procedure to avoid this kind of problem. Installing on the trunk. jeff
[wwwdocs] gcc-4.9/changes.html -- tweak openmp.org link
This one seems to have escaped my http->https changes for openmp.org the last month(s). Committed. Gerald Index: gcc-4.9/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v retrieving revision 1.96 diff -u -r1.96 changes.html --- gcc-4.9/changes.html30 Sep 2018 14:38:52 - 1.96 +++ gcc-4.9/changes.html1 Dec 2018 17:39:57 - @@ -125,7 +125,7 @@ New Languages and Language specific improvements -Version 4.0 of the http://www.openmp.org/specifications/; +Version 4.0 of the https://www.openmp.org/specifications/; >OpenMP specification is now supported in the C and C++ compilers and starting with the 4.9.1 release also in the Fortran compiler. The new -fopenmp-simd option can be used to enable OpenMP's
Re: [PATCH 2/6] ifcvt: Allow constants operands in noce_convert_multiple_sets.
On 11/15/18 4:34 AM, Robin Dapp wrote: >> This may ultimately be too simplistic. There are targets where some >> constants are OK, but others may not be. By checking the predicate >> like this I think you can cause over-aggressive if-conversion if the >> target allows a range of integers in the expander's operand predicate, >> but allows a narrower range in the actual define_insn (presumably the >> expander loads them into a pseudo or somesuch in that case). >> >> We know that over-aggressive if-conversion into conditional moves hurts >> some targets. >> >> Ideally you'd create the actual insn with the constants you want to use >> and see if that's recognized as well as compute its cost. Is that just >> too painful at this point for some reason? > > Conditional moves in noce_convert_multiple_sets are processed via > noce_emit_cmove which itself performs quite some preprocessing and calls > optab's emit_conditional_move in the end, so the insn will already be > emitted before being able to decide whether to decline it due to costs. > In addition, every noce_emit_cmove will emit the condition check again > as well as possible temporaries. I wonder if we could arrange to emit them onto a new sequence. We could then cost the entire sequence. If we end up wanting to do the transformation we then splice that sequence into the main insn chain at the appropriate place. There should be a start/push/pop/end for sequences that you could use for helpers. > > Comparing the costs of the whole sequence will therefore still prove > difficult as all the additionally generated insns will not get removed > until reload and make a fair comparison nigh impossible. You'd probably have to make an educated guess about what insns from the original sequence would die and could therefore be removed. > > I was reluctant to factor out all the preprocessing stuff, separate it > from the condition check and actual emitting part but that's properly > the "right way" to do it, including emitting the condition only once in > the beginning. If the push_to_sequence idea works you may not have to do a ton of refactoring. Essentially it changes where things like emit_insn and friends splice in newly created insns. It may allow you to leave most of the current code in-place and you just have to splice in the sequence at the end (there's a routine to help you with that too -- it's been a long time, so the names aren't in memory anymore). > > However, for now, I could imagine changing only the > conversion_profitable_p hook in our backend to only count the cmovs and > ignore everything else in the sequence. This would be somewhat hacky > though and still wouldn't allow constants :) That does sound hacky.. jeff
[wwwdocs] news/chill.html - tweak a link
www.itu.int has moved to https. Committed. Gerald Index: news/chill.html === RCS file: /cvs/gcc/wwwdocs/htdocs/news/chill.html,v retrieving revision 1.9 diff -u -r1.9 chill.html --- news/chill.html 30 Sep 2018 14:38:54 - 1.9 +++ news/chill.html 1 Dec 2018 17:25:55 - @@ -28,7 +28,7 @@ the 1984 version, and some other extensions. However, it does not implement all of the features of any standard. The most recent standard is -http://www.itu.int/rec/T-REC-Z.200/en;>Z.200 (11/93). +https://www.itu.int/rec/T-REC-Z.200/en;>Z.200 (11/93). The GNU Chill implementation is not being actively developed. Cygnus has one customer we are maintaining Chill for,
[wwwdocs] Adjust address of Doxygen in codingconventions.html
Committed. Gerald Index: codingconventions.html === RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v retrieving revision 1.89 diff -u -r1.89 codingconventions.html --- codingconventions.html 28 Nov 2018 23:39:31 - 1.89 +++ codingconventions.html 1 Dec 2018 17:19:00 - @@ -665,7 +665,7 @@ first. libstdc++-v3: In docs/doxygen, comments in *.cfg.in are -partially autogenerated from http://www.doxygen.org;>the +partially autogenerated from http://www.doxygen.nl;>the Doxygen tool. In docs/html, the ext/lwg-* files are copied from http://www.open-std.org/jtc1/sc22/wg21/;>the C++ committee homepage, the 27_io/binary_iostream_* files are copies of Usenet postings, and most
[committed] Trivial testsuite fix to cope with Indu's recent change
Indu's change to clean up some profiling dumps clearly wasn't regression
tested as it fails on every target.
We have an edge to a block with a call to an explicitly marked cold
function in it. We consider that a precise prediction.
Indu's change reflects that information into the dump file, changing it
from "count 0," to "count 0 (precise),".
This change fixes the test. Indu, please do a regression test on your
changes. That's standard procedure to avoid this kind of problem.
Installing on the trunk.
jeff
commit 0a0f643d48dc019090042b18fb1f09f21accf640
Author: law
Date: Sat Dec 1 16:52:22 2018 +
* gcc.dg/predict-22.c: Update expected output.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@266709
138bc75d-0d04-0410-961f-82ee72b054a4
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index c5ca4be86c4..18e08062163 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2018-12-01 Jeff Law
+
+ * gcc.dg/predict-22.c: Update expected output.
+
2018-12-01 Jakub Jelinek
PR target/54589
diff --git a/gcc/testsuite/gcc.dg/predict-22.c
b/gcc/testsuite/gcc.dg/predict-22.c
index 0d50c81ebce..a613d266ea8 100644
--- a/gcc/testsuite/gcc.dg/predict-22.c
+++ b/gcc/testsuite/gcc.dg/predict-22.c
@@ -55,5 +55,5 @@ foo (int x, int y, int z)
baz ();
}
/* { dg-final { scan-tree-dump-times "Invalid sum" 0 "optimized"} } */
-/* { dg-final { scan-tree-dump-times "count 0," 1 "optimized"} } */
+/* { dg-final { scan-tree-dump-times "count 0 .precise.," 1 "optimized"} } */
/* { dg-final { scan-rtl-dump-times "COLD_PARTITION" 1 "bbpart"} } */
Re: C++ PATCH to implement C++20 P0634R3, Down with typename!
On Sat, Dec 01, 2018 at 10:57:12AM -0500, Jason Merrill wrote: > On 11/30/18 6:08 PM, Marek Polacek wrote: > > + TYPENAME_OPTIONAL_P is true if the typename keyword is optional in this > > + context. */ > ... > > + TYPENAME_OPTIONAL_P is true if the typename keyword is optional in > > + this context. > > You have a couple of these left over from the previous patch. OK with that > fixed. One day I'll learn how to use grep. Thanks for the reviews! Marek
Re: C++ PATCH to implement C++20 P0634R3, Down with typename!
On 11/30/18 6:08 PM, Marek Polacek wrote: + TYPENAME_OPTIONAL_P is true if the typename keyword is optional in this + context. */ ... + TYPENAME_OPTIONAL_P is true if the typename keyword is optional in + this context. You have a couple of these left over from the previous patch. OK with that fixed. Jason
Re: [doc, rfc] document __builtin_setjmp and __builtin_longjmp
On Nov 30 2018, Sandra Loosemore wrote:
> +@code{__builtin_setjmp} and @code{__builtin_longjmp} use GCC's normal
Please avoid starting the sentence with a non-capital.
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."
