Re: [PATCH] PR target/91441 - Turn off -fsanitize=kernel-address if TARGET_ASAN_SHADOW_OFFSET is not implemented.

[Kito Cheng]

Hi Jeff:

Thanks, committed as r274631.

On Fri, Aug 16, 2019 at 11:51 PM Jeff Law  wrote:
>
> On 8/15/19 8:45 PM, Kito Cheng wrote:
> >  - -fsanitize=kernel-address will call targetm.asan_shadow_offset ()
> >at asan_shadow_offset, so it will crash if TARGET_ASAN_SHADOW_OFFSET
> >is not implemented, that's mean -fsanitize=kernel-address is not
> >supported for target without TARGET_ASAN_SHADOW_OFFSET implementation.
> >
> > gcc/ChangeLog:
> >
> >   PR target/91441
> >   * toplev.c (process_options): Check TARGET_ASAN_SHADOW_OFFSET is
> >   implemented for -fsanitize=kernel-address, and merge check logic
> >   with -fsanitize=address.
> >
> > testsuite/ChangeLog:
> >
> >   PR target/91441
> >   * gcc.target/riscv/pr91441.c: New.
> OK
> jeff

Re: C++ PATCH for c++/91264 - detect modifying const objects in constexpr

[Jason Merrill]

Ok, thanks.

On Sun, Aug 18, 2019, 6:26 PM Marek Polacek  wrote:

> On Sun, Aug 18, 2019 at 08:37:14PM -0400, Marek Polacek wrote:
> > Ok if that passes?
>
> Which it did.
>

Re: [PATCH V2 8/8] bpf: add myself as the maintainer for the eBPF port

[Jeff Law]

On 8/16/19 6:50 PM, Jose E. Marchesi wrote:
> ChangeLog:
> 
>   * MAINTAINERS: Add myself as the maintainer for the eBPF port.
Will need steering committee approval, but I don't see that being
problematical.

jeff

Re: [PATCH V2 7/8] bpf: manual updates for eBPF

[Jeff Law]

On 8/16/19 6:50 PM, Jose E. Marchesi wrote:
> gcc/ChangeLog:
> 
>   * doc/invoke.texi (Option Summary): Cover eBPF.
>   (eBPF Options): New section.
>   * doc/extend.texi (BPF Built-in Functions): Likewise.
>   (BPF Kernel Helpers): Likewise.
This is likely fine once the port as a whole is accepted.

jeff

Re: [PATCH V2 6/8] bpf: adjust GCC testsuite to eBPF limitations

[Jeff Law]

On 8/16/19 6:50 PM, Jose E. Marchesi wrote:
> This patch makes many tests in gcc.dg and gcc.c-torture to be skipped
> in bpf-*-* targets.  This is due to the many limitations imposed by
> eBPF to what would be perfectly valid C code: no support for indirect
> calls, no support for more than 5 arguments to function calls, no
> support for indirect jumps, a very limited range for direct jumps, the
> stack limit, lack of standard header files, etc.
> 
> Hopefully some of these restrictions will be relaxed in the future.
> In particular, I expect the stack limit will be significantly
> increased at some point.  Also, as semantics associated with object
> linking get developed in eBPF, it may be possible at some point to
> provide a set of standard run-time libraries for eBPF programs.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.dg/builtins-config.h: eBPF doesn't support C99 standard
>   functions.
>   * gcc.c-torture/compile/2211-1.c: Skip if target bpf-*-*.
>   * gcc.c-torture/compile/2403-1.c: Likewise.
>   * gcc.c-torture/compile/2609-1.c: Likewise.
>   * gcc.c-torture/compile/2804-1.c: Likewise.
>   * gcc.c-torture/compile/20001226-1.c: Likewise.
>   * gcc.c-torture/compile/20010102-1.c: Likewise.
>   * gcc.c-torture/compile/20010107-1.c: Likewise.
>   * gcc.c-torture/compile/20011109-1.c: Likewise.
>   * gcc.c-torture/compile/20011218-1.c: Likewise.
>   * gcc.c-torture/compile/20011229-1.c: Likewise.
>   * gcc.c-torture/compile/20020129-1.c: Likewise.
>   * gcc.c-torture/compile/20020304-1.c: Likewise.
>   * gcc.c-torture/compile/20020320-1.c: Likewise.
>   * gcc.c-torture/compile/20020604-1.c: Likewise.
>   * gcc.c-torture/compile/20020706-1.c: Likewise.
>   * gcc.c-torture/compile/20020706-2.c: Likewise.
>   * gcc.c-torture/compile/20021015-1.c: Likewise.
>   * gcc.c-torture/compile/20021205-1.c: Likewise.
>   * gcc.c-torture/compile/20030903-1.c: Likewise.
>   * gcc.c-torture/compile/20030921-1.c: Likewise.
>   * gcc.c-torture/compile/20031023-1.c: Likewise.
>   * gcc.c-torture/compile/20031023-2.c: Likewise.
>   * gcc.c-torture/compile/20031023-3.c: Likewise.
>   * gcc.c-torture/compile/20031023-4.c: Likewise.
>   * gcc.c-torture/compile/20031125-1.c: Likewise.
>   * gcc.c-torture/compile/20040101-1.c: Likewise.
>   * gcc.c-torture/compile/20040317-2.c: Likewise.
>   * gcc.c-torture/compile/20040614-1.c: Likewise.
>   * gcc.c-torture/compile/20040726-1.c: Likewise.
>   * gcc.c-torture/compile/20040909-1.c: Likewise.
>   * gcc.c-torture/compile/20050122-1.c: Likewise.
>   * gcc.c-torture/compile/20050202-1.c: Likewise.
>   * gcc.c-torture/compile/20050303-1.c: Likewise.
>   * gcc.c-torture/compile/20050622-1.c: Likewise.
>   * gcc.c-torture/compile/20051216-1.c: Likewise.
>   * gcc.c-torture/compile/20060208-1.c: Likewise.
>   * gcc.c-torture/compile/20060421-1.c: Likewise.
>   * gcc.c-torture/compile/20071207-1.c: Likewise.
>   * gcc.c-torture/compile/20080903-1.c: Likewise.
>   * gcc.c-torture/compile/20081108-1.c: Likewise.
>   * gcc.c-torture/compile/20101217-1.c: Likewise.
>   * gcc.c-torture/compile/20121027-1.c: Likewise.
>   * gcc.c-torture/compile/20150327.c: Likewise.
>   * gcc.c-torture/compile/20151204.c: Likewise.
>   * gcc.c-torture/compile/900313-1.c: Likewise.
>   * gcc.c-torture/compile/920428-2.c: Likewise.
>   * gcc.c-torture/compile/920501-12.c: Likewise.
>   * gcc.c-torture/compile/920501-4.c: Likewise.
>   * gcc.c-torture/compile/920501-7.c: Likewise.
>   * gcc.c-torture/compile/920625-1.c: Likewise.
>   * gcc.c-torture/compile/920723-1.c: Likewise.
>   * gcc.c-torture/compile/920928-5.c: Likewise.
>   * gcc.c-torture/compile/921202-1.c: Likewise.
>   * gcc.c-torture/compile/930117-1.c: Likewise.
>   * gcc.c-torture/compile/930421-1.c: Likewise.
>   * gcc.c-torture/compile/930607-1.c: Likewise.
>   * gcc.c-torture/compile/930623-1.c: Likewise.
>   * gcc.c-torture/compile/931003-1.c: Likewise.
>   * gcc.c-torture/compile/931004-1.c: Likewise.
>   * gcc.c-torture/compile/950719-1.c: Likewise.
>   * gcc.c-torture/compile/951222-1.c: Likewise.
>   * gcc.c-torture/compile/961004-1.c: Likewise.
>   * gcc.c-torture/compile/980504-1.c: Likewise.
>   * gcc.c-torture/compile/980816-1.c: Likewise.
>   * gcc.c-torture/compile/990517-1.c: Likewise.
>   * gcc.c-torture/compile/990625-1.c: Likewise.
>   * gcc.c-torture/compile/991213-2.c: Likewise.
>   * gcc.c-torture/compile/DFcmp.c: Likewise.
>   * gcc.c-torture/compile/HIcmp.c: Likewise.
>   * gcc.c-torture/compile/HIset.c: Likewise.
>   * gcc.c-torture/compile/QIcmp.c: Likewise.
>   * gcc.c-torture/compile/QIset.c: Likewise.
>   * gcc.c-torture/compile/SFset.c: Likewise.
>   * gcc.c-torture/compile/SIcmp.c: Likewise.
>   * 

