[PATCH] Fix Asan ICEs on unexpected types (PR62140, PR61897)

[Yury Gribov]

Hi all,

Asan pass currently ICEs if it sees int arguments used in 
memcmp/memset/etc. functions (it expects uintptr_t there). Attached 
patch fixes this.


Related bugreports:
* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62140
* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61897

Ok to commit?

BTW regarding ChangeLog: should I mention both bugs (they are 
duplicates) or just one of them?


-Y
commit e3324d8d3528f0cb1a56e784f0887a4743a3e0f2
Author: Yury Gribov 
Date:   Wed Aug 20 13:56:03 2014 +0400

2014-08-22  Yury Gribov  

gcc/
	PR sanitizer/62140
	* asan.c (asan_mem_ref_get_end): Handle non-ptroff_t lengths.
	(build_check_stmt): Likewise.
	(instrument_strlen_call): Likewise.
	(asan_expand_check_ifn): Likewise and fix types.
	(maybe_cast_to_ptrmode): New function.

gcc/testsuite/
	PR sanitizer/62140
	* c-c++-common/asan/pr62140-1.c: New test.
	* c-c++-common/asan/pr62140-2.c: New test.

diff --git a/gcc/asan.c b/gcc/asan.c
index 15c0737..ea1d3eb 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -318,6 +318,9 @@ asan_mem_ref_get_end (tree start, tree len)
   if (len == NULL_TREE || integer_zerop (len))
 return start;
 
+  if (!ptrofftype_p (len))
+len = convert_to_ptrofftype (len);
+
   return fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (start), start, len);
 }
 
@@ -1553,6 +1556,27 @@ maybe_create_ssa_name (location_t loc, tree base, gimple_stmt_iterator *iter,
   return gimple_assign_lhs (g);
 }
 
+/* LEN can already have necessary size and precision;
+   in that case, do not create a new variable.  */
+
+tree
+maybe_cast_to_ptrmode (location_t loc, tree len, gimple_stmt_iterator *iter,
+		   bool before_p)
+{
+  if (ptrofftype_p (len))
+return len;
+  gimple g
+= gimple_build_assign_with_ops (NOP_EXPR,
+make_ssa_name (pointer_sized_int_node, NULL),
+len, NULL);
+  gimple_set_location (g, loc);
+  if (before_p)
+gsi_insert_before (iter, g, GSI_SAME_STMT);
+  else
+gsi_insert_after (iter, g, GSI_NEW_STMT);
+  return gimple_assign_lhs (g);
+}
+
 /* Instrument the memory access instruction BASE.  Insert new
statements before or after ITER.
 
@@ -1598,7 +1622,10 @@ build_check_stmt (location_t loc, tree base, tree len,
   base = maybe_create_ssa_name (loc, base, &gsi, before_p);
 
   if (len)
-len = unshare_expr (len);
+{
+  len = unshare_expr (len);
+  len = maybe_cast_to_ptrmode (loc, len, iter, before_p);
+}
   else
 {
   gcc_assert (size_in_bytes != -1);
@@ -1804,6 +1831,7 @@ instrument_mem_region_access (tree base, tree len,
 static bool
 instrument_strlen_call (gimple_stmt_iterator *iter)
 {
+  gimple g;
   gimple call = gsi_stmt (*iter);
   gcc_assert (is_gimple_call (call));
 
@@ -1812,6 +1840,8 @@ instrument_strlen_call (gimple_stmt_iterator *iter)
 	  && DECL_BUILT_IN_CLASS (callee) == BUILT_IN_NORMAL
 	  && DECL_FUNCTION_CODE (callee) == BUILT_IN_STRLEN);
 
+  location_t loc = gimple_location (call);
+
   tree len = gimple_call_lhs (call);
   if (len == NULL)
 /* Some passes might clear the return value of the strlen call;
@@ -1820,28 +1850,28 @@ instrument_strlen_call (gimple_stmt_iterator *iter)
 return false;
   gcc_assert (INTEGRAL_TYPE_P (TREE_TYPE (len)));
 
-  location_t loc = gimple_location (call);
+  len = maybe_cast_to_ptrmode (loc, len, iter, /*before_p*/false);
+
   tree str_arg = gimple_call_arg (call, 0);
   bool start_instrumented = has_mem_ref_been_instrumented (str_arg, 1);
 
   tree cptr_type = build_pointer_type (char_type_node);
-  gimple str_arg_ssa =
-gimple_build_assign_with_ops (NOP_EXPR,
-  make_ssa_name (cptr_type, NULL),
-  str_arg, NULL);
-  gimple_set_location (str_arg_ssa, loc);
-  gsi_insert_before (iter, str_arg_ssa, GSI_SAME_STMT);
-
-  build_check_stmt (loc, gimple_assign_lhs (str_arg_ssa), NULL_TREE, 1, iter,
+  g = gimple_build_assign_with_ops (NOP_EXPR,
+make_ssa_name (cptr_type, NULL),
+str_arg, NULL);
+  gimple_set_location (g, loc);
+  gsi_insert_before (iter, g, GSI_SAME_STMT);
+  str_arg = gimple_assign_lhs (g);
+
+  build_check_stmt (loc, str_arg, NULL_TREE, 1, iter,
 		/*is_non_zero_len*/true, /*before_p=*/true,
 		/*is_store=*/false, /*is_scalar_access*/true, /*align*/0,
 		start_instrumented, start_instrumented);
 
-  gimple g =
-gimple_build_assign_with_ops (POINTER_PLUS_EXPR,
-  make_ssa_name (cptr_type, NULL),
-  gimple_assign_lhs (str_arg_ssa),
-  len);
+  g = gimple_build_assign_with_ops (POINTER_PLUS_EXPR,
+make_ssa_name (cptr_type, NULL),
+str_arg,
+len);
   gimple_set_location (g, loc);
   gsi_insert_after (iter, g, GSI_NEW_STMT);
 
@@ -2470,9 +2500,6 @@ asan_expand_check_ifn (gimple_stmt_iterator *iter, bool use_calls)
 
   HOST_WIDE_INT real_size_in_bytes = size_in_bytes == -1 ? 1 : size_in_bytes;
 
-  tree uintptr_type
-= build_nonstandard_integer_type (TYPE_PRECISION (TREE_TYPE (base)), 1);
-
   tree shadow_ptr_t

Re: [PATCH] Fix Asan ICEs on unexpected types (PR62140, PR61897)

[Yury Gribov]

On 08/22/2014 12:47 PM, Yury Gribov wrote:

Attached patch fixes this.


As usual I forgot to mention tests: this was bootstrapped on x64 and 
regtested for x64 and i686 and also Asan-bootstrapped for x64.


-Y

[BUILDROBOT] Ann: config-list.mk backend updated (was: [jbg...@lug-owl.de: Re: r214024 ...])

[Jan-Benedict Glaw]

On Sun, 2014-08-17 14:05:24 +0200, Manuel López-Ibáñez  
wrote:
[...]
> In config-list.mk, it says "Make sure you have a recent enough gcc
> (with ada support) in your path so that --enable-werror-always will
> work" For this commit in particular, recent enough means "exactly the
> same revision". Otherwise, --enable-werror-always won't work. And you
> cannot build that compiler with --enable-werror-always. See also:
> https://gcc.gnu.org/ml/gcc/2014-01/msg00157.html
> 
> I think that for a build-bot it would be better to bootstrap the
> compiler for the current target once (without --enable-werror-always),
> then use that compiler to build the rest minus the current target
> (with --enable-werror-always). This could be done within
> config-list.mk or from another script.

I just finished my preliminary testing of buildrobot's backend scripts
(for the config-list.mk builds) last night and enabled it on gcc76.

  Gcc76 will now always build a fresh native GCC, and then try to
build a cross-compiler with this exact version. Though the scheduler
will take some time to adopt to the new timings (and I think about
just scheduling the two backend types separately), but it's running
now and we can be keen for the results.

  Thanks for giving me some hints here, that was quite valueable!

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
 Signature of:Arroganz verkürzt fruchtlose Gespräche.
 the second  :   -- Jan-Benedict Glaw


signature.asc
Description: Digital signature

[PATCHv2][MIPS] Implement O32 ABI extensions (GCC)

[Matthew Fortune]

Updated patch covering all comments from the previous thread:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00401.html

This patch has merged together the odd-spreg work with the other ABI
work as these two features are now inseparable due to the inclusion of
a 4th FP ABI variant called FP64A. The wiki page describing these
extensions has been updated and the patch is consistent with the
features.

https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking

It is worth noting that LLVM 3.5 will include all ABI extensions
described in the wiki page with consistent options and behaviour.

The vast majority of this patch has been reviewed in detail already and
testing has been ongoing for some time within teams at Imagination.
This code has also been released for inclusion in the next Android NDK.

I have addressed one of the final concerns from Richard and Maciej
regarding an inconsistency between the prologue FP callee-save and
fixed-regs. I opted to resolve this in a very focussed manner to just
address the impact of fixed-regs rather than the more general issue
of occasionally saving more state than absolutely required. If there
is a desire to improve this further then I am very keen to leave that
to a future patch.

This work has been tested for both bare metal and linux based targets.
There are no regressions.

This patch is dependent on two patches which are awaiting approval:

"Add target hook to override DWARF2 frame register size
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01748.html

"Do not reload unallocated FP_REGS pseudos via GR_REGS"
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01745.html

Regards,
Matthew

2014-07-31  Matthew Fortune  

gcc/
* common/config/mips/mips-common.c (mips_handle_option): Ensure
that -mfp32, -mfp64 disable -mfpxx and -mfpxx disables -mfp64.
* config.gcc (--with-fp-32): New option.
(--with-odd-spreg-32): Likewise.
* config.in (HAVE_AS_MODULE): New config define.
* config/mips/mips-protos.h
(mips_secondary_memory_needed): New prototype.
(mips_hard_regno_caller_save_mode): Likewise.
* config/mips/mips.c (mips_get_reg_raw_mode): New static prototype.
(mips_get_arg_info): Assert that V2SFmode is only handled specially
with TARGET_PAIRED_SINGLE_FLOAT.
(mips_return_mode_in_fpr_p): Likewise.
(mips16_call_stub_mode_suffix): Likewise.
(mips_get_reg_raw_mode): New static function.
(mips_return_fpr_pair): O32 return values span two registers.
(mips16_build_call_stub): Likewise.
(mips_function_value_regno_p): Support both FP return registers.
(mips_output_64bit_xfer): Use mthc1 whenever TARGET_HAS_MXHC1.  Add
specific cases for TARGET_FPXX to move via memory.
(mips_dwarf_register_span): For TARGET_FPXX pretend that modes larger
than UNITS_PER_FPREG 'span' one register.
(mips_dwarf_frame_reg_mode): New static function.
(mips_file_start): Switch to using .module instead of .gnu_attribute.
No longer support FP ABI 4 (-mips32r2 -mfp64), replace with FP ABI 6.
Add FP ABI 5 (-mfpxx) and FP ABI 7 (-mfp64 -mno-odd-spreg).
(mips_save_reg, mips_restore_reg): Always represent DFmode frame
slots with two CFI directives even for O32 FP64.
(mips_for_each_saved_gpr_and_fpr): Account for fixed_regs when
saving/restoring callee-saved registers.
(mips_hard_regno_mode_ok_p): Implement O32 FP64A extension.
(mips_secondary_memory_needed): New function.
(mips_option_override): ABI check for TARGET_FLOATXX.  Disable
odd-numbered single-precision registers when using TARGET_FLOATXX.
Implement -modd-spreg and defaults.
(mips_conditional_register_usage): Redefine O32 FP64 to match O32 FP32
callee-saved behaviour.
(mips_hard_regno_caller_save_mode): Implement.
(TARGET_GET_RAW_RESULT_MODE): Define target hook.
(TARGET_GET_RAW_ARG_MODE): Define target hook.
(TARGET_DWARF_FRAME_REG_MODE): Define target hook.
* config/mips/mips.h (TARGET_FLOAT32): New macro.
(TARGET_CPU_CPP_BUILTINS): TARGET_FPXX is __mips_fpr==0. Add
_MIPS_SPFPSET builtin define.
(MIPS_FPXX_OPTION_SPEC): New macro.
(OPTION_DEFAULT_SPECS): Pass through --with-fp-32=* to -mfp and
--with-odd-spreg-32=* to -m[no-]odd-spreg.
(ISA_HAS_ODD_SPREG): New macro.
(ISA_HAS_MXHC1): True for anything other than -mfp32.
(ASM_SPEC): Pass through mfpxx, mfp64, -mno-odd-spreg and -modd-spreg.
(MIN_FPRS_PER_FMT): Redefine in terms of TARGET_ODD_SPREG.
(HARD_REGNO_CALLER_SAVE_MODE): Define.  Implement O32 FPXX extension
(HARD_REGNO_CALL_PART_CLOBBERED): Likewise.
(SECONDARY_MEMORY_NEEDED): Likewise.
(FUNCTION_ARG_REGNO_P): Update for O32 FPXX and FP64 extensions.
* config/mips/mips.md (define_attr enabled): Impleme

[PATCH i386 AVX512] [21/n] Extend variable shift patterns.

[Kirill Yukhin]

Hello,
This patch extends shift patterns with per-element
shift value. It was adopted by approach suggested
in previous patches.

Bootstrapped.
New tests on top of patch-set all pass
under simulator.

Is it ok for trunk?

gcc/
* config/i386/sse.md
(define_mode_iterator VI48_AVX2_48_AVX512F): Delete.
(define_mode_iterator VI48_AVX512BW): New.
(define_insn "_v"): Delete.
(define_insn "_v"
with VI48_AVX2_48_AVX512F): New.
(define_insn "_v"
with VI2_AVX512VL): Ditto.

--
Thanks, K

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 5084892..cd0c08e 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -359,9 +359,9 @@
(V8SI "TARGET_AVX2") V4SI
(V8DI "TARGET_AVX512F") (V4DI "TARGET_AVX2") V2DI])
 
-(define_mode_iterator VI48_AVX2_48_AVX512F
-  [(V16SI "TARGET_AVX512F") (V8SI "TARGET_AVX2") V4SI
-   (V8DI "TARGET_AVX512F") (V4DI "TARGET_AVX2") V2DI])
+(define_mode_iterator VI48_AVX512F
+  [(V16SI "TARGET_AVX512F") V8SI V4SI
+   (V8DI "TARGET_AVX512F") V4DI V2DI])
 
 (define_mode_iterator V48_AVX2
   [V4SF V2DF
@@ -15320,17 +15320,28 @@
(set_attr "prefix" "maybe_evex")
(set_attr "mode" "")])
 
-(define_insn "_v"
-  [(set (match_operand:VI48_AVX2_48_AVX512F 0 "register_operand" "=v")
-   (any_lshift:VI48_AVX2_48_AVX512F
- (match_operand:VI48_AVX2_48_AVX512F 1 "register_operand" "v")
- (match_operand:VI48_AVX2_48_AVX512F 2 "nonimmediate_operand" "vm")))]
+(define_insn "_v"
+  [(set (match_operand:VI48_AVX512F 0 "register_operand" "=v")
+   (any_lshift:VI48_AVX512F
+ (match_operand:VI48_AVX512F 1 "register_operand" "v")
+ (match_operand:VI48_AVX512F 2 "nonimmediate_operand" "vm")))]
   "TARGET_AVX2 && "
   "vpv\t{%2, %1, %0|%0, 
%1, %2}"
   [(set_attr "type" "sseishft")
(set_attr "prefix" "maybe_evex")
(set_attr "mode" "")])
 
