Re: [PATCH] Fix __has_include error recovery in libcpp (PR preprocessor/88974)
On Fri, Jan 25, 2019 at 09:31:18AM -0500, Jason Merrill wrote:
> On 1/25/19 12:15 AM, Jakub Jelinek wrote:
> > On Thu, Jan 24, 2019 at 05:16:52PM -0500, Jason Merrill wrote:
> > > > --- libcpp/expr.c.jj2019-01-01 12:38:16.132007335 +0100
> > > > +++ libcpp/expr.c 2019-01-24 14:07:10.080774120 +0100
> > > > @@ -2238,7 +2238,9 @@ parse_has_include (cpp_reader *pfile, en
> > > > XDELETEVEC (fname);
> > > >}
> > > > - if (paren && cpp_get_token (pfile)->type != CPP_CLOSE_PAREN)
> > > > + if (paren
> > > > + && pfile->cur_token[-1].type != CPP_EOF
> > >
> > > Is there a reason not to use the SEEN_EOL macro here, too (first moving it
> > > into a header)?
> >
> > I can move it if you want to internal.h.
>
> OK with that change.
Here is what I've committed after another bootstrap/regtest on
{x86_64,i686}-linux. Thanks.
2019-01-26 Jakub Jelinek
PR preprocessor/88974
* directives.c (SEEN_EOL): Move macro to ...
* internal.h (SEEN_EOL): ... here.
* expr.c (parse_has_include): Don't cpp_get_token if SEEN_EOL ().
* c-c++-common/cpp/pr88974.c: New test.
--- libcpp/directives.c.jj 2019-01-24 19:08:45.0 +0100
+++ libcpp/directives.c 2019-01-25 21:31:22.755442351 +0100
@@ -204,8 +204,6 @@ static const directive linemarker_dir =
do_linemarker, UC"#", 1, KANDR, IN_I
};
-#define SEEN_EOL() (pfile->cur_token[-1].type == CPP_EOF)
-
/* Skip any remaining tokens in a directive. */
static void
skip_rest_of_line (cpp_reader *pfile)
--- libcpp/internal.h.jj2019-01-24 19:08:45.0 +0100
+++ libcpp/internal.h 2019-01-25 21:33:00.339379400 +0100
@@ -593,6 +593,8 @@ struct cpp_reader
#define is_nvspace(x) IS_NVSPACE(x)
#define is_space(x)IS_SPACE_OR_NUL(x)
+#define SEEN_EOL() (pfile->cur_token[-1].type == CPP_EOF)
+
/* This table is constant if it can be initialized at compile time,
which is the case if cpp was compiled with GCC >=2.7, or another
compiler that supports C99. */
--- libcpp/expr.c.jj2019-01-24 19:08:45.147042475 +0100
+++ libcpp/expr.c 2019-01-25 21:34:22.098500546 +0100
@@ -2238,7 +2238,7 @@ parse_has_include (cpp_reader *pfile, en
XDELETEVEC (fname);
}
- if (paren && cpp_get_token (pfile)->type != CPP_CLOSE_PAREN)
+ if (paren && !SEEN_EOL () && cpp_get_token (pfile)->type != CPP_CLOSE_PAREN)
cpp_error (pfile, CPP_DL_ERROR,
"missing ')' after \"__has_include__\"");
--- gcc/testsuite/c-c++-common/cpp/pr88974.c.jj 2019-01-24 14:25:02.271100711
+0100
+++ gcc/testsuite/c-c++-common/cpp/pr88974.c2019-01-24 14:24:48.098334156
+0100
@@ -0,0 +1,6 @@
+/* PR preprocessor/88974 */
+/* { dg-do preprocess } */
+
+#if __has_include ( character" "" { target *-*-* } .-1 } */
+#endif
Jakub
[PATCH] Fix avx512{f,vl} shuffles (PR target/87214)
Hi!
The following 4 define_insn shuffle patterns don't have sufficient
conditions. As can be seen even from the way how they transform the
RTL representation into the mask, e.g.:
mask = INTVAL (operands[3]) / 2;
mask |= INTVAL (operands[5]) / 2 << 2;
mask |= (INTVAL (operands[7]) - 8) / 2 << 4;
mask |= (INTVAL (operands[9]) - 8) / 2 << 6;
operands[3] = GEN_INT (mask);
or how corresponding expander constructs the RTL representation from the mask,
e.g.:
emit_insn (gen_avx512f_shuf_64x2_1_mask
(operands[0], operands[1], operands[2],
GEN_INT (((mask >> 0) & 3) * 2),
GEN_INT (((mask >> 0) & 3) * 2 + 1),
GEN_INT (((mask >> 2) & 3) * 2),
GEN_INT (((mask >> 2) & 3) * 2 + 1),
GEN_INT (((mask >> 4) & 3) * 2 + 8),
GEN_INT (((mask >> 4) & 3) * 2 + 9),
GEN_INT (((mask >> 6) & 3) * 2 + 8),
GEN_INT (((mask >> 6) & 3) * 2 + 9),
they really require not just that there are 2 (or 4) consecutive numbers
from certain range (in the predicate), but also that the first of these
numbers is a multiple of 2 (or 4) - the least significant 1 (or 2) bits
are ignored when creating the mask for the hw instruction.
Rather than including a huge set of new predicates like
const_0_or_2_operand, const_0_2_4_or_6_operand etc., this patch just
verifies the least significant 1 (or 2) bits are zero where needed,
plus some formatting fixes.
Bootstrapped/regtested on x86_64-linux and i686-linux (on skylake-avx512),
verified both testcases FAIL without the patch, including for the second one
every single subtest in there (all those are where at least one set of pairs
or quadruples starts with a number that is not a multiple of 2 or 4).
Ok for trunk and release branches after a while?
2019-01-26 Jakub Jelinek
PR target/87214
* config/i386/sse.md
(avx512dq_shuf_64x2_1,
avx512f_shuf_64x2_1): Ensure the
first constants in pairs are multiples of 2. Formatting fixes.
(avx512vl_shuf_32x4_1,
avx512vl_shuf_32x4_1): Ensure the
first constants in each quadruple are multiples of 4. Formatting fixes.
* gcc.target/i386/avx512vl-pr87214-1.c: New test.
* gcc.target/i386/avx512vl-pr87214-2.c: New test.
--- gcc/config/i386/sse.md.jj 2019-01-25 23:46:02.156263173 +0100
+++ gcc/config/i386/sse.md 2019-01-26 00:01:24.510168638 +0100
@@ -13372,13 +13372,15 @@ (define_insn "avx512dq_shu
(vec_concat:
(match_operand:VI8F_256 1 "register_operand" "v")
(match_operand:VI8F_256 2 "nonimmediate_operand" "vm"))
- (parallel [(match_operand 3 "const_0_to_3_operand")
-(match_operand 4 "const_0_to_3_operand")
-(match_operand 5 "const_4_to_7_operand")
-(match_operand 6 "const_4_to_7_operand")])))]
+ (parallel [(match_operand 3 "const_0_to_3_operand")
+(match_operand 4 "const_0_to_3_operand")
+(match_operand 5 "const_4_to_7_operand")
+(match_operand 6 "const_4_to_7_operand")])))]
"TARGET_AVX512VL
- && (INTVAL (operands[3]) == (INTVAL (operands[4]) - 1)
- && INTVAL (operands[5]) == (INTVAL (operands[6]) - 1))"
+ && (INTVAL (operands[3]) & 1) == 0
+ && INTVAL (operands[3]) == INTVAL (operands[4]) - 1
+ && (INTVAL (operands[5]) & 1) == 0
+ && INTVAL (operands[5]) == INTVAL (operands[6]) - 1"
{
int mask;
mask = INTVAL (operands[3]) / 2;
@@ -13421,19 +13423,23 @@ (define_insn "avx512f_shuf_
(vec_concat:
(match_operand:V8FI 1 "register_operand" "v")
(match_operand:V8FI 2 "nonimmediate_operand" "vm"))
- (parallel [(match_operand 3 "const_0_to_7_operand")
-(match_operand 4 "const_0_to_7_operand")
-(match_operand 5 "const_0_to_7_operand")
-(match_operand 6 "const_0_to_7_operand")
-(match_operand 7 "const_8_to_15_operand")
-(match_operand 8 "const_8_to_15_operand")
-(match_operand 9 "const_8_to_15_operand")
-(match_operand 10 "const_8_to_15_operand")])))]
+ (parallel [(match_operand 3 "const_0_to_7_operand")
+(match_operand 4 "const_0_to_7_operand")
+(match_operand 5 "const_0_to_7_operand")
+(match_operand 6 "const_0_to_7_operand")
+(match_operand 7 "const_8_to_15_operand")
+(match_operand 8 "const_8_to_15_operand")
+(match_operand 9 "const_8_to_15_operand")
+(match_operand 10 "const_8_to_15_operand")])))]
"TARGET_AVX512F
- && (INTVAL (operands[3]) == (INTVAL (operands[4]) - 1)
- && INTVAL (operands[5]) == (INTVAL (operands[6]) - 1)
- && INTVAL (operands[7]) == (INTVAL (operands[8]) - 1)
- && INTVAL (operands[9]) == (INTVAL (operands[10]) - 1))"
+ && (INTVAL (operands[3]) &
[Ada] Fix suboptimal -gnatR3 output for discriminated record type
This is a regression present on all active branches: the output of -gnatR3 is
suboptimal in some cases, for example:
package P is
type Arr is array (Short_Integer range <>) of Integer;
type Rec (D : Short_Integer) is record
A : Arr (2 .. D);
end record;
end P;
for Rec'Object_Size use 1048544;
for Rec'Value_Size use (((#1 max 1) + 0) * 32);
for Rec'Alignment use 4;
for Rec use record
D at 0 range 0 .. 15;
A at 4 range 0 .. ??;
end record;
Tested on x86_64-suse-linux, applied on all active branches.
2019-01-26 Eric Botcazou
* gcc-interface/decl.c (annotate_value) : Use test on
the sign bit instead of on the sign of the value.
: Turn addition of negative constant into subtraction.
: Add test for degenerate case.
: Simplify.
--
Eric BotcazouIndex: gcc-interface/decl.c
===
--- gcc-interface/decl.c (revision 268182)
+++ gcc-interface/decl.c (working copy)
@@ -8250,8 +8250,9 @@ annotate_value (tree gnu_size)
{
case INTEGER_CST:
/* For negative values, build NEGATE_EXPR of the opposite. Such values
- can appear for discriminants in expressions for variants. */
- if (tree_int_cst_sgn (gnu_size) < 0)
+ can appear for discriminants in expressions for variants. Note that,
+ sizetype being unsigned, we don't directly use tree_int_cst_sgn. */
+ if (tree_int_cst_sign_bit (gnu_size))
{
tree t = wide_int_to_tree (sizetype, -wi::to_wide (gnu_size));
tcode = Negate_Expr;
@@ -8323,8 +8324,21 @@ annotate_value (tree gnu_size)
case EQ_EXPR: tcode = Eq_Expr; break;
case NE_EXPR: tcode = Ne_Expr; break;
-case MULT_EXPR:
case PLUS_EXPR:
+ /* Turn addition of negative constant into subtraction. */
+ if (TREE_CODE (TREE_OPERAND (gnu_size, 1)) == INTEGER_CST
+ && tree_int_cst_sign_bit (TREE_OPERAND (gnu_size, 1)))
+ {
+ tcode = Minus_Expr;
+ ops[0] = annotate_value (TREE_OPERAND (gnu_size, 0));
+ wide_int op1 = -wi::to_wide (TREE_OPERAND (gnu_size, 1));
+ ops[1] = annotate_value (wide_int_to_tree (sizetype, op1));
+ break;
+ }
+
+ /* ... fall through ... */
+
+case MULT_EXPR:
tcode = (TREE_CODE (gnu_size) == MULT_EXPR ? Mult_Expr : Plus_Expr);
/* Fold conversions from bytes to bits into inner operations. */
if (TREE_CODE (TREE_OPERAND (gnu_size, 1)) == INTEGER_CST
@@ -8334,6 +8348,7 @@ annotate_value (tree gnu_size)
if (TREE_CODE (inner_op) == TREE_CODE (gnu_size)
&& TREE_CODE (TREE_OPERAND (inner_op, 1)) == INTEGER_CST)
{
+ ops[0] = annotate_value (TREE_OPERAND (inner_op, 0));
tree inner_op_op1 = TREE_OPERAND (inner_op, 1);
tree gnu_size_op1 = TREE_OPERAND (gnu_size, 1);
widest_int op1;
@@ -8341,10 +8356,13 @@ annotate_value (tree gnu_size)
op1 = (wi::to_widest (inner_op_op1)
* wi::to_widest (gnu_size_op1));
else
- op1 = (wi::to_widest (inner_op_op1)
- + wi::to_widest (gnu_size_op1));
- ops[1] = UI_From_gnu (wide_int_to_tree (sizetype, op1));
- ops[0] = annotate_value (TREE_OPERAND (inner_op, 0));
+ {
+ op1 = (wi::to_widest (inner_op_op1)
+ + wi::to_widest (gnu_size_op1));
+ if (wi::zext (op1, TYPE_PRECISION (sizetype)) == 0)
+ return ops[0];
+ }
+ ops[1] = annotate_value (wide_int_to_tree (sizetype, op1));
}
}
break;
@@ -8352,18 +8370,12 @@ annotate_value (tree gnu_size)
case BIT_AND_EXPR:
tcode = Bit_And_Expr;
/* For negative values in sizetype, build NEGATE_EXPR of the opposite.
- Such values appear in expressions with aligning patterns. Note that,
- since sizetype is unsigned, we have to jump through some hoops. */
+ Such values can appear in expressions with aligning patterns. */
if (TREE_CODE (TREE_OPERAND (gnu_size, 1)) == INTEGER_CST)
{
- tree op1 = TREE_OPERAND (gnu_size, 1);
- wide_int signed_op1 = wi::sext (wi::to_wide (op1),
- TYPE_PRECISION (sizetype));
- if (wi::neg_p (signed_op1))
- {
- op1 = wide_int_to_tree (sizetype, wi::neg (signed_op1));
- ops[1] = annotate_value (build1 (NEGATE_EXPR, sizetype, op1));
- }
+ wide_int op1 = wi::sext (wi::to_wide (TREE_OPERAND (gnu_size, 1)),
+ TYPE_PRECISION (sizetype));
+ ops[1] = annotate_value (wide_int_to_tree (sizetype, op1));
}
break;
[Ada] Small tweak and formatting fixes
This does a small tweak in gnat_to_gnu with no functional changes and fixes
some formatting issues in recently added code.
Tested on x86_64-suse-linux, applied on the mainline.
2019-01-26 Eric Botcazou
* gcc-interface/trans.c (Iterate_Acc_Clause_Arg): Fix formatting.
(Acc_gnat_to_gnu): Likewise.
(Acc_Data_to_gnu): Likewise.
(Acc_Var_to_gnu): Likewise.
(Acc_Reduc_to_gnu): Likewise.
(Acc_Size_List_to_gnu): Likewise.
(Pragma_to_gnu) : Likewise.
): Likewise.
(find_loop_for): Remove default value for parameters.
* gcc-interface/trans.c (gnat_to_gnu) : Merge into...
): ...this.
--
Eric BotcazouIndex: gcc-interface/trans.c
===
--- gcc-interface/trans.c (revision 268182)
+++ gcc-interface/trans.c (working copy)
@@ -1253,7 +1253,6 @@ Identifier_to_gnu (Node_Id gnat_node, tr
return gnu_result;
}
-
/* If GNAT_EXPR is an N_Identifier, N_Integer_Literal or N_Operator_Symbol,
call FN on it. If GNAT_EXPR is an aggregate, call FN on each of its
elements. In both cases, pass GNU_EXPR and DATA as additional arguments.
@@ -1285,16 +1284,19 @@ Iterate_Acc_Clause_Arg (Node_Id gnat_exp
gnu_expr = fn (Expression (gnat_list_expr), gnu_expr, data);
}
else
- gcc_unreachable();
- break;
+ gcc_unreachable ();
+ break;
+
case N_Identifier:
case N_Integer_Literal:
case N_Operator_Symbol:
- gnu_expr = fn (gnat_expr, gnu_expr, data);
- break;
+ gnu_expr = fn (gnat_expr, gnu_expr, data);
+ break;
+
default:
- gcc_unreachable();
+ gcc_unreachable ();
}
+
return gnu_expr;
}
@@ -1329,18 +1331,19 @@ Acc_gnat_to_gnu (Node_Id gnat_node)
static tree
Acc_Data_to_gnu (Node_Id gnat_expr, tree gnu_clauses, void* data)
{
- tree gnu_clause;
- enum gomp_map_kind kind = *((enum gomp_map_kind*) data);
- gnu_clause = build_omp_clause (EXPR_LOCATION(gnu_loop_stack->last ()->stmt),
- OMP_CLAUSE_MAP);
+ const enum gomp_map_kind kind = *((enum gomp_map_kind*) data);
+ tree gnu_clause
+= build_omp_clause (EXPR_LOCATION(gnu_loop_stack->last ()->stmt),
+ OMP_CLAUSE_MAP);
gcc_assert (Nkind (gnat_expr) == N_Identifier);
- OMP_CLAUSE_DECL (gnu_clause) =
-gnat_to_gnu_entity (Entity (gnat_expr), NULL_TREE, false);
+ OMP_CLAUSE_DECL (gnu_clause)
+= gnat_to_gnu_entity (Entity (gnat_expr), NULL_TREE, false);
TREE_ADDRESSABLE (OMP_CLAUSE_DECL (gnu_clause)) = 1;
OMP_CLAUSE_SET_MAP_KIND (gnu_clause, kind);
OMP_CLAUSE_CHAIN (gnu_clause) = gnu_clauses;
+
return gnu_clause;
}
@@ -1353,13 +1356,13 @@ Acc_Data_to_gnu (Node_Id gnat_expr, tree
static tree
Acc_Var_to_gnu (Node_Id gnat_expr, tree gnu_clauses, void* data)
{
- tree gnu_clause;
- enum omp_clause_code kind = *((enum omp_clause_code*) data);
- gnu_clause =
-build_omp_clause (EXPR_LOCATION (gnu_loop_stack->last ()->stmt), kind);
+ const enum omp_clause_code kind = *((enum omp_clause_code*) data);
+ tree gnu_clause
+= build_omp_clause (EXPR_LOCATION (gnu_loop_stack->last ()->stmt), kind);
OMP_CLAUSE_DECL (gnu_clause) = Acc_gnat_to_gnu (gnat_expr);
OMP_CLAUSE_CHAIN (gnu_clause) = gnu_clauses;
+
return gnu_clause;
}
@@ -1372,13 +1375,15 @@ Acc_Var_to_gnu (Node_Id gnat_expr, tree
static tree
Acc_Reduc_Var_to_gnu (Node_Id gnat_expr, tree gnu_clauses, void* data)
{
- tree gnu_clause;
- tree_code code = *((tree_code*) data);
- gnu_clause = build_omp_clause (EXPR_LOCATION (gnu_loop_stack->last ()->stmt),
- OMP_CLAUSE_REDUCTION);
+ const tree_code code = *((tree_code*) data);
+ tree gnu_clause
+= build_omp_clause (EXPR_LOCATION (gnu_loop_stack->last ()->stmt),
+ OMP_CLAUSE_REDUCTION);
+
OMP_CLAUSE_DECL (gnu_clause) = Acc_gnat_to_gnu (gnat_expr);
OMP_CLAUSE_REDUCTION_CODE (gnu_clause) = code;
OMP_CLAUSE_CHAIN (gnu_clause) = gnu_clauses;
+
return gnu_clause;
}
@@ -1389,6 +1394,7 @@ static tree
Acc_Reduc_to_gnu (Node_Id gnat_expr)
{
tree gnu_clauses = NULL_TREE;
+
for (Node_Id gnat_op = First (Component_Associations (gnat_expr));
Present (gnat_op);
gnat_op = Next (gnat_op))
@@ -1421,8 +1427,9 @@ Acc_Reduc_to_gnu (Node_Id gnat_expr)
code = TRUTH_ORIF_EXPR;
break;
default:
- gcc_unreachable();
+ gcc_unreachable ();
}
+
/* Unsupported reduction operation. This should have been
caught in sem_prag.adb. */
gcc_assert (code != ERROR_MARK);
@@ -1432,6 +1439,7 @@ Acc_Reduc_to_gnu (Node_Id gnat_expr)
Acc_Reduc_Var_to_gnu,
&code);
}
+
return gnu_clauses;
}
@@ -1461,15 +1469,15 @@ Acc_Size_Expr_to_gnu (Node_Id gnat_expr,
static tree
Acc_Size_List_to_gnu (Node_Id gnat_expr)
{
- tree gnu_clause;
- tree gnu_list;
+ tree gnu_clause
+= build_omp_clause (EXPR_LOCATION (gnu_loop_stack->last ()->stmt),
+ OMP_CLAUSE_TILE);
+ tree gnu_list = Iterate_Acc_Clause_Arg (gnat_expr, NULL_TR
Re: PING [PATCH] tighten up -Wbuiltin-declaration-mismatch (PR 86125, 88886, 86308)
On Sat, Jan 26, 2019 at 01:25:04AM +, Joseph Myers wrote: > It's also broken the build of the glibc testsuite, e.g.: > > ../time/time.h:88:15: error: mismatch in argument 1 type of built-in function > 'strftime'; expected 'char *' [-Werror=builtin-declaration-mismatch] >88 | extern size_t strftime (char *__restrict __s, size_t __maxsize, > > (presence or absence of qualifiers on a parameter is not part of the > function type and should not be compared here). There are several further issues, even after fixing the toplevel qualifiers on arguments as well as return type + fixing up the testcases, there is another problem, the code has the magic handling only for fileptr_type_node, but we actually need handling for all builtin_structptr_types struct types, otherwise e.g. for strftime we warn that the last argument should not be const struct tm *, but const void *, when it actually should be const struct tm *. Working on it. Jakub
Re: PING [PATCH] tighten up -Wbuiltin-declaration-mismatch (PR 86125, 88886, 86308)
On Sat, Jan 26, 2019 at 01:35:05PM +0100, Jakub Jelinek wrote:
> On Sat, Jan 26, 2019 at 01:25:04AM +, Joseph Myers wrote:
> > It's also broken the build of the glibc testsuite, e.g.:
> >
> > ../time/time.h:88:15: error: mismatch in argument 1 type of built-in
> > function 'strftime'; expected 'char *'
> > [-Werror=builtin-declaration-mismatch]
> >88 | extern size_t strftime (char *__restrict __s, size_t __maxsize,
> >
> > (presence or absence of qualifiers on a parameter is not part of the
> > function type and should not be compared here).
>
> There are several further issues, even after fixing the toplevel qualifiers on
> arguments as well as return type + fixing up the testcases, there is another
> problem, the code has the magic handling only for fileptr_type_node, but we
> actually need handling for all builtin_structptr_types struct types,
> otherwise e.g. for strftime we warn that the last argument should not be
> const struct tm *, but const void *, when it actually should be const struct
> tm *.
It is actually worse than that, because unlike C++, in C fileptr_type_node
is a mere void * and const_tm_ptr_type_node a mere const_ptr_type_node.
So, on
/* PR c/86125 */
/* { dg-do compile } */
/* { dg-options "-Wbuiltin-declaration-mismatch -Wextra
-Wno-ignored-qualifiers" } */
typedef __SIZE_TYPE__ size_t;
struct FILE;
struct tm;
struct fenv_t;
struct fexcept_t;
typedef struct FILE FILE;
typedef struct fenv_t fenv_t;
typedef struct fexcept_t fexcept_t;
typedef const int cint;
size_t strftime (char *__restrict, const size_t, const char *__restrict,
/* { dg-bogus "mismatch in argument 1 type of built-in function" } */
const struct tm *__restrict) __attribute__((nothrow));
int fprintf (struct FILE *, const char *const, ...);
/* { dg-bogus "mismatch in argument 2 type of built-in function" } */
cint putc (int, struct FILE *);
/* { dg-bogus "mismatch in return type of built-in function" } */
cint fegetenv (fenv_t *);
/* { dg-bogus "mismatch in argument 1 type of built-in function" } */
cint fesetenv (const fenv_t *);
/* { dg-bogus "mismatch in return type of built-in function" } */
int fegetexceptflag (fexcept_t *, const int);
/* { dg-bogus "mismatch in argument 1 type of built-in function" } */
int fesetexceptflag (const fexcept_t *, const int);
/* { dg-bogus "mismatch in argument 1 type of built-in function" } */
we get among all the other bogus warnings
Wbuiltin-declaration-mismatch-11.c:21:5: warning: mismatch in argument 1 type
of built-in function ‘fegetexceptflag’; expected ‘struct FILE *’
[-Wbuiltin-declaration-mismatch]
21 | int fegetexceptflag (fexcept_t *, const int); /* { dg-bogus
"mismatch in argument 1 type of built-in function" } */
| ^~~
Suggesting one uses struct FILE * argument to fegetexceptflag is not a very
good suggestion.
Jakub
[PATCH, libphobos] Committed merge upstream phobos and druntime
Hi,
This patch merges platform fixes for both druntime and phobos from upstream.
Bootstrapped and regression tested on x86_64-linux-gnu.
Committed to trunk as r268293.
--
Iain
---
diff --git a/libphobos/libdruntime/MERGE b/libphobos/libdruntime/MERGE
new file mode 100644
index 000..b98e0ed6c16
--- /dev/null
+++ b/libphobos/libdruntime/MERGE
@@ -0,0 +1,4 @@
+f2db21937e650553066c30f1a9d5a7d08a1b3573
+
+The first line of this file holds the git revision number of the last
+merge done from the dlang/druntime repository.
diff --git a/libphobos/libdruntime/core/stdc/limits.d b/libphobos/libdruntime/core/stdc/limits.d
index 3ed167216ce..3ab7ed1e4f7 100644
--- a/libphobos/libdruntime/core/stdc/limits.d
+++ b/libphobos/libdruntime/core/stdc/limits.d
@@ -14,6 +14,15 @@
module core.stdc.limits;
+version (OSX)
+version = Darwin;
+else version (iOS)
+version = Darwin;
+else version (TVOS)
+version = Darwin;
+else version (WatchOS)
+version = Darwin;
+
private import core.stdc.config;
extern (C):
@@ -21,6 +30,10 @@ extern (C):
nothrow:
@nogc:
+//
+// Numerical limits
+//
+
///
enum CHAR_BIT = 8;
///
@@ -59,3 +72,113 @@ enum LLONG_MIN = long.min;
enum LLONG_MAX = long.max;
///
enum ULLONG_MAX = ulong.max;
+
+//
+// File system limits
+//
+
+version (Darwin)
+{
+///
+enum MAX_CANON = 1024;
+///
+enum MAX_INPUT = 1024;
+///
+enum NAME_MAX = 255;
+///
+enum PATH_MAX = 1024;
+///
+enum PIPE_BUF = 512;
+}
+
+version (DragonFlyBSD)
+{
+///
+enum MAX_CANON = 255;
+///
+enum MAX_INPUT = 255;
+///
+enum NAME_MAX = 255;
+///
+enum PATH_MAX = 1024;
+///
+enum PIPE_BUF = 512;
+}
+else version (FreeBSD)
+{
+///
+enum MAX_CANON = 255;
+///
+enum MAX_INPUT = 255;
+///
+enum NAME_MAX = 255;
+///
+enum PATH_MAX = 1024;
+///
+enum PIPE_BUF = 512;
+}
+else version (linux)
+{
+///
+enum MAX_CANON = 255;
+///
+enum MAX_INPUT = 255;
+///
+enum NAME_MAX = 255;
+///
+enum PATH_MAX = 4096;
+///
+enum PIPE_BUF = 4096;
+}
+else version (NetBSD)
+{
+///
+enum MAX_CANON = 255;
+///
+enum MAX_INPUT = 255;
+///
+enum NAME_MAX = 511;
+///
+enum PATH_MAX = 1024;
+///
+enum PIPE_BUF = 512;
+}
+else version (OpenBSD)
+{
+///
+enum MAX_CANON = 255;
+///
+enum MAX_INPUT = 255;
+///
+enum NAME_MAX = 255;
+///
+enum PATH_MAX = 1024;
+///
+enum PIPE_BUF = 512;
+}
+else version (Solaris)
+{
+///
+enum MAX_CANON = 256;
+///
+enum MAX_INPUT = 512;
+///
+enum NAME_MAX = 255;
+///
+enum PATH_MAX = 1024;
+///
+enum PIPE_BUF = 5120;
+}
+else version (Windows)
+{
+///
+enum MAX_CANON = 256;
+///
+enum MAX_INPUT = 256;
+///
+enum NAME_MAX = 256;
+///
+enum PATH_MAX = 260;
+///
+enum PIPE_BUF = 5120;
+}
diff --git a/libphobos/libdruntime/core/sys/posix/aio.d b/libphobos/libdruntime/core/sys/posix/aio.d
index 8300d920ca9..be36a03e229 100644
--- a/libphobos/libdruntime/core/sys/posix/aio.d
+++ b/libphobos/libdruntime/core/sys/posix/aio.d
@@ -11,6 +11,15 @@ module core.sys.posix.aio;
private import core.sys.posix.signal;
private import core.sys.posix.sys.types;
+version (OSX)
+version = Darwin;
+else version (iOS)
+version = Darwin;
+else version (TVOS)
+version = Darwin;
+else version (WatchOS)
+version = Darwin;
+
version (Posix):
extern (C):
@@ -63,7 +72,7 @@ version (CRuntime_Glibc)
}
}
}
-else version (OSX)
+else version (Darwin)
{
struct aiocb
{
@@ -171,7 +180,7 @@ version (CRuntime_Glibc)
AIO_ALLDONE
}
}
-else version (OSX)
+else version (Darwin)
{
enum
{
@@ -209,7 +218,7 @@ version (CRuntime_Glibc)
LIO_NOP
}
}
-else version (OSX)
+else version (Darwin)
{
enum
{
@@ -246,7 +255,7 @@ version (CRuntime_Glibc)
LIO_NOWAIT
}
}
-else version (OSX)
+else version (Darwin)
{
enum
{
diff --git a/libphobos/libdruntime/rt/arrayassign.d b/libphobos/libdruntime/rt/arrayassign.d
index a128eaec053..389ff92ef78 100644
--- a/libphobos/libdruntime/rt/arrayassign.d
+++ b/libphobos/libdruntime/rt/arrayassign.d
@@ -30,7 +30,12 @@ extern (C) void[] _d_arrayassign(TypeInfo ti, void[] from, void[] to)
// Need a temporary buffer tmp[] big enough to hold one element
void[16] buf = void;
-void* ptmp = (elementSize > buf.sizeof) ? alloca(elementSize) : buf.ptr;
+void* ptmp = (elementSize > buf.sizeof) ? malloc(elementSize) : buf.ptr;
+scope (exit)
+{
+if (ptmp != buf.ptr)
+free(ptmp);
+}
return _d_arrayassign_l(ti
[C PATCH] Fix PR86125 fallout
Hi!
Here is an untested patch that should fix all of that, ok for trunk
if it passes bootstrap/regtest on {x86_64,i686}-linux?
Notes:
1) seems the C++ FE is even stricter and uses the
builtin_structptr_types[x].str string to verify the pointed type
has the right TYPE_NAME; is that something we want to require
for C also? That would mean we'd warn about
Wbuiltin-declaration-mismatch-6.c etc. too, because it uses:
struct StdioFile;
int fprintf (struct StdioFile*, const char*, ...);
If it was
typedef struct StdioFile FILE;
int fprintf (FILE*, const char*, ...);
that would be accepted then. Also, unlike C++, C has struct tags vs.
typedef tags as separate namespaces, so we'd need to either handle
it specially for struct tm (where the standard prototype is
const struct tm *, not const tm *) vs. the rest, or accept struct
as well as typedef names equal to builtin_structptr_types[x].str,
or don't do anything here (I didn't want to be even stricter than
Martin's patch)
2) it accepts any kind of pointed type and just requires it is the same
later on, so it accepts e.g.
struct StdioFile;
typedef struct StdioFile FILE;
int fprintf (const FILE *, const char *, ...);
and then requires those pointers to be the same in all cases.
Shall we verify the qualifiers on the pointed type before we accept
it into last_structptr_types? If yes, right now it would emit
weird diagnostics (request that the type would be say const void *
instead of struct tm *)
3) for fexcept_t and fenv_t, there are actually 2 types for each,
const {fexcept,fenv}_t * vs. {fexcept,fenv}_t *. No verification
is done that the TYPE_MAIN_VARIANT is the same between both if both
are seen. This only makes sense if 2) is implemented, and would
probably work if both 1) and 2) are implemented without anything
further.
Not planning to work on these myself, all I want to fix is the breakage.
2019-01-26 Jakub Jelinek
PR c/86125
* c-decl.c (last_fileptr_type): Remove.
(last_structptr_types): New variable.
(match_builtin_function_types): Compare TYPE_MAIN_VARIANT of
{old,new}rettype instead of the types themselves. Assert
last_structptr_types array has the same number of elements
as builtin_structptr_types array. Use TYPE_MAIN_VARIANT for
argument oldtype and newtype. Instead of handling
just fileptr_type_node specially, handle all builtin_structptr_types
pointer nodes. Formatting fix.
* c-common.c (c_common_nodes_and_builtins): Build type variants for
builtin_structptr_types types even for C.
* gcc.dg/Wbuiltin-declaration-mismatch-7.c: Guard testcase for
lp64, ilp32 and llp64 only.
(fputs): Use unsigned long long instead of size_t for return type.
(vfprintf, vfscanf): Accept arbitrary target specific type for
va_list.
--- gcc/c/c-decl.c.jj 2019-01-25 23:46:06.121198286 +0100
+++ gcc/c/c-decl.c 2019-01-26 15:34:02.749450800 +0100
@@ -1632,13 +1632,13 @@ c_bind (location_t loc, tree decl, bool
}
-/* Stores the first FILE* argument type (whatever it is) seen in
- a declaration of a file I/O built-in. Subsequent declarations
- of such built-ins are expected to refer to it rather than to
- fileptr_type_node which is just void* (or to any other type).
+/* Stores the first FILE*, const struct tm* etc. argument type (whatever it
+ is) seen in a declaration of a file I/O etc. built-in. Subsequent
+ declarations of such built-ins are expected to refer to it rather than to
+ fileptr_type_node etc. which is just void* (or to any other type).
Used only by match_builtin_function_types. */
-static GTY(()) tree last_fileptr_type;
+static GTY(()) tree last_structptr_types[6];
/* Subroutine of compare_decls. Allow harmless mismatches in return
and argument types provided that the type modes match. Set *STRICT
@@ -1660,13 +1660,18 @@ match_builtin_function_types (tree newty
if (TYPE_MODE (oldrettype) != TYPE_MODE (newrettype))
return NULL_TREE;
- if (!comptypes (oldrettype, newrettype))
+ if (!comptypes (TYPE_MAIN_VARIANT (oldrettype),
+ TYPE_MAIN_VARIANT (newrettype)))
*strict = oldrettype;
tree oldargs = TYPE_ARG_TYPES (oldtype);
tree newargs = TYPE_ARG_TYPES (newtype);
tree tryargs = newargs;
+ gcc_checking_assert ((sizeof (last_structptr_types)
+ / sizeof (last_structptr_types[0]))
+ == (sizeof (builtin_structptr_types)
+ / sizeof (builtin_structptr_types[0])));
for (unsigned i = 1; oldargs || newargs; ++i)
{
if (!oldargs
@@ -1675,8 +1680,8 @@ match_builtin_function_types (tree newty
|| !TREE_VALUE (newargs))
return NULL_TREE;
- tree oldtype = TREE_VALUE (oldargs);
- tree newtype = TREE_VALUE (newargs);
+ tree oldtype = TYPE_MAIN_VARIAN
Re: testsuite dg-directives glitches
I have committed the following patch to the gcc-7-branch as r268294 after a
regtest.
Manfred, could you please check with your script that I did not miss
some test in the gcc-7 and gcc-8 branches?
TIA
Dominique
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 268292)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,15 @@
+2019-01-26 Manfred Schwarb
+
+ * gfortran.dg/array_function_5.f90
+ * gfortran.dg/class_66.f90
+ * gfortran.dg/dec_structure_12.f90
+ * gfortran.dg/dec_structure_14.f90
+ * gfortran.dg/dec_structure_15.f90
+ * gfortran.dg/extends_11.f03
+ * gfortran.dg/pr58968.f
+ * gfortran.dg/pr78259.f90
+ * gfortran.dg/debug/pr35154-stabs.f
+
2019-01-24 Uroš Bizjak
PR target/88998
diff -up ../7_clean/gcc/testsuite/gfortran.dg/array_function_5.f90
gcc/testsuite/gfortran.dg/array_function_5.f90
--- ../7_clean/gcc/testsuite/gfortran.dg/array_function_5.f90 2017-04-21
16:03:35.0 +0200
+++ gcc/testsuite/gfortran.dg/array_function_5.f90 2019-01-25
12:27:40.0 +0100
@@ -1,4 +1,4 @@
-! { dg-do run }
+! { dg-do run }
! PR41278 internal compiler error related to matmul and transpose
! Test case prepared by Jerry DeLisle
! Original test case by Chris
diff -up ../7_clean/gcc/testsuite/gfortran.dg/class_66.f90
gcc/testsuite/gfortran.dg/class_66.f90
--- ../7_clean/gcc/testsuite/gfortran.dg/class_66.f90 2017-12-07
12:49:38.0 +0100
+++ gcc/testsuite/gfortran.dg/class_66.f90 2019-01-25 12:28:06.0
+0100
@@ -1,4 +1,4 @@
-! { dg- do run }
+! { dg-do run }
!
! Test the fix for PR78641 in which an ICE occured on assignment
! of a class array constructor to a derived type array.
diff -up ../7_clean/gcc/testsuite/gfortran.dg/dec_structure_12.f90
gcc/testsuite/gfortran.dg/dec_structure_12.f90
--- ../7_clean/gcc/testsuite/gfortran.dg/dec_structure_12.f90 2017-04-21
16:03:35.0 +0200
+++ gcc/testsuite/gfortran.dg/dec_structure_12.f90 2019-01-25
12:28:58.0 +0100
@@ -1,4 +1,4 @@
-! { dg-do "compile" }
+! { dg-do compile }
! { dg-options "-fdec-structure" }
!
! Test a regression where multiple anonymous structures failed to
diff -up ../7_clean/gcc/testsuite/gfortran.dg/dec_structure_14.f90
gcc/testsuite/gfortran.dg/dec_structure_14.f90
--- ../7_clean/gcc/testsuite/gfortran.dg/dec_structure_14.f90 2017-04-21
16:03:32.0 +0200
+++ gcc/testsuite/gfortran.dg/dec_structure_14.f90 2019-01-25
12:29:10.0 +0100
@@ -1,4 +1,4 @@
- ! { dg-do "compile" }
+ ! { dg-do compile }
! { dg-options "-fdec-structure" }
!
! Test that structures inside a common block do not require the
diff -up ../7_clean/gcc/testsuite/gfortran.dg/dec_structure_15.f90
gcc/testsuite/gfortran.dg/dec_structure_15.f90
--- ../7_clean/gcc/testsuite/gfortran.dg/dec_structure_15.f90 2017-04-21
16:03:29.0 +0200
+++ gcc/testsuite/gfortran.dg/dec_structure_15.f90 2019-01-25
12:29:23.0 +0100
@@ -1,4 +1,4 @@
-! { dg-do "compile" }
+! { dg-do compile }
! { dg-options "" }
!
! PR fortran/77584
diff -up ../7_clean/gcc/testsuite/gfortran.dg/extends_11.f03
gcc/testsuite/gfortran.dg/extends_11.f03
--- ../7_clean/gcc/testsuite/gfortran.dg/extends_11.f03 2017-04-21
16:03:35.0 +0200
+++ gcc/testsuite/gfortran.dg/extends_11.f032019-01-25 12:29:59.0
+0100
@@ -37,4 +37,4 @@
recruit%service%education%person%ss = 9
end
-! { dg-final { scan-tree-dump-times "
+recruit\\.service\\.education\\.person\\.ss =" 8 "original"} }
+! { dg-final { scan-tree-dump-times "
+recruit\\.service\\.education\\.person\\.ss =" 8 "original" } }
diff -up ../7_clean/gcc/testsuite/gfortran.dg/pr58968.f
gcc/testsuite/gfortran.dg/pr58968.f
--- ../7_clean/gcc/testsuite/gfortran.dg/pr58968.f 2017-04-21
16:03:35.0 +0200
+++ gcc/testsuite/gfortran.dg/pr58968.f 2019-01-25 12:30:29.0 +0100
@@ -1,5 +1,5 @@
C PR rtl-optimization/58968.f
-C { dg-do compile { target powerpc*-*-*} }
+C { dg-do compile { target powerpc*-*-* } }
C { dg-options "-mcpu=power7 -O3 -w -ffast-math -funroll-loops" }
SUBROUTINE MAKTABS(IW,SOME,LBOX1,LBOX2,LBOX3,NSPACE,NA,NB,
*LBST,X,
diff -up ../7_clean/gcc/testsuite/gfortran.dg/pr78259.f90
gcc/testsuite/gfortran.dg/pr78259.f90
--- ../7_clean/gcc/testsuite/gfortran.dg/pr78259.f902017-04-21
16:03:34.0 +0200
+++ gcc/testsuite/gfortran.dg/pr78259.f90 2019-01-25 12:31:01.0
+0100
@@ -1,4 +1,4 @@
-! { dg-do "compile" }
+! { dg-do compile }
! { dg-options "-fdec-structure" }
!
! PR fortran/78259
--- ../7_clean/gcc/testsuite/gfortran.dg/debug/pr35154-stabs.f 2017-04-21
16:03:30.0 +0200
+++ gcc/testsuite/gfortran.dg/debug/pr35154-stabs.f 2019-01-25
12:28:37.0 +0100
@@ -1,7 +1,7 @@
C Test program for common block debugging. G. Helffrich 11 July 2004.
C { dg-
Fix for gcc-7-branch/gcc/testsuite/gfortran.dg/pr51434.f90
Committed as obvious at revision r268295
2019-01-26 Dominique d'Humieres
PR fortran/85579
* gfortran.dg/pr51434.f90: Fix the TRANSFER argument.
--- ../7_clean/gcc/testsuite/gfortran.dg/pr51434.f902018-03-10
01:18:34.0 +0100
+++ gcc/testsuite/gfortran.dg/pr51434.f90 2019-01-26 16:18:32.0
+0100
@@ -6,7 +6,7 @@ module foo
character(len=1), parameter :: s(n) = 'a'
type :: a
integer :: m = n
- character(len=1):: t(n) = transfer('abcde ', s)
+ character(len=1):: t(n) = transfer('abcde', s)
end type a
end module foo
Dominique
[Ada] Fix wrong assignment of overaligned array component
This is a regression present on all active branches: under a specific set of
circumstances, the compiler generate wrong code for the assignment of an array
component of a record type, when the nominal subtype of the component is an
array type with an alignment clause that specifies a larger alignment than the
natural one.
Tested on x86_64-suse-linux, applied on all active branches.
2019-01-26 Eric Botcazou
* gcc-interface/trans.c (gnat_to_gnu) : Use
DECL_SIZE_UNIT instead of TYPE_SIZE_UNIT for the size to be assigned
by a call to memset if the LHS is a DECL.
2019-01-26 Eric Botcazou
* gnat.dg/array34.adb: New test.
--
Eric BotcazouIndex: gcc-interface/trans.c
===
--- gcc-interface/trans.c (revision 335507)
+++ gcc-interface/trans.c (revision 335508)
@@ -7754,12 +7754,17 @@ gnat_to_gnu (Node_Id gnat_node)
= real_zerop (gnu_rhs)
? integer_zero_node
: fold_convert (integer_type_node, gnu_rhs);
- tree to = gnu_lhs;
- tree type = TREE_TYPE (to);
- tree size
- = SUBSTITUTE_PLACEHOLDER_IN_EXPR (TYPE_SIZE_UNIT (type), to);
- tree to_ptr = build_fold_addr_expr (to);
+ tree dest = build_fold_addr_expr (gnu_lhs);
tree t = builtin_decl_explicit (BUILT_IN_MEMSET);
+ /* Be extra careful not to write too much data. */
+ tree size;
+ if (TREE_CODE (gnu_lhs) == COMPONENT_REF)
+ size = DECL_SIZE_UNIT (TREE_OPERAND (gnu_lhs, 1));
+ else if (DECL_P (gnu_lhs))
+ size = DECL_SIZE_UNIT (gnu_lhs);
+ else
+ size = TYPE_SIZE_UNIT (TREE_TYPE (gnu_lhs));
+ size = SUBSTITUTE_PLACEHOLDER_IN_EXPR (size, gnu_lhs);
if (TREE_CODE (value) == INTEGER_CST && !integer_zerop (value))
{
tree mask
@@ -7767,7 +7772,7 @@ gnat_to_gnu (Node_Id gnat_node)
((HOST_WIDE_INT) 1 << BITS_PER_UNIT) - 1);
value = int_const_binop (BIT_AND_EXPR, value, mask);
}
- gnu_result = build_call_expr (t, 3, to_ptr, value, size);
+ gnu_result = build_call_expr (t, 3, dest, value, size);
}
/* Otherwise build a regular assignment. */
-- { dg-do run }
procedure Array34 is
type Arr is array (1 .. 6) of Short_Short_Integer;
for Arr'Alignment use 4;
type Rec is record
A : Arr;
B: Short_Integer;
end record;
pragma Pack (Rec);
R : Rec;
begin
R.B := 31415;
R.A := (others => 0);
if R.B /= 31415 then
raise Program_Error;
end if;
end;
Re: [PATCH] Fix PR87295
On Fri, Jan 25, 2019 at 7:57 AM Richard Biener wrote: > > The following fixes an ICE with -flto -ffat-lto-objects > -fdebug-types-section -g where optimize_external_refs does not > expect to see DW_AT_signature as made "local" by build_abbrev_table(sic!). > > This is because we run optimize_external_refs twice in this setup. > > The fix is to make the second run not pick up "local" DW_AT_signature > as external. Alternatively build_abbrev_table could be adjusted > to not keep those as DW_AT_signature. It's not even clear to me > whether a DW_AT_signature as we output it is valid DWARF ... > to quote non-LTO -g: > > <1><1d>: Abbrev Number: 13 (DW_TAG_structure_type) > <1e> DW_AT_name: (indirect string, offset: 0x8b): > integral_constant > <22> DW_AT_signature : <0x5d> Yes, that seems pretty clearly wrong. It doesn't make sense for DW_AT_signature to be a local reference; it should only have DW_FORM_ref_sig8. > <26> DW_AT_declaration : 1 > <26> DW_AT_sibling : <0x48> > ... > <1><5d>: Abbrev Number: 16 (DW_TAG_structure_type) > <5e> DW_AT_name: (indirect string, offset: 0x8b): > integral_constant > <62> DW_AT_signature : signature: 0x1f6a4ae7cc5a362e > <6a> DW_AT_declaration : 1 > <6a> DW_AT_sibling : <0x7b> And there's no reason to have two skeleton DIEs for the same type. > Of course the main "issue" is that copy_unworthy_types > duplicated this parent into 1d and 5d in the first place > (but that's a pure optimization issue?). Indeed. > Not doing that > would have avoided the situation in PR87295. But then > why should optimize_external_refs_1 have this special > code handling DW_AT_signature in the first place if this > was not intended... (so even better, kill that and the > build_abbrev_table optimization and fix copy_unworthy_types?) The point of optimize_external_refs_1 is to remember when we've seen a skeleton DIE so we can refer to it from other DIEs in the same unit rather than use DW_FORM_ref_sig8. The problem is just that we get two skeleton DIEs so we wrongly change one to refer to the other. One possibility would be to suppress the local reference optimization for DW_AT_signature, but avoiding the redundant skeleton should fix the problem and also save space. > Oh, and insert rants of -fdebug-types-section not being > used by anybody. Jakub, what's your thinking on -fdebug-types-section these days? Jason
Re: [PATCH] Handle timeout warnings in dg-extract-results
Hi Christophe, > On 23 Jan 2019, at 13:16, Christophe Lyon wrote: > dg-extract-results currently moves lines like > WARNING: program timed out > at the end of each .exp section when it generates .sum files. > > This is because it sorts its output based on the 2nd field, which is > normally the testname as in: > FAIL: gcc.c-torture/execute/20020129-1.c -O2 -flto > -fno-use-linker-plugin -flto-partition=none execution test > > As you can notice 'program' comes after > gcc.c-torture/execute/20020129-1.c alphabetically, and generally after > most (all?) GCC testnames. > > This is a bit of a pain when trying to handle transient test failures > because you can no longer match such a WARNING line to its FAIL > counterpart. > > The attached patch changes this behavior by replacing the line > WARNING: program timed out > with > WARNING: gcc.c-torture/execute/20020129-1.c -O2 -flto > -fno-use-linker-plugin -flto-partition=none execution test program > timed out > > The effect is that this line will now appear immediately above the > FAIL: gcc.c-torture/execute/20020129-1.c -O2 -flto > -fno-use-linker-plugin -flto-partition=none execution test > so that it's easier to match them. > > > I'm not sure how much people depend on the .sum format, I also > considered emitting > WARNING: program timed out gcc.c-torture/execute/20020129-1.c -O2 > -flto -fno-use-linker-plugin -flto-partition=none execution test > > I also restricted the patch to handling only 'program timed out' > cases, to avoid breaking other things. > > I considered fixing this in Dejagnu, but it seemed more complicated, > and would delay adoption in GCC anyway. > > What do people think about this? It seems a good idea (for those of us with targets prone to timeout issues). I’m going to give it a try on Darwin. Iain > > Thanks, > > Christophe >
[patch, libgfortran, committed] PR89020
Committed as simple and obvious. (With a ChangeLog Bobble fixed)
Regression tested on x86_64.
Committed r268301
M libgfortran/ChangeLog
M libgfortran/io/close.c
Regards,
Jerry
2019-01-26 Jerry DeLisle
PR libfortran/89020
* io/close.c (st_close): Generate error if calls to 'remove'
return an error.
diff --git a/libgfortran/io/close.c b/libgfortran/io/close.c
index cbcbf4e71a1..2b35e49c9cc 100644
--- a/libgfortran/io/close.c
+++ b/libgfortran/io/close.c
@@ -99,7 +99,11 @@ st_close (st_parameter_close *clp)
else
{
#if HAVE_UNLINK_OPEN_FILE
- remove (u->filename);
+
+ if (remove (u->filename))
+ generate_error (&clp->common, LIBERROR_OS,
+ "File cannot be deleted, possibly in use by"
+ " another process");
#else
path = strdup (u->filename);
#endif
@@ -112,7 +116,10 @@ st_close (st_parameter_close *clp)
#if !HAVE_UNLINK_OPEN_FILE
if (path != NULL)
{
- remove (path);
+ if (remove (u->filename))
+ generate_error (&clp->common, LIBERROR_OS,
+ "File cannot be deleted, possibly in use by"
+ " another process");
free (path);
}
#endif
Re: [PR fortran/57553, patch] - bad error message for invalid use of STORAGE_SIZE
Committed as Revision: 268303 URL: https://gcc.gnu.org/viewcvs?rev=268303&root=gcc&view=rev Log: 2019-01-26 Harald Anlauf PR fortran/57553 * expr.c (check_inquiry): Add list of inquiry functions allowed in constant expressions for F2008+. 2019-01-26 Harald Anlauf PR fortran/57553 * gfortran.dg/pr57553.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr57553.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog Thanks for the review and support. Harald P.S.: this was my first actual commit to gcc. On 01/24/19 23:28, Thomas Koenig wrote: > Hi Harald, > >> OK for trunk? > > OK. Also not likely to cause a regression, so I think this is quite > fine for now. > > Regards > > Thomas >
[PATCH PR d/89042] Committed fix for ICE when compiling void initialized enums
Hi, This patch changes an assertion into an early return condition, fixing PR d/89042. Bootstrapped and regression tested on x86_64-linux-gnu. Committed to trunk as r268304. -- Iain --- gcc/d/ChangeLog: 2019-01-26 Iain Buclaw PR d/89042 * decl.cc (DeclVisitor::visit(VarDeclaration)): Don't assert if handling a void initialized manifest constant. gcc/testsuite/ChangeLog: 2019-01-26 Iain Buclaw PR d/89042 * gdc.dg/pr89042a.d: New test. * gdc.dg/pr89042b.d: New test. --- diff --git a/gcc/d/decl.cc b/gcc/d/decl.cc index aba1abbf891..7edfe523d3e 100644 --- a/gcc/d/decl.cc +++ b/gcc/d/decl.cc @@ -593,8 +593,11 @@ public: if (d->isInstantiated ()) return; + /* Cannot make an expression out of a void initializer. */ + if (!d->_init || d->_init->isVoidInitializer ()) + return; + tree decl = get_symbol_decl (d); - gcc_assert (d->_init && !d->_init->isVoidInitializer ()); Expression *ie = initializerToExpression (d->_init); /* CONST_DECL was initially intended for enumerals and may be used for diff --git a/gcc/testsuite/gdc.dg/pr89042a.d b/gcc/testsuite/gdc.dg/pr89042a.d new file mode 100644 index 000..42e05aee181 --- /dev/null +++ b/gcc/testsuite/gdc.dg/pr89042a.d @@ -0,0 +1,2 @@ +// https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89042 +enum void[] a = void; diff --git a/gcc/testsuite/gdc.dg/pr89042b.d b/gcc/testsuite/gdc.dg/pr89042b.d new file mode 100644 index 000..73a1c6eff2d --- /dev/null +++ b/gcc/testsuite/gdc.dg/pr89042b.d @@ -0,0 +1,2 @@ +// https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89042 +enum void[2] a = void;
[wwwdocs] List -Wabsolute-value in gcc-9/changes.html
Hi, I'd like to propose the following hunk mentioning -Wabsolute-value in changes.html of the upcoming gcc 9. Is it OK? Thanks, Martin Index: htdocs/gcc-9/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v retrieving revision 1.36 diff -u -r1.36 changes.html --- htdocs/gcc-9/changes.html 18 Jan 2019 11:52:13 - 1.36 +++ htdocs/gcc-9/changes.html 26 Jan 2019 21:57:17 - @@ -89,6 +89,18 @@ +C + + New warnings: + + -Wabsolute-value warns when a wrong absolute value + function seems to be used or when it does not have any effect because + its argument is an unsigned type. The -Wabsolute-value + option is included in -Wextra. + + + + C++ New warnings:
Re: [wwwdocs] List -Wabsolute-value in gcc-9/changes.html
On Sat, 26 Jan 2019, Martin Jambor wrote: > I'd like to propose the following hunk mentioning -Wabsolute-value in > changes.html of the upcoming gcc 9. Is it OK? Lovely^WThanks, ok! Actually, one question: > + -Wabsolute-value warns when a wrong absolute value > + function seems to be used or when it does not have any effect because > + its argument is an unsigned type. The -Wabsolute-value > + option is included in -Wextra. What is a "wrong absolute value function"? That might be good to show by means of an example? (Also in invoke.texi, which I checked before writing this.) Gerald
Re: [Driver] Add support for -fuse-ld=lld
On Thu, Jun 23, 2016 at 09:01:30PM -0700, Davide Italiano wrote: > LLVM currently ships with a new ELF linker http://lld.llvm.org/. > I experiment a lot with gcc and lld so it would be nice if > -fuse-ld=lld is supported (considering the linker is now mature enough > to link large C/C++ applications). > > Also, IMHO, -fuse-ld should be a generic facility which accept other > linkers (as long as they follow the convention ld.), and should > also support absolute path, e.g. -fuse-ld=/usr/local/bin/ld.mylinker. > Probably outside of the scope of this patch, but I thought worth > mentioning. This can never work correctly. The many HAVE_LD_* flags are set for the linker you are configured against. Now normally GNU ld and Gold will be built from the same tree, so they will be at least mostly compatible. But for some other linker that cannot ever work. If you can choose a random linker at runtime then the linker features the compiler is built for will almost certainly not match those that linker has. You can built with --with-ld=/some/path/to/your/lld, and *that* should work fine. But -fuse-ld=/smth/random will result in randomness. Segher
Re: [wwwdocs] List -Wabsolute-value in gcc-9/changes.html
Hi, On Sat, Jan 26 2019, Gerald Pfeifer wrote: > On Sat, 26 Jan 2019, Martin Jambor wrote: >> I'd like to propose the following hunk mentioning -Wabsolute-value in >> changes.html of the upcoming gcc 9. Is it OK? > > Lovely^WThanks, ok! > > Actually, one question: > >> + -Wabsolute-value warns when a wrong absolute value >> + function seems to be used or when it does not have any effect because >> + its argument is an unsigned type. The -Wabsolute-value >> + option is included in -Wextra. > > What is a "wrong absolute value function"? That might be good to > show by means of an example? (Also in invoke.texi, which I checked > before writing this.) Most usually wrong means an absolute value function for a shorter type than the one privided, such as abs when labs would be approproiate, or abs or labs when you actually need llabs. Or using normal floating-point absolute value function such as fabs for binary-coded-decimal. Or even for a complex double/float, which hitherto passed without a warning. I'm not sure how to change the wording, perhaps "...when a used absolute value function seems wrong for the type of its argument" ...? Martin
Re: [C PATCH] Fix PR86125 fallout
On Sat, Jan 26, 2019 at 04:01:13PM +0100, Jakub Jelinek wrote:
> Here is an untested patch that should fix all of that, ok for trunk
> if it passes bootstrap/regtest on {x86_64,i686}-linux?
Had to change:
-+ { dg-do compile { target { lp64 || ilp32 || llp64 } } }
++ { dg-do compile { target { { lp64 || ilp32 } || llp64 } } }
in the testcase, otherwise it passed bootstrap/regtest on both successfully.
Jakub
Re: C++ PATCH for c++/78244 - narrowing conversion in template not detected, part 2
On Fri, Jan 25, 2019 at 4:20 PM Marek Polacek wrote:
> On Fri, Jan 25, 2019 at 10:05:00AM -0500, Jason Merrill wrote:
> > On 1/24/19 7:17 PM, Marek Polacek wrote:
> > > On Wed, Jan 23, 2019 at 03:34:04PM -0500, Jason Merrill wrote:
> > > > On Wed, Jan 23, 2019 at 12:57 PM Marek Polacek
> > > > wrote:
> > > > >
> > > > > On Wed, Jan 23, 2019 at 09:00:36AM -0500, Jason Merrill wrote:
> > > > > > I was talking about digest_init, not reshape_init. digest_init
> > > > > > calls
> > > > > > convert_for_initialization.
> > > > >
> > > > > /facepalm
> > > > >
> > > > > So yes, digest_init calls convert_for_initialization which will end up
> > > > > calling perform_implicit_conversion_flags which could call
> > > > > convert_like_real
> > > > > where the narrowing warnings are given, but it doesn't, we go to this
> > > > > case:
> > > > >
> > > > >else if (processing_template_decl && conv->kind != ck_identity)
> > > > > {
> > > > >/* In a template, we are only concerned about determining the
> > > > > type of non-dependent expressions, so we do not have to
> > > > > perform the actual conversion. But for initializers, we
> > > > > need to be able to perform it at instantiation
> > > > > (or instantiate_non_dependent_expr) time. */
> > > > >expr = build1 (IMPLICIT_CONV_EXPR, type, expr);
> > > > >
> > > > > finish_decltype_type throws away the expression because it's not
> > > > > dependent, and
> > > > > only uses its type. So narrowing remains undetected. Not sure if I
> > > > > should mess
> > > > > with perform_implicit_conversion_flags.
> > > >
> > > > Let's try that; this is a situation where the comment is incorrect.
> > > > Perhaps just call check_narrowing here if appropriate, rather than go
> > > > through the whole conversion machinery.
> > >
> > > I have not been successful.
> > >
> > > First, I modified perform_implicit_conversion_flags to go the convert_like
> > > route when dealing with something non-dependent. That breaks e.g. in
> > > build_value_init:
> > > 346 /* The AGGR_INIT_EXPR tweaking below breaks in templates. */
> > > 347 gcc_assert (!processing_template_decl
> > > 348 || (SCALAR_TYPE_P (type) || TREE_CODE (type) ==
> > > ARRAY_TYPE));
> > > Even if I restrict the convert_like way for non-dependent exprs in a
> > > template
> > > for scalars, it still breaks elsewhere, e.g. constexpr-template3.C where
> > > it
> > > complains about taking the address of an rvalue.
> > >
> > > Second, I added check_narrowing to the processing_template_decl case in
> > > perform_implicit_conversion_flags. That works except it breaks
> > > constexpr-inst1.C -- we no longer get the error. That's because currently
> > > check_narrowing in finish_compound_literal calls maybe_constant_init,
> > > which
> > > calls instantiate_constexpr_fns and we get the desired diagnostic. But if
> > > I move check_narrowing to perform_implicit_conversion_flags, we no longer
> > > call it in this case -- processing_template_decl is 0 so we call
> > > convert_like
> > > but that doesn't do the trick.
> > >
> > > So, back to the patch that leaves check_narrowing in
> > > finish_compound_literal?
> >
> > That patch still needs a test for the aggregate case.
>
> Ok, this is a version with Wnarrowing16.C added.
>
> ...but we still don't warn for the TYPE_NON_AGGREGATE_CLASS case in
> finish_compound_literal, so the nightmare continues.
Alas. Are you going to keep looking at that, or would you like me to take over?
> - if (SCALAR_TYPE_P (type)
> - && !BRACE_ENCLOSED_INITIALIZER_P (compound_literal)
> + if (!BRACE_ENCLOSED_INITIALIZER_P (compound_literal)
>&& !check_narrowing (type, compound_literal, complain))
> return error_mark_node;
Does this hunk actually make a difference? It looks like
check_narrowing only does anything for arithmetic types.
OK with or without this hunk.
Jason
Re: C++ PATCH for c++/89024 - ICE with incomplete enum type
On Fri, Jan 25, 2019 at 6:22 PM Marek Polacek wrote: > > On Fri, Jan 25, 2019 at 12:14:07PM -0500, Jason Merrill wrote: > > On 1/25/19 12:09 PM, Marek Polacek wrote: > > > On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote: > > > > On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill wrote: > > > > > > > > > > On 1/24/19 2:16 PM, Marek Polacek wrote: > > > > > > This test ICEs since r159006 which added > > > > > > > > > > > > type = ENUM_UNDERLYING_TYPE (type); > > > > > > > > > > > > to type_promotes_to. In this test ENUM_UNDERLYING_TYPE is null > > > > > > because we > > > > > > haven't yet parsed '}' of the enum and the underlying type isn't > > > > > > fixed, and > > > > > > so checking TYPE_UNSIGNED crashed. > > > > > > > > > > > > I've added some checks to the test to see if the types seem to be > > > > > > OK; clang++ > > > > > > agrees. > > > > > > > > > > > > Bootstrapped/regtested on x86_64-linux, ok for trunk/8/7? > > > > > > > > > > > > 2019-01-24 Marek Polacek > > > > > > > > > > > >PR c++/89024 - ICE with incomplete enum type. > > > > > >* cvt.c (type_promotes_to): Check if prom is non-null. > > > > > > > > > > 9.6/6: An enumeration whose underlying type is not fixed is an > > > > > incomplete type from its point of declaration to immediately after the > > > > > closing } of its enum-specifier, at which point it becomes a complete > > > > > type. > > > > > > > > > > So the conversion is ill-formed. > > > > > > > > > > Jason > > > > > > > > But the conversion in the example (in > > > > decltype(__test_aux<_To1>(declval<_From1>( > > > > is in a SFINAE context, so shouldn't it gracefully fall back to the > > > > `(...)` overload? > > > > > > I think so, and clang++ and icc also compile the testcase fine (and we > > > used to > > > too, before r159006). > > > > Absolutely, the conversion being ill-formed means substitution fails, and we > > reject that candidate. I meant that we shouldn't get as far as > > type_promotes_to for an incomplete type. > > Makes sense. So here's another attempt: > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > 2019-01-25 Marek Polacek > > PR c++/89024 - ICE with incomplete enum type. > * call.c (standard_conversion): When converting an > ARITHMETIC_TYPE_P to an incomplete type, return NULL. OK. Jason
Re: [C++ PATCH] [PR87770] test partial specializations for type dependence
On Fri, Jan 25, 2019 at 9:18 PM Alexandre Oliva wrote:
> On Jan 24, 2019, Jason Merrill wrote:
>
> > The latter; you can't have a partial specialization in a function.
>
> *nod* (though not entirely reflected in the patch below, I see)
> >> Any suggestion of a good name for the inline function (or would you
> >> prefer it to be a macro?) that tests whether a decl satisfies this
> >> predicate? primary_or_partial_spec_p?
>
> > Sounds good.
>
> I was not entirely clear on what the predicate was supposed to be when I
> wrote the above. I hadn't fully realized we were testing properties of
> a template instantiation by inspecting mostly properties of the
> template, rather than of the instantiation proper. Once I realized
> that, I hesitated between introducing a function to test properties of
> the base template directly, or a function to test the instantiation for
> those properties. It wasn't clear to me that having e.g. only
> DECL_TI_TEMPLATE as an argument would be enough to test everything we
> needed: we wouldn't have the context (should be the same) or the
> template args (certainly not the same, but sharing the same depth?) of
> the instantiation we were supposed to assess to begin with.
>
> So I went with a different name that reflected more closely the test I
> implemented: instantiates_primary_template_p.
That sounds good.
> Now, maybe we're better off with something that tests the template
> rather than the instantiation, to use at other places where
> PRIMARY_TEMPLATE_P is found insufficient. If that's the case, I'll have
> to figure out whether taking just the template is enough, or whether we
> need the tinfo object or are better off taking additional arguments.
> But since that will take additional investigation and you had nodded to
> the logic that involved the args of the instantiation, I'm leaving it at
> this for now. Please let me know whether the alternate form would be
> preferred.
>
> This patch bootstrapped on x86_64- and i686-linux-gnu, and is undergoing
> regression testing ATM. Ok to install if it passes?
>
>
> for gcc/cp/ChangeLog
>
> PR c++/87770
> * pt.c (instantiates_primary_template_p): New.
> (type_dependent_expression_p): Use it.
>
> for gcc/testsuite/ChangeLog
>
> PR c++/87770
> * g++.dg/pr87770.C: New.
> ---
> gcc/cp/pt.c| 55
> +++-
> gcc/testsuite/g++.dg/pr87770.C | 11
> 2 files changed, 65 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/g++.dg/pr87770.C
>
> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> index 48c180cc13b3..d413fa81c59e 100644
> --- a/gcc/cp/pt.c
> +++ b/gcc/cp/pt.c
> @@ -400,6 +400,59 @@ template_class_depth (tree type)
>return depth;
> }
>
> +/* Return TRUE if NODE instantiates a template that has arguments of
> + its own, be it directly a primary template or indirectly through a
> + partial specializations. */
> +static inline bool
> +instantiates_primary_template_p (tree node)
> +{
> + tree tinfo;
> + if (!DECL_P (node))
> +tinfo = CLASSTYPE_TEMPLATE_INFO (node);
> + else if (DECL_LANG_SPECIFIC (node))
> +tinfo = DECL_TEMPLATE_INFO (node);
> + else
> +tinfo = NULL_TREE;
Maybe use get_template_info?
> + if (!tinfo)
> +return false;
> +
> + tree tmpl = TI_TEMPLATE (tinfo);
> + if (PRIMARY_TEMPLATE_P (tmpl))
> +return true;
> +
> + if (!DECL_TEMPLATE_SPECIALIZATION (tmpl))
> +return false;
> +
> + /* So now we know we have a specialization, but it could be a full
> + or a partial specialization. To tell which, compare the depth of
> + its template arguments with those of its context. ??? How do we
> + tell apart a partial from a full explicit specialization in a
> + non-template context? */
We don't need to tell them apart here, the caller checks if there are
any dependent template arguments.
> + tree ctxt;
> + if (!DECL_P (node))
> +ctxt = TYPE_CONTEXT (node);
> + else
> +ctxt = DECL_CONTEXT (node);
We know tmpl is a decl, so we can unconditionally take its DECL_CONTEXT.
> + tree ctinfo;
> + if (!DECL_P (ctxt))
> +ctinfo = CLASSTYPE_TEMPLATE_INFO (ctxt);
> + else if (DECL_LANG_SPECIFIC (ctxt))
> +ctinfo = DECL_TEMPLATE_INFO (ctxt);
> + else
> +ctinfo = NULL_TREE;
And you can use get_template_info here as well.
Jason