Re: C++ PATCH for c++/91264 - detect modifying const objects in constexpr

[Marek Polacek]

On Sun, Aug 18, 2019 at 08:37:14PM -0400, Marek Polacek wrote:
> Ok if that passes?

Which it did.

Re: [PATCH V2 5/8] bpf: make target-supports.exp aware of eBPF

[Jeff Law]

On 8/16/19 6:50 PM, Jose E. Marchesi wrote:
> This patch makes the several effective target checks in
> target-supports.exp to be aware of eBPF targets.
> 
> gcc/testsuite/ChangeLog:
> 
>   * lib/target-supports.exp (check_effective_target_malloc): New
>   function.
>   (check_effective_target_trampolines): Adapt to eBPF.
>   (check_effective_target_stack_size): Likewise.
>   (dg-effective-target-value): Likewise.
>   (check_effective_target_indirect_jumps): Likewise.
>   (check_effective_target_nonlocal_goto): Likewise.
>   (check_effective_target_global_constructor): Likewise.
>   (check_effective_target_return_address): Likewise.
> ---
>  gcc/testsuite/ChangeLog   | 11 +++
>  gcc/testsuite/lib/target-supports.exp | 27 +++
>  2 files changed, 30 insertions(+), 8 deletions(-)
> 
> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index 300d22a2d65..8b6168626d8 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
>  
> @@ -546,7 +550,11 @@ proc check_effective_target_stack_size { } {
>  proc dg-effective-target-value { effective_target } {
>  if { "$effective_target" == "stack_size" } {
>   if [check_effective_target_stack_size] {
> - return [target_info gcc,stack_size]
> + if [istarget bpf-*-*] {
> + return "512"
> + } else {
> + return [target_info gcc,stack_size]
> + }
>   }
>  }
Shouldn't the BPF stack size be defined be in your target files?


The ChangeLog mentions check_effective_target_malloc, but I don't see it
in the patch itself.  Note that it needs to be documented in
gcc/doc/sourcebuild.texi as well if you are adding a new
check_effective_target_

jeff

Re: [PATCH V2 4/8] bpf: gcc.target eBPF testsuite

[Jeff Law]

On 8/16/19 6:50 PM, Jose E. Marchesi wrote:
> This patch adds a new testsuite to gcc.target, with eBPF specific
> tests.
> 
> Tests are included for:
> - Target specific diagnostics.
> - All built-in functions.
> 
> testsuite/ChangeLog:
> 
>   * gcc.target/bpf/bpf.exp: New file.
>   * gcc.target/bpf/builtin-load.c: Likewise.
>   * cc.target/bpf/constant-calls.c: Likewise.
>   * gcc.target/bpf/diag-funargs.c: Likewise.
>   * cc.target/bpf/diag-indcalls.c: Likewise.
>   * gcc.target/bpf/helper-bind.c: Likewise.
>   * cc.target/bpf/helper-bpf-redirect.c: Likewise.
>   * gcc.target/bpf/helper-clone-redirect.c: Likewise.
>   * gcc.target/bpf/helper-csum-diff.c: Likewise.
>   * gcc.target/bpf/helper-csum-update.c: Likewise.
>   * gcc.target/bpf/helper-current-task-under-cgroup.c: Likewise.
>   * gcc.target/bpf/helper-fib-lookup.c: Likewise.
>   * gcc.target/bpf/helper-get-cgroup-classid.c: Likewise.
>   * gcc.target/bpf/helper-get-current-cgroup-id.c: Likewise.
>   * gcc.target/bpf/helper-get-current-comm.c: Likewise.
>   * gcc.target/bpf/helper-get-current-pid-tgid.c: Likewise.
>   * gcc.target/bpf/helper-get-current-task.c: Likewise.
>   * gcc.target/bpf/helper-get-current-uid-gid.c: Likewise.
>   * gcc.target/bpf/helper-get-hash-recalc.c: Likewise.
>   * gcc.target/bpf/helper-get-listener-sock.c: Likewise.
>   * gcc.target/bpf/helper-get-local-storage.c: Likewise.
>   * gcc.target/bpf/helper-get-numa-node-id.c: Likewise.
>   * gcc.target/bpf/helper-get-prandom-u32.c: Likewise.
>   * gcc.target/bpf/helper-get-route-realm.c: Likewise.
>   * gcc.target/bpf/helper-get-smp-processor-id.c: Likewise.
>   * gcc.target/bpf/helper-get-socket-cookie.c: Likewise.
>   * gcc.target/bpf/helper-get-socket-uid.c: Likewise.
>   * gcc.target/bpf/helper-getsockopt.c: Likewise.
>   * gcc.target/bpf/helper-get-stack.c: Likewise.
>   * gcc.target/bpf/helper-get-stackid.c: Likewise.
>   * gcc.target/bpf/helper-ktime-get-ns.c: Likewise.
>   * gcc.target/bpf/helper-l3-csum-replace.c: Likewise.
>   * gcc.target/bpf/helper-l4-csum-replace.c: Likewise.
>   * gcc.target/bpf/helper-lwt-push-encap.c: Likewise.
>   * gcc.target/bpf/helper-lwt-seg6-action.c: Likewise.
>   * gcc.target/bpf/helper-lwt-seg6-adjust-srh.c: Likewise.
>   * gcc.target/bpf/helper-lwt-seg6-store-bytes.c: Likewise.
>   * gcc.target/bpf/helper-map-delete-elem.c: Likewise.
>   * gcc.target/bpf/helper-map-lookup-elem.c: Likewise.
>   * gcc.target/bpf/helper-map-peek-elem.c: Likewise.
>   * gcc.target/bpf/helper-map-pop-elem.c: Likewise.
>   * gcc.target/bpf/helper-map-push-elem.c: Likewise.
>   * gcc.target/bpf/helper-map-update-elem.c: Likewise.
>   * gcc.target/bpf/helper-msg-apply-bytes.c: Likewise.
>   * gcc.target/bpf/helper-msg-cork-bytes.c: Likewise.
>   * gcc.target/bpf/helper-msg-pop-data.c: Likewise.
>   * gcc.target/bpf/helper-msg-pull-data.c: Likewise.
>   * gcc.target/bpf/helper-msg-push-data.c: Likewise.
>   * gcc.target/bpf/helper-msg-redirect-hash.c: Likewise.
>   * gcc.target/bpf/helper-msg-redirect-map.c: Likewise.
>   * gcc.target/bpf/helper-override-return.c: Likewise.
>   * gcc.target/bpf/helper-perf-event-output.c: Likewise.
>   * gcc.target/bpf/helper-perf-event-read.c: Likewise.
>   * gcc.target/bpf/helper-perf-event-read-value.c: Likewise.
>   * gcc.target/bpf/helper-perf-prog-read-value.c: Likewise.
>   * gcc.target/bpf/helper-probe-read.c: Likewise.
>   * gcc.target/bpf/helper-probe-read-str.c: Likewise.
>   * gcc.target/bpf/helper-probe-write-user.c: Likewise.
>   * gcc.target/bpf/helper-rc-keydown.c: Likewise.
>   * gcc.target/bpf/helper-rc-pointer-rel.c: Likewise.
>   * gcc.target/bpf/helper-rc-repeat.c: Likewise.
>   * gcc.target/bpf/helper-redirect-map.c: Likewise.
>   * gcc.target/bpf/helper-set-hash.c: Likewise.
>   * gcc.target/bpf/helper-set-hash-invalid.c: Likewise.
>   * gcc.target/bpf/helper-setsockopt.c: Likewise.
>   * gcc.target/bpf/helper-skb-adjust-room.c: Likewise.
>   * gcc.target/bpf/helper-skb-cgroup-id.c: Likewise.
>   * gcc.target/bpf/helper-skb-change-head.c: Likewise.
>   * gcc.target/bpf/helper-skb-change-proto.c: Likewise.
>   * gcc.target/bpf/helper-skb-change-tail.c: Likewise.
>   * gcc.target/bpf/helper-skb-change-type.c: Likewise.
>   * gcc.target/bpf/helper-skb-ecn-set-ce.c: Likewise.
>   * gcc.target/bpf/helper-skb-get-tunnel-key.c: Likewise.
>   * gcc.target/bpf/helper-skb-get-tunnel-opt.c: Likewise.
>   * gcc.target/bpf/helper-skb-get-xfrm-state.c: Likewise.
>   * gcc.target/bpf/helper-skb-load-bytes.c: Likewise.
>   * gcc.target/bpf/helper-skb-load-bytes-relative.c: Likewise.
>   * gcc.target/bpf/helper-skb-pull-data.c: Likewise.
>   * gcc.target/bpf/helper-skb-set-tunnel-key.c: Likewise.
>   * 

Re: [PATCH V2 3/8] bpf: new libgcc port

[Jeff Law]

On 8/16/19 6:50 PM, Jose E. Marchesi wrote:
> This patch adds an eBPF port to libgcc.
> 
> As of today, compiled eBPF programs do not support a single-entry
> point schema.  Instead, a BPF "executable" is a relocatable ELF object
> file containing multiple entry points, in certain named sections.
> 
> Also, the BPF loaders in the kernel do not execute .ini/.fini
> constructors/destructors.  Therefore, this patch provides empty crtn.S
> and cri.S files.
> 
> libgcc/ChangeLog:
> 
>   * config.host: Set cpu_type for bpf-*-* targets.
>   * config/bpf/t-bpf: Likewise.
>   * config/bpf/crtn.S: Likewise.
>   * config/bpf/crti.S: New file.

> diff --git a/libgcc/config/bpf/crti.S b/libgcc/config/bpf/crti.S
> new file mode 100644
> index 000..e69de29bb2d
> diff --git a/libgcc/config/bpf/crtn.S b/libgcc/config/bpf/crtn.S
> new file mode 100644
> index 000..e69de29bb2d
> diff --git a/libgcc/config/bpf/t-bpf b/libgcc/config/bpf/t-bpf
> new file mode 100644
> index 000..c1bda7c98cb
> --- /dev/null
> +++ b/libgcc/config/bpf/t-bpf
> @@ -0,0 +1,24 @@
> +HOST_LIBGCC2_CFLAGS += -O0
> +LIB2ADDEH = 
I'd like to understand the motivation behind the -O0, but otherwise I
don't see anything particularly concerning here.

Jeff

Re: [PATCH V2 1/8] Update config.sub and config.guess.

[Jeff Law]

On 8/16/19 6:50 PM, Jose E. Marchesi wrote:
>   * config.sub: Import upstream version 2019-06-30.
>   * config.guess: Import upstream version 2019-07-24.
Similar to the runtimes and such where we're downstream resyncing to the
upstream sources is always OK in stage1.  Feel free to commit whenever
you want.

jeff

[RFA] [PR tree-optimization/80576] Handle strcpy and strcpy_chk in DSE

[Jeff Law]

So this builds on the previous DSE patch to add handling of strcpy and
resolves the remainder of 80576.

Recall there's two cases to consider.

If the strcpy is the first store (ie, potentially dead), then the
conservative choice when setting up the ao_ref is to take the smaller of
the destination object's size and the maximum length of the source string.

For the second store (ie, the killing store) we want the minimum of the
length of the source string when setting up the ao_ref.

We do not handle trimming in the case of a partially dead call to
strcpy.  We only handle cases where it's fully dead.


Bootstrapped and regression tested on x86_64, i686, aarch64, ppc64,
ppc64le, s390x & sparc64.

Also built and tested the various *-elf targets with no regressions.  I
also verified the new test passes on all those targets.

Several other targets have been bootstrapped (alpha, m68k, various arm*
things, mipsisa32r2, riscv64 and others).


OK for the trunk?

Jeff



PR tree-optimization/80576
* tree-ssa-dse.c (initialize_ao_ref_for_dse): Handle strcpy and
strcpy_chk.
(dse_dom_walker::dse_optimize_stmt): Similarly.
 
* gcc.dg/tree-ssa/ssa-dse-41.c: New test.

commit 24f60672cacb4da2ae898ec7e90bd55f52073954
Author: Jeff Law 
Date:   Fri Aug 9 18:13:50 2019 -0400

MOre DSE improvements

Add test

diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
index ae03980f792..47907617aaf 100644
--- a/gcc/tree-ssa-dse.c
+++ b/gcc/tree-ssa-dse.c
@@ -181,6 +181,56 @@ initialize_ao_ref_for_dse (gimple *stmt, ao_ref *write, 
bool maxlen)
return true;
  }
 
+   case BUILT_IN_STRCPY:
+   case BUILT_IN_STRCPY_CHK:
+ {
+   tree dest = gimple_call_arg (stmt, 0);
+   tree src = gimple_call_arg (stmt, 1);
+   tree size = NULL_TREE;
+
+   /* Get the range of the length of the source string.  */
+   c_strlen_data src_data = { };
+   if (get_range_strlen (src, _data, 1))
+ {
+   size = maxlen ? src_data.maxlen : src_data.minlen;
+
+   /* Adjust the source length to account for NUL terminator.  */
+   size = fold_build2 (PLUS_EXPR, TREE_TYPE (size), size, 
integer_one_node);
+ }
+
+   /* If we are asking for the minimum size and did not get a usable
+  size from get_range_strlen, then the minimum size would be zero
+  and there's nothing we can do.   If we were asking for the
+  maximum size, then we can try and get a size from the destination
+  object.  */
+   if (!maxlen && !size)
+ return false;
+
+   /* If we did not get a size from the source operand, then try to
+  get it from the size of the destination object's type.
+
+  If we got a size from the source operand, then choose the
+  minimum of the size from the operand and the size we got
+  from the input operand.  In theory the latter would be
+  sufficient, but the size from the input operand is a range
+  and could, in theory, be larger than the output buffer
+  due to imprecision in the computation of the size.  */
+   tree dest_size = objsize_from_type (dest);
+   if (!size)
+ size = dest_size;
+   else if (dest_size)
+ size = fold_build2 (MIN_EXPR, TREE_TYPE (dest_size),
+ dest_size, size);
+
+   /* If we still don't have size information, then assume we can
+  not analyze this case.  */
+   if (!size)
+ return false;
+
+   ao_ref_init_from_ptr_and_size (write, dest, size);
+   return true;
+ }
+
/* A calloc call can never be dead, but it can make
   subsequent stores redundant if they store 0 into
   the same memory locations.  */
@@ -1078,6 +1128,26 @@ dse_dom_walker::dse_optimize_stmt (gimple_stmt_iterator 
*gsi)
return;
  }
 
