[libcpp] Fix ICE with conditional macros (PR preprocessor/61977)
Hi!
cpp_peek_token is broken whenever it sees CPP_EOF, as it doesn't back up
the previous tokens (if any) and the CPP_EOF token, so for callers
of cpp_peek_token whenever it returns CPP_EOF it is a fatal condition,
so one really can't peek safely.
cpp_peek_token has apparently been written for the conditional macros
where it really assumes one can safely peek tokens several times.
The following patch fixes that. If no CPP_EOF is seen or it is seen on the
last token, index will be -1 and thus count - index is still count + 1
as before, but if we hit CPP_EOF earlier, we only back up tokens before
that.
Richard and Prathamesh raised this issue already some time ago:
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00895.html
but there was no follow-up on that.
Bootstrapped/regtested on powerpc64{,le}-linux and {x86_64,i686}-linux, ok
for trunk?
2015-03-31 Jakub Jelinek
PR preprocessor/61977
* lex.c (cpp_peek_token): If peektok is CPP_EOF, back it up
with all tokens peeked by the current function.
--- libcpp/lex.c.jj 2015-03-17 18:10:12.0 +0100
+++ libcpp/lex.c2015-03-31 19:39:28.207748285 +0200
@@ -2084,11 +2084,14 @@ cpp_peek_token (cpp_reader *pfile, int i
{
peektok = _cpp_lex_token (pfile);
if (peektok->type == CPP_EOF)
- return peektok;
+ {
+ index--;
+ break;
+ }
}
while (index--);
- _cpp_backup_tokens_direct (pfile, count + 1);
+ _cpp_backup_tokens_direct (pfile, count - index);
pfile->keep_tokens--;
return peektok;
--- gcc/testsuite/gcc.dg/cpp/pr61977.c.jj 2015-03-31 19:46:12.226279905
+0200
+++ gcc/testsuite/gcc.dg/cpp/pr61977.c 2015-03-31 19:46:03.638417398 +0200
@@ -0,0 +1,4 @@
+/* PR preprocessor/61977 */
+/* { dg-do preprocess } */
+
+vector
Jakub
[PATCH] Disable ppc/spu context sensitive macros for CLK_ASM preprocessing (PR preprocessor/61977)
Hi!
The context sensitive macros are inherently C/C++ specific, so trying to
expand them into anything when preprocessing assembler doesn't make any
sense to me.
Ok for trunk?
2015-04-01 Jakub Jelinek
PR preprocessor/61977
* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Don't
predefine __vector/__bool/__pixel macros nor context sensitive
macros for CLK_ASM.
* config/spu/spu-c.c (spu_cpu_cpp_builtins): Similarly.
--- gcc/config/rs6000/rs6000-c.c.jj 2015-01-09 22:00:06.0 +0100
+++ gcc/config/rs6000/rs6000-c.c2015-04-01 10:31:19.127603956 +0200
@@ -420,7 +420,7 @@ rs6000_cpu_cpp_builtins (cpp_reader *pfi
if (TARGET_FRSQRTES)
builtin_define ("__RSQRTEF__");
- if (TARGET_EXTRA_BUILTINS)
+ if (TARGET_EXTRA_BUILTINS && cpp_get_options (pfile)->lang != CLK_ASM)
{
/* Define the AltiVec syntactic elements. */
builtin_define ("__vector=__attribute__((altivec(vector__)))");
--- gcc/config/spu/spu-c.c.jj 2015-01-09 22:00:01.0 +0100
+++ gcc/config/spu/spu-c.c 2015-04-01 10:33:20.473610886 +0200
@@ -203,7 +203,8 @@ spu_cpu_cpp_builtins (struct cpp_reader
cpp_assert (pfile, "machine=spu");
if (spu_arch == PROCESSOR_CELLEDP)
cpp_define (pfile, "__SPU_EDP__");
- cpp_define (pfile, "__vector=__attribute__((__spu_vector__))");
+ if (cpp_get_options (pfile)->lang != CLK_ASM)
+cpp_define (pfile, "__vector=__attribute__((__spu_vector__))");
switch (spu_ea_model)
{
case 32:
@@ -216,7 +217,7 @@ spu_cpu_cpp_builtins (struct cpp_reader
gcc_unreachable ();
}
- if (!flag_iso)
+ if (!flag_iso && cpp_get_options (pfile)->lang != CLK_ASM)
{
/* Define this when supporting context-sensitive keywords. */
cpp_define (pfile, "__VECTOR_KEYWORD_SUPPORTED__");
Jakub
Re: [PATCH] Disable ppc/spu context sensitive macros for CLK_ASM preprocessing (PR preprocessor/61977)
On Wed, Apr 1, 2015 at 10:40 AM, Jakub Jelinek wrote: > Hi! > > The context sensitive macros are inherently C/C++ specific, so trying to > expand them into anything when preprocessing assembler doesn't make any > sense to me. Why are the -c.c cpp builtins defined at all when preprocessing assembly? Or in other words: should these (supposedly) language-dependent hooks for cpp builtins be called if the pre-processor is called stand-alone? Ciao! Steven
Re: [PATCH] Disable ppc/spu context sensitive macros for CLK_ASM preprocessing (PR preprocessor/61977)
On Wed, Apr 01, 2015 at 10:57:10AM +0200, Steven Bosscher wrote: > On Wed, Apr 1, 2015 at 10:40 AM, Jakub Jelinek wrote: > > Hi! > > > > The context sensitive macros are inherently C/C++ specific, so trying to > > expand them into anything when preprocessing assembler doesn't make any > > sense to me. > > Why are the -c.c cpp builtins defined at all when preprocessing > assembly? Or in other words: should these (supposedly) > language-dependent hooks for cpp builtins be called if the > pre-processor is called stand-alone? The preprocessor, whether invoked through cpp or gcc driver, is still the C (or C++) FE, and when it doesn't preprocess with -x assembler-with-cpp, it still preprocesses C and has to define these. Most of the macros -c.c defines are needed for assembler preprocessing too, lots of things would break if there wouldn't be on x86_64 say __x86_64__ define. My patch disables just the clearly C/C++ specific macros, I mean defining __vector to __attribute__((...)) where the definition has C/C++ syntax clearly isn't very useful in assembler, and vector contextual macro that expands sometimes to something C specific neither. Jakub
Re: [C++ Patch/RFC] PR 56100
Hi,
On 03/31/2015 09:13 PM, Jason Merrill wrote:
On 03/31/2015 01:14 PM, Paolo Carlini wrote:
Note, I took the idea of allowing for current_instantiation ()->decl !=
current_function_decl from some code prepared by Dodji for
-Wunused-local-typedefs
Let's make this a predicate function.
Indeed. Thus I'm finishing testing the below.
Thanks!
Paolo.
//
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 221795)
+++ cp/cp-tree.h(working copy)
@@ -5732,6 +5732,7 @@ extern tree get_mostly_instantiated_function_type
extern bool problematic_instantiation_changed (void);
extern void record_last_problematic_instantiation (void);
extern struct tinst_level *current_instantiation(void);
+extern bool instantiating_current_function_p(void);
extern tree maybe_get_template_decl_from_type_decl (tree);
extern int processing_template_parmlist;
extern bool dependent_type_p (tree);
Index: cp/name-lookup.c
===
--- cp/name-lookup.c(revision 221795)
+++ cp/name-lookup.c(working copy)
@@ -973,9 +973,8 @@ pushdecl_maybe_friend_1 (tree x, bool is_friend)
/* If this is a locally defined typedef in a function that
is not a template instantation, record it to implement
-Wunused-local-typedefs. */
- if (current_instantiation () == NULL
- || (current_instantiation ()->decl != current_function_decl))
- record_locally_defined_typedef (x);
+ if (!instantiating_current_function_p ())
+ record_locally_defined_typedef (x);
}
/* Multiple external decls of the same identifier ought to match.
@@ -1277,7 +1276,8 @@ pushdecl_maybe_friend_1 (tree x, bool is_friend)
old and new decls are type decls. */
|| (TREE_CODE (oldglobal) == TYPE_DECL
&& (!DECL_ARTIFICIAL (oldglobal)
- || TREE_CODE (x) == TYPE_DECL
+ || TREE_CODE (x) == TYPE_DECL)))
+ && !instantiating_current_function_p ())
/* XXX shadow warnings in outer-more namespaces */
{
if (warning_at (input_location, OPT_Wshadow,
Index: cp/pt.c
===
--- cp/pt.c (revision 221795)
+++ cp/pt.c (working copy)
@@ -20773,6 +20773,13 @@ current_instantiation (void)
return current_tinst_level;
}
+bool
+instantiating_current_function_p (void)
+{
+ return (current_instantiation ()
+ && current_instantiation ()->decl == current_function_decl);
+}
+
/* [temp.param] Check that template non-type parm TYPE is of an allowable
type. Return zero for ok, nonzero for disallowed. Issue error and
warning messages under control of COMPLAIN. */
Index: testsuite/g++.dg/warn/Wshadow-10.C
===
--- testsuite/g++.dg/warn/Wshadow-10.C (revision 0)
+++ testsuite/g++.dg/warn/Wshadow-10.C (working copy)
@@ -0,0 +1,15 @@
+// PR c++/56100
+// { dg-options "-Wshadow" }
+
+struct bar
+{
+ template
+ void baz () { int foo; }
+};
+
+int foo;
+
+int main ()
+{
+ bar ().baz ();
+}
Index: testsuite/g++.dg/warn/Wshadow-11.C
===
--- testsuite/g++.dg/warn/Wshadow-11.C (revision 0)
+++ testsuite/g++.dg/warn/Wshadow-11.C (working copy)
@@ -0,0 +1,15 @@
+// PR c++/56100
+// { dg-options "-Wshadow" }
+
+int foo; // { dg-message "shadowed declaration" }
+
+struct bar
+{
+ template
+ void baz () { int foo; } // { dg-warning "shadows a global" }
+};
+
+int main ()
+{
+ bar ().baz ();
+}
Index: testsuite/g++.dg/warn/Wshadow-8.C
===
--- testsuite/g++.dg/warn/Wshadow-8.C (revision 0)
+++ testsuite/g++.dg/warn/Wshadow-8.C (working copy)
@@ -0,0 +1,15 @@
+// PR c++/56100
+// { dg-options "-Wshadow" }
+
+template
+struct bar
+{
+ void baz () { int foo; }
+};
+
+int foo;
+
+int main ()
+{
+ bar ().baz ();
+}
Index: testsuite/g++.dg/warn/Wshadow-9.C
===
--- testsuite/g++.dg/warn/Wshadow-9.C (revision 0)
+++ testsuite/g++.dg/warn/Wshadow-9.C (working copy)
@@ -0,0 +1,15 @@
+// PR c++/56100
+// { dg-options "-Wshadow" }
+
+int foo; // { dg-message "shadowed declaration" }
+
+template
+struct bar
+{
+ void baz () { int foo; } // { dg-warning "shadows a global" }
+};
+
+int main ()
+{
+ bar ().baz ();
+}
Re: C++ PATCH for c++/65554 (ICE with user-defined initializer_list)
On Tue, Mar 31, 2015 at 03:11:24PM -0400, Jason Merrill wrote:
> On 03/31/2015 01:22 PM, Marek Polacek wrote:
> >The user *should* have been using . But responding to this
> >with an ICE isn't acceptable either.
> >
> >We do reject wholly incompatible user-defined initializer_list: finish_struct
> >requires it be a template with a pointer field followed by an integer field,
> >and in this case it is, but convert_like_real assumes that the second integer
> >field has a size_type, so it initializes the length with that type. But as
> >the
> >following testcase (which clang accepts) shows, it might be a different
> >integer
> >type, and gimplifier doesn't like any non-trivial conversion in an
> >assignment.
>
> I think I'd prefer to enforce that the second integer is size_t, not just an
> integer, so that the assumption in convert_like_real is correct.
Ok, that isn't hard to do either.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2015-04-01 Marek Polacek
PR c++/65554
* class.c (finish_struct): Require that the second field of a
user-defined initializer_list be of size type.
* g++.dg/cpp0x/initlist93.C: New test.
* g++.dg/cpp0x/initlist94.C: New test.
diff --git gcc/cp/class.c gcc/cp/class.c
index c2d4201..9f189fb 100644
--- gcc/cp/class.c
+++ gcc/cp/class.c
@@ -6891,7 +6891,7 @@ finish_struct (tree t, tree attributes)
if (f && TREE_CODE (TREE_TYPE (f)) == POINTER_TYPE)
{
f = next_initializable_field (DECL_CHAIN (f));
- if (f && TREE_CODE (TREE_TYPE (f)) == INTEGER_TYPE)
+ if (f && same_type_p (TREE_TYPE (f), size_type_node))
ok = true;
}
}
diff --git gcc/testsuite/g++.dg/cpp0x/initlist93.C
gcc/testsuite/g++.dg/cpp0x/initlist93.C
index e69de29..84a4738 100644
--- gcc/testsuite/g++.dg/cpp0x/initlist93.C
+++ gcc/testsuite/g++.dg/cpp0x/initlist93.C
@@ -0,0 +1,13 @@
+// PR c++/65554
+// { dg-do compile { target c++11 } }
+
+namespace std
+{
+template class initializer_list // { dg-error "definition of
std::initializer_list does not match" }
+{
+ int *_M_array;
+ int _M_len;
+};
+}
+
+// { dg-prune-output "compilation terminated" }
diff --git gcc/testsuite/g++.dg/cpp0x/initlist94.C
gcc/testsuite/g++.dg/cpp0x/initlist94.C
index e69de29..f83a81d 100644
--- gcc/testsuite/g++.dg/cpp0x/initlist94.C
+++ gcc/testsuite/g++.dg/cpp0x/initlist94.C
@@ -0,0 +1,13 @@
+// PR c++/65554
+// { dg-do compile { target c++11 } }
+
+typedef decltype (sizeof (int)) size_type;
+
+namespace std
+{
+template class initializer_list
+{
+ int *_M_array;
+ size_type _M_len;
+};
+}
Marek
Re: [C++ Patch/RFC] PR 56100
On Wed, Apr 01, 2015 at 12:02:36PM +0200, Paolo Carlini wrote:
> --- cp/pt.c (revision 221795)
> +++ cp/pt.c (working copy)
> @@ -20773,6 +20773,13 @@ current_instantiation (void)
>return current_tinst_level;
> }
>
> +bool
> +instantiating_current_function_p (void)
> +{
> + return (current_instantiation ()
> + && current_instantiation ()->decl == current_function_decl);
> +}
> +
This function is missing a comment.
[PATCH, AArch64] Fix PR 65624 (ICE in aarch64-linux-gnueabi crosscompiler on i686 host).
Hi,
expanding AArch64 AdvSIMD builtins, aarch64_simd_expand_builtin puts
return type and arguments types in args[SIMD_MAX_BUILTIN_ARGS] array and
indicates the last argument with SIMD_ARG_STOP. When expanding
4-argument builtin with return value, aarch64_simd_expand_builtin stores
SIMD_ARG_STOP to args[5], that overflows args since
SIMD_MAX_BUILTIN_ARGS == 5. This causes ICE for aarch64 cross-compiler
on i686 host:
$
/home/m.ostapenko/jazz64/vd49_a5x/toolchain/aarch64-tizen/libexec/gcc/aarch64-tizen-linux-gnueabi/5.0.0/cc1
-quiet ref_vqdmlsl_lane.c -quiet -dumpbase ref_vqdmlsl_lane.c
-march=armv8-a+simd -mlittle-endian -mabi=lp64 -auxbase-strip
ref_vqdmlsl_lane.gccarm.o -g -Wall -Wno-unused-variable
-Wno-unused-function -Wno-error=unused-local-typedefs -fshort-wchar
-freport-bug
// In file included from ref_vqdmlal_lane.c:27:0,
// from ref_vqdmlsl_lane.c:29:
//
/home/m.ostapenko/jazz64/vd49_a5x/toolchain/aarch64-tizen/lib/gcc/aarch64-tizen-linux-gnueabi/5.0.0/include/arm_neon.h:
In function 'exec_vqdmlsl_lane':
//
/home/m.ostapenko/jazz64/vd49_a5x/toolchain/aarch64-tizen/lib/gcc/aarch64-tizen-linux-gnueabi/5.0.0/include/arm_neon.h:19165:10:
internal compiler error: tree check: accessed operand 8 of call_expr
with 7 operands in aarch64_simd_expand_args, at
config/aarch64/aarch64-builtins.c:915
//return __builtin_aarch64_sqdmlsl_lanev4hi (__a, __b, __c, __d);
// ^
// 0x89b4948 tree_operand_check_failed(int, tree_node const*, char
const*, int, char const*)
//
>/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/tree.c:9507
// 0x8a3c9f9 tree_operand_check
//
>/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/tree.h:3346
// 0x8a3c9f9 aarch64_simd_expand_args
//
>/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/config/aarch64/aarch64-builtins.c:915
// 0x8a3c9f9 aarch64_simd_expand_builtin(int, tree_node*, rtx_def*)
This trivial patch fixes the issue.
No regressions found for aarch64-linux-gnueabi (on x86_64 and i686
hosts), ok to commit?
-Maxim
gcc/ChangeLog:
2015-04-01 Max Ostapenko
PR target/65624
* config/aarch64/aarch64-builtins.c (aarch64_simd_expand_builtin): Increase
args array size by one to avoid buffer overflow.
gcc/testsuite/ChangeLog:
2015-04-01 Max Ostapenko
PR target/65624
* gcc.target/aarch64/pr65624.c: New test.
diff --git a/gcc/config/aarch64/aarch64-builtins.c b/gcc/config/aarch64/aarch64-builtins.c
index a9b3305..8a9fff8 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -1025,7 +1025,7 @@ aarch64_simd_expand_builtin (int fcode, tree exp, rtx target)
aarch64_simd_builtin_datum *d =
&aarch64_simd_builtin_data[fcode - AARCH64_SIMD_PATTERN_START];
enum insn_code icode = d->code;
- builtin_simd_arg args[SIMD_MAX_BUILTIN_ARGS];
+ builtin_simd_arg args[SIMD_MAX_BUILTIN_ARGS + 1];
int num_args = insn_data[d->code].n_operands;
int is_void = 0;
int k;
diff --git a/gcc/testsuite/gcc.target/aarch64/pr65624.c b/gcc/testsuite/gcc.target/aarch64/pr65624.c
new file mode 100644
index 000..8eb3786
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr65624.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+
+#include
+
+int32x4_t
+foo (void)
+{
+ int32x4_t vector_int32x4;
+ int16x4_t vector3_int16x4;
+ int16x4_t vector4_int16x4;
+ static int32_t buffer_int32x4[32];
+
+ vector_int32x4 = vld1q_s32(buffer_int32x4);
+ return vqdmlsl_lane_s16(vector_int32x4, vector3_int16x4, vector4_int16x4, 0);
+}
Re: [PATCH, AArch64] Fix PR 65624 (ICE in aarch64-linux-gnueabi crosscompiler on i686 host).
Looks good to me. Indeed, I'd support this being an "obvious" fix --Alan Maxim Ostapenko wrote: Hi, expanding AArch64 AdvSIMD builtins, aarch64_simd_expand_builtin puts return type and arguments types in args[SIMD_MAX_BUILTIN_ARGS] array and indicates the last argument with SIMD_ARG_STOP. When expanding 4-argument builtin with return value, aarch64_simd_expand_builtin stores SIMD_ARG_STOP to args[5], that overflows args since SIMD_MAX_BUILTIN_ARGS == 5. This causes ICE for aarch64 cross-compiler on i686 host: $ /home/m.ostapenko/jazz64/vd49_a5x/toolchain/aarch64-tizen/libexec/gcc/aarch64-tizen-linux-gnueabi/5.0.0/cc1 -quiet ref_vqdmlsl_lane.c -quiet -dumpbase ref_vqdmlsl_lane.c -march=armv8-a+simd -mlittle-endian -mabi=lp64 -auxbase-strip ref_vqdmlsl_lane.gccarm.o -g -Wall -Wno-unused-variable -Wno-unused-function -Wno-error=unused-local-typedefs -fshort-wchar -freport-bug // In file included from ref_vqdmlal_lane.c:27:0, // from ref_vqdmlsl_lane.c:29: // /home/m.ostapenko/jazz64/vd49_a5x/toolchain/aarch64-tizen/lib/gcc/aarch64-tizen-linux-gnueabi/5.0.0/include/arm_neon.h: In function 'exec_vqdmlsl_lane': // /home/m.ostapenko/jazz64/vd49_a5x/toolchain/aarch64-tizen/lib/gcc/aarch64-tizen-linux-gnueabi/5.0.0/include/arm_neon.h:19165:10: internal compiler error: tree check: accessed operand 8 of call_expr with 7 operands in aarch64_simd_expand_args, at config/aarch64/aarch64-builtins.c:915 //return __builtin_aarch64_sqdmlsl_lanev4hi (__a, __b, __c, __d); // ^ // 0x89b4948 tree_operand_check_failed(int, tree_node const*, char const*, int, char const*) // >/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/tree.c:9507 // 0x8a3c9f9 tree_operand_check // >/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/tree.h:3346 // 0x8a3c9f9 aarch64_simd_expand_args // >/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/config/aarch64/aarch64-builtins.c:915 // 0x8a3c9f9 aarch64_simd_expand_builtin(int, tree_node*, rtx_def*) This trivial patch fixes the issue. No regressions found for aarch64-linux-gnueabi (on x86_64 and i686 hosts), ok to commit? -Maxim
[libcpp] Disable cb.line_change callbacks from within cpp_peek_token (PR preprocessor/61977)
Hi!
This is one possible way to fix another problem with the contextual macros.
When preprocessing e.g. vector at the end of line (both with -mno-altivec
and -maltivec), we cpp_peek_token at least the next token, and unfortunately
during the peek we already call pfile->cb.line_change hook. So we get
int y; \n
emitted at that point, then e.g. when vector isn't expanded, we notice the
current print.src_line is wrong for the token and thus emit
\n## 5 "pr61977-1.c"\n vector
and then when actually calling cpp_get_token_1 on the next token we emit
the newline again from another pfile->cb.line_change hook.
I believe we really should never call cb.line_change hook from within
cpp_peek_token, the tokens are re-added to lookaheads and will be processed
by _cpp_lex_token again at some point.
Below is one possible fix for that, another option is introduce another
pfile->state or pfile field for that, or another option would be to
pass some flag from cpp_peek_token down to _cpp_lex_token.
As cpp_peek_token is used very rarely, right now only in:
1) the contextual builtin macro stuff (powerpc*/spu only)
2) in __has_attribute/__has_cpp_attribute implementation
3) in genmatch build utility
the attached patch, while perhaps not the cleanest, has the advantage of not
affecting the more often used code path that might be performance critical.
Ok for trunk if it passes testing on powerpc64{,le}-linux and
{x86_64,i686}-linux?
2015-04-01 Jakub Jelinek
PR preprocessor/61977
* lex.c (cpp_peek_token): Temporarily clear pfile->cb.line_change.
* gcc.target/powerpc/pr61977-1.c: New test.
* gcc.target/powerpc/pr61977-2.c: New test.
--- libcpp/lex.c.jj 2015-03-31 19:39:28.0 +0200
+++ libcpp/lex.c2015-04-01 12:03:31.146846380 +0200
@@ -2080,6 +2080,12 @@ cpp_peek_token (cpp_reader *pfile, int i
count = index;
pfile->keep_tokens++;
+ /* For peeked tokens temporarily disable line_change reporting,
+ until the tokens are parsed for real. */
+ void (*line_change) (cpp_reader *, const cpp_token *, int)
+= pfile->cb.line_change;
+ pfile->cb.line_change = NULL;
+
do
{
peektok = _cpp_lex_token (pfile);
@@ -2093,6 +2099,7 @@ cpp_peek_token (cpp_reader *pfile, int i
_cpp_backup_tokens_direct (pfile, count - index);
pfile->keep_tokens--;
+ pfile->cb.line_change = line_change;
return peektok;
}
--- gcc/testsuite/gcc.target/powerpc/pr61977-1.c.jj 2015-04-01
12:15:15.341311939 +0200
+++ gcc/testsuite/gcc.target/powerpc/pr61977-1.c2015-04-01
12:17:32.030102843 +0200
@@ -0,0 +1,8 @@
+/* PR preprocessor/61977 */
+/* { dg-do preprocess } */
+/* { dg-options "-mno-altivec -mno-vsx" } */
+
+int y; vector
+int x;
+
+/* { dg-final { scan-file "pr61977-1.i" "(^|\\n)int y; vector\\n" } } */
--- gcc/testsuite/gcc.target/powerpc/pr61977-2.c.jj 2015-04-01
12:15:18.125266339 +0200
+++ gcc/testsuite/gcc.target/powerpc/pr61977-2.c2015-04-01
12:18:22.033321600 +0200
@@ -0,0 +1,8 @@
+/* PR preprocessor/61977 */
+/* { dg-do preprocess } */
+/* { dg-options "-maltivec" } */
+
+int y; vector
+int x;
+
+/* { dg-final { scan-file "pr61977-2.i" "(^|\\n)int y;
__attribute__\\(\\(altivec\\(vector__\\)\\)\\)\\n" } } */
Jakub
PATCH: Update --with-system-zlib
On Tue, Mar 31, 2015 at 10:04 AM, H.J. Lu wrote:
> On Tue, Mar 31, 2015 at 10:01 AM, Mike Frysinger wrote:
>> On 31 Mar 2015 09:56, H.J. Lu wrote:
>>> On Tue, Mar 31, 2015 at 9:41 AM, Mike Frysinger wrote:
>>> > On 31 Mar 2015 03:10, H.J. Lu wrote:
>>> >> On Mon, Mar 30, 2015 at 11:13 PM, Mike Frysinger wrote:
>>> >> > On 26 Mar 2015 08:57, H.J. Lu wrote:
>>> >> >> --- a/bfd/configure.ac
>>> >> >> +++ b/bfd/configure.ac
>>> >> >>
>>> >> >> -# Link in zlib if we can. This allows us to read compressed debug
>>> >> >> sections.
>>> >> >> -# This is used only by compress.c.
>>> >> >> -AM_ZLIB
>>> >> >> +# Use the system's zlib library.
>>> >> >> +zlibdir=-L../zlib
>>> >> >> +zlibinc="-I\$(srcdir)/../zlib"
>>> >> >> +AC_ARG_WITH(system-zlib,
>>> >> >> +[AS_HELP_STRING([--with-system-zlib], [use installed libz])],
>>> >> >> +zlibdir=
>>> >> >> +zlibinc=
>>> >> >> +)
>>> >> >
>>> >> > this is wrong. the 3rd arg is whether the option was specified, not
>>> >> > that the
>>> >> > option was disabled. you need to check $withval is equal to "no" (or
>>> >> > not equal
>>> >> > to "yes").
>>> >>
>>> >> That is what gcc/configure.ac has and it works for me.
>>> >
>>> > then gcc/configure.ac is also broken. whether "it works for me" is
>>> > irrelevant -- simply read the code and you'll see it's wrong. if you
>>> > pass --without-system-zlib the code wrongly behaves as if you passed
>>> > --with-system-zlib.
>>> >
>>> > i mention this because it is breaking my test builds. not that that
>>> > really matters -- the code is clearly incorrect.
>>>
>>> We should fix zlib.m4 and use it in gcc/configure.ac.
>>
>> sure; i await your patches ;). i'm not trying to point fingers here for
>> pointing's sake -- binutils & gdb were working before and now they're broken,
>> and they broke due to the zlib patches you merged. so i think it's
>> reasonable
>> to expect you to drive further fixes (probably across gcc) even though the
>> bug
>> has existed in gcc for sometime.
>
> Sure. I have put it in my queue.
>
> Sorry for the inconvenience.
>
I checked the enclosed patches to update --with-system-zlib. They fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65645
in binutils-gdb tree and add --with-system-zlib to top level configure --help.
--
H.J.
From 031f1448b68a9eae3392353857c7873f857c2221 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Wed, 1 Apr 2015 04:51:55 -0700
Subject: [PATCH 1/3] Unset zlibdir/zlibinc only for --with-system-zlib
* zlib.m4 (AM_ZLIB): Unset zlibdir and zlibinc only for
--with-system-zlib.
---
config/ChangeLog | 5 +
config/zlib.m4 | 6 --
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/config/ChangeLog b/config/ChangeLog
index 945f080..6dc4998 100644
--- a/config/ChangeLog
+++ b/config/ChangeLog
@@ -1,3 +1,8 @@
+2015-04-01 H.J. Lu
+
+ * zlib.m4 (AM_ZLIB): Unset zlibdir and zlibinc only for
+ --with-system-zlib.
+
2015-03-31 H.J. Lu
* zlib.m4 (AM_ZLIB): Replace --with-zlib with --with-system-zlib.
diff --git a/config/zlib.m4 b/config/zlib.m4
index 3664295..aa3ac48 100644
--- a/config/zlib.m4
+++ b/config/zlib.m4
@@ -9,8 +9,10 @@ AC_DEFUN([AM_ZLIB],
zlibinc="-I\$(srcdir)/../zlib"
AC_ARG_WITH(system-zlib,
[AS_HELP_STRING([--with-system-zlib], [use installed libz])],
- zlibdir=
- zlibinc=
+ if test x$with_system_zlib = xyes ; then
+zlibdir=
+zlibinc=
+ fi
)
AC_SUBST(zlibdir)
AC_SUBST(zlibinc)
--
2.1.0
From afa59b79006af1572ceeebcd2ada5a13e483f6b1 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Wed, 1 Apr 2015 04:55:48 -0700
Subject: [PATCH 2/3] Regenerate configure in bfd/binutils/gas/gdb
bfd/
2015-04-01 H.J. Lu
* configure: Regenerated.
binutils/
2015-04-01 H.J. Lu
* configure: Regenerated.
gas/
2015-04-01 H.J. Lu
* configure: Regenerated.
gdb/
2015-04-01 H.J. Lu
* configure: Regenerated.
---
bfd/ChangeLog | 4
bfd/configure | 6 --
binutils/ChangeLog | 4
binutils/configure | 6 --
gas/ChangeLog | 4
gas/configure | 6 --
gdb/ChangeLog | 4
gdb/configure | 6 --
8 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/bfd/ChangeLog b/bfd/ChangeLog
index 10ea6fc..5d3013a 100644
--- a/bfd/ChangeLog
+++ b/bfd/ChangeLog
@@ -1,3 +1,7 @@
+2015-04-01 H.J. Lu
+
+ * configure: Regenerated.
+
2015-03-31 Ed Schouten
* config.bfd (targ_defvec): Set to x86_64_elf64_cloudabi_vec
diff --git a/bfd/configure b/bfd/configure
index 777d74a..4f0bdd8 100755
--- a/bfd/configure
+++ b/bfd/configure
@@ -13862,8 +13862,10 @@ _ACEOF
# Check whether --with-system-zlib was given.
if test "${with_system_zlib+set}" = set; then :
- withval=$with_system_zlib; zlibdir=
- zlibinc=
+ withval=$with_system_zlib; if test x$with_system_zlib = xyes ; then
+zlibdir=
+zlibinc=
+ fi
fi
diff --git a/binutils/ChangeLog b/binutils/ChangeLog
index bd3890c..e369f6b 100644
--- a/binutils/ChangeLog
+++ b/binutils/ChangeLog
@@ -1,3 +1,7
Re: [PATCH] Disable ppc/spu context sensitive macros for CLK_ASM preprocessing (PR preprocessor/61977)
Jakub Jelinek wrote: > The context sensitive macros are inherently C/C++ specific, so trying to > expand them into anything when preprocessing assembler doesn't make any > sense to me. Makes sense. > 2015-04-01 Jakub Jelinek > > PR preprocessor/61977 > * config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Don't > predefine __vector/__bool/__pixel macros nor context sensitive > macros for CLK_ASM. > * config/spu/spu-c.c (spu_cpu_cpp_builtins): Similarly. The SPU part is OK. Thanks, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
Re: C++ PATCH for c++/65554 (ICE with user-defined initializer_list)
OK, thanks. Jason
Re: libgomp nvptx plugin: rework initialisation and support the proposed load/unload hooks (was: Merge current set of OpenACC changes from gomp-4_0-branch)
On Wed, Apr 01, 2015 at 07:21:47 +0200, Jakub Jelinek wrote:
> On Wed, Apr 01, 2015 at 02:53:28AM +0300, Ilya Verbin wrote:
> > +/* Similar to gomp_fatal, but release mutexes before. */
> > +
> > +static void
> > +gomp_fatal_unlock (const char *fmt, ...)
> > +{
> > + int i;
> > + va_list list;
> > +
> > + for (i = 0; i < num_devices; i++)
> > +gomp_mutex_unlock (&devices[i].lock);
>
> This is wrong. Calling gomp_mutex_unlock on a lock that you don't have
> locked is undefined behavior.
> You really should unlock it in the caller which should be aware which 0/1/2
> locks it holds.
I was worried about the following scenario:
1. Thread 1 in GOMP_target locks device 1.
2. Thread 2 in GOMP_target locks device 2 and calls gomp_fatal.
3. GOMP_offload_unregister will wait for device 1, even device 2 is unlocked.
Anyway, it was a bad idea to unlock mutexes from non-owner thread.
Here is patch, which unlocks proper mutexes in the caller, as you suggested.
make check-target-libgomp passed.
diff --git a/gcc/config/i386/intelmic-mkoffload.c
b/gcc/config/i386/intelmic-mkoffload.c
index f93007c..e101f93 100644
--- a/gcc/config/i386/intelmic-mkoffload.c
+++ b/gcc/config/i386/intelmic-mkoffload.c
@@ -350,14 +350,24 @@ generate_host_descr_file (const char *host_compiler)
"#ifdef __cplusplus\n"
"extern \"C\"\n"
"#endif\n"
- "void GOMP_offload_register (void *, int, void *);\n\n"
+ "void GOMP_offload_register (void *, int, void *);\n"
+ "void GOMP_offload_unregister (void *, int, void *);\n\n"
"__attribute__((constructor))\n"
"static void\n"
"init (void)\n"
"{\n"
" GOMP_offload_register (&__OFFLOAD_TABLE__, %d,
__offload_target_data);\n"
+ "}\n\n", GOMP_DEVICE_INTEL_MIC);
+
+ fprintf (src_file,
+ "__attribute__((destructor))\n"
+ "static void\n"
+ "fini (void)\n"
+ "{\n"
+ " GOMP_offload_unregister (&__OFFLOAD_TABLE__, %d,
__offload_target_data);\n"
"}\n", GOMP_DEVICE_INTEL_MIC);
+
fclose (src_file);
unsigned new_argc = 0;
diff --git a/libgomp/libgomp-plugin.h b/libgomp/libgomp-plugin.h
index d9cbff5..1072ae4 100644
--- a/libgomp/libgomp-plugin.h
+++ b/libgomp/libgomp-plugin.h
@@ -51,14 +51,12 @@ enum offload_target_type
OFFLOAD_TARGET_TYPE_INTEL_MIC = 6
};
-/* Auxiliary struct, used for transferring a host-target address range mapping
- from plugin to libgomp. */
-struct mapping_table
+/* Auxiliary struct, used for transferring pairs of addresses from plugin
+ to libgomp. */
+struct addr_pair
{
- uintptr_t host_start;
- uintptr_t host_end;
- uintptr_t tgt_start;
- uintptr_t tgt_end;
+ uintptr_t start;
+ uintptr_t end;
};
/* Miscellaneous functions. */
diff --git a/libgomp/libgomp.h b/libgomp/libgomp.h
index 3089401..a1d42c5 100644
--- a/libgomp/libgomp.h
+++ b/libgomp/libgomp.h
@@ -224,7 +224,6 @@ struct gomp_team_state
};
struct target_mem_desc;
-struct gomp_memory_mapping;
/* These are the OpenMP 4.0 Internal Control Variables described in
section 2.3.1. Those described as having one copy per task are
@@ -657,7 +656,7 @@ struct target_mem_desc {
struct gomp_device_descr *device_descr;
/* Memory mapping info for the thread that created this descriptor. */
- struct gomp_memory_mapping *mem_map;
+ struct splay_tree_s *mem_map;
/* List of splay keys to remove (or decrease refcount)
at the end of region. */
@@ -683,20 +682,6 @@ struct splay_tree_key_s {
#include "splay-tree.h"
-/* Information about mapped memory regions (per device/context). */
-
-struct gomp_memory_mapping
-{
- /* Mutex for operating with the splay tree and other shared structures. */
- gomp_mutex_t lock;
-
- /* True when tables have been added to this memory map. */
- bool is_initialized;
-
- /* Splay tree containing information about mapped memory regions. */
- struct splay_tree_s splay_tree;
-};
-
typedef struct acc_dispatch_t
{
/* This is a linked list of data mapped using the
@@ -773,19 +758,18 @@ struct gomp_device_descr
unsigned int (*get_caps_func) (void);
int (*get_type_func) (void);
int (*get_num_devices_func) (void);
- void (*register_image_func) (void *, void *);
void (*init_device_func) (int);
void (*fini_device_func) (int);
- int (*get_table_func) (int, struct mapping_table **);
+ int (*load_image_func) (int, void *, struct addr_pair **);
+ void (*unload_image_func) (int, void *);
void *(*alloc_func) (int, size_t);
void (*free_func) (int, void *);
void *(*dev2host_func) (int, void *, const void *, size_t);
void *(*host2dev_func) (int, void *, const void *, size_t);
void (*run_func) (int, void *, void *);
- /* Memory-mapping info for this device instance. */
- /* Uses a separate lock. */
- struct gomp_memory_mapping mem_map;
+ /* Splay tree containing information about mapped memory regions. */
+ struct splay_tree_s mem_
Re: [Patch, fortran, PR44672, v2] [F08] ALLOCATE with SOURCE and no array-spec
Hi all,
during debugging another fortran code, I figured that some cases were not yet
met. Especially the case where a class array is in the source= or mold=
expression. This new version of the patch fixes the issue now.
Bootstraps and regtests ok on x86_64-linux-gnu/F20.
Ok for 5.2 trunk?
Regards,
Andre
On Mon, 30 Mar 2015 19:47:49 +0200
Andre Vehreschild wrote:
> Dear all,
>
> please find attach a patch fixing pr44672:
>
> integer, dimension(:) :: arr
> allocate(arr, source = [1,2,3])
>
> as for F2008:C633 now is no longer flagged, beside when you insist on
> -std=f2003 or lower. Furthermore does the patch implement the F2008 feature of
> obsoleting the explicit array specification on the arrays to allocate, when
> an array valued source=/mold= expression is given.
>
> Bootstrap and regtests ok on x86_64-linux-gnu/F20.
>
> This batched is based on a trunk having my latest for pr60322 patched in (else
> deltas may occur).
>
> Ok for 5.2 trunk?
>
> Regards,
> Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
pr44672_2.clog
Description: Binary data
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 643cd6a..9835edc 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2394,6 +2394,9 @@ typedef struct gfc_code
{
gfc_typespec ts;
gfc_alloc *list;
+ /* Take the array specification from expr3 to allocate arrays
+ without an explicit array specification. */
+ unsigned arr_spec_from_expr3:1;
}
alloc;
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 316b413..ce2e29e 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -6804,7 +6804,7 @@ conformable_arrays (gfc_expr *e1, gfc_expr *e2)
have a trailing array reference that gives the size of the array. */
static bool
-resolve_allocate_expr (gfc_expr *e, gfc_code *code)
+resolve_allocate_expr (gfc_expr *e, gfc_code *code, bool *array_alloc_wo_spec)
{
int i, pointer, allocatable, dimension, is_abstract;
int codimension;
@@ -7103,9 +7103,20 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code)
if (!ref2 || ref2->type != REF_ARRAY || ref2->u.ar.type == AR_FULL
|| (dimension && ref2->u.ar.dimen == 0))
{
- gfc_error ("Array specification required in ALLOCATE statement "
- "at %L", &e->where);
- goto failure;
+ /* F08:C633. */
+ if (code->expr3)
+ {
+ if (!gfc_notify_std (GFC_STD_F2008, "Array specification required "
+ "in ALLOCATE statement at %L", &e->where))
+ goto failure;
+ *array_alloc_wo_spec = true;
+ }
+ else
+ {
+ gfc_error ("Array specification required in ALLOCATE statement "
+ "at %L", &e->where);
+ goto failure;
+ }
}
/* Make sure that the array section reference makes sense in the
@@ -7124,7 +7135,7 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code)
for (i = 0; i < ar->dimen; i++)
{
- if (ref2->u.ar.type == AR_ELEMENT)
+ if (ar->type == AR_ELEMENT || ar->type == AR_FULL)
goto check_symbols;
switch (ar->dimen_type[i])
@@ -7375,8 +7386,103 @@ resolve_allocate_deallocate (gfc_code *code, const char *fcn)
if (strcmp (fcn, "ALLOCATE") == 0)
{
+ bool arr_alloc_wo_spec = false;
for (a = code->ext.alloc.list; a; a = a->next)
- resolve_allocate_expr (a->expr, code);
+ resolve_allocate_expr (a->expr, code, &arr_alloc_wo_spec);
+
+ if (arr_alloc_wo_spec && code->expr3)
+ {
+ /* Mark the allocate to have to take the array specification
+ from the expr3. */
+ code->ext.alloc.arr_spec_from_expr3 = 1;
+
+ if (code->expr3->expr_type == EXPR_ARRAY
+ || code->expr3->expr_type == EXPR_FUNCTION)
+ {
+ /* The trans stage can not cope with expr3->expr_type
+ being EXPR_ARRAY or EXPR_FUNCTION, therefore create a
+ temporary variable and assign expr3 to it, substituting
+ the variable in expr3. */
+ char name[25];
+ static unsigned int alloc_sym_count = 0;
+ gfc_symbol *temp_var_sym;
+ gfc_expr *temp_var;
+ gfc_code *ass, *iter;
+ gfc_namespace *ns = code->ext.alloc.list->expr->symtree->n.sym->ns;
+ gfc_array_spec *as;
+ int dim;
+ mpz_t dim_size;
+
+ /* The name of the new variable. */
+ sprintf (name, "alloc_arr_init.%d", alloc_sym_count++);
+ gfc_get_symbol (name, ns, &temp_var_sym);
+ temp_var_sym->attr.artificial = 1;
+ temp_var_sym->attr.flavor = FL_VARIABLE;
+ temp_var_sym->ts = code->expr3->ts;
+ /* Build an EXPR_VARIABLE node. */
+ temp_var = gfc_get_expr ();
+ temp_var->expr_type = EXPR_VARIABLE;
+ temp_var->symtree = gfc_find_symtree (ns->sym_root, name);
+ temp_var->ts = code->expr3->ts;
+ temp_var->where = code->expr3->where;
+
+ /* Now to the most important: Set the array specification
+ correctly. */
+ as = gfc_get_array_spec ();
+ temp_var->rank = as->rank = code->expr3->rank;
+
Re: libgomp nvptx plugin: rework initialisation and support the proposed load/unload hooks (was: Merge current set of OpenACC changes from gomp-4_0-branch)
On Wed, Apr 01, 2015 at 04:14:05PM +0300, Ilya Verbin wrote:
> On Wed, Apr 01, 2015 at 07:21:47 +0200, Jakub Jelinek wrote:
> > On Wed, Apr 01, 2015 at 02:53:28AM +0300, Ilya Verbin wrote:
> > > +/* Similar to gomp_fatal, but release mutexes before. */
> > > +
> > > +static void
> > > +gomp_fatal_unlock (const char *fmt, ...)
> > > +{
> > > + int i;
> > > + va_list list;
> > > +
> > > + for (i = 0; i < num_devices; i++)
> > > +gomp_mutex_unlock (&devices[i].lock);
> >
> > This is wrong. Calling gomp_mutex_unlock on a lock that you don't have
> > locked is undefined behavior.
> > You really should unlock it in the caller which should be aware which 0/1/2
> > locks it holds.
>
> I was worried about the following scenario:
> 1. Thread 1 in GOMP_target locks device 1.
> 2. Thread 2 in GOMP_target locks device 2 and calls gomp_fatal.
> 3. GOMP_offload_unregister will wait for device 1, even device 2 is unlocked.
How is that different from
1. Thread 1 in GOMP_target locks device 1.
2. Thread 2 calls exit.
? I mean when you unlock the device and register locks if you own them
before gomp_fatal.
> Anyway, it was a bad idea to unlock mutexes from non-owner thread.
>
> Here is patch, which unlocks proper mutexes in the caller, as you suggested.
> make check-target-libgomp passed.
LGTM with proper ChangeLog entry.
Jakub
Re: [C++ Patch/RFC] PR 56100
On 04/01/2015 06:12 AM, Marek Polacek wrote:
On Wed, Apr 01, 2015 at 12:02:36PM +0200, Paolo Carlini wrote:
--- cp/pt.c (revision 221795)
+++ cp/pt.c (working copy)
@@ -20773,6 +20773,13 @@ current_instantiation (void)
return current_tinst_level;
}
+bool
+instantiating_current_function_p (void)
+{
+ return (current_instantiation ()
+ && current_instantiation ()->decl == current_function_decl);
+}
+
This function is missing a comment.
OK with that fixed.
Jason
[PATCH, CFT] Fix bootstrap with in-tree ISL
Hi,
Trying to build config-list.mk for current trunk.
The box is a stable debian (7.8 it seems) so the OS' ISL is too old
thus i was attempting to use in-tree ISL.
When using an in-tree ISL gcc attempts to determine if it is recent
enough and AFAIU fails to do so since the system's ISL (which we will not use)
might be too old and the in-tree ISL is not yet built.
This results in HAVE_ISL_SCHED_CONSTRAINTS_COMPUTE_SCHEDULE being not
set and thus compilation of graphite-isl-ast-to-gimple.c fails with
"template with C linkage".
The attached seems to get me past compilation of
graphite-isl-ast-to-gimple.c with config-list.mk for e.g.
alpha-linux-gnu
I'm scheduling a proper regstrap on x86_64-linux-gnu for a native
compiler but this will take days to start i fear.
So.. if somebody has spare cycles.. :)
cheers,
config/ChangeLog:
2015-04-01 Bernhard Reutner-Fischer
* isl.m4 (ISL_CHECK_VERSION): AC_SUBST ENABLE_ISL_CHECK.
ChangeLog:
2015-04-01 Bernhard Reutner-Fischer
* Makefile.tpl: Set HOST_ISL_CHECK from substituted
ENABLE_ISL_CHECK.
(HOST_EXPORTS): Add ENABLE_ISL_CHECK.
* Makefile.in: Regenerate.
gcc/ChangeLog:
2015-04-01 Bernhard Reutner-Fischer
* configure.ac: Assume a current ISL when using in-tree ISL.
* configure: Regenerate.
When using an in-tree ISL gcc attempts to determine if it is recent
enough and fails to do so since the system's ISL (which we will not use)
might be too old and the in-tree ISL is not yet built.
This results in HAVE_ISL_SCHED_CONSTRAINTS_COMPUTE_SCHEDULE being not
set and thus compilation of graphite-isl-ast-to-gimple.c fails with
"template with C linkage".
config/ChangeLog:
2015-04-01 Bernhard Reutner-Fischer
* isl.m4 (ISL_CHECK_VERSION): AC_SUBST ENABLE_ISL_CHECK.
ChangeLog:
2015-04-01 Bernhard Reutner-Fischer
* Makefile.tpl: Set HOST_ISL_CHECK from substituted
ENABLE_ISL_CHECK.
(HOST_EXPORTS): Add ENABLE_ISL_CHECK.
* Makefile.in: Regenerate.
gcc/ChangeLog:
2015-04-01 Bernhard Reutner-Fischer
* configure.ac: Assume a current ISL when using in-tree ISL.
* configure: Regenerate.
diff --git a/Makefile.in b/Makefile.in
index 36b4008..4ea875e 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -222,6 +222,7 @@ HOST_EXPORTS = \
GMPINC="$(HOST_GMPINC)"; export GMPINC; \
ISLLIBS="$(HOST_ISLLIBS)"; export ISLLIBS; \
ISLINC="$(HOST_ISLINC)"; export ISLINC; \
+ ENABLE_ISL_CHECK="$(HOST_ISL_CHECK)"; export ENABLE_ISL_CHECK; \
LIBELFLIBS="$(HOST_LIBELFLIBS)" ; export LIBELFLIBS; \
LIBELFINC="$(HOST_LIBELFINC)" ; export LIBELFINC; \
@if gcc-bootstrap
@@ -314,6 +315,8 @@ HOST_GMPINC = @gmpinc@
# Where to find ISL
HOST_ISLLIBS = @isllibs@
HOST_ISLINC = @islinc@
+# in-tree ISL has ENABLE_ISL_CHECK set to "no"
+HOST_ISL_CHECK = @ENABLE_ISL_CHECK@
# Where to find libelf
HOST_LIBELFLIBS = @libelflibs@
diff --git a/Makefile.tpl b/Makefile.tpl
index 1ea1954..5794128 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -225,6 +225,7 @@ HOST_EXPORTS = \
GMPINC="$(HOST_GMPINC)"; export GMPINC; \
ISLLIBS="$(HOST_ISLLIBS)"; export ISLLIBS; \
ISLINC="$(HOST_ISLINC)"; export ISLINC; \
+ ENABLE_ISL_CHECK="$(HOST_ISL_CHECK)"; export ENABLE_ISL_CHECK; \
LIBELFLIBS="$(HOST_LIBELFLIBS)" ; export LIBELFLIBS; \
LIBELFINC="$(HOST_LIBELFINC)" ; export LIBELFINC; \
@if gcc-bootstrap
@@ -317,6 +318,8 @@ HOST_GMPINC = @gmpinc@
# Where to find ISL
HOST_ISLLIBS = @isllibs@
HOST_ISLINC = @islinc@
+# in-tree ISL has ENABLE_ISL_CHECK set to "no"
+HOST_ISL_CHECK = @ENABLE_ISL_CHECK@
# Where to find libelf
HOST_LIBELFLIBS = @libelflibs@
diff --git a/config/isl.m4 b/config/isl.m4
index 459fac1..67634e0 100644
--- a/config/isl.m4
+++ b/config/isl.m4
@@ -116,6 +116,7 @@ AC_DEFUN([ISL_CHECK_VERSION],
LDFLAGS=$_isl_saved_LDFLAGS
LIBS=$_isl_saved_LIBS
fi
+ AC_SUBST([ENABLE_ISL_CHECK])dnl
]
)
diff --git a/configure b/configure
index 064e69b..0e4b0f2 100755
--- a/configure
+++ b/configure
@@ -649,6 +649,7 @@ extra_linker_plugin_flags
extra_linker_plugin_configure_flags
islinc
isllibs
+ENABLE_ISL_CHECK
poststage1_ldflags
poststage1_libs
stage1_ldflags
diff --git a/gcc/configure b/gcc/configure
index 20dbce6..a3ac299 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -28175,15 +28175,25 @@ fi
# Check whether isl_schedule_constraints_compute_schedule is available;
# it's new in ISL-0.13.
-if test "x${ISLLIBS}" != "x" ; then
- saved_CFLAGS="$CFLAGS"
- CFLAGS="$CFLAGS $ISLINC"
- saved_LIBS="$LIBS"
- LIBS="$LIBS $ISLLIBS $GMPLIBS"
+# When using an in-tree ISL then we assume it is recent enough
+if test x"$ENABLE_ISL_CHECK" = x"no"; then
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking Checking for isl_schedule_constraints_compute_schedule" >&5
+$as_echo_n "checking Checking for isl_schedule_constraints_compute_schedule... " >&6; }
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes (in-tree)" >&5
+$as_echo "yes (in-tree)" >&6; }
- { $as_echo "$as_me:${as_lineno-$LINENO}:
Re: Inliner badness metric tweak
On Sun, Mar 29, 2015 at 6:45 PM, Jan Hubicka wrote: > Hi, > this patch makes inline metric to be >estimate_speedup > (over) > edge_growth^2*overall_growth > > This is intended to make stronger push on inliner to preffer functions with > smaller growth and do not take overall growth (that is expected unit growth > after inlining all calls to a give function) so seriously. > > This solve code size regression for tramp3d and also improve DLV. I tested it > on firefox with resonable results and on subset of SPEC that caused inliner > issues in past. > > Lacking access to SUSE's periodic testers, I intend to commit it today and > watch them for possible regressions. > > Bootstrapped/regtested x86_64-linux. > > PR ipa/65076 > * ipa-inline.c (edge_badness): Base denominator on callee's > grwoth squared. This caused: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65654 -- H.J.
Re: [PATCH, CFT] Fix bootstrap with in-tree ISL
On 1 April 2015 at 17:53, Tobias Grosser wrote: > On 04/01/2015 05:09 PM, Bernhard Reutner-Fischer wrote: >> >> Hi, >> >> Trying to build config-list.mk for current trunk. >> The box is a stable debian (7.8 it seems) so the OS' ISL is too old >> thus i was attempting to use in-tree ISL. >> >> When using an in-tree ISL gcc attempts to determine if it is recent >> enough and AFAIU fails to do so since the system's ISL (which we will not >> use) >> might be too old and the in-tree ISL is not yet built. >> >> This results in HAVE_ISL_SCHED_CONSTRAINTS_COMPUTE_SCHEDULE being not >> set and thus compilation of graphite-isl-ast-to-gimple.c fails with >> "template with C linkage". >> >> The attached seems to get me past compilation of >> graphite-isl-ast-to-gimple.c with config-list.mk for e.g. >> alpha-linux-gnu >> >> I'm scheduling a proper regstrap on x86_64-linux-gnu for a native >> compiler but this will take days to start i fear. >> So.. if somebody has spare cycles.. :) > > > Hi Bernhard, > > I can not give an OK for the makefile/configure changes, but in general this > seems to be the right direction. It seems that the in-tree ISL is not configured nor built upon make all-gcc, so libbackend linking fails as it stands. Will have a closer look.. thanks, > > Thanks, > Tobias
Re: [PATCH, CFT] Fix bootstrap with in-tree ISL
On 04/01/2015 05:09 PM, Bernhard Reutner-Fischer wrote: Hi, Trying to build config-list.mk for current trunk. The box is a stable debian (7.8 it seems) so the OS' ISL is too old thus i was attempting to use in-tree ISL. When using an in-tree ISL gcc attempts to determine if it is recent enough and AFAIU fails to do so since the system's ISL (which we will not use) might be too old and the in-tree ISL is not yet built. This results in HAVE_ISL_SCHED_CONSTRAINTS_COMPUTE_SCHEDULE being not set and thus compilation of graphite-isl-ast-to-gimple.c fails with "template with C linkage". The attached seems to get me past compilation of graphite-isl-ast-to-gimple.c with config-list.mk for e.g. alpha-linux-gnu I'm scheduling a proper regstrap on x86_64-linux-gnu for a native compiler but this will take days to start i fear. So.. if somebody has spare cycles.. :) Hi Bernhard, I can not give an OK for the makefile/configure changes, but in general this seems to be the right direction. Thanks, Tobias
C++ PATCH for c++/65646 (ICE after error specializing missing static data member)
This testcase started crashing because the added call to
check_explicit_specialization does a SET_DECL_TEMPLATE_SPECIALIZATION
which wasn't happening previously, and then determine_visibility assumes
that if DECL_USE_TEMPLATE is set, so is DECL_TEMPLATE_INFO. Fixed for
GCC 5 by avoiding the call if we aren't dealing with a member template.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 5dbbdeda316eaa8f2b2a43fc28762f7d7ecca22c
Author: Jason Merrill
Date: Wed Apr 1 10:14:53 2015 -0400
PR c++/65646
* decl.c (grokvardecl): Don't call check_explicit_specialization
for non-template members of a class template.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index f05aefa..31b8e0c 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -8210,7 +8210,9 @@ grokvardecl (tree type,
DECL_INTERFACE_KNOWN (decl) = 1;
// Handle explicit specializations and instantiations of variable templates.
- if (orig_declarator)
+ if (orig_declarator
+ /* For GCC 5 fix 65646 this way. */
+ && current_tmpl_spec_kind (template_count) != tsk_none)
decl = check_explicit_specialization (orig_declarator, decl,
template_count, 0);
diff --git a/gcc/testsuite/g++.dg/template/static36.C b/gcc/testsuite/g++.dg/template/static36.C
new file mode 100644
index 000..36c48b0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/static36.C
@@ -0,0 +1,4 @@
+// PR c++/65646
+
+template class A {};
+template <> A<> &A<>::a; // { dg-error "" }
Re: PATCH: Update --with-system-zlib
On 01 Apr 2015 05:04, H.J. Lu wrote:
> --- a/config/zlib.m4
> +++ b/config/zlib.m4
> @@ -9,8 +9,10 @@ AC_DEFUN([AM_ZLIB],
>zlibinc="-I\$(srcdir)/../zlib"
>AC_ARG_WITH(system-zlib,
>[AS_HELP_STRING([--with-system-zlib], [use installed libz])],
> - zlibdir=
> - zlibinc=
> + if test x$with_system_zlib = xyes ; then
> +zlibdir=
> +zlibinc=
> + fi
>)
this is inside the 3rd arg, so normally you check $withval. this code will
still work as the generated shell does:
if test "${with_system_zlib+set}" = set; then :
withval=$with_system_zlib; [3rd arg content]
fi
> bfd/ChangeLog | 4
> bfd/configure | 6 --
> binutils/ChangeLog | 4
> binutils/configure | 6 --
> gas/ChangeLog | 4
> gas/configure | 6 --
> gdb/ChangeLog | 4
> gdb/configure | 6 --
you need to regenerate the sim tree too
-mike
signature.asc
Description: Digital signature
Re: PATCH: Update --with-system-zlib
On April 1, 2015 6:54:31 PM GMT+02:00, Mike Frysinger wrote:
>On 01 Apr 2015 05:04, H.J. Lu wrote:
>> --- a/config/zlib.m4
>> +++ b/config/zlib.m4
>> @@ -9,8 +9,10 @@ AC_DEFUN([AM_ZLIB],
>>zlibinc="-I\$(srcdir)/../zlib"
>>AC_ARG_WITH(system-zlib,
>>[AS_HELP_STRING([--with-system-zlib], [use installed libz])],
>> - zlibdir=
>> - zlibinc=
>> + if test x$with_system_zlib = xyes ; then
>> +zlibdir=
>> +zlibinc=
>> + fi
>>)
>
>this is inside the 3rd arg, so normally you check $withval. this code
>will
>still work as the generated shell does:
>if test "${with_system_zlib+set}" = set; then :
Why doesn't this expand to test -n "${with_system_zlib+set}"
nowadays, BTW? Would be faster to parse and supposedly sums up quite a bit,
fwiw.
Cheers,
> withval=$with_system_zlib; [3rd arg content]
>fi
>
>> bfd/ChangeLog | 4
>> bfd/configure | 6 --
>> binutils/ChangeLog | 4
>> binutils/configure | 6 --
>> gas/ChangeLog | 4
>> gas/configure | 6 --
>> gdb/ChangeLog | 4
>> gdb/configure | 6 --
>
>you need to regenerate the sim tree too
>-mike
Re: PATCH: Update --with-system-zlib
On 01 Apr 2015 19:05, Bernhard Reutner-Fischer wrote:
> On April 1, 2015 6:54:31 PM GMT+02:00, Mike Frysinger wrote:
> >On 01 Apr 2015 05:04, H.J. Lu wrote:
> >> --- a/config/zlib.m4
> >> +++ b/config/zlib.m4
> >> @@ -9,8 +9,10 @@ AC_DEFUN([AM_ZLIB],
> >>zlibinc="-I\$(srcdir)/../zlib"
> >>AC_ARG_WITH(system-zlib,
> >>[AS_HELP_STRING([--with-system-zlib], [use installed libz])],
> >> - zlibdir=
> >> - zlibinc=
> >> + if test x$with_system_zlib = xyes ; then
> >> +zlibdir=
> >> +zlibinc=
> >> + fi
> >>)
> >
> >this is inside the 3rd arg, so normally you check $withval. this code
> >will
> >still work as the generated shell does:
> >if test "${with_system_zlib+set}" = set; then :
>
> Why doesn't this expand to test -n "${with_system_zlib+set}"
> nowadays, BTW? Would be faster to parse and supposedly sums up quite a bit,
> fwiw.
question for the autoconf list ?
although note that this is autoconf-2.64 as that is what the tree has locked
itself to currently.
-mike
signature.asc
Description: Digital signature
Re: PATCH: Update --with-system-zlib
On Wed, Apr 1, 2015 at 9:54 AM, Mike Frysinger wrote:
> On 01 Apr 2015 05:04, H.J. Lu wrote:
>> --- a/config/zlib.m4
>> +++ b/config/zlib.m4
>> @@ -9,8 +9,10 @@ AC_DEFUN([AM_ZLIB],
>>zlibinc="-I\$(srcdir)/../zlib"
>>AC_ARG_WITH(system-zlib,
>>[AS_HELP_STRING([--with-system-zlib], [use installed libz])],
>> - zlibdir=
>> - zlibinc=
>> + if test x$with_system_zlib = xyes ; then
>> +zlibdir=
>> +zlibinc=
>> + fi
>>)
>
> this is inside the 3rd arg, so normally you check $withval. this code will
> still work as the generated shell does:
> if test "${with_system_zlib+set}" = set; then :
> withval=$with_system_zlib; [3rd arg content]
> fi
>
>> bfd/ChangeLog | 4
>> bfd/configure | 6 --
>> binutils/ChangeLog | 4
>> binutils/configure | 6 --
>> gas/ChangeLog | 4
>> gas/configure | 6 --
>> gdb/ChangeLog | 4
>> gdb/configure | 6 --
>
> you need to regenerate the sim tree too
> -mike
I pushed it onto maser.
--
H.J.
Re: libgomp nvptx plugin: rework initialisation and support the proposed load/unload hooks (was: Merge current set of OpenACC changes from gomp-4_0-branch)
On Wed, Apr 01, 2015 at 15:20:25 +0200, Jakub Jelinek wrote: > On Wed, Apr 01, 2015 at 04:14:05PM +0300, Ilya Verbin wrote: > > I was worried about the following scenario: > > 1. Thread 1 in GOMP_target locks device 1. > > 2. Thread 2 in GOMP_target locks device 2 and calls gomp_fatal. > > 3. GOMP_offload_unregister will wait for device 1, even device 2 is > > unlocked. > > How is that different from > 1. Thread 1 in GOMP_target locks device 1. > 2. Thread 2 calls exit. > ? I mean when you unlock the device and register locks if you own them > before gomp_fatal. Yeah, it's the same situation. > > Here is patch, which unlocks proper mutexes in the caller, as you suggested. > > make check-target-libgomp passed. > > LGTM with proper ChangeLog entry. When should I commit it into trunk? Without the corresponding PTX part, offloading to PTX will not work. -- Ilya
[PATCH, i386]: Fix atomic_storedi_fpu predicate
Hello!
Attached patch fixes invalid atomic_storedi_fpu predicate
(match_operand:DI 1 "register_operand" "x,m,?r").
This predicate is not compatible with memory constraint.
While at this, I also changed expanders to accept memory operands
that can be handled by *_fpu instructions. To avoid unwanted pattern
matching, UNSPEC_MOVA has been replaced with UNSPEC_LDA and
UNSPEC_STA. Also, the move from uninitalized operand in
atomic_store_fpu was fixed in case of memory input operand with xmm
temporary register.
2015-04-01 Uros Bizjak
* config/i386/sync.md (UNSPEC_MOVA): Remove.
(atomic_load): Change operand 0 predicate to
nonimmediate_operand and fix up the destination when needed.
Use UNSPEC_LDA.
(atomic_loaddi_fpu): Use UNSPEC_LDA.
(atomic_store): Change operand 1 predicate to
nonimmendate_operand and move the source to register when needed.
Use UNSPEC_STA.
(atomic_store_1): Use UNSPEC_STA.
(atomic_storedi_fpu): Change operand 1 to nonimmediate_operand.
Fix moves from memory operand. Use UNSPEC_STA.
The patch was bootstraped and regression tested on x86_64-linux-gnu
{,-m32} and committed to mainline SVN.
Uros.
Index: config/i386/sync.md
===
--- config/i386/sync.md (revision 221807)
+++ config/i386/sync.md (working copy)
@@ -21,7 +21,8 @@
UNSPEC_LFENCE
UNSPEC_SFENCE
UNSPEC_MFENCE
- UNSPEC_MOVA ; For __atomic support
+
+ ;; __atomic support
UNSPEC_LDA
UNSPEC_STA
])
@@ -140,10 +141,10 @@
])
(define_expand "atomic_load"
- [(set (match_operand:ATOMIC 0 "register_operand")
+ [(set (match_operand:ATOMIC 0 "nonimmediate_operand")
(unspec:ATOMIC [(match_operand:ATOMIC 1 "memory_operand")
(match_operand:SI 2 "const_int_operand")]
- UNSPEC_MOVA))]
+ UNSPEC_LDA))]
""
{
/* For DImode on 32-bit, we can use the FPU to perform the load. */
@@ -152,14 +153,25 @@
(operands[0], operands[1],
assign_386_stack_local (DImode, SLOT_TEMP)));
else
-emit_move_insn (operands[0], operands[1]);
+{
+ rtx dst = operands[0];
+
+ if (MEM_P (dst))
+ dst = gen_reg_rtx (mode);
+
+ emit_move_insn (dst, operands[1]);
+
+ /* Fix up the destination if needed. */
+ if (dst != operands[0])
+ emit_move_insn (operands[0], dst);
+}
DONE;
})
(define_insn_and_split "atomic_loaddi_fpu"
[(set (match_operand:DI 0 "nonimmediate_operand" "=x,m,?r")
(unspec:DI [(match_operand:DI 1 "memory_operand" "m,m,m")]
- UNSPEC_MOVA))
+ UNSPEC_LDA))
(clobber (match_operand:DI 2 "memory_operand" "=X,X,m"))
(clobber (match_scratch:DF 3 "=X,xf,xf"))]
"!TARGET_64BIT && (TARGET_80387 || TARGET_SSE)"
@@ -197,9 +209,9 @@
(define_expand "atomic_store"
[(set (match_operand:ATOMIC 0 "memory_operand")
- (unspec:ATOMIC [(match_operand:ATOMIC 1 "register_operand")
+ (unspec:ATOMIC [(match_operand:ATOMIC 1 "nonimmediate_operand")
(match_operand:SI 2 "const_int_operand")]
- UNSPEC_MOVA))]
+ UNSPEC_STA))]
""
{
enum memmodel model = (enum memmodel) (INTVAL (operands[2]) & MEMMODEL_MASK);
@@ -215,6 +227,8 @@
}
else
{
+ operands[1] = force_reg (mode, operands[1]);
+
/* For seq-cst stores, when we lack MFENCE, use XCHG. */
if (model == MEMMODEL_SEQ_CST && !(TARGET_64BIT || TARGET_SSE2))
{
@@ -238,14 +252,14 @@
[(set (match_operand:SWI 0 "memory_operand" "=m")
(unspec:SWI [(match_operand:SWI 1 "" "")
(match_operand:SI 2 "const_int_operand")]
- UNSPEC_MOVA))]
+ UNSPEC_STA))]
""
"%K2mov{}\t{%1, %0|%0, %1}")
(define_insn_and_split "atomic_storedi_fpu"
[(set (match_operand:DI 0 "memory_operand" "=m,m,m")
- (unspec:DI [(match_operand:DI 1 "register_operand" "x,m,?r")]
- UNSPEC_MOVA))
+ (unspec:DI [(match_operand:DI 1 "nonimmediate_operand" "x,m,?r")]
+ UNSPEC_STA))
(clobber (match_operand:DI 2 "memory_operand" "=X,X,m"))
(clobber (match_scratch:DF 3 "=X,xf,xf"))]
"!TARGET_64BIT && (TARGET_80387 || TARGET_SSE)"
@@ -273,7 +287,7 @@
else
{
adjust_reg_mode (tmp, DImode);
- emit_move_insn (tmp, mem);
+ emit_move_insn (tmp, src);
src = tmp;
}
}
Re: [libcpp] Disable cb.line_change callbacks from within cpp_peek_token (PR preprocessor/61977)
On 04/01/2015 07:24 AM, Jakub Jelinek wrote: Below is one possible fix for that, another option is introduce another pfile->state or pfile field for that, I notice that pfile->state.skipping suppresses the line change as well as various diagnostics that also seem inappropriate for peeking. Perhaps we could use a new state field instead in those places, and only check state.skipping for the actual skipping behavior. But this patch is fine if you don't want to bother with that. Jason
Re: [libcpp] Disable cb.line_change callbacks from within cpp_peek_token (PR preprocessor/61977)
On Wed, Apr 01, 2015 at 04:23:12PM -0400, Jason Merrill wrote: > On 04/01/2015 07:24 AM, Jakub Jelinek wrote: > >Below is one possible fix for that, another option is introduce another > >pfile->state or pfile field for that, > > I notice that pfile->state.skipping suppresses the line change as well as > various diagnostics that also seem inappropriate for peeking. Perhaps we > could use a new state field instead in those places, and only check > state.skipping for the actual skipping behavior. I was thinking about that, but e.g. warnings like warn_about_normalization only happen during _cpp_lex_direct and thus would not be reported at all if they were skipped during cpp_peek_token. Jakub
[PATCH, bfin] handle BFIN_CPU_UNKNOWN in TARGET_CPU_CPP_BUILTINS
Hi,
gcc/c-family/c-cppbuiltin.c
In file included from ./tm.h:21:0,
from
../../../../../../home/me/src/gcc-5.0.mine/gcc/c-family/c-cppbuiltin.c:23:
../../../../../../home/me/src/gcc-5.0.mine/gcc/c-family/c-cppbuiltin.c:
In function ‘void c_cpp_builtins(cpp_reader*)’:
../../../../../../home/me/src/gcc-5.0.mine/gcc/config/bfin/bfin.h:43:14:
error: enumeration value ‘BFIN_CPU_UNKNOWN’ not handled in switch
[-Werror=switch]
switch (bfin_cpu_type) \
^
../../../../../../home/me/src/gcc-5.0.mine/gcc/c-family/c-cppbuiltin.c:1243:3:
note: in expansion of macro ‘TARGET_CPU_CPP_BUILTINS’
TARGET_CPU_CPP_BUILTINS ();
^
cc1plus: all warnings being treated as errors
make[2]: *** [c-family/c-cppbuiltin.o] Error 1
gcc/ChangeLog:
2015-04-01 Bernhard Reutner-Fischer
* config/bfin/bfin.h (TARGET_CPU_CPP_BUILTINS): Add BFIN_CPU_UNKNOWN.
diff --git a/gcc/config/bfin/bfin.h b/gcc/config/bfin/bfin.h
index fd90199..49cc741 100644
--- a/gcc/config/bfin/bfin.h
+++ b/gcc/config/bfin/bfin.h
@@ -42,6 +42,8 @@
\
switch (bfin_cpu_type) \
{ \
+ case BFIN_CPU_UNKNOWN: \
+ break;\
case BFIN_CPU_BF512: \
builtin_define ("__ADSPBF512__"); \
builtin_define ("__ADSPBF51x__"); \
Re: [PATCH, bfin] handle BFIN_CPU_UNKNOWN in TARGET_CPU_CPP_BUILTINS
Bernd, same for c6x for unk_isa, fwiw. thanks, On 1 April 2015 at 23:34, Bernhard Reutner-Fischer wrote: > Hi, > > gcc/c-family/c-cppbuiltin.c > In file included from ./tm.h:21:0, > from > ../../../../../../home/me/src/gcc-5.0.mine/gcc/c-family/c-cppbuiltin.c:23: > ../../../../../../home/me/src/gcc-5.0.mine/gcc/c-family/c-cppbuiltin.c: > In function ‘void c_cpp_builtins(cpp_reader*)’: > ../../../../../../home/me/src/gcc-5.0.mine/gcc/config/bfin/bfin.h:43:14: > error: enumeration value ‘BFIN_CPU_UNKNOWN’ not handled in switch > [-Werror=switch] >switch (bfin_cpu_type) \ > ^ > ../../../../../../home/me/src/gcc-5.0.mine/gcc/c-family/c-cppbuiltin.c:1243:3: > note: in expansion of macro ‘TARGET_CPU_CPP_BUILTINS’ >TARGET_CPU_CPP_BUILTINS (); >^ > cc1plus: all warnings being treated as errors > make[2]: *** [c-family/c-cppbuiltin.o] Error 1 > > gcc/ChangeLog: > > 2015-04-01 Bernhard Reutner-Fischer > > * config/bfin/bfin.h (TARGET_CPU_CPP_BUILTINS): Add BFIN_CPU_UNKNOWN.
Re: Fix increase_alignment
On 9 March 2015 at 00:37, Jan Hubicka wrote:
>>
>> I unforutnately spot another problem. With presence of section anchors we
>> can not increase alignment of symbol that was already placed into the
>> section.
>> I think this is reason why we still have pass_increase_alignments that runs
>> only on target with anchors.
>>
>> I added the following check:
>>
>> + /* If target is already placed in an anchor, we can not touch its
>> + alignment. */
>> + if (DECL_RTL_SET_P (target->decl)
>> + && MEM_P (DECL_RTL (target->decl))
>> + && SYMBOL_REF_HAS_BLOCK_INFO_P (XEXP (DECL_RTL (target->decl), 0)))
>> +return false;
>>
>> but found it breaks several vectorization testcases with LTO. This is
>> becuase notice_global_symbol computes DECL_RTL even before
>> node->increase_alignment is run and we are stuck.
>>
>> I decided to track this separately from this patch that snowballed quite a
>> bit
>> already. I do not see how to solve it short of making notice_global_symbol to
>> not compute DECL_RTL. It was never quite clear to me why
>> notice_global_symbol
>> is actually doing this at first place. Is it becuase of target mangling
>> happing only at RTL generation time?
>
> This is now PR65355
Your follow-up patch 88ada5e935d58223ae2d9ce6d0c1c71c372680a8 a.k.a r221269
added this to emit_local():
static bool
-emit_local (tree decl ATTRIBUTE_UNUSED,
+emit_local (tree decl,
const char *name ATTRIBUTE_UNUSED,
unsigned HOST_WIDE_INT size ATTRIBUTE_UNUSED,
unsigned HOST_WIDE_INT rounded ATTRIBUTE_UNUSED)
{
+ int align = symtab_node::get (decl)->definition_alignment ();
#if defined ASM_OUTPUT_ALIGNED_DECL_LOCAL
ASM_OUTPUT_ALIGNED_DECL_LOCAL (asm_out_file, decl, name,
-size, DECL_ALIGN (decl));
+size, align);
return true;
#elif defined ASM_OUTPUT_ALIGNED_LOCAL
- ASM_OUTPUT_ALIGNED_LOCAL (asm_out_file, name, size, DECL_ALIGN (decl));
+ ASM_OUTPUT_ALIGNED_LOCAL (asm_out_file, name, size, align);
return true;
#else
ASM_OUTPUT_LOCAL (asm_out_file, name, size, rounded);
return false;
#endif
}
which gives
gcc/varasm.c:1936:7: error: unused variable ‘align’ [-Werror=unused-variable]
int align = symtab_node::get (decl)->definition_alignment ();
^
on
log/alpha64-dec-vms
log/alpha-dec-vms
log/i686-cygwinOPT-enable-threads=yes
log/i686-mingw32crt
log/i686-openbsd3.0
log/i686-pc-msdosdjgpp
log/m68k-openbsd
Maybe just flag it as used or copy-move it?
TIA,
Re: C++ PATCH for c++/65554 (ICE with user-defined initializer_list)
On Wed, Apr 1, 2015 at 3:08 AM, Marek Polacek wrote: > On Tue, Mar 31, 2015 at 03:11:24PM -0400, Jason Merrill wrote: >> On 03/31/2015 01:22 PM, Marek Polacek wrote: >> >The user *should* have been using . But responding to >> >this >> >with an ICE isn't acceptable either. >> > >> >We do reject wholly incompatible user-defined initializer_list: >> >finish_struct >> >requires it be a template with a pointer field followed by an integer field, >> >and in this case it is, but convert_like_real assumes that the second >> >integer >> >field has a size_type, so it initializes the length with that type. But as >> >the >> >following testcase (which clang accepts) shows, it might be a different >> >integer >> >type, and gimplifier doesn't like any non-trivial conversion in an >> >assignment. >> >> I think I'd prefer to enforce that the second integer is size_t, not just an >> integer, so that the assumption in convert_like_real is correct. > > Ok, that isn't hard to do either. > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > 2015-04-01 Marek Polacek > > PR c++/65554 > * class.c (finish_struct): Require that the second field of a > user-defined initializer_list be of size type. > > * g++.dg/cpp0x/initlist93.C: New test. > * g++.dg/cpp0x/initlist94.C: New test. > This caused: FAIL: g++.dg/cpp0x/pr57101.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/cpp0x/pr57101.C -std=gnu++14 (test for excess errors) on 32 bit system. -- H.J.
Re: [PATCH] Fix PR ipa/65557
On Mon, Mar 30, 2015 at 3:19 PM, Martin Liška wrote: > On 03/30/2015 07:03 PM, Jan Hubicka wrote: >>> >>> Hello. >>> >>> Following patch fixed the issue, where we have to check if function >>> summary >>> for IPA CP has been already created. >>> >>> Tested on x86_64-linux-pc w/o any new regression introduced. >>> Ready for trunk? >>> >>> Thanks, >>> Martin >> >> >>> >From c33680093e67328863836a845e847bf1b1b23d0e Mon Sep 17 00:00:00 2001 >>> From: mliska >>> Date: Sun, 29 Mar 2015 20:20:33 +0200 >>> Subject: [PATCH] Fix PR65557. >>> >>> gcc/ChangeLog: >>> >>> 2015-03-29 Martin Liska >>> >>> PR ipa/65557 >>> * ipa-icf.c (sem_function::equals_wpa): Check if IPA CP >>> has already filled up function summary. >> >> >> OK, there is one extra occurence of flag_ipa_cp test, so please update it >> consistently. >> >> Honza >> > > Hi. > > You are right, there's one more occurrence of the usage. > I'm going to install the patch I've attached. > This caused: FAIL: g++.dg/torture/pr64378.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) FAIL: g++.dg/torture/pr64378.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) on x86-64. -- H.J.
Re: Fix increase_alignment
>
> Your follow-up patch 88ada5e935d58223ae2d9ce6d0c1c71c372680a8 a.k.a r221269
> added this to emit_local():
>
> static bool
> -emit_local (tree decl ATTRIBUTE_UNUSED,
> +emit_local (tree decl,
> const char *name ATTRIBUTE_UNUSED,
> unsigned HOST_WIDE_INT size ATTRIBUTE_UNUSED,
> unsigned HOST_WIDE_INT rounded ATTRIBUTE_UNUSED)
> {
> + int align = symtab_node::get (decl)->definition_alignment ();
> #if defined ASM_OUTPUT_ALIGNED_DECL_LOCAL
>ASM_OUTPUT_ALIGNED_DECL_LOCAL (asm_out_file, decl, name,
> -size, DECL_ALIGN (decl));
> +size, align);
>return true;
> #elif defined ASM_OUTPUT_ALIGNED_LOCAL
> - ASM_OUTPUT_ALIGNED_LOCAL (asm_out_file, name, size, DECL_ALIGN (decl));
> + ASM_OUTPUT_ALIGNED_LOCAL (asm_out_file, name, size, align);
>return true;
> #else
>ASM_OUTPUT_LOCAL (asm_out_file, name, size, rounded);
>return false;
> #endif
> }
>
> which gives
>
> gcc/varasm.c:1936:7: error: unused variable ‘align’ [-Werror=unused-variable]
>int align = symtab_node::get (decl)->definition_alignment ();
>^
>
> on
> log/alpha64-dec-vms
> log/alpha-dec-vms
> log/i686-cygwinOPT-enable-threads=yes
> log/i686-mingw32crt
> log/i686-openbsd3.0
> log/i686-pc-msdosdjgpp
> log/m68k-openbsd
>
> Maybe just flag it as used or copy-move it?
Yep, lets just move it into the ifdefs. Can you please check that the alignment
looks right atone of those targets? I am not quite sure who is supposed to
do so on targets not defining ASM_OUTPUT_ALIGNED_LOCAL.
Perhaps we want then to prvent vectorizer from updating the alignments.
Honza
>
> TIA,
Re: [PATCH] Disable ppc/spu context sensitive macros for CLK_ASM preprocessing (PR preprocessor/61977)
On Wed, Apr 1, 2015 at 4:40 AM, Jakub Jelinek wrote: > Hi! > > The context sensitive macros are inherently C/C++ specific, so trying to > expand them into anything when preprocessing assembler doesn't make any > sense to me. > > Ok for trunk? > > 2015-04-01 Jakub Jelinek > > PR preprocessor/61977 > * config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Don't > predefine __vector/__bool/__pixel macros nor context sensitive > macros for CLK_ASM. > * config/spu/spu-c.c (spu_cpu_cpp_builtins): Similarly. Okay. Thanks, David
Re: [PATCH, libmpx, i386, PR driver/65444] Pass '-z bndplt' when building dynamic objects with MPX
On 03/31/2015 03:47 AM, Ilya Enkovich wrote: On 23 Mar 13:19, Ilya Enkovich wrote: Hi, May this patch go into trunk at this point? It is very important for dynamic MPX codes. Thanks, Ilya I additionally documented changes in invoke.texi. OK for trunk? Thanks, Ilya -- gcc/ 2015-03-31 Ilya Enkovich PR driver/65444 * config/i386/linux-common.h (MPX_SPEC): New. (CHKP_SPEC): Add MPX_SPEC. * doc/invoke.texi (-fcheck-pointer-boudns): Document possible issues with '-z bndplt' support in linker. libmpx/ 2015-03-31 Ilya Enkovich PR driver/65444 * configure.ac: Add check for '-z bndplt' support by linker. Add link_mpx output variable. * libmpx.spec.in (link_mpx): New. * configure: Regenerate. Just to make sure I understand. With this patch we conditionally pass -z bndplt based on whether or not it's supported by the linker we find when we configure GCC. Failure to pass -z bndplt won't cause the program to misbehave, but will limit the effectiveness of MPX. Gold doesn't support -z bndplt, just newer versions of the BFD linker. Gold issues an error for -z bndplt, old BFD linkers will issue a warning. There are, at least in theory, use cases where we might not have a PLT and thus -z bndplt wouldn't make sense anyway. I guess the one thing I don't like here is that whether or not to pass -z bndplt is made at the time we configure GCC. Yet, it's trivial for someone to change the system linker later, either to gold or from an old BFD linker that doesn't support -z bndplt to one that does support -z bndplt. [ Note we have the same issue with certain assembler feature tests. ] I'm not aware of any real infrastructure in GCC to query the behavior of the linker at link time and then customize the options passed. So if it's going to be configurable, then that's the only time to do the test. I strongly disagree with HJ's assertion that we should always pass the flag, regardless of the underlying linker. So, in an ideal world, we'd query the linker at link time and pass the flag anytime we have a linker that supports the capability and perhaps warn if the linker doesn't support that capability. Given we're not in that ideal world, I think Ilya's patch is reasonable and should be installed. jeff
Re: Inliner badness metric tweak
> > This caused: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65654 I will look into it; the assert checks that the expected function growth match the real growth after inlining, so it is a semi-latent bug hit by this patch. Honza > > -- > H.J.
[RS6000] Fix 65576 regression
This cures an unrecognizable insn ICE by modifying a predicate of extenddftf2_internal (the only place this predicate is used) to ensure that rtl optimization passes do not substitute 0.0 for a register with known 0.0 value, except when VSX is enabled. ie. Don't undo the necessary register move emitted by the extenddftf2_fprs expander. Bootstrapped and regression tested powerpc64le-linux, powerpc64-linux and powerpc-linux. OK to apply? PR target/65576 PR target/65240 * config/rs6000/predicates.md (zero_reg_mem_operand): Exclude 0.0 constant unless TARGET_VSX. Index: gcc/config/rs6000/predicates.md === --- gcc/config/rs6000/predicates.md (revision 221805) +++ gcc/config/rs6000/predicates.md (working copy) @@ -964,7 +964,8 @@ ;; Return 1 if the operand is CONST_DOUBLE 0, register or memory operand. (define_predicate "zero_reg_mem_operand" - (ior (match_operand 0 "zero_fp_constant") + (ior (and (match_test "TARGET_VSX") + (match_operand 0 "zero_fp_constant")) (match_operand 0 "reg_or_mem_operand"))) ;; Return 1 if the operand is a CONST_INT and it is the element for 64-bit -- Alan Modra Australia Development Lab, IBM
