Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping these patches:

PR84146 fix -fcompare-debug issues with -mcet -fcf-protection=full
  http://gcc.gnu.org/ml/gcc-patches/2018-02/msg00390.html

PR83708 __VA_OPT__ assorted fixes
  http://gcc.gnu.org/ml/gcc-patches/2018-01/msg00727.html

Thanks

Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 2 patches:

http://gcc.gnu.org/ml/gcc-patches/2018-02/msg01340.html
  - PR target/84524 avx512* wrong-code bug

http://gcc.gnu.org/ml/gcc-patches/2018-02/msg01337.html
  - fix c-c++-common/Warray-bounds-2.c testcase for -fpic

Thanks

Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping following patch:

http://gcc.gnu.org/ml/gcc-patches/2018-02/msg01461.html
  PR84564 - fix ICE with -mforce-indirect-call

Thanks

Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the

http://gcc.gnu.org/ml/gcc-patches/2018-03/msg00238.html
  - PR84704 - ICE on a[({ 0; })] op= something with -g

patch.  Thanks.

Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the
  http://gcc.gnu.org/ml/gcc-patches/2018-04/msg00123.html
  P1 PR85177 vinsert[if]{32x4,64x2} pattern fix
patch.

Thanks

Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the

  http://gcc.gnu.org/ml/gcc-patches/2018-04/msg00414.html
  PR85281 - assorted -masm=intel fixes

patch.  Thanks.

Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping following patches for stage1:

  - PR78420 __builtin_early_constant_p 
http://gcc.gnu.org/ml/gcc-patches/2018-03/msg00355.html

  - use --push-state --as-needed and --pop-state around -lgcc_s
http://gcc.gnu.org/ml/gcc-patches/2018-04/msg00567.html

  - PR85466 next{after,toward}{,f,l} constant folding
http://gcc.gnu.org/ml/gcc-patches/2018-04/msg01027.html

  - PR85480 improve AVX512 128-bit insertion into 512-bit zero vector
http://gcc.gnu.org/ml/gcc-patches/2018-04/msg01058.html

Thanks

Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the:

  http://gcc.gnu.org/ml/gcc-patches/2017-10/msg01895.html
  PR debug/82718
  Fix DWARF5 .debug_loclist handling with hot/cold partitioning

patch.  Thanks

Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the following patches:

  http://gcc.gnu.org/ml/gcc-patches/2017-10/msg01895.html
  PR debug/82718
  Fix DWARF5 .debug_loclist handling with hot/cold partitioning

  http://gcc.gnu.org/ml/gcc-patches/2017-11/msg00851.html
  C++2A P0428R2 - familiar template syntax for generic lambdas

  http://gcc.gnu.org/ml/gcc-patches/2017-11/msg01026.html
  C++2A P0329R4: Designated Initialization

Thanks

Jakub

Patch ping #2

[Eric Botcazou]

Not as many as Jakub, but still. :-)


Fix annoying gcov filename handling (gcov.c, 2 lines):
  http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01380.html

Introduce -Wstack-usage:
  http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01992.html

Extend TYPE_DECL_IS_STUB trick (dwarf2out.c, 1 line):
  http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00683.html

Emit DW_AT_artificial for types:
  http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00700.html

Fix PR lto/48492 (bis) (dwarf2out.c, 1 line):
  http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01461.html

Thanks in advance.


-- 
Eric Botcazou

Re: Patch ping

[Richard Guenther]

On Mon, 23 May 2011, Jakub Jelinek wrote:

> Hi!
> 
> - http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00895.html
>   P1 PR48973 4.6/4.7 fix for expansion of comparisons with signed
>   1 bit precision type

Ok.

I'll leave the rest to others.

Thanks,
Richard.

Re: Patch ping

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/23/11 01:48, Jakub Jelinek wrote:

> 
> - http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00403.html
>   debug info improvement for unused parameters passed in memory
OK.


> 
> - http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01454.html
>   PR49032 fix dbxout so that -gstabs doesn't reference optimized
>   away static vars
OK.

Jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJN2op6AAoJEBRtltQi2kC7aCAH/3KgaTS9z8SLio0jH+5wzIzt
Ctjt7xsHKUMoY+fw4EZG/N9grRCYHnSSIA+aqKD4lPAj61sVM5z7LuOV7UOicwjv
BEw7UCblFUh9bduttxZ0PmhHOCk5NXjYCbvVh7SUC62H//eg8KIzLnvhuPe5pg+v
Z2u2huj+oN2dmpj6C9oR6XZGqxDjehU6+QMrWQcJLESq1M/eYYdzPZpiuqcHyhBr
6CYGJPJIgMyiN4VaFFsK+5t5+n2SAWESbb6VT/yCl5HsKMpTvhtPqy29LEOUZYYq
l+ulwSVDD+yQCsEY3or3nm07O2uYLkr6dZyoby4AfBBeVJX0Sp7lPoXons64doo=
=NTdi
-END PGP SIGNATURE-

Re: Patch ping

[Diego Novillo]

On Mon, Mar 14, 2011 at 16:19, Jakub Jelinek  wrote:
> Hi!
>
> http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01749.html
>  - PR middle-end/47917, snprintf folding

OK.


Diego.

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 3 patches from a week ago:

http://gcc.gnu.org/ml/gcc-patches/2016-08/msg01995.html
  - PR77375 - wrong-code with mutable members in base classes

http://gcc.gnu.org/ml/gcc-patches/2016-08/msg01998.html
  - PR77338 - fix constexpr ICE on PARM_DECL with incomplete type

http://gcc.gnu.org/ml/gcc-patches/2016-08/msg02002.html
  - PR77379 - fix testcase mangling regexps for 32-bit targets

Jakub

Re: Patch ping

[Jeff Law]

On 03/03/2016 07:35 AM, Jakub Jelinek wrote:

Hi!

I'd like to ping fix for P1 PR69947:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01743.html
So essentially this is just marking more things so that we don't prune 
them away, right?


It's similar conceptually to one of Pierre-Marie's patches where he 
removed the switch and recursed anytime the operand's val_class matched 
dw_val_class_die_ref and was !external.  Yours just explicitly adds the 
new DW_OP_ things to the switch and has a slightly looser check 
(dropping the !external part of the check).


I could argue for either approach.  Yours AFAICT is safer in that it 
won't recurse on unexpected DW_OP_ things.  Of course, it may 
require more long term maintenance to keep the list of things to recurse 
on up-to-date.


Either approach is OK with me, given you're a lot more familiar with our 
dwarf writer than I, I'll go with your judgment on which is the best 
approach to address the problem.


jeff

Re: Patch ping

[Jakub Jelinek]

On Fri, Mar 04, 2016 at 12:10:26AM -0700, Jeff Law wrote:
> On 03/03/2016 07:35 AM, Jakub Jelinek wrote:
> >Hi!
> >
> >I'd like to ping fix for P1 PR69947:
> >https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01743.html
> So essentially this is just marking more things so that we don't prune them
> away, right?
> 
> It's similar conceptually to one of Pierre-Marie's patches where he removed
> the switch and recursed anytime the operand's val_class matched
> dw_val_class_die_ref and was !external.  Yours just explicitly adds the new
> DW_OP_ things to the switch and has a slightly looser check (dropping the
> !external part of the check).

The !external part is IMHO not needed, as we only set external for
attributes, not for operands of DWARF expression opcodes.
And, while checking both operands for dw_val_class_die_ref is possible, it
is not enough, it doesn't cover the DW_OP_GNU_entry_value case where it is
a val_loc, and that case really depends on the context, other val_locs
shouldn't be traversed.  So, I think it is better to list the opcodes
explicitly, as that gives the needed context to what the arguments are,
perhaps at some point we'll refer to DIEs that we want to do something
different for.
When adding new DW_OP_* values, one has to change dozens of other places
anyway, so one further one doesn't matter, one has to search for all the
spots anyway.

Jakub

Re: Patch ping

[Jeff Law]

On 03/04/2016 12:30 AM, Jakub Jelinek wrote:

Hi!

I'd like to ping a texinfo fix for __builtin_alloca*:
http://gcc.gnu.org/ml/gcc-patches/2016-02/msg01842.html

OK.

jeff

Re: Patch ping

[Jason Merrill]

OK.

Jason

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the PR c++/66808, PR c++/69000
http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html
patch, fixing ICE with GNU __thread vars in templates.

Thanks

Jakub

Re: Patch ping

[Richard Biener]

On Wed, 10 Feb 2016, Jakub Jelinek wrote:

> Hi!
> 
> I'd like to ping a P1 patch:
> PR ipa/69241, PR c++/69649
>   https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00192.html

Ok.

Thanks,
Richard.

>   Jakub
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: Patch ping

[Bernd Schmidt]

On 09/14/2016 11:47 PM, Jakub Jelinek wrote:



http://gcc.gnu.org/ml/gcc-patches/2016-09/msg00088.html
  - PR77425 - fix UB in sd_iterator_cond


Ok.


Bernd

Re: Patch ping

[Bernd Schmidt]

On 09/28/2016 09:24 PM, Jakub Jelinek wrote:

I'd like to ping the

http://gcc.gnu.org/ml/gcc-patches/2016-09/msg01436.html

patch, containing various fixes for gimple-ssa-sprintf.c.
If the 0 < var to var > 0 changes are deemed too controversial, I can
separate them from the other changes.


I'd like to see them separated because they are obvious and good, so 
please install them first.



Bernd

Re: Patch ping

[Jakub Jelinek]

On Wed, Sep 28, 2016 at 09:28:14PM +0200, Bernd Schmidt wrote:
> On 09/28/2016 09:24 PM, Jakub Jelinek wrote:
> >I'd like to ping the
> >
> >http://gcc.gnu.org/ml/gcc-patches/2016-09/msg01436.html
> >
> >patch, containing various fixes for gimple-ssa-sprintf.c.
> >If the 0 < var to var > 0 changes are deemed too controversial, I can
> >separate them from the other changes.
> 
> I'd like to see them separated because they are obvious and good, so please
> install them first.

Ok, so here is the separated patch I've installed:

2016-09-28  Jakub Jelinek  

* gimple-ssa-sprintf.c: Fix comment formatting.
(format_integer): Use is_gimple_assign.
(pass_sprintf_length::handle_gimple_call): Use gimple_call_builtin_p
and gimple_call_fndecl.  Reorder case BUILT_IN_SPRINTF_CHK.  Fix up
BUILT_IN_SNPRINTF_CHK comment.  Replace "to to" with "to" in comment.
(pass_sprintf_length::execute): Use is_gimple_call.

--- gcc/gimple-ssa-sprintf.c.jj 2016-09-21 08:54:15.0 +0200
+++ gcc/gimple-ssa-sprintf.c2016-09-21 15:09:02.209261013 +0200
@@ -37,7 +37,7 @@ along with GCC; see the file COPYING3.
 
The pass handles all forms standard sprintf format directives,
including character, integer, floating point, pointer, and strings,
-   with  the standard C flags, widths, and precisions.  For integers
+   with the standard C flags, widths, and precisions.  For integers
and strings it computes the length of output itself.  For floating
point it uses MPFR to fornmat known constants with up and down
rounding and uses the resulting range of output lengths.  For
@@ -464,7 +464,7 @@ struct conversion_spec
 
   /* Format conversion function that given a conversion specification
  and an argument returns the formatting result.  */
-  fmtresult  (*fmtfunc) (const conversion_spec &, tree);
+  fmtresult (*fmtfunc) (const conversion_spec &, tree);
 
   /* Return True when a the format flag CHR has been used.  */
   bool get_flag (char chr) const