+   case BUILT_IN_STRCPY:
+   case BUILT_IN_STRCPY_CHK:
+ {
+   enum dse_store_status store_status;
+   m_byte_tracking_enabled
+ = setup_live_bytes_from_ref (, m_live_bytes);
+   store_status = dse_classify_store (, stmt,
+  m_byte_tracking_enabled,
+  m_live_bytes);
+   if (store_status == DSE_STORE_LIVE)
+ return;
+
+   /* We don't handle trimming these calls, though we might
+  be able to trim a strcpy into a strncpy for example.  */
+
+   if (store_status == DSE_STORE_DEAD)
+ delete_dead_or_redundant_call (gsi, "dead");
+   break;
+ }
+
case BUILT_IN_CALLOC:
  /* We already know the arguments are integer constants.  */
  dse_optimize_redundant_stores (stmt);
diff 

Re: C++ PATCH for c++/91264 - detect modifying const objects in constexpr

[Marek Polacek]

On Sun, Aug 18, 2019 at 05:08:07PM -0700, Jason Merrill wrote:
> On 8/18/19 6:52 AM, Marek Polacek wrote:
> > On Fri, Aug 16, 2019 at 05:40:39PM -0700, Jason Merrill wrote:
> > > On 8/16/19 5:11 AM, Marek Polacek wrote:
> > > > On Thu, Aug 15, 2019 at 08:21:25PM -0400, Jason Merrill wrote:
> > > > > On 8/15/19 5:34 PM, Marek Polacek wrote:
> > > > > > On Wed, Aug 14, 2019 at 02:50:13PM -0400, Jason Merrill wrote:
> > > > > > > On Thu, Aug 8, 2019 at 3:25 PM Marek Polacek  
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > On Thu, Aug 08, 2019 at 11:06:17AM -0400, Jason Merrill wrote:
> > > > > > > > > On 8/6/19 3:20 PM, Marek Polacek wrote:
> > > > > > > > > > On Mon, Aug 05, 2019 at 03:54:19PM -0400, Jason Merrill 
> > > > > > > > > > wrote:
> > > > > > > > > > > On 7/31/19 3:26 PM, Marek Polacek wrote:
> > > > > > > > > > > > One of the features of constexpr is that it doesn't 
> > > > > > > > > > > > allow UB; and such UB must
> > > > > > > > > > > > be detected at compile-time.  So running your code in a 
> > > > > > > > > > > > context that requires
> > > > > > > > > > > > a constant expression should ensure that the code in 
> > > > > > > > > > > > question is free of UB.
> > > > > > > > > > > > In effect, constexpr can serve as a sanitizer.  E.g. 
> > > > > > > > > > > > this article describes in
> > > > > > > > > > > > in more detail:
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > [dcl.type.cv]p4 says "Any attempt to modify a const 
> > > > > > > > > > > > object during its lifetime
> > > > > > > > > > > > results in undefined behavior." However, as the article 
> > > > > > > > > > > > above points out, we
> > > > > > > > > > > > aren't detecting that case in constexpr evaluation.
> > > > > > > > > > > > 
> > > > > > > > > > > > This patch fixes that.  It's not that easy, though, 
> > > > > > > > > > > > because we have to keep in
> > > > > > > > > > > > mind [class.ctor]p5:
> > > > > > > > > > > > "A constructor can be invoked for a const, volatile or 
> > > > > > > > > > > > const volatile object.
> > > > > > > > > > > > const and volatile semantics are not applied on an 
> > > > > > > > > > > > object under construction.
> > > > > > > > > > > > They come into effect when the constructor for the most 
> > > > > > > > > > > > derived object ends."
> > > > > > > > > > > > 
> > > > > > > > > > > > I handled this by keeping a hash set which tracks 
> > > > > > > > > > > > objects under construction.
> > > > > > > > > > > > I considered other options, such as going up 
> > > > > > > > > > > > call_stack, but that wouldn't
> > > > > > > > > > > > work with trivial constructor/op=.  It was also 
> > > > > > > > > > > > interesting to find out that
> > > > > > > > > > > > the definition of TREE_HAS_CONSTRUCTOR says "When 
> > > > > > > > > > > > appearing in a FIELD_DECL,
> > > > > > > > > > > > it means that this field has been duly initialized in 
> > > > > > > > > > > > its constructor" though
> > > > > > > > > > > > nowhere in the codebase do we set TREE_HAS_CONSTRUCTOR 
> > > > > > > > > > > > on a FIELD_DECL as far
> > > > > > > > > > > > as I can see.  Unfortunately, using this bit proved 
> > > > > > > > > > > > useless for my needs here.
> > > > > > > > > > > 
> > > > > > > > > > > > Also, be mindful of mutable subobjects.
> > > > > > > > > > > > 
> > > > > > > > > > > > Does this approach look like an appropriate strategy 
> > > > > > > > > > > > for tracking objects'
> > > > > > > > > > > > construction?
> > > > > > > > > > > 
> > > > > > > > > > > For scalar objects, we should be able to rely on 
> > > > > > > > > > > INIT_EXPR vs. MODIFY_EXPR
> > > > > > > > > > > to distinguish between initialization and modification; 
> > > > > > > > > > > for class objects, I
> > > > > > > > > > 
> > > > > > > > > > This is already true: only class object go into the hash 
> > > > > > > > > > set.
> > > > > > > > > > 
> > > > > > > > > > > wonder about setting a flag on the CONSTRUCTOR after 
> > > > > > > > > > > initialization is
> > > > > > > > > > > complete to indicate that the value is now constant.
> > > > > > > > > > 
> > > > > > > > > > But here we're not dealing with CONSTRUCTORs in the gcc 
> > > > > > > > > > sense (i.e. exprs with
> > > > > > > > > > TREE_CODE == CONSTRUCTOR).  We have a CALL_EXPR like Y::Y 
> > > > > > > > > > ((struct Y *) ),
> > > > > > > > > > which initializes the object "y".  Setting a flag on the 
> > > > > > > > > > CALL_EXPR or its underlying
> > > > > > > > > > function decl wouldn't help.
> > > > > > > > > > 
> > > > > > > > > > Am I missing something?
> > > > > > > > > 
> > > > > > > > > I was thinking that where in your current patch you call
> > > > > > > > > remove_object_under_construction, we could instead mark the 
> > > > > > > > > object's value
> > > > > > > > > CONSTRUCTOR as immutable.
> > > > > > > > 
> > > > 