+(define_insn "_v"
+  [(set (match_operand:VI2_AVX512VL 0 "register_operand" "=v")
+   (any_lshift:VI2_AVX512VL
+ (match_operand:VI2_AVX512VL 1 "register_operand" "v")
+ (match_operand:VI2_AVX512VL 2 "nonimmediate_operand" "vm")))]
+  "TARGET_AVX512BW"
+  "vpv\t{%2, %1, %0|%0, 
%1, %2}"
+  [(set_attr "type" "sseishft")
+   (set_attr "prefix" "maybe_evex")
+   (set_attr "mode" "")])
+
 ;; For avx_vec_concat insn pattern
 (define_mode_attr concat_tg_mode
   [(V32QI "t") (V16HI "t") (V8SI "t") (V4DI "t") (V8SF "t") (V4DF "t")

RE: [PATCH, Fortran] PR61234: -Wuse-no-only

[VandeVondele Joost]

> OK with the documentation change and with the re-named option. Please
> also update the name in the code.

changes made and committed as r214311

[PATCH C/C++] Make use of CPP() for Wdate-time and other flags

[Manuel López-Ibáñez]

Using Common for Wdate-time when it is defined in c.opt does not
really make sense and breaks CPP(). I also took the opportunity to
move a duplicated testcase to c-c++-common.
(svn diff does not show the move).

Bootstrapped and regression tested on x86_64-linux-gnu.

OK?

gcc/c-family/ChangeLog:

2014-08-22  Manuel López-Ibáñez  

* c.opt (Wcomment): Use CPP, Var and LangEnabledBy.
(Wmultichar): Likewise.
(Wdate-time): Use C-family languages instead of Common. Use CPP
and Var.
* c-opts.c (c_common_handle_option): Do not handle the above
options here.
(sanitize_cpp_opts): Likewise.

gcc/testsuite/ChangeLog:

2014-08-22  Manuel López-Ibáñez  

* g++.dg/warn/wdate-time.C: Remove.
* gcc.dg/wdate-time.c: Move from here...
* c-c++-common/wdate-time.c: ... to here.
Index: gcc/c-family/c.opt
===
--- gcc/c-family/c.opt  (revision 214220)
+++ gcc/c-family/c.opt  (working copy)
@@ -326,11 +326,11 @@ Warn about subscripts whose type is \"ch
 Wclobbered
 C ObjC C++ ObjC++ Var(warn_clobbered) Warning EnabledBy(Wextra)
 Warn about variables that might be changed by \"longjmp\" or \"vfork\"
 
 Wcomment
-C ObjC C++ ObjC++ Warning
+C ObjC C++ ObjC++ CPP(warn_comments) Var(cpp_warn_comment) Warning 
LangEnabledBy(C ObjC C++ ObjC++,Wall)
 Warn about possibly nested block comments, and C++ comments spanning more than 
one physical line
 
 Wcomments
 C ObjC C++ ObjC++ Warning Alias(Wcomment)
 Synonym for -Wcomment
@@ -596,11 +596,11 @@ Warn about global functions without prot
 
 Wmudflap
 C ObjC C++ ObjC++ Ignore Warn(switch %qs is no longer supported)
 
 Wmultichar
-C ObjC C++ ObjC++ Warning
+C ObjC C++ ObjC++ CPP(warn_multichar) Var(cpp_warn_multichar) Warning
 Warn about use of multi-character character constants
 
 Wnarrowing
 C ObjC C++ ObjC++ Warning Var(warn_narrowing) Init(-1) LangEnabledBy(C++ 
ObjC++,Wall)
 Warn about narrowing conversions within { } that are ill-formed in C++11
@@ -700,11 +700,11 @@ Warn when a pointer is cast to an intege
 Wpragmas
 C ObjC C++ ObjC++ Var(warn_pragmas) Init(1) Warning
 Warn about misuses of pragmas
 
 Wdate-time
-Common Var(cpp_warn_date_time) Warning
+C ObjC C++ ObjC++ CPP(warn_date_time) Var(cpp_warn_date_time) Warning
 Warn about __TIME__, __DATE__ and __TIMESTAMP__ usage
 
 Wproperty-assign-default
 ObjC ObjC++ Var(warn_property_assign_default) Init(1) Warning
 Warn if a property for an Objective-C object has no assign semantics specified
Index: gcc/c-family/c-opts.c
===
--- gcc/c-family/c-opts.c   (revision 214220)
+++ gcc/c-family/c-opts.c   (working copy)
@@ -366,22 +366,17 @@ c_common_handle_option (size_t scode, co
 
 case OPT_Wall:
   /* ??? Don't add new options here. Use LangEnabledBy in c.opt.  */
 
   cpp_opts->warn_trigraphs = value;
-  cpp_opts->warn_comments = value;
   cpp_opts->warn_num_sign_change = value;
   break;
 
 case OPT_Wbuiltin_macro_redefined:
   cpp_opts->warn_builtin_macro_redefined = value;
   break;
 
-case OPT_Wcomment:
-  cpp_opts->warn_comments = value;
-  break;
-
 case OPT_Wc___compat:
   cpp_opts->warn_cxx_operator_names = value;
   break;
 
 case OPT_Wdeprecated:
@@ -405,16 +400,12 @@ c_common_handle_option (size_t scode, co
   break;
 
 case OPT_Wmissing_include_dirs:
   cpp_opts->warn_missing_include_dirs = value;
   break;
-
-case OPT_Wmultichar:
-  cpp_opts->warn_multichar = value;
-  break;
-
 case OPT_Wnormalized_:
+  /* FIXME: Move all this to c.opt.  */
   if (kind == DK_ERROR)
{
  gcc_assert (!arg);
  inform (input_location, "-Werror=normalized=: set -Wnormalized=nfc");
  cpp_opts->warn_normalize = normalized_C;
@@ -1294,11 +1285,10 @@ sanitize_cpp_opts (void)
   else if (cpp_opts->deps.missing_files)
 error ("-MG may only be used with -M or -MM");
 
   cpp_opts->unsigned_char = !flag_signed_char;
   cpp_opts->stdc_0_in_system_headers = STDC_0_IN_SYSTEM_HEADERS;
-  cpp_opts->warn_date_time = cpp_warn_date_time;
   cpp_opts->cpp_warn_c90_c99_compat = warn_c90_c99_compat;
 
   /* Wlong-long is disabled by default. It is enabled by:
   [-Wpedantic | -Wtraditional] -std=[gnu|c]++98 ; or
   [-Wpedantic | -Wtraditional] -std=non-c99 ; or
Index: gcc/testsuite/gcc.dg/wdate-time.c
===
--- gcc/testsuite/gcc.dg/wdate-time.c   (revision 214220)
+++ gcc/testsuite/gcc.dg/wdate-time.c   (working copy)
@@ -1,6 +0,0 @@
-/* { dg-do compile } */
-/* { dg-options "-Wdate-time" } */
-
-const char time[] = __TIME__;  /* { dg-warning "might prevent reproducible 
builds" }  */
-const char date[] = __DATE__;  /* { dg-warning "might prevent reproducible 
builds" }  */
-const char timestamp[] = __TIMESTAMP__;  /* { dg-warning "might prevent 
reproducible builds" }  */
Index: gcc/

[PATCH][ARM/AArch64] Add scheduling info for ARMv8-A FPU new instructions in Cortex-A53

[Kyrill Tkachov]

Hi all,

The Cortex-A53 scheduler description is missing rules for insn types used by instructions 
such as vrint*, vmaxnm, vminnm causing them to be assigned to the "nothing" 
unit.

This patch causes such instructions to be treated the same way as other simple 
FPU instructions.

Bootstrapped and tested on aarch64-linux and tested on arm-none-eabi as well.

Ok for trunk?

Thanks,
Kyrill

2014-08-22  Kyrylo Tkachov  

* config/arm/cortex-a53.md (cortex_a53_fpalu): Add f_rints, f_rintd,
f_minmaxs, f_minmaxd types.
commit 8f38a58ebb76ae8d63659d488b57a2e0bc9bbdcc
Author: Kyrylo Tkachov 
Date:   Thu Jun 19 13:37:38 2014 +0100

[ARM/AArch64] Schedule ARMv8-A FPU insns on Cortex-A53

diff --git a/gcc/config/arm/cortex-a53.md b/gcc/config/arm/cortex-a53.md
index e342cb2..72262d7 100644
--- a/gcc/config/arm/cortex-a53.md
+++ b/gcc/config/arm/cortex-a53.md
@@ -216,7 +216,8 @@
   (and (eq_attr "tune" "cortexa53")
(eq_attr "type" "ffariths, fadds, ffarithd, faddd, fmov, fmuls,\
 f_cvt,f_cvtf2i,f_cvti2f,\
-			fcmps, fcmpd, fcsel"))
+fcmps, fcmpd, fcsel, f_rints, f_rintd, f_minmaxs,\
+f_minmaxd"))
   "cortex_a53_slot0+cortex_a53_fpadd_pipe")
 
 (define_insn_reservation "cortex_a53_fconst" 2

[PATCH] Fix environment variables restoring in GCC testsuite.

[Maxim Ostapenko]

Hi,

When testing, I've noticed, that Asan-bootstrapped GCC should be 
executed with ASAN_OPTIONS=detect_leaks=0 because of memory leaks in 
GCC, reported by Leak Sanitizer.


When I ran Asan test on Asan-bootstrapped GCC, some of them fail with 
memory leaks into GCC, even if Lsan is disabled. This caused by slightly 
wrong logic in saving/restoring env variables functionality in 
gcc-dg.exp (some tests override ASAN_OPTIONS and this env variable isn't 
restored correcty).


This tiny patch seems to fix the issue.

Tested on x86_64-pc-linux-gnu.

Ok to commit?

-Maxim
gcc/testsuite/ChangeLog:

2014-08-22  Max Ostapenko  

	* lib/gcc-dg.exp: Change pattern.

diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index 3390caa..d438c05 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -295,8 +295,8 @@ proc set-target-env-var { } {
 foreach env_var $set_target_env_var {
 	set var [lindex $env_var 0]
 	set value [lindex $env_var 1]
-	if [info exists env($var)] {
-	lappend saved_target_env_var [list $var 1 $env($var)]
+	if [info exists ::env($var)] {
+	lappend saved_target_env_var [list $var 1 $::env($var)]
 	} else {
 	lappend saved_target_env_var [list $var 0]
 	}

Re: __intN patch 3/5: main __int128 -> __intN conversion.

[Joseph S. Myers]

On Fri, 22 Aug 2014, DJ Delorie wrote:

> > Maybe you need to refactor __glibcxx_digits so there is a version taking 
> > the bitsize as an argument rather than using sizeof(T) * __CHAR_BIT__, but 
> > that should be the only change needed to handle such types with the 
> > existing macros.  The bitsize macros should be the only ones needing 
> > predefining to pass information to libstdc++.
> 
> Like this?

Yes (well, the libstdc++ changes will need to go to the libstdc++ mailing 
list for review there, but this is the sort of thing I'd expect to keep 
the way libstdc++ defines these limits as consistent as possible between 
different types).

-- 
Joseph S. Myers
jos...@codesourcery.com

[PATCH, i386] PR61360: Do not update "enabled" attribute during lra and reload passes

[Gopalasubramanian, Ganesh]

This patch fixes PR 61360.

The attribute "enabled" should actually be used enable/disable alternative 
based on sub-targets.
In this pattern, it gets used across passes too. 
However, modifying this attribute in LRA pass is not something it is meant for.
This patch allows enabling/disabling the attribute when optimizing for size, 
but not during lra pass or reload pass.

Bootstrap passes.
OK for upstream?

Regards
Ganesh

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 6d91da0..3775f6e 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,4 +1,10 @@
-2014-08-22  David Malcolm  
+2014-08-22 Ganesh Gopalasubramanian  
+
+   PR 61360
+   * config/i386/i386.md (*float2_sse):
+   Do not modify "enabled" attribute during LRA pass.
+
+014-08-22  David Malcolm  

* cprop.c (struct occr): Strengthen field "insn" from rtx to
rtx_insn *.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 8e74eab..de2ecf0 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -4795,10 +4795,10 @@
   /* ??? For sched1 we need constrain_operands to be able to
  select an alternative.  Leave this enabled before RA.  */
   (symbol_ref "TARGET_INTER_UNIT_CONVERSIONS
-   || optimize_function_for_size_p (cfun)
-   || !(reload_completed
-|| reload_in_progress
-|| lra_in_progress)")
+   || (optimize_function_for_size_p (cfun)
+   && !(reload_completed
+|| reload_in_progress
+|| lra_in_progress))")
]
(symbol_ref "true")))
])

[PATCH i386 AVX512] [22/n] Extend unaligned loads & stores.

[Kirill Yukhin]

Hello,
This patch extends unaligned loads and stores patterns.

I've refactored original patch (stored on SVN's branch)
toward reducing complexity of conditions in
   define_insn "_storedqu_mask"

It seems like such a trick won't work for:
   _loaddqu
Problem is V[32|16]QI modes, which enabled for SSE/AVX
w/o masking and for AVX-512BW & AVX-512VL when masking is
on.

Of course, I can split the define_insn & define_expand
into 3 patterns w/ mode iterators of:
  1. V16QI, V32QI - baseline is SSE2, masks enabled for AVX-512BW&VL
  2. V64QI, V8HI, V16HI, V32HI - baseline is AVX-512BW, masks enabled
 for AVX-512VL
  3. V8DI, V4DI, V2DI, V16SI, V8SI, V4SI - baseline is AVX-512F, masks
 enabled for AVX-512VL.

But such approach will lead to 6 patterns instead of 2 (with non-trivial
asm emit). I have doubts if it is useful...


Current patch passess bootstrap and shows now regiressions under
simulator.

What do you think?

gcc/
* config/i386/sse.md
(define_mode_iterator VI48_AVX512VL): New.
(define_mode_iterator VI_UNALIGNED_LOADSTORE): Add V64QI, V32HI, V16HI,
V8HI, V4SI, V4DI, V2DI modes.
(define_expand "_loaddqu"): Update
condition.
(define_insn "*_loaddqu"): Update
condition, handle new modes.
(define_insn "_storedqu"): Handle new modes.
(define_insn "avx512f_storedqu_mask"): Delete.
(define_insn "_storedqu_mask" with
VI48_AVX512VL): New.
(define_insn "_storedqu_mask" with
VI12_AVX512VL): Ditto.

--
Thanks, K


diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index cd0c08e..51cfada 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -235,6 +235,10 @@
 (define_mode_iterator VF_512
   [V16SF V8DF])
 
+(define_mode_iterator VI48_AVX512VL
+  [V16SI (V8SI  "TARGET_AVX512VL") (V4SI  "TARGET_AVX512VL")
+   V8DI  (V4DI  "TARGET_AVX512VL") (V2DI  "TARGET_AVX512VL")])
+
 (define_mode_iterator VF2_AVX512VL
   [V8DF (V4DF "TARGET_AVX512VL") (V2DF "TARGET_AVX512VL")])
 
@@ -260,8 +264,12 @@
   [(V32QI "TARGET_AVX") V16QI])
 
 (define_mode_iterator VI_UNALIGNED_LOADSTORE
-  [(V32QI "TARGET_AVX") V16QI
-   (V16SI "TARGET_AVX512F") (V8DI "TARGET_AVX512F")])
+  [(V64QI "TARGET_AVX512BW") (V32QI "TARGET_AVX") V16QI
+   (V32HI "TARGET_AVX512BW")
+   (V16HI "TARGET_AVX512BW && TARGET_AVX512VL")
+   (V8HI "TARGET_AVX512BW && TARGET_AVX512VL")
+   (V16SI "TARGET_AVX512F") (V8SI "TARGET_AVX512VL") (V4SI "TARGET_AVX512VL")
+   (V8DI "TARGET_AVX512F") (V4DI "TARGET_AVX512VL") (V2DI "TARGET_AVX512VL")])
 
 ;; All DImode vector integer modes
 (define_mode_iterator VI8
@@ -1172,7 +1180,10 @@
(unspec:VI_UNALIGNED_LOADSTORE
  [(match_operand:VI_UNALIGNED_LOADSTORE 1 "nonimmediate_operand")]
  UNSPEC_LOADU))]
-  "TARGET_SSE2 && "
+  "TARGET_SSE2 
+   && (!
+   || (TARGET_AVX512BW && TARGET_AVX512VL)
+   || (mode != V32QImode && (mode != V16QImode)))"
 {
   /* For AVX, normal *mov_internal pattern will handle unaligned loads
  just fine if misaligned_operand is true, and without the UNSPEC it can
@@ -1197,20 +1208,27 @@
(unspec:VI_UNALIGNED_LOADSTORE
  [(match_operand:VI_UNALIGNED_LOADSTORE 1 "nonimmediate_operand" "vm")]
  UNSPEC_LOADU))]
-  "TARGET_SSE2 && "
+  "TARGET_SSE2
+   && (!
+   || (TARGET_AVX512BW && TARGET_AVX512VL)
+   || (mode != V32QImode && (mode != V16QImode)))"
 {
   switch (get_attr_mode (insn))
 {
+case MODE_V16SF:
 case MODE_V8SF:
 case MODE_V4SF:
   return "%vmovups\t{%1, %0|%0, %1}";
-case MODE_XI:
-  if (mode == V8DImode)
-   return "vmovdqu64\t{%1, %0|%0, %1}";
-  else
-   return "vmovdqu32\t{%1, %0|%0, %1}";
 default:
-  return "%vmovdqu\t{%1, %0|%0, %1}";
+  switch (mode)
+  {
+  case V32QImode:
+  case V16QImode:
+   if (!(TARGET_AVX512VL && TARGET_AVX512BW))
+ return "%vmovdqu\t{%1, %0|%0, %1}";
+  default:
+   return "vmovdqu\t{%1, 
%0|%0, %1}";
+  }
 }
 }
   [(set_attr "type" "ssemov")
@@ -1246,13 +1264,16 @@
 case MODE_V8SF:
 case MODE_V4SF:
   return "%vmovups\t{%1, %0|%0, %1}";
-case MODE_XI:
-  if (mode == V8DImode)
-   return "vmovdqu64\t{%1, %0|%0, %1}";
-  else
-   return "vmovdqu32\t{%1, %0|%0, %1}";
 default:
-  return "%vmovdqu\t{%1, %0|%0, %1}";
+  switch (mode)
+  {
+  case V32QImode:
+  case V16QImode:
+   if (!(TARGET_AVX512VL && TARGET_AVX512BW))
+ return "%vmovdqu\t{%1, %0|%0, %1}";
+  default:
+ return "vmovdqu\t{%1, %0|%0, %1}";
+  }
 }
 }
   [(set_attr "type" "ssemov")
@@ -1276,21 +1297,32 @@
  ]
  (const_string "")))])
 
-(define_insn "avx512f_storedqu_mask"
-  [(set (match_operand:VI48_512 0 "memory_operand" "=m")
-   (vec_merge:VI48_512
- (unspec:VI48_512
-   [(match_operand:VI48_512 1 "register_operand" "v")]
+(define_insn "_storedqu_mask"
+  [(set (match_

Re: werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable))

[Jan-Benedict Glaw]

On Sat, 2014-07-26 13:31:42 -0400, Hans-Peter Nilsson  wrote:
> On Fri, 25 Jul 2014, Hans-Peter Nilsson wrote:
> > Anyway, on to the point of this message: by the quoted list it
> > seems you have a local host called pluto using 4.9.1 as the host
> > gcc for some build; does config-list.mk work for that?
> 
> Never mind, I found a 4.9.1 installation on gcc110 and the
> answer seems to be "yes", but still investigating; I disabled
> Ada.  It might be useful to run a modified config-list.mk using
> that version.
> 
> BTW, I found the answer to be "no" for 4.8.1 as per gcc111 due
> to a common warning on a concat call.

As written elsewhere: I think I correctly reworked the config-list.mk
building backend last night. It's running on gcc76 already (will put
it on gcc20 as soon as I'm convinced it *really* works) and then we'll
get the cross-compiler built with a GCC of the very same SCM revision.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
 Signature of:If it doesn't work, force it.
 the second  :   If it breaks, it needed replacing anyway.


signature.asc
Description: Digital signature

Re: [Patch, AArch64] Restructure arm_neon.h vector types' implementation.

[Tejas Belagod]

On 28/06/14 11:25, Marc Glisse wrote:

On Mon, 23 Jun 2014, Tejas Belagod wrote:


Here is a patch that restructures neon builtins to use vector types based on
standard base types. We previously defined arm_neon.h's neon vector
types(int8x8_t) using gcc's front-end vector extensions. We now move away
from that and use types built internally(e.g. __Int8x8_t). These internal
types names are defined by the AAPCS64 and we build arm_neon.h's public
vector types over these internal types. e.g.

  typedef __Int8x8_t int8x8_t;

as opposed to

  typedef __builtin_aarch64_simd_qi int8x8_t
__attribute__ ((__vector_size__ (8)));

Impact on mangling:

This patch does away with these builtin scalar types that the vector types
were based on. These were previously used to look up mangling names. We now
use the internal vector type names(e.g. __Int8x8_t) to lookup mangling for
the arm_neon.h-exported vector types. There are a few internal scalar
types(__builtin_aarch64_simd_oi etc.) that is needed to efficiently implement
some NEON Intrinsics. These will be declared in the back-end and registered
in the front-end and aarch64-specific builtin types, but are not
user-visible. These, along with a few scalar __builtin types that aren't
user-visible will have implementation-defined mangling. Because we don't have
strong-typing across all builtins yet, we still have to maintain the old
builtin scalar types - they will be removed once we move over to a
strongly-typed builtin system implemented by the qualifier infrastructure.

Marc Glisse's patch in this thread exposed this issue
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00618.html. I've tested my
patch with the change that his patch introduced, and it seems to work fine -
specifically these two lines:

+  for (tree t = registered_builtin_types; t; t = TREE_CHAIN (t))
+emit_support_tinfo_1 (TREE_VALUE (t));


If you still have that build somewhere, could you try:
nm -C libsupc++.a | grep typeinfo
and check how much your builtins appear there? With my patch you may have
half-floats in addition to what you get without the patch (I think that's
a good thing), but I hope not too much more...

Thanks for working on this,



Marc,

Revisiting this old thread - sorry for the delay in getting back.

When I do this, I see no aarch64 builtin types listed with my patch and 
the above two lines from your patch. Is this expected?


Thanks,
Tejas.

Re: [Patch, AArch64] Restructure arm_neon.h vector types' implementation.

[Tejas Belagod]

On 27/06/14 17:01, Yufeng Zhang wrote:

On 27 June 2014 16:32, Tejas Belagod  wrote:


2014-06-23  Tejas Belagod  

diff --git a/gcc/config/aarch64/aarch64-simd-builtin-types.def
b/gcc/config/aarch64/aarch64-simd-builtin-types.def
new file mode 100644
index 000..aa6a84e
--- /dev/null
+++ b/gcc/config/aarch64/aarch64-simd-builtin-types.def
@@ -0,0 +1,50 @@
+/* Builtin AdvSIMD types.
+   Copyright (C) 2014 Free Software Foundation, Inc.
+   Contributed by ARM Ltd.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   GCC is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */
+
+  ENTRY (Int8x8_t, V8QI, none, 10)
+  ENTRY (Int8x16_t, V16QI, none, 11)
+  ENTRY (Int16x4_t, V4HI, none, 11)
+  ENTRY (Int16x8_t, V8HI, none, 11)
+  ENTRY (Int32x2_t, V2SI, none, 11)
+  ENTRY (Int32x4_t, V4SI, none, 11)
+  ENTRY (Int64x1_t, DI, none, 11)
+  ENTRY (Int64x2_t, V2DI, none, 11)
+  ENTRY (Uint8x8_t, V8QI, unsigned, 11)
+  ENTRY (Uint8x16_t, V16QI, unsigned, 12)
+  ENTRY (Uint16x4_t, V4HI, unsigned, 12)
+  ENTRY (Uint16x8_t, V8HI, unsigned, 12)
+  ENTRY (Uint32x2_t, V2SI, unsigned, 12)
+  ENTRY (Uint32x4_t, V4SI, unsigned, 12)
+  ENTRY (Uint64x1_t, DI, unsigned, 12)
+  ENTRY (Uint64x2_t, V2DI, unsigned, 12)
+  ENTRY (Poly8_t, QI, poly, 9)
+  ENTRY (Poly16_t, HI, poly, 10)
+  ENTRY (Poly64_t, DI, poly, 10)
+  ENTRY (Poly128_t, TI, poly, 11)
+  ENTRY (Poly8x8_t, V8QI, poly, 11)
+  ENTRY (Poly8x16_t, V16QI, poly, 12)
+  ENTRY (Poly16x4_t, V4HI, poly, 12)
+  ENTRY (Poly16x8_t, V8HI, poly, 12)
+  ENTRY (Poly64x1_t, DI, poly, 12)
+  ENTRY (Poly64x2_t, V2DI, poly, 12)
+  ENTRY (Float32x2_t, V2SF, none, 13)
+  ENTRY (Float32x4_t, V4SF, none, 13)
+  ENTRY (Float64x1_t, DF, none, 13)


Will this revert Alan Lawrance's commit in 211892, which defines
Float64x1_t to have V1DF mode?



I've rebased over Alan's changes and am currently testing a renewed 
patch. Will post once testing is happy.


Thanks,
Tejas.

Re: [Patch, AArch64] Restructure arm_neon.h vector types' implementation.

[Tejas Belagod]

On 04/07/14 15:27, James Greenhalgh wrote:

On Fri, Jun 27, 2014 at 04:32:19PM +0100, Tejas Belagod wrote:

+/* Internal scalar builtin types.  These types are used to support
+   neon intrinsic builtins.  They are _not_ user-visible types.  Therefore
+   the mangling for these types are implementation defined.  */
+const char *aarch64_scalar_builtin_types[] = {
+  "__builtin_aarch64_simd_qi",
+  "__builtin_aarch64_simd_hi",
+  "__builtin_aarch64_simd_si",
+  "__builtin_aarch64_simd_sf",
+  "__builtin_aarch64_simd_di",
+  "__builtin_aarch64_simd_df",
+  "__builtin_aarch64_simd_poly8",
+  "__builtin_aarch64_simd_poly16",
+  "__builtin_aarch64_simd_poly64",
+  "__builtin_aarch64_simd_poly128",
+  "__builtin_aarch64_simd_ti",
+  "__builtin_aarch64_simd_uqi",
+  "__builtin_aarch64_simd_uhi",
+  "__builtin_aarch64_simd_usi",
+  "__builtin_aarch64_simd_udi",
+  "__builtin_aarch64_simd_ei",
+  "__builtin_aarch64_simd_oi",
+  "__builtin_aarch64_simd_ci",
+  "__builtin_aarch64_simd_xi",
+  NULL
+};



+static const char *
+aarch64_mangle_builtin_scalar_type (const_tree type)
+{
+  int i = 0;
+
+  while (aarch64_scalar_builtin_types[i] != NULL)
  {
-  default:
-   eltype = aarch64_build_scalar_type (GET_MODE_INNER (mode),
-   unsigned_p, poly_p);
-   return build_vector_type_for_mode (eltype, mode);
-   break;
-  VECTOR_TYPES
-   }
+  const char *name = aarch64_scalar_builtin_types[i];
+
+  if (TREE_CODE (TYPE_NAME (type)) == TYPE_DECL
+ && DECL_NAME (TYPE_NAME (type))
+ && !strcmp (IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (type))), name))
+   return aarch64_scalar_builtin_types[i];
+  i++;
+}
+  return NULL;
  }



diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
index 3ed8a98..50d294e 100644
--- a/gcc/config/aarch64/arm_neon.h
+++ b/gcc/config/aarch64/arm_neon.h
@@ -32,66 +32,45 @@
+typedef __Poly8_t poly8_t;
+typedef __Poly16_t poly16_t;
+typedef __Poly64_t poly64_t;
+typedef __Poly128_t poly128_t;


This looks wrong to me. The type which eventually becomes poly8_t in
arm_neon.h has "__Poly8_t" as its internal type name.

When you go through the loop in aarch64_mangle_builtin_scalar_type you'll
be checking in aarch64_scalar_builtin_types for a string matching
"__Poly8_t" and won't find it, so we'll end up with default mangling for this
type.



Sorry for the delay in getting back.

You're right. Testing a fixed patch.


One question I have is, if for all the backend types we define we want the
mangled name to be:

   

then why do we not just return that and save the string comparisons?

I can see some argument for future flexibility, but in that case we will need
to rewrite this code anyway. Is there some other hole in my reasoning?



