[PATCH] Fix ICE in redirect_jump_1 (PR inline-asm/63282)
Hi!
On the following testcase, dead_or_predicable decides to call
redirect_jump_1 on asm goto which has more than one label, but the
bb still has just two successors (one of the labels points to
code label at the start of the fallthru bb) and redirect_jump_1
ICEs on that.
Usually dead_or_predicable fails if !any_condjump_p, but there
is a shortcut (goto no_body) that bypasses that.
I think it doesn't really make sense to allow anything but normal
conditional jumps here, so the first patch just gives up in that
case. Have done instrumented bootstrap on
{i?86,x86_64,aarch64,armv7hl,ppc64,ppc64le,s390,s390x}-linux
with this and the added goto cancel didn't trigger in any of the
bootstraps, and triggered only on 1-3 testcases in the testsuite
which all had asm goto in them (one of them this newly added
testcase).
Alternately, the second patch turns an assert in redirect_jump_1
into return 0, so it will fail (that also fixes the testcase).
With that patch alone, I'm worried about dead_or_predicable calling
invert_jump_1 on asm goto, which I can't understand how it would work
(there is no way how the "condition" can be inverted). So, if
the second patch is preferable, I think dead_or_predicable should
still goto cancel if (reversep && !any_condjump_p (jump)). Or
invert_jump_1 should fail early if !any_condjump_p. Or both
of the patches could be applied together as is (of course, testcase
just from one of those).
2014-09-29 Jakub Jelinek
PR inline-asm/63282
* ifcvt.c (dead_or_predicable): Don't call redirect_jump_1
or invert_jump_1 if jump isn't any_condjump_p.
* gcc.c-torture/compile/pr63282.c: New test.
--- gcc/ifcvt.c.jj 2014-09-12 09:29:21.0 +0200
+++ gcc/ifcvt.c 2014-09-26 20:50:08.610965141 +0200
@@ -4357,6 +4357,9 @@ dead_or_predicable (basic_block test_bb,
old_dest = JUMP_LABEL (jump);
if (other_bb != new_dest)
{
+ if (!any_condjump_p (jump))
+ goto cancel;
+
if (JUMP_P (BB_END (dest_edge->src)))
new_dest_label = JUMP_LABEL (BB_END (dest_edge->src));
else if (new_dest == EXIT_BLOCK_PTR_FOR_FN (cfun))
--- gcc/testsuite/gcc.c-torture/compile/pr63282.c.jj2014-09-26
20:51:40.999482179 +0200
+++ gcc/testsuite/gcc.c-torture/compile/pr63282.c 2014-09-26
20:51:43.882467325 +0200
@@ -0,0 +1,13 @@
+/* PR inline-asm/63282 */
+
+void bar (void);
+
+void
+foo (void)
+{
+ asm volatile goto ("" : : : : a, b);
+a:
+ bar ();
+b:
+ return;
+}
Jakub
2014-09-26 Jakub Jelinek
PR inline-asm/63282
* jump.c (redirect_jump_1): If ASM_OPERANDS_LABEL_LENGTH (asmop)
is not 1, return 0.
* gcc.c-torture/compile/pr63282.c: New test.
--- gcc/jump.c.jj 2014-09-16 10:00:36.0 +0200
+++ gcc/jump.c 2014-09-26 20:54:46.174519857 +0200
@@ -1510,9 +1510,8 @@ redirect_jump_1 (rtx jump, rtx nlabel)
asmop = extract_asm_operands (PATTERN (jump));
if (asmop)
{
- if (nlabel == NULL)
+ if (nlabel == NULL || ASM_OPERANDS_LABEL_LENGTH (asmop) != 1)
return 0;
- gcc_assert (ASM_OPERANDS_LABEL_LENGTH (asmop) == 1);
loc = &ASM_OPERANDS_LABEL (asmop, 0);
}
else if (GET_CODE (PATTERN (jump)) == PARALLEL)
--- gcc/testsuite/gcc.c-torture/compile/pr63282.c.jj2014-09-26
20:51:40.999482179 +0200
+++ gcc/testsuite/gcc.c-torture/compile/pr63282.c 2014-09-26
20:51:43.882467325 +0200
@@ -0,0 +1,13 @@
+/* PR inline-asm/63282 */
+
+void bar (void);
+
+void
+foo (void)
+{
+ asm volatile goto ("" : : : : a, b);
+a:
+ bar ();
+b:
+ return;
+}
[committed] Fix alignment for OpenMP mapped array sections with non-zero bias (PR middle-end/63247)
Hi!
For OMP_CLAUSE_MAP_POINTER on arrays (rather than pointers), when the
bias is non-zero, we pass map those as a pointer mapping, so need
to request alignment of the pointer variable rather than the array
itself.
Fixed thusly, bootstrapped/tested on x86_64-linux and i686-linux,
committed to trunk/4.9.
2014-09-29 Jakub Jelinek
PR middle-end/63247
* omp-low.c (lower_omp_target): For OMP_CLAUSE_MAP_POINTER
of ARRAY_TYPE, if not OMP_CLAUSE_MAP_ZERO_BIAS_ARRAY_SECTION
use the alignment of avar rather than ovar.
--- gcc/omp-low.c.jj2014-09-22 12:13:21.0 +0200
+++ gcc/omp-low.c 2014-09-26 11:40:20.185658337 +0200
@@ -10117,6 +10117,9 @@ lower_omp_target (gimple_stmt_iterator *
continue;
}
+ unsigned int talign = TYPE_ALIGN_UNIT (TREE_TYPE (ovar));
+ if (DECL_P (ovar) && DECL_ALIGN_UNIT (ovar) > talign)
+ talign = DECL_ALIGN_UNIT (ovar);
if (nc)
{
tree var = lookup_decl_in_outer_ctx (ovar, ctx);
@@ -10131,6 +10134,7 @@ lower_omp_target (gimple_stmt_iterator *
= create_tmp_var (TREE_TYPE (TREE_TYPE (x)), NULL);
mark_addressable (avar);
gimplify_assign (avar, build_fold_addr_expr (var), &ilist);
+ talign = DECL_ALIGN_UNIT (avar);
avar = build_fold_addr_expr (avar);
gimplify_assign (x, avar, &ilist);
}
@@ -10183,9 +10187,6 @@ lower_omp_target (gimple_stmt_iterator *
default:
gcc_unreachable ();
}
- unsigned int talign = TYPE_ALIGN_UNIT (TREE_TYPE (ovar));
- if (DECL_P (ovar) && DECL_ALIGN_UNIT (ovar) > talign)
- talign = DECL_ALIGN_UNIT (ovar);
talign = ceil_log2 (talign);
tkind |= talign << 3;
CONSTRUCTOR_APPEND_ELT (vkind, purpose,
Jakub
RE: [PATCH][ARM] Fix -fcall-saved-rX for X > 7 with -Os -mthumb
Ping?
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent: Wednesday, August 20, 2014 9:28 AM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH][ARM] Fix -fcall-saved-rX for X > 7
>
> This patch makes -fcall-saved-rX for X > 7 on Thumb target when
> optimizing for size. It works by adding a new field
> x_user_set_call_save_regs in struct target_hard_regs to track whether
> an entry in fields x_fixed_regs, x_call_used_regs and
> x_call_really_used_regs was user set or is in its default value. Then it can
> decide whether to set a given high register as caller saved or not when
> optimizing for size based on this information.
>
> ChangeLog are as follows:
>
> *** gcc/ChangeLog ***
>
> 2014-08-15 Thomas Preud'homme
>
> * config/arm/arm.c (arm_conditional_register_usage): Only set high
> registers as caller saved when optimizing for size *and* the user did
> not asked otherwise through -fcall-saved-* switch.
> * hard-reg-set.h (x_user_set_call_save_regs): New.
> (user_set_call_save_regs): Define.
> * reginfo.c (init_reg_sets): Initialize user_set_call_save_regs.
> (fix_register): Indicate in user_set_call_save_regs that the value set
> in call_save_regs and fixed_regs is user set.
>
>
> *** gcc/testsuite/ChangeLog ***
>
> 2014-08-15 Thomas Preud'homme
>
> * gcc.target/arm/fcall-save-rhigh.c: New.
>
>
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index 2f8d327..8324fa3 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -30084,7 +30084,8 @@ arm_conditional_register_usage (void)
> stacking them. */
>for (regno = FIRST_HI_REGNUM;
> regno <= LAST_HI_REGNUM; ++regno)
> - fixed_regs[regno] = call_used_regs[regno] = 1;
> + if (!user_set_call_save_regs[regno])
> + fixed_regs[regno] = call_used_regs[regno] = 1;
> }
>
>/* The link register can be clobbered by any branch insn,
> diff --git a/gcc/hard-reg-set.h b/gcc/hard-reg-set.h
> index b8ab3df..b523637 100644
> --- a/gcc/hard-reg-set.h
> +++ b/gcc/hard-reg-set.h
> @@ -614,6 +614,11 @@ struct target_hard_regs {
>
>char x_call_really_used_regs[FIRST_PSEUDO_REGISTER];
>
> + /* Indexed by hard register number, contains 1 for registers
> + whose saving at function call was decided by the user
> + with -fcall-saved-*, -fcall-used-* or -ffixed-*. */
> + char x_user_set_call_save_regs[FIRST_PSEUDO_REGISTER];
> +
>/* The same info as a HARD_REG_SET. */
>HARD_REG_SET x_call_used_reg_set;
>
> @@ -685,6 +690,8 @@ extern struct target_hard_regs
> *this_target_hard_regs;
>(this_target_hard_regs->x_call_used_regs)
> #define call_really_used_regs \
>(this_target_hard_regs->x_call_really_used_regs)
> +#define user_set_call_save_regs \
> + (this_target_hard_regs->x_user_set_call_save_regs)
> #define call_used_reg_set \
>(this_target_hard_regs->x_call_used_reg_set)
> #define call_fixed_reg_set \
> diff --git a/gcc/reginfo.c b/gcc/reginfo.c
> index 7668be0..0b35f7f 100644
> --- a/gcc/reginfo.c
> +++ b/gcc/reginfo.c
> @@ -183,6 +183,7 @@ init_reg_sets (void)
>memcpy (call_really_used_regs, initial_call_really_used_regs,
> sizeof call_really_used_regs);
> #endif
> + memset (user_set_call_save_regs, 0, sizeof user_set_call_save_regs);
> #ifdef REG_ALLOC_ORDER
>memcpy (reg_alloc_order, initial_reg_alloc_order, sizeof
> reg_alloc_order);
> #endif
> @@ -742,6 +743,7 @@ fix_register (const char *name, int fixed, int
> call_used)
> if (fixed == 0)
> call_really_used_regs[i] = call_used;
> #endif
> + user_set_call_save_regs[i] = 1;
> }
> }
> }
> diff --git a/gcc/testsuite/gcc.target/arm/fcall-save-rhigh.c
> b/gcc/testsuite/gcc.target/arm/fcall-save-rhigh.c
> new file mode 100644
> index 000..a321a2b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/fcall-save-rhigh.c
> @@ -0,0 +1,10 @@
> +/* { dg-do compile } */
> +/* { dg-final { scan-assembler "mov\\s+r.\\s*,\\s*r8" } } */
> +/* { dg-require-effective-target arm_thumb1_ok } */
> +/* { dg-options "-Os -mthumb -mcpu=cortex-m0 -fcall-saved-r8" } */
> +
> +void
> +save_regs (void)
> +{
> + asm volatile ("" ::: "r7", "r8");
> +}
>
> Ok for trunk?
>
> Best regards,
>
> Thomas
>
>
Re: [PATCH 2/n] OpenMP 4.0 offloading infrastructure: LTO streaming
> 2014-09-27 Ilya Verbin
> Ilya Tocar
> Andrey Turetskiy
> Bernd Schmidt
> gcc/
> * cgraph.h (symtab_node): Add need_dump flag.
> * cgraphunit.c: Include lto-section-names.h.
> (initialize_offload): New function.
> (ipa_passes): Initialize offload and call ipa_write_summaries if there
> is something to write to OMP_SECTION_NAME_PREFIX sections.
> (symbol_table::compile): Call lto_streamer_hooks_init under flag_openmp.
> * ipa-inline-analysis.c (inline_generate_summary): Do not exit under
> flag_openmp.
> (inline_free_summary): Always remove hooks.
> * lto-cgraph.c (lto_set_symtab_encoder_in_partition): Exit if there is
> no need to encode the node.
> (referenced_from_other_partition_p, reachable_from_other_partition_p):
> Ignore references from non-target functions to target functions if we
> are streaming out target-side bytecode (offload lto mode).
> (select_what_to_dump): New function.
> * lto-section-names.h (OMP_SECTION_NAME_PREFIX): Define.
> (section_name_prefix): Declare.
> * lto-streamer.c (offload_lto_mode): New variable.
> (section_name_prefix): New variable.
> (lto_get_section_name): Use section_name_prefix instead of
> LTO_SECTION_NAME_PREFIX.
> * lto-streamer.h (select_what_to_dump): Declare.
> (offload_lto_mode): Declare.
> * omp-low.c (is_targetreg_ctx): New function.
> (create_omp_child_function, check_omp_nesting_restrictions): Use it.
> (expand_omp_target): Set mark_force_output for the target functions.
> (lower_omp_critical): Add target attribute for omp critical symbol.
> * passes.c (ipa_write_summaries): Call select_what_to_dump.
> gcc/lto/
> * lto-object.c (lto_obj_add_section): Use section_name_prefix instead of
> LTO_SECTION_NAME_PREFIX.
> * lto-partition.c (add_symbol_to_partition_1): Always set
> node->need_dump to true.
> (lto_promote_cross_file_statics): Call select_what_to_dump.
> * lto.c (lto_section_with_id): Use section_name_prefix instead of
> LTO_SECTION_NAME_PREFIX.
> (read_cgraph_and_symbols): Read OMP_SECTION_NAME_PREFIX sections, if
> being built as an offload compiler.
>
> Thanks,
> -- Ilya
>
> ---
>
> diff --git a/gcc/cgraph.h b/gcc/cgraph.h
> index 7481906..9ab970d 100644
> --- a/gcc/cgraph.h
> +++ b/gcc/cgraph.h
> @@ -444,6 +444,11 @@ public:
>/* Set when init priority is set. */
>unsigned in_init_priority_hash : 1;
>
> + /* Set when symbol needs to be dumped into LTO bytecode for LTO,
> + or in pragma omp target case, for separate compilation targeting
> + a different architecture. */
> + unsigned need_dump : 1;
dump for me implied debug dump. LTO is usually called streaming, so prehaps
need_lto_stremaing?
> +/* Check whether there is at least one function or global variable to
> offload.
> + */
> +
> +static bool
> +initialize_offload (void)
Perhaps have_offload_p? Nothing is initialized here...
> +{
> + bool have_offload = false;
> + struct cgraph_node *node;
> + struct varpool_node *vnode;
> +
> + FOR_EACH_DEFINED_FUNCTION (node)
> +if (lookup_attribute ("omp declare target", DECL_ATTRIBUTES
> (node->decl)))
> + {
> + have_offload = true;
> + break;
> + }
> +
> + FOR_EACH_DEFINED_VARIABLE (vnode)
> +{
> + if (!lookup_attribute ("omp declare target",
> + DECL_ATTRIBUTES (vnode->decl))
> + || TREE_CODE (vnode->decl) != VAR_DECL
> + || DECL_SIZE (vnode->decl) == 0)
> + continue;
> + have_offload = true;
> +}
> +
> + return have_offload;
> +}
> +
> static void
> ipa_passes (void)
> {
> + bool have_offload = false;
>gcc::pass_manager *passes = g->get_passes ();
>
>set_cfun (NULL);
> @@ -2004,6 +2036,14 @@ ipa_passes (void)
>gimple_register_cfg_hooks ();
>bitmap_obstack_initialize (NULL);
>
> + if (!in_lto_p && flag_openmp)
> +{
> + have_offload = initialize_offload ();
> + /* OpenMP offloading requires LTO infrastructure. */
> + if (have_offload)
> + flag_generate_lto = 1;
> +}
> +
>invoke_plugin_callbacks (PLUGIN_ALL_IPA_PASSES_START, NULL);
>
>if (!in_lto_p)
> @@ -2041,7 +2081,20 @@ ipa_passes (void)
> targetm.asm_out.lto_start ();
>
>if (!in_lto_p)
> -ipa_write_summaries ();
> +{
> + if (have_offload)
> + {
> + offload_lto_mode = true;
> + section_name_prefix = OMP_SECTION_NAME_PREFIX;
> + ipa_write_summaries ();
> + }
> + if (flag_lto)
> + {
> + offload_lto_mode = false;
> + section_name_prefix = LTO_SECTION_NAME_PREFIX;
> + ipa_write_summaries ();
> + }
How does LTO combine with offloading?
> @@ -4325,11 +4325,6 @@ void
> inline_free_summary (void)
> {
>struct cgraph_node *node;
> - if (!inline_edge_summary_vec.exists ())
> -return
Re: [PATCH C++] - SD-6 Implementation Part 1 - __has_include.
On 09/25/2014 12:57 PM, Jason Merrill wrote:
On 09/01/2014 09:34 PM, Ed Smith-Rowland wrote:
(open_file_failed()): Not an error to not find a header file for
__has_include__.
Hmm, looks like this means that __has_include__ will silently return
false if a header exists but is unreadable; I would think that we want
it to be true (and have an error when the user tries to include it).
Jason
I have changed __has_include__ to return true if a header exists but is
unreadable. Then I tried to see if an error would occur for a header of
permission 000.
Just including it gives a permission error. Putting it into an #if
block does not.
---
ed@bad-horse:~/tr2$ ls -l hidden.h
-- 1 ed ed 0 Sep 26 10:27 hidden.h
---
// Try header that exists but we can't read.
#if __has_include("hidden.h")
# warning "found hidden.h"
# include "hidden.h" // No error!
#else
# error "hidden.h"
#endif
#if 1
# include "hidden.h" // No error!
#endif
---
Is this a bug in cpp?
I'm going to submit new patches that answer all your questions. As far
as this one goes I do no worse than current behavior.
As for [[deprecated]] for C++11 I'll add another patch on top of the four.
Ed
Re: [RFC: Patch, PR 60102] [4.9/4.10 Regression] powerpc fp-bit ices@dwf_regno
On Mon, 4 Aug 2014, Edmar wrote: > Committed on trunk, revision 213596 > Committed on 4.9 branch, revision 213597 This change regressed GDB for e500v2 multilibs, presumably because it does not understand the new DWARF register numbers and does not know how to map them to hardware registers. Here's the full list of regressions observed: FAIL: gdb.base/store.exp: var double l; print old l, expecting -1 FAIL: gdb.base/store.exp: var double l; print old r, expecting -2 FAIL: gdb.base/store.exp: var double l; print incremented l, expecting 2 FAIL: gdb.base/store.exp: var doublest l; print old l, expecting -1 FAIL: gdb.base/store.exp: var doublest l; print old r, expecting -2 FAIL: gdb.base/store.exp: var doublest l; print new l, expecting 4 FAIL: gdb.base/store.exp: var doublest l; print incremented l, expecting 2 FAIL: gdb.base/store.exp: upvar double l; print old l, expecting -1 FAIL: gdb.base/store.exp: upvar double l; print old r, expecting -2 UNRESOLVED: gdb.base/store.exp: upvar double l; set l to 4 UNRESOLVED: gdb.base/store.exp: upvar double l; print new l, expecting 4 FAIL: gdb.base/store.exp: upvar doublest l; print old l, expecting -1 FAIL: gdb.base/store.exp: upvar doublest l; print old r, expecting -2 UNRESOLVED: gdb.base/store.exp: upvar doublest l; set l to 4 UNRESOLVED: gdb.base/store.exp: upvar doublest l; print new l, expecting 4 These tests all used to score a PASS status. Do you plan to address this problem anyhow? Maciej
Re: RFA: one more version of the patch for PR61360
On Fri, Sep 26, 2014 at 10:31 PM, Vladimir Makarov wrote: > I guess we achieved the consensus about the following patch to fix PR61360 > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61360 > > The patch was successfully bootstrapped and tested (w/wo -march=amdfam10) on > x86/x86-64. > > Is it ok to commit to trunk? > > 2014-09-26 Vladimir Makarov > > PR target/61360 > * lra.c (lra): Remove call of recog_init. > * recog.c (constrain_operands): Permit reg for memory constraint > when LRA is used. > * config/i386/i386.md (*float2_sse): > Enable first alternative independently on RA stage. Please also mention that this patch reverts: 2014-04-01 Richard Henderson PR target/60704 * config/i386/i386.md (*float2_sse): Leave the second alternative enabled before register allocation. The x86 part is OK. BTW: I think that this patch should also be backported to 4.9 branch, since the original patch and the PR60704 fix were also installed there. Thanks, Uros.
[committed] Fix ICE in pa_output_function_epilogue
The attached change fixes a segmentation fault that occurs building
llvm-toolchain-3.4.
Tested on hppa-unknown-linux-gnu. Committed to trunk, 4.9 and 4.8
branches.
Dave
--
John David Anglin dave.ang...@bell.net
2014-09-28 John David Anglin
* config/pa/pa.c (pa_output_function_epilogue): Only update
last_address when a nonnote insn is found.
Index: config/pa/pa.c
===
--- config/pa/pa.c (revision 215649)
+++ config/pa/pa.c (working copy)
@@ -4208,9 +4208,12 @@
{
last_address = extra_nop ? 4 : 0;
insn = get_last_nonnote_insn ();
- last_address += INSN_ADDRESSES (INSN_UID (insn));
- if (INSN_P (insn))
- last_address += insn_default_length (insn);
+ if (insn)
+ {
+ last_address += INSN_ADDRESSES (INSN_UID (insn));
+ if (INSN_P (insn))
+ last_address += insn_default_length (insn);
+ }
last_address = ((last_address + FUNCTION_BOUNDARY / BITS_PER_UNIT - 1)
& ~(FUNCTION_BOUNDARY / BITS_PER_UNIT - 1));
}
Re: [jit] Add a test of using very long names
On Sep 26, 2014, at 12:31 PM, David Malcolm wrote:
> On Fri, 2014-09-26 at 11:45 -0700, Mike Stump wrote:
>> On Sep 26, 2014, at 8:14 AM, David Malcolm
>> wrote:
>>> * jit.dg/test-long-names.c: New test case.
>>
>>> +/* 65KB */
>>> +#define NAME_LENGTH (65 * 1024)
>>
>> 65K was a tiny name back in 1999, 16M was a large name then. Today,
>> 16M is tiny enough. And yeah, this was a customer bug report, just
>> normal C++ code with template manglings back then and yeah, we fixed
>> the bug and tested it out to 16M to ensure we would not hit another
>> bug in the next decade. As far as I know, we didn’t. If you want to
>> ensure it works nicely for the next decade test out to, say, 128M and
>> then throw that test case away. I’d be curious if you hit any
>> problems at 128M.
>
> Out of curiosity I tried upping NAME_LENGTH to 129M.
>
> The compiler handled it fine, but FWIW "as" seems to be stuck here
:-( Then, it doesn’t work.
I’d report the as bug. Also, you might try binary searching for the limit.
Hopefully 16M works just fine. If it doesn’t, then someone broke it recently.
I tested a simple program on my machine and got it up to 31M for gcc and 512M
for clang. gcc died as 32M. clang, well, I grew impatient waiting for the
compile times. 512M should bee good for the next 100 years I suspect. 31M is
likely fine for the next 2 decades, though, that bug should be fixed.
gcc died like this for me:
gcc: internal compiler error: Illegal instruction: 4 (program cc1)
:-(
$ cat t.c
#include
/* gcc works to 31, fails as 32, clang goes beyond 512 */
#define M 32*1024*1024
char buf[M+1];
int main() {
int i;
for (i = 0; i < M; ++i)
buf[i] = '0';
printf ("#include \n\
\n\
int i%s;\n\
\n\
int main() {\n\
++i%s;\n\
return 0;\n\
}\n\
", buf, buf);
return 0;
}
[PATCH] Add test case for "((void (*)(void)) 0)()"
For the original microblaze, it will report error with "-O0" (and other
flags are all OK).
gcc/testsuite/:
2014-09-28 Chen Gang
* gcc.c-torture/compile/calls-void.c: New test.
---
gcc/testsuite/gcc.c-torture/compile/calls-void.c | 23 +++
1 file changed, 23 insertions(+)
create mode 100644 gcc/testsuite/gcc.c-torture/compile/calls-void.c
diff --git a/gcc/testsuite/gcc.c-torture/compile/calls-void.c
b/gcc/testsuite/gcc.c-torture/compile/calls-void.c
new file mode 100644
index 000..a8dacd7
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/calls-void.c
@@ -0,0 +1,23 @@
+/* { dg-require-effective-target ptr32plus } */
+typedef void (*T)(void);
+f1 ()
+{
+ ((T) 0)();
+}
+f2 ()
+{
+ ((T) 1000)();
+}
+f3 ()
+{
+ ((T) 1000)();
+}
+f4 (r)
+{
+ ((T) r)();
+}
+f5 ()
+{
+ int (*r)() = f3;
+ ((T) r)();
+}
--
1.9.3
Re: [fortran,patch] Forbid assignment of different character kinds
Hi FX, FX wrote: When I added support for nondefault initial character kinds, I thought they could be assigned freely to each other. It turns out it’s not the case: Am am vaguely remembering that some interpretation request/change now allows this. And if I look at the current Fortran 2015 draft, I find "For an intrinsic assignment statement where the variable is of type character, if expr has a different kind type parameter, each character c in expr is converted to the kind type parameterof the variable by ACHAR(IACHAR(c), KIND(variable))" See http://j3-fortran.org/doc/year/14/14-007r2.pdf, "7.2.1.3 Interpretation of intrinsic assignments", paragraph 11. I have rechecked Fortran 2008 (10-007) - and it has the same wording. It could be either already F2003 - added in some corrigendum or Fortran 2008 – feel free to check the corrigenda: https://gcc.gnu.org/wiki/GFortranStandards Tobias
[PATCH v2] Fix signed integer overflow in gcc/data-streamer.c
On 2014.09.28 at 14:36 +0200, Steven Bosscher wrote:
>
> Can you use HOST_WIDE_INT_1U for this?
Sure. Thanks for the suggestion.
(Fix now resembles similar idiom in data-streamer-in.c)
2014-09-28 Markus Trippelsdorf
* data-streamer.c (bp_unpack_var_len_int): Avoid signed
integer overflow.
diff --git a/gcc/data-streamer.c b/gcc/data-streamer.c
index 0e19c72162aa..785beb5165fa 100644
--- a/gcc/data-streamer.c
+++ b/gcc/data-streamer.c
@@ -110,7 +110,7 @@ bp_unpack_var_len_int (struct bitpack_d *bp)
if ((half_byte & 0x8) == 0)
{
if ((shift < HOST_BITS_PER_WIDE_INT) && (half_byte & 0x4))
- result |= - ((HOST_WIDE_INT)1 << shift);
+ result |= - (HOST_WIDE_INT_1U << shift);
return result;
}
--
Markus
Re: [PATCH] Fix signed integer overflow in gcc/data-streamer.c
On Sun, Sep 28, 2014 at 2:22 PM, Markus Trippelsdorf wrote:
> Running the testsuite with a -fsanitize=undefined instrumented compiler
> shows:
> % gcc -O2 -flto -fno-use-linker-plugin -flto-partition=none
> testsuite/gcc.dg/torture/pr28045.c
> gcc/data-streamer.c:113:45: runtime error: negation of -9223372036854775808
> cannot be represented in type 'long int'; cast to an unsigned type to negate
> this value to itself
>
> The fix is obvious.
>
> Boostrapped and tested on x86_64-unknown-linux-gnu.
> OK for trunk?
> Thanks.
>
> 2014-09-28 Markus Trippelsdorf
>
> * data-streamer.c (bp_unpack_var_len_int): Avoid signed
> integer overflow.
>
> diff --git a/gcc/data-streamer.c b/gcc/data-streamer.c
> index 0e19c72162aa..0760ed590c22 100644
> --- a/gcc/data-streamer.c
> +++ b/gcc/data-streamer.c
> @@ -110,7 +110,7 @@ bp_unpack_var_len_int (struct bitpack_d *bp)
>if ((half_byte & 0x8) == 0)
> {
> if ((shift < HOST_BITS_PER_WIDE_INT) && (half_byte & 0x4))
> - result |= - ((HOST_WIDE_INT)1 << shift);
> + result |= - ((unsigned HOST_WIDE_INT)1 << shift);
>
> return result;
> }
Can you use HOST_WIDE_INT_1U for this?
Ciao!
Steven
[PATCH] Fix signed integer overflow in gcc/data-streamer.c
Running the testsuite with a -fsanitize=undefined instrumented compiler
shows:
% gcc -O2 -flto -fno-use-linker-plugin -flto-partition=none
testsuite/gcc.dg/torture/pr28045.c
gcc/data-streamer.c:113:45: runtime error: negation of -9223372036854775808
cannot be represented in type 'long int'; cast to an unsigned type to negate
this value to itself
The fix is obvious.
Boostrapped and tested on x86_64-unknown-linux-gnu.
OK for trunk?
Thanks.
2014-09-28 Markus Trippelsdorf
* data-streamer.c (bp_unpack_var_len_int): Avoid signed
integer overflow.
diff --git a/gcc/data-streamer.c b/gcc/data-streamer.c
index 0e19c72162aa..0760ed590c22 100644
--- a/gcc/data-streamer.c
+++ b/gcc/data-streamer.c
@@ -110,7 +110,7 @@ bp_unpack_var_len_int (struct bitpack_d *bp)
if ((half_byte & 0x8) == 0)
{
if ((shift < HOST_BITS_PER_WIDE_INT) && (half_byte & 0x4))
- result |= - ((HOST_WIDE_INT)1 << shift);
+ result |= - ((unsigned HOST_WIDE_INT)1 << shift);
return result;
}
--
Markus
[fortran,patch] Forbid assignment of different character kinds
Hi all, When I added support for nondefault initial character kinds, I thought they could be assigned freely to each other. It turns out it’s not the case: this is PR 37173. The attached patch simplifies the front-end by dropping support for conversion: then, the generic conversion code generates a sensible error message. I also fixed some testcases (including some co-array testing), and removed two of them that only exercised this specific aspect. Tobias: I think the CAF library could also be simplified by dropping this nonfeature, but I don’t know it well (have never built it, used it or tested it) to do so. Bootstrapped and regtested on x86_64-apple-darwin14. OK to commit? FX PS: given the little feedback we get on that feature, I suppose nobody actually uses nondefault character kinds. Just like it seems nobody uses the IEEE modules (no feedback received, at all, since implementation). I suppose that makes me the kind of implementing useless standard features. What’s next? char_convert.ChangeLog Description: Binary data char_convert.diff Description: Binary data