Re: C++ PATCH for c++/91264 - detect modifying const objects in constexpr

[Jason Merrill]

On 8/18/19 6:52 AM, Marek Polacek wrote:

On Fri, Aug 16, 2019 at 05:40:39PM -0700, Jason Merrill wrote:

On 8/16/19 5:11 AM, Marek Polacek wrote:

On Thu, Aug 15, 2019 at 08:21:25PM -0400, Jason Merrill wrote:

On 8/15/19 5:34 PM, Marek Polacek wrote:

On Wed, Aug 14, 2019 at 02:50:13PM -0400, Jason Merrill wrote:

On Thu, Aug 8, 2019 at 3:25 PM Marek Polacek  wrote:


On Thu, Aug 08, 2019 at 11:06:17AM -0400, Jason Merrill wrote:

On 8/6/19 3:20 PM, Marek Polacek wrote:

On Mon, Aug 05, 2019 at 03:54:19PM -0400, Jason Merrill wrote:

On 7/31/19 3:26 PM, Marek Polacek wrote:

One of the features of constexpr is that it doesn't allow UB; and such UB must
be detected at compile-time.  So running your code in a context that requires
a constant expression should ensure that the code in question is free of UB.
In effect, constexpr can serve as a sanitizer.  E.g. this article describes in
in more detail:


[dcl.type.cv]p4 says "Any attempt to modify a const object during its lifetime
results in undefined behavior." However, as the article above points out, we
aren't detecting that case in constexpr evaluation.

This patch fixes that.  It's not that easy, though, because we have to keep in
mind [class.ctor]p5:
"A constructor can be invoked for a const, volatile or const volatile object.
const and volatile semantics are not applied on an object under construction.
They come into effect when the constructor for the most derived object ends."

I handled this by keeping a hash set which tracks objects under construction.
I considered other options, such as going up call_stack, but that wouldn't
work with trivial constructor/op=.  It was also interesting to find out that
the definition of TREE_HAS_CONSTRUCTOR says "When appearing in a FIELD_DECL,
it means that this field has been duly initialized in its constructor" though
nowhere in the codebase do we set TREE_HAS_CONSTRUCTOR on a FIELD_DECL as far
as I can see.  Unfortunately, using this bit proved useless for my needs here.



Also, be mindful of mutable subobjects.

Does this approach look like an appropriate strategy for tracking objects'
construction?


For scalar objects, we should be able to rely on INIT_EXPR vs. MODIFY_EXPR
to distinguish between initialization and modification; for class objects, I


This is already true: only class object go into the hash set.


wonder about setting a flag on the CONSTRUCTOR after initialization is
complete to indicate that the value is now constant.


But here we're not dealing with CONSTRUCTORs in the gcc sense (i.e. exprs with
TREE_CODE == CONSTRUCTOR).  We have a CALL_EXPR like Y::Y ((struct Y *) ),
which initializes the object "y".  Setting a flag on the CALL_EXPR or its 
underlying
function decl wouldn't help.

Am I missing something?


I was thinking that where in your current patch you call
remove_object_under_construction, we could instead mark the object's value
CONSTRUCTOR as immutable.


Ah, what you meant was to look at DECL_INITIAL of the object we're
constructing, which could be a CONSTRUCTOR.  Unfortunately, this
DECL_INITIAL is null (in all the new tests when doing
remove_object_under_construction), so there's nothing to mark as TREE_READONLY 
:/.


There's a value in ctx->values, isn't there?


Doesn't seem to be the case for e.g.

struct A {
 int n;
 constexpr A() : n(1) { n = 2; }
};

struct B {
 const A a;
 constexpr B(bool b) {
   if (b)
 const_cast(a).n = 3; // { dg-error "modifying a const object" }
   }
};

constexpr B b(false);
static_assert(b.a.n == 2, "");

Here we're constructing "b", its ctx->values->get(new_obj) is initially
"{}".  In the middle of constructing "b", we construct "b.a", but that
has nothing in ctx->values.


Right, subobjects aren't in ctx->values.  In cxx_eval_call_expression we
have

if (DECL_CONSTRUCTOR_P (fun))
  /* This can be null for a subobject constructor call, in

 which case what we care about is the initialization

 side-effects rather than the value.  We could get at the

 value by evaluating *this, but we don't bother; there's

 no need to put such a call in the hash table.  */
  result = lval ? ctx->object : ctx->ctor;

Your patch already finds *this (b.a) and puts it in new_obj; if it's const
we can evaluate it to get the CONSTRUCTOR to set TREE_READONLY on.


Ah, got it!  This patch uses setting TREE_READONLY to achieve what I was after.
I also needed to set TREE_READONLY in cxx_eval_constant_expression/DECL_EXPR.
The additional evaluating will only happen for const-qual objects so I hope not
very often.

Any further comments?  Thanks,

@@ -1910,6 +1958,29 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree 
t,