There seems to be no robust TYPE_NAME check only to filter out backend 
builtin types into the backend hook function. A non-NULL_TREE TYPE_NAME 
is used to represent something more than just backend builtin types, I 
believe. Therefore there is a risk of letting in more types which we 
will need to filter out anyway, hence the static table of type names. If 
we have to use the table, we might as well have the strlen prepended to 
the mangled names anyway. Hope this reasoning holds water.


Thanks,
Tejas.

Re: Migrating gcc.c-torture

[Bernd Schmidt]

On 07/29/2014 12:36 AM, Joseph S. Myers wrote:

On Thu, 24 Jul 2014, Jakub Jelinek wrote:

Yeah.  I believe gcc.c-torture/compile/ has been converted already,
so it is just about gcc.c-torture/execute/.  Each of these tests has
it's own default idioms, e.g. -w in by default in gcc.c-torture/.


Using -w does not strike me as a feature - ideally we'd like to know if 
we produce new warnings. Almost all of the existing warnings could be 
shut up by adding declarations of abort and exit.



So, please just tweak execute.exp, so that it does what it did until now
(perhaps with the exception of *.x files support) in dg framework, and
convert *.exp files into dg-* directives in the testcases.


And note that this is bug 20567.  Existing dg-* directive uses in
gcc.c-torture/execute/ (which are currently ignored) may or may not be
correct, so they should be reviewed as part of such a migration to decide
whether they should stay or be removed.  (There aren't that many of them
to review.)


Here's another attempt. I've used a global default of "-w" as in 
c-torture/compile; in testcases that use dg-options (overriding this 
default) I've usually added in declarations of abort and exit to shut up 
the warnings.


Some notes about testcases where the conversion wasn't straightforward:

931004-12.c:
# xfail this on powerpc-*-darwin, see PR 15923
In the PR, we first see a note that the test has been xfailed, then 
later we see a "Fixed". I've decided not to keep the xfail.


