[pushed] Ada : Fix bootstrap after r11-4793.
Hi
The patch omitted a change for Ada, fixed thus.
tested on x86_64-darwin,
pushed to master as obvious/bootstrap fix.
thanks
Iain
gcc/ada/ChangeLog:
* gcc-interface/misc.c (gnat_printable_name): Change
DECL_IS_BUILTIN -> DECL_IS_UNDECLARED_BUILTIN.
---
gcc/ada/gcc-interface/misc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/ada/gcc-interface/misc.c b/gcc/ada/gcc-interface/misc.c
index 781868e2ad3..87724af814e 100644
--- a/gcc/ada/gcc-interface/misc.c
+++ b/gcc/ada/gcc-interface/misc.c
@@ -559,7 +559,7 @@ gnat_printable_name (tree decl, int verbosity)
__gnat_decode (coded_name, ada_name, 0);
- if (verbosity == 2 && !DECL_IS_BUILTIN (decl))
+ if (verbosity == 2 && !DECL_IS_UNDECLARED_BUILTIN (decl))
{
Set_Identifier_Casing (ada_name, DECL_SOURCE_FILE (decl));
return ggc_strdup (Name_Buffer);
--
2.24.1
Re: Rename DECL_IS_BUILTIN to DECL_IS_UNDECLARED_BUILTIN
Andreas Schwab wrote: ../../gcc/ada/gcc-interface/misc.c: In function 'const char* gnat_printable_name(tree, int)': ../../gcc/ada/gcc-interface/misc.c:562:47: error: 'DECL_IS_BUILTIN' was not declared in this scope if (verbosity == 2 && !DECL_IS_BUILTIN (decl)) should be fixed by https://gcc.gnu.org/pipermail/gcc-cvs/2020-November/336719.html thanks Iain
Re: [pushed] Ada : Fix bootstrap after r11-4793.
> The patch omitted a change for Ada, fixed thus. > > tested on x86_64-darwin, > pushed to master as obvious/bootstrap fix. > thanks > Iain > > gcc/ada/ChangeLog: > > * gcc-interface/misc.c (gnat_printable_name): Change > DECL_IS_BUILTIN -> DECL_IS_UNDECLARED_BUILTIN. Thanks for fixing this! -- Eric Botcazou
Re: [PATCH] c++: Tweaks for value_dependent_expression_p.
On Fri, Oct 30, 2020 at 02:36:00AM +, Marek Polacek via Gcc-patches wrote:
> We may not call value_dependent_expression_p on expressions that are
> not potential constant expressions, otherwise value_d could crash,
> as I saw recently (in C++98). So beef up the checking in i_d_e_p.
>
> This revealed a curious issue: when we have __PRETTY_FUNCTION__ in
> a template function, we set its DECL_VALUE_EXPR to error_mark_node
> (cp_make_fname_decl), so potential_c_e returns false when it gets it,
> but value_dependent_expression_p handles it specially and says true.
> This broke lambda-generic-pretty1.C. So take care of that.
>
> And then also tweak uses_template_parms.
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
Hi,
This breaks the GCC build for msp430-elf. The large memory model
(-mlarge) uses __int20 pointers.
In file included from
/home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/sstream:38,
from
../../../../../../libstdc++-v3/src/c++20/sstream-inst.cc:30:
/home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/istream:
In function 'std::basic_istream<_CharT, _Traits>&
std::operator>>(std::basic_istream<_CharT, _Traits>&, _CharT (&)[_Num])':
/home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/istream:840:26:
error: non-constant condition for static assertion
840 | static_assert(_Num <=
__gnu_cxx::__numeric_traits::__max);
|
~^
/home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/istream:840:26:
error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is
not usable in a constant expression
In file included from
/home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/bits/stl_algobase.h:63,
from
/home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/bits/char_traits.h:39,
from
/home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/ios:40,
from
/home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/istream:38,
from
/home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/sstream:38,
from
../../../../../../libstdc++-v3/src/c++20/sstream-inst.cc:30:
/home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/ext/numeric_traits.h:78:27:
note: '__gnu_cxx::__numeric_traits_integer<__int20>::__max' was not
initialized with a constant expression
78 | static const _Value __max = __glibcxx_max(_Value);
| ^
make[9]: *** [Makefile:550: sstream-inst.lo] Error 1
>
> gcc/cp/ChangeLog:
>
> * constexpr.c (potential_constant_expression_1): Treat
> __PRETTY_FUNCTION__ inside a template function as
> potentially-constant.
> * pt.c (uses_template_parms): Call
> instantiation_dependent_expression_p instead of
> value_dependent_expression_p.
> (instantiation_dependent_expression_p): Check
> potential_constant_expression before calling
> value_dependent_expression_p.
> ---
> gcc/cp/constexpr.c | 5 +
> gcc/cp/pt.c| 5 +++--
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
> index b46824f128d..c257dfcb2e6 100644
> --- a/gcc/cp/constexpr.c
> +++ b/gcc/cp/constexpr.c
> @@ -7716,6 +7716,11 @@ potential_constant_expression_1 (tree t, bool
> want_rval, bool strict, bool now,
> }
> return false;
> }
> + /* Treat __PRETTY_FUNCTION__ inside a template function as
> + potentially-constant. */
> + else if (DECL_PRETTY_FUNCTION_P (t)
> +&& DECL_VALUE_EXPR (t) == error_mark_node)
> + return true;
> return RECUR (DECL_VALUE_EXPR (t), rval);
> }
>if (want_rval
> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> index b569644514c..c419fb470ee 100644
> --- a/gcc/cp/pt.c
> +++ b/gcc/cp/pt.c
> @@ -10755,7 +10755,7 @@ uses_template_parms (tree t)
>else if (t == error_mark_node)
> dependent_p = false;
>else
> -dependent_p = value_dependent_expression_p (t);
> +dependent_p = instantiation_dependent_expression_p (t);
>
>processing_template_decl = saved_processing_template_decl;
>
> @@ -27293,7 +27293,8 @@ bool
> instantiation_dependent_expression_p (tree expression)
> {
>return (instantiation_dependent_uneval_expression_p (expression)
> - || value_dependent_expression_p (expression));
> + || (potential_constant_expression (expression)
> + && value_dependent_expression_p (expression)));
> }
>
> /* Like type_dependent_expression_p, but it also works while not processing
>
> base-commit: 4f0606fe4bbf1346f83dd4d0c9060c6b46672a7d
> --
> 2.28.0
Re: [PATCH] libcpp: Update cpp_wcwidth() to Unicode 13.0.0
On Fri, Nov 6, 2020 at 12:46 PM Jeff Law wrote: > > > On 10/23/20 9:01 AM, Lewis Hyatt via Gcc-patches wrote: > > Hello- > > > > The attached patch updates cpp_wcwidth() (for computation of display > > widths needed to calculate column numbers in diagnostics) from Unicode 12 > > to Unicode 13. The patch was purely mechanical, following the directions > > in contrib/unicode/README without any unexpected hiccups. A couple > > questions please: > > > > -Is it OK for master? > > Yes, it is OK for the trunk. Please go ahead and commit it. > > > > > > -Unicode 13 actually came out just immediately before GCC 10 was > > released. Would it make sense to put this on GCC 10 branch as well? > > I wouldn't. The general guidance is that we fix regressions on the > release branches and this wouldn't qualify. > Got it, thanks! All set now. -Lewis -Lewis
[PATCH] Objective-C++ : Allow prefix attrs on linkage specs.
Hi,
For Objective-C++/C, we cater for the possibility that a class interface
(@interface) might be preceded by prefix attributes. In the case of
Objective-C++, the reference implementation (a.k.a. clang) also allows
(and combines) prefix attributes that precede a linkage specification
(but only on a single decl).
Some discussion with Nathan here:
https://gcc.gnu.org/pipermail/gcc/2020-October/234057.html
The upshot is that clang’s behaviour is inconsistent (I can file a bug,
I guess) - but since what is “well-formed” for Objective-C is defined in
reality by what clang accepts - there is a body of code out there that
depends on the behaviour (some variant of Hyrum’s law, or corollary
to it, perhaps?).
Inability to parse code including these patterns is blocking progress
in modernising GNU Objective-C.. so I need to find a way forward.
The compromise made here is to accept the sequence when parsing
for Objective-C++, and to warn** that the attributes are discarded otherwise.
This seems to me to be an improvement in diagnostics for regular C++
(since it now says something pertinent to the actual problem and does
the 'same as usual' when encountering an unhandled attribute).
Tested across the Darwin patch, and on x86_64-linux-gnu,
OK for master?
thanks
Iain
** trivially, that could be an error instead - but it seems we usually warn
for unrecognised attributes.
—— commit message
For Objective-C++, this combines prefix attributes from before and
after top level linkage specs. The "reference implementation" for
Objective-C++ allows this, and system headers depend on it.
e.g.
__attribute__((__deprecated__))
extern "C" __attribute__((__visibility__("default")))
@interface MyClass
...
@end
Would consider the list of prefix attributes to the interface for
MyClass to include both the visibility and deprecated ones.
When we are compiling regular C++, this emits a warning and discards
any prefix attributes before a linkage spec.
gcc/cp/ChangeLog:
* parser.c (cp_parser_declaration): Unless we are compiling for
Ojective-C++, warn about and discard any attributes that prefix
a linkage specification.
---
gcc/cp/parser.c | 71 +++--
1 file changed, 57 insertions(+), 14 deletions(-)
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index c4c672efa09..320d151c060 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -2187,7 +2187,7 @@ static void cp_parser_already_scoped_statement
static void cp_parser_declaration_seq_opt
(cp_parser *);
static void cp_parser_declaration
- (cp_parser *);
+ (cp_parser *, tree);
static void cp_parser_toplevel_declaration
(cp_parser *);
static void cp_parser_block_declaration
@@ -2238,7 +2238,7 @@ static tree cp_parser_alias_declaration
static void cp_parser_asm_definition
(cp_parser *);
static void cp_parser_linkage_specification
- (cp_parser *);
+ (cp_parser *, tree);
static void cp_parser_static_assert
(cp_parser *, bool);
static tree cp_parser_decltype
@@ -13496,7 +13496,7 @@ cp_parser_declaration_seq_opt (cp_parser* parser)
__extension__ declaration */
static void
-cp_parser_declaration (cp_parser* parser)
+cp_parser_declaration (cp_parser* parser, tree prefix_attrs)
{
int saved_pedantic;
@@ -13504,7 +13504,7 @@ cp_parser_declaration (cp_parser* parser)
if (cp_parser_extension_opt (parser, &saved_pedantic))
{
/* Parse the qualified declaration. */
- cp_parser_declaration (parser);
+ cp_parser_declaration (parser, prefix_attrs);
/* Restore the PEDANTIC flag. */
pedantic = saved_pedantic;
@@ -13521,11 +13521,50 @@ cp_parser_declaration (cp_parser* parser)
tree attributes = NULL_TREE;
+ /* Conditionally, allow attributes to precede a linkage specification. */
+ if (token1->keyword == RID_ATTRIBUTE)
+{
+ cp_lexer_save_tokens (parser->lexer);
+ attributes = cp_parser_attributes_opt (parser);
+ gcc_checking_assert (attributes);
+ cp_token *t1 = cp_lexer_peek_token (parser->lexer);
+ cp_token *t2 = (t1->type == CPP_EOF
+ ? t1 : cp_lexer_peek_nth_token (parser->lexer, 2));
+ if (t1->keyword == RID_EXTERN
+ && cp_parser_is_pure_string_literal (t2))
+ {
+ cp_lexer_commit_tokens (parser->lexer);
+ /* We might have already been here. */
+ if (!c_dialect_objc ())
+ {
+ warning_at (token1->location, OPT_Wattributes, "attributes are"
+ " only permitted in this position for Objective-C++,"
+ " ignored");
+ attributes = NULL_TREE;
+ }
+ token1 = t1;
+ token2 = t2;
+ }
+ else
+ {
+ cp_lexer_rollback_tokens (parser->lexer);
+ attributes = NULL_TREE;
+ }
+}
+ /* If we already had some attributes, and we've added more, then prepend.
+ Otherwise attributes just contains any that we just read. *
[C PATCH RFC] Drop qualifiers during lvalue conversion
To better understand what impact this may have, I added code
to drop the qualifiers in 'convert_lvalue_to_rvalue'. Here
is the patch.
There are three new errors in the testsuite:
In 'gcc.dg/cond-constqual-1.c' we test for the opposite
behavior for conditional operators. I do not know why.
We could just invert the test.
In 'gcc.dg/pr60195.c' there is a new warning for a statement
with no effect for an unused atomic load. This warning
seems correct to me and I think it is wrong that we do not
currently have it.
Finally, there is a failure:
FAIL: gcc.dg/tree-ssa/pr33723.c scan-tree-dump-not gimple "t = D"
This is a partial regression related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33723
where we now produce a temporary if there is a
qualifier:
void
baz1 (void)
{
T t;
t = (const T) { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } };
test (&t);
}
Not sure what to do about it, maybe 'convert' is not
the right function to use.
Best,
Martin
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 96840377d90..aeacd30badd 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -2080,6 +2080,8 @@ convert_lvalue_to_rvalue (location_t loc, struct c_expr
exp,
exp = default_function_array_conversion (loc, exp);
if (!VOID_TYPE_P (TREE_TYPE (exp.value)))
exp.value = require_complete_type (loc, exp.value);
+ if (convert_p && !error_operand_p (exp.value))
+exp.value = convert (build_qualified_type (TREE_TYPE (exp.value),
TYPE_UNQUALIFIED),
exp.value);
if (really_atomic_lvalue (exp.value))
{
vec *params;
diff --git a/gcc/testsuite/gcc.dg/cond-constqual-1.c
b/gcc/testsuite/gcc.dg/cond-constqual-1.c
index 3354c7214a4..b5a09cb0038 100644
--- a/gcc/testsuite/gcc.dg/cond-constqual-1.c
+++ b/gcc/testsuite/gcc.dg/cond-constqual-1.c
@@ -11,5 +11,5 @@ test (void)
__typeof__ (1 ? foo (0) : 0) texpr;
__typeof__ (1 ? i : 0) texpr2;
texpr = 0; /* { dg-bogus "read-only variable" "conditional expression with
call to const
function" } */
- texpr2 = 0; /* { dg-error "read-only variable" "conditional expression with
const variable" } */
+ texpr2 = 0; /* { dg-bogus "read-only variable" "conditional expression with
const variable" } */
}
diff --git a/gcc/testsuite/gcc.dg/lvalue-11.c b/gcc/testsuite/gcc.dg/lvalue-11.c
new file mode 100644
index 000..45a97d86890
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/lvalue-11.c
@@ -0,0 +1,46 @@
+/* test that lvalue conversions drops qualifiers, Bug 97702 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+
+void f(void)
+{
+ const int j;
+ typeof((0,j)) i10; i10 = j;;
+ typeof(+j) i11; i11 = j;;
+ typeof(-j) i12; i12 = j;;
+ typeof(1?j:0) i13; i13 = j;;
+ typeof((int)j) i14; i14 = j;;
+ typeof((const int)j) i15; i15 = j;;
+}
+
+void g(void)
+{
+ volatile int j;
+ typeof((0,j)) i21; i21 = j;;
+ typeof(+j) i22; i22 = j;;
+ typeof(-j) i23; i23 = j;;
+ typeof(1?j:0) i24; i24 = j;;
+ typeof((int)j) i25; i25 = j;;
+ typeof((volatile int)j) i26; i26 = j;;
+}
+
+void h(void)
+{
+ _Atomic int j;
+ typeof((0,j)) i32; i32 = j;;
+ typeof(+j) i33; i33 = j;;
+ typeof(-j) i34; i34 = j;;
+ typeof(1?j:0) i35; i35 = j;;
+ typeof((int)j) i36; i36 = j;;
+ typeof((_Atomic int)j) i37; i37 = j;;
+}
+
+void e(void)
+{
+ int* restrict j;
+ typeof((0,j)) i43; i43 = j;;
+ typeof(1?j:0) i44; i44 = j;;
+ typeof((int*)j) i45; i45 = j;;
+ typeof((int* restrict)j) i46; i46 = j;;
+}
diff --git a/gcc/testsuite/gcc.dg/pr60195.c b/gcc/testsuite/gcc.dg/pr60195.c
index 0a50a30be25..8eccf7f63ad 100644
--- a/gcc/testsuite/gcc.dg/pr60195.c
+++ b/gcc/testsuite/gcc.dg/pr60195.c
@@ -15,7 +15,7 @@ atomic_int
fn2 (void)
{
atomic_int y = 0;
- y;
+ y; /* { dg-warning "statement with no effect" } */
return y;
}
[PATCH] CFI-handling : Add a hook to allow target-specific Personality and LSDA indirections.
Hi
** Actually, this was originally posted during last stage-1, but I forgot to
keep
pinging it…
At present, the output of .cfi_personality and .cfi_lsda assumes
ELF semantics for indirections. This isn't suitable for all targets
and is one blocker to moving Darwin to use .cfi_.
The patch adds a target hook that allows non-ELF targets to use
indirections appropriate to their needs.
tested across the Darwin range and on x86_64-linux-gnu,
OK for master?
thanks
Iain
--
gcc/ChangeLog:
* config/darwin-protos.h (darwin_make_eh_symbol_indirect): New.
* config/darwin.c (darwin_make_eh_symbol_indirect): New. Use
Mach-O semantics for personality and ldsa indirections.
* config/darwin.h (TARGET_ASM_MAKE_EH_SYMBOL_INDIRECT): New.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in: Add TARGET_ASM_MAKE_EH_SYMBOL_INDIRECT hook.
* dwarf2out.c (dwarf2out_do_cfi_startproc): If the target defines
a hook for indirecting personality and ldsa references, use that
otherwise default to ELF semantics.
* target.def (make_eh_symbol_indirect): New target hook.
---
gcc/config/darwin-protos.h | 1 +
gcc/config/darwin.c| 11 +++
gcc/config/darwin.h| 3 +++
gcc/doc/tm.texi| 4
gcc/doc/tm.texi.in | 2 ++
gcc/dwarf2out.c| 14 --
gcc/target.def | 10 ++
7 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/gcc/config/darwin-protos.h b/gcc/config/darwin-protos.h
index 49c540fe08e..3f222c3bbdc 100644
--- a/gcc/config/darwin-protos.h
+++ b/gcc/config/darwin-protos.h
@@ -69,6 +69,7 @@ extern void darwin_non_lazy_pcrel (FILE *, rtx);
extern void darwin_emit_unwind_label (FILE *, tree, int, int);
extern void darwin_emit_except_table_label (FILE *);
+extern rtx darwin_make_eh_symbol_indirect (rtx, bool);
extern void darwin_pragma_ignore (struct cpp_reader *);
extern void darwin_pragma_options (struct cpp_reader *);
diff --git a/gcc/config/darwin.c b/gcc/config/darwin.c
index dd4857f9e34..3265e3e6cb7 100644
--- a/gcc/config/darwin.c
+++ b/gcc/config/darwin.c
@@ -2225,6 +2225,17 @@ darwin_emit_except_table_label (FILE *file)
ASM_OUTPUT_LABEL (file, section_start_label);
}
+rtx
+darwin_make_eh_symbol_indirect (rtx orig, bool ARG_UNUSED (pubvis))
+{
+ if (DARWIN_PPC == 0 && TARGET_64BIT)
+return orig;
+
+ return gen_rtx_SYMBOL_REF (Pmode,
+machopic_indirection_name (orig,
+ /*stub_p=*/false));
+}
+
/* Return, and mark as used, the name of the stub for the mcount function.
Currently, this is only called by X86 code in the expansion of the
FUNCTION_PROFILER macro, when stubs are enabled. */
diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index f9d4fec30a0..5a766319cb0 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -591,6 +591,9 @@ extern GTY(()) int darwin_ms_struct;
/* Emit a label to separate the exception table. */
#define TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL darwin_emit_except_table_label
+/* Make an EH (personality or LDSA) symbol indirect as needed. */
+#define TARGET_ASM_MAKE_EH_SYMBOL_INDIRECT darwin_make_eh_symbol_indirect
+
/* Our profiling scheme doesn't LP labels and counter words. */
#define NO_PROFILE_COUNTERS1
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 833320ba7bf..a783a21f6cf 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -9560,6 +9560,10 @@ given instruction. This is only used when
@code{TARGET_EXCEPT_UNWIND_INFO}
returns @code{UI_TARGET}.
@end deftypefn
+@deftypefn {Target Hook} rtx TARGET_ASM_MAKE_EH_SYMBOL_INDIRECT (rtx
@var{origsymbol}, bool @var{pubvis})
+If necessary, modify personality and LSDA references to handle indirection.
The original symbol is in @code{origsymbol} and if @code{pubvis} is true the
symbol is visible outside the TU.
+@end deftypefn
+
@deftypevr {Target Hook} bool TARGET_ASM_UNWIND_EMIT_BEFORE_INSN
True if the @code{TARGET_ASM_UNWIND_EMIT} hook should be called before the
assembly for @var{insn} has been emitted, false if the hook should be called
afterward.
@end deftypevr
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 58109be3693..897f2896266 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -6456,6 +6456,8 @@ the jump-table.
@hook TARGET_ASM_UNWIND_EMIT
+@hook TARGET_ASM_MAKE_EH_SYMBOL_INDIRECT
+
@hook TARGET_ASM_UNWIND_EMIT_BEFORE_INSN
@node Exception Region Output
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index bc32a17efcd..bea02f9fbce 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -991,7 +991,12 @@ dwarf2out_do_cfi_startproc (bool second)
in the assembler. Further, the assembler can't handle any
of the weirder relocation types. */
if (enc & DW_EH_PE_indirect)
- ref = dw2_force_const_mem (ref, true);
+ {
+ if (targetm.asm_out.make_eh_symbol_i
PING^4 [PATCH] Use the section flag 'o' for __patchable_function_entries
On Sat, Oct 31, 2020 at 5:01 AM H.J. Lu wrote: > > On Fri, Oct 23, 2020 at 5:41 AM H.J. Lu wrote: > > > > On Fri, Oct 2, 2020 at 6:00 AM H.J. Lu wrote: > > > > > > On Thu, Feb 6, 2020 at 6:57 PM H.J. Lu wrote: > > > > > > > > This commit in GNU binutils 2.35: > > > > > > > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=b7d072167715829eed0622616f6ae0182900de3e > > > > > > > > added the section flag 'o' to .section directive: > > > > > > > > .section __patchable_function_entries,"awo",@progbits,foo > > > > > > > > which specifies the symbol name which the section references. Assembler > > > > creates a unique __patchable_function_entries section with the section, > > > > where foo is defined, as its linked-to section. Linker keeps a section > > > > if its linked-to section is kept during garbage collection. > > > > > > > > This patch checks assembler support for the section flag 'o' and uses > > > > it to implement __patchable_function_entries section. Since Solaris may > > > > use GNU assembler with Solairs ld. Even if GNU assembler supports the > > > > section flag 'o', it doesn't mean that Solairs ld supports it. This > > > > feature is disabled for Solairs targets. > > > > > > > > gcc/ > > > > > > > > PR middle-end/93195 > > > > PR middle-end/93197 > > > > * configure.ac (HAVE_GAS_SECTION_LINK_ORDER): New. Define if > > > > the assembler supports the section flag 'o' for specifying > > > > section with link-order. > > > > * dwarf2out.c (output_comdat_type_unit): Pass 0 as flags2 > > > > to targetm.asm_out.named_section. > > > > * config/sol2.c (solaris_elf_asm_comdat_section): Likewise. > > > > * output.h (SECTION2_LINK_ORDER): New. > > > > (switch_to_section): Add an unsigned int argument. > > > > (default_no_named_section): Likewise. > > > > (default_elf_asm_named_section): Likewise. > > > > * target.def (asm_out.named_section): Likewise. > > > > * targhooks.c (default_print_patchable_function_entry): Pass > > > > current_function_decl to get_section and SECTION2_LINK_ORDER > > > > to switch_to_section. > > > > * varasm.c (default_no_named_section): Add an unsigned int > > > > argument. > > > > (default_elf_asm_named_section): Add an unsigned int argument, > > > > flags2. Use 'o' flag for SECTION2_LINK_ORDER if assembler > > > > supports it. > > > > (switch_to_section): Add an unsigned int argument and pass it > > > > to targetm.asm_out.named_section. > > > > (handle_vtv_comdat_section): Pass 0 to > > > > targetm.asm_out.named_section. > > > > * config.in: Regenerated. > > > > * configure: Likewise. > > > > * doc/tm.texi: Likewise. > > > > > > > > gcc/testsuite/ > > > > > > > > PR middle-end/93195 > > > > * g++.dg/pr93195a.C: New test. > > > > * g++.dg/pr93195b.C: Likewise. > > > > * lib/target-supports.exp > > > > (check_effective_target_o_flag_in_section): New proc. > > > > > > PING > > > > > > https://gcc.gnu.org/pipermail/gcc-patches/2020-February/539963.html > > > > PING. > > > > PING. > PING. -- H.J.
Re: [PATCH 1/4] c++: Fix ICE with variadic concepts and aliases [PR93907]
On Fri, 6 Nov 2020, Jason Merrill wrote:
> On 11/5/20 8:40 PM, Patrick Palka wrote:
> > This patch (naively) extends the PR93907 fix to also apply to variadic
> > concepts invoked with a type argument pack. Without this, we ICE on
> > the below testcase (a variadic version of concepts-using2.C) in the same
> > manner as we used to on concepts-using2.C before r10-7133.
> >
> > Patch series bootstrapped and regtested on x86_64-pc-linux-gnu,
> > and also tested against cmcstl2 and range-v3.
> >
> > gcc/cp/ChangeLog:
> >
> > PR c++/93907
> > * constraint.cc (tsubst_parameter_mapping): Also canonicalize
> > the type arguments of a TYPE_ARGUMENT_PACk.
> >
> > gcc/testsuite/ChangeLog:
> >
> > PR c++/93907
> > * g++.dg/cpp2a/concepts-using3.C: New test, based off of
> > concepts-using2.C.
> > ---
> > gcc/cp/constraint.cc | 10
> > gcc/testsuite/g++.dg/cpp2a/concepts-using3.C | 52
> > 2 files changed, 62 insertions(+)
> > create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-using3.C
> >
> > diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
> > index b6f6f0d02a5..c871a8ab86a 100644
> > --- a/gcc/cp/constraint.cc
> > +++ b/gcc/cp/constraint.cc
> > @@ -2252,6 +2252,16 @@ tsubst_parameter_mapping (tree map, tree args,
> > subst_info info)
>
> Hmm, the
>
> > else if (ARGUMENT_PACK_P (arg))
> > new_arg = tsubst_argument_pack (arg, args, complain, in_decl);
>
> just above this seems redundant, since tsubst_template_arg handles packs just
> fine. In fact, I wonder why tsubst_argument_pack is used specifically
> anywhere? It seems to get some edge cases better than the code in tsubst, but
> the solution to that would seem to be replacing the code in tsubst with a call
> to tsubst_argument_pack; then we can remove all the other calls to the
> function.
They seem interchangeable here wrt handling TYPE_ARGUMENT_PACKs, but not
NONTYPE_ARGUMENT_PACKs. It looks like tsubst_template_arg ends up just
issuing an error from tsubst_expr if we try using it to substitute into
a NONTYPE_ARGUMENT_PACK.
>
> > new_arg = tsubst_template_arg (arg, args, complain, in_decl);
> > if (TYPE_P (new_arg))
> > new_arg = canonicalize_type_argument (new_arg, complain);
> > + if (TREE_CODE (new_arg) == TYPE_ARGUMENT_PACK)
> > + {
> > + tree pack_args = ARGUMENT_PACK_ARGS (new_arg);
> > + for (int i = 0; i < TREE_VEC_LENGTH (pack_args); i++)
> > + {
> > + tree& pack_arg = TREE_VEC_ELT (pack_args, i);
> > + if (TYPE_P (pack_arg))
> > + pack_arg = canonicalize_type_argument (pack_arg,
> > complain);
>
> Do we need the TYPE_P here, since we already know we're in a
> TYPE_ARGUMENT_PACK? That is, can an element of a TYPE_ARGUMENT_PACK be an
> invalid argument to canonicalize_type_argument?
With -fconcepts-ts, the elements of a TYPE_ARGUMENT_PACK here can be
TEMPLATE_DECLs, as in e.g. line 28 of concepts/template-parm3.C.
>
> OTOH, I wonder if we need to canonicalize non-type arguments here as well?
Hmm, I'm not sure. Not doing so should at worst result in a
satisfaction cache miss in release builds, and in checking builds should
get caught by the hash table sanitizer. I haven't been able to come up
with a testcase that demonstrates it's necessary.
>
> I wonder if tsubst_template_arg should canonicalize rather than leave that up
> to the caller? I suppose that could do a bit more work when the result is
> going to end up in convert_template_argument and get canonicalized again; I
> don't know if that would be significant.
That seems like it works, based on some limited testing. But there are
only two users of canonicalize_template_argument outside of
convert_template_argument itself, and the one use in unify is still
needed even with this change (or else we get many ICEs coming from
verify_unstripped_args if we try to remove it). So the benefit of such
a change seems marginal at the moment.
>
> > }
> > if (new_arg == error_mark_node)
> > return error_mark_node;
> > diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-using3.C
> > b/gcc/testsuite/g++.dg/cpp2a/concepts-using3.C
> > new file mode 100644
> > index 000..2c8ad40d104
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/cpp2a/concepts-using3.C
> > @@ -0,0 +1,52 @@
> > +// PR c++/93907
> > +// { dg-options -std=gnu++20 }
> > +
> > +// This testcase is a variadic version of concepts-using2.C; the only
> > +// difference is that 'cd' and 'ce' are now variadic concepts.
> > +
> > +template struct c {
> > + static constexpr int d = a;
> > + typedef c e;
> > +};
> > +template struct f;
> > +template using g = typename f::e;
> > +struct b;
> > +template struct f { using e = b; };
> > +template struct m { typedef g aj; };
> > +template struct n { typedef typename m::aj e; };
> > +template using an = typename n::e;
> > +template constexpr bool ao = c::d;
> >
Re: [PATCH] c++: Don't purge the satisfaction caches
On Fri, 6 Nov 2020, Jason Merrill wrote:
> On 11/2/20 9:03 AM, Patrick Palka wrote:
> > On Tue, 27 Oct 2020, Patrick Palka wrote:
> >
> > > The adoption of P2104 means we can memoize the result of satisfaction
> > > indefinitely and no longer have to clear the satisfaction caches on
> > > various events that would affect satisfaction. To that end, this patch
> > > removes clear_satisfaction_cache and adjusts its callers appropriately.
> > >
> > > This provides a massive reduction in compile time and memory use in some
> > > cases. For example, on the libstdc++ test std/ranges/adaptor/join.cc,
> > > compile time and memory usage drops nearly 75%, from 7.5s/770MB to
> > > 2s/230MB, with a --enable-checking=release compiler.
> > >
> > > [ This patch depends on
> > >
> > > c++: Check constraints only for candidate conversion functions.
> > >
> > >Without it, many of the libstdc++ range adaptor tests fail due to
> > >us now indefinitely memoizing a bogus satisfaction result caused by
> > >checking the constraints of a conversion function when we weren't
> > >supposed to, which led to a "use of foo_view::end() before deduction
> > >of auto" SFINAE error. This went unnoticed without this patch because
> > >by the time we needed this satisfaction result again, we had cleared
> > >the satisfaction cache and finished deducing the return type of
> > >foo_view::end(), so on subsequent tries we computed the correct
> > >satisfaction result. ]
> >
> > With the library-side workaround r11-4584 for the range adaptor test
> > failures now committed, the mentioned frontend patch about candidate
> > conversion functions is no longer a prerequisite (and was not we want
> > anyway).
> >
> > >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > > trunk (pending approval of the prerequisite patch)? Also tested on
> > > cmcstl2 and range-v3.
> >
> > Now successfully bootstrapped and regtested on top of r11-4584, and also
> > tested on cmcstl2 and range-v3. Does this look OK for trunk?
>
> For me, this patch broke the view.join test in cmcstl2. Are you not seeing
> that?
Yes, cmcstl2's join_view suffers from the exact same issue that the
libstdc++ join_view (and many other views) had before the library-side
fix r11-4584. (They are defined very similarly.)
In short, the satisfaction value of range inadvertently
depends on itself. We don't fall into an infinite loop only because
this circular dependence is through return type deduction of
join_view::begin, and this part of the dependence chain breaks the
infinite loop via a "use of foo before deduction of auto" SFINAE error.
We used to invalidate the cache shortly thereafter, but no longer, so
the bogus satisfaction value is now observable.
The following rough patch can be used to get a better sense of what's
going on. It inserts a dummy satisfaction value into the satisfaction
cache when evaluating an atom for the first atom, and verifies
via a gcc_assert that we don't try retrieving the satisfaction value of
this atom while its being evaluated. The view.join test of cmcstl2
trips over this assert. (Diagnosing when the satisfaction value of an
atom depends on itself is on my TODO list after the rest of the caching
optimizations are in. Getting good diagnostics for this is a little
tricky.)
-- >8 --
diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index c871a8ab86a..0f7663b9a7a 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -2312,6 +2312,9 @@ static GTY((deletable)) hash_table *sat_cache;
/* Cache the result of constraint_satisfaction_value. */
static GTY((deletable)) hash_map *decl_satisfied_cache;
+static void
+save_satisfaction (tree constr, tree args, tree result);
+
static tree
get_satisfaction (tree constr, tree args)
{
@@ -2320,9 +2323,19 @@ get_satisfaction (tree constr, tree args)
sat_entry elt = { constr, args, NULL_TREE };
sat_entry* found = sat_cache->find (&elt);
if (found)
-return found->result;
+{
+ /* If this assert fails, then the satisfaction value of an atom
+recursively depends on itself. */
+ gcc_assert (found->result);
+ return found->result;
+}
else
-return NULL_TREE;
+{
+ /* Mark that this atom is being evaluated by setting its
+result to NULL_TREE. */
+ save_satisfaction (constr, args, NULL_TREE);
+ return NULL_TREE;
+}
}
static void
[r11-4813 Regression] FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++98 (test for warnings, line 36) on Linux/x86_64
On Linux/x86_64,
8b7a9a249a63e066cff6e95db05a3158b4cc56cc is the first bad commit
commit 8b7a9a249a63e066cff6e95db05a3158b4cc56cc
Author: Martin Uecker
Date: Sat Nov 7 00:48:33 2020 +0100
C Parser: Implement mixing of labels and code.
caused
FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++14 (test for excess
errors)
FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++14 (test for
warnings, line 30)
FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++14 (test for
warnings, line 32)
FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++14 (test for
warnings, line 36)
FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++17 (test for excess
errors)
FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++17 (test for
warnings, line 30)
FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++17 (test for
warnings, line 32)
FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++17 (test for
warnings, line 36)
FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++2a (test for excess
errors)
FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++2a (test for
warnings, line 30)
FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++2a (test for
warnings, line 32)
FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++2a (test for
warnings, line 36)
FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++98 (test for excess
errors)
FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++98 (test for
warnings, line 30)
FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++98 (test for
warnings, line 32)
FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++98 (test for
warnings, line 36)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-4813/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=c-c++-common/Wimplicit-fallthrough-20.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=c-c++-common/Wimplicit-fallthrough-20.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=c-c++-common/Wimplicit-fallthrough-20.c
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=c-c++-common/Wimplicit-fallthrough-20.c
--target_board='unix{-m64\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at skpgkp2 at gmail dot com)
Re: [r11-4813 Regression] FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++98 (test for warnings, line 36) on Linux/x86_64
On Sat, Nov 07, 2020 at 10:15:14AM -0800, sunil.k.pandey via Gcc-patches wrote:
> On Linux/x86_64,
>
> 8b7a9a249a63e066cff6e95db05a3158b4cc56cc is the first bad commit
> commit 8b7a9a249a63e066cff6e95db05a3158b4cc56cc
> Author: Martin Uecker
> Date: Sat Nov 7 00:48:33 2020 +0100
>
> C Parser: Implement mixing of labels and code.
>
> caused
>
> FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++14 (test for excess
> errors)
> FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++14 (test for
> warnings, line 30)
> FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++14 (test for
> warnings, line 32)
> FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++14 (test for
> warnings, line 36)
> FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++17 (test for excess
> errors)
> FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++17 (test for
> warnings, line 30)
> FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++17 (test for
> warnings, line 32)
> FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++17 (test for
> warnings, line 36)
> FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++2a (test for excess
> errors)
> FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++2a (test for
> warnings, line 30)
> FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++2a (test for
> warnings, line 32)
> FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++2a (test for
> warnings, line 36)
> FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++98 (test for excess
> errors)
> FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++98 (test for
> warnings, line 30)
> FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++98 (test for
> warnings, line 32)
> FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++98 (test for
> warnings, line 36)
Fixed:
-- >8 --
The r11-4813 patch removed "ignored" from the dg-warnings in this test,
causing this test to fail when compiled as C++.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/testsuite/ChangeLog:
* c-c++-common/Wimplicit-fallthrough-20.c: Adjust dg-warning.
---
gcc/testsuite/c-c++-common/Wimplicit-fallthrough-20.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/c-c++-common/Wimplicit-fallthrough-20.c
b/gcc/testsuite/c-c++-common/Wimplicit-fallthrough-20.c
index 810c331b19a..bc0cd0fe580 100644
--- a/gcc/testsuite/c-c++-common/Wimplicit-fallthrough-20.c
+++ b/gcc/testsuite/c-c++-common/Wimplicit-fallthrough-20.c
@@ -27,13 +27,13 @@ g (int i)
switch (i)
{
case -1:
- __attribute__((used)); /* { dg-warning "empty declaration" } */
+ __attribute__((used)); /* { dg-warning "empty declaration|ignored" } */
default:
- __attribute__((used)); /* { dg-warning "empty declaration" } */
+ __attribute__((used)); /* { dg-warning "empty declaration|ignored" } */
case 1:
return 6;
case 2 ... 4:
- __attribute__((used)); /* { dg-warning "empty declaration" } */
+ __attribute__((used)); /* { dg-warning "empty declaration|ignored" } */
case 5:
return 7;
}
base-commit: 497c9f8d4dd0252f2e0dd5bf0f1cb29e187525ee
--
2.28.0
Re: [r11-4813 Regression] FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++98 (test for warnings, line 36) on Linux/x86_64
Thanks, Marek!
Re: [PATCH] rs6000: MMA type causes an ICE in ranger pass due to incompatible types
On 10/21/20 2:31 PM, Peter Bergner wrote: > Ok, I'll wait a week and then do the backport and testing. I just pushed this to the GCC 10 release branch now. Peter