+ /* At this point, the object's constructor will have run, so
+the object is 

Re: [PATCH, sanitizer] Wrap rethrow_primary_exception (PR 87880).

[Iain Sandoe]

> On 16 Jun 2019, at 19:58, Jakub Jelinek  wrote:
> 
> On Sun, Jun 16, 2019 at 07:54:42PM +0100, Iain Sandoe wrote:

>> Actually, because the way in which interposing works for Darwin is 
>> different, the only
>> symbol change in the library on Darwin is removing an "undefined dynamic 
>> lookup".
>> So, for back-ports, I can could up with some Darwin-specific Makefike change 
>> that
>> only adds the ASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION=0 for Darwin.
>> 
>> So - OK for trunk with a bumped soname?
> 
> Yes.
> 
>> (and a TODO to figure a Darwin-only backport)
> 
> Yeah.

This turned out to be easier than I’d expected, since there was already a 
Darwin-specific
guard in the Makefile.

Tested on x86_64-darwin{11,13,14,16,17,18}, x86_64,powerpc64-linux-gnu
(that the symbol is not removed for the Linux cases).

Applied to the 9 branch for 9.3
Iain

libsanitizer/

2019-08-18  Iain Sandoe  

Backport from mainline
2019-06-18  Iain Sandoe  

PR libsanitizer/87880
* asan/asan_interceptors.h:
(ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION): New.
* asan/Makefile.am (DEFS): Add (for Darwin only)
ASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION, defined to 0.
* asan/Makefile.in: Regenerated.


diff --git a/libsanitizer/asan/Makefile.am b/libsanitizer/asan/Makefile.am
index 867240d244..6efbc1df7f 100644
--- a/libsanitizer/asan/Makefile.am
+++ b/libsanitizer/asan/Makefile.am
@@ -5,7 +5,7 @@ gcc_version := $(shell @get_gcc_base_ver@ 
$(top_srcdir)/../gcc/BASE-VER)
 
 DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS -DASAN_HAS_EXCEPTIONS=1 -DASAN_NEEDS_SEGV=1 
-DCAN_SANITIZE_UB=0
 if USING_MAC_INTERPOSE
-DEFS += -DMAC_INTERPOSE_FUNCTIONS -DMISSING_BLOCKS_SUPPORT
+DEFS += -DMAC_INTERPOSE_FUNCTIONS -DMISSING_BLOCKS_SUPPORT 
-DASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION=0
 endif
 AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic 
-Wno-long-long  -fPIC -fno-builtin -fno-exceptions -fno-rtti 
-fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros 
-fno-ipa-icf
 AM_CXXFLAGS += $(LIBSTDCXX_RAW_CXX_CXXFLAGS)

diff --git a/libsanitizer/asan/asan_interceptors.h 
b/libsanitizer/asan/asan_interceptors.h
index b599ebb0ba..beb1dc9532 100644
--- a/libsanitizer/asan/asan_interceptors.h
+++ b/libsanitizer/asan/asan_interceptors.h
@@ -79,7 +79,12 @@ void InitializePlatformInterceptors();
 #if ASAN_HAS_EXCEPTIONS && !SANITIZER_WINDOWS && !SANITIZER_SOLARIS && \
 !SANITIZER_NETBSD
 # define ASAN_INTERCEPT___CXA_THROW 1
-# define ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION 1
+# if ! defined(ASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION) \
+ || ASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION
+#   define ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION 1
+# else
+#   define ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION 0
+# endif
 # if defined(_GLIBCXX_SJLJ_EXCEPTIONS) || (SANITIZER_IOS && defined(__arm__))
 #  define ASAN_INTERCEPT__UNWIND_SJLJ_RAISEEXCEPTION 1
 # else

[Darwin, fixincludes, committed] Fix PR83531

[Iain Sandoe]

There is no reasonable chance that the SDKs in question will be re-
issued, so the only viable solution is a fixincludes.

tested on x86_64-darwin, x86_64-linux-gnu, powerpc64-linux-gnu
(fixincludes tests pass on linux)
applied to mainline,
Iain

2019-08-18  C.G. Dogan 
Iain Sandoe  

PR target/83531
* inclhack.def (darwin_api_availability): New, strip leading
underscores from API_ defines.
* fixincl.x: Regenerate.
* tests/base/os/availability.h: New file.

diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index 861532c2a1..3c6b48d26e 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -194,6 +194,33 @@ fix = {
_EndOfHeader_;
 };
 
+/*
+ *  SDKs for 10.13 and 10.14 omit the definitions for API_AVAILABLE where
+ *  __attribute__((availability)) is not supported.
+ */
+fix = {
+hackname  = darwin_api_availability;
+mach  = "*-*-darwin*";
+files = os/availability.h;
+bypass= "__IPHONE_OS_VERSION_MIN_REQUIRED";
+select=
+" *#define __API_AVAILABLE.*\n"
+" *#define __API_DEPRECATED.*\n"
+" *#define __API_DEPRECATED_WITH_REPLACEMENT.*\n"
+" *#define __API_UNAVAILABLE.*\n";
+c_fix = format;
+c_fix_arg =
+"#define API_AVAILABLE(...)\n"
+"#define API_DEPRECATED(...)\n"
+"#define API_DEPRECATED_WITH_REPLACEMENT(...)\n"
+"#define API_UNAVAILABLE(...)\n";
+test_text =
+"#define __API_AVAILABLE(...)\n"
+"#define __API_DEPRECATED(...)\n"
+"#define __API_DEPRECATED_WITH_REPLACEMENT(...)\n"
+"#define __API_UNAVAILABLE(...)\n";
+};
+
 /*
  *  This fixes __FD_ZERO bug for linux 2.x.y (x <= 2 && y <= some n)
  */
diff --git a/fixincludes/tests/base/os/availability.h 
b/fixincludes/tests/base/os/availability.h
new file mode 100644
index 00..e8696b14ac
--- /dev/null
+++ b/fixincludes/tests/base/os/availability.h
@@ -0,0 +1,18 @@
+/*  DO NOT EDIT THIS FILE.
+
+It has been auto-edited by fixincludes from:
+
+   "fixinc/tests/inc/os/availability.h"
+
+This had to be done to correct non-standard usages in the
+original, manufacturer supplied header file.  */
+
+
+
+#if defined( DARWIN_API_AVAILABILITY_CHECK )
+#define API_AVAILABLE(...)
+#define API_DEPRECATED(...)
+#define API_DEPRECATED_WITH_REPLACEMENT(...)
+#define API_UNAVAILABLE(...)
+
+#endif  /* DARWIN_API_AVAILABILITY_CHECK */

[Darwin, PPC, committed] Fix fail of cpp/assert4.c

[Iain Sandoe]

Despite that the cpp assert facility is deprecated, we do have a test
for it.

This test needs the cpu and machine asserts to be implemented
which hadn't been done for PPC Darwin.  Fixed thus.

tested on powerpc-darwin9,
applied to mainline,
Iain

gcc/

2019-08-18  Iain Sandoe  

* config/rs6000/darwin.h (TARGET_OS_CPP_BUILTINS): Add asserts
for cpu and machine.  Factor 64/32b builtins.

diff --git a/gcc/config/rs6000/darwin.h b/gcc/config/rs6000/darwin.h
index 150dc4f4cd..a626325c2d 100644
--- a/gcc/config/rs6000/darwin.h
+++ b/gcc/config/rs6000/darwin.h
@@ -52,11 +52,23 @@
 #define TARGET_OS_CPP_BUILTINS()   \
   do   \
 {  \
-  if (!TARGET_64BIT) builtin_define ("__ppc__");   \
-  if (!TARGET_64BIT) builtin_define ("__PPC__");   \
-  if (TARGET_64BIT) builtin_define ("__ppc64__");  \
-  if (TARGET_64BIT) builtin_define ("__PPC64__");  \
   builtin_define ("__POWERPC__");  \
+  builtin_define ("__PPC__");  \
+  if (TARGET_64BIT)\
+   {   \
+ builtin_define ("__ppc64__"); \
+ builtin_define ("__PPC64__"); \
+ builtin_define ("__powerpc64__"); \
+ builtin_assert ("cpu=powerpc64"); \
+ builtin_assert ("machine=powerpc64"); \
+   }   \
+  else \
+   {   \
+ builtin_define ("__ppc__");   \
+ builtin_define_std ("PPC");   \
+ builtin_assert ("cpu=powerpc");   \
+ builtin_assert ("machine=powerpc");   \
+   }   \
   builtin_define ("__NATURAL_ALIGNMENT__");\
   darwin_cpp_builtins (pfile); \
 }  \