cvt-1.c:
Has a dubious comment about the test failing on d10v without 32 bit 
ints. Since that would indicate a bug in the target, and the target was 
removed anyway (or never added - can't find any other mention of it), 
decided not to keep the xfail.


20030125-1.x:
Uses a test for *linux*, *gnu* or uclibc to identify whether the target 
supports C99 library functions. Replaced with require-effective-target 
c99_runtime.


990413-2.c:
Says the test is x86 specific. Not moved to gcc.target however, in order 
to keep it running with all torture options.


20111227-[23].c:
Wants to examing optimizer log files (which presumably doesn't do 
anything when run in current c-torture), and wants to run at only one 
optimization level. Moved to gcc.dg and added -free since it is not 
enabled at -O.


20010129-1.c:
Has some tcl code that modifies options on i686 based on whether -m64 is 
specified. As a translation I've used

/* { dg-options "-mtune-i686" { target { { i?86*-*-* } && ilp32 } } } */
which I think should do the same thing.

920710-1.x:
Claims h8300 does not have long long. The .x file predates a checkin 
that makes LONG_LONG_TYPE_SIZE 64 on h8300. Decided not to keep this.


pr53366-1.x:
No corresponding test exists (there are tests with that name in 
dg/torture and target/i386).


These are the changes on x86_64-linux:

=== gcc Summary ===

-# of expected passes   199892
+# of expected passes   199844
 # of unexpected failures   247
 # of unexpected successes  54
 # of expected failures 526
-# of unsupported tests 3487
+# of unsupported tests 3495

Ok?


Bernd
diff --git a/gcc/testsuite/gcc.c-torture/execute/20010122-1.c b/gcc/testsuite/gcc.c-torture/execute/20010122-1.c
index 280e3d4..14269fa 100644
--- a/gcc/testsuite/gcc.c-torture/execute/20010122-1.c
+++ b/gcc/testsuite/gcc.c-torture/execute/20010122-1.c
@@ -1,3 +1,4 @@
+/* { dg-skip-if "requires frame pointers" { *-*-* } "-fomit-frame-pointer" "" } */
 
 extern void exit (int);
 extern void abort (void);
diff --git a/gcc/testsuite/gcc.c-torture/execute/20010122-1.x b/gcc/testsuite/gcc.c-torture/execute/20010122-1.x
deleted file mode 100644
index 6558236..000
--- a/gcc/testsuite/gcc.c-torture/execute/20010122-1.x
+++ /dev/null
@@ -1,11 +0,0 @@
-# This test relies on __builtin_return_address(1) returning something
-# useful or NULL.  This is not guaranteed to be be so, especially when 
-# -fomit-frame-pointer is used.  So do not test with it.
-
-set torture_eval_before_compile {
-  if {[string match {*-fomit-frame-pointer*} "$option"]} {
-continue
-  }
-}
-
-return 0
diff --git a/gcc/testsuite/gcc.c-torture/execute/20010129-1.c b/gcc/testsuite/gcc.c-torture/execute/20010129-1.c
index a4ea5e4..0586577 100644
--- a/gcc/testsuite/gcc.c-torture/execute/20010129-1.c
+++ b/gcc/testsuite/gcc.c-torture/execute/20010129-1.c
@@ -1,3 +1,5 @@
+/* { dg-options "-mtune-i686" { target { { i?86*-*-* } && ilp32 } } } */
+
 long baz1 (void *a)
 {
   static long l;
diff --git a/gcc/testsuite/gcc.c-torture/execute/20010129-1.x b/gcc/testsuite/gcc.c-torture/execute/20010129-1.x
deleted file mode 100644
index 7e474c4..000
--- a/gcc/testsuite/gcc.c-torture/execute/20010129-1.x
+++ /dev/null
@@ -1,13 +0,0 @@
-# Use "-mtune=i686" on i?86-*-* unless "-m64" is specified.
-if { [istarget "i?86-*-*"] } {
-  set target_name [target_info name]
-  if {[board_info $target_name exists multilib_flags]} {
-set multilib_flags [board_info $targe

Re: Enable EBX for x86 in 32bits PIC code

[Ilya Enkovich]

Hi,

On Cauldron 2014 we had a couple of talks about relaxation of ebx usage in 
32bit PIC mode.  It was decided that the best approach would be to not fix ebx 
register, use speudo register for GOT base address and let allocator do the 
rest.  This should be similar to how clang and icc work with GOT base address.  
I've been working for some time on such patch and now want to share my results.

The idea of the patch was very simple and included few things;
 1.  Set PIC_OFFSET_TABLE_REGNUM to INVALID_REGNUM to specify that we do not 
have any hard reg fixed for PIC.
 2.  Initialize pic_offset_table_rtx with a new pseudo register in the begining 
of a function expand.
 3.  Change ABI so that there is a possible implicit PIC argument for calls; 
pic_offset_table_rtx is used as an arg value if such implicit arg exist.

Such approach worked well on small tests but trying to run some benchmarks we 
faced a problem with reload of address constants.  The problem is that when we 
try to rematerialize address constant or some constant memory reference, we 
have to use pic_offset_table_rtx.  It means we insert new usages of a speudo 
register and alocator cannot handle it correctly.  Same problem also applies 
for float and vector constants.

Rematerialization is not the only case causing new pic_offset_table_rtx usage.  
Another case is a split of some instructions using constant but not having 
proper constraints.  E.g. pushtf pattern allows push of constant but it has to 
be replaced with push of memory in reload pass causing additional usage of 
pic_offset_table_rtx.

There are two ways to fix it.  The first one is to support modifications of 
pseudo register live range during reload and correctly allocate hard regs for 
its new usages (currently we have some hard reg allocated for new usage of 
pseudo reg but it may contain value of some other pseudo reg; thus we reveal 
the problem at runtime only).

The second way is to avoid all cases when new usages of pic_offset_table_rtx 
appear in reload.  That is a way I chose because it appeared simplier to me and 
would allow me to get some performance data faster.  Also having 
rematerialization of address anf float constants in PIC mode would mean we have 
higher register pressure, thus having them on stack should be even more 
efficient.  To achieve it I had to cut off reg equivs to all exprs using symbol 
references and all constants living in the memory.  I also had to avoid 
instructions requiring split in reload causing load of constant from memory 
(*push[txd]f).

Resulting compiler successfully passes make check, compiles EEMBC and SPEC2000 
benchmarks.  There is no confidence I covered all cases and there still may be 
some templates causing split in reload with new pic_offset_table_rtx usages.  I 
think support of reload with pseudo PIC would be better and more general 
solution.  But I don't know how difficult is to implement it though.  Any ideas 
on resolving this reload issue?

I collected some performance numbers for EEMBC and SPEC2000 benchmarks.  Here 
are patch results for -Ofast optlevel with LTO collectd on Avoton server:
AUTOmark +1,9%
TELECOMmark +4,0%
DENmark +10,0%
SPEC2000 -0,5%

There are few degradations on EEMBC benchmarks but on SPEC2000 situation is 
different and we see more performance losses.  Some of them are caused by 
disabled rematerialization of address constants.  In some cases relaxed ebx 
causes more spills/fills in plaecs where GOT is frequently used.  There are 
also some minor fixes required in the patch to allow more efficient function 
prolog (avoid unnecessary GOT register initialization and allow its 
initialization without ebx usage).  Suppose some performance problems may be 
resolved but a good fix for reload should go first.

Thanks,
Ilya
--
diff --git a/gcc/calls.c b/gcc/calls.c
index 4285ec1..85dae6b 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -1122,6 +1122,14 @@ initialize_argument_information (int num_actuals 
ATTRIBUTE_UNUSED,
 call_expr_arg_iterator iter;
 tree arg;
 
+if (targetm.calls.implicit_pic_arg (fndecl ? fndecl : fntype))
+  {
+   gcc_assert (pic_offset_table_rtx);
+   args[j].tree_value = make_tree (ptr_type_node,
+   pic_offset_table_rtx);
+   j--;
+  }
+
 if (struct_value_addr_value)
   {
args[j].tree_value = struct_value_addr_value;
@@ -2520,6 +2528,10 @@ expand_call (tree exp, rtx target, int ignore)
 /* Treat all args as named.  */
 n_named_args = num_actuals;
 
+  /* Add implicit PIC arg.  */
+  if (targetm.calls.implicit_pic_arg (fndecl ? fndecl : fntype))
+num_actuals++;
+
   /* Make a vector to hold all the information about each arg.  */
   args = XALLOCAVEC (struct arg_data, num_actuals);
   memset (args, 0, num_actuals * sizeof (struct arg_data));
@@ -3133,6 +3145,8 @@ expand_call (tree exp, rtx target, int ignore)
{
  int arg_nr = return_flags & ERF_RETURN_ARG_MASK;

Re: [PATCH] Fix wrong refactoring in cgraph_node::function_symbol

[Martin Liška]

On 08/13/2014 02:25 PM, Ilya Enkovich wrote:
> Hi,
>
> This patch is to fix wrong refactoring for cgraph_node::function_symbol 
> introduced by this patch: 
> https://gcc.gnu.org/ml/gcc-cvs/2014-07/msg00805.html.  Here is how function 
> was refactored:
>
> -cgraph_function_node (struct cgraph_node *node, enum availability 
> *availability)
> +cgraph_node *
> +cgraph_node::function_symbol (enum availability *availability)
>  {
> +  cgraph_node *node = NULL;
> +
>do
>  {
> -  node = cgraph_function_or_thunk_node (node, availability);
> +  node = ultimate_alias_target (availability);
>if (node->thunk.thunk_p)
> {
>   node = node->callees->callee;
>   if (availability)
> {
>   enum availability a;
> - a = cgraph_function_body_availability (node);
> + a = node->get_availability ();
>   if (a < *availability)
> *availability = a;
> }
> - node = cgraph_function_or_thunk_node (node, availability);
> + node = node->ultimate_alias_target (availability);
> }
>  } while (node && node->thunk.thunk_p);
>return node;
>  }
>
> first ultimate_alias_target call always uses 'this' instead of 'node'.  This 
> causes infinite loop.
>
> Patch was bootstrapped and regtested on linux-x86_64.  OK for trunk?
Hello.
Thank you for the fix. Unfortunately, there's no test case that would show me 
the problem.

Martin
>
> Thanks,
> Ilya
> --
>
> 2014-08-13  Ilya Enkovich  
>
>   * cgraph.c (cgraph_node::function_symbol): Fix wrong
>   cgraph_function_node to cgraph_node::function_symbol
>   refactoring.
>
> diff --git a/gcc/cgraph.c b/gcc/cgraph.c
> index 5a0b903..370a96a 100644
> --- a/gcc/cgraph.c
> +++ b/gcc/cgraph.c
> @@ -3000,11 +3000,11 @@ cgraph_node::verify_cgraph_nodes (void)
>  cgraph_node *
>  cgraph_node::function_symbol (enum availability *availability)
>  {
> -  cgraph_node *node = NULL;
> +  cgraph_node *node = this;
>  
>do
>  {
> -  node = ultimate_alias_target (availability);
> +  node = node->ultimate_alias_target (availability);
>if (node->thunk.thunk_p)
>   {
> node = node->callees->callee;

Re: [PATCH, rs6000] PR 62195, Fix wi constraint

[David Edelsohn]

On Thu, Aug 21, 2014 at 3:30 PM, Michael Meissner
 wrote:
> (I'm not sure if an earlier patch got mailed out, I'm sorry if there are
> duplicate postings).
>
> I had a thinko in my patch on August 11th, in that I allowed the wi constraint
> to be FLOAT_REGS on a non-VSX system, but I had a pattern in movdi that
> generated a VSX instruction.  I have tightened wi, so that it applies only 
> when
> VSX is used.
>
> In addition, I had used wi for lfiwax/lfiwzx and in the case issued an ISA 
> 2.07
> (power8) instruction.  I have changed these cases to use the wj constraint
> (constraint for register class under ISA 2.07 for doing move direct of
> DImode).  I decided that it wasn't worth adding a new constraint for these
> cases, and if the user does -mcpu=power8 -mno-move-direct, it will still
> generate the lfiwax/lfiwzx instructions which target the traditional floating
> point registers.  I have done bootstraps with this compiler and it had no
> regressions.  Is the patch ok to check in?
>
> 2014-08-21  Michael Meissner  
>
> PR target/62195
> * doc/md.texi (Machine Constraints): Update PowerPC wi constraint
> documentation to state it is only for VSX operations.
>
> * config/rs6000/rs6000.c (rs6000_init_hard_regno_mode_ok): Make wi
> constraint only active if VSX.
>
> * config/rs6000/rs6000.md (lfiwax): Use wj constraint instead of
> wi cosntraint for ISA 2.07 lxsiwax/lxsiwzx instructions.
> (lfiwzx): Likewise.

Okay.

Thanks David

Re: [Patch, AArch64] Restructure arm_neon.h vector types' implementation.

[Marc Glisse]

On Fri, 22 Aug 2014, Tejas Belagod wrote:


On 28/06/14 11:25, Marc Glisse wrote:

On Mon, 23 Jun 2014, Tejas Belagod wrote:

Here is a patch that restructures neon builtins to use vector types based 
on

standard base types. We previously defined arm_neon.h's neon vector
types(int8x8_t) using gcc's front-end vector extensions. We now move away
from that and use types built internally(e.g. __Int8x8_t). These internal
types names are defined by the AAPCS64 and we build arm_neon.h's public
vector types over these internal types. e.g.

  typedef __Int8x8_t int8x8_t;

as opposed to

  typedef __builtin_aarch64_simd_qi int8x8_t
__attribute__ ((__vector_size__ (8)));

Impact on mangling:

This patch does away with these builtin scalar types that the vector types
were based on. These were previously used to look up mangling names. We 
now

use the internal vector type names(e.g. __Int8x8_t) to lookup mangling for
the arm_neon.h-exported vector types. There are a few internal scalar
types(__builtin_aarch64_simd_oi etc.) that is needed to efficiently 
implement
some NEON Intrinsics. These will be declared in the back-end and 
registered

in the front-end and aarch64-specific builtin types, but are not
user-visible. These, along with a few scalar __builtin types that aren't
user-visible will have implementation-defined mangling. Because we don't 
have

strong-typing across all builtins yet, we still have to maintain the old
builtin scalar types - they will be removed once we move over to a
strongly-typed builtin system implemented by the qualifier infrastructure.

Marc Glisse's patch in this thread exposed this issue
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00618.html. I've tested my
patch with the change that his patch introduced, and it seems to work fine 
-

specifically these two lines:

+  for (tree t = registered_builtin_types; t; t = TREE_CHAIN (t))
+emit_support_tinfo_1 (TREE_VALUE (t));


If you still have that build somewhere, could you try:
nm -C libsupc++.a | grep typeinfo
and check how much your builtins appear there? With my patch you may have
half-floats in addition to what you get without the patch (I think that's
a good thing), but I hope not too much more...

Thanks for working on this,



Marc,

Revisiting this old thread - sorry for the delay in getting back.

When I do this, I see no aarch64 builtin types listed with my patch and the 
above two lines from your patch. Is this expected?


I think it is good that they don't appear :-)

Thanks,

--
Marc Glisse

Re: [PATCH] Fix for PR/62089 (enable missing Asan checks)

[Yury Gribov]

On 08/19/2014 04:31 PM, Yury Gribov wrote:

On 08/19/2014 03:37 PM, Dominique Dhumieres wrote:

Makes sense, I've attached new patch (retested as usual).


Well, you probably did not test with -m32:


Right, I only did plain "make check" until now. Thanks for reporting,
I'll check this tomorrow.


Looks like the pattern in my test is too strict:
Asan will not always be able to detect that invalid memory access
is use-after-return (see implementation of __asan_poison_memory_region
for details). I'll cook a trivial patch to fix this next week.

-Y

Re: [PATCH AArch64 1/2] Add execution tests of vget_low and vget_high

[Richard Earnshaw]

On 12/08/14 10:55, Alan Lawrence wrote:
> Following patch replaces the current "temporary inline assembler" 
> implementation 
> of vget_high. So this patch adds a test first. We don't have any test 
> coverage 
> of vget_low, either, so add that too.
> 
> Passing on aarch64-none-elf and aarch64_be-none-elf.
> 
> 

You're missing ChangeLog entries for both this and its follow-on.

R.

> test_vget_high.patch
> 
> 
> diff --git a/gcc/testsuite/gcc.target/aarch64/vget_high_1.c 
> b/gcc/testsuite/gcc.target/aarch64/vget_high_1.c
> new file mode 100644
> index 
> ..4cb872da2cd269df5290a6af928ed958c4fecd09
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/vget_high_1.c
> @@ -0,0 +1,60 @@
> +/* { dg-do run } */
> +/* { dg-options "-O3 -std=c99" } */
> +
> +#include 
> +
> +extern void abort (void);
> +
> +#define VARIANTS(VARIANT)\
> +VARIANT (uint8_t, 8, uint8x8_t, uint8x16_t, u8)  \
> +VARIANT (uint16_t, 4, uint16x4_t, uint16x8_t, u16)   \
> +VARIANT (uint32_t, 2, uint32x2_t, uint32x4_t, u32)   \
> +VARIANT (uint64_t, 1, uint64x1_t, uint64x2_t, u64)   \
> +VARIANT (int8_t, 8, int8x8_t, int8x16_t, s8) \
> +VARIANT (int16_t, 4, int16x4_t, int16x8_t, s16)  \
> +VARIANT (int32_t, 2, int32x2_t, int32x4_t, s32)  \
> +VARIANT (int64_t, 1, int64x1_t, int64x2_t, s64)  \
> +VARIANT (float32_t, 2, float32x2_t, float32x4_t, f32)\
> +VARIANT (float64_t, 1, float64x1_t, float64x2_t, f64)
> +
> +
> +#define TESTMETH(BASETYPE, NUM64, TYPE64, TYPE128, SUFFIX)   \
> +int  \
> +test_vget_low_ ##SUFFIX (BASETYPE *data) \
> +{\
> +  BASETYPE temp [NUM64]; \
> +  TYPE128 vec = vld1q_##SUFFIX (data);   \
> +  TYPE64 high = vget_high_##SUFFIX (vec);\
> +  vst1_##SUFFIX (temp, high);\
> +  for (int i = 0; i < NUM64; i++)\
> +if (temp[i] != data[i + NUM64])  \
> +  return 1;  \
> +  return 0;  \
> +}
> +
> +VARIANTS (TESTMETH)
> +
> +#define CHECK(BASETYPE, NUM64, TYPE64, TYPE128, SUFFIX)  \
> +  if (test_vget_low_##SUFFIX (BASETYPE ## _ ## data) != 0)   \
> +abort ();
> +
> +int
> +main (int argc, char **argv)
> +{
> +  uint8_t uint8_t_data[16] =
> +  { 1, 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47 };
> +  uint16_t uint16_t_data[8] = { 1, 22, 333, , 5, , 777, 88 };
> +  uint32_t uint32_t_data[4] = { 65537, 11, 7, 23 };
> +  uint64_t uint64_t_data[2] = { 0xdeadbeefcafebabeULL, 0x0123456789abcdefULL 
> };
> +  int8_t int8_t_data[16] =
> +  { -1, -3, -5, -7, 9, -11, -13, 15, -17, -19, 21, -23, 25, 27, -29, -31 
> };
> +  int16_t int16_t_data[8] = { -17, 19, 3, -999, 44048, 505, , 1000};
> +  int32_t int32_t_data[4] = { 123456789, -987654321, -135792468, 975318642 };
> +  int64_t int64_t_data[2] = {0xfedcba9876543210LL, 0xdeadbabecafebeefLL };
> +  float32_t float32_t_data[4] = { 3.14159, 2.718, 1.414, 100.0 };
> +  float64_t float64_t_data[2] = { 1.0100100011, 12345.6789 };
> +
> +  VARIANTS (CHECK);
> +
> +  return 0;
> +}
> diff --git a/gcc/testsuite/gcc.target/aarch64/vget_low_1.c 
> b/gcc/testsuite/gcc.target/aarch64/vget_low_1.c
> new file mode 100644
> index 
> ..f8016ef73124981f7042957521f42754566e9518
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/vget_low_1.c
> @@ -0,0 +1,60 @@
> +/* { dg-do run } */
> +/* { dg-options "-O3 -std=c99" } */
> +
> +#include 
> +
> +extern void abort (void);
> +
> +#define VARIANTS(VARIANT)\
> +VARIANT (uint8_t, 8, uint8x8_t, uint8x16_t, u8)  \
> +VARIANT (uint16_t, 4, uint16x4_t, uint16x8_t, u16)   \
> +VARIANT (uint32_t, 2, uint32x2_t, uint32x4_t, u32)   \
> +VARIANT (uint64_t, 1, uint64x1_t, uint64x2_t, u64)   \
> +VARIANT (int8_t, 8, int8x8_t, int8x16_t, s8) \
> +VARIANT (int16_t, 4, int16x4_t, int16x8_t, s16)  \
> +VARIANT (int32_t, 2, int32x2_t, int32x4_t, s32)  \
> +VARIANT (int64_t, 1, int64x1_t, int64x2_t, s64)  \
> +VARIANT (float32_t, 2, float32x2_t, float32x4_t, f32)\
> +VARIANT (float64_t, 1, float64x1_t, float64x2_t, f64)
> +
> +
> +#define TESTMETH(BASETYPE, NUM64, TYPE64, TYPE128, SUFFIX)   \
> +int  \
> +test_vget_low_ ##SUFFIX (BASETYPE *data) \
> +{\
> +  BASETYPE temp [NUM64]; \
> +  TYPE128 vec = vld1q_##SUFFIX (data);   \
> +  TYPE64 lo

Re: [wwwdocs] Update GCC5 changes.html

[Marek Polacek]

On Fri, Aug 22, 2014 at 01:11:28AM +0200, Gerald Pfeifer wrote:
> > +  -fsanitize=float-cast-overflow: check that the 
> > result
> > +  of floating-point type to integer conversion does not overflow;
> 
> "conversions" (plural)?

Ok, changed.
 
> > +A new -Wswitch-bool option has been added for the C 
> > and C++
> > +   compilers, which warns whenever a switch statement has an
> > +   index of boolean type.
> 
> Here, and in the other cases, "A new option ..." might be less
> ambigous -- someone might read this as an option for this command-line
> option.  This is just a suggestion, feel free to ignore.
> 
> I would say "command-line option" instead of just option, though.
 
Done.

> > +A new -Wlogical-not-parentheses option has been added 
> > for the
> > +   C and C++ compilers, which warns about logical not used on the left hand
> > +   side operand of a comparison.
> 
> "logical not" in quotes, perhaps?  Otherwise this may be a bit hard to
> parse.
> 
 
Done.

> > +A new -Wsizeof-array-argument option has been added 
> > for the
> > +   C and C++ compilers, which warns when the sizeof operator 
> > is
> > +   applied to a parameter that is declared as an array in a function 
> > definition.
> 
> "has been" instead of "is declard"?
> 
 
Done.

> > +It is possible to disable warnings about conversions between 
> > pointers
> > +   that have incompatible types via a new warning option
> > +   -Wno-incompatible-pointer-types; warnings about implicit
> > +   incompatible integer to pointer and pointer to integer conversions via
> > +   a new warning option -Wno-int-conversion; and warnings 
> > about
> > +   qualifiers on pointers being discarded via a new warning option
> 
> Should we write "pointer-to-integer" and the like, here and in other
> parts of the patch?  Probably best a question for Joseph (and if he
> has approved code/document patches where that was not the case, than
> the answer pretty likely is now. ;-)

Elsewhere in the code base I see mainly "pointer to integer" so I
haven't changed this.

The following patch contains two more options: -Wc99-c11-compat and
-Wbool-compare.

Ok?

--- changes.html.mp 2014-08-22 15:29:07.345371623 +0200
+++ changes.html2014-08-22 15:46:14.242458840 +0200
@@ -16,11 +16,59 @@
 
 General Optimizer Improvements
 
+  
+UndefinedBehaviorSanitizer gained a few new sanitization options:
+
+  -fsanitize=float-divide-by-zero: detect floating-point
+  division by zero;
+  -fsanitize=float-cast-overflow: check that the result
+  of floating-point type to integer conversions do not overflow;
+  -fsanitize=bounds: enable instrumentation of array 
bounds
+ and detect out-of-bounds accesses;
+  -fsanitize=alignment: enable alignment checking, detect
+ various misaligned objects.
+
+
+  
+
 New Languages and Language specific improvements
 
 
-
-
+C family
+
+  
+A new command-line option -Wswitch-bool has been added for
+   the C and C++ compilers, which warns whenever a switch 
statement
+   has an index of boolean type.
+A new command-line option -Wlogical-not-parentheses has 
been added
+   for the C and C++ compilers, which warns about "logical not" used on 
the left hand
+   side operand of a comparison.
+A new command-line option -Wsizeof-array-argument has 
been added
+   for the C and C++ compilers, which warns when the sizeof 
operator
+   is applied to a parameter that has been declared as an array in a 
function
+   definition.
+A new command-line option -Wbool-compare has been added 
for
+   the C and C++ compilers, which warns about boolean expressions compared 
with
+   an integer value different from 
true/false.
+  
+
+C
+
+  
+A new command-line option -Wc90-c99-compat has been added 
to warn
+   about features not present in ISO C90, but present in ISO C99.
+A new command-line option -Wc99-c11-compat has been added 
to warn
+   about features not present in ISO C99, but present in ISO C11.
+It is possible to disable warnings about conversions between pointers
+   that have incompatible types via a new warning option
+   -Wno-incompatible-pointer-types; warnings about implicit
+   incompatible integer to pointer and pointer to integer conversions via
+   a new warning option -Wno-int-conversion; and warnings 
about
+   qualifiers on pointers being discarded via a new warning option
+   -Wno-discarded-qualifiers.
+The C front end now generates more precise caret diagnostics.
+  
+
 
   
 Fortran

Marek

Re: [C++ PATCH] Fix -Wlogical-not-parentheses (PR c++/62199)

[Marek Polacek]

On Thu, Aug 21, 2014 at 02:34:54PM -0400, Jason Merrill wrote:
> On 08/21/2014 11:41 AM, Marek Polacek wrote:
> >+  current.lhs_type = cp_lexer_next_token_is (parser->lexer, CPP_NOT)
> >+ ? TRUTH_NOT_EXPR : ERROR_MARK;
> ...
> >+  rhs_type = cp_lexer_next_token_is (parser->lexer, CPP_NOT)
> >+ ? TRUTH_NOT_EXPR : ERROR_MARK;
> 
> Again, this indentation needs parens to survive Emacs.
 
Ah, since I don't use Emacs, I thought that the parens are necessary
only if the first operand is e.g. a comparison.  Fixed both.

> >+  /* If the LHS was !CST, we have true/false now.  Convert it
> >+ to integer type, otherwise we wouldn't warn.  */
> >+  if (TREE_CODE (current.lhs) == INTEGER_CST)
> >+lhs = convert (integer_type_node, current.lhs);
> 
> Hmm, why are we checking for BOOLEAN_TYPE on the lhs, again?  It seems to me
> that
> 
> bool b;
> if (!b == 1)
> 
> is also probably an error.

I was checking for BOOLEAN_TYPE on the lhs because that's what clang
seems to be doing.  Yet I agree with you, meaning that I can just drop
the convert line, and the lhs check as well.  I added a new test for
that and updated docs to that effect.  Note that I also added an EXPR_P
check, because without that, we might ICE on an invalid code.  So
hopefully this version is better than the others ;).

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2014-08-22  Marek Polacek  

PR c++/62199
* doc/invoke.texi: Update -Wlogical-not-parentheses description.
c-family/
* c-common.c (warn_logical_not_parentheses): Don't check whether
the LHS is a boolean.
cp/
* parser.c (cp_parser_binary_expression): Check each LHS if it's
preceded with logical not.  Handle logical not of constants.
testsuite/
* c-c++-common/pr62199.c: New test.
* c-c++-common/pr62199-2.c: New test.
* g++.dg/warn/Wparentheses-25.C: Drop XFAILs.

diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index c5eb2a7..58e5944 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -1727,7 +1727,8 @@ warn_logical_operator (location_t location, enum 
tree_code code, tree type,
 
 /* Warn about logical not used on the left hand side operand of a comparison.
This function assumes that the LHS is inside of TRUTH_NOT_EXPR.
-   Do not warn if the LHS or RHS is of a boolean or a vector type.  */
+   Do not warn if the LHS is of a vector type, or if RHS is of a boolean or
+   a vector type.  */
 
 void
 warn_logical_not_parentheses (location_t location, enum tree_code code,
@@ -1738,8 +1739,7 @@ warn_logical_not_parentheses (location_t location, enum 
tree_code code,
   if (TREE_TYPE (lhs) == NULL_TREE
   || TREE_TYPE (rhs) == NULL_TREE)
 ;
-  else if (TREE_CODE (TREE_TYPE (lhs)) == BOOLEAN_TYPE
-  || TREE_CODE (TREE_TYPE (rhs)) == BOOLEAN_TYPE
+  else if (TREE_CODE (TREE_TYPE (rhs)) == BOOLEAN_TYPE
   || VECTOR_TYPE_P (TREE_TYPE (lhs))
   || VECTOR_TYPE_P (TREE_TYPE (rhs)))
 return;
diff --git gcc/cp/parser.c gcc/cp/parser.c
index 9053bfa..7a2cab5 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -8020,13 +8020,12 @@ cp_parser_binary_expression (cp_parser* parser, bool 
cast_p,
   enum tree_code rhs_type;
   enum cp_parser_prec new_prec, lookahead_prec;
   tree overload;
-  bool parenthesized_not_lhs_warn
-= cp_lexer_next_token_is (parser->lexer, CPP_NOT);
 
   /* Parse the first expression.  */
+  current.lhs_type = (cp_lexer_next_token_is (parser->lexer, CPP_NOT))
+? TRUTH_NOT_EXPR : ERROR_MARK;
   current.lhs = cp_parser_cast_expression (parser, /*address_p=*/false,
   cast_p, decltype_p, pidk);
-  current.lhs_type = ERROR_MARK;
   current.prec = prec;
 
   if (cp_parser_error_occurred (parser))
@@ -8081,8 +8080,9 @@ cp_parser_binary_expression (cp_parser* parser, bool 
cast_p,
 
   /* Extract another operand.  It may be the RHS of this expression
 or the LHS of a new, higher priority expression.  */
+  rhs_type = (cp_lexer_next_token_is (parser->lexer, CPP_NOT))
+? TRUTH_NOT_EXPR : ERROR_MARK;
   rhs = cp_parser_simple_cast_expression (parser);
-  rhs_type = ERROR_MARK;
 
   /* Get another operator token.  Look up its precedence to avoid
 building a useless (immediately popped) stack entry for common
@@ -8125,9 +8125,15 @@ cp_parser_binary_expression (cp_parser* parser, bool 
cast_p,
c_inhibit_evaluation_warnings -= current.lhs == truthvalue_true_node;
 
   if (warn_logical_not_paren
- && parenthesized_not_lhs_warn)
-   warn_logical_not_parentheses (current.loc, current.tree_type,
- TREE_OPERAND (current.lhs, 0), rhs);
+ && current.lhs_type == TRUTH_NOT_EXPR)
+   {
+ if (TREE_CODE (current.lhs) == INTEGER_CST)
+   warn_logical_not_parentheses (current.loc, current.tree_type,
+   

Re: [PATCH] Fix condition in ira-color.c and lra-spills.c (PR c/61271)

[Marek Polacek]

On Thu, Aug 21, 2014 at 03:38:25PM -0400, Vladimir Makarov wrote:
> Sorry, Marek.  I guess it is wrong.  STACK_GROWS_DOWNWARD is only 0 or 1
> in these files (it is achieved by redefinition of STACK_GROWS_DOWNWARD
> in the files).  FAME_GROWS_DOWNWARD can be 0 or anything non-zero (even
> non-constant) as tm.texi contains
> 
> @defmac FRAME_GROWS_DOWNWARD
> Define this macro to nonzero value if the addresses of local variable slots
> are at negative offsets from the frame pointer.
> @end defmac
> 
> It works now as all machine description files use 1 as non-zero value.
> 
> So the documentation should be changed but it is not wise, error prune,
> and right now the macro value can be non-constant during compilation
> time theoretically.
 
Whoops, that is sneaky, thanks for the exaplanation.

> So you need another way to transform the expressions to get rid of the
> warning.
> 
> As I remember the code was actually taken from the old RA and not simple
> as it looks.
 
So what we can do is to just wrap the LHS of the comparison in parens;
this ought to suppress the warning.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2014-08-22  Marek Polacek  

PR c/61271
* ira-color.c (coalesced_pseudo_reg_slot_compare): Wrap LHS of
a comparison in parens.
* lra-spills.c (pseudo_reg_slot_compare): Wrap LHS of a comparison
in parens.

diff --git gcc/ira-color.c gcc/ira-color.c
index 36c3c87..e2ea359 100644
--- gcc/ira-color.c
+++ gcc/ira-color.c
@@ -3850,7 +3850,7 @@ coalesced_pseudo_reg_slot_compare (const void *v1p, const 
void *v2p)
   slot_num2 = -ALLOCNO_HARD_REGNO (a2);
   if ((diff = slot_num1 - slot_num2) != 0)
 return (frame_pointer_needed
-   || !FRAME_GROWS_DOWNWARD == STACK_GROWS_DOWNWARD ? diff : -diff);
+   || (!FRAME_GROWS_DOWNWARD) == STACK_GROWS_DOWNWARD ? diff : -diff);
   total_size1 = MAX (PSEUDO_REGNO_BYTES (regno1),
 regno_max_ref_width[regno1]);
   total_size2 = MAX (PSEUDO_REGNO_BYTES (regno2),
diff --git gcc/lra-spills.c gcc/lra-spills.c
index 50f63fc..38a81e6 100644
--- gcc/lra-spills.c
+++ gcc/lra-spills.c
@@ -237,7 +237,7 @@ pseudo_reg_slot_compare (const void *v1p, const void *v2p)
   slot_num2 = pseudo_slots[regno2].slot_num;
   if ((diff = slot_num1 - slot_num2) != 0)
 return (frame_pointer_needed
-   || !FRAME_GROWS_DOWNWARD == STACK_GROWS_DOWNWARD ? diff : -diff);
+   || (!FRAME_GROWS_DOWNWARD) == STACK_GROWS_DOWNWARD ? diff : -diff);
   total_size1 = GET_MODE_SIZE (lra_reg_info[regno1].biggest_mode);
   total_size2 = GET_MODE_SIZE (lra_reg_info[regno2].biggest_mode);
   if ((diff = total_size2 - total_size1) != 0)


Marek

Re: [C++ PATCH] Fix -Wlogical-not-parentheses (PR c++/62199)

[Paolo Carlini]

HI,

On 08/22/2014 04:48 PM, Marek Polacek wrote:

+  current.lhs_type = (cp_lexer_next_token_is (parser->lexer, CPP_NOT))
+? TRUTH_NOT_EXPR : ERROR_MARK;

IMHO, you want to close the parenthesis later, right before the semicolon.

Paolo.

Re: [patch,gomp4] make fortran loop variables implicitly private in openacc

[Cesar Philippidis]

On 08/13/2014 01:41 PM, Tobias Burnus wrote:
> Cesar Philippidis wrote:
>> According to section 2.6.1 in the openacc spec, fortran loop variables
>> should be implicitly private like in openmp. This patch does just so.
> 
> Makes sense. Looking at the patch, I wonder whether the context is
> properly handled when mixing OpenMP and OpenACC. I have the feeling that
> one then might end up using the OpenACC context when one should use the
> OpenMP context. However, I have not fully followed the program flow. For
> instance, would something like
> 
> !$oacc parallel
> !$omp simd private(i) reduction(+:c)
> do i = 1, n
> ...
> end do
> 
> be properly handled?

These contexts are used to prevent situations like that. See
gfortran.dg/goacc/omp.f95 for examples. Also, Thomas mentioned that we
shouldn't need a separate oacc_context, so I've added an is_openmp field
to omp_context to indicate if omp_current_context represents an openmp
context (true) or openacc (false).

>> Also, while working on this patch, I noticed that I made the check for
>> variables appearing in multiple openacc clauses too strict. A private
>> variable may also appear inside a reduction clause. I've also included a
>> fix for this in this patch.
> 
> In OpenMP, one has (OMP 4.0, 2.14.3): "A list item that specifies a
> given variable may not appear in more than one clause on the same
> directive, except that a variable may be specified in both firstprivate
> and lastprivate clauses."
> And in 2.14.3.3, OpenMP has: "List items that appear in a private,
> firstprivate, or reduction clause in a parallel construct may also
> appear in a private clause in an enclosed parallel,task, or worksharing,
> or simd construct.
> 
> I tried to find it in something similar in OpenACC - but I failed. I
> found in (OpenACC 2.0a, 2.7.11) a reference to reduction with private,
> which implies that a reduction variable my be private, but I didn't find
> much more. In particular, it is not clear to me whether it would permit
> only those which are private implicitly or in an oacc parallel region or
> also in an explicit private clause in the same directive. Can you point
> me to the spec?

I'm not sure. I sent an email to the openacc technical mailing list, but
I haven't heard back from them.

> Additionally, I wonder whether you shouldn't also add a test case for
> the reduction with private.

I added one, see private-3.f95. Beware, part of that test is commented
out because our support for the private clause is incomplete. Thomas is
working on the private and firstprivate clauses, so he can uncomment
that portion of the test once the private clause is fully working.

Is this patch ok for gomp-4_0-branch?

Cesar
2014-08-21  Cesar Philippidis  

	gcc/fortran/
	* openmp.c (oacc_compatible_clauses): New function.
	(resolve_omp_clauses): Use it.
	(struct omp_context): Add is_openmp member.
	(gfc_resolve_omp_parallel_blocks): Set is_openmp true.
	(gfc_resolve_do_iterator): Scan for compatible clauses.
	(typedef oacc_context): Remove.
	(oacc_current_ctx): Remove. Use omp_current_ctx for both
	OpenACC and OpenMP.
	(resolve_oacc_directive_inside_omp_region): Replace
	oacc_current_ctx with omp_current_ctx.
	(resolve_omp_directive_inside_oacc_region): Likewise.
	(resolve_oacc_nested_loops): Likewise.
	(resolve_oacc_params_in_parallel): Likewise.
	(resolve_oacc_loop_blocks): Likewise. Set is_openmp to false.

	gcc/testsuite/
	* gfortran.dg/goacc/private-1.f95: New test.
	* gfortran.dg/goacc/private-2.f95: New test.
	* gfortran.dg/goacc/private-3.f95: New test.


diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index 91e00c4..e07a508 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -2713,6 +2713,29 @@ resolve_omp_udr_clause (gfc_omp_namelist *n, gfc_namespace *ns,
   return copy;
 }
 
+/* Returns true if clause in list 'list' is compatible with any of
+   of the clauses in lists [0..list-1].  E.g., a reduction variable may
+   appear in both reduction and private clauses, so this function
+   will return true in this case.  */
+
+static bool
+oacc_compatible_clauses (gfc_omp_clauses *clauses, int list,
+			   gfc_symbol *sym, bool openacc)
+{
+  gfc_omp_namelist *n;
+
+  if (!openacc)
+return false;
+
+  if (list != OMP_LIST_REDUCTION)
+return false;
+
+  for (n = clauses->lists[OMP_LIST_PRIVATE]; n; n = n->next)
+if (n->sym == sym)
+  return true;
+
+  return false;
+}
 
 /* OpenMP directive resolving routines.  */
 
@@ -2826,7 +2849,8 @@ resolve_omp_clauses (gfc_code *code, locus *where,
 	&& list != OMP_LIST_TO)
   for (n = omp_clauses->lists[list]; n; n = n->next)
 	{
-	  if (n->sym->mark)
+	  if (n->sym->mark && !oacc_compatible_clauses (omp_clauses, list,
+			n->sym, openacc))
 	gfc_error ("Symbol '%s' present on multiple clauses at %L",
 		   n->sym->name, where);
 	  else
@@ -3787,6 +3811,7 @@ struct omp_context
   struct pointer_set_t *sharing_clauses;
   struct pointer_set_t *private_iterators;
   struct omp_c

Re: [PATCH] Fix condition in ira-color.c and lra-spills.c (PR c/61271)

[Vladimir Makarov]

On 2014-08-22 10:51 AM, Marek Polacek wrote:

Bootstrapped/regtested on x86_64-linux, ok for trunk?



Ok. Thanks, Marek.


2014-08-22  Marek Polacek  

PR c/61271
* ira-color.c (coalesced_pseudo_reg_slot_compare): Wrap LHS of
a comparison in parens.
* lra-spills.c (pseudo_reg_slot_compare): Wrap LHS of a comparison
in parens.

diff --git gcc/ira-color.c gcc/ira-color.c
index 36c3c87..e2ea359 100644
--- gcc/ira-color.c
+++ gcc/ira-color.c
@@ -3850,7 +3850,7 @@ coalesced_pseudo_reg_slot_compare (const void *v1p, const 
void *v2p)
slot_num2 = -ALLOCNO_HARD_REGNO (a2);
if ((diff = slot_num1 - slot_num2) != 0)
  return (frame_pointer_needed
-   || !FRAME_GROWS_DOWNWARD == STACK_GROWS_DOWNWARD ? diff : -diff);
+   || (!FRAME_GROWS_DOWNWARD) == STACK_GROWS_DOWNWARD ? diff : -diff);
total_size1 = MAX (PSEUDO_REGNO_BYTES (regno1),
 regno_max_ref_width[regno1]);
total_size2 = MAX (PSEUDO_REGNO_BYTES (regno2),
diff --git gcc/lra-spills.c gcc/lra-spills.c
index 50f63fc..38a81e6 100644
--- gcc/lra-spills.c
+++ gcc/lra-spills.c
@@ -237,7 +237,7 @@ pseudo_reg_slot_compare (const void *v1p, const void *v2p)
slot_num2 = pseudo_slots[regno2].slot_num;
if ((diff = slot_num1 - slot_num2) != 0)
  return (frame_pointer_needed
-   || !FRAME_GROWS_DOWNWARD == STACK_GROWS_DOWNWARD ? diff : -diff);
+   || (!FRAME_GROWS_DOWNWARD) == STACK_GROWS_DOWNWARD ? diff : -diff);
total_size1 = GET_MODE_SIZE (lra_reg_info[regno1].biggest_mode);
total_size2 = GET_MODE_SIZE (lra_reg_info[regno2].biggest_mode);
if ((diff = total_size2 - total_size1) != 0)

Re: [Patch 1/2] Don't put out a call to memcpy for volatile struct operations

[Joseph S. Myers]

On Thu, 21 Aug 2014, Mike Stump wrote:

> 1 - I use n843 for C99, which is slightly different from the standard, but in 
> this case I suspect it is the same.

Use N1256 (C99+TC1+TC2+TC3) instead.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [RFC, PATCH 4/n] IPA C++ refactoring

[Jan Hubicka]

> 
> On 08/21/2014 04:31 PM, Jan Hubicka wrote:
> >> Hello,
> >>following patch introduces a new symbol_table class, encapsulating 
> >> functions related to symbol table management. Apart from that, cgraph_edge 
> >> related functions become members of the class. Finally, a portion of 
> >> clean-up has been applied to cgraph.h.
> >>
> >> Bootstrapped on x86_64-pc-linux-gnu and majority of BEs have been tested 
> >> for C and C++, no regression observed.
> >>
> >> Thank you,
> >> Martin
> >>
> >> -  if (!used_as_abstract_origin && cgraph_state != CGRAPH_STATE_PARSING)
> >> +  if (!used_as_abstract_origin && symtab->state != CGRAPH_STATE_PARSING)
> > I would probably rename this CGRAPH_ enum into SYMTAB.  Given it is a 
> > symtab state now ;)
> Good observation, what about renaming enum values to: PARSING, 
> CONSTRUCTION,...
> I think CGRAPH_ prefix is superfluous.

Yep, I just wanted to use cgraph_ consistently for callgarph to avoid namespace 
polution back in 2002 ;)
I suppose we can make it symtab::PARSING
> +  /* Determine if symbol declaration is needed.  That is, visible to 
> something
> + either outside this translation unit, something magic in the system
> + configury */
> +  bool needed_p (void);

Add comment that this is used only during symtab construction.
>  
>/* Create edge from a given function to CALLEE in the cgraph.  */
> -  struct cgraph_edge *create_edge (cgraph_node *callee,
> -gimple call_stmt, gcov_type count,
> -int freq);
> +  cgraph_edge *create_edge (cgraph_node *callee,
> + gimple call_stmt, gcov_type count,
> + int freq);
> +
>/* Create an indirect edge with a yet-undetermined callee where the call
>   statement destination is a formal parameter of the caller with index
>   PARAM_INDEX. */
> -  struct cgraph_edge *create_indirect_edge (gimple call_stmt, int ecf_flags,
> - gcov_type count, int freq,
> - bool compute_indirect_info = true);
> +  cgraph_edge *create_indirect_edge (gimple call_stmt, int ecf_flags,
> +  gcov_type count, int freq,
> +  bool compute_indirect_info = true);

We have add_reference and others are create_*.  I guess we ought rename 
add_reference
to create_reference by followup patch?

An alternative would be to consistently use constructors here...
> +
> +  /* Register a top-level asm statement ASM_STR.  */
> +  inline asm_node *finalize_toplevel_asm (tree asm_str);
> +
> +  /* Analyze the whole compilation unit once it is parsed completely.  */
> +  void finalize_compilation_unit (void);

process_same_body_aliases followed by compile should be here.
> +
> +  /* Process CGRAPH_NEW_FUNCTIONS and perform actions necessary to add these
> + functions into callgraph in a way so they look like ordinary reachable
> + functions inserted into callgraph already at construction time.  */
> +  void process_new_functions (void);
> +
> +  /* C++ frontend produce same body aliases all over the place, even before 
> PCH
> + gets streamed out. It relies on us linking the aliases with their 
> function
> + in order to do the fixups, but ipa-ref is not PCH safe.  Consequentely 
> we
> + first produce aliases without links, but once C++ FE is sure he won't 
> sream
> + PCH we build the links via this function.  */
> +  void process_same_body_aliases (void);
> +
> +  /* Once all functions from compilation unit are in memory, produce all 
> clones
> + and update all calls.  We might also do this on demand if we don't want 
> to
> + bring all functions to memory prior compilation, but current WHOPR
> + implementation does that and it is is bit easier to keep everything 
> right
> + in this order.  */
> +  void materialize_all_clones (void);
> +
> +  /* Perform simple optimizations based on callgraph.  */
> +  void compile (void);
> +
> +  /* Register a symbol NODE.  */
> +  inline void register_symbol (symtab_node *node);
> +
> +  inline void
> +  clear_asm_symbols (void)

OK with these changes.

Honza

Re: [PATCH C/C++] Make use of CPP() for Wdate-time and other flags

[Joseph S. Myers]

On Fri, 22 Aug 2014, Manuel L?pez-Ib??ez wrote:

> Using Common for Wdate-time when it is defined in c.opt does not
> really make sense and breaks CPP(). I also took the opportunity to
> move a duplicated testcase to c-c++-common.
> (svn diff does not show the move).
> 
> Bootstrapped and regression tested on x86_64-linux-gnu.
> 
> OK?

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [C++ PATCH] Fix -Wlogical-not-parentheses (PR c++/62199)

[Marek Polacek]

On Fri, Aug 22, 2014 at 04:53:53PM +0200, Paolo Carlini wrote:
> HI,
> 
> On 08/22/2014 04:48 PM, Marek Polacek wrote:
> >+  current.lhs_type = (cp_lexer_next_token_is (parser->lexer, CPP_NOT))
> >+ ? TRUTH_NOT_EXPR : ERROR_MARK;
> IMHO, you want to close the parenthesis later, right before the semicolon.

Ouch, so much for my formatting skills.

2014-08-22  Marek Polacek  

PR c++/62199
* doc/invoke.texi: Update -Wlogical-not-parentheses description.
c-family/
* c-common.c (warn_logical_not_parentheses): Don't check whether
the LHS is a boolean.
cp/
* parser.c (cp_parser_binary_expression): Check each LHS if it's
preceded with logical not.  Handle logical not of constants.
testsuite/
* c-c++-common/pr62199.c: New test.
* c-c++-common/pr62199-2.c: New test.
* g++.dg/warn/Wparentheses-25.C: Drop XFAILs.

diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index c5eb2a7..58e5944 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -1727,7 +1727,8 @@ warn_logical_operator (location_t location, enum 
tree_code code, tree type,
 
 /* Warn about logical not used on the left hand side operand of a comparison.
This function assumes that the LHS is inside of TRUTH_NOT_EXPR.
-   Do not warn if the LHS or RHS is of a boolean or a vector type.  */
+   Do not warn if the LHS is of a vector type, or if RHS is of a boolean or
+   a vector type.  */
 
 void
 warn_logical_not_parentheses (location_t location, enum tree_code code,
@@ -1738,8 +1739,7 @@ warn_logical_not_parentheses (location_t location, enum 
tree_code code,
   if (TREE_TYPE (lhs) == NULL_TREE
   || TREE_TYPE (rhs) == NULL_TREE)
 ;
-  else if (TREE_CODE (TREE_TYPE (lhs)) == BOOLEAN_TYPE
-  || TREE_CODE (TREE_TYPE (rhs)) == BOOLEAN_TYPE
+  else if (TREE_CODE (TREE_TYPE (rhs)) == BOOLEAN_TYPE
   || VECTOR_TYPE_P (TREE_TYPE (lhs))
   || VECTOR_TYPE_P (TREE_TYPE (rhs)))
 return;
diff --git gcc/cp/parser.c gcc/cp/parser.c
index 9053bfa..ac937c9 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -8020,13 +8020,12 @@ cp_parser_binary_expression (cp_parser* parser, bool 
cast_p,
   enum tree_code rhs_type;
   enum cp_parser_prec new_prec, lookahead_prec;
   tree overload;
-  bool parenthesized_not_lhs_warn
-= cp_lexer_next_token_is (parser->lexer, CPP_NOT);
 
   /* Parse the first expression.  */
+  current.lhs_type = (cp_lexer_next_token_is (parser->lexer, CPP_NOT)
+ ? TRUTH_NOT_EXPR : ERROR_MARK);
   current.lhs = cp_parser_cast_expression (parser, /*address_p=*/false,
   cast_p, decltype_p, pidk);
-  current.lhs_type = ERROR_MARK;
   current.prec = prec;
 
   if (cp_parser_error_occurred (parser))
@@ -8081,8 +8080,9 @@ cp_parser_binary_expression (cp_parser* parser, bool 
cast_p,
 
   /* Extract another operand.  It may be the RHS of this expression
 or the LHS of a new, higher priority expression.  */
+  rhs_type = (cp_lexer_next_token_is (parser->lexer, CPP_NOT)
+ ? TRUTH_NOT_EXPR : ERROR_MARK);
   rhs = cp_parser_simple_cast_expression (parser);
-  rhs_type = ERROR_MARK;
 
   /* Get another operator token.  Look up its precedence to avoid
 building a useless (immediately popped) stack entry for common
@@ -8125,9 +8125,15 @@ cp_parser_binary_expression (cp_parser* parser, bool 
cast_p,
c_inhibit_evaluation_warnings -= current.lhs == truthvalue_true_node;
 
   if (warn_logical_not_paren
- && parenthesized_not_lhs_warn)
-   warn_logical_not_parentheses (current.loc, current.tree_type,
- TREE_OPERAND (current.lhs, 0), rhs);
+ && current.lhs_type == TRUTH_NOT_EXPR)
+   {
+ if (TREE_CODE (current.lhs) == INTEGER_CST)
+   warn_logical_not_parentheses (current.loc, current.tree_type,
+ current.lhs, rhs);
+ else if (EXPR_P (current.lhs))
+   warn_logical_not_parentheses (current.loc, current.tree_type,
+ TREE_OPERAND (current.lhs, 0), rhs);
+   }
 
   overload = NULL;
   /* ??? Currently we pass lhs_type == ERROR_MARK and rhs_type ==
diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi
index f8499bc..df2b722 100644
--- gcc/doc/invoke.texi
+++ gcc/doc/invoke.texi
@@ -4776,8 +4776,9 @@ bit-wise operator is likely to be expected.
 @opindex Wlogical-not-parentheses
 @opindex Wno-logical-not-parentheses
 Warn about logical not used on the left hand side operand of a comparison.
-This option does not warn if the LHS or RHS operand is of a boolean or
-a vector type.  Its purpose is to detect suspicious code like the following:
+This option does not warn if the LHS is of a vector type, or if the RHS
+operand is of a boolean or a vector type.  Its purpose is to detect suspicious
+code like the following:
 @smallexample
 int a;
 @

Re: [patch, avr] Remove avr devices that are not released

[Denis Chertykov]

2014-08-20 18:36 GMT+04:00 Sivanupandi, Pitchumani
:
> Attached patch removes avr devices that are not released
> (may not be released in near future also).
>
> If OK, could someone commit please?
>
> Regards,
> Pitchumani
>
> gcc/ChangeLog
>
> 2014-08-20  Pitchumani Sivanupandi 
>
> * config/avr/avr-mcus.def: Remove atmega26hvg, atmega64rfa2,
> atmega48hvf, atxmega32x1, atmxt224, atmxt224e, atmxt336s,
> atmxt540s and atmxt540sreva devices.
> * config/avr/avr-tables.opt: Regenerate.
> * config/avr/t-multilib: Regenerate.
> * doc/avr-mmcu.texi: Regenerate.
>

Committed.

Denis.

Re: [C++ PATCH] Fix -Wlogical-not-parentheses (PR c++/62199)

[Jason Merrill]

On 08/22/2014 11:59 AM, Marek Polacek wrote:

+ if (TREE_CODE (current.lhs) == INTEGER_CST)
+   warn_logical_not_parentheses (current.loc, current.tree_type,
+ current.lhs, rhs);
+ else if (EXPR_P (current.lhs))
+   warn_logical_not_parentheses (current.loc, current.tree_type,
+ TREE_OPERAND (current.lhs, 0), rhs);


Sorry to nitpick, but now that we aren't checking the lhs for 
BOOLEAN_TYPE, do we need to look at it at all?


Jason

Re: [C++ PATCH] Fix -Wlogical-not-parentheses (PR c++/62199)

[Marek Polacek]

On Fri, Aug 22, 2014 at 12:24:16PM -0400, Jason Merrill wrote:
> On 08/22/2014 11:59 AM, Marek Polacek wrote:
> >+  if (TREE_CODE (current.lhs) == INTEGER_CST)
> >+warn_logical_not_parentheses (current.loc, current.tree_type,
> >+  current.lhs, rhs);
> >+  else if (EXPR_P (current.lhs))
> >+warn_logical_not_parentheses (current.loc, current.tree_type,
> >+  TREE_OPERAND (current.lhs, 0), rhs);
> 
> Sorry to nitpick, but now that we aren't checking the lhs for BOOLEAN_TYPE,
> do we need to look at it at all?

I believe so: if the LHS is an INTEGER_CST, we can't use TREE_OPERAND
on it.  Happens e.g. for if (!5 > a).

Marek

Re: [C++ PATCH] Fix -Wlogical-not-parentheses (PR c++/62199)

[Jason Merrill]

On 08/22/2014 12:33 PM, Marek Polacek wrote:

On Fri, Aug 22, 2014 at 12:24:16PM -0400, Jason Merrill wrote:

Sorry to nitpick, but now that we aren't checking the lhs for BOOLEAN_TYPE,
do we need to look at it at all?


I believe so: if the LHS is an INTEGER_CST, we can't use TREE_OPERAND
on it.  Happens e.g. for if (!5 > a).


Yes, but why do we want to use TREE_OPERAND on it?

Jason

Re: [Patch 1/2] Don't put out a call to memcpy for volatile struct operations

[Mike Stump]

On Aug 22, 2014, at 8:42 AM, Joseph S. Myers  wrote:
> On Thu, 21 Aug 2014, Mike Stump wrote:
>> 1 - I use n843 for C99, which is slightly different from the standard, but 
>> in this case I suspect it is the same.
> 
> Use N1256 (C99+TC1+TC2+TC3) instead.

Thanks.  I had the C99.pdf to quote from, it is just the plain .txt file I find 
way easier than the pdf file.  I’ve updated to n1256 as I found a .txt version 
of it.

[C++ RFC/Patch] PR 34938

[Paolo Carlini]

Hi,

maybe this old issue is already fixed. We used to ICE on:

typedef void (*fptr)() __attribute((noreturn));
template void foo();
template void bar();

fptr f = bar< foo<0> >;

but lately we simply reject it:

34938.C:5:10: error: no matches converting function ‘bar’ to type ‘fptr 
{aka void (*)() volatile}’

fptr f = bar< foo<0> >;
^
34938.C:3:21: note: candidate is: template)() 
volatile> void bar()

template void bar();
^

is that Ok? clang behaves like us, EDG accepts the code. A secondary 
issue I noticed is that we print 'volatile' instead of the attribute, 
that is fixed by the patchlet below.


Thanks,
Paolo.

//
Index: c/c-objc-common.c
===
--- c/c-objc-common.c   (revision 214335)
+++ c/c-objc-common.c   (working copy)
@@ -165,7 +165,8 @@ c_tree_printer (pretty_printer *pp, text_info *tex
   return true;
 
 case 'v':
-  pp_c_cv_qualifiers (cpp, va_arg (*text->args_ptr, int), hash);
+  pp_c_cv_qualifiers (cpp, va_arg (*text->args_ptr, int), hash,
+ /*method_type*/false);
   return true;
 
 default:
Index: c-family/c-pretty-print.c
===
--- c-family/c-pretty-print.c   (revision 214335)
+++ c-family/c-pretty-print.c   (working copy)
@@ -168,7 +168,8 @@ pp_c_exclamation (c_pretty_printer *pp)
 /* Print out the external representation of QUALIFIERS.  */
 
 void
-pp_c_cv_qualifiers (c_pretty_printer *pp, int qualifiers, bool func_type)
+pp_c_cv_qualifiers (c_pretty_printer *pp, int qualifiers,
+   bool func_type, bool method_type)
 {
   const char *p = pp_last_position_in_text (pp);
   bool previous = false;
@@ -192,7 +193,8 @@ void
 {
   if (previous)
 pp_c_whitespace (pp);
-  pp_c_ws_string (pp, func_type ? "__attribute__((const))" : "const");
+  pp_c_ws_string (pp, (func_type && !method_type
+  ? "__attribute__((const))" : "const"));
   previous = true;
 }
 
@@ -200,7 +202,8 @@ void
 {
   if (previous)
 pp_c_whitespace (pp);
-  pp_c_ws_string (pp, func_type ? "__attribute__((noreturn))" : 
"volatile");
+  pp_c_ws_string (pp, (func_type || method_type
+  ? "__attribute__((noreturn))" : "volatile"));
   previous = true;
 }
 
@@ -273,7 +276,8 @@ pp_c_type_qualifier_list (c_pretty_printer *pp, tr
 
   qualifiers = TYPE_QUALS (t);
   pp_c_cv_qualifiers (pp, qualifiers,
- TREE_CODE (t) == FUNCTION_TYPE);
+ TREE_CODE (t) == FUNCTION_TYPE,
+ TREE_CODE (t) == METHOD_TYPE);
 
   if (!ADDR_SPACE_GENERIC_P (TYPE_ADDR_SPACE (t)))
 {
Index: c-family/c-pretty-print.h
===
--- c-family/c-pretty-print.h   (revision 214335)
+++ c-family/c-pretty-print.h   (working copy)
@@ -119,7 +119,8 @@ void pp_c_tree_decl_identifier (c_pretty_printer *
 void pp_c_function_definition (c_pretty_printer *, tree);
 void pp_c_attributes (c_pretty_printer *, tree);
 void pp_c_attributes_display (c_pretty_printer *, tree);
-void pp_c_cv_qualifiers (c_pretty_printer *pp, int qualifiers, bool func_type);
+void pp_c_cv_qualifiers (c_pretty_printer *pp, int qualifiers,
+bool func_type, bool method_type);
 void pp_c_type_qualifier_list (c_pretty_printer *, tree);
 void pp_c_parameter_type_list (c_pretty_printer *, tree);
 void pp_c_specifier_qualifier_list (c_pretty_printer *, tree);
Index: cp/cxx-pretty-print.h
===
--- cp/cxx-pretty-print.h   (revision 214335)
+++ cp/cxx-pretty-print.h   (working copy)
@@ -59,8 +59,8 @@ struct cxx_pretty_printer : c_pretty_printer
 
 #define pp_cxx_cv_qualifier_seq(PP, T)   \
pp_c_type_qualifier_list (PP, T)
-#define pp_cxx_cv_qualifiers(PP, CV)   \
-   pp_c_cv_qualifiers (PP, CV, false)
+#define pp_cxx_cv_qualifiers(PP, CV, FT, MT)   \
+   pp_c_cv_qualifiers (PP, CV, FT, MT)
 
 #define pp_cxx_whitespace(PP)  pp_c_whitespace (PP)
 #define pp_cxx_left_paren(PP)  pp_c_left_paren (PP)
Index: cp/error.c
===
--- cp/error.c  (revision 214335)
+++ cp/error.c  (working copy)
@@ -839,7 +839,9 @@ dump_type_suffix (cxx_pretty_printer *pp, tree t,
dump_parameters (pp, arg, flags & ~TFF_FUNCTION_DEFAULT_ARGUMENTS);
 
pp->padding = pp_before;
-   pp_cxx_cv_qualifiers (pp, type_memfn_quals (t));
+   pp_cxx_cv_qualifiers (pp, type_memfn_quals (t),
+ TREE_CODE (t) == FUNCTION_TYPE,
+ TREE_CODE (t) == METHOD_TYPE);
dump_ref_qualifier (pp, t, flags);
dump_exception_spec (pp, TYPE_RAISES_EXCEPTIONS (t), flags);
dump_type_suffix (pp, TREE_TYPE (t), flags);

Re: [C++ RFC/Patch] PR 34938

[Jason Merrill]

On 08/22/2014 01:53 PM, Paolo Carlini wrote:

maybe this old issue is already fixed. We used to ICE on:

typedef void (*fptr)() __attribute((noreturn));
template void foo();
template void bar();

fptr f = bar< foo<0> >;

but lately we simply reject it:

34938.C:5:10: error: no matches converting function ‘bar’ to type ‘fptr
{aka void (*)() volatile}’
fptr f = bar< foo<0> >;
^
34938.C:3:21: note: candidate is: template)()
volatile> void bar()
template void bar();
^

is that Ok? clang behaves like us, EDG accepts the code.


Well, since the attribute is outside the language, I guess we get to 
decide what it means; C++11 [[noreturn]] is only defined on decls, not 
types.


I think rejecting it makes sense; since bar is not declared as noreturn, 
assigning its address to a noreturn function pointer seems wrong.



A secondary
issue I noticed is that we print 'volatile' instead of the attribute,
that is fixed by the patchlet below.


Currently function-cv-quals on a FUNCTION_TYPE used as a typedef or 
template parameter have the same encoding as the const and noreturn 
attributes; to get the printing right you need to know the context of 
the FUNCTION_TYPE.  If it's the type of a pointer, then the attribute is 
correct.


Jason

Re: [PATCH c++/57709] Wshadow is too strict / has false positives

[Manuel López-Ibáñez]

On 22 August 2014 00:22, Paolo Carlini  wrote:
> Hi,
>
>
> On 08/22/2014 12:01 AM, Manuel López-Ibáñez wrote:
>>
>> On 21 August 2014 23:35, Jason Merrill  wrote:
>>>
>>> On 08/21/2014 04:22 PM, Manuel López-Ibáńez wrote:

 +   && TREE_CODE (x) != FUNCTION_DECL
 +   && !FUNCTION_POINTER_TYPE_P (TREE_TYPE (x
>>>
>>>
>>> How about pointer to member function?
>>
>> Maybe like this? BTW, I did not actually want to include the
>> gcc_assert(), it was just a sanity check, thus I deleted it from this
>> patch.
>
> Note by the way, that this patch would introduce the *first* use of
> FUNCTION_POINTER_TYPE_P in the C++ front-end. Are we sure we want to use
> that vs TYPE_PTRFN_P?!? At the moment I'm a bit tired by I seem to remember
> subtleties in this area...

I took all the comments above into consideration and produced this new
version. Since the comments in cp-tree.h did actually confuse me more
than help, I decided to make them more consistent. This could be
committed together, separated or not at all as you wish.

Bootstrapped and regression tested.

gcc/cp/ChangeLog:

2014-08-22  Manuel López-Ibáñez  

PR c++/57709
* name-lookup.c (pushdecl_maybe_friend_1): Do not warn if a
declaration shadows a function declaration, unless the former
declares a function, pointer to function or pointer to member
function, because this is a common and valid case in real-world
code.
* cp-tree.h (TYPE_PTRFN_P,TYPE_REFFN_P,TYPE_PTRMEMFUNC_P):
Improve description.

gcc/testsuite/ChangeLog:

2014-08-22  Manuel López-Ibáñez  

PR c++/57709
* g++.dg/Wshadow.C: New test.
Index: gcc/testsuite/g++.dg/Wshadow.C
===
--- gcc/testsuite/g++.dg/Wshadow.C  (revision 0)
+++ gcc/testsuite/g++.dg/Wshadow.C  (revision 0)
@@ -0,0 +1,15 @@
+// { dg-do compile }
+// { dg-options "-Wshadow" }
+// PR c++/57709 
+class C {
+  int both_var; // { dg-message "declaration" }
+  void var_and_method(void) {} // { dg-message "declaration" }
+  void m() { 
+int 
+  both_var,  // { dg-warning "shadows" }
+  var_and_method; 
+  }
+  void m2() { 
+void (C::*var_and_method)(void); // { dg-warning "shadows" }
+  }
+};
Index: gcc/cp/cp-tree.h
===
--- gcc/cp/cp-tree.h(revision 214229)
+++ gcc/cp/cp-tree.h(working copy)
@@ -3556,22 +3556,21 @@ more_aggr_init_expr_args_p (const aggr_i
 #define TYPE_PTROBV_P(NODE)\
   (TYPE_PTR_P (NODE)   \
&& !(TREE_CODE (TREE_TYPE (NODE)) == FUNCTION_TYPE  \
|| TREE_CODE (TREE_TYPE (NODE)) == METHOD_TYPE))
 
-/* Returns true if NODE is a pointer to function.  */
+/* Returns true if NODE is a pointer to function type.  */
 #define TYPE_PTRFN_P(NODE) \
   (TYPE_PTR_P (NODE)   \
&& TREE_CODE (TREE_TYPE (NODE)) == FUNCTION_TYPE)
 
-/* Returns true if NODE is a reference to function.  */
+/* Returns true if NODE is a reference to function type.  */
 #define TYPE_REFFN_P(NODE) \
   (TREE_CODE (NODE) == REFERENCE_TYPE  \
&& TREE_CODE (TREE_TYPE (NODE)) == FUNCTION_TYPE)
 
-/* Nonzero for _TYPE node means that this type is a pointer to member
-   function type.  */
+/* Returns true if NODE is a pointer to member function type.  */
 #define TYPE_PTRMEMFUNC_P(NODE)\
   (TREE_CODE (NODE) == RECORD_TYPE \
&& TYPE_PTRMEMFUNC_FLAG (NODE))
 
 #define TYPE_PTRMEMFUNC_FLAG(NODE) \
Index: gcc/cp/name-lookup.c
===
--- gcc/cp/name-lookup.c(revision 214229)
+++ gcc/cp/name-lookup.c(working copy)
@@ -1237,13 +1237,28 @@ pushdecl_maybe_friend_1 (tree x, bool is
  else
member = NULL_TREE;
 
  if (member && !TREE_STATIC (member))
{
- /* Location of previous decl is not useful in this case.  */
- warning (OPT_Wshadow, "declaration of %qD shadows a member of 
'this'",
-  x);
+ if (BASELINK_P (member))
+   member = BASELINK_FUNCTIONS (member);
+ member = OVL_CURRENT (member);
+   
+ /* Do not warn if a variable shadows a function, unless
+the variable is a function or a pointer-to-function.  */
+ if (TREE_CODE (member) != FUNCTION_DECL
+ || TREE_CODE (x) == FUNCTION_DECL
+ || TYPE_PTRFN_P (TREE_TYPE (x))
+ || TYPE_PTRMEMFUNC_P (TREE_TYPE (x)))
+   {
+ if (warning_at (input_location, OPT_Wshadow,
+ "declaration of %qD shadows a member of 
%qT",
+  

Re: [PATCH c++/57709] Wshadow is too strict / has false positives

[Jason Merrill]

On 08/22/2014 02:24 PM, Manuel López-Ibáñez wrote:

+ && DECL_P(member))


Missing space before paren.

OK with that fixed.

Jason

Re: [C++ PATCH] Fix -Wlogical-not-parentheses (PR c++/62199)

[Marek Polacek]

On Fri, Aug 22, 2014 at 12:52:51PM -0400, Jason Merrill wrote:
> On 08/22/2014 12:33 PM, Marek Polacek wrote:
> >On Fri, Aug 22, 2014 at 12:24:16PM -0400, Jason Merrill wrote:
> >>Sorry to nitpick, but now that we aren't checking the lhs for BOOLEAN_TYPE,
> >>do we need to look at it at all?
> >
> >I believe so: if the LHS is an INTEGER_CST, we can't use TREE_OPERAND
> >on it.  Happens e.g. for if (!5 > a).
> 
> Yes, but why do we want to use TREE_OPERAND on it?

Oh yeah, seems that we don't need that.  Actually, I think we can take
this one step further: since we can't use unary ! on a vector, we can
drop the VECTOR_TYPE checks, meaning that we don't need the lhs
parameter at all!  What do you say?

Bootstrapped/regtested on x86_64-linux.

2014-08-22  Marek Polacek  

PR c++/62199
* doc/invoke.texi: Update -Wlogical-not-parentheses description.
c-family/
* c-common.c (warn_logical_not_parentheses): Don't check LHS.  Don't
check for vector types.  Drop LHS argument.
* c-common.h (warn_logical_not_parentheses): Adjust.
c/
* c-typeck.c (parser_build_binary_op): Adjust call to
warn_logical_not_parentheses.
cp/
* parser.c (cp_parser_binary_expression): Check each LHS if it's
preceded with logical not.  Adjust call to
warn_logical_not_parentheses.
testsuite/
* c-c++-common/pr62199.c: New test.
* c-c++-common/pr62199-2.c: New test.
* g++.dg/warn/Wparentheses-25.C: Drop XFAILs.

diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index c5eb2a7..58b9763 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -1727,21 +1727,15 @@ warn_logical_operator (location_t location, enum 
tree_code code, tree type,
 
 /* Warn about logical not used on the left hand side operand of a comparison.
This function assumes that the LHS is inside of TRUTH_NOT_EXPR.
-   Do not warn if the LHS or RHS is of a boolean or a vector type.  */
+   Do not warn if RHS is of a boolean type.  */
 
 void
 warn_logical_not_parentheses (location_t location, enum tree_code code,
- tree lhs, tree rhs)
+ tree rhs)
 {
-  if (TREE_CODE_CLASS (code) != tcc_comparison)
-return;
-  if (TREE_TYPE (lhs) == NULL_TREE
-  || TREE_TYPE (rhs) == NULL_TREE)
-;
-  else if (TREE_CODE (TREE_TYPE (lhs)) == BOOLEAN_TYPE
-  || TREE_CODE (TREE_TYPE (rhs)) == BOOLEAN_TYPE
-  || VECTOR_TYPE_P (TREE_TYPE (lhs))
-  || VECTOR_TYPE_P (TREE_TYPE (rhs)))
+  if (TREE_CODE_CLASS (code) != tcc_comparison
+  || TREE_TYPE (rhs) == NULL_TREE
+  || TREE_CODE (TREE_TYPE (rhs)) == BOOLEAN_TYPE)
 return;
 
   warning_at (location, OPT_Wlogical_not_parentheses,
diff --git gcc/c-family/c-common.h gcc/c-family/c-common.h
index 995bc8c..20b65e9 100644
--- gcc/c-family/c-common.h
+++ gcc/c-family/c-common.h
@@ -780,8 +780,7 @@ extern void overflow_warning (location_t, tree);
 extern bool warn_if_unused_value (const_tree, location_t);
 extern void warn_logical_operator (location_t, enum tree_code, tree,
   enum tree_code, tree, enum tree_code, tree);
-extern void warn_logical_not_parentheses (location_t, enum tree_code, tree,
- tree);
+extern void warn_logical_not_parentheses (location_t, enum tree_code, tree);
 extern void check_main_parameter_types (tree decl);
 extern bool c_determine_visibility (tree);
 extern bool vector_types_compatible_elements_p (tree, tree);
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index d6d96cf..a7de8f3 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -3414,7 +3414,7 @@ parser_build_binary_op (location_t location, enum 
tree_code code,
   if (warn_logical_not_paren
   && code1 == TRUTH_NOT_EXPR
   && code2 != TRUTH_NOT_EXPR)
-warn_logical_not_parentheses (location, code, arg1.value, arg2.value);
+warn_logical_not_parentheses (location, code, arg2.value);
 
   /* Warn about comparisons against string literals, with the exception
  of testing for equality or inequality of a string literal with NULL.  */
diff --git gcc/cp/parser.c gcc/cp/parser.c
index 9053bfa..4dc7c33 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -8020,13 +8020,12 @@ cp_parser_binary_expression (cp_parser* parser, bool 
cast_p,
   enum tree_code rhs_type;
   enum cp_parser_prec new_prec, lookahead_prec;
   tree overload;
-  bool parenthesized_not_lhs_warn
-= cp_lexer_next_token_is (parser->lexer, CPP_NOT);
 
   /* Parse the first expression.  */
+  current.lhs_type = (cp_lexer_next_token_is (parser->lexer, CPP_NOT)
+ ? TRUTH_NOT_EXPR : ERROR_MARK);
   current.lhs = cp_parser_cast_expression (parser, /*address_p=*/false,
   cast_p, decltype_p, pidk);
-  current.lhs_type = ERROR_MARK;
   current.prec = prec;
 
   if (cp_parser_error_occurred (parser))
@@ -8081,8 +8080,9 @@ cp_parser_binary_expression (cp_parser* par

Re: [C++ PATCH] Fix -Wlogical-not-parentheses (PR c++/62199)

[Jason Merrill]

OK, thanks.

Jason

Re: [C++ RFC/Patch] PR 34938

[Paolo Carlini]

Hi,

On 08/22/2014 08:17 PM, Jason Merrill wrote:

On 08/22/2014 01:53 PM, Paolo Carlini wrote:

maybe this old issue is already fixed. We used to ICE on:

typedef void (*fptr)() __attribute((noreturn));
template void foo();
template void bar();

fptr f = bar< foo<0> >;

but lately we simply reject it:

34938.C:5:10: error: no matches converting function ‘bar’ to type ‘fptr
{aka void (*)() volatile}’
fptr f = bar< foo<0> >;
^
34938.C:3:21: note: candidate is: template)()
volatile> void bar()
template void bar();
^

is that Ok? clang behaves like us, EDG accepts the code.


Well, since the attribute is outside the language, I guess we get to 
decide what it means; C++11 [[noreturn]] is only defined on decls, not 
types.


I think rejecting it makes sense; since bar is not declared as 
noreturn, assigning its address to a noreturn function pointer seems 
wrong.

Ok, thanks. Good.

A secondary
issue I noticed is that we print 'volatile' instead of the attribute,
that is fixed by the patchlet below.


Currently function-cv-quals on a FUNCTION_TYPE used as a typedef or 
template parameter have the same encoding as the const and noreturn 
attributes;

Indeed, this is also my understanding per pp_c_cv_qualifiers.
to get the printing right you need to know the context of the 
FUNCTION_TYPE.  If it's the type of a pointer, then the attribute is 
correct.
Ok. Currently in cases like the present one, dump_type_suffix upon a 
pointer recurses and we end up calling pp_cxx_cv_qualifiers on the given 
FUNCTION_TYPE / METHOD_TYPE. Thus pp_cxx_cv_qualifiers lacks the pointer 
context, just sees the latter. Do you think that the current simple 
setup, thus my patch which just extends it, can be incorrect in some cases?


Thanks,
Paolo.

Re: __intN patch 3/5: main __int128 -> __intN conversion.

[DJ Delorie]

> > > Maybe you need to refactor __glibcxx_digits so there is a version taking 
> > > the bitsize as an argument rather than using sizeof(T) * __CHAR_BIT__, 
> > > but 
> > > that should be the only change needed to handle such types with the 
> > > existing macros.  The bitsize macros should be the only ones needing 
> > > predefining to pass information to libstdc++.
> > 
> > Like this?
> 
> Yes (well, the libstdc++ changes will need to go to the libstdc++ mailing 
> list for review there, but this is the sort of thing I'd expect to keep 
> the way libstdc++ defines these limits as consistent as possible between 
> different types).

Ok, here's the updated c-cppbuiltins.c and all the libstdc++-v3
changes, cross-posted to the libstdc++ list.  I tested the macros on
x86-64 (before and after) and msp430 (after) with __int128 and __int20
and get the right values in all cases.


Index: gcc/c-family/c-cppbuiltin.c
===
--- gcc/c-family/c-cppbuiltin.c (revision 213886)
+++ gcc/c-family/c-cppbuiltin.c (working copy)
@@ -775,12 +775,14 @@ cpp_iec_559_complex_value (void)
 }
 
 /* Hook that registers front end and target-specific built-ins.  */
 void
 c_cpp_builtins (cpp_reader *pfile)
 {
+  int i;
+
   /* -undef turns off target-specific built-ins.  */
   if (flag_undef)
 return;
 
   define_language_independent_builtin_macros (pfile);
 
@@ -845,12 +847,29 @@ c_cpp_builtins (cpp_reader *pfile)
   builtin_define_type_minmax ("__WCHAR_MIN__", "__WCHAR_MAX__",
  underlying_wchar_type_node);
   builtin_define_type_minmax ("__WINT_MIN__", "__WINT_MAX__", wint_type_node);
   builtin_define_type_max ("__PTRDIFF_MAX__", ptrdiff_type_node);
   builtin_define_type_max ("__SIZE_MAX__", size_type_node);
 
+  for (i = 0; i < NUM_INT_N_ENTS; i ++)
+if (int_n_enabled_p[i])
+  {
+   char buf[35+20+20];
+
+   /* These are used to configure the C++ library.  */
+
+   if (!flag_iso || int_n_data[i].bitsize == POINTER_SIZE)
+ {
+   sprintf (buf, "__GLIBCXX_TYPE_INT_N_%d=__int%d", i, 
int_n_data[i].bitsize);
+   cpp_define (parse_in, buf);
+
+   sprintf (buf, "__GLIBCXX_BITSIZE_INT_N_%d=%d", i, 
int_n_data[i].bitsize);
+   cpp_define (parse_in, buf);
+ }
+  }
+
   /* stdint.h and the testsuite need to know these.  */
   builtin_define_stdint_macros ();
 
   /* Provide information for library headers to determine whether to
  define macros such as __STDC_IEC_559__ and
  __STDC_IEC_559_COMPLEX__.  */
@@ -993,15 +1012,20 @@ c_cpp_builtins (cpp_reader *pfile)
   else if (flag_stack_protect == 1)
 cpp_define (pfile, "__SSP__=1");
 
   if (flag_openmp)
 cpp_define (pfile, "_OPENMP=201307");
 
-  if (int128_integer_type_node != NULL_TREE)
-builtin_define_type_sizeof ("__SIZEOF_INT128__",
-   int128_integer_type_node);
+  for (i = 0; i < NUM_INT_N_ENTS; i ++)
+if (int_n_enabled_p[i])
+  {
+   char buf[15+20];
+   sprintf(buf, "__SIZEOF_INT%d__", int_n_data[i].bitsize);
+   builtin_define_type_sizeof (buf,
+   int_n_trees[i].signed_type);
+  }
   builtin_define_type_sizeof ("__SIZEOF_WCHAR_T__", wchar_type_node);
   builtin_define_type_sizeof ("__SIZEOF_WINT_T__", wint_type_node);
   builtin_define_type_sizeof ("__SIZEOF_PTRDIFF_T__",
  unsigned_ptrdiff_type_node);
 
   /* A straightforward target hook doesn't work, because of problems
Index: libstdc++-v3/src/c++11/limits.cc
===
--- libstdc++-v3/src/c++11/limits.cc(revision 213886)
+++ libstdc++-v3/src/c++11/limits.cc(working copy)
@@ -385,60 +385,72 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   const bool numeric_limits::is_bounded;
   const bool numeric_limits::is_modulo;
   const bool numeric_limits::traps;
   const bool numeric_limits::tinyness_before;
   const float_round_style numeric_limits::round_style;
 
-#if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_INT128)
-  const bool numeric_limits<__int128>::is_specialized;
-  const int  numeric_limits<__int128>::digits;
-  const int  numeric_limits<__int128>::digits10;
-  const int  numeric_limits<__int128>::max_digits10;
-  const bool numeric_limits<__int128>::is_signed;
-  const bool numeric_limits<__int128>::is_integer;
-  const bool numeric_limits<__int128>::is_exact;
-  const int  numeric_limits<__int128>::radix;
-  const int  numeric_limits<__int128>::min_exponent;
-  const int  numeric_limits<__int128>::min_exponent10;
-  const int  numeric_limits<__int128>::max_exponent;
-  const int  numeric_limits<__int128>::max_exponent10;
-  const bool numeric_limits<__int128>::has_infinity;
-  const bool numeric_limits<__int128>::has_quiet_NaN;
-  const bool numeric_limits<__int128>::has_signaling_NaN;
-  const float_denorm_style numeric_limits<__int128>::has_denorm;
-  const bool 

Re: [C++ RFC/Patch] PR 34938

[Jason Merrill]

On 08/22/2014 03:19 PM, Paolo Carlini wrote:

Ok. Currently in cases like the present one, dump_type_suffix upon a
pointer recurses and we end up calling pp_cxx_cv_qualifiers on the given
FUNCTION_TYPE / METHOD_TYPE. Thus pp_cxx_cv_qualifiers lacks the pointer
context, just sees the latter. Do you think that the current simple
setup, thus my patch which just extends it, can be incorrect in some cases?


Yes, I think your patch changes it to be incorrect in different cases 
than the ones where it's currently incorrect, namely the typedef and 
template argument cases that I mentioned.


Incidentally, I don't understand


+  pp_c_ws_string (pp, (func_type && !method_type

vs

+  pp_c_ws_string (pp, (func_type || method_type


Surely the same logic is appropriate for both const and noreturn, and 
they are represented the same way on both function_ and method_type.


Jason

Re: [C++ PATCH] Fix -Wlogical-not-parentheses (PR c++/62199)

[Jason Merrill]

On 08/22/2014 03:24 PM, Marc Glisse wrote:

Note that there is a patch waiting for a review that makes us accept !v
for vector v:


Ah, indeed.  I still think we might as well treat vectors the same as 
other types here.


Jason

Re: [C++ RFC/Patch] PR 34938

[Paolo Carlini]

Hi,

On 08/22/2014 09:27 PM, Jason Merrill wrote:

On 08/22/2014 03:19 PM, Paolo Carlini wrote:

Ok. Currently in cases like the present one, dump_type_suffix upon a
pointer recurses and we end up calling pp_cxx_cv_qualifiers on the given
FUNCTION_TYPE / METHOD_TYPE. Thus pp_cxx_cv_qualifiers lacks the pointer
context, just sees the latter. Do you think that the current simple
setup, thus my patch which just extends it, can be incorrect in some 
cases?


Yes, I think your patch changes it to be incorrect in different cases 
than the ones where it's currently incorrect, namely the typedef and 
template argument cases that I mentioned.
Let me think about this. I'm not sure to understand what this boils down 
to, if we have to seriously restructure what we have got or not. Do you 
think that we have to track during the recursion in dump_type_suffix 
that the FUNCTION_TYPE / METHOD_TYPE comes from a pointer?

Incidentally, I don't understand


+  pp_c_ws_string (pp, (func_type && !method_type

vs

+  pp_c_ws_string (pp, (func_type || method_type


Surely the same logic is appropriate for both const and noreturn, and 
they are represented the same way on both function_ and method_type.
Ah, Ok, now I see, it's just that volatile member functions aren't 
*that* common ;)


Paolo.

Re: [C++ PATCH] Fix -Wlogical-not-parentheses (PR c++/62199)

[Marc Glisse]

On Fri, 22 Aug 2014, Marek Polacek wrote:


On Fri, Aug 22, 2014 at 12:52:51PM -0400, Jason Merrill wrote:

On 08/22/2014 12:33 PM, Marek Polacek wrote:

On Fri, Aug 22, 2014 at 12:24:16PM -0400, Jason Merrill wrote:

Sorry to nitpick, but now that we aren't checking the lhs for BOOLEAN_TYPE,
do we need to look at it at all?


I believe so: if the LHS is an INTEGER_CST, we can't use TREE_OPERAND
on it.  Happens e.g. for if (!5 > a).


Yes, but why do we want to use TREE_OPERAND on it?


Oh yeah, seems that we don't need that.  Actually, I think we can take
this one step further: since we can't use unary ! on a vector, we can
drop the VECTOR_TYPE checks, meaning that we don't need the lhs
parameter at all!  What do you say?


Note that there is a patch waiting for a review that makes us accept !v 
for vector v:

https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01695.html

I didn't check at what level you do the test, so I don't know if it can 
see a TRUTH_NOT_EXPR for a vector or if it has already been replaced by 
EQ_EXPR at that point.


--
Marc Glisse

Re: [C++ RFC/Patch] PR 34938

[Manuel López-Ibáñez]

On 22 August 2014 21:33, Paolo Carlini  wrote:
>> Incidentally, I don't understand
>>
>>> +  pp_c_ws_string (pp, (func_type && !method_type
>>
>> vs
>>>
>>> +  pp_c_ws_string (pp, (func_type || method_type
>>
>>
>> Surely the same logic is appropriate for both const and noreturn, and they
>> are represented the same way on both function_ and method_type.
>
> Ah, Ok, now I see, it's just that volatile member functions aren't *that*
> common ;)

Are there actually cases where the qualifiers mean different things
for function_type and method_type?

Re: [C++ PATCH] Fix -Wlogical-not-parentheses (PR c++/62199)

[Marc Glisse]

On Fri, 22 Aug 2014, Jason Merrill wrote:


On 08/22/2014 03:24 PM, Marc Glisse wrote:

Note that there is a patch waiting for a review that makes us accept !v
for vector v:


Ah, indeed.  I still think we might as well treat vectors the same as other 
types here.


Ok, now that it is a conscious choice, it feels much safer :-)
Though depending on where exactly this is called, it would be funny if we 
warned for !v==-1 but not for !v==true, when the possible values for the 
elements of !v are actually {-1,0}. I guess I'll have to test after Marek 
commits.


Thanks,

--
Marc Glisse

Re: [C++ RFC/Patch] PR 34938

[Jason Merrill]

On 08/22/2014 03:47 PM, Manuel López-Ibáñez wrote:

Are there actually cases where the qualifiers mean different things
for function_type and method_type?


If a FUNCTION_TYPE is a typedef or template argument, TYPE_READONLY and 
TYPE_VOLATILE are the function-cv-quals.  A plain METHOD_TYPE cannot 
appear in those contexts.


In all other contexts, TYPE_READONLY and TYPE_VOLATILE are attributes 
const and noreturn.


I've tried to move the function-cv-quals out of those flags a couple of 
times and given up.


Jason

Re: [Patch] Switch elimination pass for PR 54742

[Sebastian Pop]

Richard Biener wrote:
> On Wed, Aug 20, 2014 at 10:29 PM, Sebastian Pop  wrote:
> > James Greenhalgh wrote:
> >> On Tue, Aug 19, 2014 at 09:39:56PM +0100, Steve Ellcey wrote:
> >> > Here is an official submission for the switch optimization described in
> >> > PR 54742.  I have addressed the formatting/comment issues that were 
> >> > raised
> >> > and also added a test case based on comment #27 from PR 54742 and I 
> >> > fixed a
> >> > bug I found while doing benchmarking with SPEC2006 (the perl benchmark 
> >> > was
> >> > generating an ICE in a routine with multiple switch statements).
> >> >
> >> > I ran the benchmarking to see if I could find any more tests that are
> >> > helped like coremark is and while I found a number of benchmarks in
> >> > SPEC 2006 and EEMBC where the optimization is triggered, this 
> >> > optimization
> >> > generally didn't affect the performance of those benchmarks.  The biggest
> >> > impact I could find was on the perl benchmark in SPEC where I saw around
> >> > a 0.4% improvement on a MIPS 74k.  Not huge, but not nothing.
> >>
> >> For what it is worth, I see a nice (~4%) improvement in Crafty from
> >> SPEC 2000. I haven't investigated too deeply, but at a first glance the
> >> number of branch mispredictions has dropped just over 1%, as you
> >> might hope from this optimisation.
> >>
> >> I can also attest to there being a number of places the optimisation is
> >> triggered (with high enough parameters; I was running with
> >> --param max-switch-paths=1000 --param max-switch-insns=1), but like
> >> you I don't see much measurable change in execution time.
> >
> > Without change to the default params, I see the switch shortcut having a
> > performance impact on both png and jpeg, compress and decompress mode.
> >
> > I think that's enough to remove the "benchmarketing" label from the switch
> > shortcut transform.
> 
> Did you look at the actual code transformation the pass does to these?
> (what is 'png' and 'jpeg'?)  What's the code size impact?

google("jddctmgr.c") the start_pass function contains a for loop with a switch
stmt that is optimized by Steve's pass.

The png one occurs in google("pngread.c png_image_read_colormap")

There is not much code duplicated in both cases.

Sebastian

Re: __intN patch 3/5: main __int128 -> __intN conversion.

[Joseph S. Myers]

On Fri, 22 Aug 2014, DJ Delorie wrote:

> > > > Maybe you need to refactor __glibcxx_digits so there is a version 
> > > > taking 
> > > > the bitsize as an argument rather than using sizeof(T) * __CHAR_BIT__, 
> > > > but 
> > > > that should be the only change needed to handle such types with the 
> > > > existing macros.  The bitsize macros should be the only ones needing 
> > > > predefining to pass information to libstdc++.
> > > 
> > > Like this?
> > 
> > Yes (well, the libstdc++ changes will need to go to the libstdc++ mailing 
> > list for review there, but this is the sort of thing I'd expect to keep 
> > the way libstdc++ defines these limits as consistent as possible between 
> > different types).
> 
> Ok, here's the updated c-cppbuiltins.c and all the libstdc++-v3
> changes, cross-posted to the libstdc++ list.  I tested the macros on
> x86-64 (before and after) and msp430 (after) with __int128 and __int20
> and get the right values in all cases.

I'd like to see the updated version of the whole of patch 3 (tested to be 
actually independent of the other patches) for review, though I won't be 
reviewing the C++ parts.

> + if (!flag_iso || int_n_data[i].bitsize == POINTER_SIZE)

I don't see flag_iso as relevant here (since the macros are in the 
implementation namespace).  The definitions could reasonably be restricted 
to c_dialect_cxx (), though, given that they are specifically for use by 
libstdc++ (and it's easier to add a macro later for C if needed, than to 
remove one after adding it).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: __intN patch 3/5: main __int128 -> __intN conversion.

[DJ Delorie]

> I don't see flag_iso as relevant here (since the macros are in the 
> implementation namespace).  The definitions could reasonably be restricted 
> to c_dialect_cxx (), though, given that they are specifically for use by 
> libstdc++ (and it's easier to add a macro later for C if needed, than to 
> remove one after adding it).

They reflect a previous check in libstdc++ to remove __int128
specializations for non-ISO cases.  Now, though, libstdc++ doesn't
know which types are needed for pointers and which aren't, so the
check was moved to inside gcc, which does know.

Re: [C++ RFC/Patch] PR 34938

[Paolo Carlini]

Hi again,

On 08/22/2014 09:33 PM, Paolo Carlini wrote:

Hi,

On 08/22/2014 09:27 PM, Jason Merrill wrote:

On 08/22/2014 03:19 PM, Paolo Carlini wrote:

Ok. Currently in cases like the present one, dump_type_suffix upon a
pointer recurses and we end up calling pp_cxx_cv_qualifiers on the 
given
FUNCTION_TYPE / METHOD_TYPE. Thus pp_cxx_cv_qualifiers lacks the 
pointer

context, just sees the latter. Do you think that the current simple
setup, thus my patch which just extends it, can be incorrect in some 
cases?


Yes, I think your patch changes it to be incorrect in different cases 
than the ones where it's currently incorrect, namely the typedef and 
template argument cases that I mentioned.
Let me think about this. I'm not sure to understand what this boils 
down to, if we have to seriously restructure what we have got or not. 
Do you think that we have to track during the recursion in 
dump_type_suffix that the FUNCTION_TYPE / METHOD_TYPE comes from a 
pointer?

Like the below, which I'm finishing testing?

Note that apparently this regressed in 4.9, after some clean ups and C++ 
work to the diagnostic committed by Gaby. Thus maybe eventually we want 
to fix the issue in the release branch too.


Thanks,
Paolo.

PS: Something I also noticed is that we ignore the noreturn attribute in:

typedef void (A::*ptrmf)() __attribute((noreturn));

I don't remember a Bugzilla for that, but I suppose it should be fine. 
clang doesn't complain for sure. And what about references?


typedef void (&fref)() __attribute((noreturn));

/
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 214359)
+++ cp/cp-tree.h(working copy)
@@ -4728,7 +4728,8 @@ enum overload_flags { NO_SPECIAL = 0, DTOR_FLAG, T
TFF_NO_OMIT_DEFAULT_TEMPLATE_ARGUMENTS: do not omit template arguments
identical to their defaults.
TFF_NO_TEMPLATE_BINDINGS: do not print information about the template
-   arguments for a function template specialization.  */
+   arguments for a function template specialization.
+   TFF_POINTER: we are printing a pointer type.  */
 
 #define TFF_PLAIN_IDENTIFIER   (0)
 #define TFF_SCOPE  (1)
@@ -4745,6 +4746,7 @@ enum overload_flags { NO_SPECIAL = 0, DTOR_FLAG, T
 #define TFF_UNQUALIFIED_NAME   (1 << 11)
 #define TFF_NO_OMIT_DEFAULT_TEMPLATE_ARGUMENTS (1 << 12)
 #define TFF_NO_TEMPLATE_BINDINGS   (1 << 13)
+#define TFF_POINTER(1 << 14)
 
 /* Returns the TEMPLATE_DECL associated to a TEMPLATE_TEMPLATE_PARM
node.  */
Index: cp/cxx-pretty-print.h
===
--- cp/cxx-pretty-print.h   (revision 214359)
+++ cp/cxx-pretty-print.h   (working copy)
@@ -59,8 +59,8 @@ struct cxx_pretty_printer : c_pretty_printer
 
 #define pp_cxx_cv_qualifier_seq(PP, T)   \
pp_c_type_qualifier_list (PP, T)
-#define pp_cxx_cv_qualifiers(PP, CV)   \
-   pp_c_cv_qualifiers (PP, CV, false)
+#define pp_cxx_cv_qualifiers(PP, CV, FT) \
+   pp_c_cv_qualifiers (PP, CV, FT)
 
 #define pp_cxx_whitespace(PP)  pp_c_whitespace (PP)
 #define pp_cxx_left_paren(PP)  pp_c_left_paren (PP)
Index: cp/error.c
===
--- cp/error.c  (revision 214359)
+++ cp/error.c  (working copy)
@@ -820,6 +820,8 @@ dump_type_suffix (cxx_pretty_printer *pp, tree t,
   if (TREE_CODE (TREE_TYPE (t)) == ARRAY_TYPE
  || TREE_CODE (TREE_TYPE (t)) == FUNCTION_TYPE)
pp_cxx_right_paren (pp);
+  if (TREE_CODE (t) == POINTER_TYPE)
+   flags |= TFF_POINTER;
   dump_type_suffix (pp, TREE_TYPE (t), flags);
   break;
 
@@ -839,7 +841,7 @@ dump_type_suffix (cxx_pretty_printer *pp, tree t,
dump_parameters (pp, arg, flags & ~TFF_FUNCTION_DEFAULT_ARGUMENTS);
 
pp->padding = pp_before;
-   pp_cxx_cv_qualifiers (pp, type_memfn_quals (t));
+   pp_cxx_cv_qualifiers (pp, type_memfn_quals (t), flags & TFF_POINTER);
dump_ref_qualifier (pp, t, flags);
dump_exception_spec (pp, TYPE_RAISES_EXCEPTIONS (t), flags);
dump_type_suffix (pp, TREE_TYPE (t), flags);
Index: testsuite/g++.dg/template/pr34938.C
===
--- testsuite/g++.dg/template/pr34938.C (revision 0)
+++ testsuite/g++.dg/template/pr34938.C (working copy)
@@ -0,0 +1,7 @@
+// PR c++/34938
+
+typedef void (*fptr)() __attribute((noreturn)); 
+template  void foo();
+template void bar();
+
+fptr f = bar< foo<0> >;   // { dg-error "noreturn" }

Re: [PATCH, C++, CPP] Add C++1z to the preprocessor. Rename C++1y to C++14.

[Jason Merrill]

OK, thanks.

Jason

Re: Migrating gcc.c-torture

[Mike Stump]

On Aug 22, 2014, at 5:18 AM, Bernd Schmidt  wrote:
> 
> Here's another attempt.

> Ok?

Ok.  Thanks a ton for doing the work.

The resolutions look fine, the translation looks good.

Before you check it in, consider:

  930529-1.x has some alpha bits but I didn’t notice a discussion nor do I have 
state on the bug to know if the resolution is correct.

As always, people will comment (or just fix) any noticed fallout.

Re: [C++ RFC/Patch] PR 34938

[Jason Merrill]

Does your patch handle this correctly?

template  struct A { };
A*p = 42;

Jason

Re: [PATCH] * MAINTAINERS (Write After Approval): Add myself.

[Mike Stump]

On Nov 1, 2013, at 3:11 PM, tsaund...@mozilla.com wrote:
> From: tbsaunde 
> 
> diff --git a/ChangeLog b/ChangeLog
> index e925959..8c24d35 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,7 @@
> +2013-11-01  Trevor Saunders  
> +
> +* MAINTAINERS (Write After Approval): Add myself.
> +
> 2013-10-30  Jason Merrill  
> 
>   * Makefile.tpl (STAGE1_CONFIGURE_FLAGS): Pass
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bf16972..25ae10e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -514,6 +514,7 @@ Matthew Sachs 
> msa...@apple.com
> Hariharan Sandanagobalane hariharan@gmail.com
> Iain Sandoe   i...@codesourcery.com
> Duncan Sands  baldr...@gcc.gnu.org
> +Trevor Saunders  tsaund...@mozilla.com
> William Schmidt   wschm...@linux.vnet.ibm.com
> Tilo Schwarz  t...@tilo-schwarz.de
> Dodji Seketelido...@gcc.gnu.org

No, like this:

Index: MAINTAINERS
===
--- MAINTAINERS (revision 214240)
+++ MAINTAINERS (working copy)
@@ -523,7 +523,7 @@ Matthew Sachs   
msa...@apple.com
 Hariharan Sandanagobalane  hariharan@gmail.com
 Iain Sandoei...@codesourcery.com
 Duncan Sands   baldr...@gcc.gnu.org
-Trevor Saunderstsaund...@mozilla.com
+Trevor Saunderstsaund...@mozilla.com
 William Schmidtwschm...@linux.vnet.ibm.com
 Tilo Schwarz   t...@tilo-schwarz.de
 Dodji Seketeli do...@gcc.gnu.org

Also, I’m concerned that someone’s editor isn’t getting the spacing right.  I 
tried emacs, vi vim and ed, they all agree on my machine.  ed of course to rule 
out the new fangled editors, as they might get it wrong…  :-)

Fix ARM ICE for register var asm ("pc") (PR target/60606)

[Joseph S. Myers]

PR 60606 reports an ICE on ARM when declaring a register variable in
register pc.  Discussion in that bug suggests this usage should be
considered invalid and give an error.  It turns out similar ICEs also
occur (after errors) for other cases of invalid register variables.

This patch fixes at least the original bug and others I observed in
the course of fixing it (there may well be other cases of registers,
on ARM and elsewhere, that still create such ICEs).  To make pc
invalid for register variables, arm_regno_class is changed to return
NO_REGS for PC_REGNUM (which is consistent with REG_CLASS_CONTENTS).
Testing the scope of the bug showed similar issues for cc in Thumb
mode; that is made invalid by making arm_hard_regno_mode_ok disallow
it for non-MODE_CC modes (i.e. modes that might apply to a variable).
To avoid ICEs after errors, make_decl_rtl is make to clear
DECL_ASSEMBLER_NAME and DECL_HARD_REGISTER when a hard register
specification turns out to be invalid.  cfgexpand.c:expand_one_var is
then made to call expand_one_error_var in this case, consistent with
other cases of erroneous variables.

Tested with no regressions for cross to arm-none-eabi (it also fixes
failures of gcc.dg/noncompile/920507-1.c, which is PR 61330).  OK to
commit?

2014-08-22  Joseph Myers  

PR target/60606
PR target/61330
* varasm.c (make_decl_rtl): Clear DECL_ASSEMBLER_NAME and
DECL_HARD_REGISTER and return for invalid register specifications.
* cfgexpand.c (expand_one_var): If expand_one_hard_reg_var clears
DECL_HARD_REGISTER, call expand_one_error_var.
* config/arm/arm.c (arm_hard_regno_mode_ok): Do not allow
CC_REGNUM with non-MODE_CC modes.
(arm_regno_class): Return NO_REGS for PC_REGNUM.

2014-08-22  Joseph Myers  

PR target/60606
PR target/61330
* gcc.dg/torture/pr60606-1.c, gcc.target/arm/pr60606-2.c,
gcc.target/arm/pr60606-3.c, gcc.target/arm/pr60606-4.c: New tests.

Index: gcc/cfgexpand.c
===
--- gcc/cfgexpand.c (revision 214225)
+++ gcc/cfgexpand.c (working copy)
@@ -1307,7 +1307,12 @@ expand_one_var (tree var, bool toplevel, bool real
   else if (TREE_CODE (var) == VAR_DECL && DECL_HARD_REGISTER (var))
 {
   if (really_expand)
-expand_one_hard_reg_var (var);
+   {
+ expand_one_hard_reg_var (var);
+ if (!DECL_HARD_REGISTER (var))
+   /* Invalid register specification.  */
+   expand_one_error_var (var);
+   }
 }
   else if (use_register_for_decl (var))
 {
Index: gcc/testsuite/gcc.dg/torture/pr60606-1.c
===
--- gcc/testsuite/gcc.dg/torture/pr60606-1.c(revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr60606-1.c(revision 0)
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-ffat-lto-objects" } */
+
+int
+f (void)
+{
+  register unsigned int r asm ("no-such-register"); /* { dg-error "invalid 
register name" } */
+  return r;
+}
Index: gcc/testsuite/gcc.target/arm/pr60606-2.c
===
--- gcc/testsuite/gcc.target/arm/pr60606-2.c(revision 0)
+++ gcc/testsuite/gcc.target/arm/pr60606-2.c(revision 0)
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O" } */
+
+int
+f (void)
+{
+  register unsigned pc asm ("pc"); /* { dg-error "not general enough" } */
+  
+  return pc > 0x12345678;
+}
Index: gcc/testsuite/gcc.target/arm/pr60606-3.c
===
--- gcc/testsuite/gcc.target/arm/pr60606-3.c(revision 0)
+++ gcc/testsuite/gcc.target/arm/pr60606-3.c(revision 0)
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-O" } */
+
+int
+f (void)
+{
+  register unsigned int r asm ("cc"); /* { dg-error "not general 
enough|suitable for data type" } */
+  return r;
+}
Index: gcc/testsuite/gcc.target/arm/pr60606-4.c
===
--- gcc/testsuite/gcc.target/arm/pr60606-4.c(revision 0)
+++ gcc/testsuite/gcc.target/arm/pr60606-4.c(revision 0)
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-O" } */
+
+int
+f (void)
+{
+  register unsigned int r[50] asm ("r1"); /* { dg-error "suitable for a 
register" } */
+  return r[1];
+}
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 214225)
+++ gcc/config/arm/arm.c(working copy)
@@ -22969,6 +22969,9 @@ arm_hard_regno_mode_ok (unsigned int regno, enum m
|| (TARGET_HARD_FLOAT && TARGET_VFP
&& regno == VFPCC_REGNUM));
 
+  if (regno == CC_REGNUM && GET_MODE_CLASS (mode) != MODE_CC)
+return false;
+
   if (TARGET_THUMB1)
 /* For the Thumb we only allow values bigger than SImode in
registers 0 - 6, so that there is always a second low
@@

Re: [C++ RFC/Patch] PR 34938

[Paolo Carlini]

Hi,

On 08/22/2014 10:45 PM, Jason Merrill wrote:

Does your patch handle this correctly?

template  struct A { };
A*p = 42;

I would say yes:

34938_2.C:2:20: error: invalid conversion from ‘int’ to ‘Aconst>*’ [-fpermissive]

 A*p = 42;

But, interestingly, in this case 4.8.x was incorrect, this specific case 
isn't a 4.9 regression. I would definitely add this testcase too to the 
testsuite.


Paolo.

Re: [PATCH, g++, testsuite] Skip thread_local6.C on target using wrapper

[Mike Stump]

On Aug 21, 2014, at 6:33 PM, Tony Wang  wrote:
> Thanks for your reply, and I also thought of your suggestion to wrap the 
> _exit. The fact is that dejagnu does
> the wrapper to both exit() and _exit(), but it give a higher priority to the 
> exit(), which means if you both
> call exit() and _exit(), it will only output the return value in exit().

Hum...  There is some code that scans for:

*** EXIT code 0

in dejagnu in remote.exp and I suspect it selects the wrong line (if there are 
multiple lines).  I think it should find the last line, not the first.  Another 
fix would be fix it, however, that’s annoying as then we need a dejagnu update 
or we need to replace one of the functions in dejagnu, which I always hate 
doing.  I mention it here for completeness.

> Ok, I will commit with this version.

Thanks.

[PATCH 1/4] aarch64: Improve epilogue unwind info

[Richard Henderson]

Delay cfi restore opcodes until the stack frame is deallocated.
This reduces the number of cfi advance opcodes required.

We perform a similar optimization in the x86_64 epilogue.


* config/aarch64/aarch64.c (aarch64_popwb_single_reg): Remove.
(aarch64_popwb_pair_reg): Remove.
(aarch64_restore_callee_saves): Add CFI_OPS argument; fill it with
the restore ops performed by the insns generated.
(aarch64_expand_epilogue): Attach CFI_OPS to the stack deallocation
insn.  Perform the calls_eh_return addition later; do not attempt to
preserve the CFA in that case.  Don't use aarch64_set_frame_expr.
---
 gcc/config/aarch64/aarch64.c | 177 +--
 1 file changed, 52 insertions(+), 125 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index c3c871e..9a11e05 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1964,23 +1964,6 @@ aarch64_pushwb_single_reg (enum machine_mode mode, 
unsigned regno,
   RTX_FRAME_RELATED_P (insn) = 1;
 }
 
-static void
-aarch64_popwb_single_reg (enum machine_mode mode, unsigned regno,
- HOST_WIDE_INT adjustment)
-{
-  rtx base_rtx = stack_pointer_rtx;
-  rtx insn, reg, mem;
-
-  reg = gen_rtx_REG (mode, regno);
-  mem = gen_rtx_POST_MODIFY (Pmode, base_rtx,
-plus_constant (Pmode, base_rtx, adjustment));
-  mem = gen_rtx_MEM (mode, mem);
-
-  insn = emit_move_insn (reg, mem);
-  add_reg_note (insn, REG_CFA_RESTORE, reg);
-  RTX_FRAME_RELATED_P (insn) = 1;
-}
-
 static rtx
 aarch64_gen_storewb_pair (enum machine_mode mode, rtx base, rtx reg, rtx reg2,
  HOST_WIDE_INT adjustment)
@@ -2011,7 +1994,6 @@ aarch64_pushwb_pair_reg (enum machine_mode mode, unsigned 
regno1,
   insn = emit_insn (aarch64_gen_storewb_pair (mode, stack_pointer_rtx, reg1,
  reg2, adjustment));
   RTX_FRAME_RELATED_P (XVECEXP (PATTERN (insn), 0, 2)) = 1;
-
   RTX_FRAME_RELATED_P (XVECEXP (PATTERN (insn), 0, 1)) = 1;
   RTX_FRAME_RELATED_P (insn) = 1;
 }
@@ -2033,29 +2015,6 @@ aarch64_gen_loadwb_pair (enum machine_mode mode, rtx 
base, rtx reg, rtx reg2,
 }
 }
 
-static void
-aarch64_popwb_pair_reg (enum machine_mode mode, unsigned regno1,
-   unsigned regno2, HOST_WIDE_INT adjustment, rtx cfa)
-{
-  rtx insn;
-  rtx reg1 = gen_rtx_REG (mode, regno1);
-  rtx reg2 = gen_rtx_REG (mode, regno2);
-
-  insn = emit_insn (aarch64_gen_loadwb_pair (mode, stack_pointer_rtx, reg1,
-reg2, adjustment));
-  RTX_FRAME_RELATED_P (XVECEXP (PATTERN (insn), 0, 2)) = 1;
-  RTX_FRAME_RELATED_P (XVECEXP (PATTERN (insn), 0, 1)) = 1;
-  RTX_FRAME_RELATED_P (insn) = 1;
-
-  if (cfa)
-add_reg_note (insn, REG_CFA_ADJUST_CFA,
- (gen_rtx_SET (Pmode, stack_pointer_rtx,
-   plus_constant (Pmode, cfa, adjustment;
-
-  add_reg_note (insn, REG_CFA_RESTORE, reg1);
-  add_reg_note (insn, REG_CFA_RESTORE, reg2);
-}
-
 static rtx
 aarch64_gen_store_pair (enum machine_mode mode, rtx mem1, rtx reg1, rtx mem2,
rtx reg2)
@@ -2151,9 +2110,8 @@ aarch64_save_callee_saves (enum machine_mode mode, 
HOST_WIDE_INT start_offset,
 static void
 aarch64_restore_callee_saves (enum machine_mode mode,
  HOST_WIDE_INT start_offset, unsigned start,
- unsigned limit, bool skip_wb)
+ unsigned limit, bool skip_wb, rtx *cfi_ops)
 {
-  rtx insn;
   rtx base_rtx = stack_pointer_rtx;
   rtx (*gen_mem_ref) (enum machine_mode, rtx) = (frame_pointer_needed
 ? gen_frame_mem : gen_rtx_MEM);
@@ -2187,25 +2145,14 @@ aarch64_restore_callee_saves (enum machine_mode mode,
 
  offset = start_offset + cfun->machine->frame.reg_offset[regno2];
  mem2 = gen_mem_ref (mode, plus_constant (Pmode, base_rtx, offset));
- insn = emit_insn (aarch64_gen_load_pair (mode, reg, mem, reg2,
-  mem2));
- add_reg_note (insn, REG_CFA_RESTORE, reg);
- add_reg_note (insn, REG_CFA_RESTORE, reg2);
+ emit_insn (aarch64_gen_load_pair (mode, reg, mem, reg2, mem2));
 
- /* The first part of a frame-related parallel insn is
-always assumed to be relevant to the frame
-calculations; subsequent parts, are only
-frame-related if explicitly marked.  */
- RTX_FRAME_RELATED_P (XVECEXP (PATTERN (insn), 0, 1)) = 1;
+ *cfi_ops = alloc_reg_note (REG_CFA_RESTORE, reg2, *cfi_ops);
  regno = regno2;
}
   else
-   {
- insn = emit_move_insn (reg, mem);
- add_reg_note (insn, REG_CFA_RESTORE, reg);
-   }
-
-  RTX_FRAME_RELATED_P (insn) = 1;
+   emit_move_insn (reg, mem);
+  *cfi_ops = alloc_

[PATCH 4/4] aarch64: Don't duplicate calls_alloca check

[Richard Henderson]

Generic code already handles calls_alloca for determining
the need for a frame pointer.

* config/aarch64/aarch64.c (aarch64_frame_pointer_required): Don't
check calls_alloca.
---
 gcc/config/aarch64/aarch64.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index c890773..b80f283 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1805,11 +1805,6 @@ aarch64_libgcc_cmp_return_mode (void)
 static bool
 aarch64_frame_pointer_required (void)
 {
-  /* If the function contains dynamic stack allocations, we need to
- use the frame pointer to access the static parts of the frame.  */
-  if (cfun->calls_alloca)
-return true;
-
   /* In aarch64_override_options_after_change
  flag_omit_leaf_frame_pointer turns off the frame pointer by
  default.  Turn it back on now if we've not got a leaf
-- 
1.8.3.1

[PATCH 2/4] aarch64: Tidy prologue unwind notes

[Richard Henderson]

We were marking more than necessary in aarch64_set_frame_expr.
Fold the reduced function into aarch64_expand_prologue as necessary.

* config/aarch64/aarch64.c (aarch64_set_frame_expr): Remove.
(aarch64_expand_prologue): Use REG_CFA_ADJUST_CFA directly,
or no special markup at all.
---
 gcc/config/aarch64/aarch64.c | 56 
 1 file changed, 15 insertions(+), 41 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 9a11e05..dcca446 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1918,22 +1918,6 @@ aarch64_layout_frame (void)
   cfun->machine->frame.laid_out = true;
 }
 
-/* Make the last instruction frame-related and note that it performs
-   the operation described by FRAME_PATTERN.  */
-
-static void
-aarch64_set_frame_expr (rtx frame_pattern)
-{
-  rtx insn;
-
-  insn = get_last_insn ();
-  RTX_FRAME_RELATED_P (insn) = 1;
-  RTX_FRAME_RELATED_P (frame_pattern) = 1;
-  REG_NOTES (insn) = alloc_EXPR_LIST (REG_FRAME_RELATED_EXPR,
- frame_pattern,
- REG_NOTES (insn));
-}
-
 static bool
 aarch64_register_saved_on_entry (int regno)
 {
@@ -2243,29 +2227,29 @@ aarch64_expand_prologue (void)
{
  rtx op0 = gen_rtx_REG (Pmode, IP0_REGNUM);
  emit_move_insn (op0, GEN_INT (-frame_size));
- emit_insn (gen_add2_insn (stack_pointer_rtx, op0));
- aarch64_set_frame_expr (gen_rtx_SET
- (Pmode, stack_pointer_rtx,
-  plus_constant (Pmode,
- stack_pointer_rtx,
- -frame_size)));
+ insn = emit_insn (gen_add2_insn (stack_pointer_rtx, op0));
+
+ add_reg_note (insn, REG_CFA_ADJUST_CFA,
+   gen_rtx_SET (VOIDmode, stack_pointer_rtx,
+plus_constant (Pmode, stack_pointer_rtx,
+   -frame_size)));
+ RTX_FRAME_RELATED_P (insn) = 1;
}
   else if (frame_size > 0)
{
- if ((frame_size & 0xfff) != frame_size)
+ int hi_ofs = frame_size & 0xfff000;
+ int lo_ofs = frame_size & 0x000fff;
+
+ if (hi_ofs)
{
  insn = emit_insn (gen_add2_insn
-   (stack_pointer_rtx,
-GEN_INT (-(frame_size
-   & ~(HOST_WIDE_INT)0xfff;
+   (stack_pointer_rtx, GEN_INT (-hi_ofs)));
  RTX_FRAME_RELATED_P (insn) = 1;
}
- if ((frame_size & 0xfff) != 0)
+ if (lo_ofs)
{
  insn = emit_insn (gen_add2_insn
-   (stack_pointer_rtx,
-GEN_INT (-(frame_size
-   & (HOST_WIDE_INT)0xfff;
+   (stack_pointer_rtx, GEN_INT (-lo_ofs)));
  RTX_FRAME_RELATED_P (insn) = 1;
}
}
@@ -2286,10 +2270,6 @@ aarch64_expand_prologue (void)
  insn = emit_insn (gen_add2_insn (stack_pointer_rtx,
   GEN_INT (-offset)));
  RTX_FRAME_RELATED_P (insn) = 1;
- aarch64_set_frame_expr (gen_rtx_SET
- (Pmode, stack_pointer_rtx,
-  gen_rtx_MINUS (Pmode, stack_pointer_rtx,
- GEN_INT (offset;
 
  aarch64_save_callee_saves (DImode, fp_offset, R29_REGNUM,
 R30_REGNUM, false);
@@ -2302,14 +2282,8 @@ aarch64_expand_prologue (void)
  insn = emit_insn (gen_add3_insn (hard_frame_pointer_rtx,
   stack_pointer_rtx,
   GEN_INT (fp_offset)));
- aarch64_set_frame_expr (gen_rtx_SET
- (Pmode, hard_frame_pointer_rtx,
-  plus_constant (Pmode,
- stack_pointer_rtx,
- fp_offset)));
  RTX_FRAME_RELATED_P (insn) = 1;
- insn = emit_insn (gen_stack_tie (stack_pointer_rtx,
-  hard_frame_pointer_rtx));
+ emit_insn (gen_stack_tie (stack_pointer_rtx, hard_frame_pointer_rtx));
}
   else
{
-- 
1.8.3.1

[PATCH 0/4] AArch64: Improve unwind info generation

[Richard Henderson]

... and other cleanups to the prologue and epilogue functions.

Moving around the epilogue .cfi_restore ops, in particular, is worth
several percentage points in the size of .eh_frame / .debug_frame.

The last numbers I have for this aren't quite comparible, since when
I collected them I was also disabling the frame pointer.  But fwiw,
it was 220k from 1.2M in cc1plus, or just shy of 20%.

Ok?


r~


Richard Henderson (4):
  aarch64: Improve epilogue unwind info
  aarch64: Tidy prologue unwind notes
  aarch64: Tidy prologue local variables
  aarch64: Don't duplicate calls_alloca check

 gcc/config/aarch64/aarch64.c | 252 +--
 1 file changed, 74 insertions(+), 178 deletions(-)

-- 
1.8.3.1

[PATCH 3/4] aarch64: Tidy prologue local variables

[Richard Henderson]

Don't continually re-read data from cfun->machine.

* config/aarch64/aarch64.c (aarch64_expand_prologue): Load
cfun->machine->frame.hard_fp_offset into a local variable.
---
 gcc/config/aarch64/aarch64.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index dcca446..c890773 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -2194,18 +2194,18 @@ aarch64_expand_prologue (void)
   */
   HOST_WIDE_INT frame_size, offset;
   HOST_WIDE_INT fp_offset; /* Offset from hard FP to SP.  */
+  HOST_WIDE_INT hard_fp_offset;
   rtx insn;
 
   aarch64_layout_frame ();
 
-  if (flag_stack_usage_info)
-current_function_static_stack_size = cfun->machine->frame.frame_size;
-
   frame_size = cfun->machine->frame.frame_size;
-  offset = cfun->machine->frame.frame_size;
+  hard_fp_offset = cfun->machine->frame.hard_fp_offset;
+  offset = frame_size;
+  fp_offset = frame_size - hard_fp_offset;
 
-  fp_offset = cfun->machine->frame.frame_size
- - cfun->machine->frame.hard_fp_offset;
+  if (flag_stack_usage_info)
+current_function_static_stack_size = frame_size;
 
   /* Store pairs and load pairs have a range only -512 to 504.  */
   if (offset >= 512)
@@ -2216,7 +2216,7 @@ aarch64_expand_prologue (void)
 register area.  This will allow the pre-index write-back
 store pair instructions to be used for setting up the stack frame
 efficiently.  */
-  offset = cfun->machine->frame.hard_fp_offset;
+  offset = hard_fp_offset;
   if (offset >= 512)
offset = cfun->machine->frame.saved_regs_size;
 
-- 
1.8.3.1

Re: [patch, nios2] testsuite cleanup

[Hans-Peter Nilsson]

On Thu, 21 Aug 2014, Mike Stump wrote:
> On Aug 21, 2014, at 10:59 AM, Sandra Loosemore  
> wrote:
> > On 08/21/2014 11:36 AM, Mike Stump wrote:
> >> On Aug 21, 2014, at 8:00 AM, Sandra Loosemore
> >>  wrote:
> >>> tests that assume some non-default branch costs in the back end
> >>
> >> Thanks.
> >>
> >> One comment, could you put in /* non default branch cost */ above the
> >> three where that is true.
> >
> > The three what?  :-S
>
> Sorry, I meant 4?  Your patch has four instances of this change:
>
> -/* { dg-do run { target { ! "m68k*-*-* mmix*-*-* mep*-*-* bfin*-*-* 
> v850*-*-* picochip*-*-* moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* 
> powerpc*-*-* xtensa*-*-* hppa*-*-*"} } } */
> +/* { dg-do run { target { ! "m68k*-*-* mmix*-*-* mep*-*-* bfin*-*-* 
> v850*-*-* picochip*-*-* moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* 
> powerpc*-*-* xtensa*-*-* hppa*-*-* nios2*-*-*"} } } */
>
> see your patch for them.  Can you change the patch effectively to:
>
> -/* { dg-do run { target { ! "m68k*-*-* mmix*-*-* mep*-*-* bfin*-*-* 
> v850*-*-* picochip*-*-* moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* 
> powerpc*-*-* xtensa*-*-* hppa*-*-*"} } } */
> +/* non default branch cost */
> +/* { dg-do run { target { ! "m68k*-*-* mmix*-*-* mep*-*-* bfin*-*-* 
> v850*-*-* picochip*-*-* moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* 
> powerpc*-*-* xtensa*-*-* hppa*-*-* nios2*-*-*"} } } */
>
> instead?  The comment serves as documentation as to what all
> the listed targets have in common.  A person doing a new port,
> can then read the comment, and say I am non-default branch cost,
> so add me, or alternatively, I am the default, this failure is a
> bug I need to investigate and fix.

It's the other way round re "listed targets".  (CRIS and MMIX
have the default branch cost, ditto m68k and moxie, didn't check
the others.)

brgds, H-P

Re: Enable EBX for x86 in 32bits PIC code

[Hans-Peter Nilsson]

(Dropping gcc@ and people known to subscribe to gcc-patches
from the CC.)

Sorry for the drive-by review, but...

On Fri, 22 Aug 2014, Ilya Enkovich wrote:
> Hi,
>
> On Cauldron 2014 we had a couple of talks about relaxation of
> ebx usage in 32bit PIC mode.  It was decided that the best
> approach would be to not fix ebx register, use speudo register
> for GOT base address and let allocator do the rest.  This should
> be similar to how clang and icc work with GOT base address.
> I've been working for some time on such patch and now want to
> share my results.

...did you send the right version of the patch?
This one uses the RTX-returning hook only in boolean tests,
unless I misread.

Using the return value in boolean tests (non/NULL) here:

> diff --git a/gcc/calls.c b/gcc/calls.c
> index 4285ec1..85dae6b 100644
> --- a/gcc/calls.c
> +++ b/gcc/calls.c
> @@ -1122,6 +1122,14 @@ initialize_argument_information (int num_actuals 
> ATTRIBUTE_UNUSED,
>  call_expr_arg_iterator iter;
>  tree arg;
>
> +if (targetm.calls.implicit_pic_arg (fndecl ? fndecl : fntype))
...
> +  /* Add implicit PIC arg.  */
> +  if (targetm.calls.implicit_pic_arg (fndecl ? fndecl : fntype))
> +num_actuals++;
...
> +  if (targetm.calls.implicit_pic_arg (fndecl ? fndecl : fntype))

but:

> +/* Return reg in which implicit PIC base address
> +   arg is passed.  */
> +static rtx
> +ix86_implicit_pic_arg (const_tree fntype_or_decl ATTRIBUTE_UNUSED)
...
> +#undef TARGET_IMPLICIT_PIC_ARG
> +#define TARGET_IMPLICIT_PIC_ARG ix86_implicit_pic_arg
>  #undef TARGET_FUNCTION_ARG_BOUNDARY

and:

> --- a/gcc/doc/tm.texi
> +++ b/gcc/doc/tm.texi
> @@ -3967,6 +3967,12 @@ If @code{TARGET_FUNCTION_INCOMING_ARG} is not defined,
>  @code{TARGET_FUNCTION_ARG} serves both purposes.
>  @end deftypefn
>
> +@deftypefn {Target Hook} rtx TARGET_IMPLICIT_PIC_ARG (const_tree 
> @var{fntype_or_decl})
> +This hook returns register holding PIC base address for functions
> +which do not fix hard register but handle it similar to function arg
> +assigning a virtual reg for it.
> +@end deftypefn

Also, the contains_symbol_ref removal seems like an independent
cleanup-patch.

> index a458380..63d2be5 100644
> --- a/gcc/var-tracking.c
> +++ b/gcc/var-tracking.c
> @@ -661,7 +661,6 @@ static bool variable_different_p (variable, variable);
>  static bool dataflow_set_different (dataflow_set *, dataflow_set *);
>  static void dataflow_set_destroy (dataflow_set *);
>
> -static bool contains_symbol_ref (rtx);

brgds, H-P

C++ PATCH to support non-constexpr variable templates

[Jason Merrill]

Since nobody else seemed to be working on finishing up variable template 
support, I've gone ahead and done it.  There were only a few tweaks needed.


For the pr59638.C issue, I'm throwing away the implicit template 
parameter list before we call start_decl so we don't actually create an 
implicit template.  I expect that getting from there to doing type 
deduction from the initializer will be pretty simple; my guess is that 
it doesn't work as desired now mainly because type_uses_auto doesn't 
look into parameter types.


Jason
commit 9c0cd66186ac4159b7541ea5968eda6d599d3ab8
Author: Jason Merrill 
Date:   Fri Aug 22 16:34:08 2014 -0400

	Allow non-constexpr variable templates.
	* decl2.c (note_variable_template_instantiation): New.
	* cp-tree.h: Declare it.
	* pt.c (instantiate_decl): Call it.
	(push_template_decl_real): Allow non-constexpr variable templates.
	* semantics.c (finish_id_expression): Mark the variable template
	instantiation as used.
	* mangle.c (write_mangled_name): Variable template instantiations
	are mangled.
	* parser.c (cp_parser_init_declarator): Complain about
	non-function implicit templates.

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 81c7fd6..5d4df6b 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5051,6 +5051,8 @@ variable_template_p (tree t)
 {
   if (TREE_CODE (t) != TEMPLATE_DECL)
 return false;
+  if (!PRIMARY_TEMPLATE_P (t))
+return false;
   if (tree r = DECL_TEMPLATE_RESULT (t))
 return VAR_P (r);
   return false;
@@ -5393,6 +5395,7 @@ extern tree get_tls_wrapper_fn			(tree);
 extern void mark_needed(tree);
 extern bool decl_needed_p			(tree);
 extern void note_vague_linkage_fn		(tree);
+extern void note_variable_template_instantiation (tree);
 extern tree build_artificial_parm		(tree, tree);
 extern bool possibly_inlined_p			(tree);
 extern int parm_index   (tree);
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 63583a8..74a10fb 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -787,6 +787,14 @@ note_vague_linkage_fn (tree decl)
   vec_safe_push (deferred_fns, decl);
 }
 
+/* As above, but for variable template instantiations.  */
+
+void
+note_variable_template_instantiation (tree decl)
+{
+  vec_safe_push (pending_statics, decl);
+}
+
 /* We have just processed the DECL, which is a static data member.
The other parameters are as for cp_finish_decl.  */
 
diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 40508ab..283983f 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -667,6 +667,8 @@ write_mangled_name (const tree decl, bool top_level)
 	}
 }
   else if (VAR_P (decl)
+	   /* Variable template instantiations are mangled.  */
+	   && !(DECL_LANG_SPECIFIC (decl) && DECL_TEMPLATE_INFO (decl))
 	   /* The names of non-static global variables aren't mangled.  */
 	   && DECL_EXTERNAL_LINKAGE_P (decl)
 	   && (CP_DECL_CONTEXT (decl) == global_namespace
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 4dc7c33..7d8b710 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -16779,6 +16779,8 @@ cp_parser_init_declarator (cp_parser* parser,
   /* Peek at the next token.  */
   token = cp_lexer_peek_token (parser->lexer);
 
+  bool bogus_implicit_tmpl = false;
+
   if (function_declarator_p (declarator))
 {
   /* Check to see if the token indicates the start of a
@@ -16831,6 +16833,19 @@ cp_parser_init_declarator (cp_parser* parser,
 	  return decl;
 	}
 }
+  else if (parser->fully_implicit_function_template_p)
+{
+  /* A non-template declaration involving a function parameter list
+	 containing an implicit template parameter will be made into a
+	 template.  If the resulting declaration is not going to be an
+	 actual function then finish the template scope here to prevent it.
+	 An error message will be issued once we have a decl to talk about.
+
+ FIXME probably we should do type deduction rather than create an
+ implicit template, but the standard currently doesn't allow it. */
+  bogus_implicit_tmpl = true;
+  finish_fully_implicit_template (parser, NULL_TREE);
+}
 
   /* [dcl.dcl]
 
@@ -16996,21 +17011,10 @@ cp_parser_init_declarator (cp_parser* parser,
   warning (OPT_Wattributes,
 	   "attributes after parenthesized initializer ignored");
 
-  /* A non-template declaration involving a function parameter list containing
- an implicit template parameter will have been made into a template.  If it
- turns out that the resulting declaration is not an actual function then
- finish the template declaration here.  An error message will already have
- been issued.  */
-  if (parser->fully_implicit_function_template_p)
-if (!function_declarator_p (declarator))
-  {
-	if (pushed_scope)
-	  {
-	pop_scope (pushed_scope);
-	pushed_scope = 0;
-	  }
-	finish_fully_implicit_template (parser, /*member_decl_opt=*/0);
-  }
+  /* And now complain about a non-function implic