@@ -1032,10 +1032,10 @@ format_integer (const conversion_spec &s
{
  /* The argument here may be the result of promoting the actual
 argument to int.  Try to determine the type of the actual
-argument before promotion and  narrow down its range that
+argument before promotion and narrow down its range that
 way.  */
  gimple *def = SSA_NAME_DEF_STMT (arg);
- if (gimple_code (def) == GIMPLE_ASSIGN)
+ if (is_gimple_assign (def))
{
  tree_code code = gimple_assign_rhs_code (def);
  if (code == NOP_EXPR)
@@ -2449,18 +2449,10 @@ pass_sprintf_length::handle_gimple_call
   call_info info = call_info ();
 
   info.callstmt = gsi_stmt (gsi);
-  info.func = gimple_call_fn (info.callstmt);
-  if (!info.func)
-return;
-
-  if (TREE_CODE (info.func) == ADDR_EXPR)
-info.func = TREE_OPERAND (info.func, 0);
-
-  if (TREE_CODE (info.func) != FUNCTION_DECL
-  || !DECL_BUILT_IN(info.func)
-  || DECL_BUILT_IN_CLASS (info.func) != BUILT_IN_NORMAL)
+  if (!gimple_call_builtin_p (info.callstmt, BUILT_IN_NORMAL))
 return;
 
+  info.func = gimple_call_fndecl (info.callstmt);
   info.fncode = DECL_FUNCTION_CODE (info.func);
 
   /* The size of the destination as in snprintf(dest, size, ...).  */
@@ -2487,6 +2479,14 @@ pass_sprintf_length::handle_gimple_call
   info.argidx = 2;
   break;
 
+case BUILT_IN_SPRINTF_CHK:
+  // Signature:
+  //   __builtin___sprintf_chk (dst, ost, objsize, format, ...)
+  idx_objsize = 2;
+  idx_format = 3;
+  info.argidx = 4;
+  break;
+
 case BUILT_IN_SNPRINTF:
   // Signature:
   //   __builtin_snprintf (dst, size, format, ...)
@@ -2498,7 +2498,7 @@ pass_sprintf_length::handle_gimple_call
 
 case BUILT_IN_SNPRINTF_CHK:
   // Signature:
-  //   __builtin___sprintf_chk (dst, size, ost, objsize, format, ...)
+  //   __builtin___snprintf_chk (dst, size, ost, objsize, format, ...)
   idx_dstsize = 1;
   idx_objsize = 3;
   idx_format = 4;
@@ -2506,14 +2506,6 @@ pass_sprintf_length::handle_gimple_call
   info.bounded = true;
   break;
 
-case BUILT_IN_SPRINTF_CHK:
-  // Signature:
-  //   __builtin___sprintf_chk (dst, ost, objsize, format, ...)
-  idx_objsize = 2;
-  idx_format = 3;
-  info.argidx = 4;
-  break;
-
 case BUILT_IN_VSNPRINTF:
   // Signature:
   //   __builtin_vsprintf (dst, size, format, va)
@@ -2556,7 +2548,7 @@ pass_sprintf_length::handle_gimple_call
 
   if (idx_dstsize == HOST_WIDE_INT_M1U)
 {
-  // For non-bounded functions like sprintf, to to determine
+  // For non-bounded functions like sprintf, to determine
   // the size of the destination from the object or pointer
   // passed to it as the first argument.
   dstsize = get_destination_size (gimple_call_arg (info.callstmt, 0));
@@ -2667,7 +2660,7 @@ pass_sprintf_l

Re: Patch ping

[Jakub Jelinek]

On Wed, Sep 28, 2016 at 09:28:14PM +0200, Bernd Schmidt wrote:
> On 09/28/2016 09:24 PM, Jakub Jelinek wrote:
> >I'd like to ping the
> >
> >http://gcc.gnu.org/ml/gcc-patches/2016-09/msg01436.html
> >
> >patch, containing various fixes for gimple-ssa-sprintf.c.
> >If the 0 < var to var > 0 changes are deemed too controversial, I can
> >separate them from the other changes.
> 
> I'd like to see them separated because they are obvious and good, so please
> install them first.

And here are the 0 < var to var > 0 changes.  Thoughts on those?

2016-09-28  Jakub Jelinek  

* gimple-ssa-sprintf.c (pass_sprintf_length::gate): Use x > 0 instead
of 0 < x.
(format_floating, format_string, format_directive,
get_destination_size, pass_sprintf_length::handle_gimple_call):
Likewise.

--- gcc/gimple-ssa-sprintf.c.jj 2016-09-21 08:54:15.0 +0200
+++ gcc/gimple-ssa-sprintf.c2016-09-21 15:09:02.209261013 +0200
@@ -130,8 +130,8 @@ pass_sprintf_length::gate (function *)
  not optimizing and the pass is being invoked early, or when
  optimizing and the pass is being invoked during optimization
  (i.e., "late").  */
-  return ((0 < warn_format_length || flag_printf_return_value)
- && (0 < optimize) == fold_return_value);
+  return ((warn_format_length > 0 || flag_printf_return_value)
+ && (optimize > 0) == fold_return_value);
 }
 
 /* The result of a call to a formatted function.  */
@@ -1188,7 +1188,7 @@ format_floating (const conversion_spec &
 case 'a':
   {
/* The minimum output is "0x.p+0".  */
-   res.range.min = 6 + (0 < prec ? prec : 0);
+   res.range.min = 6 + (prec > 0 ? prec : 0);
 
/* Compute the maximum just once.  */
static const int a_max[] = {
@@ -1249,7 +1249,7 @@ format_floating (const conversion_spec &
   gcc_unreachable ();
 }
 
-  if (0 < width)
+  if (width > 0)
 {
   if (res.range.min < (unsigned)width)
res.range.min = width;
@@ -1440,7 +1440,7 @@ get_string_length (tree str)
 static fmtresult
 format_string (const conversion_spec &spec, tree arg)
 {
-  unsigned width = spec.have_width && 0 < spec.width ? spec.width : 0;
+  unsigned width = spec.have_width && spec.width > 0 ? spec.width : 0;
   int prec = spec.have_precision ? spec.precision : -1;
 
   if (spec.star_width)
@@ -1756,7 +1756,7 @@ format_directive (const pass_sprintf_len
 }
   else
 {
-  if (!res->warned && 0 < fmtres.range.min && navail < fmtres.range.min)
+  if (!res->warned && fmtres.range.min > 0 && navail < fmtres.range.min)
{
  const char* fmtstr
= (info.bounded
@@ -2332,7 +2332,7 @@ get_destination_size (tree dest)
  a member array as opposed to the whole enclosing object), otherwise
  use type-zero object size to determine the size of the enclosing
  object (the function fails without optimization in this type).  */
-  int ost = 0 < optimize;
+  int ost = optimize > 0;
   unsigned HOST_WIDE_INT size;
   if (compute_builtin_object_size (dest, ost, &size))
 return size;
@@ -2648,7 +2640,8 @@ pass_sprintf_length::handle_gimple_call
  attempt to substitute the computed result for the return value of
  the call.  Avoid this optimization when -frounding-math is in effect
  and the format string contains a floating point directive.  */
-  if (0 < optimize && flag_printf_return_value
+  if (optimize > 0
+  && flag_printf_return_value
   && (!flag_rounding_math || !res.floating))
 try_substitute_return_value (gsi, info, res);
 }


Jakub

Re: Patch ping

[Bernd Edlinger]

Hi,

I too personally always prefer to write the code as the variable
at the left side and the constant at the right side of the
comparison, because that is how I would also say it naturally
in an English or German sentence.

Like for instance "my son is more than 7 years old".

I think nobody would ever say it the other way round.

Maybe, except when it is a mathematical "a < b < c" relation,
I would write it in C as "a < b && b < c", even if b is the
variable part and a and c the constants.

Hope that does not add more confusion...


Having that said, the patch looks good to me.


Thanks
Bernd.

Re: Patch ping

[Bernd Schmidt]

On 09/28/2016 09:47 PM, Jakub Jelinek wrote:

And here are the 0 < var to var > 0 changes.  Thoughts on those?


I kind of meant it the other way round, so yeah, please install.


Bernd

Re: Patch ping

[Jakub Jelinek]

On Wed, Sep 28, 2016 at 11:17:55PM +0200, Bernd Schmidt wrote:
> On 09/28/2016 09:47 PM, Jakub Jelinek wrote:
> >And here are the 0 < var to var > 0 changes.  Thoughts on those?
> 
> I kind of meant it the other way round, so yeah, please install.

Oops, sorry, shall I revert what I've committed then?

Jakub

Re: Patch ping

[Bernd Schmidt]

On 09/28/2016 11:40 PM, Jakub Jelinek wrote:

On Wed, Sep 28, 2016 at 11:17:55PM +0200, Bernd Schmidt wrote:

On 09/28/2016 09:47 PM, Jakub Jelinek wrote:

And here are the 0 < var to var > 0 changes.  Thoughts on those?


I kind of meant it the other way round, so yeah, please install.


Oops, sorry, shall I revert what I've committed then?


No, I think it looks fine too, although I can't figure out why that one 
block of code was moved.



Bernd

Re: Patch ping

[Jakub Jelinek]

On Wed, Sep 28, 2016 at 11:46:59PM +0200, Bernd Schmidt wrote:
> On 09/28/2016 11:40 PM, Jakub Jelinek wrote:
> >On Wed, Sep 28, 2016 at 11:17:55PM +0200, Bernd Schmidt wrote:
> >>On 09/28/2016 09:47 PM, Jakub Jelinek wrote:
> >>>And here are the 0 < var to var > 0 changes.  Thoughts on those?
> >>
> >>I kind of meant it the other way round, so yeah, please install.
> >
> >Oops, sorry, shall I revert what I've committed then?
> 
> No, I think it looks fine too, although I can't figure out why that one
> block of code was moved.

The intent was that each of the non-__*_chk builtins is followed by its
__*_chk counterpart; without the patch that was almost the case except for
that one exception.

Jakub

Re: Patch ping

[Richard Biener]

On Mon, 11 Jul 2016, Jakub Jelinek wrote:

> Hi!
> 
> I'd like to ping
> PR71716 - fix hang with long double atomics
> http://gcc.gnu.org/ml/gcc-patches/2016-07/msg00045.html

Ok.

Thanks,
Richard.

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping
  PR87506 - https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01758.html

You've acked the patch with the asserts but that FAILs as mentioned
in the above mail.  The following has been bootstrapped/regtested
and works, can it be committed without those asserts and let those
be handled incrementally later (though, I'm afraid I'm not familiar enough
with resolving those).

Thanks.

2018-11-21  Jakub Jelinek  

PR c++/87506
* constexpr.c (adjust_temp_type): Handle EMPTY_CLASS_EXPR.

* g++.dg/cpp0x/constexpr-87506.C: New test.

--- gcc/cp/constexpr.c.jj   2018-11-16 21:35:34.551110868 +0100
+++ gcc/cp/constexpr.c  2018-11-19 09:35:06.880386449 +0100
@@ -1280,6 +1280,8 @@ adjust_temp_type (tree type, tree temp)
   /* Avoid wrapping an aggregate value in a NOP_EXPR.  */
   if (TREE_CODE (temp) == CONSTRUCTOR)
 return build_constructor (type, CONSTRUCTOR_ELTS (temp));
+  if (TREE_CODE (temp) == EMPTY_CLASS_EXPR)
+return build0 (EMPTY_CLASS_EXPR, type);
   gcc_assert (scalarish_type_p (type));
   return cp_fold_convert (type, temp);
 }
--- gcc/testsuite/g++.dg/cpp0x/constexpr-87506.C.jj 2018-11-19 
09:33:07.795341369 +0100
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-87506.C2018-11-19 
09:33:07.795341369 +0100
@@ -0,0 +1,12 @@
+// PR c++/87506
+// { dg-do compile { target c++11 } }
+
+struct A {};
+struct B { constexpr B (const A) {} };
+struct C : B { using B::B; };
+
+void
+foo ()
+{
+  C c (A{});
+}


Jakub

Re: patch ping

[Jeff Law]

On 04/11/2015 04:27 PM, Bernhard Reutner-Fischer wrote:

Hi,

I'd like to ask an RM or global reviewer to kindly consider the
following patches preventing one or the other target in config-list.mk
to build:

[PATCH, bfin] handle BFIN_CPU_UNKNOWN in TARGET_CPU_CPP_BUILTINS
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00034.html

OK.



[PATCH, c6x] handle unk_isa in TARGET_CPU_CPP_BUILTINS
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00089.html

OK.




Cosmetic patchlets pending but probably for stage 1 now:

Remove redundant guard in emit_bss()
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00337.html

OK.



tree-tailcall: Commentary typo fix, remove fwd declaration
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00342.html

OK.



s/ ;/;/g Makefile.tpl
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00380.html

OK

Note there is a policy that requires all patches to be bootstrapped and 
regression tested.  These are trivial enough that I'll approve them 
as-is.  However, in the future, please bootstrap and regression test 
changes whenever possible.


Thanks,
Jeff

Re: Patch ping

[Jeff Law]

On 04/17/2015 01:59 AM, Jakub Jelinek wrote:

Hi!

I'd like to ping

PR target/65689 - P2 - http://gcc.gnu.org/ml/gcc-patches/2015-04/msg00358.html

patch (perhaps with the code[?] == ' ' -> ISSPACE (code[?]) changes or
strstr, as discussed in the following thread).
At this point of course for trunk only, and perhaps after a while for 5.2.
For the comment in compute_maybe_allows, "This should be conservative" 
could be interpreted as setting both bits or setting neither bit.  The 
code clearly does the former and with the background from reading the 
patch thread I know why, but someone reading the code may not get it 
without having to either look in the archives or follow how it gets 
used.  Consider updating the comment.


I'd tend to prefer strstr; I don't think this is performance sensitive code.

OK for the trunk with the comment fixed and your call on how to handle 
the whitespace issues.


jeff

Re: Patch ping

[Richard Earnshaw]

On 06/02/14 12:12, Jakub Jelinek wrote:
> Hi!
> 
> I'd like to ping a few outstanding patches:
> 
> - PR59575 P1 ARM dwarf2cfi ICEs fix
>   http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01997.html
> 

Wasn't this already approved (with comment fix)?

https://gcc.gnu.org/ml/gcc-patches/2014-02/msg00392.html

R.

> - PR59992 P1 var-tracking improvement
>   http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01962.html
> 
> - PR60030 P1 ubsan expansion fix
>   http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00167.html
> 
>   Jakub
> 

Re: Patch ping

[Richard Earnshaw]

On 17/04/15 16:46, Richard Earnshaw wrote:
> On 06/02/14 12:12, Jakub Jelinek wrote:
>> Hi!
>>
>> I'd like to ping a few outstanding patches:
>>
>> - PR59575 P1 ARM dwarf2cfi ICEs fix
>>   http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01997.html
>>
> 
> Wasn't this already approved (with comment fix)?
> 
> https://gcc.gnu.org/ml/gcc-patches/2014-02/msg00392.html
> 

Never mind.  Old mail popped back to the top of my list due to Jeff's
other response.

R.

> R.
> 
>> - PR59992 P1 var-tracking improvement
>>   http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01962.html
>>
>> - PR60030 P1 ubsan expansion fix
>>   http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00167.html
>>
>>  Jakub
>>
> 

Re: patch ping

[Bernhard Reutner-Fischer]

On April 13, 2015 3:12:48 PM GMT+02:00, Jeff Law  wrote:
>On 04/11/2015 04:27 PM, Bernhard Reutner-Fischer wrote:
>> Hi,
>>
>> I'd like to ask an RM or global reviewer to kindly consider the
>> following patches preventing one or the other target in
>config-list.mk
>> to build:
>>
>> [PATCH, bfin] handle BFIN_CPU_UNKNOWN in TARGET_CPU_CPP_BUILTINS
>> https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00034.html
>OK.
>
>>
>> [PATCH, c6x] handle unk_isa in TARGET_CPU_CPP_BUILTINS
>> https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00089.html
>OK.
>
>>
>>
>> Cosmetic patchlets pending but probably for stage 1 now:
>>
>> Remove redundant guard in emit_bss()
>> https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00337.html
>OK.
>
>>
>> tree-tailcall: Commentary typo fix, remove fwd declaration
>> https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00342.html
>OK.
>
>>
>> s/ ;/;/g Makefile.tpl
>> https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00380.html
>OK
>
>Note there is a policy that requires all patches to be bootstrapped and
>
>regression tested.  These are trivial enough that I'll approve them 
>as-is.  However, in the future, please bootstrap and regression test 
>changes whenever possible.

I'm aware of this policy. I did my best not to break other configs. By now all 
of the above were pushed including the erroneously committed
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01270.html
to fix 
PR target/47122 vax-*-openbsd* config.gcc typo

that Jakub was kind enough to confirm to be obvious on IRC.

Thanks for your reviews!

Since I touched Makefile.tpl and there was at least one other patch against it 
in GCC, i would be grateful if someone could synch Makefile.tpl back to 
binutils-gdb in two days or three so I can sleep well again a couple of days 
after that :)
cheers,

Re: patch ping

[Jan Hubicka]

> Hi,
> 
> I'd like to ping these patches
> 
> http://gcc.gnu.org/ml/gcc-patches/2015-01/msg02716.html
> pr 61889 - p1 don't require ftw.h in gcov-tool.c

Looks good enough. Hopefully eventually someone will write mingw implementation.
OK
> 
> http://gcc.gnu.org/ml/gcc-patches/2015-01/msg01869.html
> pr 64076 - p2 - don't ICE on invalid code that has ironly and not ironly
> thunks

OK.
Please add me to CC for patches that I can aprove.

Honza
> 
> thanks!
> 
> Trev

Re: Patch ping

[Richard Biener]

On Wed, 25 Feb 2015, Jakub Jelinek wrote:

> On Wed, Feb 18, 2015 at 11:00:35AM +0100, Jakub Jelinek wrote:
> > On Tue, Feb 17, 2015 at 11:00:14AM +0100, Richard Biener wrote:
> > > I'm just looking for a way to make this less of a hack (and the LTO IL
> > > less target dependent).  Not for GCC 5 for which something like your
> > > patch is probably ok, but for the future.
> > 
> > So, given Ilya's and Thomas' testing, is this acceptable for now, and
> > perhaps we can try to do something better for GCC 6?
> > 
> > Here is the patch with full ChangeLog:
> 
> I'd like to ping following patch:
> http://gcc.gnu.org/ml/gcc-patches/2015-02/msg01080.html

Oops, totally forgot about this one.

Shouldn't

+   default:
+ error ("unsupported mode %s\n", mname);

be a fatal_error ()?  After all if we hit this but continue we'll
stream random crap.  I also think we should be a bit more user-centric
here and maybe report "for host / offload target combination".

+static GTY(()) const unsigned char *lto_mode_identity_table;

why in GC memory?

Ok with changes along these lines.

Thanks,
Richard.


> > 2015-02-18  Jakub Jelinek  
> > 
> > * passes.c (ipa_write_summaries_1): Call lto_output_init_mode_table.
> > (ipa_write_optimization_summaries): Likewise.
> > * tree-streamer.h: Include data-streamer.h.
> > (streamer_mode_table): Declare extern variable.
> > (bp_pack_machine_mode, bp_unpack_machine_mode): New inline functions.
> > * lto-streamer-out.c (lto_output_init_mode_table,
> > lto_write_mode_table): New functions.
> > (produce_asm_for_decls): Call lto_write_mode_table when streaming
> > offloading LTO.
> > * lto-section-in.c (lto_section_name): Add "mode_table" entry.
> > (lto_create_simple_input_block): Add mode_table argument to the
> > lto_input_block constructors.
> > * ipa-prop.c (ipa_prop_read_section, read_replacements_section):
> > Likewise.
> > * data-streamer-in.c (string_for_index): Likewise.
> > * ipa-inline-analysis.c (inline_read_section): Likewise.
> > * ipa-icf.c (sem_item_optimizer::read_section): Likewise.
> > * lto-cgraph.c (input_cgraph_opt_section): Likewise.
> > * lto-streamer-in.c (lto_read_body_or_constructor,
> > lto_input_toplevel_asms): Likewise.
> > (lto_input_mode_table): New function.
> > * tree-streamer-out.c (pack_ts_fixed_cst_value_fields,
> > pack_ts_decl_common_value_fields, pack_ts_type_common_value_fields):
> > Use bp_pack_machine_mode.
> > * real.h (struct real_format): Add name field.
> > * lto-streamer.h (enum lto_section_type): Add LTO_section_mode_table.
> > (class lto_input_block): Add mode_table member.
> > (lto_input_block::lto_input_block): Add mode_table_ argument,
> > initialize mode_table.
> > (struct lto_file_decl_data): Add mode_table field.
> > (lto_input_mode_table, lto_output_init_mode_table): New prototypes.
> > * tree-streamer-in.c (unpack_ts_fixed_cst_value_fields,
> > unpack_ts_decl_common_value_fields,
> > unpack_ts_type_common_value_fields): Call bp_unpack_machine_mode.
> > * tree-streamer.c (streamer_mode_table): New variable.
> > * real.c (ieee_single_format, mips_single_format,
> > motorola_single_format, spu_single_format, ieee_double_format,
> > mips_double_format, motorola_double_format,
> > ieee_extended_motorola_format, ieee_extended_intel_96_format,
> > ieee_extended_intel_128_format, ieee_extended_intel_96_round_53_format,
> > ibm_extended_format, mips_extended_format, ieee_quad_format,
> > mips_quad_format, vax_f_format, vax_d_format, vax_g_format,
> > decimal_single_format, decimal_double_format, decimal_quad_format,
> > ieee_half_format, arm_half_format, real_internal_format): Add name
> > field.
> > * config/pdp11/pdp11.c (pdp11_f_format, pdp11_d_format): Likewise.
> > lto/
> > * lto.c (lto_mode_identity_table): New variable.
> > (lto_read_decls): Add mode_table argument to the lto_input_block
> > constructor.
> > (lto_file_finalize): Initialize mode_table.
> > (lto_init): Initialize lto_mode_identity_table.
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild,
Dilip Upmanyu, Graham Norton HRB 21284 (AG Nuernberg)

Re: Patch ping

[Jakub Jelinek]

On Wed, Feb 25, 2015 at 10:10:52AM +0100, Richard Biener wrote:
> Oops, totally forgot about this one.
> 
> Shouldn't
> 
> + default:
> +   error ("unsupported mode %s\n", mname);
> 
> be a fatal_error ()?  After all if we hit this but continue we'll

Ok, I'll change it.

> stream random crap.  I also think we should be a bit more user-centric
> here and maybe report "for host / offload target combination".

Eventually, sure, we should be able (based on options) either turn all the
errors from the offloading compiler into warnings that just disable the
offloading for some particular offloading target.

> +static GTY(()) const unsigned char *lto_mode_identity_table;
> 
> why in GC memory?

The reason for that is that it is referenced from GC structure, and in the
offloading path they should be GC allocated, so that they can be released
when the corresponding GC structure holding pointer to that goes away.
In the non-offloading LTO, all those GC structures will contain the same
value, lto_mode_identity_table, but if that would be heap allocated, GC
would be upset.

Jakub

Re: Patch ping

[Andreas Krebbel]

On 05/05/2015 08:52 PM, Jakub Jelinek wrote:
> Hi!
> 
> http://gcc.gnu.org/ml/gcc-patches/2015-04/msg01432.html
>   - this got approved for arm and aarch64, but not for s390{,x}
>   Ok for trunk?

Yes. Thanks!

-Andreas-

Re: Patch ping

[DJ Delorie]

> - http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01370.html
>   PR sanitizer/56781
>   fix --with-build-config=bootstrap-ubsan bootstrap of lto-plugin

I have no particular problem with this patch, although the build has
gotten beyond my full understanding these days...

However, does this fix a regression?  If not, it should wait for
stage1.

> - http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01433.html
>   PR sanitizer/56781
>   fix --with-build-config=bootstrap-asan bootstrap of lto-plugin

Are we really going to multilib libiberty for every "useful" option we
think of?  For the build/host, we have a generic way of providing
CFLAGS, and for the target we already have a multilib structure.

Re: Patch ping

[Jeff Law]

On 04/09/14 07:07, Jakub Jelinek wrote:

Hi!

I'd like to ping:

- http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01370.html
   PR sanitizer/56781
   fix --with-build-config=bootstrap-ubsan bootstrap of lto-plugin

- http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01433.html
   PR sanitizer/56781
   fix --with-build-config=bootstrap-asan bootstrap of lto-plugin
Like DJ, I think these should wait until the next stage1.  They're 
primarily of interest to GCC developers and they don't fix a regression 
AFAIK.


Jeff

Re: Patch ping

[Jakub Jelinek]

On Wed, Apr 09, 2014 at 06:29:48PM -0400, DJ Delorie wrote:
> 
> > - http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01370.html
> >   PR sanitizer/56781
> >   fix --with-build-config=bootstrap-ubsan bootstrap of lto-plugin
> 
> I have no particular problem with this patch, although the build has
> gotten beyond my full understanding these days...
> 
> However, does this fix a regression?  If not, it should wait for
> stage1.

But ubsan is a new feature in 4.9, and it is a bootstrap failure with that
feature.

> > - http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01433.html
> >   PR sanitizer/56781
> >   fix --with-build-config=bootstrap-asan bootstrap of lto-plugin
> 
> Are we really going to multilib libiberty for every "useful" option we
> think of?  For the build/host, we have a generic way of providing
> CFLAGS, and for the target we already have a multilib structure.

This is for the host libiberty only, and only when gcc is configured a
certain way.  The intent is to have libiberty that is going to be
linked into all the build and host tools instrumented, so that we actually
catch bugs in libiberty or bugs in host/build tools calling libiberty
functions as much as possible, but for the lto-plugin, which is dlopened
by the linker which we don't have a control on, we need host libiberty without
the address sanitization because otherwise it would only work properly if
the linker itself has been address sanitized.

Jakub

Re: Patch ping

[DJ Delorie]

> But ubsan is a new feature in 4.9, and it is a bootstrap failure
> with that feature.

I will leave it up to the release manager to decide if they want this
non-regression patch applied before the branch, then.

> This is for the host libiberty only, and only when gcc is configured
> a certain way.  The intent is to have libiberty that is going to be
> linked into all the build and host tools instrumented, so that we
> actually catch bugs in libiberty or bugs in host/build tools calling
> libiberty functions as much as possible, but for the lto-plugin,
> which is dlopened by the linker which we don't have a control on, we
> need host libiberty without the address sanitization because
> otherwise it would only work properly if the linker itself has been
> address sanitized.

So, if libiberty isn't built with sanitization, it would still *work*
but not be instrumented?

Re: Patch ping

[Tobias Burnus]

DJ Delorie wrote:

>This is for the host libiberty only, and only when gcc is configured
>a certain way.  The intent is to have libiberty that is going to be
>linked into all the build and host tools instrumented, so that we
>actually catch bugs in libiberty or bugs in host/build tools calling
>libiberty functions as much as possible, but for the lto-plugin,
>which is dlopened by the linker which we don't have a control on, we
>need host libiberty without the address sanitization because
>otherwise it would only work properly if the linker itself has been
>address sanitized.


So, if libiberty isn't built with sanitization, it would still*work*
but not be instrumented?


That's my understanding. However, currently, without the patch the 
sanitizer is also used with the LTO plugin, which breaks the build with 
--with-build-config=bootstrap-ubsan,bootstrap-asan.


Always building libiberty without UBSAN/ASAN even when the 
bootstrap-asan/ubsan option has been used, would be an option. However, 
if one also sanitizes libiberty, one has the chance to find bugs also in 
that library.


Tobias

PS: I found the out-of-bounds checking of ASAN and the integer overflow 
checks of UBSAN very helpful for the program I use at work.

Re: Patch ping

[Jakub Jelinek]

On Mon, Jan 13, 2014 at 08:22:47AM -0700, Jeff Law wrote:
> On 01/13/14 08:20, Jakub Jelinek wrote:
> >On Mon, Jan 13, 2014 at 08:15:11AM -0700, Jeff Law wrote:
> >>On 01/13/14 01:07, Jakub Jelinek wrote:
> >>>I'd like to ping 2 patches:
> >>>
> >>>http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00140.html
> >>>- Ensure GET_MODE_{SIZE,INNER,NUNITS} (const) is constant rather than
> >>>   memory load after optimization (I'd like to keep the current 
> >>>   patch for the reasons mentioned there, but also add this patch)
> >>I'd tend to think this is 4.10/5.0 material.  Unless (for example),
> >>you've got a PR where this makes a significant difference in compile
> >>time.
> >
> >Ok, will defer it then.
> THanks.  I've put in my queued folder as well ;-)

Is this ok now for stage1?

Jakub

Re: Patch ping

[Jakub Jelinek]

On Thu, Apr 10, 2014 at 12:01:31PM -0400, DJ Delorie wrote:
> > But ubsan is a new feature in 4.9, and it is a bootstrap failure
> > with that feature.
> 
> I will leave it up to the release manager to decide if they want this
> non-regression patch applied before the branch, then.
> 
> > This is for the host libiberty only, and only when gcc is configured
> > a certain way.  The intent is to have libiberty that is going to be
> > linked into all the build and host tools instrumented, so that we
> > actually catch bugs in libiberty or bugs in host/build tools calling
> > libiberty functions as much as possible, but for the lto-plugin,
> > which is dlopened by the linker which we don't have a control on, we
> > need host libiberty without the address sanitization because
> > otherwise it would only work properly if the linker itself has been
> > address sanitized.
> 
> So, if libiberty isn't built with sanitization, it would still *work*
> but not be instrumented?

Certainly.  If libiberty isn't built with sanitization (that is the normal
case), then even nothing changes in the way it is built.
The problem is only when it is built with sanitization that we actually for
the lto-plugin (and whatever else is built as an dlopenable module, not
an application) need a variant of the host libiberty that isn't built with
sanitization (talking about asan only here, ubsan can handle this).

So, now that 4.9 has branched, are both patches ok for trunk, or just the
first one?  The first one fixes --with-build-config=bootstrap-ubsan
fully and --with-build-config=bootstrap-asan partially, the second one
--with-build-config=bootstrap-asan fully.

Jakub

Re: Patch ping

[Toon Moene]

On 04/14/2014 01:02 PM, Jakub Jelinek wrote:


On Thu, Apr 10, 2014 at 12:01:31PM -0400, DJ Delorie wrote:



So, now that 4.9 has branched, are both patches ok for trunk, or just the
first one?  The first one fixes --with-build-config=bootstrap-ubsan
fully and --with-build-config=bootstrap-asan partially, the second one
--with-build-config=bootstrap-asan fully.


Now that the 4.9 branch happened, I sincerely hope this goes in (both 
parts of it) - my bootstrap-asan run this morning still failed.


I'm quite sure regular asan/ubsan bootstraps on various platforms (mine 
is only the most common x86-64 one) would be helpful to find bugs in the 
compilers' frontends, middle end and libraries ...


Kind regards,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

Re: Patch ping

[DJ Delorie]

I'll approve both patches, if you agree to think about a way to solve
this problem without module-specific configury changes for each such
command line option.  I understand the usefulness of having
instrumentation, but the configure hack is a hack.

Note that in a combined tree this isn't a problem, because we'd just
instrument the linker at the same time.

Re: Patch ping

[Jeff Law]

On 01/13/14 01:07, Jakub Jelinek wrote:

Hi!

I'd like to ping 2 patches:

http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00140.html
- Ensure GET_MODE_{SIZE,INNER,NUNITS} (const) is constant rather than
   memory load after optimization (I'd like to keep the current 
   patch for the reasons mentioned there, but also add this patch)
This is fine.  Per the follow-up discussion, I think you can mark it was 
resolving 36109 as well.




http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00131.html
- PR target/59617
   handle gather loads for AVX512 (at least non-masked ones, masked ones
   will need to wait for 5.0 and we need to find how to represent it in
   GIMPLE)

I'll leave this to Uros :-)

jeff

Re: Patch ping

[Jakub Jelinek]

On Wed, Apr 16, 2014 at 02:45:37PM -0400, DJ Delorie wrote:
> I'll approve both patches, if you agree to think about a way to solve
> this problem without module-specific configury changes for each such
> command line option.  I understand the usefulness of having
> instrumentation, but the configure hack is a hack.

Only the second patch I'd consider a hack, the first patch merely makes sure
the POSTSTAGE1_LDFLAGS stuff actually isn't eaten by libtool.

I'll think about other options for the second patch.

> Note that in a combined tree this isn't a problem, because we'd just
> instrument the linker at the same time.

Only if you never use the plugin from the combined tree build with any other
linker.  Add -B ../ to some other linker and suddenly it will crash.

Jakub

Re: Patch ping

[Uros Bizjak]

On Wed, Apr 16, 2014 at 11:35 PM, Jeff Law  wrote:
>
>> I'd like to ping 2 patches:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00140.html
>> - Ensure GET_MODE_{SIZE,INNER,NUNITS} (const) is constant rather than
>>memory load after optimization (I'd like to keep the current
>> 
>>patch for the reasons mentioned there, but also add this patch)
>
> This is fine.  Per the follow-up discussion, I think you can mark it was
> resolving 36109 as well.
>
>
>>
>> http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00131.html
>> - PR target/59617
>>handle gather loads for AVX512 (at least non-masked ones, masked ones
>>will need to wait for 5.0 and we need to find how to represent it in
>>GIMPLE)
>
> I'll leave this to Uros :-)

IIRC, this patch was already committed to 4.9 some time ago.

Uros.

Re: Patch ping

[Jeff Law]

On 01/05/15 06:53, Jakub Jelinek wrote:

Hi!

I'd like to ping 3 patches:

http://gcc.gnu.org/ml/gcc-patches/2014-12/msg01519.html
   - PR64344 - -fsanitize=float-cast-overflow fix - the C FE part
 is approved, but not the sanitizer bits outside of the FE

OK.



http://gcc.gnu.org/ml/gcc-patches/2014-12/msg01271.html
   - PR64265 - tsan support for exceptions

OK.



http://gcc.gnu.org/ml/gcc-patches/2014-12/msg00297.html
   - -fsanitize=vptr support
How is this different from vtable pointer verification that we already 
support?  Is there some reason we can't just use that instead?


jeff

Re: Patch ping

[Jakub Jelinek]

On Mon, Jan 05, 2015 at 02:27:41PM -0700, Jeff Law wrote:
> On 01/05/15 06:53, Jakub Jelinek wrote:
> >Hi!
> >
> >I'd like to ping 3 patches:
> >
> >http://gcc.gnu.org/ml/gcc-patches/2014-12/msg01519.html
> >   - PR64344 - -fsanitize=float-cast-overflow fix - the C FE part
> > is approved, but not the sanitizer bits outside of the FE
> OK.
> 
> >
> >http://gcc.gnu.org/ml/gcc-patches/2014-12/msg01271.html
> >   - PR64265 - tsan support for exceptions
> OK.
> 
> >
> >http://gcc.gnu.org/ml/gcc-patches/2014-12/msg00297.html
> >   - -fsanitize=vptr support
> How is this different from vtable pointer verification that we already
> support?  Is there some reason we can't just use that instead?

I don't now the current vtable pointer verification too much, but my
understanding of it is that it is hardly usable, because e.g. it requires
libstdc++ to be rebuilt with the verification enabled, otherwise you can't
verify stuff, and that means a performance penalty even for code you don't
want to verify.  Unlike that, -fsanitize=vptr is lightweight, and you only
rebuild with it what you want and can have other code kept as is, not
recompiled.

Jakub

Re: Patch ping

[Jakub Jelinek]

On Mon, Jan 05, 2015 at 10:39:03PM +0100, Jakub Jelinek wrote:
> > >http://gcc.gnu.org/ml/gcc-patches/2014-12/msg00297.html
> > >   - -fsanitize=vptr support
> > How is this different from vtable pointer verification that we already
> > support?  Is there some reason we can't just use that instead?
> 
> I don't now the current vtable pointer verification too much, but my
> understanding of it is that it is hardly usable, because e.g. it requires
> libstdc++ to be rebuilt with the verification enabled, otherwise you can't
> verify stuff, and that means a performance penalty even for code you don't
> want to verify.  Unlike that, -fsanitize=vptr is lightweight, and you only
> rebuild with it what you want and can have other code kept as is, not
> recompiled.

Also, it seems to verify significantly less than -fsanitize=vptr does,
only method calls, while -fsanitize=vptr also verifies member accesses
and downcasts/upcasts.

Jakub

Re: Patch ping

[Jeff Law]

On 01/05/15 14:39, Jakub Jelinek wrote:

On Mon, Jan 05, 2015 at 02:27:41PM -0700, Jeff Law wrote:

On 01/05/15 06:53, Jakub Jelinek wrote:

Hi!

I'd like to ping 3 patches:

http://gcc.gnu.org/ml/gcc-patches/2014-12/msg01519.html
   - PR64344 - -fsanitize=float-cast-overflow fix - the C FE part
 is approved, but not the sanitizer bits outside of the FE

OK.



http://gcc.gnu.org/ml/gcc-patches/2014-12/msg01271.html
   - PR64265 - tsan support for exceptions

OK.



http://gcc.gnu.org/ml/gcc-patches/2014-12/msg00297.html
   - -fsanitize=vptr support

How is this different from vtable pointer verification that we already
support?  Is there some reason we can't just use that instead?


I don't now the current vtable pointer verification too much, but my
understanding of it is that it is hardly usable, because e.g. it requires
libstdc++ to be rebuilt with the verification enabled, otherwise you can't
verify stuff, and that means a performance penalty even for code you don't
want to verify.  Unlike that, -fsanitize=vptr is lightweight, and you only
rebuild with it what you want and can have other code kept as is, not
recompiled.

OK.  I'd forgotten about the "recompile libstdc++" aspect.  Sigh.

The language independent stuff looks reasonable to me -- you know this 
code better than I, so it was just a cursory look.  Jason should ack the 
C++ bits.


jeff

Re: Patch ping...

[Jason Merrill]

On 01/14/2015 12:30 AM, Jan Hubicka wrote:

I would like to ping the patch to fix divergence between a type and its main 
variant introduced by C++ FE.


OK.

Jason

Patch ping #2

[Jakub Jelinek]

Hi!

- http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01182.html   
   
  various debug info improvements (typed DWARF stack etc.)  
   

   
- http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01246.html   
   
  optimize away unneeded DW_OP_GNU_convert ops with typed DWARF stack   
   

   
- http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01669.html   
   
  PR48688 optimization, I know Richard asked for trying it during   
   
  combine, but that attempt failed due to opposite optimization 
   

Jakub

Re: Patch ping

[Richard Henderson]

On 06/19/2011 11:41 PM, Jakub Jelinek wrote:
> [debug]
>   http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00649.html
>   trunk only
>   DW_OP_GNU_parameter_ref support
> 
> [debug]
>   http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00751.html
>   trunk only
>   DW_OP_GNU_convert <0> support

Both ok.


r~

Re: Patch ping

[Eric Botcazou]

> [testsuite]
>   http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01069.html
>   PR tree-optimization/48377, PR middle-end/49191
>   trunk/4.6
>   non_strict_align testsuite support

Mike, Rainer, can one of you two take a look at this?

-- 
Eric Botcazou

Re: Patch ping

[Mike Stump]

On Jun 25, 2011, at 11:53 AM, Eric Botcazou wrote:
>> [testsuite]
>>  http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01069.html
>>  PR tree-optimization/48377, PR middle-end/49191
>>  trunk/4.6
>>  non_strict_align testsuite support
> 
> Mike, Rainer, can one of you two take a look at this?

Done, reviewed and approved in original thread.

Patch ping #3

[Eric Botcazou]

Extend TYPE_DECL_IS_STUB trick (1 line):
  http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00683.html

Emit DW_AT_artificial for types:
  http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00700.html

Fix PR lto/48492 (bis) (1 line):
  http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01461.html

Thanks in advance.

-- 
Eric Botcazou

Re: Patch ping

[Richard Guenther]

On Wed, 2 Nov 2011, Jakub Jelinek wrote:

> Hi!
> 
> - Gather vectorization patch + incremental patches
>   http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02411.html

I'm not sure I like using new builtins for gather representation
on the tree level too much, given that we are now moving
towards using tree codes for suffle.  Thus, how complicated
would it be to have a gather tree code and optab and to
handle the mixed size index issue in the expander?

I realize this would be quite some reorg to the patchset ...
so, why did you choose builtins over a more generic approach?

>   http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02846.html

+  if (TREE_CODE (base) == MEM_REF)
 {
-  off = TREE_OPERAND (base, 1);
+  if (!integer_zerop (TREE_OPERAND (base, 1)))
+   {
+ if (off == NULL_TREE)
+   {
+ double_int moff = mem_ref_offset (base);
+ off = double_int_to_tree (sizetype, moff);
+   }
+ else
+   off = size_binop (PLUS_EXPR, off, TREE_OPERAND (base, 1));

that's not safe, TREE_OPEAND (base, 1) is of pointer type, so
you unconditionally need to do the conversion to sizetype of
TREE_OPEAND (base, 1).

The routine lacks comments - it's got quite big and fails to
state any reason for its complexity.  I'm also not sure why
DR would include any loop invariant parts of the SCEV - doesn't
it instantiate just for the loop in question?

Thanks,
Richard.

Re: Patch ping

[Jakub Jelinek]

On Fri, Nov 04, 2011 at 10:52:44AM +0100, Richard Guenther wrote:
> > - Gather vectorization patch + incremental patches
> >   http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02411.html
> 
> I'm not sure I like using new builtins for gather representation
> on the tree level too much, given that we are now moving
> towards using tree codes for suffle.  Thus, how complicated
> would it be to have a gather tree code and optab and to
> handle the mixed size index issue in the expander?
> 
> I realize this would be quite some reorg to the patchset ...
> so, why did you choose builtins over a more generic approach?

Because while permutations etc. are common to most targets,
currently gather is very specialized, specific to one target,
with lots of details how it must look like (e.g. the mask stuff where
we currently don't even have tree code for conditional loads or conditional
stores), and additionally unlike VEC_PERM_EXPR etc. which are normal
expressions this one is a reference (and conditional one too), so
I'm afraid I'd need to touch huge amounts of code (most places that
currently handle MEM_REF/TARGET_MEM_REF would need to handle
VEC_GATHER_MEM_REF too, as it is a memory read (well, set of conditional
memory reads).  The i?86 backend already has (except 4) all the needed
builtins anyway and handles expanding them too, the 4 ones are just
to cope with the weirdo definition of some of them (half sized vectors).
And when it is represented as builtin, the side-effects are handled by
all optimization passes automatically, similarly how e.g. atomic builtins
are right now builtins and not expressions.

So I thought it is better to use builtins right now, then when we in 4.8+
hopefully do something about conditional loads/stores and their
vectorization and if we introduce for that some new GIMPLE representation,
this could be done on top of that.

> >   http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02846.html
> 
> +  if (TREE_CODE (base) == MEM_REF)
>  {
> -  off = TREE_OPERAND (base, 1);
> +  if (!integer_zerop (TREE_OPERAND (base, 1)))
> + {
> +   if (off == NULL_TREE)
> + {
> +   double_int moff = mem_ref_offset (base);
> +   off = double_int_to_tree (sizetype, moff);
> + }
> +   else
> + off = size_binop (PLUS_EXPR, off, TREE_OPERAND (base, 1));
> 
> that's not safe, TREE_OPEAND (base, 1) is of pointer type, so
> you unconditionally need to do the conversion to sizetype of
> TREE_OPEAND (base, 1).

Ok, will fix.

> The routine lacks comments - it's got quite big and fails to

And add the comments.

> state any reason for its complexity.  I'm also not sure why
> DR would include any loop invariant parts of the SCEV - doesn't
> it instantiate just for the loop in question?

I'm not sure I understand your question.  With the incremental
patch I'm not using any DR info appart from DR_REF to determine
what is loop invariant part of the address and what is not.
The reason for that is that split_constant_offset turns the GIMPLE
code into a sometimes big tree, which actually may contain a mixture
of loop invariants/constants and SSA_NAMEs defined in the loop,
that all with casts, multiplications/additions/subtractions.
For gather I need to split it into a single loop invariant
argument (which can be computed before the loop as loop invariant
and thus can be arbitrary tree expression that is just gimplified
there) and another SSA_NAME defined into the loop which can be
vectorized which is perhaps sign-extended and multiplied by 1/2/4/8.

With the approach the incremental patch does I just
walk what split_constant_offset during DR walks and peel off
loop invariants until I have something that should be used as the
vectorized index.

Jakub

Re: Patch ping

[Richard Guenther]

On Fri, 4 Nov 2011, Jakub Jelinek wrote:

> On Fri, Nov 04, 2011 at 10:52:44AM +0100, Richard Guenther wrote:
> > > - Gather vectorization patch + incremental patches
> > >   http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02411.html
> > 
> > I'm not sure I like using new builtins for gather representation
> > on the tree level too much, given that we are now moving
> > towards using tree codes for suffle.  Thus, how complicated
> > would it be to have a gather tree code and optab and to
> > handle the mixed size index issue in the expander?
> > 
> > I realize this would be quite some reorg to the patchset ...
> > so, why did you choose builtins over a more generic approach?
> 
> Because while permutations etc. are common to most targets,
> currently gather is very specialized, specific to one target,
> with lots of details how it must look like (e.g. the mask stuff where
> we currently don't even have tree code for conditional loads or conditional
> stores), and additionally unlike VEC_PERM_EXPR etc. which are normal
> expressions this one is a reference (and conditional one too), so
> I'm afraid I'd need to touch huge amounts of code (most places that
> currently handle MEM_REF/TARGET_MEM_REF would need to handle
> VEC_GATHER_MEM_REF too, as it is a memory read (well, set of conditional
> memory reads).  The i?86 backend already has (except 4) all the needed
> builtins anyway and handles expanding them too, the 4 ones are just
> to cope with the weirdo definition of some of them (half sized vectors).
> And when it is represented as builtin, the side-effects are handled by
> all optimization passes automatically, similarly how e.g. atomic builtins
> are right now builtins and not expressions.
> 
> So I thought it is better to use builtins right now, then when we in 4.8+
> hopefully do something about conditional loads/stores and their
> vectorization and if we introduce for that some new GIMPLE representation,
> this could be done on top of that.

Ok.  I guess it's ok to use builtins for now - I didn't think of
the memory reference issue ;)

> > >   http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02846.html
> > 
> > +  if (TREE_CODE (base) == MEM_REF)
> >  {
> > -  off = TREE_OPERAND (base, 1);
> > +  if (!integer_zerop (TREE_OPERAND (base, 1)))
> > +   {
> > + if (off == NULL_TREE)
> > +   {
> > + double_int moff = mem_ref_offset (base);
> > + off = double_int_to_tree (sizetype, moff);
> > +   }
> > + else
> > +   off = size_binop (PLUS_EXPR, off, TREE_OPERAND (base, 1));
> > 
> > that's not safe, TREE_OPEAND (base, 1) is of pointer type, so
> > you unconditionally need to do the conversion to sizetype of
> > TREE_OPEAND (base, 1).
> 
> Ok, will fix.
> 
> > The routine lacks comments - it's got quite big and fails to
> 
> And add the comments.
> 
> > state any reason for its complexity.  I'm also not sure why
> > DR would include any loop invariant parts of the SCEV - doesn't
> > it instantiate just for the loop in question?
> 
> I'm not sure I understand your question.  With the incremental
> patch I'm not using any DR info appart from DR_REF to determine
> what is loop invariant part of the address and what is not.
> The reason for that is that split_constant_offset turns the GIMPLE
> code into a sometimes big tree, which actually may contain a mixture
> of loop invariants/constants and SSA_NAMEs defined in the loop,
> that all with casts, multiplications/additions/subtractions.
> For gather I need to split it into a single loop invariant
> argument (which can be computed before the loop as loop invariant
> and thus can be arbitrary tree expression that is just gimplified
> there) and another SSA_NAME defined into the loop which can be
> vectorized which is perhaps sign-extended and multiplied by 1/2/4/8.
> 
> With the approach the incremental patch does I just
> walk what split_constant_offset during DR walks and peel off
> loop invariants until I have something that should be used as the
> vectorized index.

It looks like split_constant_offset walks def stmts in an unbound
fashion.  That's surely a bad idea - SCEV should already have
expanded everything non-loop-invariant, thus it should at most
look through DEFs that trivially add to the constant offset,
not through others.

Richard.

Re: Patch ping

[Michael Matz]

Hi,

On Fri, 4 Nov 2011, Richard Guenther wrote:

> > With the approach the incremental patch does I just walk what 
> > split_constant_offset during DR walks and peel off loop invariants 
> > until I have something that should be used as the vectorized index.
> 
> It looks like split_constant_offset walks def stmts in an unbound 
> fashion.  That's surely a bad idea - SCEV should already have expanded 
> everything non-loop-invariant, thus it should at most look through DEFs 
> that trivially add to the constant offset, not through others.

split_constant_offset is also used for canonicalization, to increase 
chances of finding the same base in two data refs to be able to use offset 
based disambiguation.  For that it sometimes has to look also through loop 
invariant parts.


Ciao,
Michael.

Re: Patch ping

[Richard Guenther]

On Mon, Nov 7, 2011 at 10:45 PM, Jakub Jelinek  wrote:
> Hi!
>
> I'd like to ping the restrict_based_on_field attribute patch:
> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00135.html
>
> We currently don't do cast restricts and even if we do them again,
> as this attribute doesn't make the type __restrict it wouldn't
> affect those, it only affects parameters, if they are __restrict
> themselves what they point to, and global vars.
>
> IMHO it would be a pitty not to improve generated code for std::vector
> for 4.7.

The patch probably needs updating for the changes I committed and
it still says

"The patch is still incomplete,.."

It does look like this would map to the more general solution
explicitely specifying a restrict tag.  That way we'd avoid the
funny field walkings (do you properly update the FIELD_DECL
parameter of the attribute when instantiating templates?)

--- libstdc++-v3/include/bits/stl_vector.h.jj   2011-08-18
08:36:12.0 +0200
+++ libstdc++-v3/include/bits/stl_vector.h  2011-10-03 15:45:26.0 
+0200
@@ -77,9 +77,18 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   struct _Vector_impl
   : public _Tp_alloc_type
   {
-   pointer _M_start;
-   pointer _M_finish;
-   pointer _M_end_of_storage;
+   /* These pointers act like restricted pointers, except that there
+  are 3 pointers pointing into the same array instead of just one.
+  That is, if any part of the array pointed by _M_start is
+  modified, it can be accessed through either pointers based
+  on the _M_start field, or based on the _M_finish field, or
+  _M_end_of_storage field.  */
+   pointer _M_start
+ __attribute__((__restrict_based_on_field__ (_M_start)));
+   pointer _M_finish
+ __attribute__((__restrict_based_on_field__ (_M_start)));
+   pointer _M_end_of_storage
+ __attribute__((__restrict_based_on_field__ (_M_start)));

are we sure that no shallow copies of vectors are allowed?  I'm thinking
of move constructors or so ...

Finally just the above is not very much testing coverage.

Thanks,
Richard.

Re: Patch ping

[Joseph S. Myers]

On Mon, 29 Aug 2011, Jakub Jelinek wrote:

> http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00428.html
>   Adjust gthr-posix.h so that g++ -C -E works with STL headers
>

OK in the absence of libgcc maintainer objections within 24 hours.

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

Re: Patch ping

[Bernd Schmidt]

On 08/29/11 11:03, Jakub Jelinek wrote:
> http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01767.html
>   PR middle-end/48722  
>   Fix RTL sharing problem with CALL_INSN_FUNCTION_USAGE  

Looks OK.


Bernd

Re: Patch ping

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/29/11 03:03, Jakub Jelinek wrote:
> Hi!
> 
> http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01767.html PR
> middle-end/48722 Fix RTL sharing problem with
> CALL_INSN_FUNCTION_USAGE
> 
> http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00428.html Adjust
> gthr-posix.h so that g++ -C -E works with STL headers
OK and OK.

Thanks,
Jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOW/UVAAoJEBRtltQi2kC7qA8H/16vGf20cdoMv/aHwa+tmW0S
eWkn6kbYHHy1M+ai61nP8tCe5TSalI2UC0sJKiI/Y83Hs7pYqLFptTyauqzpTezQ
kpxEemFQ1VBvR5gfsv+Ypkc/LvSogKt3Oodq98tt+XxciCDjqpHIOgNy1KSo8gpJ
tOJfVBOF8RLnmvwLKI3X8EpDAe7T7BYJqnj+yEb0TzPHawMhA29NPNK6lkD+o8Ub
EcujfaqTSTE2sOWe9OlgAQO5NbOk89c7jUKwuww0yNYg24xAnK0jXGASJ48wassN
xOLtb9dIndvC1KtNtyg0ttp3UYdtnIF9PNPfjtoysUrVCumhZ7ipCfi1hS90xXA=
=t/A/
-END PGP SIGNATURE-

Re: Patch ping

[Jeff Law]

On 09/12/2011 09:18 AM, Jakub Jelinek wrote:

Hi!

I'd like to ping two patches of mine:

http://gcc.gnu.org/ml/gcc-patches/2011-08/msg02385.html
   - PR rtl-optimization/50212
 fix EH ICE with -freorder-blocks-and-partition
Seems OK.  Though I did wonder why we were deleting the label and 
whether or not that was an indication that there was another suitable 
label in the insn stream that should be used instead.  Assuming you 
verified that is not the case, then this patch is OK.





http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00386.html
   - PR debug/50299
 addition original argument mode to
 CALL_INSN_FUNCTION_USAGE to fix up call site debug info

OK
jeff

Re: Patch ping

[Richard Sandiford]

Jakub Jelinek  writes:
> optimize all ones vectors in simplify-rtx.c (and i386 expansion):
>   http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01364.html

I wonder whether we should have a CONSTM1_RTX(MODE).  It seems
inconsistent to have vector 0s and 1s, but only have integer -1s.

As far as simplify-rtx.c goes, I think all_ones_cst should cover the
existing CONST_INT_P case too.  CONST_INTs have to be represented as
sign-extended, and "trueop1" should still have mode "mode", so something's
wrong if the current code matches things that aren't constm1_rtx.
The simplify-rtx.c change looks good otherwise.

Richard

Re: Patch ping

[Richard Guenther]

On Mon, 5 Mar 2012, Jakub Jelinek wrote:

> Hi!
> 
> I'd like to ping two patches deferred to 4.8.  I've bootstrapped/regtested
> them on x86_64-linux and i686-linux:
> 
> - PR51721 VRP register_edge_assert_for_2 improvements
>   http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00046.html

Ok.

Thanks,
Richard.

Re: Patch ping

[Richard Henderson]

On 03/05/2012 03:08 AM, Jakub Jelinek wrote:
> - PR51902 dwarf2out .debug_ranges ~ 22% reduction
>   http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01171.html

Ok.


r~

[Fortran] Patch ping

[Tobias Burnus]

Dear all,

first, I would like to ping my patch:
- [Patch, Fortran] PR52864 - fix actual/formal checks
  http://gcc.gnu.org/ml/fortran/2012-04/msg00059.html

Other patches with pending review:
- [Patch, Fortran, F03] PR52909: Procedure pointers not private to modules
  http://gcc.gnu.org/ml/fortran/2012-04/msg00033.html
  Caveat: ABI breakage
- [patch, fortran] PR fortran/52537 Optimize string comparisons against empty 
strings
  http://gcc.gnu.org/ml/fortran/2012-04/msg00068.html
- [Patch, libfortran] Combine get_mem and internal_malloc_size
  http://gcc.gnu.org/ml/fortran/2012-03/msg00127.html


Approved but not yet committed:

My patches:
- (My "TREE_PUBLIC() = 0 for module procedures" test-case fix
   http://gcc.gnu.org/ml/fortran/2012-04/msg00082.html) 
- [Patch, Fortran] PR52864 - Fix pointer-intent regresssion
  http://gcc.gnu.org/ml/fortran/2012-04/msg00058.html

Janus:
- [Patch, Fortran, OOP] PR 52968: Call to type-bound procedure wrongly rejected
  http://gcc.gnu.org/ml/fortran/2012-04/msg00083.html

Thomas:
- [patch, fortran] Trim spaces on list-directed reads
  http://gcc.gnu.org/ml/fortran/2012-04/msg00040.html
- [patch, fortran-dev] Use fixed variable sizes for stride calculations
  http://gcc.gnu.org/ml/fortran/2012-04/msg00074.html

Bernhard:
- [PATCH] gfortran testsuite: implicitly cleanup-modules, part 2
  http://gcc.gnu.org/ml/fortran/2012-04/msg00065.html

Janne:
- [Patch, fortran] PR 49010/24518 MOD/MODULO fixes
  http://gcc.gnu.org/ml/fortran/2012-04/msg00012.html
  Okayed but haven't found best wording.


 * * *

gfortran regression status:

- PR52916 - [4.8 Regression] 481.wrf in SPEC CPU 2006 failed to build
  Fixed - except for followup test-suite fix
- PR 52864 - [4.6/4.7/4.8 Regression] Assignment to pointer component ...
  rejects-valid. Approved patch, not yet committed.
  (Non regression issue: Patch submitted, pending review)
- PR 52679 - [4.6 Regression] ICE in gfortran 4.6.3, x86_64 
  ice-on-valid-code.
- PR 45586 - [4.8 Regression] ICE non-trivial conversion at assignment
  ice-checking (tree decl issue related to "restrict"ed pointers.)
- PR49791 - [4.5/4.6/4.7/4.8 Regression] Formatted namelist reads fai... 
  Special case remaining. Related to more serious namelist nonregression
  PR 51825 
- PR50981 - [4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL...
  Mostly fixed. Could consider skipping the backporting. Some non-regressions
  still have to be fixed.
- PR51520 - [4.6 Regression] ICE in gfortran 4.6.2, x86_64 
  ice-on-valid-code
- PR52062 - [4.6 regression] public generic name, specific functions ... 
  ice-on-valid-code 
- PR50410 - [4.6/4.7/4.8 Regression] ICE in record_reference 
  ice-on-invalid-code  Multiple data initialization, draft patch available
- PR50105. [4.6/4.7/4.8 Regression] I/O with g6.5 - wrong number of ... 
  wrong-code. Not a regression (according to J3, WG5 approval pending);
  missed diagnostic
- PR 52158 - Regression on character function with gfortran 4.7 
  No true regression. Bogusly rejects previously working character(len=:),
  but the support was shaky.
- PR 42954 - [4.5/4.6/4.7/4.8 regression] TARGET_*_CPP_BUILTINS issues...


Tobias

PS: I hope that I found all pending patches and correctly stated their status.

Re: Patch ping

[Richard Guenther]

On Mon, Jan 2, 2012 at 11:37 AM, Jakub Jelinek  wrote:
> Hi!
>
> http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01539.html
> PR driver/48306, P2
>  - libiberty fix for gcc driver to find paths even when
>    $PATH contains some gcc subdirectories
>
> http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01451.html
>  - the passes.c and reload1.c memory leak fixes (opts-common.c
>    already fixed)

This one is ok.

Thanks,
Richard.

>        Jakub

Re: Patch ping

[Richard Guenther]

On Tue, Jan 24, 2012 at 11:28 AM, Jakub Jelinek  wrote:
> Hi!
>
> I'd like to ping following patch:
>
> - http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00819.html
>  P2 option handling ICE with -Wp,-pie or -Wp,-shared

Ok.

Thanks,
Richard.

>        Jakub

Re: Patch ping

[Paolo Carlini]

On 02/03/2012 11:13 AM, Jakub Jelinek wrote:

- http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01492.html
   update libstdc++ baseline_symbols.txt for several targets

This is Ok (sorry for not telling you explicitly earlier)

Thanks,
Paolo.

Re: Patch ping

[Jan Hubicka]

> Hi!
> 
> I'd like to ping two patches:
> 
> - http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01335.html
>   PR debug/51950  P2
>   -gdwarf-4 -fdebug-types-section cloning bug
> 
> - http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00496.html
>   PR middle-end/51929 P1
>   cgraph verification failure with same body aliases and cloning

I am convinced I approved this in the PR. The patch is OK.
Thanks for looking ito it.

Honza
> 
>   Jakub

Re: Patch ping

[Richard Biener]

On Tue, 25 Jul 2017, Jakub Jelinek wrote:

> Hi!
> 
> I'd like to ping 2 patches:
> 
> - UBSAN -fsanitize=pointer-overflow support
>   - http://gcc.gnu.org/ml/gcc-patches/2017-06/msg01365.html

The probablility stuff might need updating?

Can you put the TYPE_PRECISION (sizetype) != POINTER_SIZE check
in option processing and inform people that pointer overflow sanitizing
is not done instead?

Where you handle DECL_BIT_FIELD_REPRESENTATIVE in 
maybe_instrument_pointer_overflow you could instead of building
a new COMPONENT_REF strip the bitfield ref and just remember
DECL_FIELD_OFFSET/BIT_OFFSET to be added to the get_inner_reference
result?  You don't seem to use 'size' anywhere.  You fail to allow
other handled components -- for no good reason?  You fail to handle
&MEM[ptr + CST] a canonical gimple invariant way of ptr +p CST,
the early out bitpos == 0 will cause non-instrumentation here.
(I'd just round down in the case of bitpos % BITS_PER_UNIT != 0)

Otherwise looks good.

> - noipa attribute addition
>  
>   http://gcc.gnu.org/ml/gcc-patches/2016-12/msg01501.html 
>  

Ok.

Thanks,
Richard.

Re: Patch ping

[Jakub Jelinek]

On Wed, Jul 26, 2017 at 12:34:10PM +0200, Richard Biener wrote:
> On Tue, 25 Jul 2017, Jakub Jelinek wrote:
> 
> > Hi!
> > 
> > I'd like to ping 2 patches:
> > 
> > - UBSAN -fsanitize=pointer-overflow support
> >   - http://gcc.gnu.org/ml/gcc-patches/2017-06/msg01365.html
> 
> The probablility stuff might need updating?

Yes, done in my copy.

> Can you put the TYPE_PRECISION (sizetype) != POINTER_SIZE check
> in option processing and inform people that pointer overflow sanitizing
> is not done instead?

That is problematic, because during the option processing sizetype
is NULL, it is set up only much later.  And that processing depends on
the options being finalized and backend initialized etc.
I guess I could emit a warning in the sanopt pass once or something.
Or do it very late in do_compile, after lang_dependent_init (we don't
handle any other option there though). 
But it is still just a theoretical case, because libubsan is supported
only on selected subset of targets and none of those have such weird
sizetype vs. pointer size setup.  And without libubsan, the only thing
one could do would be -fsanitize=undefined -fsanitize-undefined-trap-on-error
or -fsanitize=pointer-overflow -fsanitize-undefined-trap-on-error,
otherwise one would run into missing libubsan.

> Where you handle DECL_BIT_FIELD_REPRESENTATIVE in 
> maybe_instrument_pointer_overflow you could instead of building
> a new COMPONENT_REF strip the bitfield ref and just remember
> DECL_FIELD_OFFSET/BIT_OFFSET to be added to the get_inner_reference
> result?

That is not enough, the bitfield could be in variable length structure etc.
Furthermore, I need that COMPONENT_REF with the representative later
in the function, so that I can compute the ptr and base_addr.

>  You don't seem to use 'size' anywhere.

size I thought about but then decided not to do anything with it.
There are two cases, one is where there is no ADDR_EXPR and it actually
a memory reference.  
In that case in theory the size could be used, but it would need
to be used only for the positive offsets, so like:
if (off > 0) {
  if (ptr + off + size < ptr)
runtime_fail;
} else if (ptr + off > ptr)
  runtime_fail;
but when it is actually a memory reference, I suppose it will fail
at runtime anyway when performing such an access, so I think it is
unnecessary.  And for the ADDR_EXPR case, the size is irrelevant, we
are just taking address of the start of the object.

> You fail to allow other handled components -- for no good reason?

I was trying to have a quick bail out.  What other handled components might
be relevant?  I guess IMAGPART_EXPR.  For say BIT_FIELD_REF I don't think
I can
  tree ptr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (t)), t);

>  You fail to handle
> &MEM[ptr + CST] a canonical gimple invariant way of ptr +p CST,
> the early out bitpos == 0 will cause non-instrumentation here.

Guess I could use:
  if ((offset == NULL_TREE
   && bitpos == 0
   && (TREE_CODE (inner) != MEM_REF
   || integer_zerop (TREE_OPERAND (inner, 1
The rest of the code will handle it.

> (I'd just round down in the case of bitpos % BITS_PER_UNIT != 0)

But then the
  tree ptr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (t)), t);
won't work again.

> > - noipa attribute addition  
> >
> >   http://gcc.gnu.org/ml/gcc-patches/2016-12/msg01501.html   
> >
> 
> Ok.

Thanks, will retest it now.

Here is the -fsanitize=pointer-overflow patch untested, updated
for the probability and other stuff mentioned above.

Jakub
2017-07-26  Jakub Jelinek  

PR sanitizer/80998
* sanopt.c (pass_sanopt::execute): Handle IFN_UBSAN_PTR.
* tree-ssa-alias.c (call_may_clobber_ref_p_1): Likewise.
* flag-types.h (enum sanitize_code): Add SANITIZER_POINTER_OVERFLOW.
Or it into SANITIZER_UNDEFINED.
* ubsan.c: Include gimple-fold.h and varasm.h.
(ubsan_expand_ptr_ifn): New function.
(instrument_pointer_overflow): New function.
(maybe_instrument_pointer_overflow): New function.
(instrument_object_size): Formatting fix.
(pass_ubsan::execute): Call instrument_pointer_overflow
and maybe_instrument_pointer_overflow.
* internal-fn.c (expand_UBSAN_PTR): New function.
* ubsan.h (ubsan_expand_ptr_ifn): Declare.
* sanitizer.def (__ubsan_handle_pointer_overflow,
__ubsan_handle_pointer_overflow_abort): New builtins.
* tree-ssa-tail-merge.c (merge_stmts_p): Handle IFN_UBSAN_PTR.
* internal-fn.def (UBSAN_PTR): New internal function.
* opts.c (sanitizer_opts): Add pointer-overflow.
* lto-streamer-in.c (input_function): Handle IFN_UBSAN_PTR.
* fold-const.c (build_range_check): Compute pointer range check in

Re: Patch ping

[Richard Biener]

On Wed, 26 Jul 2017, Jakub Jelinek wrote:

> On Wed, Jul 26, 2017 at 12:34:10PM +0200, Richard Biener wrote:
> > On Tue, 25 Jul 2017, Jakub Jelinek wrote:
> > 
> > > Hi!
> > > 
> > > I'd like to ping 2 patches:
> > > 
> > > - UBSAN -fsanitize=pointer-overflow support
> > >   - http://gcc.gnu.org/ml/gcc-patches/2017-06/msg01365.html
> > 
> > The probablility stuff might need updating?
> 
> Yes, done in my copy.
> 
> > Can you put the TYPE_PRECISION (sizetype) != POINTER_SIZE check
> > in option processing and inform people that pointer overflow sanitizing
> > is not done instead?
> 
> That is problematic, because during the option processing sizetype
> is NULL, it is set up only much later.  And that processing depends on

Ah, ok - fine then as-is.

> the options being finalized and backend initialized etc.
> I guess I could emit a warning in the sanopt pass once or something.
> Or do it very late in do_compile, after lang_dependent_init (we don't
> handle any other option there though). 
> But it is still just a theoretical case, because libubsan is supported
> only on selected subset of targets and none of those have such weird
> sizetype vs. pointer size setup.  And without libubsan, the only thing
> one could do would be -fsanitize=undefined -fsanitize-undefined-trap-on-error
> or -fsanitize=pointer-overflow -fsanitize-undefined-trap-on-error,
> otherwise one would run into missing libubsan.
>
> > Where you handle DECL_BIT_FIELD_REPRESENTATIVE in 
> > maybe_instrument_pointer_overflow you could instead of building
> > a new COMPONENT_REF strip the bitfield ref and just remember
> > DECL_FIELD_OFFSET/BIT_OFFSET to be added to the get_inner_reference
> > result?
> 
> That is not enough, the bitfield could be in variable length structure etc.
> Furthermore, I need that COMPONENT_REF with the representative later
> in the function, so that I can compute the ptr and base_addr.

Ok.
 
> >  You don't seem to use 'size' anywhere.
> 
> size I thought about but then decided not to do anything with it.
> There are two cases, one is where there is no ADDR_EXPR and it actually
> a memory reference.  
> In that case in theory the size could be used, but it would need
> to be used only for the positive offsets, so like:
> if (off > 0) {
>   if (ptr + off + size < ptr)
> runtime_fail;
> } else if (ptr + off > ptr)
>   runtime_fail;
> but when it is actually a memory reference, I suppose it will fail
> at runtime anyway when performing such an access, so I think it is
> unnecessary.  And for the ADDR_EXPR case, the size is irrelevant, we
> are just taking address of the start of the object.
> 
> > You fail to allow other handled components -- for no good reason?
> 
> I was trying to have a quick bail out.  What other handled components might
> be relevant?  I guess IMAGPART_EXPR.  For say BIT_FIELD_REF I don't think
> I can
>   tree ptr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (t)), t);

REALPART/IMAGPART_EXPR, yes.  You can't address BIT_FIELD_REF
apart those on byte boundary (&vector[4] is eventually folded to
a BIT_FIELD_REF).  Similar for VIEW_CONVERT_EXPR, but you are
only building the address on the base?

> >  You fail to handle
> > &MEM[ptr + CST] a canonical gimple invariant way of ptr +p CST,
> > the early out bitpos == 0 will cause non-instrumentation here.
> 
> Guess I could use:
>   if ((offset == NULL_TREE
>&& bitpos == 0
>&& (TREE_CODE (inner) != MEM_REF
>  || integer_zerop (TREE_OPERAND (inner, 1
> The rest of the code will handle it.

Yeah.

> 
> > (I'd just round down in the case of bitpos % BITS_PER_UNIT != 0)
> 
> But then the
>   tree ptr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (t)), t);
> won't work again.

Hmm.  So instead of building the address on the original tree you
could build the difference based on what get_inner_reference returns
in bitpos/offset?

> > > - noipa attribute addition
> > >  
> > >   http://gcc.gnu.org/ml/gcc-patches/2016-12/msg01501.html 
> > >  
> > 
> > Ok.
> 
> Thanks, will retest it now.
> 
> Here is the -fsanitize=pointer-overflow patch untested, updated
> for the probability and other stuff mentioned above.
> 
>   Jakub
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: Patch ping

[Jakub Jelinek]

On Wed, Jul 26, 2017 at 04:13:30PM +0200, Richard Biener wrote:
> > >  You don't seem to use 'size' anywhere.
> > 
> > size I thought about but then decided not to do anything with it.
> > There are two cases, one is where there is no ADDR_EXPR and it actually
> > a memory reference.  
> > In that case in theory the size could be used, but it would need
> > to be used only for the positive offsets, so like:
> > if (off > 0) {
> >   if (ptr + off + size < ptr)
> > runtime_fail;
> > } else if (ptr + off > ptr)
> >   runtime_fail;
> > but when it is actually a memory reference, I suppose it will fail
> > at runtime anyway when performing such an access, so I think it is
> > unnecessary.  And for the ADDR_EXPR case, the size is irrelevant, we
> > are just taking address of the start of the object.
> > 
> > > You fail to allow other handled components -- for no good reason?
> > 
> > I was trying to have a quick bail out.  What other handled components might
> > be relevant?  I guess IMAGPART_EXPR.  For say BIT_FIELD_REF I don't think
> > I can
> >   tree ptr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (t)), t);
> 
> REALPART/IMAGPART_EXPR, yes.  You can't address BIT_FIELD_REF
> apart those on byte boundary (&vector[4] is eventually folded to
> a BIT_FIELD_REF).  Similar for VIEW_CONVERT_EXPR, but you are
> only building the address on the base?
> 
> > >  You fail to handle
> > > &MEM[ptr + CST] a canonical gimple invariant way of ptr +p CST,
> > > the early out bitpos == 0 will cause non-instrumentation here.
> > 
> > Guess I could use:
> >   if ((offset == NULL_TREE
> >&& bitpos == 0
> >&& (TREE_CODE (inner) != MEM_REF
> >|| integer_zerop (TREE_OPERAND (inner, 1
> > The rest of the code will handle it.
> 
> Yeah.
> 
> > 
> > > (I'd just round down in the case of bitpos % BITS_PER_UNIT != 0)
> > 
> > But then the
> >   tree ptr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (t)), t);
> > won't work again.
> 
> Hmm.  So instead of building the address on the original tree you
> could build the difference based on what get_inner_reference returns
> in bitpos/offset?

I'm building both addresses and subtracting them to get the offset.
I guess the other option is to compute just the address of the base
(i.e. base_addr), and add offset (if non-NULL) plus bitpos / BITS_PER_UNIT
plus offset from the MEM_REF (if any).  In that case it would probably
handle any handled_component_p and bitfields too.

Jakub

Re: Patch ping

[Richard Biener]

On Wed, 26 Jul 2017, Jakub Jelinek wrote:

> On Wed, Jul 26, 2017 at 04:13:30PM +0200, Richard Biener wrote:
> > > >  You don't seem to use 'size' anywhere.
> > > 
> > > size I thought about but then decided not to do anything with it.
> > > There are two cases, one is where there is no ADDR_EXPR and it actually
> > > a memory reference.  
> > > In that case in theory the size could be used, but it would need
> > > to be used only for the positive offsets, so like:
> > > if (off > 0) {
> > >   if (ptr + off + size < ptr)
> > > runtime_fail;
> > > } else if (ptr + off > ptr)
> > >   runtime_fail;
> > > but when it is actually a memory reference, I suppose it will fail
> > > at runtime anyway when performing such an access, so I think it is
> > > unnecessary.  And for the ADDR_EXPR case, the size is irrelevant, we
> > > are just taking address of the start of the object.
> > > 
> > > > You fail to allow other handled components -- for no good reason?
> > > 
> > > I was trying to have a quick bail out.  What other handled components 
> > > might
> > > be relevant?  I guess IMAGPART_EXPR.  For say BIT_FIELD_REF I don't think
> > > I can
> > >   tree ptr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (t)), t);
> > 
> > REALPART/IMAGPART_EXPR, yes.  You can't address BIT_FIELD_REF
> > apart those on byte boundary (&vector[4] is eventually folded to
> > a BIT_FIELD_REF).  Similar for VIEW_CONVERT_EXPR, but you are
> > only building the address on the base?
> > 
> > > >  You fail to handle
> > > > &MEM[ptr + CST] a canonical gimple invariant way of ptr +p CST,
> > > > the early out bitpos == 0 will cause non-instrumentation here.
> > > 
> > > Guess I could use:
> > >   if ((offset == NULL_TREE
> > >&& bitpos == 0
> > >&& (TREE_CODE (inner) != MEM_REF
> > >  || integer_zerop (TREE_OPERAND (inner, 1
> > > The rest of the code will handle it.
> > 
> > Yeah.
> > 
> > > 
> > > > (I'd just round down in the case of bitpos % BITS_PER_UNIT != 0)
> > > 
> > > But then the
> > >   tree ptr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (t)), t);
> > > won't work again.
> > 
> > Hmm.  So instead of building the address on the original tree you
> > could build the difference based on what get_inner_reference returns
> > in bitpos/offset?
> 
> I'm building both addresses and subtracting them to get the offset.
> I guess the other option is to compute just the address of the base
> (i.e. base_addr), and add offset (if non-NULL) plus bitpos / BITS_PER_UNIT
> plus offset from the MEM_REF (if any).  In that case it would probably
> handle any handled_component_p and bitfields too.

Yes.  Can you try sth along this route?  Should be a matter of
adding offset and bitpos / BITS_PER_UNIT (thus rounded down) plus
any MEM_REF offset on the base.

Thanks,
Richard.

Re: Patch ping

[Jakub Jelinek]

On Thu, Jul 27, 2017 at 09:19:34AM +0200, Richard Biener wrote:
> > I'm building both addresses and subtracting them to get the offset.
> > I guess the other option is to compute just the address of the base
> > (i.e. base_addr), and add offset (if non-NULL) plus bitpos / BITS_PER_UNIT
> > plus offset from the MEM_REF (if any).  In that case it would probably
> > handle any handled_component_p and bitfields too.
> 
> Yes.  Can you try sth along this route?  Should be a matter of
> adding offset and bitpos / BITS_PER_UNIT (thus rounded down) plus
> any MEM_REF offset on the base.

Here it is, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2017-07-27  Jakub Jelinek  

PR sanitizer/80998
* sanopt.c (pass_sanopt::execute): Handle IFN_UBSAN_PTR.
* tree-ssa-alias.c (call_may_clobber_ref_p_1): Likewise.
* flag-types.h (enum sanitize_code): Add SANITIZER_POINTER_OVERFLOW.
Or it into SANITIZER_UNDEFINED.
* ubsan.c: Include gimple-fold.h and varasm.h.
(ubsan_expand_ptr_ifn): New function.
(instrument_pointer_overflow): New function.
(maybe_instrument_pointer_overflow): New function.
(instrument_object_size): Formatting fix.
(pass_ubsan::execute): Call instrument_pointer_overflow
and maybe_instrument_pointer_overflow.
* internal-fn.c (expand_UBSAN_PTR): New function.
* ubsan.h (ubsan_expand_ptr_ifn): Declare.
* sanitizer.def (__ubsan_handle_pointer_overflow,
__ubsan_handle_pointer_overflow_abort): New builtins.
* tree-ssa-tail-merge.c (merge_stmts_p): Handle IFN_UBSAN_PTR.
* internal-fn.def (UBSAN_PTR): New internal function.
* opts.c (sanitizer_opts): Add pointer-overflow.
* lto-streamer-in.c (input_function): Handle IFN_UBSAN_PTR.
* fold-const.c (build_range_check): Compute pointer range check in
integral type if pointer arithmetics would be needed.  Formatting
fixes.
gcc/testsuite/
* c-c++-common/ubsan/ptr-overflow-1.c: New test.
* c-c++-common/ubsan/ptr-overflow-2.c: New test.
libsanitizer/
* ubsan/ubsan_handlers.cc: Cherry-pick upstream r304461.
* ubsan/ubsan_checks.inc: Likewise.
* ubsan/ubsan_handlers.h: Likewise.

--- gcc/sanopt.c.jj 2017-07-04 13:51:47.781815329 +0200
+++ gcc/sanopt.c2017-07-26 13:44:13.833204640 +0200
@@ -1062,6 +1062,9 @@ pass_sanopt::execute (function *fun)
case IFN_UBSAN_OBJECT_SIZE:
  no_next = ubsan_expand_objsize_ifn (&gsi);
  break;
+   case IFN_UBSAN_PTR:
+ no_next = ubsan_expand_ptr_ifn (&gsi);
+ break;
case IFN_UBSAN_VPTR:
  no_next = ubsan_expand_vptr_ifn (&gsi);
  break;
--- gcc/tree-ssa-alias.c.jj 2017-06-19 08:26:17.274597722 +0200
+++ gcc/tree-ssa-alias.c2017-07-26 13:44:13.834204628 +0200
@@ -1991,6 +1991,7 @@ call_may_clobber_ref_p_1 (gcall *call, a
   case IFN_UBSAN_BOUNDS:
   case IFN_UBSAN_VPTR:
   case IFN_UBSAN_OBJECT_SIZE:
+  case IFN_UBSAN_PTR:
   case IFN_ASAN_CHECK:
return false;
   default:
--- gcc/flag-types.h.jj 2017-06-19 08:26:17.593593662 +0200
+++ gcc/flag-types.h2017-07-26 13:44:13.834204628 +0200
@@ -238,6 +238,7 @@ enum sanitize_code {
   SANITIZE_OBJECT_SIZE = 1UL << 21,
   SANITIZE_VPTR = 1UL << 22,
   SANITIZE_BOUNDS_STRICT = 1UL << 23,
+  SANITIZE_POINTER_OVERFLOW = 1UL << 24,
   SANITIZE_SHIFT = SANITIZE_SHIFT_BASE | SANITIZE_SHIFT_EXPONENT,
   SANITIZE_UNDEFINED = SANITIZE_SHIFT | SANITIZE_DIVIDE | SANITIZE_UNREACHABLE
   | SANITIZE_VLA | SANITIZE_NULL | SANITIZE_RETURN
@@ -245,7 +246,8 @@ enum sanitize_code {
   | SANITIZE_BOUNDS | SANITIZE_ALIGNMENT
   | SANITIZE_NONNULL_ATTRIBUTE
   | SANITIZE_RETURNS_NONNULL_ATTRIBUTE
-  | SANITIZE_OBJECT_SIZE | SANITIZE_VPTR,
+  | SANITIZE_OBJECT_SIZE | SANITIZE_VPTR
+  | SANITIZE_POINTER_OVERFLOW,
   SANITIZE_UNDEFINED_NONDEFAULT = SANITIZE_FLOAT_DIVIDE | SANITIZE_FLOAT_CAST
  | SANITIZE_BOUNDS_STRICT
 };
--- gcc/ubsan.c.jj  2017-06-30 09:49:32.306609364 +0200
+++ gcc/ubsan.c 2017-07-26 20:22:34.718284238 +0200
@@ -45,6 +45,8 @@ along with GCC; see the file COPYING3.
 #include "builtins.h"
 #include "tree-object-size.h"
 #include "tree-cfg.h"
+#include "gimple-fold.h"
+#include "varasm.h"
 
 /* Map from a tree to a VAR_DECL tree.  */
 
@@ -1029,6 +1031,170 @@ ubsan_expand_objsize_ifn (gimple_stmt_it
   return true;
 }
 
+/* Expand UBSAN_PTR internal call.  */
+
+bool
+ubsan_expand_ptr_ifn (gimple_stmt_iterator *gsip)
+{
+  gimple_stmt_iterator gsi = *gsip;
+  gimple *stmt = gsi_stmt (gsi);
+  location_t loc = gimple_location (stmt);
+  gcc_assert (gimple_call_num_args (stmt) == 2);
+  tree ptr = gim

Re: Patch ping

[Richard Biener]

On Thu, 27 Jul 2017, Jakub Jelinek wrote:

> On Thu, Jul 27, 2017 at 09:19:34AM +0200, Richard Biener wrote:
> > > I'm building both addresses and subtracting them to get the offset.
> > > I guess the other option is to compute just the address of the base
> > > (i.e. base_addr), and add offset (if non-NULL) plus bitpos / BITS_PER_UNIT
> > > plus offset from the MEM_REF (if any).  In that case it would probably
> > > handle any handled_component_p and bitfields too.
> > 
> > Yes.  Can you try sth along this route?  Should be a matter of
> > adding offset and bitpos / BITS_PER_UNIT (thus rounded down) plus
> > any MEM_REF offset on the base.
> 
> Here it is, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?

Ok.

Thanks,
Richard.

> 2017-07-27  Jakub Jelinek  
> 
>   PR sanitizer/80998
>   * sanopt.c (pass_sanopt::execute): Handle IFN_UBSAN_PTR.
>   * tree-ssa-alias.c (call_may_clobber_ref_p_1): Likewise.
>   * flag-types.h (enum sanitize_code): Add SANITIZER_POINTER_OVERFLOW.
>   Or it into SANITIZER_UNDEFINED.
>   * ubsan.c: Include gimple-fold.h and varasm.h.
>   (ubsan_expand_ptr_ifn): New function.
>   (instrument_pointer_overflow): New function.
>   (maybe_instrument_pointer_overflow): New function.
>   (instrument_object_size): Formatting fix.
>   (pass_ubsan::execute): Call instrument_pointer_overflow
>   and maybe_instrument_pointer_overflow.
>   * internal-fn.c (expand_UBSAN_PTR): New function.
>   * ubsan.h (ubsan_expand_ptr_ifn): Declare.
>   * sanitizer.def (__ubsan_handle_pointer_overflow,
>   __ubsan_handle_pointer_overflow_abort): New builtins.
>   * tree-ssa-tail-merge.c (merge_stmts_p): Handle IFN_UBSAN_PTR.
>   * internal-fn.def (UBSAN_PTR): New internal function.
>   * opts.c (sanitizer_opts): Add pointer-overflow.
>   * lto-streamer-in.c (input_function): Handle IFN_UBSAN_PTR.
>   * fold-const.c (build_range_check): Compute pointer range check in
>   integral type if pointer arithmetics would be needed.  Formatting
>   fixes.
> gcc/testsuite/
>   * c-c++-common/ubsan/ptr-overflow-1.c: New test.
>   * c-c++-common/ubsan/ptr-overflow-2.c: New test.
> libsanitizer/
>   * ubsan/ubsan_handlers.cc: Cherry-pick upstream r304461.
>   * ubsan/ubsan_checks.inc: Likewise.
>   * ubsan/ubsan_handlers.h: Likewise.
> 
> --- gcc/sanopt.c.jj   2017-07-04 13:51:47.781815329 +0200
> +++ gcc/sanopt.c  2017-07-26 13:44:13.833204640 +0200
> @@ -1062,6 +1062,9 @@ pass_sanopt::execute (function *fun)
>   case IFN_UBSAN_OBJECT_SIZE:
> no_next = ubsan_expand_objsize_ifn (&gsi);
> break;
> + case IFN_UBSAN_PTR:
> +   no_next = ubsan_expand_ptr_ifn (&gsi);
> +   break;
>   case IFN_UBSAN_VPTR:
> no_next = ubsan_expand_vptr_ifn (&gsi);
> break;
> --- gcc/tree-ssa-alias.c.jj   2017-06-19 08:26:17.274597722 +0200
> +++ gcc/tree-ssa-alias.c  2017-07-26 13:44:13.834204628 +0200
> @@ -1991,6 +1991,7 @@ call_may_clobber_ref_p_1 (gcall *call, a
>case IFN_UBSAN_BOUNDS:
>case IFN_UBSAN_VPTR:
>case IFN_UBSAN_OBJECT_SIZE:
> +  case IFN_UBSAN_PTR:
>case IFN_ASAN_CHECK:
>   return false;
>default:
> --- gcc/flag-types.h.jj   2017-06-19 08:26:17.593593662 +0200
> +++ gcc/flag-types.h  2017-07-26 13:44:13.834204628 +0200
> @@ -238,6 +238,7 @@ enum sanitize_code {
>SANITIZE_OBJECT_SIZE = 1UL << 21,
>SANITIZE_VPTR = 1UL << 22,
>SANITIZE_BOUNDS_STRICT = 1UL << 23,
> +  SANITIZE_POINTER_OVERFLOW = 1UL << 24,
>SANITIZE_SHIFT = SANITIZE_SHIFT_BASE | SANITIZE_SHIFT_EXPONENT,
>SANITIZE_UNDEFINED = SANITIZE_SHIFT | SANITIZE_DIVIDE | 
> SANITIZE_UNREACHABLE
>  | SANITIZE_VLA | SANITIZE_NULL | SANITIZE_RETURN
> @@ -245,7 +246,8 @@ enum sanitize_code {
>  | SANITIZE_BOUNDS | SANITIZE_ALIGNMENT
>  | SANITIZE_NONNULL_ATTRIBUTE
>  | SANITIZE_RETURNS_NONNULL_ATTRIBUTE
> -| SANITIZE_OBJECT_SIZE | SANITIZE_VPTR,
> +| SANITIZE_OBJECT_SIZE | SANITIZE_VPTR
> +| SANITIZE_POINTER_OVERFLOW,
>SANITIZE_UNDEFINED_NONDEFAULT = SANITIZE_FLOAT_DIVIDE | SANITIZE_FLOAT_CAST
> | SANITIZE_BOUNDS_STRICT
>  };
> --- gcc/ubsan.c.jj2017-06-30 09:49:32.306609364 +0200
> +++ gcc/ubsan.c   2017-07-26 20:22:34.718284238 +0200
> @@ -45,6 +45,8 @@ along with GCC; see the file COPYING3.
>  #include "builtins.h"
>  #include "tree-object-size.h"
>  #include "tree-cfg.h"
> +#include "gimple-fold.h"
> +#include "varasm.h"
>  
>  /* Map from a tree to a VAR_DECL tree.  */
>  
> @@ -1029,6 +1031,170 @@ ubsan_expand_objsize_ifn (gimple_stmt_it
>return true;
>  }
>  
> +/* Expand UBSAN_PTR internal call.  */
> +
> +bool
> +ubsan_expand_ptr_ifn (gimple_stmt_iterator *

ARM Patch Ping

[Bernd Edlinger]

Hi,

I would like to kindly remind you of the following patches,
which are already waiting for over 6 months:

[PATCH, ARM] correctly encode the CC reg data flow
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01351.html

[PATCH, ARM] Further improve stack usage in sha512 (PR 77308)
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01567.html

[PATCH, ARM] Further improve stack usage in sha512, part 2 (PR 77308)
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01568.html


I boot-strapped and reg-tested the patches on last week's snapshot to
verify they still apply.


Thanks
Bernd.

Re: Patch ping

[Richard Biener]

On Thu, 2 Feb 2017, Jakub Jelinek wrote:

> Hi!
> 
> I'd like to ping the
> http://gcc.gnu.org/ml/gcc-patches/2017-01/msg02026.html
> patch, asan testsuite fixes not to use explicit -O* options
> in testsuite that iterates over all -O*, but instead dg-skip-if
> etc.
> 
> As discussed later in the thread, either as is for pr69276.C:
> -/* { dg-additional-options "-O0 -fno-lto" } */
> +/* { dg-skip-if "" { *-*-* }  { "*" } { "-O0" } } */
> +/* { dg-additional-options "-fno-lto" } */
> or just:
> -/* { dg-additional-options "-O0 -fno-lto" } */
> +/* { dg-skip-if "" { *-*-* }  { "*" } { "-O0" } } */

Ok with this variant.

Richard.

> or:
> -/* { dg-additional-options "-O0 -fno-lto" } */
> +/* { dg-skip-if "" { *-*-* } { "*" } { "-O0" } } */
> +/* { dg-skip-if "" { *-*-* } { "-flto" } { "" } } */
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 2 C++ patches:

- P1 PR79232 - ICEs and wrong-code with COMPOUND_EXPR on lhs of assignment
  http://gcc.gnu.org/ml/gcc-patches/2017-01/msg02341.html

- P1 PR79288 - wrong default TLS model for __thread static data members
  http://gcc.gnu.org/ml/gcc-patches/2017-01/msg02349.html

Thanks

Jakub

Re: Patch ping

[Uros Bizjak]

On Tue, Feb 7, 2017 at 4:11 PM, Jakub Jelinek  wrote:
> Hi!
>
> I'd like to ping:
>
> - P1 PR79299 AVX512{F,VL} -masm=intel v*gather* fixes
>   http://gcc.gnu.org/ml/gcc-patches/2017-01/msg02409.html

LGTM.

Thanks,
Uros.

Patch ping^2

[Jakub Jelinek]

Hi!

I'd like to ping a couple of patches:

- C++ P1 PR79232 - ICEs and wrong-code with COMPOUND_EXPR on lhs of assignment
  http://gcc.gnu.org/ml/gcc-patches/2017-01/msg02341.html

- C++ P1 PR79288 - wrong default TLS model for __thread static data members
  http://gcc.gnu.org/ml/gcc-patches/2017-01/msg02349.html

- small simplification for gimple-ssa-sprintf.c
  http://gcc.gnu.org/ml/gcc-patches/2017-02/msg00331.html

- noipa attribute addition
  http://gcc.gnu.org/ml/gcc-patches/2016-12/msg01501.html

Jakub

OpenACC Patch Ping

[Cesar Philippidis]

The following patches still need to be reviewed.

ACC ROUTINE patches:

Re: [PATCH] OpenACC routines -- c++ front end


Re: [PATCH] OpenACC routines -- middle end


Re: [PATCH] OpenACC routines -- fortran front end


ACC TILE patch:

Re: [Patch 4/5] OpenACC tile clause support, Fortran front-end parts


Cesar

C++ Patch Ping

[Jakub Jelinek]

Hi!

I'd like to ping the

http://gcc.gnu.org/ml/gcc-patches/2016-12/msg00698.html
P0490R0 GB 20: decomposition declaration should commit to tuple interpretation 
early 

patch.

Thanks

Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the PR77830 fix for out of bounds constexpr stores:
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01319.html

Jakub

Re: Patch ping

[Nathan Sidwell]

On 10/06/2017 10:12 AM, Jakub Jelinek wrote:

Hi!

I'd like to ping a couple of patches:

http://gcc.gnu.org/ml/gcc-patches/2017-09/msg01237.html
   C++2a P0704R1 - fixing const-qualified pointers to members


ok, thanks


--
Nathan Sidwell

Re: Patch ping

[Nathan Sidwell]

On 10/06/2017 10:12 AM, Jakub Jelinek wrote:

Hi!

I'd like to ping a couple of patches:




http://gcc.gnu.org/ml/gcc-patches/2017-09/msg02006.html
   PR c++/82299 - invalid -Wuseless-cast on direct enum init


Agreed, ok, thanks.

nathan

--
Nathan Sidwell

Patch ping^3

[Jakub Jelinek]

Hi!

I'd like to ping the following wrong-code patch:

http://gcc.gnu.org/ml/gcc-patches/2017-09/msg01540.html 
   
  libgcc __mulvDI3 fix - missed detection of overflow for   
   
  0x * 0x   
   
  __builtin_mul_overflow{,_p} fix for the same  
   

   
Thanks  
   

Jakub

Re: Patch ping

[Kirill Yukhin]

Hello Jakub,
On 24 Oct 13:01, Jakub Jelinek wrote:
> http://gcc.gnu.org/ml/gcc-patches/2017-10/msg00525.html
>   PR target/82460 - improve AVX512* vperm[ti]2*
>   Kyrill, can you please review this one?
Your patch is OK for trunk.

--
Thanks, K
> 
> Thanks
> 
>   Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the
  http://gcc.gnu.org/ml/gcc-patches/2017-09/msg00937.html
  - fix compile time hog in replace_placeholders
patch.

Thanks

Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 2 C++2A patches:
  http://gcc.gnu.org/ml/gcc-patches/2017-09/msg01235.html
P0683R1 - default member initializers for bit-fields

  http://gcc.gnu.org/ml/gcc-patches/2017-09/msg01237.html
P0704R1 - fixing const-qualified pointers to members

Thanks

Jakub