Re: [PATCH][DOC] Define email limit for gcc-patches mailing list.

[Gerald Pfeifer]

On Tue, 30 Apr 2019, Martin Liška wrote:
>>> This would fix bug 89770 if/when you commit it, btw:
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89770
> Thanks for useful comments, I've included all of them (except kB change).
> Feel free to see current version at https://gcc.gnu.org/lists.html

Thank you!  This whole thing caused a bit of a deja vu for me since
I already had fixed PR89770 earlier on.  Turns out it got stuck in a 
local tree, so you had to replicate that work. :-o

Gerald

[PATCH,i386] Don't use errno when freestanding (was: config/i386/xmmintrin.h: Only #include if __STDC_HOSTED__)

[Gerald Pfeifer]

On Sat, 9 Dec 2017, Jakub Jelinek wrote:
>> Some users on FreeBSD noticed a problem when trying to use GCC to
>> build things in a standalone environment that manifests itself as
>> 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd11.0/6.3.0/include/xmmintrin.h:34 
>> from
>> /usr/local/lib/gcc/x86_64-unknown-freebsd11.0/6.3.0/include/immintrin.h:29 
>> from
>> /workspace/src/sys/crypto/aesni/intel_sha256.c:62 
>> In function '_mm_malloc':
>> /usr/local/lib/gcc/x86_64-unknown-freebsd11.0/6.3.0/include/mm_malloc.h:39: 
>> error: 'errno' undeclared (first use in this function)
>> 
>> It turns out the clang version of xmmintrin.h does not include mm_malloc.h 
>> if !__STDC_HOSTED__ whereas ours unconditionally does so.
> 
> Wouldn't it be better to just ifdef out parts of gmm_malloc.h (pmm_malloc.h
> should be ok)?

Very good point, Jakub.  Thank you!  

Somehow I thought I had submitted this updated patch, but apparently 
not so. :-(  (This has been on my autotester for ages.)

Okay?  And if so, okay for GCC 9 after a while?

Gerald


2019-08-18  Gerald Pfeifer  
 
* config/i386/gmm_malloc.h: Only include errno.h and use errno
if __STDC_HOSTED__.
 
Index: config/i386/gmm_malloc.h
===
--- config/i386/gmm_malloc.h(revision 274618)
+++ config/i386/gmm_malloc.h(working copy)
@@ -25,7 +25,9 @@
 #define _MM_MALLOC_H_INCLUDED
 
 #include 
+#if __STDC_HOSTED__
 #include 
+#endif
 
 static __inline__ void * 
 _mm_malloc (size_t __size, size_t __align)
@@ -36,7 +38,9 @@ _mm_malloc (size_t __size, size_t __align)
   /* Error if align is not a power of two.  */
   if (__align & (__align - 1))
 {
+#if __STDC_HOSTED__
   errno = EINVAL;
+#endif
   return ((void *) 0);
 }
 

Re: C++ PATCH for c++/91264 - detect modifying const objects in constexpr

[Marek Polacek]

On Fri, Aug 16, 2019 at 05:40:39PM -0700, Jason Merrill wrote:
> On 8/16/19 5:11 AM, Marek Polacek wrote:
> > On Thu, Aug 15, 2019 at 08:21:25PM -0400, Jason Merrill wrote:
> > > On 8/15/19 5:34 PM, Marek Polacek wrote:
> > > > On Wed, Aug 14, 2019 at 02:50:13PM -0400, Jason Merrill wrote:
> > > > > On Thu, Aug 8, 2019 at 3:25 PM Marek Polacek  
> > > > > wrote:
> > > > > > 
> > > > > > On Thu, Aug 08, 2019 at 11:06:17AM -0400, Jason Merrill wrote:
> > > > > > > On 8/6/19 3:20 PM, Marek Polacek wrote:
> > > > > > > > On Mon, Aug 05, 2019 at 03:54:19PM -0400, Jason Merrill wrote:
> > > > > > > > > On 7/31/19 3:26 PM, Marek Polacek wrote:
> > > > > > > > > > One of the features of constexpr is that it doesn't allow 
> > > > > > > > > > UB; and such UB must
> > > > > > > > > > be detected at compile-time.  So running your code in a 
> > > > > > > > > > context that requires
> > > > > > > > > > a constant expression should ensure that the code in 
> > > > > > > > > > question is free of UB.
> > > > > > > > > > In effect, constexpr can serve as a sanitizer.  E.g. this 
> > > > > > > > > > article describes in
> > > > > > > > > > in more detail:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > [dcl.type.cv]p4 says "Any attempt to modify a const object 
> > > > > > > > > > during its lifetime
> > > > > > > > > > results in undefined behavior." However, as the article 
> > > > > > > > > > above points out, we
> > > > > > > > > > aren't detecting that case in constexpr evaluation.
> > > > > > > > > > 
> > > > > > > > > > This patch fixes that.  It's not that easy, though, because 
> > > > > > > > > > we have to keep in
> > > > > > > > > > mind [class.ctor]p5:
> > > > > > > > > > "A constructor can be invoked for a const, volatile or 
> > > > > > > > > > const volatile object.
> > > > > > > > > > const and volatile semantics are not applied on an object 
> > > > > > > > > > under construction.
> > > > > > > > > > They come into effect when the constructor for the most 
> > > > > > > > > > derived object ends."
> > > > > > > > > > 
> > > > > > > > > > I handled this by keeping a hash set which tracks objects 
> > > > > > > > > > under construction.
> > > > > > > > > > I considered other options, such as going up call_stack, 
> > > > > > > > > > but that wouldn't
> > > > > > > > > > work with trivial constructor/op=.  It was also interesting 
> > > > > > > > > > to find out that
> > > > > > > > > > the definition of TREE_HAS_CONSTRUCTOR says "When appearing 
> > > > > > > > > > in a FIELD_DECL,
> > > > > > > > > > it means that this field has been duly initialized in its 
> > > > > > > > > > constructor" though
> > > > > > > > > > nowhere in the codebase do we set TREE_HAS_CONSTRUCTOR on a 
> > > > > > > > > > FIELD_DECL as far
> > > > > > > > > > as I can see.  Unfortunately, using this bit proved useless 
> > > > > > > > > > for my needs here.
> > > > > > > > > 
> > > > > > > > > > Also, be mindful of mutable subobjects.
> > > > > > > > > > 
> > > > > > > > > > Does this approach look like an appropriate strategy for 
> > > > > > > > > > tracking objects'
> > > > > > > > > > construction?
> > > > > > > > > 
> > > > > > > > > For scalar objects, we should be able to rely on INIT_EXPR 
> > > > > > > > > vs. MODIFY_EXPR
> > > > > > > > > to distinguish between initialization and modification; for 
> > > > > > > > > class objects, I
> > > > > > > > 
> > > > > > > > This is already true: only class object go into the hash set.
> > > > > > > > 
> > > > > > > > > wonder about setting a flag on the CONSTRUCTOR after 
> > > > > > > > > initialization is
> > > > > > > > > complete to indicate that the value is now constant.
> > > > > > > > 
> > > > > > > > But here we're not dealing with CONSTRUCTORs in the gcc sense 
> > > > > > > > (i.e. exprs with
> > > > > > > > TREE_CODE == CONSTRUCTOR).  We have a CALL_EXPR like Y::Y 
> > > > > > > > ((struct Y *) ),
> > > > > > > > which initializes the object "y".  Setting a flag on the 
> > > > > > > > CALL_EXPR or its underlying
> > > > > > > > function decl wouldn't help.
> > > > > > > > 
> > > > > > > > Am I missing something?
> > > > > > > 
> > > > > > > I was thinking that where in your current patch you call
> > > > > > > remove_object_under_construction, we could instead mark the 
> > > > > > > object's value
> > > > > > > CONSTRUCTOR as immutable.
> > > > > > 
> > > > > > Ah, what you meant was to look at DECL_INITIAL of the object we're
> > > > > > constructing, which could be a CONSTRUCTOR.  Unfortunately, this
> > > > > > DECL_INITIAL is null (in all the new tests when doing
> > > > > > remove_object_under_construction), so there's nothing to mark as 
> > > > > > TREE_READONLY :/.
> > > > > 
> > > > > There's a value in ctx->values, isn't there?
> > > > 
> > > > Doesn't seem to be the case for e.g.
> > > > 
> > > > struct A {
> > > > int n;
> > 

[doc] install.texi and bfin "end of life"

[Gerald Pfeifer]

https://blackfin.uclinux.org redirects to a page on ez.analog.com
that states "End of Life for Blackfin Linux" and has a link to
sourceforge.net that at least offers some remaining bits.

Jie, can you please have a look? 

This, or something similar, probably should be backported to all
active release branches.

Committed for now.

Gerald
 
2019-08-18  Gerald Pfeifer  

* doc/install.texi (Specific, bfin): blackfin.uclinux.org is
gone, point to sourceforge.net.

Index: doc/install.texi
===
--- doc/install.texi(revision 274618)
+++ doc/install.texi(working copy)
@@ -3584,7 +3584,7 @@ See ``Blackfin Options'' in the main manual
 @end ifhtml
 
 More information, and a version of binutils with support for this processor,
-is available at @uref{https://blackfin.uclinux.org}
+are available at @uref{https://sourceforge.net/projects/adi-toolchain/}.
 
 @html
 

[wwwdocs PATCH] for Re: autovectorization in gcc

[Gerald Pfeifer]

On Thu, 10 Jan 2019, Jonathan Wakely wrote:
>> [ https://gcc.gnu.org/projects/tree-ssa/vectorization.html ]
> I'm not disputing that there could be better documentation, but that
> page is not the place to find it. That page should probably get a
> notice added saying that the project is complete and that the page is
> now only of historical interest.

Like this? ;-)

Committed.

Gerald

Index: projects/tree-ssa/vectorization.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/tree-ssa/vectorization.html,v
retrieving revision 1.42
diff -u -r1.42 vectorization.html
--- projects/tree-ssa/vectorization.html30 Sep 2018 14:38:57 -  
1.42
+++ projects/tree-ssa/vectorization.html18 Aug 2019 10:55:46 -
@@ -2,15 +2,17 @@
 
 
 
-Auto-vectorization in GCC
+Auto-vectorization in GCC
 https://gcc.gnu.org/gcc.css; />
 
 
 
 Auto-vectorization in GCC
 
-The goal of this project is to develop a loop and basic block 
vectorizer in
-GCC, based on the tree-ssa framework.
+The goal of this project was to develop a loop and basic block
+vectorizer in GCC, based on the tree-ssa framework.
+It has been completed and the functionality has been part of GCC
+for years.
 
 Table of Contents

[wwwdocs] Reverting your own patches (was: [PATCH] Revert 2 ::get to ::get_create for IPA summaries (PR ipa/86279))

[Gerald Pfeifer]

On Fri, 29 Jun 2018, Jeff Law wrote:
> ISTM that if you're reverting something recent of your own that's
> causing failures you ought to be able to revert without waiting.

Indeed.  And https://gcc.gnu.org/svnwrite.html#all documents this
in the third items.

(Well, that direct link only works after the patch below that I
just committed; the text has been there since October 2005. ;-)

Gerald


Add an id of "all" to the "Free for all" subsection.

Index: svnwrite.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/svnwrite.html,v
retrieving revision 1.44
diff -u -r1.44 svnwrite.html
--- svnwrite.html   5 Jul 2019 12:42:51 -   1.44
+++ svnwrite.html   18 Aug 2019 10:33:04 -
@@ -140,7 +140,7 @@
 SVN or the https://gcc.gnu.org/ml/gcc-cvs/;>gcc-cvs
 list.
 
-Free for all
+Free for all
 
 The following changes can be made by everyone with write access:
 

[wwwdocs] bugs/index.html - remove a last reference to Java/libgcj

[Gerald Pfeifer]

Committed.

Gerald

Index: bugs/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/index.html,v
retrieving revision 1.130
diff -u -r1.130 index.html
--- bugs/index.html 16 Aug 2019 20:59:00 -  1.130
+++ bugs/index.html 18 Aug 2019 10:06:52 -
@@ -667,9 +667,8 @@
 modify it with each major release.  If you change your compiler to a
 different major release you must recompile all libraries that
 contain C++ code.  If you fail to do so you risk getting linker
-errors or malfunctioning programs.  Some of our Java support libraries
-also contain C++ code, so you might want to recompile all libraries to
-be safe.  It should not be necessary to recompile if you have changed
+errors or malfunctioning programs.
+It should not be necessary to recompile if you have changed
 to a bug-fix release of the same version of the compiler; bug-fix
 releases are careful to avoid ABI changes. See also the
 https://gcc.gnu.org/onlinedocs/gcc/Compatibility.html;>compatibility

Re: Update x86-tune-costs.h for znver2

[Gerald Pfeifer]

On Tue, 30 Jul 2019, Jan Hubicka wrote:
>> Thanks - can you please update changes.html for it in the 9.2 section?
> There seems to be no GCC 9.2 section yet.

I see one now. 

On Tue, 30 Jul 2019, Richard Biener wrote:
> Yes.  Looks good to me btw.

Same here.  (I would have taken Richard's note as approval, though
as maintainer over that area you don't even need any.)

For the benefit of the doubt, though: okay, thanks. :-)

Gerald