Patch ping

Patch ping

[Jakub Jelinek]

Hi!

- PR middle-end/37316
  RTL fix for assign_parm_remove_parallels 4.4 regression
  http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00982.html

- PR rtl-optimization/36998
  Dwarf2 DW_CFA_GNU_args_size fixes
  http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01322.html

- PR target/37170
  RTL/target fix for arm (and xtensa in followup) missing
  assemble_external calls
  http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00063.html

	Jakub

Re: Patch ping

[Nick Clifton]

Hi Jakub,

> - PR target/37170
>   RTL/target fix for arm (and xtensa in followup) missing
>   assemble_external calls
>   http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00063.html

This patch is approved for the ARM.

Cheers
   Nick

Re: Patch ping

[Ian Lance Taylor]

Jakub Jelinek <jakub@redhat.com> writes:

> - PR middle-end/37316
>   RTL fix for assign_parm_remove_parallels 4.4 regression
>   http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00982.html

This is OK.

Thanks.

Ian

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the C23 #embed patchset:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655012.html                                                                                                                       
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655013.html                                                                                                                       
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657049.html                                                                                                                       
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657053.html

Thanks

	Jakub

Re: Patch ping

[Segher Boessenkool]

On Mon, Jun 17, 2024 at 03:26:52PM +0200, Jakub Jelinek wrote:
> I'd like to ping the
> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653573.html
> patch.  While the committed and backported patch fixed PCH on PIE
> cc1/cc1plus etc. on PowerPC, it grew up the size of the
> rs6000_init_generated_builtins function quite a lot.
> The above patch decreases it back, to even less than the size of
> the function before my fix.

A patch in the middle of a thread.  I missed it, sorry.  Please send
patches as separate threads?


Segher

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653573.html
patch.  While the committed and backported patch fixed PCH on PIE
cc1/cc1plus etc. on PowerPC, it grew up the size of the
rs6000_init_generated_builtins function quite a lot.
The above patch decreases it back, to even less than the size of
the function before my fix.

	Jakub

Re: Patch ping

[Jeff Law]

On 2/9/24 02:44, Jakub Jelinek wrote:

> 
> https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644701.html
> Introduce HOST_SIZE_T_PRINT_UNSIGNED etc. macros to fix LLP64 host build issue
> 
> Both have been successfully bootstrapped/regtested on x86_64-linux and
> i686-linux, the latter has been tested by Jonathan on Windows too.
> The alternative is start using %zu (AFAIK we only do that in libgccjit which
> isn't supported everywhere and while it is C99, not sure if all supported
> host C libraries support it), or change ira-conflicts.cc to
> --- gcc/ira-conflicts.cc	2024-02-01 21:03:57.339193085 +0100
> +++ gcc/ira-conflicts.cc	2024-02-09 10:41:39.201150644 +0100
> @@ -151,8 +151,8 @@ build_conflict_bit_table (void)
>       fprintf
>         (ira_dump_file,
>          "+++Allocating %ld bytes for conflict table (uncompressed size %ld)\n",
> -       (long) allocated_words_num * sizeof (IRA_INT_TYPE),
> -       (long) object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE));
> +       (long) (allocated_words_num * sizeof (IRA_INT_TYPE)),
> +       (long) (object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE)));
>   
>     objects_live = sparseset_alloc (ira_objects_num);
>     for (i = 0; i < ira_max_point; i++)
> Note, we have many more cases where we use %ld or %lu to print
> size_t values (ideally %zd/%zu if we can assume it on all hosts, or
> with the above introduced HOST_SIZE_T_PRINT*, the problem with the
> %ld/%lu and casts is that it truncates the values on LLP64 hosts (aka
> %Windows).
While I'd love to be able to use %z, I suspect it's going to be 
problematical.  That's one of the cleanups I need to have Mariam do on 
the CRC code which uses %z extensively in its debugging dumps.

So let's assume %z is a no-go for now.

Having a HOST_SIZE_T_PRINT_UNSIGNED seems useful, so I'd tend to prefer 
we go with that solution from the URL above rather than just throwing 
some parens around the expression before casting the result to "long".

jeff

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 2 patches:

https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644580.html
PR113617 P1 - Handle private COMDAT function symbol reference in readonly data section

More details in the
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/thread.html#644121
and
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/thread.html#644486
threads.

and

https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644701.html
Introduce HOST_SIZE_T_PRINT_UNSIGNED etc. macros to fix LLP64 host build issue

Both have been successfully bootstrapped/regtested on x86_64-linux and
i686-linux, the latter has been tested by Jonathan on Windows too.
The alternative is start using %zu (AFAIK we only do that in libgccjit which
isn't supported everywhere and while it is C99, not sure if all supported
host C libraries support it), or change ira-conflicts.cc to
--- gcc/ira-conflicts.cc	2024-02-01 21:03:57.339193085 +0100
+++ gcc/ira-conflicts.cc	2024-02-09 10:41:39.201150644 +0100
@@ -151,8 +151,8 @@ build_conflict_bit_table (void)
     fprintf
       (ira_dump_file,
        "+++Allocating %ld bytes for conflict table (uncompressed size %ld)\n",
-       (long) allocated_words_num * sizeof (IRA_INT_TYPE),
-       (long) object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE));
+       (long) (allocated_words_num * sizeof (IRA_INT_TYPE)),
+       (long) (object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE)));
 
   objects_live = sparseset_alloc (ira_objects_num);
   for (i = 0; i < ira_max_point; i++)
Note, we have many more cases where we use %ld or %lu to print
size_t values (ideally %zd/%zu if we can assume it on all hosts, or
with the above introduced HOST_SIZE_T_PRINT*, the problem with the
%ld/%lu and casts is that it truncates the values on LLP64 hosts (aka
%Windows).

	Jakub

Re: Patch ping

[Joseph Myers]

On Wed, 1 Mar 2023, Jakub Jelinek via Gcc-patches wrote:

> Hi!
> 
> I'd like to ping a few pending patches:
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607534.html
>   - PR107846 - P1 - c-family: Account for integral promotions of left shifts for -Wshift-overflow warning

OK.

> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606973.html
>   - PR107465 - P2 - c-family: Fix up -Wsign-compare BIT_NOT_EXPR handling

OK.

> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607104.html
>   - PR107465 - P2 - c-family: Incremental fix for -Wsign-compare BIT_NOT_EXPR handling

OK.

-- 
Joseph S. Myers
joseph@codesourcery.com

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping a few pending patches:

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607534.html
  - PR107846 - P1 - c-family: Account for integral promotions of left shifts for -Wshift-overflow warning

https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610285.html
  - PR108464 - P1 - file-prefix-map: Fix up -f*-prefix-map= (3 variants)

https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611647.html
  - PR108702 - P1 - c++: Don't defer local statics initialized with constant expressions

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606382.html
  - PR107703 - P3, ABI - libgcc, i386: Add __fix{,uns}bfti and __float{,un}tibf

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606973.html
  - PR107465 - P2 - c-family: Fix up -Wsign-compare BIT_NOT_EXPR handling

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607104.html
  - PR107465 - P2 - c-family: Incremental fix for -Wsign-compare BIT_NOT_EXPR handling

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607145.html
  - PR107558 - P2 - c++: Don't clear TREE_READONLY for -fmerge-all-constants for non-aggregates

https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608932.html
  - PR108079 - P2 - c, c++, cgraphunit: Prevent duplicated -Wunused-value warnings

https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611615.html
  - PR108716 - P2 - c++, debug: Fix up locus of DW_TAG_imported_module

https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611180.html
  - PR108634 - P3 - tree: Use comdat tree_code_{type,length} even for C++11/14

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605965.html
  - ABI - aarch64: Add bfloat16_t support for aarch64 (enabling it in GCC 14
    will be harder)

https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612342.html
  - libstdc++: Some baseline_symbols.txt updates

Thanks

	Jakub

Patch ping

[Jakub Jelinek]

I'd like to ping a few pending patches:

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607534.html
  - PR107846 - P1 - c-family: Account for integral promotions of left shifts for -Wshift-overflow warning

https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610285.html
  - PR108464 - P1 - file-prefix-map: Fix up -f*-prefix-map= (3 variants)

https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611647.html
  - PR108702 - P1 - c++: Don't defer local statics initialized with constant expressions

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606382.html
  - PR107703 - P3, ABI - libgcc, i386: Add __fix{,uns}bfti and __float{,un}tibf

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606973.html
  - PR107465 - P2 - c-family: Fix up -Wsign-compare BIT_NOT_EXPR handling

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607104.html
  - PR107465 - P2 - c-family: Incremental fix for -Wsign-compare BIT_NOT_EXPR handling

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607145.html
  - PR107558 - P2 - c++: Don't clear TREE_READONLY for -fmerge-all-constants for non-aggregates

https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608932.html
  - PR108079 - P2 - c, c++, cgraphunit: Prevent duplicated -Wunused-value warnings

https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611615.html
  - PR108716 - P2 - c++, debug: Fix up locus of DW_TAG_imported_module

https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611180.html
  - PR108634 - P3 - tree: Use comdat tree_code_{type,length} even for C++11/14

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605965.html
  - ABI - aarch64: Add bfloat16_t support for aarch64 (enabling it in GCC 14
    will be harder)

Thanks

	Jakub

Re: Patch ping

[Richard Sandiford]

Jakub Jelinek <jakub@redhat.com> writes:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605965.html
>   - ABI - aarch64: Add bfloat16_t support for aarch64 (enabling it in GCC 14
>     will be harder)

Sorry for the delay on this.  There's still an ongoing debate about
whether to keep the current AArch64 mangling or switch to the new one.

Thanks,
Richard

Patch ping

[Jakub Jelinek]

I'd like to ping a few pending patches:

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607534.html
  - PR107846 - P1 - c-family: Account for integral promotions of left shifts for -Wshift-overflow warning

https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610285.html
  - PR108464 - P1 - file-prefix-map: Fix up -f*-prefix-map= (3 variants)

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606382.html
  - PR107703 - P3, ABI - libgcc, i386: Add __fix{,uns}bfti and __float{,un}tibf

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606973.html
  - PR107465 - P2 - c-family: Fix up -Wsign-compare BIT_NOT_EXPR handling

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607104.html
  - PR107465 - P2 - c-family: Incremental fix for -Wsign-compare BIT_NOT_EXPR handling

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607145.html
  - PR107558 - P2 - c++: Don't clear TREE_READONLY for -fmerge-all-constants for non-aggregates

https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608932.html
  - PR108079 - P2 - c, c++, cgraphunit: Prevent duplicated -Wunused-value warnings

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605965.html
  - ABI - aarch64: Add bfloat16_t support for aarch64 (enabling it in GCC 14
    will be harder)

Thanks

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping a few pending patches:

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606973.html
  - PR107465 - c-family: Fix up -Wsign-compare BIT_NOT_EXPR handling

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607104.html
  - PR107465 - c-family: Incremental fix for -Wsign-compare BIT_NOT_EXPR handling

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607145.html
  - PR107558 - c++: Don't clear TREE_READONLY for -fmerge-all-constants for non-aggregates

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607534.html
  - PR107846 - c-family: Account for integral promotions of left shifts for -Wshift-overflow warning

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606382.html
  - PR107703 - libgcc, i386: Add __fix{,uns}bfti and __float{,un}tibf

https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608932.html
  - PR108079 - c, c++, cgraphunit: Prevent duplicated -Wunused-value warnings

Thanks

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping a few pending patches:

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606973.html
  - PR107465 - c-family: Fix up -Wsign-compare BIT_NOT_EXPR handling

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607104.html
  - PR107465 - c-family: Incremental fix for -Wsign-compare BIT_NOT_EXPR handling

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607145.html
  - PR107558 - c++: Don't clear TREE_READONLY for -fmerge-all-constants for non-aggregates

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607534.html
  - PR107846 - c-family: Account for integral promotions of left shifts for -Wshift-overflow warning

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606382.html
  - PR107703 - libgcc, i386: Add __fix{,uns}bfti and __float{,un}tibf

Thanks

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

On Mon, Oct 24, 2022 at 10:28:34AM -0600, Jeff Law wrote:
> On 10/21/22 09:42, Jakub Jelinek wrote:
> > On top of the pending
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603665.html
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604080.html
> > the following patch adds some complex builtins which have libm
> > implementation in glibc 2.26 and later on various arches.
> > It is needed for libstdc++ _Float128 support when long double is not
> > IEEE quad.
> 
> OK

Thanks a lot.

Can I ping the
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603665.html
patch these 2 approved patches (and the libstdc++ changes too) depend on?

Thanks.

	Jakub

Re: Patch ping

[Jeff Law]

On 3/2/2022 2:47 AM, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping the
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590526.html
> PR104558 - when bypassing emit_push_insn for 0 sized arg, emit at least anti_adjust_stack for alignment pad if needed
>
> patch.
So the issue is the stack isn't aligned to the pad, thus triggering the 
abort.  Right?  Assuming that's the case, the patch is OK with a 
suitable comment.

Jeff

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the

https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590526.html
PR104558 - when bypassing emit_push_insn for 0 sized arg, emit at least anti_adjust_stack for alignment pad if needed

patch.

Thanks

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the
https://gcc.gnu.org/pipermail/libstdc++/2021-December/053680.html
time_get patch.

Thanks

	Jakub

Re: Patch ping

[Jan Hubicka]

> Hi!
> 
> I'd like to ping the
> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586553.html
>   symtab: Fold &a == &b to 0 if folding_initializer [PR94716]
> 
> patch.  Thanks.
OK.
Note that with LTO partitioning it may happen that alias is defined in
one partition but used in another.  We do take care to bring the symtab
info with it so it should be safe.

Honza
> 
> 	Jakub
> 

Re: Patch ping

[Richard Biener]

On Mon, 3 Jan 2022, Jakub Jelinek wrote:

> Hi!
> 
> I'd like to ping the
> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586553.html
>   symtab: Fold &a == &b to 0 if folding_initializer [PR94716]

OK.

Thanks,
Richard.

Re: Patch ping

[Richard Biener]

On Mon, 3 Jan 2022, Jakub Jelinek wrote:

> Hi!
> 
> I'd like to ping the middle-end part of the
> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586879.html
> patch (which Uros approved the backend part for with a minor change
> I have in my tree).

OK for the middle-end parts if you properly amend md.texi

Richard.

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the middle-end part of the
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586879.html
patch (which Uros approved the backend part for with a minor change
I have in my tree).

Thanks.

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586553.html
  symtab: Fold &a == &b to 0 if folding_initializer [PR94716]

patch.  Thanks.

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping following patches:

https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583289.html
  c++, dyninit: Optimize C++ dynamic initialization by constants into DECL_INITIAL adjustment [PR102876]

  While Jason has added -fimplicit-constexpr which can fix up some cases,
  it still doesn't handle non-inline functions, or functions defined after
  the dynamic initialization, or functions defined in other TUs, so I think
  trying to optimize those after IPA is useful and as has been said, other
  compilers do it late as well.

https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584802.html
  pch, v2: Add support for PCH for relocatable executables

  I do support Iain's patches to make PCH configure time disableable,
  but if people do want it and can't use it because of PIEs, it seems
  a pitty not to support it when it is so easy.

Thanks

	Jakub

Re: Patch ping

[Richard Biener]

On Wed, 31 Mar 2021, Jakub Jelinek wrote:

> Hi!
> 
> I'd like to ping the PR98860 P1 fix - workaround for PECOFF linkers without
> DWARF5 support - to make -gdwarf-4 the default in such configurations.
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567245.html

OK.

Richard.

> Thanks
> 
> 	Jakub
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the PR98860 P1 fix - workaround for PECOFF linkers without
DWARF5 support - to make -gdwarf-4 the default in such configurations.

https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567245.html

Thanks

	Jakub

Re: Patch ping

[Richard Biener]

On Wed, 24 Mar 2021, Martin Sebor wrote:

> On 3/24/21 10:40 AM, Jakub Jelinek wrote:
> > On Wed, Mar 24, 2021 at 09:45:31AM -0600, Martin Sebor via Gcc-patches
> > wrote:
> >> E.g., OEP_IGNORE_MEMBER_OFFSET or OEP_SAME_MEMBER_OFFSET (for
> >> the converse of the first) or something like that, but hopefully
> >> you get the idea.
> > 
> > Neither of these look like a good name to me, OEP_IGNORE_MEMBER_OFFSET
> > seems like a request that member offset is not important to the equality,
> > it is always important, but in the new mode we want not just the member
> > offset to be equal, but also the fields to be the same, i.e. a stronger
> > requirement.
> > 
> > So, what about
> >    /* For OEP_ADDRESS_OF of COMPONENT_REFs, only consider same fields as
> >       equivalent rather than also different fields with the same offset.  */
> >    OEP_ADDRESS_OF_SAME_FIELD = 256
> 
> This name works for me.

Works for me as well, aka OK.

Richard.

> Thanks
> Martin
> 
> > 
> >  Jakub
> > 
> 
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: Patch ping

[Martin Sebor]

On 3/24/21 10:40 AM, Jakub Jelinek wrote:
> On Wed, Mar 24, 2021 at 09:45:31AM -0600, Martin Sebor via Gcc-patches wrote:
>> E.g., OEP_IGNORE_MEMBER_OFFSET or OEP_SAME_MEMBER_OFFSET (for
>> the converse of the first) or something like that, but hopefully
>> you get the idea.
> 
> Neither of these look like a good name to me, OEP_IGNORE_MEMBER_OFFSET
> seems like a request that member offset is not important to the equality,
> it is always important, but in the new mode we want not just the member
> offset to be equal, but also the fields to be the same, i.e. a stronger
> requirement.
> 
> So, what about
>    /* For OEP_ADDRESS_OF of COMPONENT_REFs, only consider same fields as
>       equivalent rather than also different fields with the same offset.  */
>    OEP_ADDRESS_OF_SAME_FIELD = 256

This name works for me.

Thanks
Martin

> 
> 	Jakub
> 

Re: Patch ping

[Jakub Jelinek]

On Wed, Mar 24, 2021 at 09:45:31AM -0600, Martin Sebor via Gcc-patches wrote:
> E.g., OEP_IGNORE_MEMBER_OFFSET or OEP_SAME_MEMBER_OFFSET (for
> the converse of the first) or something like that, but hopefully
> you get the idea.

Neither of these look like a good name to me, OEP_IGNORE_MEMBER_OFFSET
seems like a request that member offset is not important to the equality,
it is always important, but in the new mode we want not just the member
offset to be equal, but also the fields to be the same, i.e. a stronger
requirement.

So, what about
  /* For OEP_ADDRESS_OF of COMPONENT_REFs, only consider same fields as
     equivalent rather than also different fields with the same offset.  */
  OEP_ADDRESS_OF_SAME_FIELD = 256

	Jakub

Re: Patch ping

[Jeff Law]

On 3/24/2021 5:44 AM, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> I'd like to ping the
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566821.html
> P1 PR99565 fix.
>
> Marek has acked the gcc/c/ and gcc/c-family/ part of that patch, but it still
> has gcc/cp/ and gcc/ parts that weren't acked.
> If you have suggestions for better OEP_* flag name, I can change it.
Once Martin and you agree on a name, this is fine with the name update 
[if any].

Jeff

Re: Patch ping

[Martin Sebor]

On 3/24/21 5:44 AM, Jakub Jelinek via Gcc-patches wrote:
> Hi!
> 
> I'd like to ping the
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566821.html
> P1 PR99565 fix.
> 
> Marek has acked the gcc/c/ and gcc/c-family/ part of that patch, but it still
> has gcc/cp/ and gcc/ parts that weren't acked.
> If you have suggestions for better OEP_* flag name, I can change it.
> 

Yes, as I said, I think changing it would be helpful.  I already
tried to make some these points in my comments on the patch but
it might help to reiterate them.

A good API name reflects the purpose of the API rather than one of
its (conceivably many) use cases.

By way of an example, when a new flag was needed to implement
-Wduplicate-branches it wasn't called OEM_DUPLICATE_BRANCHES but
OEM_LEXICOGRAPHIC.  That was a good choice of a name because it's
generic enough not to be surprising when used in other contexts.

For the same reason, when an another flag is needed to refine
the behavior of the function in a way that affects the same warning,
it too should describe the effect of the flag on the function rather
than just one possible use case.

Since the new flag determines whether or not distinct members at
the same offset are considered equal, a name that mentions MEMBER
and OFFSET might be suitable.

E.g., OEP_IGNORE_MEMBER_OFFSET or OEP_SAME_MEMBER_OFFSET (for
the converse of the first) or something like that, but hopefully
you get the idea.

Martin

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566821.html
P1 PR99565 fix.

Marek has acked the gcc/c/ and gcc/c-family/ part of that patch, but it still
has gcc/cp/ and gcc/ parts that weren't acked.
If you have suggestions for better OEP_* flag name, I can change it.

Thanks.

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping two patches:

https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566324.html
PR99388 dwarf2out half float fix

https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566669.html
PR99490 dwarf2out -gsplit-dwarf ranges fixes

Thanks

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565350.html
patch, P2 PR99085 ice-on-valid-code fix in fixup_partitions.

Thanks

	Jakub

Re: Patch ping

[Jason Merrill]

On 1/25/21 4:43 AM, Jakub Jelinek wrote:
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2020-December/560741.html
>    dwarf: -gdwarf64 fix for 32-bit targets

OK.

Jason

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 3 patches:

https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563710.html
  expand: Expand x / y * y as x - x % y if the latter is cheaper [PR96696]

https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563711.html
  match.pd: Add some __builtin_ctz (x) cmp cst simplifications [PR95527]

https://gcc.gnu.org/pipermail/gcc-patches/2020-December/560741.html
  dwarf: -gdwarf64 fix for 32-bit targets

Thanks

	Jakub

Re: Patch ping

[Joseph Myers]

On Thu, 22 Oct 2020, Jakub Jelinek via Gcc-patches wrote:

> https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554804.html
>   - PR97164 - reject forming arrays with elt sizes not divisible by elt alignment

OK.

> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556153.html
>   - fix up plugin header install

OK.

The other patches need a self-contained submission showing the proposed 
commit message for that version of the patch, not just a discussion from 
the middle of a thread that can't be understood on its own without going 
through the rest of the discussion (and possibly previous patch versions) 
and doesn't say what form of explanation is proposed as a commit message.

-- 
Joseph S. Myers
joseph@codesourcery.com

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping a few patches:

https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552451.html
  - allow plugins to deal with global_options layout changes

https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553420.html
  - --enable-link-serialization{,=N} support

https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554804.html
  - PR97164 - reject forming arrays with elt sizes not divisible by elt alignment

https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555477.html
  - optimize LTO streaming of optimization nodes

https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556153.html
  - fix up plugin header install

Thanks

	Jakub

Re: Patch ping

[Nathan Sidwell]

On 10/5/20 5:09 AM, Jakub Jelinek via Gcc-patches wrote:
> Hi!
> 
> I'd like to ping a few patches:
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554845.html
>    - PR97197 - support TARGET_MEM_REF in C/C++ error pretty-printing

ok, but could you add a comment on what it's printing out.  As you say, 
it's not the original source :)

nathan

-- 
Nathan Sidwell

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping a few patches:

https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552451.html
  - allow plugins to deal with global_options layout changes

https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553420.html
  - --enable-link-serialization{,=N} support

https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553992.html
  - pass -gdwarf-5 to assembler for -gdwarf-5 if possible

https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554845.html
  - PR97197 - support TARGET_MEM_REF in C/C++ error pretty-printing

https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554804.html
  - PR97164 - reject forming arrays with elt sizes not divisible by elt alignment

Thanks

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping a few patches:

https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552451.html
  - allow plugins to deal with global_options layout changes

https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553420.html
  - --enable-link-serialization{,=N} support

https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553948.html
  - PR96994 - fix up C++ handling of default initialization with
	      consteval default ctor

https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553992.html
  - pass -gdwarf-5 to assembler for -gdwarf-5 if possible

https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554246.html
  - PR97073 - fix wrong-code on double-word op expansion

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the
https://gcc.gnu.org/legacy-ml/gcc-patches/2020-03/msg00154.html
  P1 PR94015
patch, with the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94015#c5
testcase instead of the one sent in the patch, so that it FAILs without the
fix on more targets and more reliably.

Thanks

	Jakub

Re: Patch ping

[Jeff Law]

On Thu, 2020-02-13 at 10:42 -0700, Martin Sebor wrote:
> On 2/13/20 2:54 AM, Jakub Jelinek wrote:
> > On Wed, Feb 12, 2020 at 02:39:05PM -0700, Jeff Law wrote:
> > > On Mon, 2020-02-10 at 10:24 +0100, Jakub Jelinek wrote:
> > > > Hi!
> > > > 
> > > > I'd like to ping a couple of patches:
> > > > 
> > > > PR target/91913 - arm movsi + cmpsi -> movsi_compare0 peephole2 ICE fix
> > > >     https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00010.html
> > > Letting the ARM guys deal with this.
> > 
> > Yes, that is resolved now (Richard E. committed his patch and I've
> > committed the testcase).
> > 
> > > > PR preprocessor/92319 - partially implement P1042R1: __VA_OPT__ wording clarifications
> > > >     https://gcc.gnu.org/ml/gcc-patches/2020-01/msg02104.html
> > > Jason for this one.
> > 
> > Of course; I just chose to send a ping for all my pending patches and
> > add to To: all relevant maintainers.
> > 
> > > > PR target/93069 - avx512* rejects-valid fix (rejected by assembler)
> > > >     http://gcc.gnu.org/ml/gcc-patches/2019-12/msg01606.html
> > > This is in my queue :-)
> > 
> > Ok.
> > 
> > > > PR tree-optimization/92868 - compute_objsize/gimple_call_alloc_size
> > > >                               /maybe_warn_overflow fixes
> > > >     http://gcc.gnu.org/ml/gcc-patches/2019-12/msg01164.html
> > > Martin's patch should have addressed all the issues and should include
> > > your tests (tweaked, but supposed to be equivalent).
> > 
> > No, this is something different, this isn't what has been covered by the
> > testcases, but something found by code inspection, mainly inconsistencies
> > in the APIs, e.g. the ranges represented as sizetype most of the time,
> > but with one exception where it could be some other type (wider or
> > narrower), or sometimes the range being incorrect (if there is possible
> > overflow and we punt, we didn't change the ranges effectively to VARYING,
> > but just capped the maximum), or INTEGER_CSTs compared by pointer equality
> > rather than operand_equal_p.
> 
> As I said repeatedly in my comments on the patch, I'm not in favor
> of these changes.  I don't think they hurt anything but they also
> don't fix anything that I can see.  There's is no bug the change
> fixes (PR 92868 is closed as resolved) or a test case included in
> the patch that verifies the improvement.  The changes are also not
> in the direction I'd like to see this code evolve.
Jakub, let's defer any cleanups unless there's a reported bug.  We can
come back to this stuff for gcc-11.

jeff
> 
> Martin
> 

Re: Patch ping

[Martin Sebor]

On 2/13/20 2:54 AM, Jakub Jelinek wrote:
> On Wed, Feb 12, 2020 at 02:39:05PM -0700, Jeff Law wrote:
>> On Mon, 2020-02-10 at 10:24 +0100, Jakub Jelinek wrote:
>>> Hi!
>>>
>>> I'd like to ping a couple of patches:
>>>
>>> PR target/91913 - arm movsi + cmpsi -> movsi_compare0 peephole2 ICE fix
>>>     https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00010.html
>> Letting the ARM guys deal with this.
> 
> Yes, that is resolved now (Richard E. committed his patch and I've
> committed the testcase).
> 
>>> PR preprocessor/92319 - partially implement P1042R1: __VA_OPT__ wording clarifications
>>>     https://gcc.gnu.org/ml/gcc-patches/2020-01/msg02104.html
>> Jason for this one.
> 
> Of course; I just chose to send a ping for all my pending patches and
> add to To: all relevant maintainers.
> 
>>> PR target/93069 - avx512* rejects-valid fix (rejected by assembler)
>>>     http://gcc.gnu.org/ml/gcc-patches/2019-12/msg01606.html
>> This is in my queue :-)
> 
> Ok.
> 
>>> PR tree-optimization/92868 - compute_objsize/gimple_call_alloc_size
>>>                               /maybe_warn_overflow fixes
>>>     http://gcc.gnu.org/ml/gcc-patches/2019-12/msg01164.html
>> Martin's patch should have addressed all the issues and should include
>> your tests (tweaked, but supposed to be equivalent).
> 
> No, this is something different, this isn't what has been covered by the
> testcases, but something found by code inspection, mainly inconsistencies
> in the APIs, e.g. the ranges represented as sizetype most of the time,
> but with one exception where it could be some other type (wider or
> narrower), or sometimes the range being incorrect (if there is possible
> overflow and we punt, we didn't change the ranges effectively to VARYING,
> but just capped the maximum), or INTEGER_CSTs compared by pointer equality
> rather than operand_equal_p.

As I said repeatedly in my comments on the patch, I'm not in favor
of these changes.  I don't think they hurt anything but they also
don't fix anything that I can see.  There's is no bug the change
fixes (PR 92868 is closed as resolved) or a test case included in
the patch that verifies the improvement.  The changes are also not
in the direction I'd like to see this code evolve.

Martin

Re: Patch ping

[Jakub Jelinek]

On Wed, Feb 12, 2020 at 02:39:05PM -0700, Jeff Law wrote:
> On Mon, 2020-02-10 at 10:24 +0100, Jakub Jelinek wrote:
> > Hi!
> > 
> > I'd like to ping a couple of patches:
> > 
> > PR target/91913 - arm movsi + cmpsi -> movsi_compare0 peephole2 ICE fix
> >    https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00010.html
> Letting the ARM guys deal with this.

Yes, that is resolved now (Richard E. committed his patch and I've
committed the testcase).

> > PR preprocessor/92319 - partially implement P1042R1: __VA_OPT__ wording clarifications
> >    https://gcc.gnu.org/ml/gcc-patches/2020-01/msg02104.html
> Jason for this one.

Of course; I just chose to send a ping for all my pending patches and
add to To: all relevant maintainers.

> > PR target/93069 - avx512* rejects-valid fix (rejected by assembler)
> >    http://gcc.gnu.org/ml/gcc-patches/2019-12/msg01606.html
> This is in my queue :-)

Ok.

> > PR tree-optimization/92868 - compute_objsize/gimple_call_alloc_size
> >                              /maybe_warn_overflow fixes
> >    http://gcc.gnu.org/ml/gcc-patches/2019-12/msg01164.html
> Martin's patch should have addressed all the issues and should include
> your tests (tweaked, but supposed to be equivalent).

No, this is something different, this isn't what has been covered by the
testcases, but something found by code inspection, mainly inconsistencies
in the APIs, e.g. the ranges represented as sizetype most of the time,
but with one exception where it could be some other type (wider or
narrower), or sometimes the range being incorrect (if there is possible
overflow and we punt, we didn't change the ranges effectively to VARYING,
but just capped the maximum), or INTEGER_CSTs compared by pointer equality
rather than operand_equal_p.

	Jakub

Re: Patch ping

[Jeff Law]

On Mon, 2020-02-10 at 10:24 +0100, Jakub Jelinek wrote:
> Hi!
> 
> I'd like to ping a couple of patches:
> 
> PR target/91913 - arm movsi + cmpsi -> movsi_compare0 peephole2 ICE fix
>    https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00010.html
Letting the ARM guys deal with this.


> 
> PR preprocessor/92319 - partially implement P1042R1: __VA_OPT__ wording clarifications
>    https://gcc.gnu.org/ml/gcc-patches/2020-01/msg02104.html
Jason for this one.

> 
> PR target/93069 - avx512* rejects-valid fix (rejected by assembler)
>    http://gcc.gnu.org/ml/gcc-patches/2019-12/msg01606.html
This is in my queue :-)

> 
> PR tree-optimization/92868 - compute_objsize/gimple_call_alloc_size
>                              /maybe_warn_overflow fixes
>    http://gcc.gnu.org/ml/gcc-patches/2019-12/msg01164.html
Martin's patch should have addressed all the issues and should include
your tests (tweaked, but supposed to be equivalent).

jeff

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping a couple of patches:

PR target/91913 - arm movsi + cmpsi -> movsi_compare0 peephole2 ICE fix
   https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00010.html

PR preprocessor/92319 - partially implement P1042R1: __VA_OPT__ wording clarifications
   https://gcc.gnu.org/ml/gcc-patches/2020-01/msg02104.html

PR target/93069 - avx512* rejects-valid fix (rejected by assembler)
   http://gcc.gnu.org/ml/gcc-patches/2019-12/msg01606.html

PR tree-optimization/92868 - compute_objsize/gimple_call_alloc_size
                             /maybe_warn_overflow fixes
   http://gcc.gnu.org/ml/gcc-patches/2019-12/msg01164.html

Thanks

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping a few patches:

PR target/93009 - avx512* wrong-code fix
  http://gcc.gnu.org/ml/gcc-patches/2019-12/msg01488.html

PR target/93069 - avx512* rejects-valid fix (rejected by assembler)
  http://gcc.gnu.org/ml/gcc-patches/2019-12/msg01606.html

PR tree-optimization/92868 - compute_objsize/gimple_call_alloc_size
			     /maybe_warn_overflow fixes
  http://gcc.gnu.org/ml/gcc-patches/2019-12/msg01164.html

Thanks

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

On Sat, Sep 21, 2019 at 08:14:13AM +0200, Jakub Jelinek wrote:
> 2019-09-21  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR tree-optimization/91734
> 	* generic-match-head.c: Include fold-const-call.h.
> 	* match.pd (sqrt(x) cmp c): Check the boundary value and
> 	in case inexact computation of c*c affects comparison of the boundary,
> 	turn LT_EXPR into LE_EXPR, GE_EXPR into GT_EXPR, LE_EXPR into LT_EXPR
> 	or GT_EXPR into GE_EXPR.  Punt for sqrt comparisons against NaN and
> 	for -frounding-math.  For c2, try the next smaller or larger floating
> 	point constant depending on comparison code and if it has the same
> 	sqrt as c2, use it instead of c2.
> 
> 	* gcc.dg/pr91734.c: New test.

I'd like to ping this patch (
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01281.html
).  Thanks.

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the PR89888 patch:
https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00360.html

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

Re: Patch ping

[Kirill Yukhin]

Hello Jakub
On 16 апр 10:12, Jakub Jelinek wrote:
> Hi!
> 
> I'd like to ping the
> 
>   http://gcc.gnu.org/ml/gcc-patches/2018-04/msg00414.html
>   PR85281 - assorted -masm=intel fixes
Sorry, for missing that. Patch is OK as far as tests beginning to pass.

--
Thanks, K
> 
> 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 the
  http://gcc.gnu.org/ml/gcc-patches/2018-04/msg00123.html
  P1 PR85177 vinsert[if]{32x4,64x2} pattern fix
patch.

Thanks

	Jakub

Re: Patch ping

[Kirill Yukhin]

Hello Jakub,
Sorry for missing that.

Your patch is OK.

—
Thanks, K

> On 10 Apr 2018, at 13:59, Jakub Jelinek <jakub@redhat.com> wrote:
> 
> 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

Re: Patch ping

[Jason Merrill]

OK.

On Mon, Mar 12, 2018 at 10:22 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> 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-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 following patch:

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

Thanks

	Jakub

Re: Patch ping

[Jan Hubicka]

Dne 2018-03-05 17:13, Jakub Jelinek napsal:
> 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

OK,
thanks!
Honza
> 
> Thanks
> 
> 	Jakub

Re: Patch ping

[Kirill Yukhin]

Hello Jakub,

On Friday, March 2, 2018, Jakub Jelinek <jakub@redhat.com> wrote:

> 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

Patch is OK.


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

—
Thanks, K

Re: Patch ping

[Jeff Law]

On 03/02/2018 01:17 AM, Jakub Jelinek wrote:
> 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
Hoping Kirill will chime in here.


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

jeff

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

Re: Patch ping

[Jeff Law]

On 02/14/2018 07:22 AM, Jakub Jelinek wrote:
> 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
OK.  And FWIW, I like this much more than having it be an insn note.


jeff

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:

PR83659 cxx_fold_indirect_ref ICE fix
  http://gcc.gnu.org/ml/gcc-patches/2018-01/msg02211.html

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

	Jakub

Re: Patch ping

[Jakub Jelinek]

On Mon, Nov 20, 2017 at 01:31:39PM -0500, Nathan Sidwell wrote:
> On 11/20/2017 02:55 AM, Jakub Jelinek wrote:
> 
> >    http://gcc.gnu.org/ml/gcc-patches/2017-11/msg00851.html
> >    C++2A P0428R2 - familiar template syntax for generic lambdas
> 
> Are there existing testcases checking this is permitted w/o warning under
> the appropriate circumstances?  That seems to be the only thing missing from
> the patch itself.

At least for check-c++-all I believe it is mostly covered.  E.g.
g++.dg/cpp1y/lambda-generic-x.C has:
// { dg-warning "lambda templates are only available with" "" { target c++17_down } }
which checks that with -Wpedantic there is warning emitted in -std=gnu++14
and -std=gnu++17, but not with -std=gnu++20.  Similarly several other
testcases.
And g++.dg/cpp2a/lambda-generic1.C has:
// { dg-error "lambda templates are only available with" "" { target c++17_down } }
that verifies that with -pedantic-errors in -std=c++14 and -std=c++17
an error is emitted and in -std=c++20 no error/warning is diagnosed.

So, what isn't tested is: 1) behavior for C++98/C++11 2) -Wno-pedantic
behavior 3) at least one test that would catch it even without check-c++-all
for -std=c++2a

Therefore, I've added 3 new small tests that are compiled by all language
variants and check -pedantic-errors, -Wpedantic and -Wno-pedantic behavior
and one that forces -std=c++2a into dg-options and thus works even without
check-c++-all and committed.  Thanks.

2017-11-21  Jakub Jelinek  <jakub@redhat.com>

	P0428R2 - familiar template syntax for generic lambdas
	* parser.c (cp_parser_lambda_declarator_opt): Don't pedwarn
	for cxx2a and above, reword pedwarn for C++14/C++17.

	* g++.dg/cpp1y/lambda-generic-x.C: Adjust warnings and limit
	to c++17_down target.
	* g++.dg/cpp1y/lambda-generic-dep.C: Likewise.
	* g++.dg/cpp1y/lambda-generic-77914.C: Adjust error and limit
	to c++17_down target.
	* g++.dg/cpp2a/lambda-generic1.C: New test.
	* g++.dg/cpp2a/lambda-generic2.C: New test.
	* g++.dg/cpp2a/lambda-generic3.C: New test.
	* g++.dg/cpp2a/lambda-generic4.C: New test.
	* g++.dg/cpp2a/lambda-generic5.C: New test.

--- gcc/cp/parser.c.jj	2017-11-20 19:56:04.787470779 +0100
+++ gcc/cp/parser.c	2017-11-21 09:15:30.127267088 +0100
@@ -10512,9 +10512,10 @@ cp_parser_lambda_declarator_opt (cp_pars
 	pedwarn (parser->lexer->next_token->location, 0,
 		 "lambda templates are only available with "
 		 "-std=c++14 or -std=gnu++14");
-      else
+      else if (cxx_dialect < cxx2a)
 	pedwarn (parser->lexer->next_token->location, OPT_Wpedantic,
-		 "ISO C++ does not support lambda templates");
+		 "lambda templates are only available with "
+		 "-std=c++2a or -std=gnu++2a");
 
       cp_lexer_consume_token (parser->lexer);
 
--- gcc/testsuite/g++.dg/cpp1y/lambda-generic-x.C.jj	2017-11-10 15:42:02.371152517 +0100
+++ gcc/testsuite/g++.dg/cpp1y/lambda-generic-x.C	2017-11-21 09:15:30.147266840 +0100
@@ -6,17 +6,17 @@
 
 int main()
 {
-   auto glambda = [] <typename A, typename B> (A a, B&& b) { return a < b; };	// { dg-warning "does not support lambda templates" }
+   auto glambda = [] <typename A, typename B> (A a, B&& b) { return a < b; };	// { dg-warning "lambda templates are only available with" "" { target c++17_down } }
    bool b = glambda(3, 3.14); // OK
-   auto vglambda = [] <typename P> (P printer) {				// { dg-warning "does not support lambda templates" }
+   auto vglambda = [] <typename P> (P printer) {				// { dg-warning "lambda templates are only available with" "" { target c++17_down } }
      return [=] <typename... T> (T&& ... ts) { // OK: ts is a function parameter pack
-       printer(std::forward<decltype(ts)>(ts)...);				// { dg-warning "does not support lambda templates" "" { target *-*-* } .-1 }
+       printer(std::forward<decltype(ts)>(ts)...);				// { dg-warning "lambda templates are only available with" "" { target c++17_down } .-1 }
        return [=]() {
          printer(ts ...);
        };
      };
    };
-   auto p = vglambda( [] <typename A,						// { dg-warning "does not support lambda templates" }
+   auto p = vglambda( [] <typename A,						// { dg-warning "lambda templates are only available with" "" { target c++17_down } }
                           typename B,
                           typename C> (A v1, B v2, C v3)
      { std::cout << v1 << v2 << v3; } );
--- gcc/testsuite/g++.dg/cpp1y/lambda-generic-dep.C.jj	2017-11-10 15:42:02.394152236 +0100
+++ gcc/testsuite/g++.dg/cpp1y/lambda-generic-dep.C	2017-11-21 09:15:30.161266666 +0100
@@ -27,7 +27,7 @@ struct S {
 
 int main()
 {
-  auto f = [] <typename T> (T const& s) mutable {	// { dg-warning "does not support lambda templates" }
+  auto f = [] <typename T> (T const& s) mutable {	// { dg-warning "lambda templates are only available with" "" { target c++17_down } }
     typename T::N x;
     return x.test ();
   };
--- gcc/testsuite/g++.dg/cpp1y/lambda-generic-77914.C.jj	2017-11-10 15:42:02.336152944 +0100
+++ gcc/testsuite/g++.dg/cpp1y/lambda-generic-77914.C	2017-11-21 09:15:30.169266567 +0100
@@ -4,6 +4,6 @@
 int
 main ()
 {
-  auto l = [] <typename T> () {};	// { dg-error "does not support lambda templates" }
+  auto l = [] <typename T> () {};	// { dg-error "lambda templates are only available with" "" { target c++17_down } }
   l.operator () <void> ();
 }
--- gcc/testsuite/g++.dg/cpp2a/lambda-generic1.C.jj	2017-11-21 09:15:30.169266567 +0100
+++ gcc/testsuite/g++.dg/cpp2a/lambda-generic1.C	2017-11-21 09:15:30.169266567 +0100
@@ -0,0 +1,9 @@
+// P0428R2
+// { dg-do compile { target c++14 } }
+
+int i = [](int i, auto a) { return i; }(3, 4);
+int j = []<class T>(T t, int i) { return i; }(3, 4);		  // { dg-error "lambda templates are only available with" "" { target c++17_down } }
+int k[2] = { 5, 6 };
+int l = []<typename T>(T *p) { return *p; }(k);			  // { dg-error "lambda templates are only available with" "" { target c++17_down } }
+int m = []<typename T, int N>(T (&a)[N]) { return a[N - 1]; }(k); // { dg-error "lambda templates are only available with" "" { target c++17_down } }
+int n = []<typename T>(T a, auto b) { return a + b; }(7, 8);	  // { dg-error "lambda templates are only available with" "" { target c++17_down } }
--- gcc/testsuite/g++.dg/cpp2a/lambda-generic2.C.jj	2017-11-21 09:16:47.745302618 +0100
+++ gcc/testsuite/g++.dg/cpp2a/lambda-generic2.C	2017-11-21 09:20:58.655184849 +0100
@@ -0,0 +1,7 @@
+// P0428R2
+// { dg-do compile }
+
+int j = []<class T>(T t, int i) { return i; }(3, 4);
+// { dg-error "lambda templates are only available with" "" { target c++17_down } .-1 }
+// { dg-error "lambda expressions only available with" "" { target c++98_only } .-2 }
+// { dg-error "invalid use of 'auto'" "" { target c++98_only } .-3 }
--- gcc/testsuite/g++.dg/cpp2a/lambda-generic3.C.jj	2017-11-21 09:19:59.266922799 +0100
+++ gcc/testsuite/g++.dg/cpp2a/lambda-generic3.C	2017-11-21 09:28:13.086788078 +0100
@@ -0,0 +1,8 @@
+// P0428R2
+// { dg-do compile }
+// { dg-options "-Wpedantic" }
+
+int j = []<class T>(T t, int i) { return i; }(3, 4);
+// { dg-warning "lambda templates are only available with" "" { target c++17_down } .-1 }
+// { dg-warning "lambda expressions only available with" "" { target c++98_only } .-2 }
+// { dg-error "invalid use of 'auto'" "" { target c++98_only } .-3 }
--- gcc/testsuite/g++.dg/cpp2a/lambda-generic4.C.jj	2017-11-21 09:28:33.928529224 +0100
+++ gcc/testsuite/g++.dg/cpp2a/lambda-generic4.C	2017-11-21 09:30:19.146222419 +0100
@@ -0,0 +1,8 @@
+// P0428R2
+// { dg-do compile }
+// { dg-options "-Wno-pedantic" }
+
+int j = []<class T>(T t, int i) { return i; }(3, 4);
+// { dg-warning "lambda templates are only available with" "" { target c++11_down } .-1 }
+// { dg-warning "lambda expressions only available with" "" { target c++98_only } .-2 }
+// { dg-error "invalid use of 'auto'" "" { target c++98_only } .-3 }
--- gcc/testsuite/g++.dg/cpp2a/lambda-generic5.C.jj	2017-11-21 09:21:25.785847728 +0100
+++ gcc/testsuite/g++.dg/cpp2a/lambda-generic5.C	2017-11-21 09:31:02.871679348 +0100
@@ -0,0 +1,6 @@
+// P0428R2
+// { dg-do compile }
+// { dg-options "-std=c++2a" }
+
+int j = []<class T>(T t, int i) { return i; }(3, 4);
+// { dg-bogus "lambda templates are only available with" "" { target c++2a } .-1 }


	Jakub

Re: Patch ping

[Jakub Jelinek]

On Mon, Nov 20, 2017 at 02:58:22PM -0800, Jim Wilson wrote:
> On 11/19/2017 11:55 PM, Jakub Jelinek wrote:
> > 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
> 
> I already responded to this one.
> https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01268.html

Sorry for missing that.

> The dwarf2out.c patch looks good to me, though the testcase does not fail on
> unpatched mainline anymore.  I had to go back to the 2017-10-22 snapshot to
> see the failure.  There was a followup from Mark Wielaard mentioning that
> elfutils still fails on mainline, so maybe we can get a testcase from there.

Committed both with the old and your new testcase after verifying your new
one still fails without the patch.

Thanks.

2017-11-21  Jakub Jelinek  <jakub@redhat.com>

	PR debug/82718
	* dwarf2out.c (dw_loc_list): If crtl->has_bb_partition, temporarily
	set in_cold_section_p to the partition containing loc_list->first.
	When seeing loc_list->last_before_switch node, update secname and
	perform range_across_switch second partition handling only after that.

	* gcc.dg/debug/dwarf2/pr82718-1.c: New test.
	* gcc.dg/debug/dwarf2/pr82718-2.c: New test.

--- gcc/dwarf2out.c.jj	2017-10-23 22:39:27.000000000 +0200
+++ gcc/dwarf2out.c	2017-10-25 21:01:13.237929750 +0200
@@ -16333,92 +16333,111 @@ dw_loc_list (var_loc_list *loc_list, tre
      This means we have to special case the last node, and generate
      a range of [last location start, end of function label].  */
 
-  secname = secname_for_decl (decl);
+  if (cfun && crtl->has_bb_partition)
+    {
+      bool save_in_cold_section_p = in_cold_section_p;
+      in_cold_section_p = first_function_block_is_cold;
+      if (loc_list->last_before_switch == NULL)
+	in_cold_section_p = !in_cold_section_p;
+      secname = secname_for_decl (decl);
+      in_cold_section_p = save_in_cold_section_p;
+    }
+  else
+    secname = secname_for_decl (decl);
 
   for (node = loc_list->first; node; node = node->next)
-    if (GET_CODE (node->loc) == EXPR_LIST
-	|| NOTE_VAR_LOCATION_LOC (node->loc) != NULL_RTX)
-      {
-	if (GET_CODE (node->loc) == EXPR_LIST)
-	  {
-	    /* This requires DW_OP_{,bit_}piece, which is not usable
-	       inside DWARF expressions.  */
-	    if (want_address != 2)
-	      continue;
+    {
+      bool range_across_switch = false;
+      if (GET_CODE (node->loc) == EXPR_LIST
+	  || NOTE_VAR_LOCATION_LOC (node->loc) != NULL_RTX)
+	{
+	  if (GET_CODE (node->loc) == EXPR_LIST)
+	    {
+	      descr = NULL;
+	      /* This requires DW_OP_{,bit_}piece, which is not usable
+		 inside DWARF expressions.  */
+	      if (want_address == 2)
+		descr = dw_sra_loc_expr (decl, node->loc);
+	    }
+	  else
+	    {
+	      initialized = NOTE_VAR_LOCATION_STATUS (node->loc);
+	      varloc = NOTE_VAR_LOCATION (node->loc);
+	      descr = dw_loc_list_1 (decl, varloc, want_address, initialized);
+	    }
+	  if (descr)
+	    {
+	      /* If section switch happens in between node->label
+		 and node->next->label (or end of function) and
+		 we can't emit it as a single entry list,
+		 emit two ranges, first one ending at the end
+		 of first partition and second one starting at the
+		 beginning of second partition.  */
+	      if (node == loc_list->last_before_switch
+		  && (node != loc_list->first || loc_list->first->next)
+		  && current_function_decl)
+		{
+		  endname = cfun->fde->dw_fde_end;
+		  range_across_switch = true;
+		}
+	      /* The variable has a location between NODE->LABEL and
+		 NODE->NEXT->LABEL.  */
+	      else if (node->next)
+		endname = node->next->label;
+	      /* If the variable has a location at the last label
+		 it keeps its location until the end of function.  */
+	      else if (!current_function_decl)
+		endname = text_end_label;
+	      else
+		{
+		  ASM_GENERATE_INTERNAL_LABEL (label_id, FUNC_END_LABEL,
+					       current_function_funcdef_no);
+		  endname = ggc_strdup (label_id);
+		}
+
+	      *listp = new_loc_list (descr, node->label, endname, secname);
+	      if (TREE_CODE (decl) == PARM_DECL
+		  && node == loc_list->first
+		  && NOTE_P (node->loc)
+		  && strcmp (node->label, endname) == 0)
+		(*listp)->force = true;
+	      listp = &(*listp)->dw_loc_next;
+	    }
+	}
+
+      if (cfun
+	  && crtl->has_bb_partition
+	  && node == loc_list->last_before_switch)
+	{
+	  bool save_in_cold_section_p = in_cold_section_p;
+	  in_cold_section_p = !first_function_block_is_cold;
+	  secname = secname_for_decl (decl);
+	  in_cold_section_p = save_in_cold_section_p;
+	}
+
+      if (range_across_switch)
+	{
+	  if (GET_CODE (node->loc) == EXPR_LIST)
 	    descr = dw_sra_loc_expr (decl, node->loc);
-	    if (descr == NULL)
-	      continue;
-	  }
-	else
-	  {
-	    initialized = NOTE_VAR_LOCATION_STATUS (node->loc);
-	    varloc = NOTE_VAR_LOCATION (node->loc);
-	    descr = dw_loc_list_1 (decl, varloc, want_address, initialized);
-	  }
-	if (descr)
-	  {
-	    bool range_across_switch = false;
-	    /* If section switch happens in between node->label
-	       and node->next->label (or end of function) and
-	       we can't emit it as a single entry list,
-	       emit two ranges, first one ending at the end
-	       of first partition and second one starting at the
-	       beginning of second partition.  */
-	    if (node == loc_list->last_before_switch
-		&& (node != loc_list->first || loc_list->first->next)
-		&& current_function_decl)
-	      {
-		endname = cfun->fde->dw_fde_end;
-		range_across_switch = true;
-	      }
-	    /* The variable has a location between NODE->LABEL and
-	       NODE->NEXT->LABEL.  */
-	    else if (node->next)
-	      endname = node->next->label;
-	    /* If the variable has a location at the last label
-	       it keeps its location until the end of function.  */
-	    else if (!current_function_decl)
-	      endname = text_end_label;
-	    else
-	      {
-		ASM_GENERATE_INTERNAL_LABEL (label_id, FUNC_END_LABEL,
-					     current_function_funcdef_no);
-		endname = ggc_strdup (label_id);
-	      }
-
-	    *listp = new_loc_list (descr, node->label, endname, secname);
-	    if (TREE_CODE (decl) == PARM_DECL
-		&& node == loc_list->first
-		&& NOTE_P (node->loc)
-		&& strcmp (node->label, endname) == 0)
-	      (*listp)->force = true;
-	    listp = &(*listp)->dw_loc_next;
-
-	    if (range_across_switch)
-	      {
-		if (GET_CODE (node->loc) == EXPR_LIST)
-		  descr = dw_sra_loc_expr (decl, node->loc);
-		else
-		  {
-		    initialized = NOTE_VAR_LOCATION_STATUS (node->loc);
-		    varloc = NOTE_VAR_LOCATION (node->loc);
-		    descr = dw_loc_list_1 (decl, varloc, want_address,
-					   initialized);
-		  }
-		gcc_assert (descr);
-		/* The variable has a location between NODE->LABEL and
-		   NODE->NEXT->LABEL.  */
-		if (node->next)
-		  endname = node->next->label;
-		else
-		  endname = cfun->fde->dw_fde_second_end;
-		*listp = new_loc_list (descr,
-				       cfun->fde->dw_fde_second_begin,
-				       endname, secname);
-		listp = &(*listp)->dw_loc_next;
-	      }
-	  }
-      }
+	  else
+	    {
+	      initialized = NOTE_VAR_LOCATION_STATUS (node->loc);
+	      varloc = NOTE_VAR_LOCATION (node->loc);
+	      descr = dw_loc_list_1 (decl, varloc, want_address,
+				     initialized);
+	    }
+	  gcc_assert (descr);
+	  /* The variable has a location between NODE->LABEL and
+	     NODE->NEXT->LABEL.  */
+	  if (node->next)
+	    endname = node->next->label;
+	  else
+	    endname = cfun->fde->dw_fde_second_end;
+	  *listp = new_loc_list (descr, cfun->fde->dw_fde_second_begin,
+				 endname, secname);
+	  listp = &(*listp)->dw_loc_next;
+	}
+    }
 
   /* Try to avoid the overhead of a location list emitting a location
      expression instead, but only if we didn't have more than one
--- gcc/testsuite/gcc.dg/debug/dwarf2/pr82718-1.c.jj	2017-10-25 21:10:53.324920386 +0200
+++ gcc/testsuite/gcc.dg/debug/dwarf2/pr82718-1.c	2017-10-25 21:10:25.000000000 +0200
@@ -0,0 +1,41 @@
+/* PR debug/82718 */
+/* { dg-do assemble } */
+/* { dg-options "-O2 -gdwarf-5" } */
+
+extern int e;
+extern long foo (int, void *, unsigned long, unsigned long);
+struct S
+{
+  int f;
+  unsigned long t, s;
+};
+
+static inline long
+bv (int x, void *y, unsigned long z, unsigned long w)
+{
+  long a = 0;
+  do
+    {
+      long g;
+      do
+	g = (long int) (foo (x, y + a, z - a, w + a));
+      while (g == -1L && e == 9959);
+      if (g <= 0)
+	return g < 0 ? g : a;
+      a += g;
+    }
+  while ((unsigned long) a < z);
+  return a;
+}
+
+const char *
+baz (struct S *x)
+{
+  unsigned long h = 8;
+  char *j = 0;
+  unsigned long z = x->f;
+  if (__builtin_expect (!!((unsigned long) bv (x->f, j, z, x->t + h + 10) != z), 0))
+    return 0;
+  x->s = z;
+  return j;
+}
--- gcc/testsuite/gcc.dg/debug/dwarf2/pr82718-2.c.jj	2017-08-31 21:08:14.436950781 +0200
+++ gcc/testsuite/gcc.dg/debug/dwarf2/pr82718-2.c	2017-11-21 08:55:47.433967007 +0100
@@ -0,0 +1,12 @@
+/* PR debug/82718 */
+/* { dg-do assemble } */
+/* { dg-options "-O2 -gdwarf-5" } */
+
+extern int bar (void);
+
+int
+foo (int x)
+{
+  if (bar ())
+    __builtin_abort ();
+}


	Jakub

Re: Patch ping

[Jim Wilson]

On 11/20/2017 02:58 PM, Jim Wilson wrote:
> The dwarf2out.c patch looks good to me, though the testcase does not 
> fail on unpatched mainline anymore.  I had to go back to the 2017-10-22 
> snapshot to see the failure.  There was a followup from Mark Wielaard 
> mentioning that elfutils still fails on mainline, so maybe we can get a 
> testcase from there.

The testcase was "broken" by Jan's big patch on Nov 3
     https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00104.html
It didn't seem useful to look into that, so I tried running 
multidelta/creduce on the elfutils sources, and managed to get a small 
testcase that still fails with mainline.  I then fixed it to get rid of 
the warnings.

#include <stdlib.h>
extern int c (void);
int
a(int b) {
   if (c())
     abort();
}

There is no guarantee that this testcase will still show the problem in 
the future, but it seems good enough for now.

OK with this testcase.  And with your testcase too if you think that 
still has value.

Jim

Re: Patch ping

[Jim Wilson]

On 11/19/2017 11:55 PM, Jakub Jelinek wrote:
> 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

I already responded to this one.
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01268.html

The dwarf2out.c patch looks good to me, though the testcase does not 
fail on unpatched mainline anymore.  I had to go back to the 2017-10-22 
snapshot to see the failure.  There was a followup from Mark Wielaard 
mentioning that elfutils still fails on mainline, so maybe we can get a 
testcase from there.

Jim

Re: Patch ping

[Nathan Sidwell]

On 11/20/2017 02:55 AM, Jakub Jelinek wrote:

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

Are there existing testcases checking this is permitted w/o warning 
under the appropriate circumstances?  That seems to be the only thing 
missing from the patch itself.

Otherwise ok.

nathan

-- 
Nathan Sidwell

Re: Patch ping

[Nathan Sidwell]

On 11/20/2017 02:55 AM, Jakub Jelinek wrote:
> Hi!

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

OK, thanks


-- 
Nathan Sidwell

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

[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

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

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping two patches:

http://gcc.gnu.org/ml/gcc-patches/2017-10/msg00206.html
  PR target/82370 - improve V?TImode shifts
  H.J., can you please respond whether the
  (set_attr "atom_unit" "sishuf")
  attribute just on {,v}psrldq and not on {,v}pslldq
  was intentional (and if so, why), or just an omission
  and in that case if both insns should have it or none?

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?

Thanks

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping a few patches:

http://gcc.gnu.org/ml/gcc-patches/2017-09/msg01939.html
  PR libstdc++/81706 - omp declare simd attribute vs. builtins
  C++ part of the patch

http://gcc.gnu.org/ml/gcc-patches/2017-10/msg00162.html
  PR target/82370 - prefer shorter VEX encoding of VP{AND,OR,XOR,ANDN} over
  EVEX when possible

http://gcc.gnu.org/ml/gcc-patches/2017-10/msg00205.html
  PR target/82370 - improve AVX512 vector shift patterns

http://gcc.gnu.org/ml/gcc-patches/2017-10/msg00206.html
  PR target/82370 - improve V?TImode shifts

http://gcc.gnu.org/ml/gcc-patches/2017-10/msg00207.html
  Remove useless isa attributes from various sse.md patterns

http://gcc.gnu.org/ml/gcc-patches/2017-10/msg00525.html
  PR target/82460 - improve AVX512* vperm[ti]2*

Thanks

	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/msg02006.html
>    PR c++/82299 - invalid -Wuseless-cast on direct enum init

Agreed, ok, thanks.

nathan

-- 
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/msg01237.html
>    C++2a P0704R1 - fixing const-qualified pointers to members

ok, thanks


-- 
Nathan Sidwell

Patch ping

[Jakub Jelinek]

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                                                                                           

http://gcc.gnu.org/ml/gcc-patches/2017-09/msg01939.html
  PR libstdc++/81706 - omp declare simd attribute vs. builtins
  C++ part of the patch

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

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

Thanks

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the following patch:

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

Thanks

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the following patch:
- DWARF - emit DW_AT_export_symbols for inline and anon namespaces
  https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01349.html

Thanks

	Jakub

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  <jakub@redhat.com>
> 
> 	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.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 = gimple_call_arg (stmt, 0);
> +  tree off = gimple_call_arg (stmt, 1);
> +
> +  if (integer_zerop (off))
> +    {
> +      gsi_remove (gsip, true);
> +      unlink_stmt_vdef (stmt);
> +      return true;
> +    }
> +
> +  basic_block cur_bb = gsi_bb (gsi);
> +  tree ptrplusoff = make_ssa_name (pointer_sized_int_node);
> +  tree ptri = make_ssa_name (pointer_sized_int_node);
> +  int pos_neg = get_range_pos_neg (off);
> +
> +  /* Split the original block holding the pointer dereference.  */
> +  edge e = split_block (cur_bb, stmt);
> +
> +  /* Get a hold on the 'condition block', the 'then block' and the
> +     'else block'.  */
> +  basic_block cond_bb = e->src;
> +  basic_block fallthru_bb = e->dest;
> +  basic_block then_bb = create_empty_bb (cond_bb);
> +  basic_block cond_pos_bb = NULL, cond_neg_bb = NULL;
> +  add_bb_to_loop (then_bb, cond_bb->loop_father);
> +  loops_state_set (LOOPS_NEED_FIXUP);
> +
> +  /* Set up the fallthrough basic block.  */
> +  e->flags = EDGE_FALSE_VALUE;
> +  if (pos_neg != 3)
> +    {
> +      e->count = cond_bb->count;
> +      e->probability = profile_probability::very_likely ();
> +
> +      /* Connect 'then block' with the 'else block'.  This is needed
> +	 as the ubsan routines we call in the 'then block' are not noreturn.
> +	 The 'then block' only has one outcoming edge.  */
> +      make_single_succ_edge (then_bb, fallthru_bb, EDGE_FALLTHRU);
> +
> +      /* Make an edge coming from the 'cond block' into the 'then block';
> +	 this edge is unlikely taken, so set up the probability
> +	 accordingly.  */
> +      e = make_edge (cond_bb, then_bb, EDGE_TRUE_VALUE);
> +      e->probability = profile_probability::very_unlikely ();
> +    }
> +  else
> +    {
> +      profile_count count = cond_bb->count.apply_probability (PROB_EVEN);
> +      e->count = count;
> +      e->probability = profile_probability::even ();
> +
> +      e = split_block (fallthru_bb, (gimple *) NULL);
> +      cond_neg_bb = e->src;
> +      fallthru_bb = e->dest;
> +      e->count = count;
> +      e->probability = profile_probability::very_likely ();
> +      e->flags = EDGE_FALSE_VALUE;
> +
> +      e = make_edge (cond_neg_bb, then_bb, EDGE_TRUE_VALUE);
> +      e->probability = profile_probability::very_unlikely ();
> +
> +      cond_pos_bb = create_empty_bb (cond_bb);
> +      add_bb_to_loop (cond_pos_bb, cond_bb->loop_father);
> +
> +      e = make_edge (cond_bb, cond_pos_bb, EDGE_TRUE_VALUE);
> +      e->count = count;
> +      e->probability = profile_probability::even ();
> +
> +      e = make_edge (cond_pos_bb, then_bb, EDGE_TRUE_VALUE);
> +      e->probability = profile_probability::very_unlikely ();
> +
> +      e = make_edge (cond_pos_bb, fallthru_bb, EDGE_FALSE_VALUE);
> +      e->count = count;
> +      e->probability = profile_probability::very_likely ();
> +
> +      make_single_succ_edge (then_bb, fallthru_bb, EDGE_FALLTHRU);
> +    }
> +
> +  gimple *g = gimple_build_assign (ptri, NOP_EXPR, ptr);
> +  gimple_set_location (g, loc);
> +  gsi_insert_before (&gsi, g, GSI_SAME_STMT);
> +  g = gimple_build_assign (ptrplusoff, PLUS_EXPR, ptri, off);
> +  gimple_set_location (g, loc);
> +  gsi_insert_before (&gsi, g, GSI_SAME_STMT);
> +
> +  /* Update dominance info for the newly created then_bb; note that
> +     fallthru_bb's dominance info has already been updated by
> +     split_block.  */
> +  if (dom_info_available_p (CDI_DOMINATORS))
> +    {
> +      set_immediate_dominator (CDI_DOMINATORS, then_bb, cond_bb);
> +      if (pos_neg == 3)
> +	{
> +	  set_immediate_dominator (CDI_DOMINATORS, cond_pos_bb, cond_bb);
> +	  set_immediate_dominator (CDI_DOMINATORS, fallthru_bb, cond_bb);
> +	}
> +    }
> +
> +  /* Put the ubsan builtin call into the newly created BB.  */
> +  if (flag_sanitize_undefined_trap_on_error)
> +    g = gimple_build_call (builtin_decl_implicit (BUILT_IN_TRAP), 0);
> +  else
> +    {
> +      enum built_in_function bcode
> +	= (flag_sanitize_recover & SANITIZE_POINTER_OVERFLOW)
> +	  ? BUILT_IN_UBSAN_HANDLE_POINTER_OVERFLOW
> +	  : BUILT_IN_UBSAN_HANDLE_POINTER_OVERFLOW_ABORT;
> +      tree fn = builtin_decl_implicit (bcode);
> +      tree data
> +	= ubsan_create_data ("__ubsan_ptrovf_data", 1, &loc,
> +			     NULL_TREE, NULL_TREE);
> +      data = build_fold_addr_expr_loc (loc, data);
> +      g = gimple_build_call (fn, 3, data, ptr, ptrplusoff);
> +    }
> +  gimple_stmt_iterator gsi2 = gsi_start_bb (then_bb);
> +  gimple_set_location (g, loc);
> +  gsi_insert_after (&gsi2, g, GSI_NEW_STMT);
> +
> +  /* Unlink the UBSAN_PTRs vops before replacing it.  */
> +  unlink_stmt_vdef (stmt);
> +
> +  if (TREE_CODE (off) == INTEGER_CST)
> +    g = gimple_build_cond (wi::neg_p (off) ? LT_EXPR : GE_EXPR, ptri,
> +			   fold_build1 (NEGATE_EXPR, sizetype, off),
> +			   NULL_TREE, NULL_TREE);
> +  else if (pos_neg != 3)
> +    g = gimple_build_cond (pos_neg == 1 ? LT_EXPR : GT_EXPR,
> +			   ptrplusoff, ptri, NULL_TREE, NULL_TREE);
> +  else
> +    {
> +      gsi2 = gsi_start_bb (cond_pos_bb);
> +      g = gimple_build_cond (LT_EXPR, ptrplusoff, ptri, NULL_TREE, NULL_TREE);
> +      gimple_set_location (g, loc);
> +      gsi_insert_after (&gsi2, g, GSI_NEW_STMT);
> +
> +      gsi2 = gsi_start_bb (cond_neg_bb);
> +      g = gimple_build_cond (GT_EXPR, ptrplusoff, ptri, NULL_TREE, NULL_TREE);
> +      gimple_set_location (g, loc);
> +      gsi_insert_after (&gsi2, g, GSI_NEW_STMT);
> +
> +      gimple_seq seq = NULL;
> +      tree t = gimple_build (&seq, loc, NOP_EXPR, ssizetype, off);
> +      t = gimple_build (&seq, loc, GE_EXPR, boolean_type_node,
> +			t, ssize_int (0));
> +      gsi_insert_seq_before (&gsi, seq, GSI_SAME_STMT);
> +      g = gimple_build_cond (NE_EXPR, t, boolean_false_node,
> +			     NULL_TREE, NULL_TREE);
> +    }
> +  gimple_set_location (g, loc);
> +  /* Replace the UBSAN_PTR with a GIMPLE_COND stmt.  */
> +  gsi_replace (&gsi, g, false);
> +  return false;
> +}
> +
> +
>  /* Cached __ubsan_vptr_type_cache decl.  */
>  static GTY(()) tree ubsan_vptr_type_cache_decl;
>  
> @@ -1234,6 +1400,111 @@ instrument_null (gimple_stmt_iterator gs
>      instrument_mem_ref (t, base, &gsi, is_lhs);
>  }
>  
> +/* Instrument pointer arithmetics PTR p+ OFF.  */
> +
> +static void
> +instrument_pointer_overflow (gimple_stmt_iterator *gsi, tree ptr, tree off)
> +{
> +  if (TYPE_PRECISION (sizetype) != POINTER_SIZE)
> +    return;
> +  gcall *g = gimple_build_call_internal (IFN_UBSAN_PTR, 2, ptr, off);
> +  gimple_set_location (g, gimple_location (gsi_stmt (*gsi)));
> +  gsi_insert_before (gsi, g, GSI_SAME_STMT);
> +}
> +
> +/* Instrument pointer arithmetics if any.  */
> +
> +static void
> +maybe_instrument_pointer_overflow (gimple_stmt_iterator *gsi, tree t)
> +{
> +  if (TYPE_PRECISION (sizetype) != POINTER_SIZE)
> +    return;
> +
> +  /* Handle also e.g. &s->i.  */
> +  if (TREE_CODE (t) == ADDR_EXPR)
> +    t = TREE_OPERAND (t, 0);
> +
> +  if (!handled_component_p (t) && TREE_CODE (t) != MEM_REF)
> +    return;
> +
> +  HOST_WIDE_INT bitsize, bitpos, bytepos;
> +  tree offset;
> +  machine_mode mode;
> +  int volatilep = 0, reversep, unsignedp = 0;
> +  tree inner = get_inner_reference (t, &bitsize, &bitpos, &offset, &mode,
> +				    &unsignedp, &reversep, &volatilep);
> +  tree moff = NULL_TREE;
> +
> +  bool decl_p = DECL_P (inner);
> +  tree base;
> +  if (decl_p)
> +    {
> +      if (DECL_REGISTER (inner))
> +	return;
> +      base = inner;
> +      /* If BASE is a fixed size automatic variable or
> +	 global variable defined in the current TU and bitpos
> +	 fits, don't instrument anything.  */
> +      if (offset == NULL_TREE
> +	  && bitpos > 0
> +	  && (VAR_P (base)
> +	      || TREE_CODE (base) == PARM_DECL
> +	      || TREE_CODE (base) == RESULT_DECL)
> +	  && DECL_SIZE (base)
> +	  && TREE_CODE (DECL_SIZE (base)) == INTEGER_CST
> +	  && compare_tree_int (DECL_SIZE (base), bitpos) >= 0
> +	  && (!is_global_var (base) || decl_binds_to_current_def_p (base)))
> +	return;
> +    }
> +  else if (TREE_CODE (inner) == MEM_REF)
> +    {
> +      base = TREE_OPERAND (inner, 0);
> +      if (TREE_CODE (base) == ADDR_EXPR
> +	  && DECL_P (TREE_OPERAND (base, 0))
> +	  && !TREE_ADDRESSABLE (TREE_OPERAND (base, 0))
> +	  && !is_global_var (TREE_OPERAND (base, 0)))
> +	return;
> +      moff = TREE_OPERAND (inner, 1);
> +      if (integer_zerop (moff))
> +	moff = NULL_TREE;
> +    }
> +  else
> +    return;
> +
> +  if (!POINTER_TYPE_P (TREE_TYPE (base)) && !DECL_P (base))
> +    return;
> +  bytepos = bitpos / BITS_PER_UNIT;
> +  if (offset == NULL_TREE && bytepos == 0 && moff == NULL_TREE)
> +    return;
> +
> +  tree base_addr = base;
> +  if (decl_p)
> +    base_addr = build1 (ADDR_EXPR,
> +			build_pointer_type (TREE_TYPE (base)), base);
> +  t = offset;
> +  if (bytepos)
> +    {
> +      if (t)
> +	t = fold_build2 (PLUS_EXPR, TREE_TYPE (t), t,
> +			 build_int_cst (TREE_TYPE (t), bytepos));
> +      else
> +	t = size_int (bytepos);
> +    }
> +  if (moff)
> +    {
> +      if (t)
> +	t = fold_build2 (PLUS_EXPR, TREE_TYPE (t), t,
> +			 fold_convert (TREE_TYPE (t), moff));
> +      else
> +	t = fold_convert (sizetype, moff);
> +    }
> +  t = force_gimple_operand_gsi (gsi, t, true, NULL_TREE, true,
> +				GSI_SAME_STMT);
> +  base_addr = force_gimple_operand_gsi (gsi, base_addr, true, NULL_TREE, true,
> +					GSI_SAME_STMT);
> +  instrument_pointer_overflow (gsi, base_addr, t);
> +}
> +
>  /* Build an ubsan builtin call for the signed-integer-overflow
>     sanitization.  CODE says what kind of builtin are we building,
>     LOC is a location, LHSTYPE is the type of LHS, OP0 and OP1
> @@ -1849,7 +2120,7 @@ instrument_object_size (gimple_stmt_iter
>  	{
>  	  tree rhs1 = gimple_assign_rhs1 (def_stmt);
>  	  if (TREE_CODE (rhs1) == SSA_NAME
> -	    && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs1))
> +	      && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs1))
>  	    break;
>  	  else
>  	    base = rhs1;
> @@ -1973,7 +2244,8 @@ public:
>  				| SANITIZE_ALIGNMENT
>  				| SANITIZE_NONNULL_ATTRIBUTE
>  				| SANITIZE_RETURNS_NONNULL_ATTRIBUTE
> -				| SANITIZE_OBJECT_SIZE));
> +				| SANITIZE_OBJECT_SIZE
> +				| SANITIZE_POINTER_OVERFLOW));
>      }
>  
>    virtual unsigned int execute (function *);
> @@ -2064,6 +2336,32 @@ pass_ubsan::execute (function *fun)
>  		    }
>  		}
>  	    }
> +
> +	  if (sanitize_flags_p (SANITIZE_POINTER_OVERFLOW, fun->decl))
> +	    {
> +	      if (is_gimple_assign (stmt)
> +		  && gimple_assign_rhs_code (stmt) == POINTER_PLUS_EXPR)
> +		instrument_pointer_overflow (&gsi,
> +					     gimple_assign_rhs1 (stmt),
> +					     gimple_assign_rhs2 (stmt));
> +	      if (gimple_store_p (stmt))
> +		maybe_instrument_pointer_overflow (&gsi,
> +						   gimple_get_lhs (stmt));
> +	      if (gimple_assign_single_p (stmt))
> +		maybe_instrument_pointer_overflow (&gsi,
> +						   gimple_assign_rhs1 (stmt));
> +	      if (is_gimple_call (stmt))
> +		{
> +		  unsigned args_num = gimple_call_num_args (stmt);
> +		  for (unsigned i = 0; i < args_num; ++i)
> +		    {
> +		      tree arg = gimple_call_arg (stmt, i);
> +		      if (is_gimple_reg (arg))
> +			continue;
> +		      maybe_instrument_pointer_overflow (&gsi, arg);
> +		    }
> +		}
> +	    }
>  
>  	  gsi_next (&gsi);
>  	}
> --- gcc/internal-fn.c.jj	2017-07-17 10:08:34.923647976 +0200
> +++ gcc/internal-fn.c	2017-07-26 13:44:13.837204592 +0200
> @@ -402,6 +402,14 @@ expand_UBSAN_VPTR (internal_fn, gcall *)
>  /* This should get expanded in the sanopt pass.  */
>  
>  static void
> +expand_UBSAN_PTR (internal_fn, gcall *)
> +{
> +  gcc_unreachable ();
> +}
> +
> +/* This should get expanded in the sanopt pass.  */
> +
> +static void
>  expand_UBSAN_OBJECT_SIZE (internal_fn, gcall *)
>  {
>    gcc_unreachable ();
> --- gcc/ubsan.h.jj	2017-06-20 09:05:22.498654128 +0200
> +++ gcc/ubsan.h	2017-07-26 13:44:13.837204592 +0200
> @@ -52,6 +52,7 @@ enum ubsan_encode_value_phase {
>  extern bool ubsan_expand_bounds_ifn (gimple_stmt_iterator *);
>  extern bool ubsan_expand_null_ifn (gimple_stmt_iterator *);
>  extern bool ubsan_expand_objsize_ifn (gimple_stmt_iterator *);
> +extern bool ubsan_expand_ptr_ifn (gimple_stmt_iterator *);
>  extern bool ubsan_expand_vptr_ifn (gimple_stmt_iterator *);
>  extern bool ubsan_instrument_unreachable (gimple_stmt_iterator *);
>  extern tree ubsan_create_data (const char *, int, const location_t *, ...);
> --- gcc/sanitizer.def.jj	2017-07-06 20:31:32.835082221 +0200
> +++ gcc/sanitizer.def	2017-07-26 13:44:13.837204592 +0200
> @@ -448,6 +448,10 @@ DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HAN
>  		      "__ubsan_handle_load_invalid_value",
>  		      BT_FN_VOID_PTR_PTR,
>  		      ATTR_COLD_NOTHROW_LEAF_LIST)
> +DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_POINTER_OVERFLOW,
> +		      "__ubsan_handle_pointer_overflow",
> +		      BT_FN_VOID_PTR_PTR_PTR,
> +		      ATTR_COLD_NOTHROW_LEAF_LIST)
>  DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW_ABORT,
>  		      "__ubsan_handle_divrem_overflow_abort",
>  		      BT_FN_VOID_PTR_PTR_PTR,
> @@ -484,6 +488,10 @@ DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HAN
>  		      "__ubsan_handle_load_invalid_value_abort",
>  		      BT_FN_VOID_PTR_PTR,
>  		      ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST)
> +DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_POINTER_OVERFLOW_ABORT,
> +		      "__ubsan_handle_pointer_overflow_abort",
> +		      BT_FN_VOID_PTR_PTR_PTR,
> +		      ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST)
>  DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_FLOAT_CAST_OVERFLOW,
>  		      "__ubsan_handle_float_cast_overflow",
>  		      BT_FN_VOID_PTR_PTR,
> --- gcc/tree-ssa-tail-merge.c.jj	2017-07-03 19:03:29.467756294 +0200
> +++ gcc/tree-ssa-tail-merge.c	2017-07-26 13:44:13.838204580 +0200
> @@ -1241,6 +1241,7 @@ merge_stmts_p (gimple *stmt1, gimple *st
>        case IFN_UBSAN_CHECK_SUB:
>        case IFN_UBSAN_CHECK_MUL:
>        case IFN_UBSAN_OBJECT_SIZE:
> +      case IFN_UBSAN_PTR:
>        case IFN_ASAN_CHECK:
>  	/* For these internal functions, gimple_location is an implicit
>  	   parameter, which will be used explicitly after expansion.
> --- gcc/internal-fn.def.jj	2017-07-06 20:31:43.930946892 +0200
> +++ gcc/internal-fn.def	2017-07-26 13:44:13.838204580 +0200
> @@ -166,6 +166,7 @@ DEF_INTERNAL_FN (UBSAN_VPTR, ECF_LEAF |
>  DEF_INTERNAL_FN (UBSAN_CHECK_ADD, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL)
>  DEF_INTERNAL_FN (UBSAN_CHECK_SUB, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL)
>  DEF_INTERNAL_FN (UBSAN_CHECK_MUL, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL)
> +DEF_INTERNAL_FN (UBSAN_PTR, ECF_LEAF | ECF_NOTHROW, ".R.")
>  DEF_INTERNAL_FN (UBSAN_OBJECT_SIZE, ECF_LEAF | ECF_NOTHROW, NULL)
>  DEF_INTERNAL_FN (ABNORMAL_DISPATCHER, ECF_NORETURN, NULL)
>  DEF_INTERNAL_FN (BUILTIN_EXPECT, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL)
> --- gcc/opts.c.jj	2017-07-26 13:37:44.955908409 +0200
> +++ gcc/opts.c	2017-07-26 13:44:13.839204567 +0200
> @@ -1521,6 +1521,7 @@ const struct sanitizer_opts_s sanitizer_
>  		 true),
>    SANITIZER_OPT (object-size, SANITIZE_OBJECT_SIZE, true),
>    SANITIZER_OPT (vptr, SANITIZE_VPTR, true),
> +  SANITIZER_OPT (pointer-overflow, SANITIZE_POINTER_OVERFLOW, true),
>    SANITIZER_OPT (all, ~0U, true),
>  #undef SANITIZER_OPT
>    { NULL, 0U, 0UL, false }
> --- gcc/lto-streamer-in.c.jj	2017-06-30 09:49:28.006662098 +0200
> +++ gcc/lto-streamer-in.c	2017-07-26 13:44:13.840204555 +0200
> @@ -1143,6 +1143,10 @@ input_function (tree fn_decl, struct dat
>  		      if ((flag_sanitize & SANITIZE_OBJECT_SIZE) == 0)
>  			remove = true;
>  		      break;
> +		    case IFN_UBSAN_PTR:
> +		      if ((flag_sanitize & SANITIZE_POINTER_OVERFLOW) == 0)
> +			remove = true;
> +		      break;
>  		    case IFN_ASAN_MARK:
>  		      if ((flag_sanitize & SANITIZE_ADDRESS) == 0)
>  			remove = true;
> --- gcc/fold-const.c.jj	2017-07-25 12:19:45.423601159 +0200
> +++ gcc/fold-const.c	2017-07-26 14:59:51.908708150 +0200
> @@ -4859,21 +4859,21 @@ build_range_check (location_t loc, tree
>  
>    if (low == 0)
>      return fold_build2_loc (loc, LE_EXPR, type, exp,
> -			fold_convert_loc (loc, etype, high));
> +			    fold_convert_loc (loc, etype, high));
>  
>    if (high == 0)
>      return fold_build2_loc (loc, GE_EXPR, type, exp,
> -			fold_convert_loc (loc, etype, low));
> +			    fold_convert_loc (loc, etype, low));
>  
>    if (operand_equal_p (low, high, 0))
>      return fold_build2_loc (loc, EQ_EXPR, type, exp,
> -			fold_convert_loc (loc, etype, low));
> +			    fold_convert_loc (loc, etype, low));
>  
>    if (TREE_CODE (exp) == BIT_AND_EXPR
>        && maskable_range_p (low, high, etype, &mask, &value))
>      return fold_build2_loc (loc, EQ_EXPR, type,
>  			    fold_build2_loc (loc, BIT_AND_EXPR, etype,
> -					      exp, mask),
> +					     exp, mask),
>  			    value);
>  
>    if (integer_zerop (low))
> @@ -4905,7 +4905,7 @@ build_range_check (location_t loc, tree
>  	      exp = fold_convert_loc (loc, etype, exp);
>  	    }
>  	  return fold_build2_loc (loc, GT_EXPR, type, exp,
> -			      build_int_cst (etype, 0));
> +				  build_int_cst (etype, 0));
>  	}
>      }
>  
> @@ -4915,25 +4915,15 @@ build_range_check (location_t loc, tree
>    if (etype == NULL_TREE)
>      return NULL_TREE;
>  
> +  if (POINTER_TYPE_P (etype))
> +    etype = unsigned_type_for (etype);
> +
>    high = fold_convert_loc (loc, etype, high);
>    low = fold_convert_loc (loc, etype, low);
>    exp = fold_convert_loc (loc, etype, exp);
>  
>    value = const_binop (MINUS_EXPR, high, low);
>  
> -
> -  if (POINTER_TYPE_P (etype))
> -    {
> -      if (value != 0 && !TREE_OVERFLOW (value))
> -	{
> -	  low = fold_build1_loc (loc, NEGATE_EXPR, TREE_TYPE (low), low);
> -          return build_range_check (loc, type,
> -			     	    fold_build_pointer_plus_loc (loc, exp, low),
> -			            1, build_int_cst (etype, 0), value);
> -	}
> -      return 0;
> -    }
> -
>    if (value != 0 && !TREE_OVERFLOW (value))
>      return build_range_check (loc, type,
>  			      fold_build2_loc (loc, MINUS_EXPR, etype, exp, low),
> --- gcc/testsuite/c-c++-common/ubsan/ptr-overflow-1.c.jj	2017-07-26 13:44:13.840204555 +0200
> +++ gcc/testsuite/c-c++-common/ubsan/ptr-overflow-1.c	2017-07-26 13:44:13.840204555 +0200
> @@ -0,0 +1,65 @@
> +/* PR sanitizer/80998 */
> +/* { dg-do run } */
> +/* { dg-options "-fsanitize=pointer-overflow -fno-sanitize-recover=pointer-overflow -Wall" } */
> +
> +struct S { int a; int b; int c[64]; };
> +__attribute__((noinline, noclone)) char *f1 (char *p) { return p + 1; }
> +__attribute__((noinline, noclone)) char *f2 (char *p) { return p - 1; }
> +__attribute__((noinline, noclone)) char *f3 (char *p, int i) { return p + i; }
> +__attribute__((noinline, noclone)) char *f4 (char *p, int i) { return p - i; }
> +__attribute__((noinline, noclone)) char *f5 (char *p, unsigned long int i) { return p + i; }
> +__attribute__((noinline, noclone)) char *f6 (char *p, unsigned long int i) { return p - i; }
> +__attribute__((noinline, noclone)) int *f7 (struct S *p) { return &p->a; }
> +__attribute__((noinline, noclone)) int *f8 (struct S *p) { return &p->b; }
> +__attribute__((noinline, noclone)) int *f9 (struct S *p) { return &p->c[64]; }
> +__attribute__((noinline, noclone)) int *f10 (struct S *p, int i) { return &p->c[i]; }
> +
> +char *volatile p;
> +struct S *volatile q;
> +char a[64];
> +struct S s;
> +int *volatile r;
> +
> +int
> +main ()
> +{
> +  struct S t;
> +  p = &a[32];
> +  p = f1 (p);
> +  p = f1 (p);
> +  p = f2 (p);
> +  p = f3 (p, 1);
> +  p = f3 (p, -1);
> +  p = f3 (p, 3);
> +  p = f3 (p, -6);
> +  p = f4 (p, 1);
> +  p = f4 (p, -1);
> +  p = f4 (p, 3);
> +  p = f4 (p, -6);
> +  p = f5 (p, 1);
> +  p = f5 (p, 3);
> +  p = f6 (p, 1);
> +  p = f6 (p, 3);
> +  if (sizeof (unsigned long) >= sizeof (char *))
> +    {
> +      p = f5 (p, -1);
> +      p = f5 (p, -6);
> +      p = f6 (p, -1);
> +      p = f6 (p, -6);
> +    }
> +  q = &s;
> +  r = f7 (q);
> +  r = f8 (q);
> +  r = f9 (q);
> +  r = f10 (q, 0);
> +  r = f10 (q, 10);
> +  r = f10 (q, 64);
> +  q = &t;
> +  r = f7 (q);
> +  r = f8 (q);
> +  r = f9 (q);
> +  r = f10 (q, 0);
> +  r = f10 (q, 10);
> +  r = f10 (q, 64);
> +  return 0;
> +}
> --- gcc/testsuite/c-c++-common/ubsan/ptr-overflow-2.c.jj	2017-07-26 13:44:13.840204555 +0200
> +++ gcc/testsuite/c-c++-common/ubsan/ptr-overflow-2.c	2017-07-26 13:44:13.840204555 +0200
> @@ -0,0 +1,113 @@
> +/* PR sanitizer/80998 */
> +/* { dg-do run } */
> +/* { dg-options "-fsanitize=pointer-overflow -fsanitize-recover=pointer-overflow -fno-ipa-icf -Wall" } */
> +
> +__attribute__((noinline, noclone)) char * f1 (char *p) { return p + 1; }
> +__attribute__((noinline, noclone)) char * f2 (char *p) { return p - 1; }
> +__attribute__((noinline, noclone)) char * f3 (char *p, int i) { return p + i; }
> +__attribute__((noinline, noclone)) char * f4 (char *p, int i) { return p + i; }
> +__attribute__((noinline, noclone)) char * f5 (char *p, int i) { return p - i; }
> +__attribute__((noinline, noclone)) char * f6 (char *p, int i) { return p - i; }
> +__attribute__((noinline, noclone)) char * f7 (char *p, unsigned long int i) { return p + i; }
> +__attribute__((noinline, noclone)) char * f8 (char *p, unsigned long int i) { return p + i; }
> +__attribute__((noinline, noclone)) char * f9 (char *p, unsigned long int i) { return p - i; }
> +__attribute__((noinline, noclone)) char * f10 (char *p, unsigned long int i) { return p - i; }
> +struct S { int a; int b; int c[64]; };
> +__attribute__((noinline, noclone)) int *f11 (struct S *p) { return &p->a; }
> +__attribute__((noinline, noclone)) int *f12 (struct S *p) { return &p->b; }
> +__attribute__((noinline, noclone)) int *f13 (struct S *p) { return &p->c[64]; }
> +__attribute__((noinline, noclone)) int *f14 (struct S *p, int i) { return &p->c[i]; }
> +__attribute__((noinline, noclone)) int *f15 (struct S *p, int i) { return &p->c[i]; }
> +__attribute__((noinline, noclone)) int *f16 (struct S *p) { return &p->a; }
> +__attribute__((noinline, noclone)) int *f17 (struct S *p) { return &p->b; }
> +__attribute__((noinline, noclone)) int *f18 (struct S *p) { return &p->c[64]; }
> +__attribute__((noinline, noclone)) int *f19 (struct S *p, int i) { return &p->c[i]; }
> +__attribute__((noinline, noclone)) int *f20 (struct S *p, int i) { return &p->c[i]; }
> +__attribute__((noinline, noclone)) int *f21 (struct S *p) { return &p->a; }
> +__attribute__((noinline, noclone)) int *f22 (struct S *p) { return &p->b; }
> +__attribute__((noinline, noclone)) int *f23 (struct S *p) { return &p->c[64]; }
> +__attribute__((noinline, noclone)) int *f24 (struct S *p, int i) { return &p->c[i]; }
> +__attribute__((noinline, noclone)) int *f25 (struct S *p, int i) { return &p->c[i]; }
> +
> +char *volatile p;
> +__UINTPTR_TYPE__ volatile u;
> +struct S *volatile q;
> +int *volatile r;
> +
> +int
> +main ()
> +{
> +  u = ~(__UINTPTR_TYPE__) 0;
> +  p = (char *) u;
> +  p = f1 (p);
> +  u = 0;
> +  p = (char *) u;
> +  p = f2 (p);
> +  u = -(__UINTPTR_TYPE__) 7;
> +  p = (char *) u;
> +  p = f3 (p, 7);
> +  u = 3;
> +  p = (char *) u;
> +  p = f4 (p, -4);
> +  u = 23;
> +  p = (char *) u;
> +  p = f5 (p, 27);
> +  u = -(__UINTPTR_TYPE__) 15;
> +  p = (char *) u;
> +  p = f6 (p, -15);
> +  u = -(__UINTPTR_TYPE__) 29;
> +  p = (char *) u;
> +  p = f7 (p, 31);
> +  u = 23;
> +  p = (char *) u;
> +  p = f9 (p, 24);
> +  if (sizeof (unsigned long) < sizeof (char *))
> +    return 0;
> +  u = 7;
> +  p = (char *) u;
> +  p = f8 (p, -8);
> +  u = -(__UINTPTR_TYPE__) 25;
> +  p = (char *) u;
> +  p = f10 (p, -25);
> +  u = ~(__UINTPTR_TYPE__) 0;
> +  q = (struct S *) u;
> +  r = f11 (q);
> +  r = f12 (q);
> +  r = f13 (q);
> +  r = f14 (q, 0);
> +  r = f15 (q, 63);
> +  u = ~(__UINTPTR_TYPE__) 0 - (17 * sizeof (int));
> +  q = (struct S *) u;
> +  r = f16 (q);
> +  r = f17 (q);
> +  r = f18 (q);
> +  r = f19 (q, 0);
> +  r = f20 (q, 63);
> +  u = 3 * sizeof (int);
> +  q = (struct S *) u;
> +  r = f21 (q);
> +  r = f22 (q);
> +  r = f23 (q);
> +  r = f24 (q, -2);
> +  r = f25 (q, -6);
> +  return 0;
> +}
> +
> +/* { dg-output ":5:6\[79]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+ overflowed to (0\[xX])?0\+(\n|\r\n|\r)" } */
> +/* { dg-output "\[^\n\r]*:6:6\[79]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?0\+ overflowed to (0\[xX])?\[fF]\+(\n|\r\n|\r)" } */
> +/* { dg-output "\[^\n\r]*:7:7\[46]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+9 overflowed to (0\[xX])?0\+(\n|\r\n|\r)" } */
> +/* { dg-output "\[^\n\r]*:8:7\[46]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?0\+3 overflowed to (0\[xX])?\[fF]\+(\n|\r\n|\r)" } */
> +/* { dg-output "\[^\n\r]*:9:7\[46]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?0\+17 overflowed to (0\[xX])?\[fF]\+\[cC](\n|\r\n|\r)" } */
> +/* { dg-output "\[^\n\r]*:10:7\[46]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+1 overflowed to (0\[xX])?0\+(\n|\r\n|\r)" } */
> +/* { dg-output "\[^\n\r]*:11:\[89]\[80]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+\[eE]3 overflowed to (0\[xX])?0\+2(\n|\r\n|\r)" } */
> +/* { dg-output "\[^\n\r]*:13:\[89]\[80]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?0\+17 overflowed to (0\[xX])?\[fF]\+(\n|\r\n|\r)" } */
> +/* { dg-output "\[^\n\r]*:12:\[89]\[80]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?0\+7 overflowed to (0\[xX])?\[fF]\+(\n|\r\n|\r)" } */
> +/* { dg-output "\[^\n\r]*:14:\[89]\[91]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+\[eE]7 overflowed to (0\[xX])?0\+" } */
> +/* { dg-output "(\n|\r\n|\r)" { target int32 } } */
> +/* { dg-output "\[^\n\r]*:17:\[67]\[82]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+ overflowed to (0\[xX])?0\+3(\n|\r\n|\r)" { target int32 } } */
> +/* { dg-output "\[^\n\r]*:18:\[67]\[86]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+ overflowed to (0\[xX])?0\+107(\n|\r\n|\r)" { target int32 } } */
> +/* { dg-output "\[^\n\r]*:19:\[78]\[52]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+ overflowed to (0\[xX])?0\+7(\n|\r\n|\r)" { target int32 } } */
> +/* { dg-output "\[^\n\r]*:20:\[78]\[52]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+ overflowed to (0\[xX])?0\+103(\n|\r\n|\r)" { target int32 } } */
> +/* { dg-output "\[^\n\r]*:23:\[67]\[86]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+\[bB]\[bB] overflowed to (0\[xX])?0\+\[cC]3(\n|\r\n|\r)" { target int32 } } */
> +/* { dg-output "\[^\n\r]*:25:\[78]\[52]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+\[bB]\[bB] overflowed to (0\[xX])?0\+\[bB]\[fF](\n|\r\n|\r)" { target int32 } } */
> +/* { dg-output "\[^\n\r]*:30:\[78]\[52]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?0\+\[cC] overflowed to (0\[xX])?\[fF]\+\[cC]" { target int32 } } */
> --- libsanitizer/ubsan/ubsan_handlers.cc.jj	2017-06-19 08:26:17.073600279 +0200
> +++ libsanitizer/ubsan/ubsan_handlers.cc	2017-07-26 13:44:14.261199463 +0200
> @@ -521,6 +521,37 @@ void __ubsan::__ubsan_handle_nonnull_arg
>    Die();
>  }
>  
> +static void handlePointerOverflowImpl(PointerOverflowData *Data,
> +                                      ValueHandle Base,
> +                                      ValueHandle Result,
> +                                      ReportOptions Opts) {
> +  SourceLocation Loc = Data->Loc.acquire();
> +  ErrorType ET = ErrorType::PointerOverflow;
> +
> +  if (ignoreReport(Loc, Opts, ET))
> +    return;
> +
> +  ScopedReport R(Opts, Loc, ET);
> +
> +  Diag(Loc, DL_Error, "pointer index expression with base %0 overflowed to %1")
> +    << (void *)Base << (void*)Result;
> +}
> +
> +void __ubsan::__ubsan_handle_pointer_overflow(PointerOverflowData *Data,
> +                                              ValueHandle Base,
> +                                              ValueHandle Result) {
> +  GET_REPORT_OPTIONS(false);
> +  handlePointerOverflowImpl(Data, Base, Result, Opts);
> +}
> +
> +void __ubsan::__ubsan_handle_pointer_overflow_abort(PointerOverflowData *Data,
> +                                                    ValueHandle Base,
> +                                                    ValueHandle Result) {
> +  GET_REPORT_OPTIONS(true);
> +  handlePointerOverflowImpl(Data, Base, Result, Opts);
> +  Die();
> +}
> +
>  static void handleCFIBadIcall(CFICheckFailData *Data, ValueHandle Function,
>                                ReportOptions Opts) {
>    if (Data->CheckKind != CFITCK_ICall)
> --- libsanitizer/ubsan/ubsan_checks.inc.jj	2017-06-19 08:26:17.061600432 +0200
> +++ libsanitizer/ubsan/ubsan_checks.inc	2017-07-26 13:44:14.275199294 +0200
> @@ -17,6 +17,7 @@
>  
>  UBSAN_CHECK(GenericUB, "undefined-behavior", "undefined")
>  UBSAN_CHECK(NullPointerUse, "null-pointer-use", "null")
> +UBSAN_CHECK(PointerOverflow, "pointer-overflow", "pointer-overflow")
>  UBSAN_CHECK(MisalignedPointerUse, "misaligned-pointer-use", "alignment")
>  UBSAN_CHECK(InsufficientObjectSize, "insufficient-object-size", "object-size")
>  UBSAN_CHECK(SignedIntegerOverflow, "signed-integer-overflow",
> --- libsanitizer/ubsan/ubsan_handlers.h.jj	2017-06-19 08:26:17.073600279 +0200
> +++ libsanitizer/ubsan/ubsan_handlers.h	2017-07-26 13:44:14.282199209 +0200
> @@ -146,6 +146,13 @@ struct NonNullArgData {
>  /// \brief Handle passing null pointer to function with nonnull attribute.
>  RECOVERABLE(nonnull_arg, NonNullArgData *Data)
>  
> +struct PointerOverflowData {
> +  SourceLocation Loc;
> +};
> +
> +RECOVERABLE(pointer_overflow, PointerOverflowData *Data, ValueHandle Base,
> +            ValueHandle Result)
> +
>  /// \brief Known CFI check kinds.
>  /// Keep in sync with the enum of the same name in CodeGenFunction.h
>  enum CFITypeCheckKind : unsigned char {
> 
> 
> 	Jakub
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)

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  <jakub@redhat.com>

	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.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 = gimple_call_arg (stmt, 0);
+  tree off = gimple_call_arg (stmt, 1);
+
+  if (integer_zerop (off))
+    {
+      gsi_remove (gsip, true);
+      unlink_stmt_vdef (stmt);
+      return true;
+    }
+
+  basic_block cur_bb = gsi_bb (gsi);
+  tree ptrplusoff = make_ssa_name (pointer_sized_int_node);
+  tree ptri = make_ssa_name (pointer_sized_int_node);
+  int pos_neg = get_range_pos_neg (off);
+
+  /* Split the original block holding the pointer dereference.  */
+  edge e = split_block (cur_bb, stmt);
+
+  /* Get a hold on the 'condition block', the 'then block' and the
+     'else block'.  */
+  basic_block cond_bb = e->src;
+  basic_block fallthru_bb = e->dest;
+  basic_block then_bb = create_empty_bb (cond_bb);
+  basic_block cond_pos_bb = NULL, cond_neg_bb = NULL;
+  add_bb_to_loop (then_bb, cond_bb->loop_father);
+  loops_state_set (LOOPS_NEED_FIXUP);
+
+  /* Set up the fallthrough basic block.  */
+  e->flags = EDGE_FALSE_VALUE;
+  if (pos_neg != 3)
+    {
+      e->count = cond_bb->count;
+      e->probability = profile_probability::very_likely ();
+
+      /* Connect 'then block' with the 'else block'.  This is needed
+	 as the ubsan routines we call in the 'then block' are not noreturn.
+	 The 'then block' only has one outcoming edge.  */
+      make_single_succ_edge (then_bb, fallthru_bb, EDGE_FALLTHRU);
+
+      /* Make an edge coming from the 'cond block' into the 'then block';
+	 this edge is unlikely taken, so set up the probability
+	 accordingly.  */
+      e = make_edge (cond_bb, then_bb, EDGE_TRUE_VALUE);
+      e->probability = profile_probability::very_unlikely ();
+    }
+  else
+    {
+      profile_count count = cond_bb->count.apply_probability (PROB_EVEN);
+      e->count = count;
+      e->probability = profile_probability::even ();
+
+      e = split_block (fallthru_bb, (gimple *) NULL);
+      cond_neg_bb = e->src;
+      fallthru_bb = e->dest;
+      e->count = count;
+      e->probability = profile_probability::very_likely ();
+      e->flags = EDGE_FALSE_VALUE;
+
+      e = make_edge (cond_neg_bb, then_bb, EDGE_TRUE_VALUE);
+      e->probability = profile_probability::very_unlikely ();
+
+      cond_pos_bb = create_empty_bb (cond_bb);
+      add_bb_to_loop (cond_pos_bb, cond_bb->loop_father);
+
+      e = make_edge (cond_bb, cond_pos_bb, EDGE_TRUE_VALUE);
+      e->count = count;
+      e->probability = profile_probability::even ();
+
+      e = make_edge (cond_pos_bb, then_bb, EDGE_TRUE_VALUE);
+      e->probability = profile_probability::very_unlikely ();
+
+      e = make_edge (cond_pos_bb, fallthru_bb, EDGE_FALSE_VALUE);
+      e->count = count;
+      e->probability = profile_probability::very_likely ();
+
+      make_single_succ_edge (then_bb, fallthru_bb, EDGE_FALLTHRU);
+    }
+
+  gimple *g = gimple_build_assign (ptri, NOP_EXPR, ptr);
+  gimple_set_location (g, loc);
+  gsi_insert_before (&gsi, g, GSI_SAME_STMT);
+  g = gimple_build_assign (ptrplusoff, PLUS_EXPR, ptri, off);
+  gimple_set_location (g, loc);
+  gsi_insert_before (&gsi, g, GSI_SAME_STMT);
+
+  /* Update dominance info for the newly created then_bb; note that
+     fallthru_bb's dominance info has already been updated by
+     split_block.  */
+  if (dom_info_available_p (CDI_DOMINATORS))
+    {
+      set_immediate_dominator (CDI_DOMINATORS, then_bb, cond_bb);
+      if (pos_neg == 3)
+	{
+	  set_immediate_dominator (CDI_DOMINATORS, cond_pos_bb, cond_bb);
+	  set_immediate_dominator (CDI_DOMINATORS, fallthru_bb, cond_bb);
+	}
+    }
+
+  /* Put the ubsan builtin call into the newly created BB.  */
+  if (flag_sanitize_undefined_trap_on_error)
+    g = gimple_build_call (builtin_decl_implicit (BUILT_IN_TRAP), 0);
+  else
+    {
+      enum built_in_function bcode
+	= (flag_sanitize_recover & SANITIZE_POINTER_OVERFLOW)
+	  ? BUILT_IN_UBSAN_HANDLE_POINTER_OVERFLOW
+	  : BUILT_IN_UBSAN_HANDLE_POINTER_OVERFLOW_ABORT;
+      tree fn = builtin_decl_implicit (bcode);
+      tree data
+	= ubsan_create_data ("__ubsan_ptrovf_data", 1, &loc,
+			     NULL_TREE, NULL_TREE);
+      data = build_fold_addr_expr_loc (loc, data);
+      g = gimple_build_call (fn, 3, data, ptr, ptrplusoff);
+    }
+  gimple_stmt_iterator gsi2 = gsi_start_bb (then_bb);
+  gimple_set_location (g, loc);
+  gsi_insert_after (&gsi2, g, GSI_NEW_STMT);
+
+  /* Unlink the UBSAN_PTRs vops before replacing it.  */
+  unlink_stmt_vdef (stmt);
+
+  if (TREE_CODE (off) == INTEGER_CST)
+    g = gimple_build_cond (wi::neg_p (off) ? LT_EXPR : GE_EXPR, ptri,
+			   fold_build1 (NEGATE_EXPR, sizetype, off),
+			   NULL_TREE, NULL_TREE);
+  else if (pos_neg != 3)
+    g = gimple_build_cond (pos_neg == 1 ? LT_EXPR : GT_EXPR,
+			   ptrplusoff, ptri, NULL_TREE, NULL_TREE);
+  else
+    {
+      gsi2 = gsi_start_bb (cond_pos_bb);
+      g = gimple_build_cond (LT_EXPR, ptrplusoff, ptri, NULL_TREE, NULL_TREE);
+      gimple_set_location (g, loc);
+      gsi_insert_after (&gsi2, g, GSI_NEW_STMT);
+
+      gsi2 = gsi_start_bb (cond_neg_bb);
+      g = gimple_build_cond (GT_EXPR, ptrplusoff, ptri, NULL_TREE, NULL_TREE);
+      gimple_set_location (g, loc);
+      gsi_insert_after (&gsi2, g, GSI_NEW_STMT);
+
+      gimple_seq seq = NULL;
+      tree t = gimple_build (&seq, loc, NOP_EXPR, ssizetype, off);
+      t = gimple_build (&seq, loc, GE_EXPR, boolean_type_node,
+			t, ssize_int (0));
+      gsi_insert_seq_before (&gsi, seq, GSI_SAME_STMT);
+      g = gimple_build_cond (NE_EXPR, t, boolean_false_node,
+			     NULL_TREE, NULL_TREE);
+    }
+  gimple_set_location (g, loc);
+  /* Replace the UBSAN_PTR with a GIMPLE_COND stmt.  */
+  gsi_replace (&gsi, g, false);
+  return false;
+}
+
+
 /* Cached __ubsan_vptr_type_cache decl.  */
 static GTY(()) tree ubsan_vptr_type_cache_decl;
 
@@ -1234,6 +1400,111 @@ instrument_null (gimple_stmt_iterator gs
     instrument_mem_ref (t, base, &gsi, is_lhs);
 }
 
+/* Instrument pointer arithmetics PTR p+ OFF.  */
+
+static void
+instrument_pointer_overflow (gimple_stmt_iterator *gsi, tree ptr, tree off)
+{
+  if (TYPE_PRECISION (sizetype) != POINTER_SIZE)
+    return;
+  gcall *g = gimple_build_call_internal (IFN_UBSAN_PTR, 2, ptr, off);
+  gimple_set_location (g, gimple_location (gsi_stmt (*gsi)));
+  gsi_insert_before (gsi, g, GSI_SAME_STMT);
+}
+
+/* Instrument pointer arithmetics if any.  */
+
+static void
+maybe_instrument_pointer_overflow (gimple_stmt_iterator *gsi, tree t)
+{
+  if (TYPE_PRECISION (sizetype) != POINTER_SIZE)
+    return;
+
+  /* Handle also e.g. &s->i.  */
+  if (TREE_CODE (t) == ADDR_EXPR)
+    t = TREE_OPERAND (t, 0);
+
+  if (!handled_component_p (t) && TREE_CODE (t) != MEM_REF)
+    return;
+
+  HOST_WIDE_INT bitsize, bitpos, bytepos;
+  tree offset;
+  machine_mode mode;
+  int volatilep = 0, reversep, unsignedp = 0;
+  tree inner = get_inner_reference (t, &bitsize, &bitpos, &offset, &mode,
+				    &unsignedp, &reversep, &volatilep);
+  tree moff = NULL_TREE;
+
+  bool decl_p = DECL_P (inner);
+  tree base;
+  if (decl_p)
+    {
+      if (DECL_REGISTER (inner))
+	return;
+      base = inner;
+      /* If BASE is a fixed size automatic variable or
+	 global variable defined in the current TU and bitpos
+	 fits, don't instrument anything.  */
+      if (offset == NULL_TREE
+	  && bitpos > 0
+	  && (VAR_P (base)
+	      || TREE_CODE (base) == PARM_DECL
+	      || TREE_CODE (base) == RESULT_DECL)
+	  && DECL_SIZE (base)
+	  && TREE_CODE (DECL_SIZE (base)) == INTEGER_CST
+	  && compare_tree_int (DECL_SIZE (base), bitpos) >= 0
+	  && (!is_global_var (base) || decl_binds_to_current_def_p (base)))
+	return;
+    }
+  else if (TREE_CODE (inner) == MEM_REF)
+    {
+      base = TREE_OPERAND (inner, 0);
+      if (TREE_CODE (base) == ADDR_EXPR
+	  && DECL_P (TREE_OPERAND (base, 0))
+	  && !TREE_ADDRESSABLE (TREE_OPERAND (base, 0))
+	  && !is_global_var (TREE_OPERAND (base, 0)))
+	return;
+      moff = TREE_OPERAND (inner, 1);
+      if (integer_zerop (moff))
+	moff = NULL_TREE;
+    }
+  else
+    return;
+
+  if (!POINTER_TYPE_P (TREE_TYPE (base)) && !DECL_P (base))
+    return;
+  bytepos = bitpos / BITS_PER_UNIT;
+  if (offset == NULL_TREE && bytepos == 0 && moff == NULL_TREE)
+    return;
+
+  tree base_addr = base;
+  if (decl_p)
+    base_addr = build1 (ADDR_EXPR,
+			build_pointer_type (TREE_TYPE (base)), base);
+  t = offset;
+  if (bytepos)
+    {
+      if (t)
+	t = fold_build2 (PLUS_EXPR, TREE_TYPE (t), t,
+			 build_int_cst (TREE_TYPE (t), bytepos));
+      else
+	t = size_int (bytepos);
+    }
+  if (moff)
+    {
+      if (t)
+	t = fold_build2 (PLUS_EXPR, TREE_TYPE (t), t,
+			 fold_convert (TREE_TYPE (t), moff));
+      else
+	t = fold_convert (sizetype, moff);
+    }
+  t = force_gimple_operand_gsi (gsi, t, true, NULL_TREE, true,
+				GSI_SAME_STMT);
+  base_addr = force_gimple_operand_gsi (gsi, base_addr, true, NULL_TREE, true,
+					GSI_SAME_STMT);
+  instrument_pointer_overflow (gsi, base_addr, t);
+}
+
 /* Build an ubsan builtin call for the signed-integer-overflow
    sanitization.  CODE says what kind of builtin are we building,
    LOC is a location, LHSTYPE is the type of LHS, OP0 and OP1
@@ -1849,7 +2120,7 @@ instrument_object_size (gimple_stmt_iter
 	{
 	  tree rhs1 = gimple_assign_rhs1 (def_stmt);
 	  if (TREE_CODE (rhs1) == SSA_NAME
-	    && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs1))
+	      && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs1))
 	    break;
 	  else
 	    base = rhs1;
@@ -1973,7 +2244,8 @@ public:
 				| SANITIZE_ALIGNMENT
 				| SANITIZE_NONNULL_ATTRIBUTE
 				| SANITIZE_RETURNS_NONNULL_ATTRIBUTE
-				| SANITIZE_OBJECT_SIZE));
+				| SANITIZE_OBJECT_SIZE
+				| SANITIZE_POINTER_OVERFLOW));
     }
 
   virtual unsigned int execute (function *);
@@ -2064,6 +2336,32 @@ pass_ubsan::execute (function *fun)
 		    }
 		}
 	    }
+
+	  if (sanitize_flags_p (SANITIZE_POINTER_OVERFLOW, fun->decl))
+	    {
+	      if (is_gimple_assign (stmt)
+		  && gimple_assign_rhs_code (stmt) == POINTER_PLUS_EXPR)
+		instrument_pointer_overflow (&gsi,
+					     gimple_assign_rhs1 (stmt),
+					     gimple_assign_rhs2 (stmt));
+	      if (gimple_store_p (stmt))
+		maybe_instrument_pointer_overflow (&gsi,
+						   gimple_get_lhs (stmt));
+	      if (gimple_assign_single_p (stmt))
+		maybe_instrument_pointer_overflow (&gsi,
+						   gimple_assign_rhs1 (stmt));
+	      if (is_gimple_call (stmt))
+		{
+		  unsigned args_num = gimple_call_num_args (stmt);
+		  for (unsigned i = 0; i < args_num; ++i)
+		    {
+		      tree arg = gimple_call_arg (stmt, i);
+		      if (is_gimple_reg (arg))
+			continue;
+		      maybe_instrument_pointer_overflow (&gsi, arg);
+		    }
+		}
+	    }
 
 	  gsi_next (&gsi);
 	}
--- gcc/internal-fn.c.jj	2017-07-17 10:08:34.923647976 +0200
+++ gcc/internal-fn.c	2017-07-26 13:44:13.837204592 +0200
@@ -402,6 +402,14 @@ expand_UBSAN_VPTR (internal_fn, gcall *)
 /* This should get expanded in the sanopt pass.  */
 
 static void
+expand_UBSAN_PTR (internal_fn, gcall *)
+{
+  gcc_unreachable ();
+}
+
+/* This should get expanded in the sanopt pass.  */
+
+static void
 expand_UBSAN_OBJECT_SIZE (internal_fn, gcall *)
 {
   gcc_unreachable ();
--- gcc/ubsan.h.jj	2017-06-20 09:05:22.498654128 +0200
+++ gcc/ubsan.h	2017-07-26 13:44:13.837204592 +0200
@@ -52,6 +52,7 @@ enum ubsan_encode_value_phase {
 extern bool ubsan_expand_bounds_ifn (gimple_stmt_iterator *);
 extern bool ubsan_expand_null_ifn (gimple_stmt_iterator *);
 extern bool ubsan_expand_objsize_ifn (gimple_stmt_iterator *);
+extern bool ubsan_expand_ptr_ifn (gimple_stmt_iterator *);
 extern bool ubsan_expand_vptr_ifn (gimple_stmt_iterator *);
 extern bool ubsan_instrument_unreachable (gimple_stmt_iterator *);
 extern tree ubsan_create_data (const char *, int, const location_t *, ...);
--- gcc/sanitizer.def.jj	2017-07-06 20:31:32.835082221 +0200
+++ gcc/sanitizer.def	2017-07-26 13:44:13.837204592 +0200
@@ -448,6 +448,10 @@ DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HAN
 		      "__ubsan_handle_load_invalid_value",
 		      BT_FN_VOID_PTR_PTR,
 		      ATTR_COLD_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_POINTER_OVERFLOW,
+		      "__ubsan_handle_pointer_overflow",
+		      BT_FN_VOID_PTR_PTR_PTR,
+		      ATTR_COLD_NOTHROW_LEAF_LIST)
 DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW_ABORT,
 		      "__ubsan_handle_divrem_overflow_abort",
 		      BT_FN_VOID_PTR_PTR_PTR,
@@ -484,6 +488,10 @@ DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HAN
 		      "__ubsan_handle_load_invalid_value_abort",
 		      BT_FN_VOID_PTR_PTR,
 		      ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_POINTER_OVERFLOW_ABORT,
+		      "__ubsan_handle_pointer_overflow_abort",
+		      BT_FN_VOID_PTR_PTR_PTR,
+		      ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST)
 DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_FLOAT_CAST_OVERFLOW,
 		      "__ubsan_handle_float_cast_overflow",
 		      BT_FN_VOID_PTR_PTR,
--- gcc/tree-ssa-tail-merge.c.jj	2017-07-03 19:03:29.467756294 +0200
+++ gcc/tree-ssa-tail-merge.c	2017-07-26 13:44:13.838204580 +0200
@@ -1241,6 +1241,7 @@ merge_stmts_p (gimple *stmt1, gimple *st
       case IFN_UBSAN_CHECK_SUB:
       case IFN_UBSAN_CHECK_MUL:
       case IFN_UBSAN_OBJECT_SIZE:
+      case IFN_UBSAN_PTR:
       case IFN_ASAN_CHECK:
 	/* For these internal functions, gimple_location is an implicit
 	   parameter, which will be used explicitly after expansion.
--- gcc/internal-fn.def.jj	2017-07-06 20:31:43.930946892 +0200
+++ gcc/internal-fn.def	2017-07-26 13:44:13.838204580 +0200
@@ -166,6 +166,7 @@ DEF_INTERNAL_FN (UBSAN_VPTR, ECF_LEAF |
 DEF_INTERNAL_FN (UBSAN_CHECK_ADD, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL)
 DEF_INTERNAL_FN (UBSAN_CHECK_SUB, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL)
 DEF_INTERNAL_FN (UBSAN_CHECK_MUL, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL)
+DEF_INTERNAL_FN (UBSAN_PTR, ECF_LEAF | ECF_NOTHROW, ".R.")
 DEF_INTERNAL_FN (UBSAN_OBJECT_SIZE, ECF_LEAF | ECF_NOTHROW, NULL)
 DEF_INTERNAL_FN (ABNORMAL_DISPATCHER, ECF_NORETURN, NULL)
 DEF_INTERNAL_FN (BUILTIN_EXPECT, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL)
--- gcc/opts.c.jj	2017-07-26 13:37:44.955908409 +0200
+++ gcc/opts.c	2017-07-26 13:44:13.839204567 +0200
@@ -1521,6 +1521,7 @@ const struct sanitizer_opts_s sanitizer_
 		 true),
   SANITIZER_OPT (object-size, SANITIZE_OBJECT_SIZE, true),
   SANITIZER_OPT (vptr, SANITIZE_VPTR, true),
+  SANITIZER_OPT (pointer-overflow, SANITIZE_POINTER_OVERFLOW, true),
   SANITIZER_OPT (all, ~0U, true),
 #undef SANITIZER_OPT
   { NULL, 0U, 0UL, false }
--- gcc/lto-streamer-in.c.jj	2017-06-30 09:49:28.006662098 +0200
+++ gcc/lto-streamer-in.c	2017-07-26 13:44:13.840204555 +0200
@@ -1143,6 +1143,10 @@ input_function (tree fn_decl, struct dat
 		      if ((flag_sanitize & SANITIZE_OBJECT_SIZE) == 0)
 			remove = true;
 		      break;
+		    case IFN_UBSAN_PTR:
+		      if ((flag_sanitize & SANITIZE_POINTER_OVERFLOW) == 0)
+			remove = true;
+		      break;
 		    case IFN_ASAN_MARK:
 		      if ((flag_sanitize & SANITIZE_ADDRESS) == 0)
 			remove = true;
--- gcc/fold-const.c.jj	2017-07-25 12:19:45.423601159 +0200
+++ gcc/fold-const.c	2017-07-26 14:59:51.908708150 +0200
@@ -4859,21 +4859,21 @@ build_range_check (location_t loc, tree
 
   if (low == 0)
     return fold_build2_loc (loc, LE_EXPR, type, exp,
-			fold_convert_loc (loc, etype, high));
+			    fold_convert_loc (loc, etype, high));
 
   if (high == 0)
     return fold_build2_loc (loc, GE_EXPR, type, exp,
-			fold_convert_loc (loc, etype, low));
+			    fold_convert_loc (loc, etype, low));
 
   if (operand_equal_p (low, high, 0))
     return fold_build2_loc (loc, EQ_EXPR, type, exp,
-			fold_convert_loc (loc, etype, low));
+			    fold_convert_loc (loc, etype, low));
 
   if (TREE_CODE (exp) == BIT_AND_EXPR
       && maskable_range_p (low, high, etype, &mask, &value))
     return fold_build2_loc (loc, EQ_EXPR, type,
 			    fold_build2_loc (loc, BIT_AND_EXPR, etype,
-					      exp, mask),
+					     exp, mask),
 			    value);
 
   if (integer_zerop (low))
@@ -4905,7 +4905,7 @@ build_range_check (location_t loc, tree
 	      exp = fold_convert_loc (loc, etype, exp);
 	    }
 	  return fold_build2_loc (loc, GT_EXPR, type, exp,
-			      build_int_cst (etype, 0));
+				  build_int_cst (etype, 0));
 	}
     }
 
@@ -4915,25 +4915,15 @@ build_range_check (location_t loc, tree
   if (etype == NULL_TREE)
     return NULL_TREE;
 
+  if (POINTER_TYPE_P (etype))
+    etype = unsigned_type_for (etype);
+
   high = fold_convert_loc (loc, etype, high);
   low = fold_convert_loc (loc, etype, low);
   exp = fold_convert_loc (loc, etype, exp);
 
   value = const_binop (MINUS_EXPR, high, low);
 
-
-  if (POINTER_TYPE_P (etype))
-    {
-      if (value != 0 && !TREE_OVERFLOW (value))
-	{
-	  low = fold_build1_loc (loc, NEGATE_EXPR, TREE_TYPE (low), low);
-          return build_range_check (loc, type,
-			     	    fold_build_pointer_plus_loc (loc, exp, low),
-			            1, build_int_cst (etype, 0), value);
-	}
-      return 0;
-    }
-
   if (value != 0 && !TREE_OVERFLOW (value))
     return build_range_check (loc, type,
 			      fold_build2_loc (loc, MINUS_EXPR, etype, exp, low),
--- gcc/testsuite/c-c++-common/ubsan/ptr-overflow-1.c.jj	2017-07-26 13:44:13.840204555 +0200
+++ gcc/testsuite/c-c++-common/ubsan/ptr-overflow-1.c	2017-07-26 13:44:13.840204555 +0200
@@ -0,0 +1,65 @@
+/* PR sanitizer/80998 */
+/* { dg-do run } */
+/* { dg-options "-fsanitize=pointer-overflow -fno-sanitize-recover=pointer-overflow -Wall" } */
+
+struct S { int a; int b; int c[64]; };
+__attribute__((noinline, noclone)) char *f1 (char *p) { return p + 1; }
+__attribute__((noinline, noclone)) char *f2 (char *p) { return p - 1; }
+__attribute__((noinline, noclone)) char *f3 (char *p, int i) { return p + i; }
+__attribute__((noinline, noclone)) char *f4 (char *p, int i) { return p - i; }
+__attribute__((noinline, noclone)) char *f5 (char *p, unsigned long int i) { return p + i; }
+__attribute__((noinline, noclone)) char *f6 (char *p, unsigned long int i) { return p - i; }
+__attribute__((noinline, noclone)) int *f7 (struct S *p) { return &p->a; }
+__attribute__((noinline, noclone)) int *f8 (struct S *p) { return &p->b; }
+__attribute__((noinline, noclone)) int *f9 (struct S *p) { return &p->c[64]; }
+__attribute__((noinline, noclone)) int *f10 (struct S *p, int i) { return &p->c[i]; }
+
+char *volatile p;
+struct S *volatile q;
+char a[64];
+struct S s;
+int *volatile r;
+
+int
+main ()
+{
+  struct S t;
+  p = &a[32];
+  p = f1 (p);
+  p = f1 (p);
+  p = f2 (p);
+  p = f3 (p, 1);
+  p = f3 (p, -1);
+  p = f3 (p, 3);
+  p = f3 (p, -6);
+  p = f4 (p, 1);
+  p = f4 (p, -1);
+  p = f4 (p, 3);
+  p = f4 (p, -6);
+  p = f5 (p, 1);
+  p = f5 (p, 3);
+  p = f6 (p, 1);
+  p = f6 (p, 3);
+  if (sizeof (unsigned long) >= sizeof (char *))
+    {
+      p = f5 (p, -1);
+      p = f5 (p, -6);
+      p = f6 (p, -1);
+      p = f6 (p, -6);
+    }
+  q = &s;
+  r = f7 (q);
+  r = f8 (q);
+  r = f9 (q);
+  r = f10 (q, 0);
+  r = f10 (q, 10);
+  r = f10 (q, 64);
+  q = &t;
+  r = f7 (q);
+  r = f8 (q);
+  r = f9 (q);
+  r = f10 (q, 0);
+  r = f10 (q, 10);
+  r = f10 (q, 64);
+  return 0;
+}
--- gcc/testsuite/c-c++-common/ubsan/ptr-overflow-2.c.jj	2017-07-26 13:44:13.840204555 +0200
+++ gcc/testsuite/c-c++-common/ubsan/ptr-overflow-2.c	2017-07-26 13:44:13.840204555 +0200
@@ -0,0 +1,113 @@
+/* PR sanitizer/80998 */
+/* { dg-do run } */
+/* { dg-options "-fsanitize=pointer-overflow -fsanitize-recover=pointer-overflow -fno-ipa-icf -Wall" } */
+
+__attribute__((noinline, noclone)) char * f1 (char *p) { return p + 1; }
+__attribute__((noinline, noclone)) char * f2 (char *p) { return p - 1; }
+__attribute__((noinline, noclone)) char * f3 (char *p, int i) { return p + i; }
+__attribute__((noinline, noclone)) char * f4 (char *p, int i) { return p + i; }
+__attribute__((noinline, noclone)) char * f5 (char *p, int i) { return p - i; }
+__attribute__((noinline, noclone)) char * f6 (char *p, int i) { return p - i; }
+__attribute__((noinline, noclone)) char * f7 (char *p, unsigned long int i) { return p + i; }
+__attribute__((noinline, noclone)) char * f8 (char *p, unsigned long int i) { return p + i; }
+__attribute__((noinline, noclone)) char * f9 (char *p, unsigned long int i) { return p - i; }
+__attribute__((noinline, noclone)) char * f10 (char *p, unsigned long int i) { return p - i; }
+struct S { int a; int b; int c[64]; };
+__attribute__((noinline, noclone)) int *f11 (struct S *p) { return &p->a; }
+__attribute__((noinline, noclone)) int *f12 (struct S *p) { return &p->b; }
+__attribute__((noinline, noclone)) int *f13 (struct S *p) { return &p->c[64]; }
+__attribute__((noinline, noclone)) int *f14 (struct S *p, int i) { return &p->c[i]; }
+__attribute__((noinline, noclone)) int *f15 (struct S *p, int i) { return &p->c[i]; }
+__attribute__((noinline, noclone)) int *f16 (struct S *p) { return &p->a; }
+__attribute__((noinline, noclone)) int *f17 (struct S *p) { return &p->b; }
+__attribute__((noinline, noclone)) int *f18 (struct S *p) { return &p->c[64]; }
+__attribute__((noinline, noclone)) int *f19 (struct S *p, int i) { return &p->c[i]; }
+__attribute__((noinline, noclone)) int *f20 (struct S *p, int i) { return &p->c[i]; }
+__attribute__((noinline, noclone)) int *f21 (struct S *p) { return &p->a; }
+__attribute__((noinline, noclone)) int *f22 (struct S *p) { return &p->b; }
+__attribute__((noinline, noclone)) int *f23 (struct S *p) { return &p->c[64]; }
+__attribute__((noinline, noclone)) int *f24 (struct S *p, int i) { return &p->c[i]; }
+__attribute__((noinline, noclone)) int *f25 (struct S *p, int i) { return &p->c[i]; }
+
+char *volatile p;
+__UINTPTR_TYPE__ volatile u;
+struct S *volatile q;
+int *volatile r;
+
+int
+main ()
+{
+  u = ~(__UINTPTR_TYPE__) 0;
+  p = (char *) u;
+  p = f1 (p);
+  u = 0;
+  p = (char *) u;
+  p = f2 (p);
+  u = -(__UINTPTR_TYPE__) 7;
+  p = (char *) u;
+  p = f3 (p, 7);
+  u = 3;
+  p = (char *) u;
+  p = f4 (p, -4);
+  u = 23;
+  p = (char *) u;
+  p = f5 (p, 27);
+  u = -(__UINTPTR_TYPE__) 15;
+  p = (char *) u;
+  p = f6 (p, -15);
+  u = -(__UINTPTR_TYPE__) 29;
+  p = (char *) u;
+  p = f7 (p, 31);
+  u = 23;
+  p = (char *) u;
+  p = f9 (p, 24);
+  if (sizeof (unsigned long) < sizeof (char *))
+    return 0;
+  u = 7;
+  p = (char *) u;
+  p = f8 (p, -8);
+  u = -(__UINTPTR_TYPE__) 25;
+  p = (char *) u;
+  p = f10 (p, -25);
+  u = ~(__UINTPTR_TYPE__) 0;
+  q = (struct S *) u;
+  r = f11 (q);
+  r = f12 (q);
+  r = f13 (q);
+  r = f14 (q, 0);
+  r = f15 (q, 63);
+  u = ~(__UINTPTR_TYPE__) 0 - (17 * sizeof (int));
+  q = (struct S *) u;
+  r = f16 (q);
+  r = f17 (q);
+  r = f18 (q);
+  r = f19 (q, 0);
+  r = f20 (q, 63);
+  u = 3 * sizeof (int);
+  q = (struct S *) u;
+  r = f21 (q);
+  r = f22 (q);
+  r = f23 (q);
+  r = f24 (q, -2);
+  r = f25 (q, -6);
+  return 0;
+}
+
+/* { dg-output ":5:6\[79]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+ overflowed to (0\[xX])?0\+(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*:6:6\[79]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?0\+ overflowed to (0\[xX])?\[fF]\+(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*:7:7\[46]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+9 overflowed to (0\[xX])?0\+(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*:8:7\[46]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?0\+3 overflowed to (0\[xX])?\[fF]\+(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*:9:7\[46]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?0\+17 overflowed to (0\[xX])?\[fF]\+\[cC](\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*:10:7\[46]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+1 overflowed to (0\[xX])?0\+(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*:11:\[89]\[80]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+\[eE]3 overflowed to (0\[xX])?0\+2(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*:13:\[89]\[80]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?0\+17 overflowed to (0\[xX])?\[fF]\+(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*:12:\[89]\[80]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?0\+7 overflowed to (0\[xX])?\[fF]\+(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*:14:\[89]\[91]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+\[eE]7 overflowed to (0\[xX])?0\+" } */
+/* { dg-output "(\n|\r\n|\r)" { target int32 } } */
+/* { dg-output "\[^\n\r]*:17:\[67]\[82]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+ overflowed to (0\[xX])?0\+3(\n|\r\n|\r)" { target int32 } } */
+/* { dg-output "\[^\n\r]*:18:\[67]\[86]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+ overflowed to (0\[xX])?0\+107(\n|\r\n|\r)" { target int32 } } */
+/* { dg-output "\[^\n\r]*:19:\[78]\[52]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+ overflowed to (0\[xX])?0\+7(\n|\r\n|\r)" { target int32 } } */
+/* { dg-output "\[^\n\r]*:20:\[78]\[52]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+ overflowed to (0\[xX])?0\+103(\n|\r\n|\r)" { target int32 } } */
+/* { dg-output "\[^\n\r]*:23:\[67]\[86]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+\[bB]\[bB] overflowed to (0\[xX])?0\+\[cC]3(\n|\r\n|\r)" { target int32 } } */
+/* { dg-output "\[^\n\r]*:25:\[78]\[52]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+\[bB]\[bB] overflowed to (0\[xX])?0\+\[bB]\[fF](\n|\r\n|\r)" { target int32 } } */
+/* { dg-output "\[^\n\r]*:30:\[78]\[52]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?0\+\[cC] overflowed to (0\[xX])?\[fF]\+\[cC]" { target int32 } } */
--- libsanitizer/ubsan/ubsan_handlers.cc.jj	2017-06-19 08:26:17.073600279 +0200
+++ libsanitizer/ubsan/ubsan_handlers.cc	2017-07-26 13:44:14.261199463 +0200
@@ -521,6 +521,37 @@ void __ubsan::__ubsan_handle_nonnull_arg
   Die();
 }
 
+static void handlePointerOverflowImpl(PointerOverflowData *Data,
+                                      ValueHandle Base,
+                                      ValueHandle Result,
+                                      ReportOptions Opts) {
+  SourceLocation Loc = Data->Loc.acquire();
+  ErrorType ET = ErrorType::PointerOverflow;
+
+  if (ignoreReport(Loc, Opts, ET))
+    return;
+
+  ScopedReport R(Opts, Loc, ET);
+
+  Diag(Loc, DL_Error, "pointer index expression with base %0 overflowed to %1")
+    << (void *)Base << (void*)Result;
+}
+
+void __ubsan::__ubsan_handle_pointer_overflow(PointerOverflowData *Data,
+                                              ValueHandle Base,
+                                              ValueHandle Result) {
+  GET_REPORT_OPTIONS(false);
+  handlePointerOverflowImpl(Data, Base, Result, Opts);
+}
+
+void __ubsan::__ubsan_handle_pointer_overflow_abort(PointerOverflowData *Data,
+                                                    ValueHandle Base,
+                                                    ValueHandle Result) {
+  GET_REPORT_OPTIONS(true);
+  handlePointerOverflowImpl(Data, Base, Result, Opts);
+  Die();
+}
+
 static void handleCFIBadIcall(CFICheckFailData *Data, ValueHandle Function,
                               ReportOptions Opts) {
   if (Data->CheckKind != CFITCK_ICall)
--- libsanitizer/ubsan/ubsan_checks.inc.jj	2017-06-19 08:26:17.061600432 +0200
+++ libsanitizer/ubsan/ubsan_checks.inc	2017-07-26 13:44:14.275199294 +0200
@@ -17,6 +17,7 @@
 
 UBSAN_CHECK(GenericUB, "undefined-behavior", "undefined")
 UBSAN_CHECK(NullPointerUse, "null-pointer-use", "null")
+UBSAN_CHECK(PointerOverflow, "pointer-overflow", "pointer-overflow")
 UBSAN_CHECK(MisalignedPointerUse, "misaligned-pointer-use", "alignment")
 UBSAN_CHECK(InsufficientObjectSize, "insufficient-object-size", "object-size")
 UBSAN_CHECK(SignedIntegerOverflow, "signed-integer-overflow",
--- libsanitizer/ubsan/ubsan_handlers.h.jj	2017-06-19 08:26:17.073600279 +0200
+++ libsanitizer/ubsan/ubsan_handlers.h	2017-07-26 13:44:14.282199209 +0200
@@ -146,6 +146,13 @@ struct NonNullArgData {
 /// \brief Handle passing null pointer to function with nonnull attribute.
 RECOVERABLE(nonnull_arg, NonNullArgData *Data)
 
+struct PointerOverflowData {
+  SourceLocation Loc;
+};
+
+RECOVERABLE(pointer_overflow, PointerOverflowData *Data, ValueHandle Base,
+            ValueHandle Result)
+
 /// \brief Known CFI check kinds.
 /// Keep in sync with the enum of the same name in CodeGenFunction.h
 enum CFITypeCheckKind : unsigned char {


	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 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 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 <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)

Re: Patch ping

[Jakub Jelinek]

[-- Attachment #1: Type: text/plain, Size: 3728 bytes --]

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

[-- Attachment #2: U606m --]
[-- Type: text/plain, Size: 32385 bytes --]

2017-07-26  Jakub Jelinek  <jakub@redhat.com>

	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.jj	2017-06-30 09:49:32.306609364 +0200
+++ gcc/ubsan.c	2017-07-26 15:37:11.649228991 +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 = gimple_call_arg (stmt, 0);
+  tree off = gimple_call_arg (stmt, 1);
+
+  if (integer_zerop (off))
+    {
+      gsi_remove (gsip, true);
+      unlink_stmt_vdef (stmt);
+      return true;
+    }
+
+  basic_block cur_bb = gsi_bb (gsi);
+  tree ptrplusoff = make_ssa_name (pointer_sized_int_node);
+  tree ptri = make_ssa_name (pointer_sized_int_node);
+  int pos_neg = get_range_pos_neg (off);
+
+  /* Split the original block holding the pointer dereference.  */
+  edge e = split_block (cur_bb, stmt);
+
+  /* Get a hold on the 'condition block', the 'then block' and the
+     'else block'.  */
+  basic_block cond_bb = e->src;
+  basic_block fallthru_bb = e->dest;
+  basic_block then_bb = create_empty_bb (cond_bb);
+  basic_block cond_pos_bb = NULL, cond_neg_bb = NULL;
+  add_bb_to_loop (then_bb, cond_bb->loop_father);
+  loops_state_set (LOOPS_NEED_FIXUP);
+
+  /* Set up the fallthrough basic block.  */
+  e->flags = EDGE_FALSE_VALUE;
+  if (pos_neg != 3)
+    {
+      e->count = cond_bb->count;
+      e->probability = profile_probability::very_likely ();
+
+      /* Connect 'then block' with the 'else block'.  This is needed
+	 as the ubsan routines we call in the 'then block' are not noreturn.
+	 The 'then block' only has one outcoming edge.  */
+      make_single_succ_edge (then_bb, fallthru_bb, EDGE_FALLTHRU);
+
+      /* Make an edge coming from the 'cond block' into the 'then block';
+	 this edge is unlikely taken, so set up the probability
+	 accordingly.  */
+      e = make_edge (cond_bb, then_bb, EDGE_TRUE_VALUE);
+      e->probability = profile_probability::very_unlikely ();
+    }
+  else
+    {
+      profile_count count = cond_bb->count.apply_probability (PROB_EVEN);
+      e->count = count;
+      e->probability = profile_probability::even ();
+
+      e = split_block (fallthru_bb, (gimple *) NULL);
+      cond_neg_bb = e->src;
+      fallthru_bb = e->dest;
+      e->count = count;
+      e->probability = profile_probability::very_likely ();
+      e->flags = EDGE_FALSE_VALUE;
+
+      e = make_edge (cond_neg_bb, then_bb, EDGE_TRUE_VALUE);
+      e->probability = profile_probability::very_unlikely ();
+
+      cond_pos_bb = create_empty_bb (cond_bb);
+      add_bb_to_loop (cond_pos_bb, cond_bb->loop_father);
+
+      e = make_edge (cond_bb, cond_pos_bb, EDGE_TRUE_VALUE);
+      e->count = count;
+      e->probability = profile_probability::even ();
+
+      e = make_edge (cond_pos_bb, then_bb, EDGE_TRUE_VALUE);
+      e->probability = profile_probability::very_unlikely ();
+
+      e = make_edge (cond_pos_bb, fallthru_bb, EDGE_FALSE_VALUE);
+      e->count = count;
+      e->probability = profile_probability::very_likely ();
+
+      make_single_succ_edge (then_bb, fallthru_bb, EDGE_FALLTHRU);
+    }
+
+  gimple *g = gimple_build_assign (ptri, NOP_EXPR, ptr);
+  gimple_set_location (g, loc);
+  gsi_insert_before (&gsi, g, GSI_SAME_STMT);
+  g = gimple_build_assign (ptrplusoff, PLUS_EXPR, ptri, off);
+  gimple_set_location (g, loc);
+  gsi_insert_before (&gsi, g, GSI_SAME_STMT);
+
+  /* Update dominance info for the newly created then_bb; note that
+     fallthru_bb's dominance info has already been updated by
+     split_block.  */
+  if (dom_info_available_p (CDI_DOMINATORS))
+    {
+      set_immediate_dominator (CDI_DOMINATORS, then_bb, cond_bb);
+      if (pos_neg == 3)
+	{
+	  set_immediate_dominator (CDI_DOMINATORS, cond_pos_bb, cond_bb);
+	  set_immediate_dominator (CDI_DOMINATORS, fallthru_bb, cond_bb);
+	}
+    }
+
+  /* Put the ubsan builtin call into the newly created BB.  */
+  if (flag_sanitize_undefined_trap_on_error)
+    g = gimple_build_call (builtin_decl_implicit (BUILT_IN_TRAP), 0);
+  else
+    {
+      enum built_in_function bcode
+	= (flag_sanitize_recover & SANITIZE_POINTER_OVERFLOW)
+	  ? BUILT_IN_UBSAN_HANDLE_POINTER_OVERFLOW
+	  : BUILT_IN_UBSAN_HANDLE_POINTER_OVERFLOW_ABORT;
+      tree fn = builtin_decl_implicit (bcode);
+      tree data
+	= ubsan_create_data ("__ubsan_ptrovf_data", 1, &loc,
+			     NULL_TREE, NULL_TREE);
+      data = build_fold_addr_expr_loc (loc, data);
+      g = gimple_build_call (fn, 3, data, ptr, ptrplusoff);
+    }
+  gimple_stmt_iterator gsi2 = gsi_start_bb (then_bb);
+  gimple_set_location (g, loc);
+  gsi_insert_after (&gsi2, g, GSI_NEW_STMT);
+
+  /* Unlink the UBSAN_PTRs vops before replacing it.  */
+  unlink_stmt_vdef (stmt);
+
+  if (TREE_CODE (off) == INTEGER_CST)
+    g = gimple_build_cond (wi::neg_p (off) ? LT_EXPR : GE_EXPR, ptri,
+			   fold_build1 (NEGATE_EXPR, sizetype, off),
+			   NULL_TREE, NULL_TREE);
+  else if (pos_neg != 3)
+    g = gimple_build_cond (pos_neg == 1 ? LT_EXPR : GT_EXPR,
+			   ptrplusoff, ptri, NULL_TREE, NULL_TREE);
+  else
+    {
+      gsi2 = gsi_start_bb (cond_pos_bb);
+      g = gimple_build_cond (LT_EXPR, ptrplusoff, ptri, NULL_TREE, NULL_TREE);
+      gimple_set_location (g, loc);
+      gsi_insert_after (&gsi2, g, GSI_NEW_STMT);
+
+      gsi2 = gsi_start_bb (cond_neg_bb);
+      g = gimple_build_cond (GT_EXPR, ptrplusoff, ptri, NULL_TREE, NULL_TREE);
+      gimple_set_location (g, loc);
+      gsi_insert_after (&gsi2, g, GSI_NEW_STMT);
+
+      gimple_seq seq = NULL;
+      tree t = gimple_build (&seq, loc, NOP_EXPR, ssizetype, off);
+      t = gimple_build (&seq, loc, GE_EXPR, boolean_type_node,
+			t, ssize_int (0));
+      gsi_insert_seq_before (&gsi, seq, GSI_SAME_STMT);
+      g = gimple_build_cond (NE_EXPR, t, boolean_false_node,
+			     NULL_TREE, NULL_TREE);
+    }
+  gimple_set_location (g, loc);
+  /* Replace the UBSAN_PTR with a GIMPLE_COND stmt.  */
+  gsi_replace (&gsi, g, false);
+  return false;
+}
+
+
 /* Cached __ubsan_vptr_type_cache decl.  */
 static GTY(()) tree ubsan_vptr_type_cache_decl;
 
@@ -1234,6 +1400,107 @@ instrument_null (gimple_stmt_iterator gs
     instrument_mem_ref (t, base, &gsi, is_lhs);
 }
 
+/* Instrument pointer arithmetics PTR p+ OFF.  */
+
+static void
+instrument_pointer_overflow (gimple_stmt_iterator *gsi, tree ptr, tree off)
+{
+  if (TYPE_PRECISION (sizetype) != POINTER_SIZE)
+    return;
+  gcall *g = gimple_build_call_internal (IFN_UBSAN_PTR, 2, ptr, off);
+  gimple_set_location (g, gimple_location (gsi_stmt (*gsi)));
+  gsi_insert_before (gsi, g, GSI_SAME_STMT);
+}
+
+/* Instrument pointer arithmetics if any.  */
+
+static void
+maybe_instrument_pointer_overflow (gimple_stmt_iterator *gsi, tree t)
+{
+  if (TYPE_PRECISION (sizetype) != POINTER_SIZE)
+    return;
+  /* Handle also e.g. &s->i.  */
+  if (TREE_CODE (t) == ADDR_EXPR)
+    t = TREE_OPERAND (t, 0);
+
+  switch (TREE_CODE (t))
+    {
+    case COMPONENT_REF:
+      if (TREE_CODE (t) == COMPONENT_REF
+	  && DECL_BIT_FIELD_REPRESENTATIVE (TREE_OPERAND (t, 1)) != NULL_TREE)
+	{
+	  tree repr = DECL_BIT_FIELD_REPRESENTATIVE (TREE_OPERAND (t, 1));
+	  t = build3 (COMPONENT_REF, TREE_TYPE (repr), TREE_OPERAND (t, 0),
+		      repr, TREE_OPERAND (t, 2));
+	}
+      break;
+    case ARRAY_REF:
+    case MEM_REF:
+    case REALPART_EXPR:
+    case IMAGPART_EXPR:
+      break;
+    default:
+      return;
+    }
+
+  HOST_WIDE_INT bitsize, bitpos;
+  tree offset;
+  machine_mode mode;
+  int volatilep = 0, reversep, unsignedp = 0;
+  tree inner = get_inner_reference (t, &bitsize, &bitpos, &offset, &mode,
+				    &unsignedp, &reversep, &volatilep);
+
+  if ((offset == NULL_TREE
+       && bitpos == 0
+       && (TREE_CODE (inner) != MEM_REF
+           || integer_zerop (TREE_OPERAND (inner, 1))))
+      || bitpos % BITS_PER_UNIT != 0)
+    return;
+
+  bool decl_p = DECL_P (inner);
+  tree base;
+  if (decl_p)
+    {
+      if (DECL_REGISTER (inner))
+	return;
+      base = inner;
+      /* If BASE is a fixed size automatic variable or
+	 global variable defined in the current TU and bitpos
+	 fits, don't instrument anything.  */
+      if (offset == NULL_TREE
+	  && bitpos > 0
+	  && (VAR_P (base)
+	   || TREE_CODE (base) == PARM_DECL
+	   || TREE_CODE (base) == RESULT_DECL)
+	  && DECL_SIZE (base)
+	  && TREE_CODE (DECL_SIZE (base)) == INTEGER_CST
+	  && compare_tree_int (DECL_SIZE (base), bitpos) >= 0
+	  && (!is_global_var (base) || decl_binds_to_current_def_p (base)))
+	return;
+    }
+  else if (TREE_CODE (inner) == MEM_REF)
+    base = TREE_OPERAND (inner, 0);
+  else
+    return;
+  tree ptr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (t)), t);
+
+  if (!POINTER_TYPE_P (TREE_TYPE (base)) && !DECL_P (base))
+    return;
+
+  tree base_addr = base;
+  if (decl_p)
+    base_addr = build1 (ADDR_EXPR,
+			build_pointer_type (TREE_TYPE (base)), base);
+  t = fold_build2 (MINUS_EXPR, sizetype,
+		   fold_convert (pointer_sized_int_node, ptr),
+		   fold_convert (pointer_sized_int_node, base_addr));
+  t = force_gimple_operand_gsi (gsi, t, true, NULL_TREE, true,
+				GSI_SAME_STMT);
+  base_addr = force_gimple_operand_gsi (gsi, base_addr, true, NULL_TREE, true,
+					GSI_SAME_STMT);
+  instrument_pointer_overflow (gsi, base_addr, t);
+}
+
 /* Build an ubsan builtin call for the signed-integer-overflow
    sanitization.  CODE says what kind of builtin are we building,
    LOC is a location, LHSTYPE is the type of LHS, OP0 and OP1
@@ -1849,7 +2116,7 @@ instrument_object_size (gimple_stmt_iter
 	{
 	  tree rhs1 = gimple_assign_rhs1 (def_stmt);
 	  if (TREE_CODE (rhs1) == SSA_NAME
-	    && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs1))
+	      && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs1))
 	    break;
 	  else
 	    base = rhs1;
@@ -1973,7 +2240,8 @@ public:
 				| SANITIZE_ALIGNMENT
 				| SANITIZE_NONNULL_ATTRIBUTE
 				| SANITIZE_RETURNS_NONNULL_ATTRIBUTE
-				| SANITIZE_OBJECT_SIZE));
+				| SANITIZE_OBJECT_SIZE
+				| SANITIZE_POINTER_OVERFLOW));
     }
 
   virtual unsigned int execute (function *);
@@ -2064,6 +2332,32 @@ pass_ubsan::execute (function *fun)
 		    }
 		}
 	    }
+
+	  if (sanitize_flags_p (SANITIZE_POINTER_OVERFLOW, fun->decl))
+	    {
+	      if (is_gimple_assign (stmt)
+		  && gimple_assign_rhs_code (stmt) == POINTER_PLUS_EXPR)
+		instrument_pointer_overflow (&gsi,
+					     gimple_assign_rhs1 (stmt),
+					     gimple_assign_rhs2 (stmt));
+	      if (gimple_store_p (stmt))
+		maybe_instrument_pointer_overflow (&gsi,
+						   gimple_get_lhs (stmt));
+	      if (gimple_assign_single_p (stmt))
+		maybe_instrument_pointer_overflow (&gsi,
+						   gimple_assign_rhs1 (stmt));
+	      if (is_gimple_call (stmt))
+		{
+		  unsigned args_num = gimple_call_num_args (stmt);
+		  for (unsigned i = 0; i < args_num; ++i)
+		    {
+		      tree arg = gimple_call_arg (stmt, i);
+		      if (is_gimple_reg (arg))
+			continue;
+		      maybe_instrument_pointer_overflow (&gsi, arg);
+		    }
+		}
+	    }
 
 	  gsi_next (&gsi);
 	}
--- gcc/internal-fn.c.jj	2017-07-17 10:08:34.923647976 +0200
+++ gcc/internal-fn.c	2017-07-26 13:44:13.837204592 +0200
@@ -402,6 +402,14 @@ expand_UBSAN_VPTR (internal_fn, gcall *)
 /* This should get expanded in the sanopt pass.  */
 
 static void
+expand_UBSAN_PTR (internal_fn, gcall *)
+{
+  gcc_unreachable ();
+}
+
+/* This should get expanded in the sanopt pass.  */
+
+static void
 expand_UBSAN_OBJECT_SIZE (internal_fn, gcall *)
 {
   gcc_unreachable ();
--- gcc/ubsan.h.jj	2017-06-20 09:05:22.498654128 +0200
+++ gcc/ubsan.h	2017-07-26 13:44:13.837204592 +0200
@@ -52,6 +52,7 @@ enum ubsan_encode_value_phase {
 extern bool ubsan_expand_bounds_ifn (gimple_stmt_iterator *);
 extern bool ubsan_expand_null_ifn (gimple_stmt_iterator *);
 extern bool ubsan_expand_objsize_ifn (gimple_stmt_iterator *);
+extern bool ubsan_expand_ptr_ifn (gimple_stmt_iterator *);
 extern bool ubsan_expand_vptr_ifn (gimple_stmt_iterator *);
 extern bool ubsan_instrument_unreachable (gimple_stmt_iterator *);
 extern tree ubsan_create_data (const char *, int, const location_t *, ...);
--- gcc/sanitizer.def.jj	2017-07-06 20:31:32.835082221 +0200
+++ gcc/sanitizer.def	2017-07-26 13:44:13.837204592 +0200
@@ -448,6 +448,10 @@ DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HAN
 		      "__ubsan_handle_load_invalid_value",
 		      BT_FN_VOID_PTR_PTR,
 		      ATTR_COLD_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_POINTER_OVERFLOW,
+		      "__ubsan_handle_pointer_overflow",
+		      BT_FN_VOID_PTR_PTR_PTR,
+		      ATTR_COLD_NOTHROW_LEAF_LIST)
 DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW_ABORT,
 		      "__ubsan_handle_divrem_overflow_abort",
 		      BT_FN_VOID_PTR_PTR_PTR,
@@ -484,6 +488,10 @@ DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HAN
 		      "__ubsan_handle_load_invalid_value_abort",
 		      BT_FN_VOID_PTR_PTR,
 		      ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_POINTER_OVERFLOW_ABORT,
+		      "__ubsan_handle_pointer_overflow_abort",
+		      BT_FN_VOID_PTR_PTR_PTR,
+		      ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST)
 DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_FLOAT_CAST_OVERFLOW,
 		      "__ubsan_handle_float_cast_overflow",
 		      BT_FN_VOID_PTR_PTR,
--- gcc/tree-ssa-tail-merge.c.jj	2017-07-03 19:03:29.467756294 +0200
+++ gcc/tree-ssa-tail-merge.c	2017-07-26 13:44:13.838204580 +0200
@@ -1241,6 +1241,7 @@ merge_stmts_p (gimple *stmt1, gimple *st
       case IFN_UBSAN_CHECK_SUB:
       case IFN_UBSAN_CHECK_MUL:
       case IFN_UBSAN_OBJECT_SIZE:
+      case IFN_UBSAN_PTR:
       case IFN_ASAN_CHECK:
 	/* For these internal functions, gimple_location is an implicit
 	   parameter, which will be used explicitly after expansion.
--- gcc/internal-fn.def.jj	2017-07-06 20:31:43.930946892 +0200
+++ gcc/internal-fn.def	2017-07-26 13:44:13.838204580 +0200
@@ -166,6 +166,7 @@ DEF_INTERNAL_FN (UBSAN_VPTR, ECF_LEAF |
 DEF_INTERNAL_FN (UBSAN_CHECK_ADD, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL)
 DEF_INTERNAL_FN (UBSAN_CHECK_SUB, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL)
 DEF_INTERNAL_FN (UBSAN_CHECK_MUL, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL)
+DEF_INTERNAL_FN (UBSAN_PTR, ECF_LEAF | ECF_NOTHROW, ".R.")
 DEF_INTERNAL_FN (UBSAN_OBJECT_SIZE, ECF_LEAF | ECF_NOTHROW, NULL)
 DEF_INTERNAL_FN (ABNORMAL_DISPATCHER, ECF_NORETURN, NULL)
 DEF_INTERNAL_FN (BUILTIN_EXPECT, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL)
--- gcc/opts.c.jj	2017-07-26 13:37:44.955908409 +0200
+++ gcc/opts.c	2017-07-26 13:44:13.839204567 +0200
@@ -1521,6 +1521,7 @@ const struct sanitizer_opts_s sanitizer_
 		 true),
   SANITIZER_OPT (object-size, SANITIZE_OBJECT_SIZE, true),
   SANITIZER_OPT (vptr, SANITIZE_VPTR, true),
+  SANITIZER_OPT (pointer-overflow, SANITIZE_POINTER_OVERFLOW, true),
   SANITIZER_OPT (all, ~0U, true),
 #undef SANITIZER_OPT
   { NULL, 0U, 0UL, false }
--- gcc/lto-streamer-in.c.jj	2017-06-30 09:49:28.006662098 +0200
+++ gcc/lto-streamer-in.c	2017-07-26 13:44:13.840204555 +0200
@@ -1143,6 +1143,10 @@ input_function (tree fn_decl, struct dat
 		      if ((flag_sanitize & SANITIZE_OBJECT_SIZE) == 0)
 			remove = true;
 		      break;
+		    case IFN_UBSAN_PTR:
+		      if ((flag_sanitize & SANITIZE_POINTER_OVERFLOW) == 0)
+			remove = true;
+		      break;
 		    case IFN_ASAN_MARK:
 		      if ((flag_sanitize & SANITIZE_ADDRESS) == 0)
 			remove = true;
--- gcc/fold-const.c.jj	2017-07-25 12:19:45.423601159 +0200
+++ gcc/fold-const.c	2017-07-26 14:59:51.908708150 +0200
@@ -4859,21 +4859,21 @@ build_range_check (location_t loc, tree
 
   if (low == 0)
     return fold_build2_loc (loc, LE_EXPR, type, exp,
-			fold_convert_loc (loc, etype, high));
+			    fold_convert_loc (loc, etype, high));
 
   if (high == 0)
     return fold_build2_loc (loc, GE_EXPR, type, exp,
-			fold_convert_loc (loc, etype, low));
+			    fold_convert_loc (loc, etype, low));
 
   if (operand_equal_p (low, high, 0))
     return fold_build2_loc (loc, EQ_EXPR, type, exp,
-			fold_convert_loc (loc, etype, low));
+			    fold_convert_loc (loc, etype, low));
 
   if (TREE_CODE (exp) == BIT_AND_EXPR
       && maskable_range_p (low, high, etype, &mask, &value))
     return fold_build2_loc (loc, EQ_EXPR, type,
 			    fold_build2_loc (loc, BIT_AND_EXPR, etype,
-					      exp, mask),
+					     exp, mask),
 			    value);
 
   if (integer_zerop (low))
@@ -4905,7 +4905,7 @@ build_range_check (location_t loc, tree
 	      exp = fold_convert_loc (loc, etype, exp);
 	    }
 	  return fold_build2_loc (loc, GT_EXPR, type, exp,
-			      build_int_cst (etype, 0));
+				  build_int_cst (etype, 0));
 	}
     }
 
@@ -4915,25 +4915,15 @@ build_range_check (location_t loc, tree
   if (etype == NULL_TREE)
     return NULL_TREE;
 
+  if (POINTER_TYPE_P (etype))
+    etype = unsigned_type_for (etype);
+
   high = fold_convert_loc (loc, etype, high);
   low = fold_convert_loc (loc, etype, low);
   exp = fold_convert_loc (loc, etype, exp);
 
   value = const_binop (MINUS_EXPR, high, low);
 
-
-  if (POINTER_TYPE_P (etype))
-    {
-      if (value != 0 && !TREE_OVERFLOW (value))
-	{
-	  low = fold_build1_loc (loc, NEGATE_EXPR, TREE_TYPE (low), low);
-          return build_range_check (loc, type,
-			     	    fold_build_pointer_plus_loc (loc, exp, low),
-			            1, build_int_cst (etype, 0), value);
-	}
-      return 0;
-    }
-
   if (value != 0 && !TREE_OVERFLOW (value))
     return build_range_check (loc, type,
 			      fold_build2_loc (loc, MINUS_EXPR, etype, exp, low),
--- gcc/testsuite/c-c++-common/ubsan/ptr-overflow-1.c.jj	2017-07-26 13:44:13.840204555 +0200
+++ gcc/testsuite/c-c++-common/ubsan/ptr-overflow-1.c	2017-07-26 13:44:13.840204555 +0200
@@ -0,0 +1,65 @@
+/* PR sanitizer/80998 */
+/* { dg-do run } */
+/* { dg-options "-fsanitize=pointer-overflow -fno-sanitize-recover=pointer-overflow -Wall" } */
+
+struct S { int a; int b; int c[64]; };
+__attribute__((noinline, noclone)) char *f1 (char *p) { return p + 1; }
+__attribute__((noinline, noclone)) char *f2 (char *p) { return p - 1; }
+__attribute__((noinline, noclone)) char *f3 (char *p, int i) { return p + i; }
+__attribute__((noinline, noclone)) char *f4 (char *p, int i) { return p - i; }
+__attribute__((noinline, noclone)) char *f5 (char *p, unsigned long int i) { return p + i; }
+__attribute__((noinline, noclone)) char *f6 (char *p, unsigned long int i) { return p - i; }
+__attribute__((noinline, noclone)) int *f7 (struct S *p) { return &p->a; }
+__attribute__((noinline, noclone)) int *f8 (struct S *p) { return &p->b; }
+__attribute__((noinline, noclone)) int *f9 (struct S *p) { return &p->c[64]; }
+__attribute__((noinline, noclone)) int *f10 (struct S *p, int i) { return &p->c[i]; }
+
+char *volatile p;
+struct S *volatile q;
+char a[64];
+struct S s;
+int *volatile r;
+
+int
+main ()
+{
+  struct S t;
+  p = &a[32];
+  p = f1 (p);
+  p = f1 (p);
+  p = f2 (p);
+  p = f3 (p, 1);
+  p = f3 (p, -1);
+  p = f3 (p, 3);
+  p = f3 (p, -6);
+  p = f4 (p, 1);
+  p = f4 (p, -1);
+  p = f4 (p, 3);
+  p = f4 (p, -6);
+  p = f5 (p, 1);
+  p = f5 (p, 3);
+  p = f6 (p, 1);
+  p = f6 (p, 3);
+  if (sizeof (unsigned long) >= sizeof (char *))
+    {
+      p = f5 (p, -1);
+      p = f5 (p, -6);
+      p = f6 (p, -1);
+      p = f6 (p, -6);
+    }
+  q = &s;
+  r = f7 (q);
+  r = f8 (q);
+  r = f9 (q);
+  r = f10 (q, 0);
+  r = f10 (q, 10);
+  r = f10 (q, 64);
+  q = &t;
+  r = f7 (q);
+  r = f8 (q);
+  r = f9 (q);
+  r = f10 (q, 0);
+  r = f10 (q, 10);
+  r = f10 (q, 64);
+  return 0;
+}
--- gcc/testsuite/c-c++-common/ubsan/ptr-overflow-2.c.jj	2017-07-26 13:44:13.840204555 +0200
+++ gcc/testsuite/c-c++-common/ubsan/ptr-overflow-2.c	2017-07-26 13:44:13.840204555 +0200
@@ -0,0 +1,113 @@
+/* PR sanitizer/80998 */
+/* { dg-do run } */
+/* { dg-options "-fsanitize=pointer-overflow -fsanitize-recover=pointer-overflow -fno-ipa-icf -Wall" } */
+
+__attribute__((noinline, noclone)) char * f1 (char *p) { return p + 1; }
+__attribute__((noinline, noclone)) char * f2 (char *p) { return p - 1; }
+__attribute__((noinline, noclone)) char * f3 (char *p, int i) { return p + i; }
+__attribute__((noinline, noclone)) char * f4 (char *p, int i) { return p + i; }
+__attribute__((noinline, noclone)) char * f5 (char *p, int i) { return p - i; }
+__attribute__((noinline, noclone)) char * f6 (char *p, int i) { return p - i; }
+__attribute__((noinline, noclone)) char * f7 (char *p, unsigned long int i) { return p + i; }
+__attribute__((noinline, noclone)) char * f8 (char *p, unsigned long int i) { return p + i; }
+__attribute__((noinline, noclone)) char * f9 (char *p, unsigned long int i) { return p - i; }
+__attribute__((noinline, noclone)) char * f10 (char *p, unsigned long int i) { return p - i; }
+struct S { int a; int b; int c[64]; };
+__attribute__((noinline, noclone)) int *f11 (struct S *p) { return &p->a; }
+__attribute__((noinline, noclone)) int *f12 (struct S *p) { return &p->b; }
+__attribute__((noinline, noclone)) int *f13 (struct S *p) { return &p->c[64]; }
+__attribute__((noinline, noclone)) int *f14 (struct S *p, int i) { return &p->c[i]; }
+__attribute__((noinline, noclone)) int *f15 (struct S *p, int i) { return &p->c[i]; }
+__attribute__((noinline, noclone)) int *f16 (struct S *p) { return &p->a; }
+__attribute__((noinline, noclone)) int *f17 (struct S *p) { return &p->b; }
+__attribute__((noinline, noclone)) int *f18 (struct S *p) { return &p->c[64]; }
+__attribute__((noinline, noclone)) int *f19 (struct S *p, int i) { return &p->c[i]; }
+__attribute__((noinline, noclone)) int *f20 (struct S *p, int i) { return &p->c[i]; }
+__attribute__((noinline, noclone)) int *f21 (struct S *p) { return &p->a; }
+__attribute__((noinline, noclone)) int *f22 (struct S *p) { return &p->b; }
+__attribute__((noinline, noclone)) int *f23 (struct S *p) { return &p->c[64]; }
+__attribute__((noinline, noclone)) int *f24 (struct S *p, int i) { return &p->c[i]; }
+__attribute__((noinline, noclone)) int *f25 (struct S *p, int i) { return &p->c[i]; }
+
+char *volatile p;
+__UINTPTR_TYPE__ volatile u;
+struct S *volatile q;
+int *volatile r;
+
+int
+main ()
+{
+  u = ~(__UINTPTR_TYPE__) 0;
+  p = (char *) u;
+  p = f1 (p);
+  u = 0;
+  p = (char *) u;
+  p = f2 (p);
+  u = -(__UINTPTR_TYPE__) 7;
+  p = (char *) u;
+  p = f3 (p, 7);
+  u = 3;
+  p = (char *) u;
+  p = f4 (p, -4);
+  u = 23;
+  p = (char *) u;
+  p = f5 (p, 27);
+  u = -(__UINTPTR_TYPE__) 15;
+  p = (char *) u;
+  p = f6 (p, -15);
+  u = -(__UINTPTR_TYPE__) 29;
+  p = (char *) u;
+  p = f7 (p, 31);
+  u = 23;
+  p = (char *) u;
+  p = f9 (p, 24);
+  if (sizeof (unsigned long) < sizeof (char *))
+    return 0;
+  u = 7;
+  p = (char *) u;
+  p = f8 (p, -8);
+  u = -(__UINTPTR_TYPE__) 25;
+  p = (char *) u;
+  p = f10 (p, -25);
+  u = ~(__UINTPTR_TYPE__) 0;
+  q = (struct S *) u;
+  r = f11 (q);
+  r = f12 (q);
+  r = f13 (q);
+  r = f14 (q, 0);
+  r = f15 (q, 63);
+  u = ~(__UINTPTR_TYPE__) 0 - (17 * sizeof (int));
+  q = (struct S *) u;
+  r = f16 (q);
+  r = f17 (q);
+  r = f18 (q);
+  r = f19 (q, 0);
+  r = f20 (q, 63);
+  u = 3 * sizeof (int);
+  q = (struct S *) u;
+  r = f21 (q);
+  r = f22 (q);
+  r = f23 (q);
+  r = f24 (q, -2);
+  r = f25 (q, -6);
+  return 0;
+}
+
+/* { dg-output ":5:6\[79]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+ overflowed to (0\[xX])?0\+(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*:6:6\[79]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?0\+ overflowed to (0\[xX])?\[fF]\+(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*:7:7\[46]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+9 overflowed to (0\[xX])?0\+(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*:8:7\[46]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?0\+3 overflowed to (0\[xX])?\[fF]\+(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*:9:7\[46]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?0\+17 overflowed to (0\[xX])?\[fF]\+\[cC](\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*:10:7\[46]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+1 overflowed to (0\[xX])?0\+(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*:11:\[89]\[80]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+\[eE]3 overflowed to (0\[xX])?0\+2(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*:13:\[89]\[80]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?0\+17 overflowed to (0\[xX])?\[fF]\+(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*:12:\[89]\[80]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?0\+7 overflowed to (0\[xX])?\[fF]\+(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*:14:\[89]\[91]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+\[eE]7 overflowed to (0\[xX])?0\+" } */
+/* { dg-output "(\n|\r\n|\r)" { target int32 } } */
+/* { dg-output "\[^\n\r]*:17:\[67]\[82]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+ overflowed to (0\[xX])?0\+3(\n|\r\n|\r)" { target int32 } } */
+/* { dg-output "\[^\n\r]*:18:\[67]\[86]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+ overflowed to (0\[xX])?0\+107(\n|\r\n|\r)" { target int32 } } */
+/* { dg-output "\[^\n\r]*:19:\[78]\[52]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+ overflowed to (0\[xX])?0\+7(\n|\r\n|\r)" { target int32 } } */
+/* { dg-output "\[^\n\r]*:20:\[78]\[52]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+ overflowed to (0\[xX])?0\+103(\n|\r\n|\r)" { target int32 } } */
+/* { dg-output "\[^\n\r]*:23:\[67]\[86]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+\[bB]\[bB] overflowed to (0\[xX])?0\+\[cC]3(\n|\r\n|\r)" { target int32 } } */
+/* { dg-output "\[^\n\r]*:25:\[78]\[52]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?\[fF]\+\[bB]\[bB] overflowed to (0\[xX])?0\+\[bB]\[fF](\n|\r\n|\r)" { target int32 } } */
+/* { dg-output "\[^\n\r]*:30:\[78]\[52]\[^\n\r]*runtime error: pointer index expression with base (0\[xX])?0\+\[cC] overflowed to (0\[xX])?\[fF]\+\[cC]" { target int32 } } */
--- libsanitizer/ubsan/ubsan_handlers.cc.jj	2017-06-19 08:26:17.073600279 +0200
+++ libsanitizer/ubsan/ubsan_handlers.cc	2017-07-26 13:44:14.261199463 +0200
@@ -521,6 +521,37 @@ void __ubsan::__ubsan_handle_nonnull_arg
   Die();
 }
 
+static void handlePointerOverflowImpl(PointerOverflowData *Data,
+                                      ValueHandle Base,
+                                      ValueHandle Result,
+                                      ReportOptions Opts) {
+  SourceLocation Loc = Data->Loc.acquire();
+  ErrorType ET = ErrorType::PointerOverflow;
+
+  if (ignoreReport(Loc, Opts, ET))
+    return;
+
+  ScopedReport R(Opts, Loc, ET);
+
+  Diag(Loc, DL_Error, "pointer index expression with base %0 overflowed to %1")
+    << (void *)Base << (void*)Result;
+}
+
+void __ubsan::__ubsan_handle_pointer_overflow(PointerOverflowData *Data,
+                                              ValueHandle Base,
+                                              ValueHandle Result) {
+  GET_REPORT_OPTIONS(false);
+  handlePointerOverflowImpl(Data, Base, Result, Opts);
+}
+
+void __ubsan::__ubsan_handle_pointer_overflow_abort(PointerOverflowData *Data,
+                                                    ValueHandle Base,
+                                                    ValueHandle Result) {
+  GET_REPORT_OPTIONS(true);
+  handlePointerOverflowImpl(Data, Base, Result, Opts);
+  Die();
+}
+
 static void handleCFIBadIcall(CFICheckFailData *Data, ValueHandle Function,
                               ReportOptions Opts) {
   if (Data->CheckKind != CFITCK_ICall)
--- libsanitizer/ubsan/ubsan_checks.inc.jj	2017-06-19 08:26:17.061600432 +0200
+++ libsanitizer/ubsan/ubsan_checks.inc	2017-07-26 13:44:14.275199294 +0200
@@ -17,6 +17,7 @@
 
 UBSAN_CHECK(GenericUB, "undefined-behavior", "undefined")
 UBSAN_CHECK(NullPointerUse, "null-pointer-use", "null")
+UBSAN_CHECK(PointerOverflow, "pointer-overflow", "pointer-overflow")
 UBSAN_CHECK(MisalignedPointerUse, "misaligned-pointer-use", "alignment")
 UBSAN_CHECK(InsufficientObjectSize, "insufficient-object-size", "object-size")
 UBSAN_CHECK(SignedIntegerOverflow, "signed-integer-overflow",
--- libsanitizer/ubsan/ubsan_handlers.h.jj	2017-06-19 08:26:17.073600279 +0200
+++ libsanitizer/ubsan/ubsan_handlers.h	2017-07-26 13:44:14.282199209 +0200
@@ -146,6 +146,13 @@ struct NonNullArgData {
 /// \brief Handle passing null pointer to function with nonnull attribute.
 RECOVERABLE(nonnull_arg, NonNullArgData *Data)
 
+struct PointerOverflowData {
+  SourceLocation Loc;
+};
+
+RECOVERABLE(pointer_overflow, PointerOverflowData *Data, ValueHandle Base,
+            ValueHandle Result)
+
 /// \brief Known CFI check kinds.
 /// Keep in sync with the enum of the same name in CodeGenFunction.h
 enum CFITypeCheckKind : unsigned char {

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.

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 2 patches:

- UBSAN -fsanitize=pointer-overflow support
  - http://gcc.gnu.org/ml/gcc-patches/2017-06/msg01365.html

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

	Jakub

Re: Patch ping

[Nathan Sidwell]

On 04/10/2017 09:22 AM, Jakub Jelinek wrote:

> and there I see COMPONENT_REF with BASELINK second operand with
> BASELINK_FUNCTIONS being an overload only for the methods.
> And even if I try overload with mixed methods and static member functions,
> lvalue_kind with that is only called when seeing the invalid binding
> to method:


> struct X { void o(unsigned char); static void o(int); void o(double); } x;
> void (&r12)(int) = x.o;
> void (&r13)(double) = x.o;

Ok, that makes sense.  This patch is ok, with ...

> +	  /* For static member function recurse on the BASELINK.  */

Mention that overloads of more than one function go via a different path.

nathan

-- 
Nathan Sidwell

Re: Patch ping

[Jakub Jelinek]

On Mon, Apr 10, 2017 at 08:41:28AM -0400, Nathan Sidwell wrote:
> On 04/10/2017 08:18 AM, Jakub Jelinek wrote:
> > Hi!
> > 
> > I'd like to ping 2 patches:
> > 
> > P2 PR c++/80176
> >    http://gcc.gnu.org/ml/gcc-patches/2017-04/msg00027.html
> >    reference binding to static member function
> 
> This smells fishy.  There's no reason one cannot have an overload set
> containing both static and non-static functions, in any order.  So it'll be
> 'random' as to which member of the set OVL_CURRENT looks at.

I actually don't know if I need the OVL_CURRENT thing, maybe not.
On the testcase there is an overloaded static member function and I don't
get an error on that, just on the non-overloaded one.
I've tried:
struct X { static void foo(); static void baz(int); static int baz(double); void m(int); void n(int); int n(float); } x;
void X::foo() {}
static void bar() {}
void (&r1)() = x.foo;
void (&r2)() = X::foo;
void (&r3)() = bar;
void (&r4)(int) = x.baz;
int (&r5)(double) = x.baz;
void (&r6)(int) = X::baz;
int (&r7)(double) = X::baz;
void (&r8)(int) = x.m;
void (&r9)(int) = x.n;
int (&r10)(float) = x.n;
and there I see COMPONENT_REF with BASELINK second operand with
BASELINK_FUNCTIONS being an overload only for the methods.
And even if I try overload with mixed methods and static member functions,
lvalue_kind with that is only called when seeing the invalid binding
to method:
struct X { void o(unsigned char); static void o(int); void o(double); } x;
void (&r12)(int) = x.o;
void (&r13)(double) = x.o;

Thus, would it be acceptable to omit the OVL_CURRENT as in (tested so far
just on the updated ref23.C with additional test from the above r12 snippet,
of course would perform full bootstrap/regtest with that)?

2017-04-08  Jakub Jelinek  <jakub@redhat.com>

	PR c++/80176
	* tree.c (lvalue_kind): For COMPONENT_REF with BASELINK second
	operand, if it is a static member function, recurse on the
	BASELINK.

	* g++.dg/init/ref23.C: New test.

--- gcc/cp/tree.c.jj	2017-04-07 21:17:57.078208891 +0200
+++ gcc/cp/tree.c	2017-04-10 15:18:57.941508441 +0200
@@ -105,6 +105,14 @@ lvalue_kind (const_tree ref)
       return op1_lvalue_kind;
 
     case COMPONENT_REF:
+      if (BASELINK_P (TREE_OPERAND (ref, 1)))
+	{
+	  tree fn = BASELINK_FUNCTIONS (TREE_OPERAND (ref, 1));
+
+	  /* For static member function recurse on the BASELINK.  */
+	  if (TREE_CODE (fn) == FUNCTION_DECL && DECL_STATIC_FUNCTION_P (fn))
+	    return lvalue_kind (TREE_OPERAND (ref, 1));
+	}
       op1_lvalue_kind = lvalue_kind (TREE_OPERAND (ref, 0));
       /* Look at the member designator.  */
       if (!op1_lvalue_kind)
--- gcc/testsuite/g++.dg/init/ref23.C.jj	2017-04-10 15:17:04.823911276 +0200
+++ gcc/testsuite/g++.dg/init/ref23.C	2017-04-10 15:18:07.504133944 +0200
@@ -0,0 +1,15 @@
+// PR c++/80176
+// { dg-do compile }
+
+struct X { static void foo(); static void baz(int); static int baz(double); } x;
+struct Y { void o(unsigned char); static void o(int); void o(double); } y;
+void X::foo() {}
+static void bar() {}
+void (&r1)() = x.foo;
+void (&r2)() = X::foo;
+void (&r3)() = bar;
+void (&r4)(int) = x.baz;
+int (&r5)(double) = x.baz;
+void (&r6)(int) = X::baz;
+int (&r7)(double) = X::baz;
+void (&r8)(int) = y.o;

	Jakub

Re: Patch ping

[Nathan Sidwell]

On 04/10/2017 08:18 AM, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping 2 patches:
>
> P2 PR c++/80176
>    http://gcc.gnu.org/ml/gcc-patches/2017-04/msg00027.html
>    reference binding to static member function

This smells fishy.  There's no reason one cannot have an overload set 
containing both static and non-static functions, in any order.  So it'll 
be 'random' as to which member of the set OVL_CURRENT looks at.

You at least want '&& !OVL_NEXT (..)' there to make sure you just have a 
single static fn (if that's what you want?)


nathan

-- 
Nathan Sidwell

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 2 patches:

P2 PR c++/80176
   http://gcc.gnu.org/ml/gcc-patches/2017-04/msg00027.html
   reference binding to static member function

PR debug/80263
   http://gcc.gnu.org/ml/gcc-patches/2017-04/msg00004.html
   avoid emitting sizetype artificial name into debug info

Thanks

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 2 patches:

P1 PR debug/80234
  http://gcc.gnu.org/ml/gcc-patches/2017-03/msg01489.html
  Fix dwarf2out ICE with C++17 inline static data members with redundant
  redeclaration

PR c/80163
  http://gcc.gnu.org/ml/gcc-patches/2017-03/msg01324.html
  Fix EXPAND_INITIALIZER expansion of extensions

	Jakub

Re: Patch ping

[Jakub Jelinek]

On Fri, Mar 31, 2017 at 09:07:14AM -0600, Jeff Law wrote:
> On 03/31/2017 12:36 AM, Jakub Jelinek wrote:
> > Hi!
> > 
> > I'd like to ping two patches:
> > 
> > PR c++/79572
> >   - ubsan instrumentation of reference binding to NULL if the reference
> >     is folded into INTEGER_CST with REFERENCE_TYPE
> >     http://gcc.gnu.org/ml/gcc-patches/2017-03/msg01255.html
> Just one question here -- we're working with pure trees or perhaps generic,
> not gimple here, right?  Assuming that is true, this is OK.

It is invoked during genericization, i.e. when the C++ FE trees are lowered
into generic.

	Jakub

Re: Patch ping

[Jeff Law]

On 03/31/2017 12:36 AM, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping two patches:
>
> PR c++/79572
>   - ubsan instrumentation of reference binding to NULL if the reference
>     is folded into INTEGER_CST with REFERENCE_TYPE
>     http://gcc.gnu.org/ml/gcc-patches/2017-03/msg01255.html
>
> PR debug/79255
>   - dwarf2out profiledbootstrap ICE while building gnat;
>     either the posted patch
>     http://gcc.gnu.org/ml/gcc-patches/2017-03/msg01257.html
>     or in gen_decl_die:
>    case FUNCTION_DECL:
> +    /* decl is NULL only if when processing a function declaration in
> +       BLOCK_NONLOCALIZED_VARS.  It is a normal declaration, not an
> +       abstract copy of something, so make sure we don't handle it
> +       like function inlined into something.  */
> +    if (decl == NULL_TREE)
> +      {
> +	decl = origin;
> +	origin = NULL_TREE;
> +      }
>     or something else (another possibility is to replace all decl
>     uses in case FUNCTION_DECL with decl_or_origin and
> -	  if (!origin)
> -	    origin = decl_class_context (decl);
> +	  if (!decl || !origin)
> +	    origin = decl_class_context (decl_or_origin);
I think I prefer your original approach -- pass in the original 
FUNCTION_DECL.  It seems to me like the other approaches are just 
papering over the issue.

Original approach is OK for the trunk.

jeff

Re: Patch ping

[Jeff Law]

On 03/31/2017 12:36 AM, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping two patches:
>
> PR c++/79572
>   - ubsan instrumentation of reference binding to NULL if the reference
>     is folded into INTEGER_CST with REFERENCE_TYPE
>     http://gcc.gnu.org/ml/gcc-patches/2017-03/msg01255.html
Just one question here -- we're working with pure trees or perhaps 
generic, not gimple here, right?  Assuming that is true, this is OK.

If instead we are working with gimple, then consider renaming "stmt" in 
ubsan_maybe_instrument_reference -- when I see "stmt" I think a gimple 
statement, not a tree:-)

jeff

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping two patches:

PR c++/79572
  - ubsan instrumentation of reference binding to NULL if the reference
    is folded into INTEGER_CST with REFERENCE_TYPE
    http://gcc.gnu.org/ml/gcc-patches/2017-03/msg01255.html

PR debug/79255
  - dwarf2out profiledbootstrap ICE while building gnat;
    either the posted patch
    http://gcc.gnu.org/ml/gcc-patches/2017-03/msg01257.html
    or in gen_decl_die:
   case FUNCTION_DECL:
+    /* decl is NULL only if when processing a function declaration in
+       BLOCK_NONLOCALIZED_VARS.  It is a normal declaration, not an
+       abstract copy of something, so make sure we don't handle it
+       like function inlined into something.  */
+    if (decl == NULL_TREE)
+      {
+	decl = origin;
+	origin = NULL_TREE;
+      }
    or something else (another possibility is to replace all decl
    uses in case FUNCTION_DECL with decl_or_origin and
-	  if (!origin)
-	    origin = decl_class_context (decl);
+	  if (!decl || !origin)
+	    origin = decl_class_context (decl_or_origin);
    )?
    
	Jakub

Re: Patch ping

[Uros Bizjak]

On Tue, Feb 7, 2017 at 4:11 PM, Jakub Jelinek <jakub@redhat.com> 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

[Jakub Jelinek]

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

Thanks

	Jakub

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 <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)

Patch ping

[Jakub Jelinek]

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" } } */
or:
-/* { dg-additional-options "-O0 -fno-lto" } */
+/* { dg-skip-if "" { *-*-* } { "*" } { "-O0" } } */
+/* { dg-skip-if "" { *-*-* } { "-flto" } { "" } } */

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 3 patches:

PR debug/78835 P1 -fdebug-types-section fix
http://gcc.gnu.org/ml/gcc-patches/2017-01/msg01316.html

PR debug/79129 P1 another -fdebug-types-section fix
http://gcc.gnu.org/ml/gcc-patches/2017-01/msg01478.html

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

Thanks.

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 2 patches:

- DWARF5 - adjust for 161031.2 resolution - remove padding from unit headers
  http://gcc.gnu.org/ml/gcc-patches/2017-01/msg00138.html

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

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 2 patches:

http://gcc.gnu.org/ml/gcc-patches/2016-11/msg01074.html
- C++ ABI - mangling of TLS aux symbols; either the posted
  patch or one with if (abi_version_at_least (11))

http://gcc.gnu.org/ml/gcc-patches/2016-11/msg00351.html
- DWARF Solaris bootstrap fix

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the
[C++ PATCH] Fix -Wimplicit-fallthrough in templates (PR c++/77886)
patch:

On Sat, Oct 08, 2016 at 08:13:50AM +0200, Jakub Jelinek wrote:
> 2016-10-08  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR c++/77886
> 	* pt.c (tsubst_expr) <case CASE_LABEL_EXPR> Copy over
> 	FALLTHROUGH_LABEL_P flag to the new LABEL_DECL.
> 	(tsubst_expr) <case LABEL_EXPR>: Likewise.
> 
> 	* g++.dg/warn/Wimplicit-fallthrough-2.C: New test.

Thanks.

	Jakub

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

[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: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 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

[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

[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  <jakub@redhat.com>

	* 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.000000000 +0200
+++ gcc/gimple-ssa-sprintf.c	2016-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

[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  <jakub@redhat.com>

	* 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.000000000 +0200
+++ gcc/gimple-ssa-sprintf.c	2016-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_length::execute (function *
 	  /* Iterate over statements, looking for function calls.  */
 	  gimple *stmt = gsi_stmt (si);
 
-	  if (gimple_code (stmt) == GIMPLE_CALL)
+	  if (is_gimple_call (stmt))
 	    handle_gimple_call (si);
 	}
     }

	Jakub

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

Patch ping

[Jakub Jelinek]

Hi!

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.

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

On Tue, Sep 20, 2016 at 06:12:26PM +0200, Jakub Jelinek wrote:
> 2016-09-20  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR c++/77467
> 	* constexpr.c (enum constexpr_switch_state): New.
> 	(struct constexpr_ctx): Add css_state field.
> 	(label_matches): Add CTX and STMT arguments, remove I and
> 	DEFAULT_LABEL.  For CASE_LABEL_EXPR assert ctx->css_state != NULL,
> 	handle default labels according to css_state.
> 	(cxx_eval_statement_list): Remove statement skipping, label_matches
> 	and default_label handling code.
> 	(cxx_eval_loop_expr): Exit after first iteration even if
> 	switches (jump_target).
> 	(cxx_eval_switch_expr): Set up css_state field in ctx, if default
> 	label has been seen in the body, but no cases matched, evaluate
> 	the body second time.
> 	(cxx_eval_constant_expression): Handle stmt skipping and label_matches
> 	here.  Handle PREDICT_EXPR.  For MODIFY_EXPR or INIT_EXPR, assert
> 	statement is not skipped.  For COND_EXPR during skipping, don't
> 	evaluate condition, just the then block and if still skipping at the
> 	end also the else block.
> 	(cxx_eval_outermost_constant_expr): Adjust constexpr_ctx initializer.
> 	(is_sub_constant_expr): Likewise.
> 
> 	* g++.dg/cpp1y/constexpr-77467.C: New test.

I'd like to ping this patch.  Ok for trunk?

	Jakub

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

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping a couple of patches:

C++
===

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

http://gcc.gnu.org/ml/gcc-patches/2016-09/msg00228.html
  - PR77467 - fix constexpr switch handling

http://gcc.gnu.org/ml/gcc-patches/2016-09/msg00230.html
  - PR77482 - fix ICE in cp/error.c

x86
===

http://gcc.gnu.org/ml/gcc-patches/2016-09/msg00339.html
  - PR77475 - i386 backend part of the spellcheck option changes

sched
=====

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

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping following fix:
PR71910 - http://gcc.gnu.org/ml/gcc-patches/2016-08/msg00624.html

	Jakub

Patch ping

[Cesar Philippidis]

The following patches still need to be reviewed:

* Change an LTO wrapper assert failure to an error when it detects
  missing symbols. This situation can arise in offloading code, e.g.
  when the user forgets to declare a global variable as offloadable.

  https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00043.html

* Add support for OpenACC routine clauses in fortran modules. Also,
  allow the routine directive to be applied to intrinsic procedures.

  https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00063.html

Thanks,
Cesar

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping a couple of C++ patches:

- PR70869 - change fix from cp_genericize_r tweak to cp_walk_subtrees
  http://gcc.gnu.org/ml/gcc-patches/2016-07/msg00568.html

- PR71835 - fix diagnostic ICE
  http://gcc.gnu.org/ml/gcc-patches/2016-07/msg00567.html

- PR71828 - fix *PART_EXPR handling in constexpr
  http://gcc.gnu.org/ml/gcc-patches/2016-07/msg00565.html

- PR71826 - fix error recovery in tsubst_baselink
  http://gcc.gnu.org/ml/gcc-patches/2016-07/msg00530.html

- PR71822 - fix ICE with VEC_INIT_EXPR
  http://gcc.gnu.org/ml/gcc-patches/2016-07/msg00528.html

	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.

Patch ping

[Jakub Jelinek]

Hi!

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

Thanks

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 3 XMM16+ patches:

1) avx_vec_concat<mode>
   http://gcc.gnu.org/ml/gcc-patches/2016-05/msg01826.html

2) *vec_concatv4si
   http://gcc.gnu.org/ml/gcc-patches/2016-05/msg02115.html

3) *vec_concatv2si_sse4_1
   http://gcc.gnu.org/ml/gcc-patches/2016-05/msg02129.html

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 2 patches, one mine:
  P2 PR70001 http://gcc.gnu.org/ml/gcc-patches/2016-03/msg00710.html
and one from Alex, which hasn't been pinged for quite a while, but is P1:
  P1 PR69315 https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02010.html

Thanks.

	Jakub

Re: Patch ping

[Jason Merrill]

OK.

Jason

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping a C++ PR70144 patch:
  http://gcc.gnu.org/ml/gcc-patches/2016-03/msg00653.html
Since then, Zdenek has filed another PR with __builtin_constant_p (foo)
where foo is FUNCTION_DECL, and only the above version fixes that, not the
other one.

	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

Patch ping

[Jakub Jelinek]

Hi!

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

	Jakub

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/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_<whatever> 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

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping fix for P1 PR69947:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01743.html

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping a C++ P1 fix for PR69658:
  http://gcc.gnu.org/ml/gcc-patches/2016-02/msg00352.html

	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 <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)

Patch ping

[Jakub Jelinek]

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

	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-

Patch ping

[Jakub Jelinek]

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?

	Jakub

Re: patch ping

[Bernhard Reutner-Fischer]

On April 13, 2015 3:12:48 PM GMT+02:00, Jeff Law <law@redhat.com> 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

[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

[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

[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

Patch ping

[Jakub Jelinek]

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.

	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

patch ping

[Bernhard Reutner-Fischer]

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

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


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

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

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

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping following patch:

PR65238 - P1 - http://gcc.gnu.org/ml/gcc-patches/2015-03/msg00647.html
  - fix __has_{,cpp_}attribute() with -traditional-cpp

Thanks.

	Jakub

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

[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  <jakub@redhat.com>
> > 
> > 	* 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 <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild,
Dilip Upmanyu, Graham Norton HRB 21284 (AG Nuernberg)

Patch ping

[Jakub Jelinek]

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

> 2015-02-18  Jakub Jelinek  <jakub@redhat.com>
> 
> 	* 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

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping following patch:

http://gcc.gnu.org/ml/gcc-patches/2015-02/msg00367.html
  - PR55541 - P2 - C++ debug info fix

Thanks.

	Jakub

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

patch ping

[Trevor Saunders]

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

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

thanks!

Trev

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 2 patches:

http://gcc.gnu.org/ml/gcc-patches/2015-01/msg02530.html
  - P2 - PR61925 - fix x86 #pragma GCC target handling

http://gcc.gnu.org/ml/gcc-patches/2015-01/msg02432.html
  - emit DW_LANG_Fortran{03,08} for -gdwarf-5

	Jakub

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...

[Jan Hubicka]

Hi,
I would like to ping the patch to fix divergence between a type and its main variant introduced by C++ FE.
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01202.html

Honza

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

[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

[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

[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

Patch ping

[Jakub Jelinek]

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

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

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

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 3 patches:

http://gcc.gnu.org/ml/gcc-patches/2014-12/msg00546.html
  PR63831 - P1 - fix __has_attribute/__has_cpp_attribute handling

http://gcc.gnu.org/ml/gcc-patches/2014-12/msg00568.html
  PR64023 - P3 - fix flags passed to non-bootstrapped host modules during bootstrap

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

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the -fsanitize=alignment patch:
http://gcc.gnu.org/ml/gcc-patches/2014-07/msg00334.html

Thanks.

	Jakub

Re: Patch ping

[Uros Bizjak]

On Wed, Apr 16, 2014 at 11:35 PM, Jeff Law <law@redhat.com> 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
>> <MODE_SIZE>
>>    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

[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

[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 <MODE_SIZE>
>    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

[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

[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: toon@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

[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

[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 <MODE_SIZE>
> >>>   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

[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

[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

[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

[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

[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.

Patch ping

[Jakub Jelinek]

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

Thanks

	Jakub

Patch ping

[Jakub Jelinek]

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

- 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

[Jakub Jelinek]

On Mon, Jan 13, 2014 at 07:40:16PM +0100, Uros Bizjak wrote:
> An unrelated observation: gcc should figure out that %k1 mask register
> can be used in all gather insns and avoid unnecessary copies at the
> beginning of the loop.

I thought about that too, even started modifying sse.md, but then I read the
spec and the AVX512F gather insns overwrite the mask register (like it does
for the vector mask register in AVX2 case).

	Jakub

Re: Patch ping

[Uros Bizjak]

On Mon, Jan 13, 2014 at 7:26 PM, Kirill Yukhin <kirill.yukhin@gmail.com> wrote:

>> > Kirill, is it possible for you to test the patch in the simulator? Do
>> > we have a testcase in gcc's testsuite that can be used to check this
>> > patch?
>>
>> E.g. gcc.target/i386/avx2-gather* and avx512f-gather*.
> This tests are for built-in generation. The issue is connected to
> auto code gen.
>
> It seems to be working, we have for hss2a.fppized.f:
> .L402:
>         vmovdqu64       (%rdi,%rax), %zmm1
>         kmovw   %k1, %k3
>         kmovw   %k1, %k2
>         kmovw   %k1, %k4
>         kmovw   %k1, %k5
>         addl    $1, %esi
>         vpgatherdd      npwrx.4971-4(,%zmm1,4), %zmm0{%k3}
>         vpgatherdd      (%r10,%zmm1,4), %zmm2{%k2}
>         vpmulld %zmm3, %zmm0, %zmm0
>         vpaddd  %zmm7, %zmm0, %zmm0
>         vmovdqu32       %zmm0, (%r11,%rax)
>         vpgatherdd      npwry.4973-4(,%zmm1,4), %zmm0{%k4}
>         vpmulld %zmm3, %zmm0, %zmm0
>         vpaddd  %zmm6, %zmm0, %zmm0
>         vmovdqu32       %zmm0, (%r9,%rax)
>         vpgatherdd      npwrz.4975-4(,%zmm1,4), %zmm0{%k5}
>         vpmulld %zmm3, %zmm0, %zmm0
>         vpaddd  %zmm5, %zmm0, %zmm0
>         vmovdqu32       %zmm0, (%r14,%rax)
>         vpaddd  %zmm2, %zmm4, %zmm0
>         vmovdqa64       %zmm0, (%r15,%rax)
>         addq    $64, %rax
>         cmpl    %esi, %edx
>         ja      .L402

An unrelated observation: gcc should figure out that %k1 mask register
can be used in all gather insns and avoid unnecessary copies at the
beginning of the loop.

Uros.

Re: Patch ping

[Uros Bizjak]

On Mon, Jan 13, 2014 at 7:26 PM, Kirill Yukhin <kirill.yukhin@gmail.com> wrote:

>> On Mon, Jan 13, 2014 at 09:15:14AM +0100, Uros Bizjak wrote:
>> > On Mon, Jan 13, 2014 at 9:07 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>> > Kirill, is it possible for you to test the patch in the simulator? Do
>> > we have a testcase in gcc's testsuite that can be used to check this
>> > patch?
>>
>> E.g. gcc.target/i386/avx2-gather* and avx512f-gather*.
> This tests are for built-in generation. The issue is connected to
> auto code gen.
>
> It seems to be working, we have for hss2a.fppized.f:
> .L402:
>         vmovdqu64       (%rdi,%rax), %zmm1
>         kmovw   %k1, %k3
>         kmovw   %k1, %k2
>         kmovw   %k1, %k4
>         kmovw   %k1, %k5
>         addl    $1, %esi
>         vpgatherdd      npwrx.4971-4(,%zmm1,4), %zmm0{%k3}
>         vpgatherdd      (%r10,%zmm1,4), %zmm2{%k2}
>         vpmulld %zmm3, %zmm0, %zmm0
>         vpaddd  %zmm7, %zmm0, %zmm0
>         vmovdqu32       %zmm0, (%r11,%rax)
>         vpgatherdd      npwry.4973-4(,%zmm1,4), %zmm0{%k4}
>         vpmulld %zmm3, %zmm0, %zmm0
>         vpaddd  %zmm6, %zmm0, %zmm0
>         vmovdqu32       %zmm0, (%r9,%rax)
>         vpgatherdd      npwrz.4975-4(,%zmm1,4), %zmm0{%k5}
>         vpmulld %zmm3, %zmm0, %zmm0
>         vpaddd  %zmm5, %zmm0, %zmm0
>         vmovdqu32       %zmm0, (%r14,%rax)
>         vpaddd  %zmm2, %zmm4, %zmm0
>         vmovdqa64       %zmm0, (%r15,%rax)
>         addq    $64, %rax
>         cmpl    %esi, %edx
>         ja      .L402
>
> So, I vote that patch is working.

Well, OK for mainline, then.

Thanks,
Uros.

Re: Patch ping

[Kirill Yukhin]

Hello,
On 13 Jan 09:35, Jakub Jelinek wrote:
> On Mon, Jan 13, 2014 at 09:15:14AM +0100, Uros Bizjak wrote:
> > On Mon, Jan 13, 2014 at 9:07 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> > Kirill, is it possible for you to test the patch in the simulator? Do
> > we have a testcase in gcc's testsuite that can be used to check this
> > patch?
> 
> E.g. gcc.target/i386/avx2-gather* and avx512f-gather*.
This tests are for built-in generation. The issue is connected to
auto code gen.

It seems to be working, we have for hss2a.fppized.f:
.L402:
        vmovdqu64       (%rdi,%rax), %zmm1
        kmovw   %k1, %k3
        kmovw   %k1, %k2
        kmovw   %k1, %k4
        kmovw   %k1, %k5
        addl    $1, %esi
        vpgatherdd      npwrx.4971-4(,%zmm1,4), %zmm0{%k3}
        vpgatherdd      (%r10,%zmm1,4), %zmm2{%k2}
        vpmulld %zmm3, %zmm0, %zmm0
        vpaddd  %zmm7, %zmm0, %zmm0
        vmovdqu32       %zmm0, (%r11,%rax)
        vpgatherdd      npwry.4973-4(,%zmm1,4), %zmm0{%k4}
        vpmulld %zmm3, %zmm0, %zmm0
        vpaddd  %zmm6, %zmm0, %zmm0
        vmovdqu32       %zmm0, (%r9,%rax)
        vpgatherdd      npwrz.4975-4(,%zmm1,4), %zmm0{%k5}
        vpmulld %zmm3, %zmm0, %zmm0
        vpaddd  %zmm5, %zmm0, %zmm0
        vmovdqu32       %zmm0, (%r14,%rax)
        vpaddd  %zmm2, %zmm4, %zmm0
        vmovdqa64       %zmm0, (%r15,%rax)
        addq    $64, %rax
        cmpl    %esi, %edx
        ja      .L402

So, I vote that patch is working.

--
Thanks, K

Re: Patch ping

[Jakub Jelinek]

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 <MODE_SIZE>
> >   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.

	Jakub

Re: Patch ping

[Jeff Law]

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 <MODE_SIZE>
>>>    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 ;-)

jeff

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 <MODE_SIZE>
>    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.

jeff

Re: Patch ping

[Richard Biener]

On Mon, 13 Jan 2014, Jakub Jelinek wrote:

> On Mon, Jan 13, 2014 at 09:15:14AM +0100, Uros Bizjak wrote:
> > On Mon, Jan 13, 2014 at 9:07 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> > 
> > > 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)
> > 
> > This one needs tree-optimization approval first.
> 
> Sure, that is why Richard was on To line too ;)

The vectorizer parts are ok.

Richard.

Re: Patch ping

[Jakub Jelinek]

On Mon, Jan 13, 2014 at 09:15:14AM +0100, Uros Bizjak wrote:
> On Mon, Jan 13, 2014 at 9:07 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> 
> > 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)
> 
> This one needs tree-optimization approval first.

Sure, that is why Richard was on To line too ;)

> Kirill, is it possible for you to test the patch in the simulator? Do
> we have a testcase in gcc's testsuite that can be used to check this
> patch?

E.g. gcc.target/i386/avx2-gather* and avx512f-gather*.

	Jakub

Re: Patch ping

[Uros Bizjak]

On Mon, Jan 13, 2014 at 9:07 AM, Jakub Jelinek <jakub@redhat.com> wrote:

> 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)

This one needs tree-optimization approval first.

Kirill, is it possible for you to test the patch in the simulator? Do
we have a testcase in gcc's testsuite that can be used to check this
patch?

Uros.

Patch ping

[Jakub Jelinek]

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 <MODE_SIZE>
  patch for the reasons mentioned there, but also add this patch)

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)

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping a few unreviewed patches:

- use libbacktrace in libsanitizer symbolization - PR sanitizer/59136
  http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00558.html

- allow building libsanitizer against older kernel headers
  http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00963.html

- use cp-demangle as libsanitizer+libbacktrace demangler
  http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00964.html
  (note, Gary has already committed his fix, so the demangler
  is now really malloc/calloc/realloc call free)

- ifcvt/crossjumping fix - PR rtl-optimization/58668
  http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01726.html
  (note, Eric approved earlier version of the patch but Steven
  wanted to use active_insn_p instead, haven't committed anything
  yet, waiting to see what should be committed)

- improve Scimark2 SOR by 42% through small predcom change - PR tree-optimization/59643
  http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01986.html

- fix up PCH - PR pch/59436
  http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00016.html
  (note, as pointed out by Mike in followup, what I'd like to
  commit is a version with s/(void *) // in the patch, already
  bootstrapped/regtested)

	Jakub

Re: Patch ping

[Jeff Law]

On 05/17/2013 12:49 AM, Jakub Jelinek wrote:
> Hi!
>
> http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00282.html
> Reject -fsanitize=address -fsanitize=thread linking that won't ever work at
> runtime.
I thought Dodji already OK's this.    If there's any concern about the 
scope going outside Dodji's area, then I'll approve it :-)

jeff

Patch ping

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00282.html
Reject -fsanitize=address -fsanitize=thread linking that won't ever work at
runtime.

	Jakub

Re: Patch ping

[Gabriel Dos Reis]

On Thu, Apr 25, 2013 at 5:22 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> Hi!
>
> I'd like to ping 2 color diagnostics patches:
>
> - http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00787.html
>   colorize filename using locus color even when printed
>   without :line:column

you should declare the variables locus_cs and locus_ce
with initializers, instead of declaration followed by assignments.

OK with those changes.

>
> - http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00923.html
>   make -fdiagnostics-color=auto the default if GCC_COLORS
>   env var is in environment

This patch is OK.

Thanks!


>
>         Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 2 color diagnostics patches:

- http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00787.html
  colorize filename using locus color even when printed
  without :line:column

- http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00923.html
  make -fdiagnostics-color=auto the default if GCC_COLORS
  env var is in environment

	Jakub

Re: Patch ping

[Vladimir Makarov]

On 03/05/2013 08:12 AM, Jakub Jelinek wrote:
> Hi!
>
> Thanks for all the recent reviews of memory leak plugging patches,
> there are 4 still unreviewed from last week though.
>
>   LRA leak fix:
> http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01239.html
>
This patch is ok too.

Re: Patch ping

[Vladimir Makarov]

On 03/05/2013 08:12 AM, Jakub Jelinek wrote:
> Hi!
>
> Thanks for all the recent reviews of memory leak plugging patches,
> there are 4 still unreviewed from last week though.
>
> - sched-deps leak fix:
> http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01197.html
>
>
This patch is ok.  Thanks for working on this, Jakub.

Re: Patch ping

[Richard Biener]

On Tue, 5 Mar 2013, Jakub Jelinek wrote:

> On Tue, Mar 05, 2013 at 02:26:03PM +0100, Richard Biener wrote:
> > On Tue, 5 Mar 2013, Jakub Jelinek wrote:
> > > Thanks for all the recent reviews of memory leak plugging patches,
> > > there are 4 still unreviewed from last week though.
> > > 
> > > - sched-deps leak fix:
> > > http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01197.html
> > > 
> > > - LRA leak fix:
> > > http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01239.html
> > > 
> > > - libcpp leak fix:
> > > http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01341.html
> > > 
> > > - PCH leak fix + --enable-checking=valgrind changes to allow
> > >   --enable-checking=yes,valgrind bootstrap to succeed:
> > > http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00044.html
> > 
> > That looks awkward ... isn't there a simple valgrind_disable () /
> > valgrind_enable () way of disabling checking around this code?
> 
> Unfortunately not.  I went through all valgrind.h and memcheck.h
> client calls.  If at least there was a VALGRIND_GET_VBITS variants
> that allowed getting all vbits, (i.e. whether something is unaddressable
> vs. undefined vs. defined), rather than just if any of the vbits are
> unaddressable, give up, otherwise return undefined vs. defined bits,
> it would simplify the code.  I hope perhaps future valgrind version
> could add that, so it would be just VALGRIND_GET_VBITS2,
> VALGRIND_MAKE_MEM_DEFINED before and VALGRIND_SET_VBITS2 at the end
> (restore previous state).  I've at least added __builtin_expect,
> so the binary search code isn't in hot path.  It isn't that slow,
> during binary search I'm always testing just a single byte, and
> say if we don't have any single memory allocations > 4GB, it will be
> at most 37 valgrind client calls per objects, usually much smaller
> number than that.

Alternatively using a suppressions file during bootstrap might
be possible ... maybe also useful for general valgrind
debugging use?

Richard.

Re: Patch ping

[Jakub Jelinek]

On Tue, Mar 05, 2013 at 02:26:03PM +0100, Richard Biener wrote:
> On Tue, 5 Mar 2013, Jakub Jelinek wrote:
> > Thanks for all the recent reviews of memory leak plugging patches,
> > there are 4 still unreviewed from last week though.
> > 
> > - sched-deps leak fix:
> > http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01197.html
> > 
> > - LRA leak fix:
> > http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01239.html
> > 
> > - libcpp leak fix:
> > http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01341.html
> > 
> > - PCH leak fix + --enable-checking=valgrind changes to allow
> >   --enable-checking=yes,valgrind bootstrap to succeed:
> > http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00044.html
> 
> That looks awkward ... isn't there a simple valgrind_disable () /
> valgrind_enable () way of disabling checking around this code?

Unfortunately not.  I went through all valgrind.h and memcheck.h
client calls.  If at least there was a VALGRIND_GET_VBITS variants
that allowed getting all vbits, (i.e. whether something is unaddressable
vs. undefined vs. defined), rather than just if any of the vbits are
unaddressable, give up, otherwise return undefined vs. defined bits,
it would simplify the code.  I hope perhaps future valgrind version
could add that, so it would be just VALGRIND_GET_VBITS2,
VALGRIND_MAKE_MEM_DEFINED before and VALGRIND_SET_VBITS2 at the end
(restore previous state).  I've at least added __builtin_expect,
so the binary search code isn't in hot path.  It isn't that slow,
during binary search I'm always testing just a single byte, and
say if we don't have any single memory allocations > 4GB, it will be
at most 37 valgrind client calls per objects, usually much smaller
number than that.

	Jakub

Re: Patch ping

[Richard Biener]

On Tue, 5 Mar 2013, Jakub Jelinek wrote:

> Hi!
> 
> Thanks for all the recent reviews of memory leak plugging patches,
> there are 4 still unreviewed from last week though.
> 
> - sched-deps leak fix:
> http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01197.html
> 
> - LRA leak fix:
> http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01239.html
> 
> - libcpp leak fix:
> http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01341.html
> 
> - PCH leak fix + --enable-checking=valgrind changes to allow
>   --enable-checking=yes,valgrind bootstrap to succeed:
> http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00044.html

That looks awkward ... isn't there a simple valgrind_disable () /
valgrind_enable () way of disabling checking around this code?

Richard.

Patch ping

[Jakub Jelinek]

Hi!

Thanks for all the recent reviews of memory leak plugging patches,
there are 4 still unreviewed from last week though.

- sched-deps leak fix:
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01197.html

- LRA leak fix:
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01239.html

- libcpp leak fix:
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01341.html

- PCH leak fix + --enable-checking=valgrind changes to allow
  --enable-checking=yes,valgrind bootstrap to succeed:
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00044.html

	Jakub

Re: Patch ping

[Jeff Law]

On 02/07/2013 01:24 AM, Jakub Jelinek wrote:
> Hi!
>
> - http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01477.html
>    PR56154
>    fix invalid .debug_loc entries if an empty range is emitted
>    at .Ltext0 symbol
This is good.  Please install.

jeff

Patch ping

[Jakub Jelinek]

Hi!

- http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01477.html
  PR56154
  fix invalid .debug_loc entries if an empty range is emitted
  at .Ltext0 symbol

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01056.html
  PR55742 - P1 - fix multiversioning (i386 backend)

http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01105.html
  PR55374 - put -lasan early on the command line with -fsanitize=address

	Jakub

Re: Patch ping

[Paul Richard Thomas]

Dear Jakub,

The fortran part looks fine to me.  The sooner that you commit the
better - I will update the unlimited polymorphic patch accordingly.

Thanks

Paul

On 18 December 2012 15:11, Jakub Jelinek <jakub@redhat.com> wrote:
> Hi!
>
> - PR c/39464 P2 -Wpointer-sign fix
>   http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00523.html
>
> - PR fortran/55636 P1 Fortran ABI (mangling) fix
>   http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00726.html
>
> - PR c++/55619 C FE changes corresponding to C++ FE changes for inline asm "m" constrained inputs
>   http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00852.html
>
> - PR debug/54402 P1 --max-vartrack-reverse-op-size=N to speed up var-tracking
>   http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00891.html
>
>         Jakub



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy

Patch ping

[Jakub Jelinek]

Hi!

- PR c/39464 P2 -Wpointer-sign fix
  http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00523.html

- PR fortran/55636 P1 Fortran ABI (mangling) fix
  http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00726.html

- PR c++/55619 C FE changes corresponding to C++ FE changes for inline asm "m" constrained inputs
  http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00852.html

- PR debug/54402 P1 --max-vartrack-reverse-op-size=N to speed up var-tracking
  http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00891.html

	Jakub

Re: Patch ping

[Richard Biener]

On Mon, 26 Nov 2012, Jakub Jelinek wrote:

> - PR55137 fold reassociation fix                                                                                                                 
>   http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00636.html                                                                                        
>   (alternatively also retry with unsigned atype if the reassociation                                                                             
>   would fail otherwise)                                                                                                                          

Ok.

Thanks,
Richard.

Patch ping

[Jakub Jelinek]

- PR55137 fold reassociation fix                                                                                                                 
  http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00636.html                                                                                        
  (alternatively also retry with unsigned atype if the reassociation                                                                             
  would fail otherwise)                                                                                                                          

- PR43631 fix up var-tracking notes in between bbs
  http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01201.html

- PR55331 substitute_and_fold fix for memmove folding to nothing
  http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01302.html

- convert asan to use builtins instead of building fndecls on the fly
  http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01875.html

- PR55380 tiny libcpp performance fix + hack for asan/valgrind
  http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01973.html

	Jakub

Re: Patch ping

[Richard Henderson]

On 2012-11-18 23:53, Jakub Jelinek wrote:
> I'd prefer to only invalidate the stack pointer on the first assignment
> to the hard pointer.  If the cselib link between sp and hfp is already
> broken, invalidating sp will only result in worse code.  Dunno if there
> are any targets that adjust the hard frame pointer after it has been set
> once or similar.

I'm not aware of such a target.  Though I did not audit them now.

> Perhaps we could walk here CSELIB_VAL_PTR (hfpval)->locs here, and look
> if any rtls in there have find_base_term (x->loc) == find_base_term
> (stack_pointer_rtx), and only if yes, invalidate (and guard it by the
> modified_in_p test).

Sounds plausible.

> BTW, var-tracking.c uses a similar test.

Ouch.  Where is that?


r~

Re: Patch ping

[Jakub Jelinek]

On Sat, Nov 17, 2012 at 11:10:04AM -0800, Richard Henderson wrote:
> On 11/16/2012 01:10 AM, Jakub Jelinek wrote:
> > Hi!
> > 
> > - PR54921 invalidate sp in cselib on fp setter insn
> >   http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02035.html
> >   (perhaps in light of PR54402 the single_succ (ENTRY_BLOCK_PTR)
> >   from the patch should be nuked)
> 
> > +      rtx expr = find_reg_note (insn, REG_FRAME_RELATED_EXPR, NULL_RTX);
> > +      if (expr)
> > +	pat = XEXP (expr, 0);
> > +      if (GET_CODE (pat) == SET
> > +	  && SET_DEST (pat) == hard_frame_pointer_rtx)
> > +	cselib_invalidate_rtx (stack_pointer_rtx);
> > +      else if (GET_CODE (pat) == PARALLEL)
> 
> This is only one possible way that FP can be set.
> The others are with CFA_DEF_CFA or CFA_ADJUST_CFA.
> 
> Given 
> 
> +      && frame_pointer_needed
> +      && RTX_FRAME_RELATED_P (insn)
> 
> is there any reason to do more than
> 
>        && modified_in_p (hard_frame_pointer_rtx, insn)
> 
> ?

I'd prefer to only invalidate the stack pointer on the first assignment
to the hard pointer.  If the cselib link between sp and hfp is already
broken, invalidating sp will only result in worse code.  Dunno if there
are any targets that adjust the hard frame pointer after it has been set
once or similar.
Perhaps we could walk here CSELIB_VAL_PTR (hfpval)->locs here, and look
if any rtls in there have find_base_term (x->loc) == find_base_term
(stack_pointer_rtx), and only if yes, invalidate (and guard it by the
modified_in_p test).
BTW, var-tracking.c uses a similar test.

	Jakub

Re: Patch ping

[Richard Henderson]

On 11/16/2012 01:10 AM, Jakub Jelinek wrote:
> Hi!
> 
> - PR54921 invalidate sp in cselib on fp setter insn
>   http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02035.html
>   (perhaps in light of PR54402 the single_succ (ENTRY_BLOCK_PTR)
>   from the patch should be nuked)

> +      rtx expr = find_reg_note (insn, REG_FRAME_RELATED_EXPR, NULL_RTX);
> +      if (expr)
> +	pat = XEXP (expr, 0);
> +      if (GET_CODE (pat) == SET
> +	  && SET_DEST (pat) == hard_frame_pointer_rtx)
> +	cselib_invalidate_rtx (stack_pointer_rtx);
> +      else if (GET_CODE (pat) == PARALLEL)

This is only one possible way that FP can be set.
The others are with CFA_DEF_CFA or CFA_ADJUST_CFA.

Given 

+      && frame_pointer_needed
+      && RTX_FRAME_RELATED_P (insn)

is there any reason to do more than

       && modified_in_p (hard_frame_pointer_rtx, insn)

?


r~

Re: Patch ping

[Richard Henderson]

On 11/16/2012 01:10 AM, Jakub Jelinek wrote:
> - PR55236 range test optimization fix with -fwrapv
>   http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00707.html
>   (perhaps PLUS_EXPR can be handled similarly instead of bailing out)
> 

Ok.


r~

Re: Patch ping

[Richard Henderson]

On 11/16/2012 01:10 AM, Jakub Jelinek wrote:
> - PR55188 testcase fix for targets with different branch cost
>   http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00361.html

Ok.


r~

Patch ping

[Jakub Jelinek]

Hi!

- PR54921 invalidate sp in cselib on fp setter insn
  http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02035.html
  (perhaps in light of PR54402 the single_succ (ENTRY_BLOCK_PTR)
  from the patch should be nuked)

- PR55188 testcase fix for targets with different branch cost
  http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00361.html

- PR55137 fold reassociation fix
  http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00636.html
  (alternatively also retry with unsigned atype if the reassociation
  would fail otherwise)

- PR55236 range test optimization fix with -fwrapv
  http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00707.html
  (perhaps PLUS_EXPR can be handled similarly instead of bailing out)

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01538.html
  - PR54844 with lots of dups, C++ FE ICE with sizeof in template

http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01700.html
  - PR54970 small DW_OP_GNU_implicit_pointer improvements
  - the dwarf2out.c and tree-sra.c bits of the patch already
    acked, but cfgexpand.c and var-tracking.c bits are not

	Jakub

Re: Patch ping

[Richard Guenther]

On Mon, Aug 27, 2012 at 9:42 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01100.html
>   - C++ -Wsizeof-pointer-memaccess support (C is already in)
>
> http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01376.html
>   - valtrack ICE fix

This one is ok.

Thanks,
Richard.

>         Jakub

Patch ping

[Jakub Jelinek]

http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01100.html
  - C++ -Wsizeof-pointer-memaccess support (C is already in)

http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01376.html
  - valtrack ICE fix

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00105.html
  - add warning for complit with incomplte type

	Jakub

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~

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.

Patch ping

[Jakub Jelinek]

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

- PR51902 dwarf2out .debug_ranges ~ 22% reduction
  http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01171.html

	Jakub

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

Patch ping

[Jakub Jelinek]

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

	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.

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 3 patches:

- http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01335.html
  PR debug/51950
  -gdwarf-4 -fdebug-types-section cloning bug

- http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00034.html
  PR middle-end/52074
  fix EXPAND_NORMAL expansion with -fsection-anchors

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

	Jakub

Re: Patch ping

[Richard Guenther]

On Tue, Jan 24, 2012 at 11:28 AM, Jakub Jelinek <jakub@redhat.com> 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

Patch ping

[Jakub Jelinek]

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

	Jakub

Re: Patch ping

[Richard Guenther]

On Mon, Jan 2, 2012 at 11:37 AM, Jakub Jelinek <jakub@redhat.com> 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

Patch ping

[Jakub Jelinek]

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)

	Jakub

Re: Patch ping

[Richard Guenther]

On Mon, Nov 7, 2011 at 10:45 PM, Jakub Jelinek <jakub@redhat.com> 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.000000000 +0200
+++ libstdc++-v3/include/bits/stl_vector.h	2011-10-03 15:45:26.000000000 +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.

Patch ping

[Jakub Jelinek]

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.

	Jakub

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 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

[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 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.

Patch ping

[Jakub Jelinek]

Hi!

- Gather vectorization patch + incremental patches
  http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02411.html
  http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02846.html
  http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02851.html

	Jakub

Re: Patch ping

[Richard Sandiford]

Jakub Jelinek <jakub@redhat.com> 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

Patch ping

[Jakub Jelinek]

Hi!

A couple of unreviewed patches:

tree-ssa-strlen optimization:
  [1/2] http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00890.html
  [2/2] http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00891.html

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

fortran type_for_size langhook fixes:
  http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01418.html

	Jakub

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

Patch ping

[Jakub Jelinek]

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

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

	Jakub

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

[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

[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
joseph@codesourcery.com

Patch ping

[Jakub Jelinek]

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                                                                                   

	Jakub

Patch ping

[Jakub Jelinek]

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

	Jakub

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.

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

[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~

Patch ping

[Jakub Jelinek]

[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

[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

	Jakub

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

[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.

Patch ping

[Jakub Jelinek]

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

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

- 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-05/msg01454.html
  PR49032 fix dbxout so that -gstabs doesn't reference optimized
  away static vars

- 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

Patch ping

[Jakub Jelinek]

Hi!

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

- 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

Patch ping

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01117.html
  - fix unwind info in presence of inline asm, 4.6/4.7

http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01264.html
  - typed DWARF stack

	Jakub

Re: Patch ping

[Diego Novillo]

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

OK.


Diego.

Patch ping

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01749.html
  - PR middle-end/47917, snprintf folding

	Jakub

Re: Patch ping

[Jeff Law]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/28/11 01:52, Jakub Jelinek wrote:

> 
> PR47893 P1 http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01647.html
>         add_frame_space vs. temp_slot tracking of stack slots
Approved.

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

iQEcBAEBAgAGBQJNa9IMAAoJEBRtltQi2kC7NEUH/ioHe9fL9h0MTcfz/yCbOYG0
91YtPFh0zXide3Rt+DBvgooNd3fk5PdXT2dhkiXpP0IktlOMJJYwXjbH2CtR/Ny0
g2Kb4eQxAHRfjoty3v3CmYIV1Z+pMihSTXc5Zp143o2ysOHHgqGoS+LwpQYPPni3
ZNtliHZwLe+3jNT//pr0sv8qbGkg6e+L69ZAncM+RYnOpHZAwiOKzfr8h3z0xgoh
9P2SGF9aXLDrEYkkvj3W3Awy3BcsHdFIoxJM2AyZ9qwvo9ygQmd9LCs6CRnVL6Md
vgCp3zuFNZ2r8BenduNd4ooZk4jn2hblaQDK+cc4Sp+hoDbalqx6u2mLKrGD2go=
=AOuT
-----END PGP SIGNATURE-----

Re: Patch ping

[Jeff Law]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/28/11 01:52, Jakub Jelinek wrote:

> PR47283 P4 http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01166.html
>         debug fix for Pmode!=ptr_mode and special address mode targets
>         now tested on both ia64-hpux and spu-elf
OK.
Jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNa8C2AAoJEBRtltQi2kC7B2MH/2APoXMp90YPb6WTXHJK2qlf
v0RbAUApda/dGqKDxSG95a1frfV9adUN60J/AUjBUYaeOceWfb3cNQdSx6EzJXEl
Ghz4/V+NY1jGs6w+pc32rppcR2ZLiRV/5RiG+PrHcCK1V1b+6TSRh+n9idiTWVGj
UrUrNyzS4+daie89ytr5M7MGwSFEg3Ah9RgyPBYL1oXL34gpgBlRDvABFRoNRVFx
B4FTD+rTBwx7zg7nLnGL+BOzr2fJ/WXXfxRXgDQKvoI5ljQVawnA33NKxXYOdKgD
HPhN3ONrFV7hhhxLuIYwboLW5Mr2M6nsKFHlTEehaMecsrR0H6HO7v6+E7XMJKQ=
=TVX3
-----END PGP SIGNATURE-----

Re: Patch ping

[Jeff Law]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/28/11 01:52, Jakub Jelinek wrote:
> Hi!
> 
> PR46790 P1 http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01410.html
>         (or http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01426.html )
>         workaround for older ld --gc-sections issues
I prefer the first patch (test for buggy linker). OK for trunk.

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

iQEcBAEBAgAGBQJNa8AHAAoJEBRtltQi2kC7Z6wH/3iYC0d2whnamRRn2DUVZriA
qsXxlCo2w1e/VAV3HRh48sgUz3AT5ZcCWGJZY6tRQoEWPIWOyc5g2xyGA8XSlDdP
GfvV4QiUgREtw+U65Pp9NXaUFwx3Yv5Y8npAkzRU7WMncdrrjk+mz49uhyo6IbXE
TlOaY+7hYvaBKsu5GOjo5peTKaNZWDuWrb180mz3oJa+/p8cFTMVaQVwZXfUzgC1
DCBO5Zrg1ppZMT6QMGvASJutKJ3QDZ5ySjf01XllpdoKIhO6FXt+uTD7i53AWAih
QnnrUD9GC/AHcsmY37D02DYEkraiCd63J6LcfkucYKHhR+psjFjyVo7Oybyk0yw=
=/1tY
-----END PGP SIGNATURE-----

Patch ping

[Jakub Jelinek]

Hi!

PR46790 P1 http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01410.html
        (or http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01426.html )
        workaround for older ld --gc-sections issues

PR47893 P1 http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01647.html
        add_frame_space vs. temp_slot tracking of stack slots

PR47283 P4 http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01166.html
        debug fix for Pmode!=ptr_mode and special address mode targets
        now tested on both ia64-hpux and spu-elf

	Jakub

Re: Patch ping

[IainS]

On 3 Feb 2011, at 18:43, Mike Stump wrote:

> On Feb 3, 2011, at 8:38 AM, Jakub Jelinek wrote:
>> 2011-02-03  Jakub Jelinek  <jakub@redhat.com>
>>
>> 	* config/darwin.h (SECTION_NO_ANCHOR): Remove.
>> 	* config/darwin.c (SECTION_NO_ANCHOR): Define.
>> 	(darwin_init_sections): Remove assertion.
>
> Ok.

I guess, given that it was my code, I could have said that the change  
looked correct by inspection ...

... but,  FWIW, a stage1 compiler passed

make check-gcc-c RUNTESTFLAGS="--target_board=unix\{-fsection-anchors, 
\}\{-m32,-m64\} compat.exp=* struct-layout-1.exp=* vect.exp=*"

on powerpc-darwin9.

Iain

Re: Patch ping

[Mike Stump]

On Feb 3, 2011, at 8:38 AM, Jakub Jelinek wrote:
> 2011-02-03  Jakub Jelinek  <jakub@redhat.com>
> 
> 	* config/darwin.h (SECTION_NO_ANCHOR): Remove.
> 	* config/darwin.c (SECTION_NO_ANCHOR): Define.
> 	(darwin_init_sections): Remove assertion.

Ok.

Re: Patch ping

[Jakub Jelinek]

On Thu, Feb 03, 2011 at 04:49:06PM +0000, IainS wrote:
> Yes, that seems better...
> 
> I will test this change on its own on Darwin OK?

Yeah, that should be sufficient.

	Jakub

Re: Patch ping

[IainS]

On 3 Feb 2011, at 16:38, Jakub Jelinek wrote:

> On Thu, Feb 03, 2011 at 08:27:03AM -0800, Richard Henderson wrote:
>> On 02/03/2011 08:24 AM, IainS wrote:
>>>> Well, it perhaps could be just SECTION_MACH_DEP, at least I can't  
>>>> see any
>>>> reasons why it couldn't, just the assert required that it was  
>>>> bigger:
>>>
>>> hmm,
>>> won't that  output.h to be before every instance of darwin.h?

note to self: 'please engage brain before hitting send' ;)

>> No, just so long as it's included before SECTION_NO_ANCHOR is used.
>> What's in darwin.h is merely a macro definition, not a "real" use.
>
> Well, I see no reason why SECTION_NO_ANCHOR could not be defined in
> config/darwin.c instead.  It is used just in config/darwin.c and
> config/darwin-sections.def.  While the latter is included by both
> config/darwin.c and config/darwin.h, in darwin.h only the NAME from it
> matters.

Yes, that seems better...

I will test this change on its own on Darwin OK?

(that is, if the whole patch needs checking then ping me - because  
this needs doing on PPC which takes a while)>

Iain

>
> So something like (separate patch, if you want to test it together
> with the PR31490 patch just remove the config/darwin.h hunk from the
> PR31490 patch):
>
> 2011-02-03  Jakub Jelinek  <jakub@redhat.com>
>
> 	* config/darwin.h (SECTION_NO_ANCHOR): Remove.
> 	* config/darwin.c (SECTION_NO_ANCHOR): Define.
> 	(darwin_init_sections): Remove assertion.
>
> --- gcc/config/darwin.c.jj	2011-01-15 11:26:39.411777352 +0100
> +++ gcc/config/darwin.c	2011-02-03 17:35:15.074388782 +0100
> @@ -160,6 +160,11 @@ output_objc_section_asm_op (const void *
>   output_section_asm_op (directive);
> }
>
> +
> +/* Private flag applied to disable section-anchors in a particular  
> section.  */
> +#define SECTION_NO_ANCHOR SECTION_MACH_DEP
> +
> +
> /* Implement TARGET_ASM_INIT_SECTIONS.  */
>
> void
> @@ -177,10 +182,6 @@ darwin_init_sections (void)
>   readonly_data_section = darwin_sections[const_section];
>   exception_section = darwin_sections[darwin_exception_section];
>   eh_frame_section = darwin_sections[darwin_eh_frame_section];
> -
> -  /* Make sure that there is no conflict between the 'no anchor'  
> section
> -     flag declared in darwin.h and the section flags declared in  
> output.h.  */
> -  gcc_assert (SECTION_NO_ANCHOR > SECTION_MACH_DEP);
> }
>
> int
> --- gcc/config/darwin.h.jj	2011-01-28 20:34:16.455652744 +0100
> +++ gcc/config/darwin.h	2011-02-03 17:33:25.676670013 +0100
> @@ -651,11 +651,6 @@ int darwin_label_is_anonymous_local_objc
> /* The generic version, archs should over-ride where required.  */
> #define MACHOPIC_NL_SYMBOL_PTR_SECTION ".non_lazy_symbol_pointer"
>
> -/* Private flag applied to disable section-anchors in a particular  
> section.
> -   This needs to be kept in sync with the flags used by varasm.c  
> (defined in
> -   output.h).  */
> -#define SECTION_NO_ANCHOR 0x2000000
> -
> /* Declare the section variables.  */
> #ifndef USED_FOR_TARGET
> enum darwin_section_enum {
>
>
> 	Jakub

Re: Patch ping

[Jakub Jelinek]

On Thu, Feb 03, 2011 at 08:27:03AM -0800, Richard Henderson wrote:
> On 02/03/2011 08:24 AM, IainS wrote:
> >> Well, it perhaps could be just SECTION_MACH_DEP, at least I can't see any
> >> reasons why it couldn't, just the assert required that it was bigger:
> > 
> > hmm,
> > won't that  output.h to be before every instance of darwin.h?
> 
> No, just so long as it's included before SECTION_NO_ANCHOR is used.
> What's in darwin.h is merely a macro definition, not a "real" use.

Well, I see no reason why SECTION_NO_ANCHOR could not be defined in
config/darwin.c instead.  It is used just in config/darwin.c and
config/darwin-sections.def.  While the latter is included by both
config/darwin.c and config/darwin.h, in darwin.h only the NAME from it
matters.

So something like (separate patch, if you want to test it together
with the PR31490 patch just remove the config/darwin.h hunk from the
PR31490 patch):

2011-02-03  Jakub Jelinek  <jakub@redhat.com>

	* config/darwin.h (SECTION_NO_ANCHOR): Remove.
	* config/darwin.c (SECTION_NO_ANCHOR): Define.
	(darwin_init_sections): Remove assertion.

--- gcc/config/darwin.c.jj	2011-01-15 11:26:39.411777352 +0100
+++ gcc/config/darwin.c	2011-02-03 17:35:15.074388782 +0100
@@ -160,6 +160,11 @@ output_objc_section_asm_op (const void *
   output_section_asm_op (directive);
 }
 
+
+/* Private flag applied to disable section-anchors in a particular section.  */
+#define SECTION_NO_ANCHOR SECTION_MACH_DEP
+
+
 /* Implement TARGET_ASM_INIT_SECTIONS.  */
 
 void
@@ -177,10 +182,6 @@ darwin_init_sections (void)
   readonly_data_section = darwin_sections[const_section];
   exception_section = darwin_sections[darwin_exception_section];
   eh_frame_section = darwin_sections[darwin_eh_frame_section];
-
-  /* Make sure that there is no conflict between the 'no anchor' section
-     flag declared in darwin.h and the section flags declared in output.h.  */
-  gcc_assert (SECTION_NO_ANCHOR > SECTION_MACH_DEP);
 }
 
 int
--- gcc/config/darwin.h.jj	2011-01-28 20:34:16.455652744 +0100
+++ gcc/config/darwin.h	2011-02-03 17:33:25.676670013 +0100
@@ -651,11 +651,6 @@ int darwin_label_is_anonymous_local_objc
 /* The generic version, archs should over-ride where required.  */
 #define MACHOPIC_NL_SYMBOL_PTR_SECTION ".non_lazy_symbol_pointer"
 
-/* Private flag applied to disable section-anchors in a particular section.
-   This needs to be kept in sync with the flags used by varasm.c (defined in
-   output.h).  */
-#define SECTION_NO_ANCHOR 0x2000000
-
 /* Declare the section variables.  */
 #ifndef USED_FOR_TARGET
 enum darwin_section_enum {


	Jakub

Re: Patch ping

[Richard Henderson]

On 02/03/2011 08:24 AM, IainS wrote:
>> Well, it perhaps could be just SECTION_MACH_DEP, at least I can't see any
>> reasons why it couldn't, just the assert required that it was bigger:
> 
> hmm,
> won't that  output.h to be before every instance of darwin.h?

No, just so long as it's included before SECTION_NO_ANCHOR is used.
What's in darwin.h is merely a macro definition, not a "real" use.

> .... I can if you like,

Please.


r~

Re: Patch ping

[IainS]

On 3 Feb 2011, at 16:20, Jakub Jelinek wrote:

> On Thu, Feb 03, 2011 at 08:14:23AM -0800, Richard Henderson wrote:
>> On 02/03/2011 03:58 AM, Jakub Jelinek wrote:
>>> The following patch is awaiting review for a week:
>>>
>>> - http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02059.html
>>>  P1 PR31490, section flags conflict handling
>>
>> I think the second patch, attempting to keep the warnings in  
>> declaration order,
>> is better.  I don't think there's so much extra work to warrant the  
>> inconsistency.
>
> Thanks.
>
>> One change though,
>>
>>> /* Private flag applied to disable section-anchors in a particular  
>>> section.
>>>    This needs to be kept in sync with the flags used by varasm.c  
>>> (defined in
>>>    output.h).  */
>>> -#define SECTION_NO_ANCHOR 0x2000000
>>> +#define SECTION_NO_ANCHOR 0x4000000
>>
>> That ought to have been defined as (SECTION_MACH_DEP << 1).  That  
>> does leave
>> the comment slightly out of date -- "other machine-dependent uses"  
>> perhaps?
>
> Well, it perhaps could be just SECTION_MACH_DEP, at least I can't  
> see any
> reasons why it couldn't, just the assert required that it was bigger:

hmm,
won't that  output.h to be before every instance of darwin.h?

> config/darwin.c:  gcc_assert (SECTION_NO_ANCHOR > SECTION_MACH_DEP);
> config/alpha/alpha.c:#define SECTION_PUBLIC SECTION_MACH_DEP
> config/i386/winnt.c:#define SECTION_PE_SHARED	SECTION_MACH_DEP
> config/ia64/ia64.c:#define SECTION_VMS_OVERLAY SECTION_MACH_DEP
> config/mep/mep.c:#define SECTION_MEP_VLIW	SECTION_MACH_DEP
>
> darwin doesn't support alpha/ia64/mep (I hope) and is not winnt.
> I just can't test it on Darwin.

.... I can if you like,

Iain


> 	Jakub

Re: Patch ping

[Jakub Jelinek]

On Thu, Feb 03, 2011 at 08:14:23AM -0800, Richard Henderson wrote:
> On 02/03/2011 03:58 AM, Jakub Jelinek wrote:
> > The following patch is awaiting review for a week:
> > 
> > - http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02059.html
> >   P1 PR31490, section flags conflict handling
> 
> I think the second patch, attempting to keep the warnings in declaration order,
> is better.  I don't think there's so much extra work to warrant the inconsistency.

Thanks.

> One change though,
> 
> >  /* Private flag applied to disable section-anchors in a particular section.
> >     This needs to be kept in sync with the flags used by varasm.c (defined in
> >     output.h).  */
> > -#define SECTION_NO_ANCHOR 0x2000000
> > +#define SECTION_NO_ANCHOR 0x4000000
> 
> That ought to have been defined as (SECTION_MACH_DEP << 1).  That does leave
> the comment slightly out of date -- "other machine-dependent uses" perhaps?

Well, it perhaps could be just SECTION_MACH_DEP, at least I can't see any
reasons why it couldn't, just the assert required that it was bigger:

config/darwin.c:  gcc_assert (SECTION_NO_ANCHOR > SECTION_MACH_DEP);
config/alpha/alpha.c:#define SECTION_PUBLIC SECTION_MACH_DEP
config/i386/winnt.c:#define SECTION_PE_SHARED	SECTION_MACH_DEP
config/ia64/ia64.c:#define SECTION_VMS_OVERLAY SECTION_MACH_DEP
config/mep/mep.c:#define SECTION_MEP_VLIW	SECTION_MACH_DEP

darwin doesn't support alpha/ia64/mep (I hope) and is not winnt.
I just can't test it on Darwin.

	Jakub

Re: Patch ping

[Richard Henderson]

On 02/03/2011 03:58 AM, Jakub Jelinek wrote:
> Hi!
> 
> The following patch is awaiting review for a week:
> 
> - http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02059.html
>   P1 PR31490, section flags conflict handling
> 
> 	Jakub

I think the second patch, attempting to keep the warnings in declaration order,
is better.  I don't think there's so much extra work to warrant the inconsistency.

One change though,

>  /* Private flag applied to disable section-anchors in a particular section.
>     This needs to be kept in sync with the flags used by varasm.c (defined in
>     output.h).  */
> -#define SECTION_NO_ANCHOR 0x2000000
> +#define SECTION_NO_ANCHOR 0x4000000

That ought to have been defined as (SECTION_MACH_DEP << 1).  That does leave
the comment slightly out of date -- "other machine-dependent uses" perhaps?


r~

Patch ping

[Jakub Jelinek]

Hi!

The following patch is awaiting review for a week:

- http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02059.html
  P1 PR31490, section flags conflict handling

	Jakub

Re: Patch ping

[Jeff Law]

  On 11/05/10 14:02, Jakub Jelinek wrote:
> Hi!
>
> Patches awaiting review for more than ~ a week:
>
> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02318.html
>    - Fix dead_debug_* ICE (PR debug/46171, P1)
OK.

> http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01243.html
>    - Fix up guality/sra-1.c testcase (PR middle-end/45663, P3)
OK.

> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01524.html
>    - DW_OP_GNU_entry_value + DW_TAG_GNU_call_site support
>
> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02633.html
>    - Improve debug info for params only referenced in DEBUG
>      stmts at expand time (PR debug/45882)
I'm leaving these two for someone who understands this stuff better.  If 
nobody responds in a week or so, let me know and I'll take a closer look 
at them.

Jeff

Patch ping

[Jakub Jelinek]

Hi!

Patches awaiting review for more than ~ a week:

http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02318.html
  - Fix dead_debug_* ICE (PR debug/46171, P1)

http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01243.html
  - Fix up guality/sra-1.c testcase (PR middle-end/45663, P3)

http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01524.html
  - DW_OP_GNU_entry_value + DW_TAG_GNU_call_site support

http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02633.html
  - Improve debug info for params only referenced in DEBUG
    stmts at expand time (PR debug/45882)

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

- http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00874.html
  DW_OP_GNU_implicit_pointer support

- http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01475.html
  DW_OP_GNU_entry_value/DW_TAG_GNU_call_site support

	Jakub

Re: Patch ping

[Jeff Law]

  On 07/20/10 11:01, Jakub Jelinek wrote:
> Hi!
>
> - Fix DECL_ALIGN during expand
>    PR target/44542
>    http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01803.html
OK.

> - Fix up asm-es-2.c testcase, update ppc/ia64 md.texi section
>    on inline-asm side-effects
>    testsuite/44701
>    http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01051.html
OK, after removing the extraneous "Note that on PowerPC targets," as 
suggested by Andreas.

jeff

Patch ping

[Jakub Jelinek]

Hi!

- Fix DECL_ALIGN during expand
  PR target/44542
  http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01803.html

- Fix up asm-es-2.c testcase, update ppc/ia64 md.texi section
  on inline-asm side-effects
  testsuite/44701
  http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01051.html

	Jakub

Re: Patch ping

[Jan Kratochvil]

On Mon, 21 Jun 2010 13:24:23 +0200, Jan Kratochvil wrote:
> Checked-in as r161066.  Forgot to place the PR # there so closed PR other/43480
> by hand.

Wrongly patched libjava/classpath/ChangeLog , therefore fixed it up:

------------------------------------------------------------------------
r161069 | jkratoch | 2010-06-21 13:40:02 +0200 (Mon, 21 Jun 2010) | 3 lines

Move the entry from libjava/classpath/ ChangeLog to ChangeLog.gcj as it is
a local change.  Reported by Jakub Jelinek, approved by Mark Wielaard.
------------------------------------------------------------------------
Index: libjava/classpath/ChangeLog
===================================================================
--- libjava/classpath/ChangeLog	(revision 161068)
+++ libjava/classpath/ChangeLog	(revision 161069)
@@ -1,8 +1,3 @@
-2010-06-21  Jan Kratochvil  <jan.kratochvil@redhat.com>
-
-	* doc/Makefile.am (POD2MAN): Provide --date from ChangeLog.
-	* doc/Makefile.in: Regenerate.
-
 2010-06-04  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
 
 	* scripts/check_jni_methods.sh.in: Don't use diff -U.
Index: libjava/classpath/ChangeLog.gcj
===================================================================
--- libjava/classpath/ChangeLog.gcj	(revision 161068)
+++ libjava/classpath/ChangeLog.gcj	(revision 161069)
@@ -1,3 +1,8 @@
+2010-06-21  Jan Kratochvil  <jan.kratochvil@redhat.com>
+
+	* doc/Makefile.am (POD2MAN): Provide --date from ChangeLog.
+	* doc/Makefile.in: Regenerate.
+
 2010-04-07  Jakub Jelinek  <jakub@redhat.com>
 
 	* native/jni/midi-alsa/gnu_javax_sound_midi_alsa_AlsaPortDevice.c

Re: Patch ping

[Jan Kratochvil]

On Mon, 21 Jun 2010 12:00:07 +0200, Paolo Bonzini wrote:
> On 06/21/2010 11:51 AM, Jakub Jelinek wrote:
> > I'd like to ping Jan Kratochvil's patch to fix up dates in generated
> > man pages:
> > http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01112.html
> 
> Yes, thanks!

Checked-in as r161066.  Forgot to place the PR # there so closed PR other/43480
by hand.


Thanks,
Jan

Re: Patch ping

[Paolo Bonzini]

On 06/21/2010 11:51 AM, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping Jan Kratochvil's patch to fix up dates in generated
> man pages:
> http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01112.html
>
> Ok for trunk?

Yes, thanks!

Paolo

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping Jan Kratochvil's patch to fix up dates in generated
man pages:
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01112.html

Ok for trunk?

	Jakub

Re: Patch ping

[Joseph S. Myers]

On Mon, 10 May 2010, Jakub Jelinek wrote:

> [4.6] http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01045.html
>   - improve -###

OK with "alpha numeric" changed to "alphanumeric".

-- 
Joseph S. Myers
joseph@codesourcery.com

Patch ping

[Jakub Jelinek]

Hi!

[4.6] http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00400.html
  - improve debug info with SRA optimized objects (only tree-sra
    changes reviewed so far, the 2 extra break; stmts removed 
    in my copy)

[4.6] http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01762.html
  - fix up .debug_macinfo

[4.6] http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01045.html
  - improve -###

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00082.html
  - adjustment for DWARF4 CIE header changes (new fields
    added into the middle of the header)

http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00818.html
  - 1% size decrease of .debug_loc (only merges adjacent ranges with
    the same location expression)

http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01045.html
  - improve -###

	Jakub

Re: Patch Ping

[Richard Guenther]

On Tue, Mar 2, 2010 at 7:59 PM, Jeff Law <law@redhat.com> wrote:
>
> Ping!
>
> http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01010.html

Ok.

Thanks,
Richard.

> Jeff
>

Patch Ping

[Jeff Law]

Ping!

http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01010.html

Jeff

Re: Patch ping

[Uros Bizjak]

On 02/23/2010 04:35 PM, Jakub Jelinek wrote:
> Hi!
>
> - Fix AVX vector permutation handling (PR target/43107)
>    http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00736.html
>    

> 2010-02-18  Jakub Jelinek<jakub@redhat.com>
>
> 	PR target/43107
> 	* config/i386/i386.c (avx_vpermilp_parallel): Reject indexes
> 	greater or equal to nelt instead of 2 * nelt.
> 	(expand_vec_perm_1): When op0 and op1 are equal, mask indexes
> 	with nelt - 1.
>    

Please CSE (nelt -1) into a temporary.

OK with that change.

Thanks,
Uros.

Patch ping

[Jakub Jelinek]

Hi!

- Fix AVX vector permutation handling (PR target/43107) 
  http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00736.html

	Jakub

Re: Patch ping

[Richard Guenther]

On Tue, Feb 9, 2010 at 11:43 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> Hi!
>
> http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01402.html
> - fix asm redirection of ffs on s390x (to fix glibc s390x build)

Ok.

Thanks,
Richard.

Patch ping

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01402.html
- fix asm redirection of ffs on s390x (to fix glibc s390x build)

	Jakub

Re: Patch ping

[Richard Henderson]

On 01/14/2010 01:33 AM, Jakub Jelinek wrote:
> Hi!
>
> http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00430.html
>    - 4.5: fix VTA from needlessly resetting debug stmts during inlining
>
> http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00431.html
>    - 4.5: fix var-tracking on MO_USE_NO_VAR
>
> http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00403.html
>    - 4.5/4.4: don't emit .weak for undefs that are DECL_WEAK just
>      because the undef symbols are known to use C++ vague linkage.
>      Only emit .weak for undefs if they have weak attribute, #pragma weak
>      or some target specific similar extension.
>
> All patches have been bootstrapped/regtested several times on several linux
> targets.

All ok.


r~

Patch ping

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00430.html
  - 4.5: fix VTA from needlessly resetting debug stmts during inlining

http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00431.html
  - 4.5: fix var-tracking on MO_USE_NO_VAR

http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00403.html
  - 4.5/4.4: don't emit .weak for undefs that are DECL_WEAK just
    because the undef symbols are known to use C++ vague linkage.
    Only emit .weak for undefs if they have weak attribute, #pragma weak
    or some target specific similar extension.

All patches have been bootstrapped/regtested several times on several linux
targets.

	Jakub

Re: Patch ping

[Richard Guenther]

On Mon, Jan 4, 2010 at 11:54 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> Hi!
>
> http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01011.html
> - P1 -m{arch,cpu,tune}=native regression in the driver
>     caused by -fcompare-debug changes in the driver

Ok.

Thanks,
Richard.

>        Jakub
>

Patch ping

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01011.html
- P1 -m{arch,cpu,tune}=native regression in the driver
     caused by -fcompare-debug changes in the driver

	Jakub

Re: Patch ping

[Richard Guenther]

On Mon, 2 Nov 2009, Jakub Jelinek wrote:

> Hi!
> 
> http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01627.html
> 	- Fix -fipa-struct-reorg ICE with unmaterialized clones

Ok.

Thanks,
Richard.

Patch ping

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01352.html
	- Fix ICEs with non-matched #pragma GCC visibility and namespace
	  with visibility attribute

http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01627.html
	- Fix -fipa-struct-reorg ICE with unmaterialized clones

	Jakub

Re: Patch ping

[Paolo Carlini]

> On 10/19/2009 03:16 PM, Jakub Jelinek wrote:
>> http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00837.html
>> 	- raw string support (libcpp bits reviewed by Tom Tromey already,
>> 	  C/C++ bits need approval)
>
> OK.

Great. Can you please also update wwwdocs about that?

Thanks,
Paolo.

Re: Patch ping

[Jason Merrill]

On 10/19/2009 03:16 PM, Jakub Jelinek wrote:
> http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00837.html
> 	- raw string support (libcpp bits reviewed by Tom Tromey already,
> 	  C/C++ bits need approval)

OK.

Jason

Re: Patch ping

[Joseph S. Myers]

On Mon, 19 Oct 2009, Jakub Jelinek wrote:

> http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00837.html
> 	- raw string support (libcpp bits reviewed by Tom Tromey already,
> 	  C/C++ bits need approval)

The C changes are OK.

-- 
Joseph S. Myers
joseph@codesourcery.com

Patch ping

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00864.html
	- fix DW_OP_{le,gt,ge,gt} handling in unwind-dw2.c

http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00837.html
	- raw string support (libcpp bits reviewed by Tom Tromey already,
	  C/C++ bits need approval)

	Jakub

Re: Patch ping

[Richard Henderson]

On 10/19/2009 12:16 PM, Jakub Jelinek wrote:
> Hi!
>
> http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00864.html
> 	- fix DW_OP_{le,gt,ge,gt} handling in unwind-dw2.c

Ok.


r~

Re: Patch ping

[Tom Tromey]

>>>>> "Jakub" == Jakub Jelinek <jakub@redhat.com> writes:

Tom> I didn't see anything limiting this to C++0x, but I suppose that will be
Tom> done outside libcpp.

Tom> The patch refers to `CPP_OPTION (pfile, uliterals)' but I didn't see an
Tom> addition to struct cpp_options.

Jakub> Both of the above questions are related.  It is uliterals that
Jakub> limits this to C++0x and GNUC99, and that wasn't added because it
Jakub> is already pre-existing.

Oops, I didn't think to look there :)

If you need to add a new option here, that is fine by me.  IIUC, this
part is really just about satisfying the differing needs of the C and
C++ FEs.

Tom

Re: Patch ping

[Jakub Jelinek]

On Mon, Oct 12, 2009 at 01:20:36PM -0600, Tom Tromey wrote:
> I read the patch.  Sorry about the delay -- these days my attention
> wanders a lot so pings for libcpp patches are very helpful.

Thanks.

> I didn't see anything limiting this to C++0x, but I suppose that will be
> done outside libcpp.
> 
> The patch refers to `CPP_OPTION (pfile, uliterals)' but I didn't see an
> addition to struct cpp_options.

Both of the above questions are related.  It is uliterals that limits this
to C++0x and GNUC99, and that wasn't added because it is already
pre-existing.  Before this patch it was used to limit u"", U"", u'x', U'x',
now it guards also u8"", R"[]", LR"[]", uR"[]", UR"[]" and u8R"[]" style
strings.  See init.c (lang_defaults).

> Would it be too much trouble to use calls to cpp_error_with_line for all
> new errors?  I think this is generally preferable, and in this code I
> think it would also let us emit errors against locations inside strings.
> (And, for errors about unterminated strings, it would let us point to
> the start of the string, which seems better to me.)
> 
> lex_raw_string uses _cpp_get_fresh_line, failing if that returns false.
> _cpp_get_fresh_line will always return false inside of a directive -- do
> we care about raw strings containing newlines in directives?

I'll look at these 2 tomorrow.

> +/* Lexes raw a string.  The stored string contains the spelling, including
> 
> I think the first sentence should be "Lexes a raw string".

Fixed in my copy.

> >From _cpp_lex_direct:
> 
> +    case 'R':
>        /* 'L', 'u' or 'U' may introduce wide characters or strings.  */
> 
> This comment needs an update.

Likewise.

> This isn't part of libcpp, but it seems to me that C_LEX_RAW_STRINGS is
> now confusingly named.

True, perhaps C_LEX_STRING_NO_TRANSLATE_NO_JOIN or just
C_LEX_STRING_NO_JOIN will need to be used instead.

	Jakub

Re: Patch ping

[Tom Tromey]

>>>>> "Jakub" == Jakub Jelinek <jakub@redhat.com> writes:

Jakub> Could you please in light of
Jakub> http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00179.html
Jakub> review the libcpp bits of
Jakub> http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01099.html
Jakub> ?

I read the patch.  Sorry about the delay -- these days my attention
wanders a lot so pings for libcpp patches are very helpful.

Most of the patch is clearly fine.

I didn't see anything limiting this to C++0x, but I suppose that will be
done outside libcpp.

The patch refers to `CPP_OPTION (pfile, uliterals)' but I didn't see an
addition to struct cpp_options.

Would it be too much trouble to use calls to cpp_error_with_line for all
new errors?  I think this is generally preferable, and in this code I
think it would also let us emit errors against locations inside strings.
(And, for errors about unterminated strings, it would let us point to
the start of the string, which seems better to me.)

lex_raw_string uses _cpp_get_fresh_line, failing if that returns false.
_cpp_get_fresh_line will always return false inside of a directive -- do
we care about raw strings containing newlines in directives?

Some nits..

From lex_raw_string:

+/* Lexes raw a string.  The stored string contains the spelling, including

I think the first sentence should be "Lexes a raw string".

From _cpp_lex_direct:

+    case 'R':
       /* 'L', 'u' or 'U' may introduce wide characters or strings.  */

This comment needs an update.


This isn't part of libcpp, but it seems to me that C_LEX_RAW_STRINGS is
now confusingly named.

Tom

Patch ping

[Jakub Jelinek]

Hi!

Could you please in light of
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00179.html
review the libcpp bits of
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01099.html
?

Thanks.

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping:

[4.5] Allow exceptions together with -freorder-blocks-and-partition
      http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01743.html

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

[rs6000] http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00151.html
         PR target/40017 - handle context sensitive vector bool  
                           even after #include <stdbool.h> in C99
[emutls] http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00248.html 
         PR other/40024 - fix emutls bug

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

[4.4/4.5] P2 teach fwprop to propagate into asms to avoid reload asm regressions
  http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01361.html

[4.5] Use DW_TAG_member instead of DW_TAG_variable for static data members
  http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00485.html

	Jakub

Re: Patch ping

[Ian Lance Taylor]

[ I managed to drop gcc-patches when I sent this. ]

Jakub Jelinek <jakub@redhat.com> writes:

> [c++] PR c++/36695, P2
>         http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00018.html
>         (with s/default/value/ in the error message)

This is OK.


> [c/c++] PR c/32455, P2
>         http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00644.html

I'm not really comfortable with breaking the building of old version
of glibc just to fix an ice-on-invalid.  I'll approve this for gcc
4.5, to give people more time to update their glibc.


> [c++] PR c++/38648, P2
>         http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01316.html

This is OK.


> [c] PR c/32041, P2
>         http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00369.html
>         (with s/32084/32041/g; C++ part already approved by Jason)

This is OK if no objections from the C frontend maintainers by Tuesday
(or if they approve it before then).

Thanks.

Ian

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping a couple of patches for 4.4 regressions:

[i386] PR target/38708, P1
        http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00239.html
[c++] PR c++/36695, P2
        http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00018.html
        (with s/default/value/ in the error message)
[c/c++] PR c/32455, P2
        http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00644.html
[c++] PR c++/38648, P2
        http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01316.html
[c] PR c/32041, P2
        http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00369.html
        (with s/32084/32041/g; C++ part already approved by Jason)

	Jakub

Re: Patch ping

[Richard Henderson]

Jakub Jelinek wrote:
> - http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00592.html
>   fix dwarf2out ICE on UNSPEC in DECL_RTL, PR middle-end/37275

Ok.


r~

Re: Patch ping

[Diego Novillo]

2008/9/25 Jakub Jelinek <jakub@redhat.com>:

> - http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01387.html
>  fix gcc -v --help, PR middle-end/37576

OK.


Diego.

Patch ping

[Jakub Jelinek]

Hi!

- http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00592.html
  fix dwarf2out ICE on UNSPEC in DECL_RTL, PR middle-end/37275

- http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01387.html
  fix gcc -v --help, PR middle-end/37576

	Jakub

Re: Patch ping...

[Ian Lance Taylor]

"Richard Guenther" <richard.guenther@gmail.com> writes:

> On Thu, Aug 28, 2008 at 10:32 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>> On Sat, Apr 5, 2008 at 6:26 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>> > Hi,
>>> >  I would like to ping the BRANCH_COST patch
>>> >  http://gcc.gnu.org/ml/gcc/2008-03/msg00137.html
>>> >
>>> >  I hope to proceed with updating GCC to optimize cold blocks in same way
>>> >  as -Os and explicitely marked hot functions in -Os code for speed.
>>> >  For this I need to populate RTL cost interfaces with the profile info
>>> >  and teach expansion about it.
>>> >  This is taking quite some years now, I realize it might not be clear
>>> >  what I am precisely shooting for, so I will also add wiki page.
>>>
>>> I think the patch makes sense (BRANCH_COST is special anyway compared to
>>> other isns cost), but I'd like to see the bigger picture as well here.  In
>>> particular, BRANCH_COST (hot, predictable), why isn't that simply
>>> BRANCH_COST (optimize_size_p, predictable) matching what I possibly
>>> expect for the other cost interface (insn_cost (optimize_size_p, rtx)).
>>
>> Hi,
>> with the optimize_*_for_speed_p predicates, this patch becomes cleaner
>> now.  I would also like to update other costs similar way so we can
>> avoid the current way we switch optimize_size global variable.
>>
>> Bootstrapped/regtested i686-linux, OK?
>
> It looks ok, but I think that PARAM_PREDICTABLE_BRANCH_OUTCOME
> should be a target macro and not a param.
>
> Ok with that change, but please wait 24h to let others comment.

It would be nice to see BRANCH_COST turn into a target hook rather
than a macro, Since you have to touch every definition of it anyhow.
I won't insist on it, though.

Ian

Re: Patch ping...

[Richard Guenther]

On Thu, Aug 28, 2008 at 10:32 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> On Sat, Apr 5, 2008 at 6:26 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> > Hi,
>> >  I would like to ping the BRANCH_COST patch
>> >  http://gcc.gnu.org/ml/gcc/2008-03/msg00137.html
>> >
>> >  I hope to proceed with updating GCC to optimize cold blocks in same way
>> >  as -Os and explicitely marked hot functions in -Os code for speed.
>> >  For this I need to populate RTL cost interfaces with the profile info
>> >  and teach expansion about it.
>> >  This is taking quite some years now, I realize it might not be clear
>> >  what I am precisely shooting for, so I will also add wiki page.
>>
>> I think the patch makes sense (BRANCH_COST is special anyway compared to
>> other isns cost), but I'd like to see the bigger picture as well here.  In
>> particular, BRANCH_COST (hot, predictable), why isn't that simply
>> BRANCH_COST (optimize_size_p, predictable) matching what I possibly
>> expect for the other cost interface (insn_cost (optimize_size_p, rtx)).
>
> Hi,
> with the optimize_*_for_speed_p predicates, this patch becomes cleaner
> now.  I would also like to update other costs similar way so we can
> avoid the current way we switch optimize_size global variable.
>
> Bootstrapped/regtested i686-linux, OK?

It looks ok, but I think that PARAM_PREDICTABLE_BRANCH_OUTCOME
should be a target macro and not a param.

Ok with that change, but please wait 24h to let others comment.

Thanks,
Richard.

>        * optabs.c (expand_abs_nojump): Update BRANCH_COST call.
>        * fold-cost.c (LOGICAL_OP_NON_SHORT_CIRCUIT, fold_truthop): Likewise.
>        * dojump.c (do_jump): Likewise.
>        * ifcvt.c (MAX_CONDITIONAL_EXECUTE): Likewise.
>        (note-if_info): Add BRANCH_COST.
>        (noce_try_store_flag_constants, noce_try_addcc, noce_try_store_flag_mask,
>        noce_try_cmove_arith, noce_try_cmove_arith, noce_try_cmove_arith,
>        noce_find_if_block, find_if_case_1, find_if_case_2): Use compuated
>        branch cost.
>        * expr.h (BRANCH_COST): Update default.
>        * predict.c (predictable_edge_p): New function.
>        * expmed.c (expand_smod_pow2, expand_sdiv_pow2, emit_store_flag):
>        Update BRANCH_COST call.
>        * basic-block.h (predictable_edge_p): Declare.
>        * config/alpha/alpha.h (BRANCH_COST): Update.
>        * config/frv/frv.h (BRANCH_COST): Update.
>        * config/s390/s390.h (BRANCH_COST): Update.
>        * config/spu/spu.h (BRANCH_COST): Update.
>        * config/sparc/sparc.h (BRANCH_COST): Update.
>        * config/m32r/m32r.h (BRANCH_COST): Update.
>        * config/i386/i386.h (BRANCH_COST): Update.
>        * config/i386/i386.c (ix86_expand_int_movcc): Update use of BRANCH_COST.
>        * config/sh/sh.h (BRANCH_COST): Update.
>        * config/pdp11/pdp11.h (BRANCH_COST): Update.
>        * config/avr/avr.h (BRANCH_COST): Update.
>        * config/crx/crx.h (BRANCH_COST): Update.
>        * config/xtensa/xtensa.h (BRANCH_COST): Update.
>        * config/stormy16/stormy16.h (BRANCH_COST): Update.
>        * config/m68hc11/m68hc11.h (BRANCH_COST): Update.
>        * config/iq2000/iq2000.h (BRANCH_COST): Update.
>        * config/ia64/ia64.h (BRANCH_COST): Update.
>        * config/rs6000/rs6000.h (BRANCH_COST): Update.
>        * config/arc/arc.h (BRANCH_COST): Update.
>        * config/score/score.h (BRANCH_COST): Update.
>        * config/arm/arm.h (BRANCH_COST): Update.
>        * config/pa/pa.h (BRANCH_COST): Update.
>        * config/mips/mips.h (BRANCH_COST): Update.
>        * config/vax/vax.h (BRANCH_COST): Update.
>        * config/h8300/h8300.h (BRANCH_COST): Update.
>        * params.def (PARAM_PREDICTABLE_BRANCH_OUTCOME): New.
>        * doc/invoke.texi (predictable-branch-cost-outcome): Document.
>        * doc/tm.texi (BRANCH_COST): Update.
> Index: doc/tm.texi
> ===================================================================
> *** doc/tm.texi (revision 139737)
> --- doc/tm.texi (working copy)
> *************** value to the result of that function.  T
> *** 5874,5882 ****
>  are the same as to this macro.
>  @end defmac
>
> ! @defmac BRANCH_COST
> ! A C expression for the cost of a branch instruction.  A value of 1 is
> ! the default; other values are interpreted relative to that.
>  @end defmac
>
>  Here are additional macros which do not specify precise relative costs,
> --- 5874,5887 ----
>  are the same as to this macro.
>  @end defmac
>
> ! @defmac BRANCH_COST (@var{speed_p}, @var{predictable_p})
> ! A C expression for the cost of a branch instruction.  A value of 1 is the
> ! default; other values are interpreted relative to that. Parameter @var{speed_p}
> ! is true when the branch in question should be optimized for speed.  When
> ! it is false, @code{BRANCH_COST} should be returning value optimal for code size
> ! rather then performance considerations.  @var{predictable_p} is true for well
> ! predictable branches. On many architectures the @code{BRANCH_COST} can be
> ! reduced then.
>  @end defmac
>
>  Here are additional macros which do not specify precise relative costs,
> Index: doc/invoke.texi
> ===================================================================
> *** doc/invoke.texi     (revision 139737)
> --- doc/invoke.texi     (working copy)
> *************** to the hottest structure frequency in th
> *** 6905,6910 ****
> --- 6905,6914 ----
>  parameter, then structure reorganization is not applied to this structure.
>  The default is 10.
>
> + @item predictable-branch-cost-outcome
> + When branch is predicted to be taken with probability lower than this threshold
> + (in percent), then it is considered well predictable. The default is 10.
> +
>  @item max-crossjump-edges
>  The maximum number of incoming edges to consider for crossjumping.
>  The algorithm used by @option{-fcrossjumping} is @math{O(N^2)} in
> Index: optabs.c
> ===================================================================
> *** optabs.c    (revision 139737)
> --- optabs.c    (working copy)
> *************** expand_abs_nojump (enum machine_mode mod
> *** 3443,3449 ****
>       value of X as (((signed) x >> (W-1)) ^ x) - ((signed) x >> (W-1)),
>       where W is the width of MODE.  */
>
> !   if (GET_MODE_CLASS (mode) == MODE_INT && BRANCH_COST >= 2)
>      {
>        rtx extended = expand_shift (RSHIFT_EXPR, mode, op0,
>                                   size_int (GET_MODE_BITSIZE (mode) - 1),
> --- 3443,3451 ----
>       value of X as (((signed) x >> (W-1)) ^ x) - ((signed) x >> (W-1)),
>       where W is the width of MODE.  */
>
> !   if (GET_MODE_CLASS (mode) == MODE_INT
> !       && BRANCH_COST (optimize_insn_for_speed_p (),
> !                     false) >= 2)
>      {
>        rtx extended = expand_shift (RSHIFT_EXPR, mode, op0,
>                                   size_int (GET_MODE_BITSIZE (mode) - 1),
> Index: fold-const.c
> ===================================================================
> *** fold-const.c        (revision 139737)
> --- fold-const.c        (working copy)
> *************** fold_cond_expr_with_comparison (tree typ
> *** 5109,5115 ****
>
>
>  #ifndef LOGICAL_OP_NON_SHORT_CIRCUIT
> ! #define LOGICAL_OP_NON_SHORT_CIRCUIT (BRANCH_COST >= 2)
>  #endif
>
>  /* EXP is some logical combination of boolean tests.  See if we can
> --- 5109,5117 ----
>
>
>  #ifndef LOGICAL_OP_NON_SHORT_CIRCUIT
> ! #define LOGICAL_OP_NON_SHORT_CIRCUIT \
> !   (BRANCH_COST (!cfun || optimize_function_for_speed_p (cfun), \
> !               false) >= 2)
>  #endif
>
>  /* EXP is some logical combination of boolean tests.  See if we can
> *************** fold_truthop (enum tree_code code, tree
> *** 5357,5363 ****
>       that can be merged.  Avoid doing this if the RHS is a floating-point
>       comparison since those can trap.  */
>
> !   if (BRANCH_COST >= 2
>        && ! FLOAT_TYPE_P (TREE_TYPE (rl_arg))
>        && simple_operand_p (rl_arg)
>        && simple_operand_p (rr_arg))
> --- 5359,5366 ----
>       that can be merged.  Avoid doing this if the RHS is a floating-point
>       comparison since those can trap.  */
>
> !   if (BRANCH_COST (!cfun || optimize_function_for_speed_p (cfun),
> !                  false) >= 2
>        && ! FLOAT_TYPE_P (TREE_TYPE (rl_arg))
>        && simple_operand_p (rl_arg)
>        && simple_operand_p (rr_arg))
> Index: dojump.c
> ===================================================================
> *** dojump.c    (revision 139737)
> --- dojump.c    (working copy)
> *************** do_jump (tree exp, rtx if_false_label, r
> *** 510,516 ****
>        /* High branch cost, expand as the bitwise AND of the conditions.
>         Do the same if the RHS has side effects, because we're effectively
>         turning a TRUTH_AND_EXPR into a TRUTH_ANDIF_EXPR.  */
> !       if (BRANCH_COST >= 4 || TREE_SIDE_EFFECTS (TREE_OPERAND (exp, 1)))
>        goto normal;
>
>      case TRUTH_ANDIF_EXPR:
> --- 510,518 ----
>        /* High branch cost, expand as the bitwise AND of the conditions.
>         Do the same if the RHS has side effects, because we're effectively
>         turning a TRUTH_AND_EXPR into a TRUTH_ANDIF_EXPR.  */
> !       if (BRANCH_COST (optimize_insn_for_speed_p (),
> !                      false) >= 4
> !         || TREE_SIDE_EFFECTS (TREE_OPERAND (exp, 1)))
>        goto normal;
>
>      case TRUTH_ANDIF_EXPR:
> *************** do_jump (tree exp, rtx if_false_label, r
> *** 531,537 ****
>        /* High branch cost, expand as the bitwise OR of the conditions.
>         Do the same if the RHS has side effects, because we're effectively
>         turning a TRUTH_OR_EXPR into a TRUTH_ORIF_EXPR.  */
> !       if (BRANCH_COST >= 4 || TREE_SIDE_EFFECTS (TREE_OPERAND (exp, 1)))
>        goto normal;
>
>      case TRUTH_ORIF_EXPR:
> --- 533,540 ----
>        /* High branch cost, expand as the bitwise OR of the conditions.
>         Do the same if the RHS has side effects, because we're effectively
>         turning a TRUTH_OR_EXPR into a TRUTH_ORIF_EXPR.  */
> !       if (BRANCH_COST (optimize_insn_for_speed_p (), false)>= 4
> !         || TREE_SIDE_EFFECTS (TREE_OPERAND (exp, 1)))
>        goto normal;
>
>      case TRUTH_ORIF_EXPR:
> Index: ifcvt.c
> ===================================================================
> *** ifcvt.c     (revision 139737)
> --- ifcvt.c     (working copy)
> ***************
> *** 67,73 ****
>  #endif
>
>  #ifndef MAX_CONDITIONAL_EXECUTE
> ! #define MAX_CONDITIONAL_EXECUTE   (BRANCH_COST + 1)
>  #endif
>
>  #define IFCVT_MULTIPLE_DUMPS 1
> --- 67,75 ----
>  #endif
>
>  #ifndef MAX_CONDITIONAL_EXECUTE
> ! #define MAX_CONDITIONAL_EXECUTE \
> !   (BRANCH_COST (optimize_function_for_speed_p (cfun), false) \
> !    + 1)
>  #endif
>
>  #define IFCVT_MULTIPLE_DUMPS 1
> *************** struct noce_if_info
> *** 626,631 ****
> --- 628,636 ----
>       from TEST_BB.  For the noce transformations, we allow the symmetric
>       form as well.  */
>    bool then_else_reversed;
> +
> +   /* Estimated cost of the particular branch instruction.  */
> +   int branch_cost;
>  };
>
>  static rtx noce_emit_store_flag (struct noce_if_info *, rtx, int, int);
> *************** noce_try_store_flag_constants (struct no
> *** 963,982 ****
>        normalize = 0;
>        else if (ifalse == 0 && exact_log2 (itrue) >= 0
>               && (STORE_FLAG_VALUE == 1
> !                  || BRANCH_COST >= 2))
>        normalize = 1;
>        else if (itrue == 0 && exact_log2 (ifalse) >= 0 && can_reverse
> !              && (STORE_FLAG_VALUE == 1 || BRANCH_COST >= 2))
>        normalize = 1, reversep = 1;
>        else if (itrue == -1
>               && (STORE_FLAG_VALUE == -1
> !                  || BRANCH_COST >= 2))
>        normalize = -1;
>        else if (ifalse == -1 && can_reverse
> !              && (STORE_FLAG_VALUE == -1 || BRANCH_COST >= 2))
>        normalize = -1, reversep = 1;
> !       else if ((BRANCH_COST >= 2 && STORE_FLAG_VALUE == -1)
> !              || BRANCH_COST >= 3)
>        normalize = -1;
>        else
>        return FALSE;
> --- 968,987 ----
>        normalize = 0;
>        else if (ifalse == 0 && exact_log2 (itrue) >= 0
>               && (STORE_FLAG_VALUE == 1
> !                  || if_info->branch_cost >= 2))
>        normalize = 1;
>        else if (itrue == 0 && exact_log2 (ifalse) >= 0 && can_reverse
> !              && (STORE_FLAG_VALUE == 1 || if_info->branch_cost >= 2))
>        normalize = 1, reversep = 1;
>        else if (itrue == -1
>               && (STORE_FLAG_VALUE == -1
> !                  || if_info->branch_cost >= 2))
>        normalize = -1;
>        else if (ifalse == -1 && can_reverse
> !              && (STORE_FLAG_VALUE == -1 || if_info->branch_cost >= 2))
>        normalize = -1, reversep = 1;
> !       else if ((if_info->branch_cost >= 2 && STORE_FLAG_VALUE == -1)
> !              || if_info->branch_cost >= 3)
>        normalize = -1;
>        else
>        return FALSE;
> *************** noce_try_addcc (struct noce_if_info *if_
> *** 1107,1113 ****
>
>        /* If that fails, construct conditional increment or decrement using
>         setcc.  */
> !       if (BRANCH_COST >= 2
>          && (XEXP (if_info->a, 1) == const1_rtx
>              || XEXP (if_info->a, 1) == constm1_rtx))
>          {
> --- 1112,1118 ----
>
>        /* If that fails, construct conditional increment or decrement using
>         setcc.  */
> !       if (if_info->branch_cost >= 2
>          && (XEXP (if_info->a, 1) == const1_rtx
>              || XEXP (if_info->a, 1) == constm1_rtx))
>          {
> *************** noce_try_store_flag_mask (struct noce_if
> *** 1158,1164 ****
>    int reversep;
>
>    reversep = 0;
> !   if ((BRANCH_COST >= 2
>         || STORE_FLAG_VALUE == -1)
>        && ((if_info->a == const0_rtx
>           && rtx_equal_p (if_info->b, if_info->x))
> --- 1163,1169 ----
>    int reversep;
>
>    reversep = 0;
> !   if ((if_info->branch_cost >= 2
>         || STORE_FLAG_VALUE == -1)
>        && ((if_info->a == const0_rtx
>           && rtx_equal_p (if_info->b, if_info->x))
> *************** noce_try_cmove_arith (struct noce_if_inf
> *** 1317,1323 ****
>    /* ??? FIXME: Magic number 5.  */
>    if (cse_not_expected
>        && MEM_P (a) && MEM_P (b)
> !       && BRANCH_COST >= 5)
>      {
>        a = XEXP (a, 0);
>        b = XEXP (b, 0);
> --- 1322,1328 ----
>    /* ??? FIXME: Magic number 5.  */
>    if (cse_not_expected
>        && MEM_P (a) && MEM_P (b)
> !       && if_info->branch_cost >= 5)
>      {
>        a = XEXP (a, 0);
>        b = XEXP (b, 0);
> *************** noce_try_cmove_arith (struct noce_if_inf
> *** 1347,1353 ****
>    if (insn_a)
>      {
>        insn_cost = insn_rtx_cost (PATTERN (insn_a));
> !       if (insn_cost == 0 || insn_cost > COSTS_N_INSNS (BRANCH_COST))
>        return FALSE;
>      }
>    else
> --- 1352,1358 ----
>    if (insn_a)
>      {
>        insn_cost = insn_rtx_cost (PATTERN (insn_a));
> !       if (insn_cost == 0 || insn_cost > COSTS_N_INSNS (if_info->branch_cost))
>        return FALSE;
>      }
>    else
> *************** noce_try_cmove_arith (struct noce_if_inf
> *** 1356,1362 ****
>    if (insn_b)
>      {
>        insn_cost += insn_rtx_cost (PATTERN (insn_b));
> !       if (insn_cost == 0 || insn_cost > COSTS_N_INSNS (BRANCH_COST))
>          return FALSE;
>      }
>
> --- 1361,1367 ----
>    if (insn_b)
>      {
>        insn_cost += insn_rtx_cost (PATTERN (insn_b));
> !       if (insn_cost == 0 || insn_cost > COSTS_N_INSNS (if_info->branch_cost))
>          return FALSE;
>      }
>
> *************** noce_find_if_block (basic_block test_bb,
> *** 2831,2836 ****
> --- 2836,2843 ----
>    if_info.cond_earliest = cond_earliest;
>    if_info.jump = jump;
>    if_info.then_else_reversed = then_else_reversed;
> +   if_info.branch_cost = BRANCH_COST (optimize_bb_for_speed_p (test_bb),
> +                                    predictable_edge_p (then_edge));
>
>    /* Do the real work.  */
>
> *************** find_if_case_1 (basic_block test_bb, edg
> *** 3597,3603 ****
>             test_bb->index, then_bb->index);
>
>    /* THEN is small.  */
> !   if (! cheap_bb_rtx_cost_p (then_bb, COSTS_N_INSNS (BRANCH_COST)))
>      return FALSE;
>
>    /* Registers set are dead, or are predicable.  */
> --- 3604,3612 ----
>             test_bb->index, then_bb->index);
>
>    /* THEN is small.  */
> !   if (! cheap_bb_rtx_cost_p (then_bb,
> !       COSTS_N_INSNS (BRANCH_COST (optimize_bb_for_speed_p (then_edge->src),
> !                                   predictable_edge_p (then_edge)))))
>      return FALSE;
>
>    /* Registers set are dead, or are predicable.  */
> *************** find_if_case_2 (basic_block test_bb, edg
> *** 3711,3717 ****
>             test_bb->index, else_bb->index);
>
>    /* ELSE is small.  */
> !   if (! cheap_bb_rtx_cost_p (else_bb, COSTS_N_INSNS (BRANCH_COST)))
>      return FALSE;
>
>    /* Registers set are dead, or are predicable.  */
> --- 3720,3728 ----
>             test_bb->index, else_bb->index);
>
>    /* ELSE is small.  */
> !   if (! cheap_bb_rtx_cost_p (else_bb,
> !       COSTS_N_INSNS (BRANCH_COST (optimize_bb_for_speed_p (else_edge->src),
> !                                   predictable_edge_p (else_edge)))))
>      return FALSE;
>
>    /* Registers set are dead, or are predicable.  */
> Index: expr.h
> ===================================================================
> *** expr.h      (revision 139737)
> --- expr.h      (working copy)
> *************** along with GCC; see the file COPYING3.
> *** 36,42 ****
>
>  /* The default branch cost is 1.  */
>  #ifndef BRANCH_COST
> ! #define BRANCH_COST 1
>  #endif
>
>  /* This is the 4th arg to `expand_expr'.
> --- 36,42 ----
>
>  /* The default branch cost is 1.  */
>  #ifndef BRANCH_COST
> ! #define BRANCH_COST(speed_p, predictable_p) 1
>  #endif
>
>  /* This is the 4th arg to `expand_expr'.
> Index: predict.c
> ===================================================================
> *** predict.c   (revision 139737)
> --- predict.c   (working copy)
> *************** optimize_insn_for_speed_p (void)
> *** 245,250 ****
> --- 245,267 ----
>    return !optimize_insn_for_size_p ();
>  }
>
> + /* Return true when edge E is likely to be well predictable by branch
> +    predictor.  */
> +
> + bool
> + predictable_edge_p (edge e)
> + {
> +   if (profile_status == PROFILE_ABSENT)
> +     return false;
> +   if ((e->probability
> +        <= PARAM_VALUE (PARAM_PREDICTABLE_BRANCH_OUTCOME) * REG_BR_PROB_BASE / 100)
> +       || (REG_BR_PROB_BASE - e->probability
> +           <= PARAM_VALUE (PARAM_PREDICTABLE_BRANCH_OUTCOME) * REG_BR_PROB_BASE / 100))
> +     return true;
> +   return false;
> + }
> +
> +
>  /* Set RTL expansion for BB profile.  */
>
>  void
> Index: expmed.c
> ===================================================================
> *** expmed.c    (revision 139737)
> --- expmed.c    (working copy)
> *************** expand_smod_pow2 (enum machine_mode mode
> *** 3492,3498 ****
>    result = gen_reg_rtx (mode);
>
>    /* Avoid conditional branches when they're expensive.  */
> !   if (BRANCH_COST >= 2
>        && optimize_insn_for_speed_p ())
>      {
>        rtx signmask = emit_store_flag (result, LT, op0, const0_rtx,
> --- 3492,3498 ----
>    result = gen_reg_rtx (mode);
>
>    /* Avoid conditional branches when they're expensive.  */
> !   if (BRANCH_COST (optimize_insn_for_speed_p (), false) >= 2
>        && optimize_insn_for_speed_p ())
>      {
>        rtx signmask = emit_store_flag (result, LT, op0, const0_rtx,
> *************** expand_sdiv_pow2 (enum machine_mode mode
> *** 3592,3598 ****
>    logd = floor_log2 (d);
>    shift = build_int_cst (NULL_TREE, logd);
>
> !   if (d == 2 && BRANCH_COST >= 1)
>      {
>        temp = gen_reg_rtx (mode);
>        temp = emit_store_flag (temp, LT, op0, const0_rtx, mode, 0, 1);
> --- 3592,3600 ----
>    logd = floor_log2 (d);
>    shift = build_int_cst (NULL_TREE, logd);
>
> !   if (d == 2
> !       && BRANCH_COST (optimize_insn_for_speed_p (),
> !                     false) >= 1)
>      {
>        temp = gen_reg_rtx (mode);
>        temp = emit_store_flag (temp, LT, op0, const0_rtx, mode, 0, 1);
> *************** expand_sdiv_pow2 (enum machine_mode mode
> *** 3602,3608 ****
>      }
>
>  #ifdef HAVE_conditional_move
> !   if (BRANCH_COST >= 2)
>      {
>        rtx temp2;
>
> --- 3604,3611 ----
>      }
>
>  #ifdef HAVE_conditional_move
> !   if (BRANCH_COST (optimize_insn_for_speed_p (), false)
> !       >= 2)
>      {
>        rtx temp2;
>
> *************** expand_sdiv_pow2 (enum machine_mode mode
> *** 3631,3637 ****
>      }
>  #endif
>
> !   if (BRANCH_COST >= 2)
>      {
>        int ushift = GET_MODE_BITSIZE (mode) - logd;
>
> --- 3634,3641 ----
>      }
>  #endif
>
> !   if (BRANCH_COST (optimize_insn_for_speed_p (),
> !                  false) >= 2)
>      {
>        int ushift = GET_MODE_BITSIZE (mode) - logd;
>
> *************** emit_store_flag (rtx target, enum rtx_co
> *** 5345,5351 ****
>       comparison with zero.  Don't do any of these cases if branches are
>       very cheap.  */
>
> !   if (BRANCH_COST > 0
>        && GET_MODE_CLASS (mode) == MODE_INT && (code == EQ || code == NE)
>        && op1 != const0_rtx)
>      {
> --- 5349,5356 ----
>       comparison with zero.  Don't do any of these cases if branches are
>       very cheap.  */
>
> !   if (BRANCH_COST (optimize_insn_for_speed_p (),
> !                  false) > 0
>        && GET_MODE_CLASS (mode) == MODE_INT && (code == EQ || code == NE)
>        && op1 != const0_rtx)
>      {
> *************** emit_store_flag (rtx target, enum rtx_co
> *** 5368,5377 ****
>       do LE and GT if branches are expensive since they are expensive on
>       2-operand machines.  */
>
> !   if (BRANCH_COST == 0
>        || GET_MODE_CLASS (mode) != MODE_INT || op1 != const0_rtx
>        || (code != EQ && code != NE
> !         && (BRANCH_COST <= 1 || (code != LE && code != GT))))
>      return 0;
>
>    /* See what we need to return.  We can only return a 1, -1, or the
> --- 5373,5384 ----
>       do LE and GT if branches are expensive since they are expensive on
>       2-operand machines.  */
>
> !   if (BRANCH_COST (optimize_insn_for_speed_p (),
> !                  false) == 0
>        || GET_MODE_CLASS (mode) != MODE_INT || op1 != const0_rtx
>        || (code != EQ && code != NE
> !         && (BRANCH_COST (optimize_insn_for_speed_p (),
> !                          false) <= 1 || (code != LE && code != GT))))
>      return 0;
>
>    /* See what we need to return.  We can only return a 1, -1, or the
> *************** emit_store_flag (rtx target, enum rtx_co
> *** 5467,5473 ****
>         that "or", which is an extra insn, so we only handle EQ if branches
>         are expensive.  */
>
> !       if (tem == 0 && (code == NE || BRANCH_COST > 1))
>        {
>          if (rtx_equal_p (subtarget, op0))
>            subtarget = 0;
> --- 5474,5483 ----
>         that "or", which is an extra insn, so we only handle EQ if branches
>         are expensive.  */
>
> !       if (tem == 0
> !         && (code == NE
> !             || BRANCH_COST (optimize_insn_for_speed_p (),
> !                             false) > 1))
>        {
>          if (rtx_equal_p (subtarget, op0))
>            subtarget = 0;
> Index: basic-block.h
> ===================================================================
> *** basic-block.h       (revision 139737)
> --- basic-block.h       (working copy)
> *************** extern void guess_outgoing_edge_probabil
> *** 848,853 ****
> --- 848,854 ----
>  extern void remove_predictions_associated_with_edge (edge);
>  extern bool edge_probability_reliable_p (const_edge);
>  extern bool br_prob_note_reliable_p (const_rtx);
> + extern bool predictable_edge_p (edge);
>
>  /* In cfg.c  */
>  extern void dump_regset (regset, FILE *);
> Index: config/alpha/alpha.h
> ===================================================================
> *** config/alpha/alpha.h        (revision 139737)
> --- config/alpha/alpha.h        (working copy)
> *************** extern int alpha_memory_latency;
> *** 640,646 ****
>  #define MEMORY_MOVE_COST(MODE,CLASS,IN)  (2*alpha_memory_latency)
>
>  /* Provide the cost of a branch.  Exact meaning under development.  */
> ! #define BRANCH_COST 5
>
>  /* Stack layout; function entry, exit and calling.  */
>
> --- 640,646 ----
>  #define MEMORY_MOVE_COST(MODE,CLASS,IN)  (2*alpha_memory_latency)
>
>  /* Provide the cost of a branch.  Exact meaning under development.  */
> ! #define BRANCH_COST(speed_p, predictable_p) 5
>
>  /* Stack layout; function entry, exit and calling.  */
>
> Index: config/frv/frv.h
> ===================================================================
> *** config/frv/frv.h    (revision 139737)
> --- config/frv/frv.h    (working copy)
> *************** do {                                                    \
> *** 2193,2199 ****
>
>  /* A C expression for the cost of a branch instruction.  A value of 1 is the
>     default; other values are interpreted relative to that.  */
> ! #define BRANCH_COST frv_branch_cost_int
>
>  /* Define this macro as a C expression which is nonzero if accessing less than
>     a word of memory (i.e. a `char' or a `short') is no faster than accessing a
> --- 2193,2199 ----
>
>  /* A C expression for the cost of a branch instruction.  A value of 1 is the
>     default; other values are interpreted relative to that.  */
> ! #define BRANCH_COST(speed_p, predictable_p) frv_branch_cost_int
>
>  /* Define this macro as a C expression which is nonzero if accessing less than
>     a word of memory (i.e. a `char' or a `short') is no faster than accessing a
> Index: config/s390/s390.h
> ===================================================================
> *** config/s390/s390.h  (revision 139737)
> --- config/s390/s390.h  (working copy)
> *************** extern struct rtx_def *s390_compare_op0,
> *** 828,834 ****
>
>  /* A C expression for the cost of a branch instruction.  A value of 1
>     is the default; other values are interpreted relative to that.  */
> ! #define BRANCH_COST 1
>
>  /* Nonzero if access to memory by bytes is slow and undesirable.  */
>  #define SLOW_BYTE_ACCESS 1
> --- 828,834 ----
>
>  /* A C expression for the cost of a branch instruction.  A value of 1
>     is the default; other values are interpreted relative to that.  */
> ! #define BRANCH_COST(speed_p, predictable_p) 1
>
>  /* Nonzero if access to memory by bytes is slow and undesirable.  */
>  #define SLOW_BYTE_ACCESS 1
> Index: config/spu/spu.h
> ===================================================================
> *** config/spu/spu.h    (revision 139737)
> --- config/spu/spu.h    (working copy)
> *************** targetm.resolve_overloaded_builtin = spu
> *** 434,440 ****
>
>  /* Costs */
>
> ! #define BRANCH_COST spu_branch_cost
>
>  #define SLOW_BYTE_ACCESS 0
>
> --- 434,440 ----
>
>  /* Costs */
>
> ! #define BRANCH_COST(speed_p, predictable_p) spu_branch_cost
>
>  #define SLOW_BYTE_ACCESS 0
>
> Index: config/sparc/sparc.h
> ===================================================================
> *** config/sparc/sparc.h        (revision 139737)
> --- config/sparc/sparc.h        (working copy)
> *************** do {
> *** 2196,2202 ****
>     On Niagara-2, a not-taken branch costs 1 cycle whereas a taken
>     branch costs 6 cycles.  */
>
> ! #define BRANCH_COST \
>        ((sparc_cpu == PROCESSOR_V9 \
>          || sparc_cpu == PROCESSOR_ULTRASPARC) \
>         ? 7 \
> --- 2196,2202 ----
>     On Niagara-2, a not-taken branch costs 1 cycle whereas a taken
>     branch costs 6 cycles.  */
>
> ! #define BRANCH_COST (speed_p, predictable_p) \
>        ((sparc_cpu == PROCESSOR_V9 \
>          || sparc_cpu == PROCESSOR_ULTRASPARC) \
>         ? 7 \
> Index: config/m32r/m32r.h
> ===================================================================
> *** config/m32r/m32r.h  (revision 139737)
> --- config/m32r/m32r.h  (working copy)
> *************** L2:     .word STATIC
> *** 1224,1230 ****
>  /* A value of 2 here causes GCC to avoid using branches in comparisons like
>     while (a < N && a).  Branches aren't that expensive on the M32R so
>     we define this as 1.  Defining it as 2 had a heavy hit in fp-bit.c.  */
> ! #define BRANCH_COST ((TARGET_BRANCH_COST) ? 2 : 1)
>
>  /* Nonzero if access to memory by bytes is slow and undesirable.
>     For RISC chips, it means that access to memory by bytes is no
> --- 1224,1230 ----
>  /* A value of 2 here causes GCC to avoid using branches in comparisons like
>     while (a < N && a).  Branches aren't that expensive on the M32R so
>     we define this as 1.  Defining it as 2 had a heavy hit in fp-bit.c.  */
> ! #define BRANCH_COST(speed_p, predictable_p) ((TARGET_BRANCH_COST) ? 2 : 1)
>
>  /* Nonzero if access to memory by bytes is slow and undesirable.
>     For RISC chips, it means that access to memory by bytes is no
> Index: config/i386/i386.h
> ===================================================================
> *** config/i386/i386.h  (revision 139737)
> --- config/i386/i386.h  (working copy)
> *************** do {                                                    \
> *** 1975,1981 ****
>  /* A C expression for the cost of a branch instruction.  A value of 1
>     is the default; other values are interpreted relative to that.  */
>
> ! #define BRANCH_COST ix86_branch_cost
>
>  /* Define this macro as a C expression which is nonzero if accessing
>     less than a word of memory (i.e. a `char' or a `short') is no
> --- 1975,1982 ----
>  /* A C expression for the cost of a branch instruction.  A value of 1
>     is the default; other values are interpreted relative to that.  */
>
> ! #define BRANCH_COST(speed_p, predictable_p) \
> !   (!(speed_p) ? 2 : (predictable_p) ? 0 : ix86_branch_cost)
>
>  /* Define this macro as a C expression which is nonzero if accessing
>     less than a word of memory (i.e. a `char' or a `short') is no
> Index: config/i386/i386.c
> ===================================================================
> *** config/i386/i386.c  (revision 139737)
> --- config/i386/i386.c  (working copy)
> *************** ix86_expand_int_movcc (rtx operands[])
> *** 14636,14642 ****
>         */
>
>        if ((!TARGET_CMOVE || (mode == QImode && TARGET_PARTIAL_REG_STALL))
> !         && BRANCH_COST >= 2)
>        {
>          if (cf == 0)
>            {
> --- 14636,14643 ----
>         */
>
>        if ((!TARGET_CMOVE || (mode == QImode && TARGET_PARTIAL_REG_STALL))
> !         && BRANCH_COST (optimize_insn_for_speed_p (),
> !                         false) >= 2)
>        {
>          if (cf == 0)
>            {
> *************** ix86_expand_int_movcc (rtx operands[])
> *** 14721,14727 ****
>        optab op;
>        rtx var, orig_out, out, tmp;
>
> !       if (BRANCH_COST <= 2)
>        return 0; /* FAIL */
>
>        /* If one of the two operands is an interesting constant, load a
> --- 14722,14728 ----
>        optab op;
>        rtx var, orig_out, out, tmp;
>
> !       if (BRANCH_COST (optimize_insn_for_speed_p (), false) <= 2)
>        return 0; /* FAIL */
>
>        /* If one of the two operands is an interesting constant, load a
> Index: config/sh/sh.h
> ===================================================================
> *** config/sh/sh.h      (revision 139737)
> --- config/sh/sh.h      (working copy)
> *************** struct sh_args {
> *** 2847,2853 ****
>     The SH1 does not have delay slots, hence we get a pipeline stall
>     at every branch.  The SH4 is superscalar, so the single delay slot
>     is not sufficient to keep both pipelines filled.  */
> ! #define BRANCH_COST (TARGET_SH5 ? 1 : ! TARGET_SH2 || TARGET_HARD_SH4 ? 2 : 1)
>
>  /* Assembler output control.  */
>
> --- 2847,2854 ----
>     The SH1 does not have delay slots, hence we get a pipeline stall
>     at every branch.  The SH4 is superscalar, so the single delay slot
>     is not sufficient to keep both pipelines filled.  */
> ! #define BRANCH_COST(speed_p, predictable_p) \
> !       (TARGET_SH5 ? 1 : ! TARGET_SH2 || TARGET_HARD_SH4 ? 2 : 1)
>
>  /* Assembler output control.  */
>
> Index: config/pdp11/pdp11.h
> ===================================================================
> *** config/pdp11/pdp11.h        (revision 139737)
> --- config/pdp11/pdp11.h        (working copy)
> *************** JMP     FUNCTION        0x0058  0x0000 <- FUNCTION
> *** 1057,1063 ****
>  /* there is no point in avoiding branches on a pdp,
>     since branches are really cheap - I just want to find out
>     how much difference the BRANCH_COST macro makes in code */
> ! #define BRANCH_COST (TARGET_BRANCH_CHEAP ? 0 : 1)
>
>
>  #define COMPARE_FLAG_MODE HImode
> --- 1057,1063 ----
>  /* there is no point in avoiding branches on a pdp,
>     since branches are really cheap - I just want to find out
>     how much difference the BRANCH_COST macro makes in code */
> ! #define BRANCH_COST(speed_p, predictable_p) (TARGET_BRANCH_CHEAP ? 0 : 1)
>
>
>  #define COMPARE_FLAG_MODE HImode
> Index: config/avr/avr.h
> ===================================================================
> *** config/avr/avr.h    (revision 139737)
> --- config/avr/avr.h    (working copy)
> *************** do {                                                                        \
> *** 511,517 ****
>                                         (MODE)==SImode ? 8 :   \
>                                         (MODE)==SFmode ? 8 : 16)
>
> ! #define BRANCH_COST 0
>
>  #define SLOW_BYTE_ACCESS 0
>
> --- 511,517 ----
>                                         (MODE)==SImode ? 8 :   \
>                                         (MODE)==SFmode ? 8 : 16)
>
> ! #define BRANCH_COST(speed_p, predictable_p) 0
>
>  #define SLOW_BYTE_ACCESS 0
>
> Index: config/crx/crx.h
> ===================================================================
> *** config/crx/crx.h    (revision 139737)
> --- config/crx/crx.h    (working copy)
> *************** struct cumulative_args
> *** 420,426 ****
>  /* Moving to processor register flushes pipeline - thus asymmetric */
>  #define REGISTER_MOVE_COST(MODE, FROM, TO) ((TO != GENERAL_REGS) ? 8 : 2)
>  /* Assume best case (branch predicted) */
> ! #define BRANCH_COST 2
>
>  #define SLOW_BYTE_ACCESS  1
>
> --- 420,426 ----
>  /* Moving to processor register flushes pipeline - thus asymmetric */
>  #define REGISTER_MOVE_COST(MODE, FROM, TO) ((TO != GENERAL_REGS) ? 8 : 2)
>  /* Assume best case (branch predicted) */
> ! #define BRANCH_COST(speed_p, predictable_p) 2
>
>  #define SLOW_BYTE_ACCESS  1
>
> Index: config/xtensa/xtensa.h
> ===================================================================
> *** config/xtensa/xtensa.h      (revision 139737)
> --- config/xtensa/xtensa.h      (working copy)
> *************** typedef struct xtensa_args
> *** 882,888 ****
>
>  #define MEMORY_MOVE_COST(MODE, CLASS, IN) 4
>
> ! #define BRANCH_COST 3
>
>  /* How to refer to registers in assembler output.
>     This sequence is indexed by compiler's hard-register-number (see above).  */
> --- 882,888 ----
>
>  #define MEMORY_MOVE_COST(MODE, CLASS, IN) 4
>
> ! #define BRANCH_COST(speed_p, predictable_p) 3
>
>  /* How to refer to registers in assembler output.
>     This sequence is indexed by compiler's hard-register-number (see above).  */
> Index: config/stormy16/stormy16.h
> ===================================================================
> *** config/stormy16/stormy16.h  (revision 139737)
> --- config/stormy16/stormy16.h  (working copy)
> *************** do {                                                    \
> *** 587,593 ****
>
>  #define MEMORY_MOVE_COST(M,C,I) (5 + memory_move_secondary_cost (M, C, I))
>
> ! #define BRANCH_COST 5
>
>  #define SLOW_BYTE_ACCESS 0
>
> --- 587,593 ----
>
>  #define MEMORY_MOVE_COST(M,C,I) (5 + memory_move_secondary_cost (M, C, I))
>
> ! #define BRANCH_COST(speed_p, predictable_p) 5
>
>  #define SLOW_BYTE_ACCESS 0
>
> Index: config/m68hc11/m68hc11.h
> ===================================================================
> *** config/m68hc11/m68hc11.h    (revision 139737)
> --- config/m68hc11/m68hc11.h    (working copy)
> *************** extern unsigned char m68hc11_reg_valid_f
> *** 1266,1272 ****
>
>     Pretend branches are cheap because GCC generates sub-optimal code
>     for the default value.  */
> ! #define BRANCH_COST 0
>
>  /* Nonzero if access to memory by bytes is slow and undesirable.  */
>  #define SLOW_BYTE_ACCESS      0
> --- 1266,1272 ----
>
>     Pretend branches are cheap because GCC generates sub-optimal code
>     for the default value.  */
> ! #define BRANCH_COST(speed_p, predictable_p) 0
>
>  /* Nonzero if access to memory by bytes is slow and undesirable.  */
>  #define SLOW_BYTE_ACCESS      0
> Index: config/iq2000/iq2000.h
> ===================================================================
> *** config/iq2000/iq2000.h      (revision 139737)
> --- config/iq2000/iq2000.h      (working copy)
> *************** typedef struct iq2000_args
> *** 624,630 ****
>  #define MEMORY_MOVE_COST(MODE,CLASS,TO_P)     \
>    (TO_P ? 2 : 16)
>
> ! #define BRANCH_COST 2
>
>  #define SLOW_BYTE_ACCESS 1
>
> --- 624,630 ----
>  #define MEMORY_MOVE_COST(MODE,CLASS,TO_P)     \
>    (TO_P ? 2 : 16)
>
> ! #define BRANCH_COST(speed_p, predictable_p) 2
>
>  #define SLOW_BYTE_ACCESS 1
>
> Index: config/ia64/ia64.h
> ===================================================================
> *** config/ia64/ia64.h  (revision 139737)
> --- config/ia64/ia64.h  (working copy)
> *************** do {                                                                    \
> *** 1384,1390 ****
>     many additional insn groups we run into, vs how good the dynamic
>     branch predictor is.  */
>
> ! #define BRANCH_COST 6
>
>  /* Define this macro as a C expression which is nonzero if accessing less than
>     a word of memory (i.e. a `char' or a `short') is no faster than accessing a
> --- 1384,1390 ----
>     many additional insn groups we run into, vs how good the dynamic
>     branch predictor is.  */
>
> ! #define BRANCH_COST(speed_p, predictable_p) 6
>
>  /* Define this macro as a C expression which is nonzero if accessing less than
>     a word of memory (i.e. a `char' or a `short') is no faster than accessing a
> Index: config/rs6000/rs6000.h
> ===================================================================
> *** config/rs6000/rs6000.h      (revision 139737)
> --- config/rs6000/rs6000.h      (working copy)
> *************** extern enum rs6000_nop_insertion rs6000_
> *** 967,973 ****
>     Set this to 3 on the RS/6000 since that is roughly the average cost of an
>     unscheduled conditional branch.  */
>
> ! #define BRANCH_COST 3
>
>  /* Override BRANCH_COST heuristic which empirically produces worse
>     performance for removing short circuiting from the logical ops.  */
> --- 967,973 ----
>     Set this to 3 on the RS/6000 since that is roughly the average cost of an
>     unscheduled conditional branch.  */
>
> ! #define BRANCH_COST(speed_p, predictable_p) 3
>
>  /* Override BRANCH_COST heuristic which empirically produces worse
>     performance for removing short circuiting from the logical ops.  */
> Index: config/arc/arc.h
> ===================================================================
> *** config/arc/arc.h    (revision 139737)
> --- config/arc/arc.h    (working copy)
> *************** arc_select_cc_mode (OP, X, Y)
> *** 824,830 ****
>  /* The cost of a branch insn.  */
>  /* ??? What's the right value here?  Branches are certainly more
>     expensive than reg->reg moves.  */
> ! #define BRANCH_COST 2
>
>  /* Nonzero if access to memory by bytes is slow and undesirable.
>     For RISC chips, it means that access to memory by bytes is no
> --- 824,830 ----
>  /* The cost of a branch insn.  */
>  /* ??? What's the right value here?  Branches are certainly more
>     expensive than reg->reg moves.  */
> ! #define BRANCH_COST(speed_p, predictable_p) 2
>
>  /* Nonzero if access to memory by bytes is slow and undesirable.
>     For RISC chips, it means that access to memory by bytes is no
> Index: config/score/score.h
> ===================================================================
> *** config/score/score.h        (revision 139737)
> --- config/score/score.h        (working copy)
> *************** typedef struct score_args
> *** 793,799 ****
>    (4 + memory_move_secondary_cost ((MODE), (CLASS), (TO_P)))
>
>  /* Try to generate sequences that don't involve branches.  */
> ! #define BRANCH_COST                     2
>
>  /* Nonzero if access to memory by bytes is slow and undesirable.  */
>  #define SLOW_BYTE_ACCESS                1
> --- 793,799 ----
>    (4 + memory_move_secondary_cost ((MODE), (CLASS), (TO_P)))
>
>  /* Try to generate sequences that don't involve branches.  */
> ! #define BRANCH_COST(speed_p, predictable_p) 2
>
>  /* Nonzero if access to memory by bytes is slow and undesirable.  */
>  #define SLOW_BYTE_ACCESS                1
> Index: config/arm/arm.h
> ===================================================================
> *** config/arm/arm.h    (revision 139737)
> --- config/arm/arm.h    (working copy)
> *************** do {                                                    \
> *** 2297,2303 ****
>
>  /* Try to generate sequences that don't involve branches, we can then use
>     conditional instructions */
> ! #define BRANCH_COST \
>    (TARGET_32BIT ? 4 : (optimize > 0 ? 2 : 0))
>
>  /* Position Independent Code.  */
> --- 2297,2303 ----
>
>  /* Try to generate sequences that don't involve branches, we can then use
>     conditional instructions */
> ! #define BRANCH_COST(speed_p, predictable_p) \
>    (TARGET_32BIT ? 4 : (optimize > 0 ? 2 : 0))
>
>  /* Position Independent Code.  */
> Index: config/pa/pa.h
> ===================================================================
> *** config/pa/pa.h      (revision 139737)
> --- config/pa/pa.h      (working copy)
> *************** do {                                                                    \
> *** 1570,1576 ****
>    : 2)
>
>  /* Adjust the cost of branches.  */
> ! #define BRANCH_COST (pa_cpu == PROCESSOR_8000 ? 2 : 1)
>
>  /* Handling the special cases is going to get too complicated for a macro,
>     just call `pa_adjust_insn_length' to do the real work.  */
> --- 1570,1576 ----
>    : 2)
>
>  /* Adjust the cost of branches.  */
> ! #define BRANCH_COST(speed_p, predictable_p) (pa_cpu == PROCESSOR_8000 ? 2 : 1)
>
>  /* Handling the special cases is going to get too complicated for a macro,
>     just call `pa_adjust_insn_length' to do the real work.  */
> Index: config/mips/mips.h
> ===================================================================
> *** config/mips/mips.h  (revision 139737)
> --- config/mips/mips.h  (working copy)
> *************** typedef struct mips_args {
> *** 2551,2557 ****
>  /* A C expression for the cost of a branch instruction.  A value of
>     1 is the default; other values are interpreted relative to that.  */
>
> ! #define BRANCH_COST mips_branch_cost
>  #define LOGICAL_OP_NON_SHORT_CIRCUIT 0
>
>  /* If defined, modifies the length assigned to instruction INSN as a
> --- 2551,2557 ----
>  /* A C expression for the cost of a branch instruction.  A value of
>     1 is the default; other values are interpreted relative to that.  */
>
> ! #define BRANCH_COST(speed_p, predictable_p) mips_branch_cost
>  #define LOGICAL_OP_NON_SHORT_CIRCUIT 0
>
>  /* If defined, modifies the length assigned to instruction INSN as a
> Index: config/vax/vax.h
> ===================================================================
> *** config/vax/vax.h    (revision 139737)
> --- config/vax/vax.h    (working copy)
> *************** enum reg_class { NO_REGS, ALL_REGS, LIM_
> *** 648,654 ****
>     Branches are extremely cheap on the VAX while the shift insns often
>     used to replace branches can be expensive.  */
>
> ! #define BRANCH_COST 0
>
>  /* Tell final.c how to eliminate redundant test instructions.  */
>
> --- 648,654 ----
>     Branches are extremely cheap on the VAX while the shift insns often
>     used to replace branches can be expensive.  */
>
> ! #define BRANCH_COST(speed_p, predictable_p) 0
>
>  /* Tell final.c how to eliminate redundant test instructions.  */
>
> Index: config/h8300/h8300.h
> ===================================================================
> *** config/h8300/h8300.h        (revision 139737)
> --- config/h8300/h8300.h        (working copy)
> *************** struct cum_arg
> *** 1004,1010 ****
>  #define DELAY_SLOT_LENGTH(JUMP) \
>    (NEXT_INSN (PREV_INSN (JUMP)) == JUMP ? 0 : 2)
>
> ! #define BRANCH_COST 0
>
>  /* Tell final.c how to eliminate redundant test instructions.  */
>
> --- 1004,1010 ----
>  #define DELAY_SLOT_LENGTH(JUMP) \
>    (NEXT_INSN (PREV_INSN (JUMP)) == JUMP ? 0 : 2)
>
> ! #define BRANCH_COST(speed_p, predictable_p) 0
>
>  /* Tell final.c how to eliminate redundant test instructions.  */
>
> Index: params.def
> ===================================================================
> *** params.def  (revision 139737)
> --- params.def  (working copy)
> *************** DEFPARAM (PARAM_STRUCT_REORG_COLD_STRUCT
> *** 78,83 ****
> --- 78,90 ----
>          "The threshold ratio between current and hottest structure counts",
>          10, 0, 100)
>
> + /* When branch is predicted to be taken with probability lower than this
> +    threshold (in percent), then it is considered well predictable. */
> + DEFPARAM (PARAM_PREDICTABLE_BRANCH_OUTCOME,
> +         "predictable-branch-outcome",
> +         "Maximal esitmated outcome of branch considered predictable",
> +         2, 0, 50)
> +
>  /* The single function inlining limit. This is the maximum size
>     of a function counted in internal gcc instructions (not in
>     real machine instructions) that is eligible for inlining
>

Re: Patch ping...

[Jan Hubicka]

> On Sat, Apr 5, 2008 at 6:26 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
> > Hi,
> >  I would like to ping the BRANCH_COST patch
> >  http://gcc.gnu.org/ml/gcc/2008-03/msg00137.html
> >
> >  I hope to proceed with updating GCC to optimize cold blocks in same way
> >  as -Os and explicitely marked hot functions in -Os code for speed.
> >  For this I need to populate RTL cost interfaces with the profile info
> >  and teach expansion about it.
> >  This is taking quite some years now, I realize it might not be clear
> >  what I am precisely shooting for, so I will also add wiki page.
> 
> I think the patch makes sense (BRANCH_COST is special anyway compared to
> other isns cost), but I'd like to see the bigger picture as well here.  In
> particular, BRANCH_COST (hot, predictable), why isn't that simply
> BRANCH_COST (optimize_size_p, predictable) matching what I possibly
> expect for the other cost interface (insn_cost (optimize_size_p, rtx)).

Hi,
with the optimize_*_for_speed_p predicates, this patch becomes cleaner
now.  I would also like to update other costs similar way so we can
avoid the current way we switch optimize_size global variable.

Bootstrapped/regtested i686-linux, OK?

	* optabs.c (expand_abs_nojump): Update BRANCH_COST call.
	* fold-cost.c (LOGICAL_OP_NON_SHORT_CIRCUIT, fold_truthop): Likewise.
	* dojump.c (do_jump): Likewise.
	* ifcvt.c (MAX_CONDITIONAL_EXECUTE): Likewise.
	(note-if_info): Add BRANCH_COST.
	(noce_try_store_flag_constants, noce_try_addcc, noce_try_store_flag_mask,
	noce_try_cmove_arith, noce_try_cmove_arith, noce_try_cmove_arith,
	noce_find_if_block, find_if_case_1, find_if_case_2): Use compuated
	branch cost.
	* expr.h (BRANCH_COST): Update default.
	* predict.c (predictable_edge_p): New function.
	* expmed.c (expand_smod_pow2, expand_sdiv_pow2, emit_store_flag):
	Update BRANCH_COST call.
	* basic-block.h (predictable_edge_p): Declare.
	* config/alpha/alpha.h (BRANCH_COST): Update.
	* config/frv/frv.h (BRANCH_COST): Update.
	* config/s390/s390.h (BRANCH_COST): Update.
	* config/spu/spu.h (BRANCH_COST): Update.
	* config/sparc/sparc.h (BRANCH_COST): Update.
	* config/m32r/m32r.h (BRANCH_COST): Update.
	* config/i386/i386.h (BRANCH_COST): Update.
	* config/i386/i386.c (ix86_expand_int_movcc): Update use of BRANCH_COST.
	* config/sh/sh.h (BRANCH_COST): Update.
	* config/pdp11/pdp11.h (BRANCH_COST): Update.
	* config/avr/avr.h (BRANCH_COST): Update.
	* config/crx/crx.h (BRANCH_COST): Update.
	* config/xtensa/xtensa.h (BRANCH_COST): Update.
	* config/stormy16/stormy16.h (BRANCH_COST): Update.
	* config/m68hc11/m68hc11.h (BRANCH_COST): Update.
	* config/iq2000/iq2000.h (BRANCH_COST): Update.
	* config/ia64/ia64.h (BRANCH_COST): Update.
	* config/rs6000/rs6000.h (BRANCH_COST): Update.
	* config/arc/arc.h (BRANCH_COST): Update.
	* config/score/score.h (BRANCH_COST): Update.
	* config/arm/arm.h (BRANCH_COST): Update.
	* config/pa/pa.h (BRANCH_COST): Update.
	* config/mips/mips.h (BRANCH_COST): Update.
	* config/vax/vax.h (BRANCH_COST): Update.
	* config/h8300/h8300.h (BRANCH_COST): Update.
	* params.def (PARAM_PREDICTABLE_BRANCH_OUTCOME): New.
	* doc/invoke.texi (predictable-branch-cost-outcome): Document.
	* doc/tm.texi (BRANCH_COST): Update.
Index: doc/tm.texi
===================================================================
*** doc/tm.texi	(revision 139737)
--- doc/tm.texi	(working copy)
*************** value to the result of that function.  T
*** 5874,5882 ****
  are the same as to this macro.
  @end defmac
  
! @defmac BRANCH_COST
! A C expression for the cost of a branch instruction.  A value of 1 is
! the default; other values are interpreted relative to that.
  @end defmac
  
  Here are additional macros which do not specify precise relative costs,
--- 5874,5887 ----
  are the same as to this macro.
  @end defmac
  
! @defmac BRANCH_COST (@var{speed_p}, @var{predictable_p})
! A C expression for the cost of a branch instruction.  A value of 1 is the
! default; other values are interpreted relative to that. Parameter @var{speed_p}
! is true when the branch in question should be optimized for speed.  When
! it is false, @code{BRANCH_COST} should be returning value optimal for code size
! rather then performance considerations.  @var{predictable_p} is true for well
! predictable branches. On many architectures the @code{BRANCH_COST} can be
! reduced then.
  @end defmac
  
  Here are additional macros which do not specify precise relative costs,
Index: doc/invoke.texi
===================================================================
*** doc/invoke.texi	(revision 139737)
--- doc/invoke.texi	(working copy)
*************** to the hottest structure frequency in th
*** 6905,6910 ****
--- 6905,6914 ----
  parameter, then structure reorganization is not applied to this structure.
  The default is 10.
  
+ @item predictable-branch-cost-outcome
+ When branch is predicted to be taken with probability lower than this threshold
+ (in percent), then it is considered well predictable. The default is 10.
+ 
  @item max-crossjump-edges
  The maximum number of incoming edges to consider for crossjumping.
  The algorithm used by @option{-fcrossjumping} is @math{O(N^2)} in
Index: optabs.c
===================================================================
*** optabs.c	(revision 139737)
--- optabs.c	(working copy)
*************** expand_abs_nojump (enum machine_mode mod
*** 3443,3449 ****
       value of X as (((signed) x >> (W-1)) ^ x) - ((signed) x >> (W-1)),
       where W is the width of MODE.  */
  
!   if (GET_MODE_CLASS (mode) == MODE_INT && BRANCH_COST >= 2)
      {
        rtx extended = expand_shift (RSHIFT_EXPR, mode, op0,
  				   size_int (GET_MODE_BITSIZE (mode) - 1),
--- 3443,3451 ----
       value of X as (((signed) x >> (W-1)) ^ x) - ((signed) x >> (W-1)),
       where W is the width of MODE.  */
  
!   if (GET_MODE_CLASS (mode) == MODE_INT
!       && BRANCH_COST (optimize_insn_for_speed_p (),
! 	      	      false) >= 2)
      {
        rtx extended = expand_shift (RSHIFT_EXPR, mode, op0,
  				   size_int (GET_MODE_BITSIZE (mode) - 1),
Index: fold-const.c
===================================================================
*** fold-const.c	(revision 139737)
--- fold-const.c	(working copy)
*************** fold_cond_expr_with_comparison (tree typ
*** 5109,5115 ****
  
  \f
  #ifndef LOGICAL_OP_NON_SHORT_CIRCUIT
! #define LOGICAL_OP_NON_SHORT_CIRCUIT (BRANCH_COST >= 2)
  #endif
  
  /* EXP is some logical combination of boolean tests.  See if we can
--- 5109,5117 ----
  
  \f
  #ifndef LOGICAL_OP_NON_SHORT_CIRCUIT
! #define LOGICAL_OP_NON_SHORT_CIRCUIT \
!   (BRANCH_COST (!cfun || optimize_function_for_speed_p (cfun), \
! 		false) >= 2)
  #endif
  
  /* EXP is some logical combination of boolean tests.  See if we can
*************** fold_truthop (enum tree_code code, tree 
*** 5357,5363 ****
       that can be merged.  Avoid doing this if the RHS is a floating-point
       comparison since those can trap.  */
  
!   if (BRANCH_COST >= 2
        && ! FLOAT_TYPE_P (TREE_TYPE (rl_arg))
        && simple_operand_p (rl_arg)
        && simple_operand_p (rr_arg))
--- 5359,5366 ----
       that can be merged.  Avoid doing this if the RHS is a floating-point
       comparison since those can trap.  */
  
!   if (BRANCH_COST (!cfun || optimize_function_for_speed_p (cfun),
! 		   false) >= 2
        && ! FLOAT_TYPE_P (TREE_TYPE (rl_arg))
        && simple_operand_p (rl_arg)
        && simple_operand_p (rr_arg))
Index: dojump.c
===================================================================
*** dojump.c	(revision 139737)
--- dojump.c	(working copy)
*************** do_jump (tree exp, rtx if_false_label, r
*** 510,516 ****
        /* High branch cost, expand as the bitwise AND of the conditions.
  	 Do the same if the RHS has side effects, because we're effectively
  	 turning a TRUTH_AND_EXPR into a TRUTH_ANDIF_EXPR.  */
!       if (BRANCH_COST >= 4 || TREE_SIDE_EFFECTS (TREE_OPERAND (exp, 1)))
  	goto normal;
  
      case TRUTH_ANDIF_EXPR:
--- 510,518 ----
        /* High branch cost, expand as the bitwise AND of the conditions.
  	 Do the same if the RHS has side effects, because we're effectively
  	 turning a TRUTH_AND_EXPR into a TRUTH_ANDIF_EXPR.  */
!       if (BRANCH_COST (optimize_insn_for_speed_p (),
! 		       false) >= 4
! 	  || TREE_SIDE_EFFECTS (TREE_OPERAND (exp, 1)))
  	goto normal;
  
      case TRUTH_ANDIF_EXPR:
*************** do_jump (tree exp, rtx if_false_label, r
*** 531,537 ****
        /* High branch cost, expand as the bitwise OR of the conditions.
  	 Do the same if the RHS has side effects, because we're effectively
  	 turning a TRUTH_OR_EXPR into a TRUTH_ORIF_EXPR.  */
!       if (BRANCH_COST >= 4 || TREE_SIDE_EFFECTS (TREE_OPERAND (exp, 1)))
  	goto normal;
  
      case TRUTH_ORIF_EXPR:
--- 533,540 ----
        /* High branch cost, expand as the bitwise OR of the conditions.
  	 Do the same if the RHS has side effects, because we're effectively
  	 turning a TRUTH_OR_EXPR into a TRUTH_ORIF_EXPR.  */
!       if (BRANCH_COST (optimize_insn_for_speed_p (), false)>= 4
! 	  || TREE_SIDE_EFFECTS (TREE_OPERAND (exp, 1)))
  	goto normal;
  
      case TRUTH_ORIF_EXPR:
Index: ifcvt.c
===================================================================
*** ifcvt.c	(revision 139737)
--- ifcvt.c	(working copy)
***************
*** 67,73 ****
  #endif
  
  #ifndef MAX_CONDITIONAL_EXECUTE
! #define MAX_CONDITIONAL_EXECUTE   (BRANCH_COST + 1)
  #endif
  
  #define IFCVT_MULTIPLE_DUMPS 1
--- 67,75 ----
  #endif
  
  #ifndef MAX_CONDITIONAL_EXECUTE
! #define MAX_CONDITIONAL_EXECUTE \
!   (BRANCH_COST (optimize_function_for_speed_p (cfun), false) \
!    + 1)
  #endif
  
  #define IFCVT_MULTIPLE_DUMPS 1
*************** struct noce_if_info
*** 626,631 ****
--- 628,636 ----
       from TEST_BB.  For the noce transformations, we allow the symmetric
       form as well.  */
    bool then_else_reversed;
+ 
+   /* Estimated cost of the particular branch instruction.  */
+   int branch_cost;
  };
  
  static rtx noce_emit_store_flag (struct noce_if_info *, rtx, int, int);
*************** noce_try_store_flag_constants (struct no
*** 963,982 ****
  	normalize = 0;
        else if (ifalse == 0 && exact_log2 (itrue) >= 0
  	       && (STORE_FLAG_VALUE == 1
! 		   || BRANCH_COST >= 2))
  	normalize = 1;
        else if (itrue == 0 && exact_log2 (ifalse) >= 0 && can_reverse
! 	       && (STORE_FLAG_VALUE == 1 || BRANCH_COST >= 2))
  	normalize = 1, reversep = 1;
        else if (itrue == -1
  	       && (STORE_FLAG_VALUE == -1
! 		   || BRANCH_COST >= 2))
  	normalize = -1;
        else if (ifalse == -1 && can_reverse
! 	       && (STORE_FLAG_VALUE == -1 || BRANCH_COST >= 2))
  	normalize = -1, reversep = 1;
!       else if ((BRANCH_COST >= 2 && STORE_FLAG_VALUE == -1)
! 	       || BRANCH_COST >= 3)
  	normalize = -1;
        else
  	return FALSE;
--- 968,987 ----
  	normalize = 0;
        else if (ifalse == 0 && exact_log2 (itrue) >= 0
  	       && (STORE_FLAG_VALUE == 1
! 		   || if_info->branch_cost >= 2))
  	normalize = 1;
        else if (itrue == 0 && exact_log2 (ifalse) >= 0 && can_reverse
! 	       && (STORE_FLAG_VALUE == 1 || if_info->branch_cost >= 2))
  	normalize = 1, reversep = 1;
        else if (itrue == -1
  	       && (STORE_FLAG_VALUE == -1
! 		   || if_info->branch_cost >= 2))
  	normalize = -1;
        else if (ifalse == -1 && can_reverse
! 	       && (STORE_FLAG_VALUE == -1 || if_info->branch_cost >= 2))
  	normalize = -1, reversep = 1;
!       else if ((if_info->branch_cost >= 2 && STORE_FLAG_VALUE == -1)
! 	       || if_info->branch_cost >= 3)
  	normalize = -1;
        else
  	return FALSE;
*************** noce_try_addcc (struct noce_if_info *if_
*** 1107,1113 ****
  
        /* If that fails, construct conditional increment or decrement using
  	 setcc.  */
!       if (BRANCH_COST >= 2
  	  && (XEXP (if_info->a, 1) == const1_rtx
  	      || XEXP (if_info->a, 1) == constm1_rtx))
          {
--- 1112,1118 ----
  
        /* If that fails, construct conditional increment or decrement using
  	 setcc.  */
!       if (if_info->branch_cost >= 2
  	  && (XEXP (if_info->a, 1) == const1_rtx
  	      || XEXP (if_info->a, 1) == constm1_rtx))
          {
*************** noce_try_store_flag_mask (struct noce_if
*** 1158,1164 ****
    int reversep;
  
    reversep = 0;
!   if ((BRANCH_COST >= 2
         || STORE_FLAG_VALUE == -1)
        && ((if_info->a == const0_rtx
  	   && rtx_equal_p (if_info->b, if_info->x))
--- 1163,1169 ----
    int reversep;
  
    reversep = 0;
!   if ((if_info->branch_cost >= 2
         || STORE_FLAG_VALUE == -1)
        && ((if_info->a == const0_rtx
  	   && rtx_equal_p (if_info->b, if_info->x))
*************** noce_try_cmove_arith (struct noce_if_inf
*** 1317,1323 ****
    /* ??? FIXME: Magic number 5.  */
    if (cse_not_expected
        && MEM_P (a) && MEM_P (b)
!       && BRANCH_COST >= 5)
      {
        a = XEXP (a, 0);
        b = XEXP (b, 0);
--- 1322,1328 ----
    /* ??? FIXME: Magic number 5.  */
    if (cse_not_expected
        && MEM_P (a) && MEM_P (b)
!       && if_info->branch_cost >= 5)
      {
        a = XEXP (a, 0);
        b = XEXP (b, 0);
*************** noce_try_cmove_arith (struct noce_if_inf
*** 1347,1353 ****
    if (insn_a)
      {
        insn_cost = insn_rtx_cost (PATTERN (insn_a));
!       if (insn_cost == 0 || insn_cost > COSTS_N_INSNS (BRANCH_COST))
  	return FALSE;
      }
    else
--- 1352,1358 ----
    if (insn_a)
      {
        insn_cost = insn_rtx_cost (PATTERN (insn_a));
!       if (insn_cost == 0 || insn_cost > COSTS_N_INSNS (if_info->branch_cost))
  	return FALSE;
      }
    else
*************** noce_try_cmove_arith (struct noce_if_inf
*** 1356,1362 ****
    if (insn_b)
      {
        insn_cost += insn_rtx_cost (PATTERN (insn_b));
!       if (insn_cost == 0 || insn_cost > COSTS_N_INSNS (BRANCH_COST))
          return FALSE;
      }
  
--- 1361,1367 ----
    if (insn_b)
      {
        insn_cost += insn_rtx_cost (PATTERN (insn_b));
!       if (insn_cost == 0 || insn_cost > COSTS_N_INSNS (if_info->branch_cost))
          return FALSE;
      }
  
*************** noce_find_if_block (basic_block test_bb,
*** 2831,2836 ****
--- 2836,2843 ----
    if_info.cond_earliest = cond_earliest;
    if_info.jump = jump;
    if_info.then_else_reversed = then_else_reversed;
+   if_info.branch_cost = BRANCH_COST (optimize_bb_for_speed_p (test_bb),
+ 				     predictable_edge_p (then_edge));
  
    /* Do the real work.  */
  
*************** find_if_case_1 (basic_block test_bb, edg
*** 3597,3603 ****
  	     test_bb->index, then_bb->index);
  
    /* THEN is small.  */
!   if (! cheap_bb_rtx_cost_p (then_bb, COSTS_N_INSNS (BRANCH_COST)))
      return FALSE;
  
    /* Registers set are dead, or are predicable.  */
--- 3604,3612 ----
  	     test_bb->index, then_bb->index);
  
    /* THEN is small.  */
!   if (! cheap_bb_rtx_cost_p (then_bb,
! 	COSTS_N_INSNS (BRANCH_COST (optimize_bb_for_speed_p (then_edge->src),
! 				    predictable_edge_p (then_edge)))))
      return FALSE;
  
    /* Registers set are dead, or are predicable.  */
*************** find_if_case_2 (basic_block test_bb, edg
*** 3711,3717 ****
  	     test_bb->index, else_bb->index);
  
    /* ELSE is small.  */
!   if (! cheap_bb_rtx_cost_p (else_bb, COSTS_N_INSNS (BRANCH_COST)))
      return FALSE;
  
    /* Registers set are dead, or are predicable.  */
--- 3720,3728 ----
  	     test_bb->index, else_bb->index);
  
    /* ELSE is small.  */
!   if (! cheap_bb_rtx_cost_p (else_bb, 
! 	COSTS_N_INSNS (BRANCH_COST (optimize_bb_for_speed_p (else_edge->src),
! 				    predictable_edge_p (else_edge)))))
      return FALSE;
  
    /* Registers set are dead, or are predicable.  */
Index: expr.h
===================================================================
*** expr.h	(revision 139737)
--- expr.h	(working copy)
*************** along with GCC; see the file COPYING3.  
*** 36,42 ****
  
  /* The default branch cost is 1.  */
  #ifndef BRANCH_COST
! #define BRANCH_COST 1
  #endif
  
  /* This is the 4th arg to `expand_expr'.
--- 36,42 ----
  
  /* The default branch cost is 1.  */
  #ifndef BRANCH_COST
! #define BRANCH_COST(speed_p, predictable_p) 1
  #endif
  
  /* This is the 4th arg to `expand_expr'.
Index: predict.c
===================================================================
*** predict.c	(revision 139737)
--- predict.c	(working copy)
*************** optimize_insn_for_speed_p (void)
*** 245,250 ****
--- 245,267 ----
    return !optimize_insn_for_size_p ();
  }
  
+ /* Return true when edge E is likely to be well predictable by branch
+    predictor.  */
+ 
+ bool
+ predictable_edge_p (edge e)
+ {
+   if (profile_status == PROFILE_ABSENT)
+     return false;
+   if ((e->probability
+        <= PARAM_VALUE (PARAM_PREDICTABLE_BRANCH_OUTCOME) * REG_BR_PROB_BASE / 100)
+       || (REG_BR_PROB_BASE - e->probability
+           <= PARAM_VALUE (PARAM_PREDICTABLE_BRANCH_OUTCOME) * REG_BR_PROB_BASE / 100))
+     return true;
+   return false;
+ }
+ 
+ 
  /* Set RTL expansion for BB profile.  */
  
  void
Index: expmed.c
===================================================================
*** expmed.c	(revision 139737)
--- expmed.c	(working copy)
*************** expand_smod_pow2 (enum machine_mode mode
*** 3492,3498 ****
    result = gen_reg_rtx (mode);
  
    /* Avoid conditional branches when they're expensive.  */
!   if (BRANCH_COST >= 2
        && optimize_insn_for_speed_p ())
      {
        rtx signmask = emit_store_flag (result, LT, op0, const0_rtx,
--- 3492,3498 ----
    result = gen_reg_rtx (mode);
  
    /* Avoid conditional branches when they're expensive.  */
!   if (BRANCH_COST (optimize_insn_for_speed_p (), false) >= 2
        && optimize_insn_for_speed_p ())
      {
        rtx signmask = emit_store_flag (result, LT, op0, const0_rtx,
*************** expand_sdiv_pow2 (enum machine_mode mode
*** 3592,3598 ****
    logd = floor_log2 (d);
    shift = build_int_cst (NULL_TREE, logd);
  
!   if (d == 2 && BRANCH_COST >= 1)
      {
        temp = gen_reg_rtx (mode);
        temp = emit_store_flag (temp, LT, op0, const0_rtx, mode, 0, 1);
--- 3592,3600 ----
    logd = floor_log2 (d);
    shift = build_int_cst (NULL_TREE, logd);
  
!   if (d == 2
!       && BRANCH_COST (optimize_insn_for_speed_p (),
! 		      false) >= 1)
      {
        temp = gen_reg_rtx (mode);
        temp = emit_store_flag (temp, LT, op0, const0_rtx, mode, 0, 1);
*************** expand_sdiv_pow2 (enum machine_mode mode
*** 3602,3608 ****
      }
  
  #ifdef HAVE_conditional_move
!   if (BRANCH_COST >= 2)
      {
        rtx temp2;
  
--- 3604,3611 ----
      }
  
  #ifdef HAVE_conditional_move
!   if (BRANCH_COST (optimize_insn_for_speed_p (), false)
!       >= 2)
      {
        rtx temp2;
  
*************** expand_sdiv_pow2 (enum machine_mode mode
*** 3631,3637 ****
      }
  #endif
  
!   if (BRANCH_COST >= 2)
      {
        int ushift = GET_MODE_BITSIZE (mode) - logd;
  
--- 3634,3641 ----
      }
  #endif
  
!   if (BRANCH_COST (optimize_insn_for_speed_p (),
! 		   false) >= 2)
      {
        int ushift = GET_MODE_BITSIZE (mode) - logd;
  
*************** emit_store_flag (rtx target, enum rtx_co
*** 5345,5351 ****
       comparison with zero.  Don't do any of these cases if branches are
       very cheap.  */
  
!   if (BRANCH_COST > 0
        && GET_MODE_CLASS (mode) == MODE_INT && (code == EQ || code == NE)
        && op1 != const0_rtx)
      {
--- 5349,5356 ----
       comparison with zero.  Don't do any of these cases if branches are
       very cheap.  */
  
!   if (BRANCH_COST (optimize_insn_for_speed_p (),
! 		   false) > 0
        && GET_MODE_CLASS (mode) == MODE_INT && (code == EQ || code == NE)
        && op1 != const0_rtx)
      {
*************** emit_store_flag (rtx target, enum rtx_co
*** 5368,5377 ****
       do LE and GT if branches are expensive since they are expensive on
       2-operand machines.  */
  
!   if (BRANCH_COST == 0
        || GET_MODE_CLASS (mode) != MODE_INT || op1 != const0_rtx
        || (code != EQ && code != NE
! 	  && (BRANCH_COST <= 1 || (code != LE && code != GT))))
      return 0;
  
    /* See what we need to return.  We can only return a 1, -1, or the
--- 5373,5384 ----
       do LE and GT if branches are expensive since they are expensive on
       2-operand machines.  */
  
!   if (BRANCH_COST (optimize_insn_for_speed_p (),
! 		   false) == 0
        || GET_MODE_CLASS (mode) != MODE_INT || op1 != const0_rtx
        || (code != EQ && code != NE
! 	  && (BRANCH_COST (optimize_insn_for_speed_p (),
! 			   false) <= 1 || (code != LE && code != GT))))
      return 0;
  
    /* See what we need to return.  We can only return a 1, -1, or the
*************** emit_store_flag (rtx target, enum rtx_co
*** 5467,5473 ****
  	 that "or", which is an extra insn, so we only handle EQ if branches
  	 are expensive.  */
  
!       if (tem == 0 && (code == NE || BRANCH_COST > 1))
  	{
  	  if (rtx_equal_p (subtarget, op0))
  	    subtarget = 0;
--- 5474,5483 ----
  	 that "or", which is an extra insn, so we only handle EQ if branches
  	 are expensive.  */
  
!       if (tem == 0
! 	  && (code == NE
! 	      || BRANCH_COST (optimize_insn_for_speed_p (),
! 		      	      false) > 1))
  	{
  	  if (rtx_equal_p (subtarget, op0))
  	    subtarget = 0;
Index: basic-block.h
===================================================================
*** basic-block.h	(revision 139737)
--- basic-block.h	(working copy)
*************** extern void guess_outgoing_edge_probabil
*** 848,853 ****
--- 848,854 ----
  extern void remove_predictions_associated_with_edge (edge);
  extern bool edge_probability_reliable_p (const_edge);
  extern bool br_prob_note_reliable_p (const_rtx);
+ extern bool predictable_edge_p (edge);
  
  /* In cfg.c  */
  extern void dump_regset (regset, FILE *);
Index: config/alpha/alpha.h
===================================================================
*** config/alpha/alpha.h	(revision 139737)
--- config/alpha/alpha.h	(working copy)
*************** extern int alpha_memory_latency;
*** 640,646 ****
  #define MEMORY_MOVE_COST(MODE,CLASS,IN)  (2*alpha_memory_latency)
  
  /* Provide the cost of a branch.  Exact meaning under development.  */
! #define BRANCH_COST 5
  \f
  /* Stack layout; function entry, exit and calling.  */
  
--- 640,646 ----
  #define MEMORY_MOVE_COST(MODE,CLASS,IN)  (2*alpha_memory_latency)
  
  /* Provide the cost of a branch.  Exact meaning under development.  */
! #define BRANCH_COST(speed_p, predictable_p) 5
  \f
  /* Stack layout; function entry, exit and calling.  */
  
Index: config/frv/frv.h
===================================================================
*** config/frv/frv.h	(revision 139737)
--- config/frv/frv.h	(working copy)
*************** do {							\
*** 2193,2199 ****
  
  /* A C expression for the cost of a branch instruction.  A value of 1 is the
     default; other values are interpreted relative to that.  */
! #define BRANCH_COST frv_branch_cost_int
  
  /* Define this macro as a C expression which is nonzero if accessing less than
     a word of memory (i.e. a `char' or a `short') is no faster than accessing a
--- 2193,2199 ----
  
  /* A C expression for the cost of a branch instruction.  A value of 1 is the
     default; other values are interpreted relative to that.  */
! #define BRANCH_COST(speed_p, predictable_p) frv_branch_cost_int
  
  /* Define this macro as a C expression which is nonzero if accessing less than
     a word of memory (i.e. a `char' or a `short') is no faster than accessing a
Index: config/s390/s390.h
===================================================================
*** config/s390/s390.h	(revision 139737)
--- config/s390/s390.h	(working copy)
*************** extern struct rtx_def *s390_compare_op0,
*** 828,834 ****
  
  /* A C expression for the cost of a branch instruction.  A value of 1
     is the default; other values are interpreted relative to that.  */
! #define BRANCH_COST 1
  
  /* Nonzero if access to memory by bytes is slow and undesirable.  */
  #define SLOW_BYTE_ACCESS 1
--- 828,834 ----
  
  /* A C expression for the cost of a branch instruction.  A value of 1
     is the default; other values are interpreted relative to that.  */
! #define BRANCH_COST(speed_p, predictable_p) 1
  
  /* Nonzero if access to memory by bytes is slow and undesirable.  */
  #define SLOW_BYTE_ACCESS 1
Index: config/spu/spu.h
===================================================================
*** config/spu/spu.h	(revision 139737)
--- config/spu/spu.h	(working copy)
*************** targetm.resolve_overloaded_builtin = spu
*** 434,440 ****
  \f
  /* Costs */
  
! #define BRANCH_COST spu_branch_cost
  
  #define SLOW_BYTE_ACCESS 0
  
--- 434,440 ----
  \f
  /* Costs */
  
! #define BRANCH_COST(speed_p, predictable_p) spu_branch_cost
  
  #define SLOW_BYTE_ACCESS 0
  
Index: config/sparc/sparc.h
===================================================================
*** config/sparc/sparc.h	(revision 139737)
--- config/sparc/sparc.h	(working copy)
*************** do {                                    
*** 2196,2202 ****
     On Niagara-2, a not-taken branch costs 1 cycle whereas a taken
     branch costs 6 cycles.  */
  
! #define BRANCH_COST \
  	((sparc_cpu == PROCESSOR_V9 \
  	  || sparc_cpu == PROCESSOR_ULTRASPARC) \
  	 ? 7 \
--- 2196,2202 ----
     On Niagara-2, a not-taken branch costs 1 cycle whereas a taken
     branch costs 6 cycles.  */
  
! #define BRANCH_COST (speed_p, predictable_p) \
  	((sparc_cpu == PROCESSOR_V9 \
  	  || sparc_cpu == PROCESSOR_ULTRASPARC) \
  	 ? 7 \
Index: config/m32r/m32r.h
===================================================================
*** config/m32r/m32r.h	(revision 139737)
--- config/m32r/m32r.h	(working copy)
*************** L2:     .word STATIC
*** 1224,1230 ****
  /* A value of 2 here causes GCC to avoid using branches in comparisons like
     while (a < N && a).  Branches aren't that expensive on the M32R so
     we define this as 1.  Defining it as 2 had a heavy hit in fp-bit.c.  */
! #define BRANCH_COST ((TARGET_BRANCH_COST) ? 2 : 1)
  
  /* Nonzero if access to memory by bytes is slow and undesirable.
     For RISC chips, it means that access to memory by bytes is no
--- 1224,1230 ----
  /* A value of 2 here causes GCC to avoid using branches in comparisons like
     while (a < N && a).  Branches aren't that expensive on the M32R so
     we define this as 1.  Defining it as 2 had a heavy hit in fp-bit.c.  */
! #define BRANCH_COST(speed_p, predictable_p) ((TARGET_BRANCH_COST) ? 2 : 1)
  
  /* Nonzero if access to memory by bytes is slow and undesirable.
     For RISC chips, it means that access to memory by bytes is no
Index: config/i386/i386.h
===================================================================
*** config/i386/i386.h	(revision 139737)
--- config/i386/i386.h	(working copy)
*************** do {							\
*** 1975,1981 ****
  /* A C expression for the cost of a branch instruction.  A value of 1
     is the default; other values are interpreted relative to that.  */
  
! #define BRANCH_COST ix86_branch_cost
  
  /* Define this macro as a C expression which is nonzero if accessing
     less than a word of memory (i.e. a `char' or a `short') is no
--- 1975,1982 ----
  /* A C expression for the cost of a branch instruction.  A value of 1
     is the default; other values are interpreted relative to that.  */
  
! #define BRANCH_COST(speed_p, predictable_p) \
!   (!(speed_p) ? 2 : (predictable_p) ? 0 : ix86_branch_cost)
  
  /* Define this macro as a C expression which is nonzero if accessing
     less than a word of memory (i.e. a `char' or a `short') is no
Index: config/i386/i386.c
===================================================================
*** config/i386/i386.c	(revision 139737)
--- config/i386/i386.c	(working copy)
*************** ix86_expand_int_movcc (rtx operands[])
*** 14636,14642 ****
         */
  
        if ((!TARGET_CMOVE || (mode == QImode && TARGET_PARTIAL_REG_STALL))
! 	  && BRANCH_COST >= 2)
  	{
  	  if (cf == 0)
  	    {
--- 14636,14643 ----
         */
  
        if ((!TARGET_CMOVE || (mode == QImode && TARGET_PARTIAL_REG_STALL))
! 	  && BRANCH_COST (optimize_insn_for_speed_p (),
! 		  	  false) >= 2)
  	{
  	  if (cf == 0)
  	    {
*************** ix86_expand_int_movcc (rtx operands[])
*** 14721,14727 ****
        optab op;
        rtx var, orig_out, out, tmp;
  
!       if (BRANCH_COST <= 2)
  	return 0; /* FAIL */
  
        /* If one of the two operands is an interesting constant, load a
--- 14722,14728 ----
        optab op;
        rtx var, orig_out, out, tmp;
  
!       if (BRANCH_COST (optimize_insn_for_speed_p (), false) <= 2)
  	return 0; /* FAIL */
  
        /* If one of the two operands is an interesting constant, load a
Index: config/sh/sh.h
===================================================================
*** config/sh/sh.h	(revision 139737)
--- config/sh/sh.h	(working copy)
*************** struct sh_args {
*** 2847,2853 ****
     The SH1 does not have delay slots, hence we get a pipeline stall
     at every branch.  The SH4 is superscalar, so the single delay slot
     is not sufficient to keep both pipelines filled.  */
! #define BRANCH_COST (TARGET_SH5 ? 1 : ! TARGET_SH2 || TARGET_HARD_SH4 ? 2 : 1)
  \f
  /* Assembler output control.  */
  
--- 2847,2854 ----
     The SH1 does not have delay slots, hence we get a pipeline stall
     at every branch.  The SH4 is superscalar, so the single delay slot
     is not sufficient to keep both pipelines filled.  */
! #define BRANCH_COST(speed_p, predictable_p) \
! 	(TARGET_SH5 ? 1 : ! TARGET_SH2 || TARGET_HARD_SH4 ? 2 : 1)
  \f
  /* Assembler output control.  */
  
Index: config/pdp11/pdp11.h
===================================================================
*** config/pdp11/pdp11.h	(revision 139737)
--- config/pdp11/pdp11.h	(working copy)
*************** JMP	FUNCTION	0x0058  0x0000 <- FUNCTION
*** 1057,1063 ****
  /* there is no point in avoiding branches on a pdp, 
     since branches are really cheap - I just want to find out
     how much difference the BRANCH_COST macro makes in code */
! #define BRANCH_COST (TARGET_BRANCH_CHEAP ? 0 : 1)
  
  
  #define COMPARE_FLAG_MODE HImode
--- 1057,1063 ----
  /* there is no point in avoiding branches on a pdp, 
     since branches are really cheap - I just want to find out
     how much difference the BRANCH_COST macro makes in code */
! #define BRANCH_COST(speed_p, predictable_p) (TARGET_BRANCH_CHEAP ? 0 : 1)
  
  
  #define COMPARE_FLAG_MODE HImode
Index: config/avr/avr.h
===================================================================
*** config/avr/avr.h	(revision 139737)
--- config/avr/avr.h	(working copy)
*************** do {									    \
*** 511,517 ****
  					 (MODE)==SImode ? 8 :	\
  					 (MODE)==SFmode ? 8 : 16)
  
! #define BRANCH_COST 0
  
  #define SLOW_BYTE_ACCESS 0
  
--- 511,517 ----
  					 (MODE)==SImode ? 8 :	\
  					 (MODE)==SFmode ? 8 : 16)
  
! #define BRANCH_COST(speed_p, predictable_p) 0
  
  #define SLOW_BYTE_ACCESS 0
  
Index: config/crx/crx.h
===================================================================
*** config/crx/crx.h	(revision 139737)
--- config/crx/crx.h	(working copy)
*************** struct cumulative_args
*** 420,426 ****
  /* Moving to processor register flushes pipeline - thus asymmetric */
  #define REGISTER_MOVE_COST(MODE, FROM, TO) ((TO != GENERAL_REGS) ? 8 : 2)
  /* Assume best case (branch predicted) */
! #define BRANCH_COST 2
  
  #define SLOW_BYTE_ACCESS  1
  
--- 420,426 ----
  /* Moving to processor register flushes pipeline - thus asymmetric */
  #define REGISTER_MOVE_COST(MODE, FROM, TO) ((TO != GENERAL_REGS) ? 8 : 2)
  /* Assume best case (branch predicted) */
! #define BRANCH_COST(speed_p, predictable_p) 2
  
  #define SLOW_BYTE_ACCESS  1
  
Index: config/xtensa/xtensa.h
===================================================================
*** config/xtensa/xtensa.h	(revision 139737)
--- config/xtensa/xtensa.h	(working copy)
*************** typedef struct xtensa_args
*** 882,888 ****
  
  #define MEMORY_MOVE_COST(MODE, CLASS, IN) 4
  
! #define BRANCH_COST 3
  
  /* How to refer to registers in assembler output.
     This sequence is indexed by compiler's hard-register-number (see above).  */
--- 882,888 ----
  
  #define MEMORY_MOVE_COST(MODE, CLASS, IN) 4
  
! #define BRANCH_COST(speed_p, predictable_p) 3
  
  /* How to refer to registers in assembler output.
     This sequence is indexed by compiler's hard-register-number (see above).  */
Index: config/stormy16/stormy16.h
===================================================================
*** config/stormy16/stormy16.h	(revision 139737)
--- config/stormy16/stormy16.h	(working copy)
*************** do {							\
*** 587,593 ****
  
  #define MEMORY_MOVE_COST(M,C,I) (5 + memory_move_secondary_cost (M, C, I))
  
! #define BRANCH_COST 5
  
  #define SLOW_BYTE_ACCESS 0
  
--- 587,593 ----
  
  #define MEMORY_MOVE_COST(M,C,I) (5 + memory_move_secondary_cost (M, C, I))
  
! #define BRANCH_COST(speed_p, predictable_p) 5
  
  #define SLOW_BYTE_ACCESS 0
  
Index: config/m68hc11/m68hc11.h
===================================================================
*** config/m68hc11/m68hc11.h	(revision 139737)
--- config/m68hc11/m68hc11.h	(working copy)
*************** extern unsigned char m68hc11_reg_valid_f
*** 1266,1272 ****
  
     Pretend branches are cheap because GCC generates sub-optimal code
     for the default value.  */
! #define BRANCH_COST 0
  
  /* Nonzero if access to memory by bytes is slow and undesirable.  */
  #define SLOW_BYTE_ACCESS	0
--- 1266,1272 ----
  
     Pretend branches are cheap because GCC generates sub-optimal code
     for the default value.  */
! #define BRANCH_COST(speed_p, predictable_p) 0
  
  /* Nonzero if access to memory by bytes is slow and undesirable.  */
  #define SLOW_BYTE_ACCESS	0
Index: config/iq2000/iq2000.h
===================================================================
*** config/iq2000/iq2000.h	(revision 139737)
--- config/iq2000/iq2000.h	(working copy)
*************** typedef struct iq2000_args
*** 624,630 ****
  #define MEMORY_MOVE_COST(MODE,CLASS,TO_P)	\
    (TO_P ? 2 : 16)
  
! #define BRANCH_COST 2
  
  #define SLOW_BYTE_ACCESS 1
  
--- 624,630 ----
  #define MEMORY_MOVE_COST(MODE,CLASS,TO_P)	\
    (TO_P ? 2 : 16)
  
! #define BRANCH_COST(speed_p, predictable_p) 2
  
  #define SLOW_BYTE_ACCESS 1
  
Index: config/ia64/ia64.h
===================================================================
*** config/ia64/ia64.h	(revision 139737)
--- config/ia64/ia64.h	(working copy)
*************** do {									\
*** 1384,1390 ****
     many additional insn groups we run into, vs how good the dynamic
     branch predictor is.  */
  
! #define BRANCH_COST 6
  
  /* Define this macro as a C expression which is nonzero if accessing less than
     a word of memory (i.e. a `char' or a `short') is no faster than accessing a
--- 1384,1390 ----
     many additional insn groups we run into, vs how good the dynamic
     branch predictor is.  */
  
! #define BRANCH_COST(speed_p, predictable_p) 6
  
  /* Define this macro as a C expression which is nonzero if accessing less than
     a word of memory (i.e. a `char' or a `short') is no faster than accessing a
Index: config/rs6000/rs6000.h
===================================================================
*** config/rs6000/rs6000.h	(revision 139737)
--- config/rs6000/rs6000.h	(working copy)
*************** extern enum rs6000_nop_insertion rs6000_
*** 967,973 ****
     Set this to 3 on the RS/6000 since that is roughly the average cost of an
     unscheduled conditional branch.  */
  
! #define BRANCH_COST 3
  
  /* Override BRANCH_COST heuristic which empirically produces worse
     performance for removing short circuiting from the logical ops.  */
--- 967,973 ----
     Set this to 3 on the RS/6000 since that is roughly the average cost of an
     unscheduled conditional branch.  */
  
! #define BRANCH_COST(speed_p, predictable_p) 3
  
  /* Override BRANCH_COST heuristic which empirically produces worse
     performance for removing short circuiting from the logical ops.  */
Index: config/arc/arc.h
===================================================================
*** config/arc/arc.h	(revision 139737)
--- config/arc/arc.h	(working copy)
*************** arc_select_cc_mode (OP, X, Y)
*** 824,830 ****
  /* The cost of a branch insn.  */
  /* ??? What's the right value here?  Branches are certainly more
     expensive than reg->reg moves.  */
! #define BRANCH_COST 2
  
  /* Nonzero if access to memory by bytes is slow and undesirable.
     For RISC chips, it means that access to memory by bytes is no
--- 824,830 ----
  /* The cost of a branch insn.  */
  /* ??? What's the right value here?  Branches are certainly more
     expensive than reg->reg moves.  */
! #define BRANCH_COST(speed_p, predictable_p) 2
  
  /* Nonzero if access to memory by bytes is slow and undesirable.
     For RISC chips, it means that access to memory by bytes is no
Index: config/score/score.h
===================================================================
*** config/score/score.h	(revision 139737)
--- config/score/score.h	(working copy)
*************** typedef struct score_args
*** 793,799 ****
    (4 + memory_move_secondary_cost ((MODE), (CLASS), (TO_P)))
  
  /* Try to generate sequences that don't involve branches.  */
! #define BRANCH_COST                     2
  
  /* Nonzero if access to memory by bytes is slow and undesirable.  */
  #define SLOW_BYTE_ACCESS                1
--- 793,799 ----
    (4 + memory_move_secondary_cost ((MODE), (CLASS), (TO_P)))
  
  /* Try to generate sequences that don't involve branches.  */
! #define BRANCH_COST(speed_p, predictable_p) 2
  
  /* Nonzero if access to memory by bytes is slow and undesirable.  */
  #define SLOW_BYTE_ACCESS                1
Index: config/arm/arm.h
===================================================================
*** config/arm/arm.h	(revision 139737)
--- config/arm/arm.h	(working copy)
*************** do {							\
*** 2297,2303 ****
  
  /* Try to generate sequences that don't involve branches, we can then use
     conditional instructions */
! #define BRANCH_COST \
    (TARGET_32BIT ? 4 : (optimize > 0 ? 2 : 0))
  \f
  /* Position Independent Code.  */
--- 2297,2303 ----
  
  /* Try to generate sequences that don't involve branches, we can then use
     conditional instructions */
! #define BRANCH_COST(speed_p, predictable_p) \
    (TARGET_32BIT ? 4 : (optimize > 0 ? 2 : 0))
  \f
  /* Position Independent Code.  */
Index: config/pa/pa.h
===================================================================
*** config/pa/pa.h	(revision 139737)
--- config/pa/pa.h	(working copy)
*************** do { 									\
*** 1570,1576 ****
    : 2)
  
  /* Adjust the cost of branches.  */
! #define BRANCH_COST (pa_cpu == PROCESSOR_8000 ? 2 : 1)
  
  /* Handling the special cases is going to get too complicated for a macro,
     just call `pa_adjust_insn_length' to do the real work.  */
--- 1570,1576 ----
    : 2)
  
  /* Adjust the cost of branches.  */
! #define BRANCH_COST(speed_p, predictable_p) (pa_cpu == PROCESSOR_8000 ? 2 : 1)
  
  /* Handling the special cases is going to get too complicated for a macro,
     just call `pa_adjust_insn_length' to do the real work.  */
Index: config/mips/mips.h
===================================================================
*** config/mips/mips.h	(revision 139737)
--- config/mips/mips.h	(working copy)
*************** typedef struct mips_args {
*** 2551,2557 ****
  /* A C expression for the cost of a branch instruction.  A value of
     1 is the default; other values are interpreted relative to that.  */
  
! #define BRANCH_COST mips_branch_cost
  #define LOGICAL_OP_NON_SHORT_CIRCUIT 0
  
  /* If defined, modifies the length assigned to instruction INSN as a
--- 2551,2557 ----
  /* A C expression for the cost of a branch instruction.  A value of
     1 is the default; other values are interpreted relative to that.  */
  
! #define BRANCH_COST(speed_p, predictable_p) mips_branch_cost
  #define LOGICAL_OP_NON_SHORT_CIRCUIT 0
  
  /* If defined, modifies the length assigned to instruction INSN as a
Index: config/vax/vax.h
===================================================================
*** config/vax/vax.h	(revision 139737)
--- config/vax/vax.h	(working copy)
*************** enum reg_class { NO_REGS, ALL_REGS, LIM_
*** 648,654 ****
     Branches are extremely cheap on the VAX while the shift insns often
     used to replace branches can be expensive.  */
  
! #define BRANCH_COST 0
  \f
  /* Tell final.c how to eliminate redundant test instructions.  */
  
--- 648,654 ----
     Branches are extremely cheap on the VAX while the shift insns often
     used to replace branches can be expensive.  */
  
! #define BRANCH_COST(speed_p, predictable_p) 0
  \f
  /* Tell final.c how to eliminate redundant test instructions.  */
  
Index: config/h8300/h8300.h
===================================================================
*** config/h8300/h8300.h	(revision 139737)
--- config/h8300/h8300.h	(working copy)
*************** struct cum_arg
*** 1004,1010 ****
  #define DELAY_SLOT_LENGTH(JUMP) \
    (NEXT_INSN (PREV_INSN (JUMP)) == JUMP ? 0 : 2)
  
! #define BRANCH_COST 0
  
  /* Tell final.c how to eliminate redundant test instructions.  */
  
--- 1004,1010 ----
  #define DELAY_SLOT_LENGTH(JUMP) \
    (NEXT_INSN (PREV_INSN (JUMP)) == JUMP ? 0 : 2)
  
! #define BRANCH_COST(speed_p, predictable_p) 0
  
  /* Tell final.c how to eliminate redundant test instructions.  */
  
Index: params.def
===================================================================
*** params.def	(revision 139737)
--- params.def	(working copy)
*************** DEFPARAM (PARAM_STRUCT_REORG_COLD_STRUCT
*** 78,83 ****
--- 78,90 ----
  	  "The threshold ratio between current and hottest structure counts",
  	  10, 0, 100)
  
+ /* When branch is predicted to be taken with probability lower than this
+    threshold (in percent), then it is considered well predictable. */
+ DEFPARAM (PARAM_PREDICTABLE_BRANCH_OUTCOME,
+ 	  "predictable-branch-outcome",
+ 	  "Maximal esitmated outcome of branch considered predictable",
+ 	  2, 0, 50)
+ 
  /* The single function inlining limit. This is the maximum size
     of a function counted in internal gcc instructions (not in
     real machine instructions) that is eligible for inlining

Patch ping

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00984.html
- 4.3/4.4 P1 PR rtl-optimization/36419 - last patch in the series to fix
  -Os -fasynchronous-unwind-tables

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01305.html
- 4.1/4.3/4.4 P1 regression, fix unwind info if combine_stack_adjustment
  combined post-prologue adjustment with prologue adjustment

One of:
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00764.html
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00783.html
- 4.3/4.4 P2 regression, typeid on member function: I understood
  disagreement between Jason/Mark in the thread whether arrays
  with incomplete element types are supposed to be valid typeid
  arguments or not.  Which of these patches we want (or something
  different?)?

	Jakub

Re: Patch ping

[Jason Merrill]

Jakub Jelinek wrote:
> I think this is uglification rather than cleanup, especially given the
> size of the duplicated code and that the error messages need to be
> different, but certainly if you prefer it that way, I can write a patch. 

I think I do prefer it that way, so that if we add additional checks in 
the future it will be obvious that we need to handle both cases.  If 
checks are in two different places changes in one tend not to be 
reflected in the other.

Jason

Re: Patch ping

[Jakub Jelinek]

On Wed, May 07, 2008 at 10:52:42AM -0400, Jason Merrill wrote:
> Jakub Jelinek wrote:
> >- C++ compound literal diagnostics		PR c++/36023	P2 4.3/4.4
> >  http://gcc.gnu.org/ml/gcc-patches/2008-04/msg02045.html
> 
> Rather than duplicating code, please split out the parts of 
> check_initializer that are also appropriate for finish_compound_literal.

Sorry for getting to this so late.

check_initializer has:

  if (TREE_CODE (type) == ARRAY_TYPE)
    {
      tree element_type = TREE_TYPE (type);

      /* The array type itself need not be complete, because the
         initializer may tell us how many elements are in the array.
         But, the elements of the array must be complete.  */
      if (!COMPLETE_TYPE_P (complete_type (element_type)))
        {
          error ("elements of array %q#D have incomplete type", decl);
          return NULL_TREE;
        }
      /* It is not valid to initialize a VLA.  */
      if (init
          && ((COMPLETE_TYPE_P (type) && !TREE_CONSTANT (TYPE_SIZE (type)))
              || !TREE_CONSTANT (TYPE_SIZE (element_type))))
        {
          error ("variable-sized object %qD may not be initialized", decl);
          return NULL_TREE;
        }
    }

While the 3 if conditions can be the same (assuming finish_compound_literal
passes compound_literal as init), the problem is with the diagnostics,
as finish_compound_literal doesn't have any decl, just the type, and in
check_initializer reporting the decl is really preferrable over just
returning the type.  So, if I were to move the above into separate function,
it would need to special case that, say:

bool
check_array_initializer (tree decl, tree type, tree init)
{
  if (TREE_CODE (type) == ARRAY_TYPE)
    {
      tree element_type = TREE_TYPE (type);

      /* The array type itself need not be complete, because the
         initializer may tell us how many elements are in the array.
         But, the elements of the array must be complete.  */
      if (!COMPLETE_TYPE_P (complete_type (element_type)))
        {
	  if (decl)
	    error ("elements of array %q#D have incomplete type", decl);
	  else
	    error ("elements of array %q#T have incomplete type", type);
          return true;
        }
      /* It is not valid to initialize a VLA.  */
      if (init
          && ((COMPLETE_TYPE_P (type) && !TREE_CONSTANT (TYPE_SIZE (type)))
              || !TREE_CONSTANT (TYPE_SIZE (element_type))))
        {
	  if (decl)
	    error ("variable-sized object %qD may not be initialized", decl);
	  else
	    error ("variable-sized compound literal");
          return true;
        }
    }
  return false;
}

and check_initializer replacing its code with
  if (check_array_initializer (decl, type, init))
    return NULL_TREE;
and finish_compound_literal adding:
  if (check_array_initializer (NULL_TREE, type, compound_literal))
    return error_mark_node;

I think this is uglification rather than cleanup, especially given the
size of the duplicated code and that the error messages need to be
different, but certainly if you prefer it that way, I can write a patch. 

	Jakub

Re: Patch ping

[Diego Novillo]

On 5/7/08 4:32 AM, Jakub Jelinek wrote:

> - nowait for tree-parloops.c			-		-  4.4
>   http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00288.html

ISTR approving this one.  If I didn't, the patch is OK.


Diego.

Re: Patch ping

[Jason Merrill]

Jakub Jelinek wrote:
> - C++ compound literal diagnostics		PR c++/36023	P2 4.3/4.4
>   http://gcc.gnu.org/ml/gcc-patches/2008-04/msg02045.html

Rather than duplicating code, please split out the parts of 
check_initializer that are also appropriate for finish_compound_literal.

> - fix dwarf2out.c for Fortran COMMONs		PR debug/35896	P1 4.4
>   http://gcc.gnu.org/ml/gcc-patches/2008-04/msg02114.html

OK.

Jason

Patch ping

[Jakub Jelinek]

Hi!

- C++ compound literal diagnostics		PR c++/36023	P2 4.3/4.4
  http://gcc.gnu.org/ml/gcc-patches/2008-04/msg02045.html

- fix dwarf2out.c for Fortran COMMONs		PR debug/35896	P1 4.4
  http://gcc.gnu.org/ml/gcc-patches/2008-04/msg02114.html

- change simplify_plus_minus canonicalization	PR target/36090	P1 4.3/4.4
  http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00202.html
  testcase in http://gcc.gnu.org/bugzilla/attachment.cgi?id=15576&action=view

- nowait for tree-parloops.c			-		-  4.4
  http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00288.html

All patches have been bootstrapped/regtested on x86_64-linux, PR36090
also on ppc-linux, ppc64-linux and i386-linux.

	Jakub

Re: Patch ping...

[Hans-Peter Nilsson]

On Fri, 11 Apr 2008, Mark Mitchell wrote:
> I certainly understand the idea of the attribute, and I think it's a good
> idea.  I also think a mode where -Os honors that attribute (even at the
> expense of size) is a good idea.

Yes.

>  What I don't know is whether that's the
> right default behavior for -Os.

No, for one because the person/s writing the programs may be
different (and with different views on where to add attr hot)
from the ones that need to compile it, using the -Os option.

>  I'd be interested in what others think.

As you suggested, I agree with using a separate -f, like
-foptimize-hot-for-speed to enable that behaviour (but maybe
having a shorter name).

brgds, H-P

Re: Patch ping...

[Mark Mitchell]

Michael Matz wrote:

>>> and decide on hotness.  With -Os defaulting to conservative behaviour
>>> (ie function is hot only if attribute or profile feedback suggest so)
>>> and -O2 defaulting to aggressive behaviour (function is hot if not
>>> declared cold, function local profile is within bounds).
>> This seems like a good idea, except that I'm not sure it's what people really
>> want from -Os.  With -Os, I think some users want small code, all the time,
>> period.
> 
> Then they should not use attribute(hot) or profile feedback, period.

The issue I am raising is that __attribute((hot))__ is a property of the 
application, not of the system.  So, the developer building the 
application might well mark something as "hot" because that's the inner 
loop of that application -- but the application as a whole might be very 
rarely used on the target system.  There's no way for the developer of 
the application to know that, and there's no way for the system 
integration to know that __attribute__((hot))__ is in use, effectively 
wasting precious flash.

Clearly, if this makes a 100MB application 100 bytes bigger, nobody 
cares.  I am not sure if there is any issue here in practice.  If the 
reality is that the total fraction of hot functions is very small, then 
it may be so small that we don't care.

I certainly understand the idea of the attribute, and I think it's a 
good idea.  I also think a mode where -Os honors that attribute (even at 
the expense of size) is a good idea.  What I don't know is whether 
that's the right default behavior for -Os.  I'd be interested in what 
others think.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Patch ping...

[Michael Matz]

Hi,

On Tue, 8 Apr 2008, Mark Mitchell wrote:

> > and decide on hotness.  With -Os defaulting to conservative behaviour
> > (ie function is hot only if attribute or profile feedback suggest so)
> > and -O2 defaulting to aggressive behaviour (function is hot if not
> > declared cold, function local profile is within bounds).
> 
> This seems like a good idea, except that I'm not sure it's what people really
> want from -Os.  With -Os, I think some users want small code, all the time,
> period.

Then they should not use attribute(hot) or profile feedback, period.


Ciao,
Michael.

Re: Patch ping...

[Jan Hubicka]

> 
> Of course, I don't have any objection with adding a -Os -f<something> 
> option to do something that's more like "small code, except for places 
> where you think it really matters".

To some degree, I would like to avoid GCC command line explossion.  It
always seemed to me that it is resonable to make -Os optimize for size
unless explicitely stated in program to not do so.
On the other hand, at the moment it is more about infrastructure, and I
guess we all agree on the other half that -O2 + attribute cold (or other
good hint, like abort call or builtin_expect) should lead to
optimization for size

So I am happy to drop the -Os part of the plot, and make "hot" predicate
to always result false for -Os declaring whole compiled application
cold.  Later we can think of what -f option we want or what -Os
behaviour is preferrable.

As Andi mentioned, we have problem that -O2 is bit too performance
centric for average application in many cases probably making system
built with -O2 requiring more memory than it would need and thus be
slower. Though I believe we are better in this respect than many other
compilers.

It might make sense to make -O2 more code size concerned instead of
having -Omostly-small or have some -fXXX finetunning for -Os to make -Os
useable for applications where speed matters too.  But it is better to
handle this independently. Just thinking of way how to benchmark this
drive my head crazy ;)

Honza
> 
> -- 
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713

Re: Patch ping...

[Andi Kleen]

Mark Mitchell <mark@codesourcery.com> writes:

> Jan Hubicka wrote:
>
>> What I think -Os can be really useful for is well maintained code base,
>> with code size constraints.  (Linux kernel)  You compile it with -Os and
>> get small code except for the case you explicitly use __attribute__
>> ((hot)).  Given the observation that just tiny portion of program is
>> hot, it in general makes more sense than using -O2/-O3 and cold attribute.
>
> That makes sense, but it's only one usage model.  Another case is
> where you want your applications to be small -- perhaps because the
> whole application is "cold".  I'm running on an embedded device, I
> want to have this application available, but flash is scarce, and I
> expect to need this application only very rarely; please use no more
> space than possible.

But even such an embedded application might have a single function or
two which is time critical. So giving a runtime switch for hot would
even make sense for them. 

And if they don't want it, just should just not use __attribute__((hot))

Also there is plenty of precendence on other compilers for pragmas to
change optimization levels on the fly inside files (I sometimes would really
love that for -funroll-loops for example), so there seems to be definitely
user demand for things like this.

Also to be honest I would like to have a -Omostly-small

That is current -Os is usually better for icache constrained
applications that don't loop much (like a kernel), but sometimes it
generates extremly bad code just to save a few bytes which has hurt in
the past (as in appearing on profiles for macro benchmarks).

One example for this is division code generation where on x86 -Os
prefers always the hardware DIV instructions even when they can be
magnitudes slower than an only slightly bigger expanded sequence.

__attribute__((hot)) of course is the first step to fix that.

-Andi

Re: Patch ping...

[Mark Mitchell]

Jan Hubicka wrote:

> What I think -Os can be really useful for is well maintained code base,
> with code size constraints.  (Linux kernel)  You compile it with -Os and
> get small code except for the case you explicitly use __attribute__
> ((hot)).  Given the observation that just tiny portion of program is
> hot, it in general makes more sense than using -O2/-O3 and cold attribute.

That makes sense, but it's only one usage model.  Another case is where 
you want your applications to be small -- perhaps because the whole 
application is "cold".  I'm running on an embedded device, I want to 
have this application available, but flash is scarce, and I expect to 
need this application only very rarely; please use no more space than 
possible.

If the user uses something like __attribute__((hot)) to specifically say 
something about a function that's arguable.  But, I think that -Os means 
*small*.

Of course, I don't have any objection with adding a -Os -f<something> 
option to do something that's more like "small code, except for places 
where you think it really matters".

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Patch ping...

[Jan Hubicka]

> Jan Hubicka wrote:
> 
> >I would like to have hot_bb_p predicate that take into accounts the
> >hints:
> > 1) hot/cold function attributes
> > 2) -Os versus optimize_size
> > 3) function local profile (ie things guarded with __builtin_expect or
> > leading to abort)
> > 4) profile feedback
> >and decide on hotness.  With -Os defaulting to conservative behaviour
> >(ie function is hot only if attribute or profile feedback suggest so)
> >and -O2 defaulting to aggressive behaviour (function is hot if not
> >declared cold, function local profile is within bounds).
> 
> This seems like a good idea, except that I'm not sure it's what people 
> really want from -Os.  With -Os, I think some users want small code, all 
> the time, period.

What I think -Os can be really useful for is well maintained code base,
with code size constraints.  (Linux kernel)  You compile it with -Os and
get small code except for the case you explicitly use __attribute__
((hot)).  Given the observation that just tiny portion of program is
hot, it in general makes more sense than using -O2/-O3 and cold attribute.  We
however can't make this default behaviour for -O2, since we can't insist
on user always marking hot functions hot in random package.

I am less sure about profile feedback.  Feedback with -Os can either
mean "figure hotness yourself" or "get the code faster without
increasing code size".  To some degree I however expect that "get me the
smallest code" people probably won't bother with profile feedback
anyway.

Honza
> 
> -- 
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713

Re: Patch ping...

[Mark Mitchell]

Jan Hubicka wrote:

> I would like to have hot_bb_p predicate that take into accounts the
> hints:
>  1) hot/cold function attributes
>  2) -Os versus optimize_size
>  3) function local profile (ie things guarded with __builtin_expect or
>  leading to abort)
>  4) profile feedback
> and decide on hotness.  With -Os defaulting to conservative behaviour
> (ie function is hot only if attribute or profile feedback suggest so)
> and -O2 defaulting to aggressive behaviour (function is hot if not
> declared cold, function local profile is within bounds).

This seems like a good idea, except that I'm not sure it's what people 
really want from -Os.  With -Os, I think some users want small code, all 
the time, period.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Patch ping...

[Jan Hubicka]

> 
> I think the patch makes sense (BRANCH_COST is special anyway compared to
> other isns cost), but I'd like to see the bigger picture as well here.  In
> particular, BRANCH_COST (hot, predictable), why isn't that simply
> BRANCH_COST (optimize_size_p, predictable) matching what I possibly
> expect for the other cost interface (insn_cost (optimize_size_p, rtx)).

The reason is that I don't think current paradigm of optimize_size
variable and profile info is good combination.
We have maybe_hot_bb_p and probably_cold_bb_p that use CFG profile to
guess on hotness.  Their names suggest in what direction they are
conservative and it defaults to preferred -O2 behaviour (ie code tends
to be hot unless there is really good reason for otherwise).

I would like to have hot_bb_p predicate that take into accounts the
hints:
 1) hot/cold function attributes
 2) -Os versus optimize_size
 3) function local profile (ie things guarded with __builtin_expect or
 leading to abort)
 4) profile feedback
and decide on hotness.  With -Os defaulting to conservative behaviour
(ie function is hot only if attribute or profile feedback suggest so)
and -O2 defaulting to aggressive behaviour (function is hot if not
declared cold, function local profile is within bounds).

I see that hotness in 90% corelate with !optimize_size, but not in 100%
cases, especially in decision affecting the whole function or unit or
loop or so that might contain both hot and cold stuff.  So I think
hottness is more precise name for what is going on here.

Honza

> 
> Thanks,
> Richard.

Re: Patch ping...

[Richard Guenther]

On Sat, Apr 5, 2008 at 6:26 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
> Hi,
>  I would like to ping the BRANCH_COST patch
>  http://gcc.gnu.org/ml/gcc/2008-03/msg00137.html
>
>  I hope to proceed with updating GCC to optimize cold blocks in same way
>  as -Os and explicitely marked hot functions in -Os code for speed.
>  For this I need to populate RTL cost interfaces with the profile info
>  and teach expansion about it.
>  This is taking quite some years now, I realize it might not be clear
>  what I am precisely shooting for, so I will also add wiki page.

I think the patch makes sense (BRANCH_COST is special anyway compared to
other isns cost), but I'd like to see the bigger picture as well here.  In
particular, BRANCH_COST (hot, predictable), why isn't that simply
BRANCH_COST (optimize_size_p, predictable) matching what I possibly
expect for the other cost interface (insn_cost (optimize_size_p, rtx)).

Thanks,
Richard.

Patch ping...

[Jan Hubicka]

Hi,
I would like to ping the BRANCH_COST patch
http://gcc.gnu.org/ml/gcc/2008-03/msg00137.html

I hope to proceed with updating GCC to optimize cold blocks in same way
as -Os and explicitely marked hot functions in -Os code for speed.
For this I need to populate RTL cost interfaces with the profile info
and teach expansion about it.
This is taking quite some years now, I realize it might not be clear
what I am precisely shooting for, so I will also add wiki page.

Honza

Re: Patch ping

[Tom Tromey]

>>>>> "Jakub" == Jakub Jelinek <jakub@redhat.com> writes:

Jakub> Preprocessing fix for macro expanded #pragmas:
Jakub> http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01145.html
Jakub> Bootstrapped/regtested many times on many linux targets, ok for 4.4?

I don't think I can approve or reject this patch, since it is part of
the C FE and not libcpp.

That said, it looks pretty reasonable to me.  It seems a bit odd to
duplicate the pragma/name mapping in c_pp_lookup_pragma and in
init_pragma.  I think it would be mildly better to keep this
information in a single place.

Tom

Patch ping

[Jakub Jelinek]

Hi!

Preprocessing fix for macro expanded #pragmas:
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01145.html

Bootstrapped/regtested many times on many linux targets, ok for 4.4?

	Jakub

Patch ping

[Jakub Jelinek]

Hi!

Could you please review:
Use shared OpenMP clause for FRAME.* tree-nested created vars rather than firstprivate (PR middle-end/35130)
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00360.html
?
Thanks.

	Jakub

Re: Patch ping

[Richard Guenther]

On 9/4/07, Jan Hubicka <hubicka@ucw.cz> wrote:
> Hi,
> please would be possible to review those few patches?  They are blocking
> some other stuff.
>
> Copyprop sharing fix
> http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01230.html
> Regrename fix (hopefully last needed for RTL sharing checker)
> http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01103.html

These two are ok.

Thanks,
Richard.

Patch ping

[Jan Hubicka]

Hi,
please would be possible to review those few patches?  They are blocking
some other stuff.

Copyprop sharing fix
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01230.html
Regrename fix (hopefully last needed for RTL sharing checker)
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01103.html

Kai's patch for MS/SYSV attribute handling (it would be nice feature to
have in next release)
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01515.html

Honza

Patch ping

[Zdenek Dvorak]

Hello,

http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01127.html
  -- second patch of the parloop branch merge

http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01783.html
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01876.html
  -- loop preserving project merge patches

http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00930.html
  -- improves alias information with builtin functions

Zdenek

Re: Patch ping

[Richard Guenther]

On 7/9/07, Zdenek Dvorak <rakdver@kam.mff.cuni.cz> wrote:
> Hello,
>
> http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01339.html
>   -- first patch for the parloop branch merge

Ok.

> http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01322.html
>   -- moves loop exit updating to remove_edge (one of changes to enable
>      loop structures to be preserved over more optimization passes)

Ok.

Thanks,
Richard.

Patch ping

[Zdenek Dvorak]

Hello,

http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01339.html
  -- first patch for the parloop branch merge

http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01322.html
  -- moves loop exit updating to remove_edge (one of changes to enable
     loop structures to be preserved over more optimization passes)

Zdenek

Patch ping

[Krister Walfridsson]

http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00332.html
-- Use --as-needed -lgcc_s for eh support for NetBSD

    /Krister

Re: Patch ping

[Diego Novillo]

On 5/23/07, Zdenek Dvorak <rakdver@kam.mff.cuni.cz> wrote:

> http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01633.html
> -- dominator analysis cleanups

Nice cleanup.  OK.

> http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00737.html
> -- analysis and generation of nontemporal prefetches

OK, but I hope you have the --param patch for the cache size ready soon.

> http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01862.html
> -- rtl part of the patch for generation of nontemporal stores

Looks like the obvious thing to do in RTL, but I can't approve this part.

Patch ping

[Zdenek Dvorak]

Hello,

http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01633.html
-- dominator analysis cleanups

http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00737.html
-- analysis and generation of nontemporal prefetches

http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01862.html
-- rtl part of the patch for generation of nontemporal stores

Zdenek

Patch ping

[Jan Hubicka]

Hi,
I would like to ping the patch
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01169.html
that removes line nmuber notes from RTL.  I think it is quite important
cleanup and would like it to receive testing within mainline for some
period of time.

Thanks,
Honza

Patch ping

[Zdenek Dvorak]

Hello,

http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01304.html
-- predictive commoning

http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00044.html
-- fixes two bugs that prevent us from optimizing unrolled loops

http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01633.html
-- dominator analysis cleanups

http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01965.html
-- patch to avoid rescanning cfg in cfg cleanup

Zdenek

Re: Patch ping

[Zdenek Dvorak]

Hello,

> >http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01495.html
> >
> >> estimate_num_insns is currently used for several things:
> >>
> >> -- on several places (loop unrolling, unswitching, exception
> >>    handling expansion), to estimate the size of the code
> >> -- in prefetching, to estimate time necessary to execute the
> >>    code
> >> -- in inlining for magic heuristic (that pretends to do the
> >>    former, but in fact turns out to be closer to the latter)
> >>
> >> Not surprisingly, it cannot work well enough for all these usages
> >> (in particular, the optimizations that rely on it being the size of
> >> the code suffer by the unrealistical values returned for calls and
> >> divisions).  This patch makes it possible to select which of these
> >> three estimates should be returned (by passing the structure containing
> >> costs of various constructs to it).
> 
> One thing that I didn't like with this patch was exposing the extra
> parameter at all call sites like estimate_num_insns (cfun,
> &eni_inlining_weights).
> Can we at least have wrappers around that like
> estimate_num_insns_for_inlining (cfun) or whatever better we come up with?

the reason I decided to expose this parameter everywhere is that this
way, tree_num_loop_insns can also be parametrized on what metrics we do
want to use (without need to create three versions of this function).
I can create the wrappers if you prefer anyway, although I think it
would be a bit confusing.

Zdenek

> Otherwise splitting the cost metrics is the only sane way to go - it's 
> being on
> my todo for splitting optimize-size and optimize-speed counts for inlining 
> as
> well.
> 
> I think I cannot approve this change though ;)
> 
> Thanks,
> Richard.

Re: Patch ping

[Janis Johnson]

On Fri, Dec 15, 2006 at 04:05:39PM -0800, H. J. Lu wrote:
> Hi Janis,
> 
> Can you take a look at SSSE3 builtin test patch:
> 
> http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00352.html

I'm sorry, I thought that message was just saying that you would add
to the 4.2 branch the tests you had already checked in on mainline, I
missed the extra "S" in SSSE3.

The patch is OK.

This whole directory is skipped if the effective target isn't i?86*-*-*
or x86_64-*-*, so there's no need to specify that in the individual
tests.  It's probably there for older tests from when they were in other
parts of the testsuite.  That's just for your information for future
tests, you don't need to change these.

Janis

Patch ping

[H. J. Lu]

Hi Janis,

Can you take a look at SSSE3 builtin test patch:

http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00352.html

Thanks.


H.J.

Re: Patch ping

[Richard Guenther]

On 12/15/06, Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> wrote:
> Hello,
>
> http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01495.html
>
> > estimate_num_insns is currently used for several things:
> >
> > -- on several places (loop unrolling, unswitching, exception
> >    handling expansion), to estimate the size of the code
> > -- in prefetching, to estimate time necessary to execute the
> >    code
> > -- in inlining for magic heuristic (that pretends to do the
> >    former, but in fact turns out to be closer to the latter)
> >
> > Not surprisingly, it cannot work well enough for all these usages
> > (in particular, the optimizations that rely on it being the size of
> > the code suffer by the unrealistical values returned for calls and
> > divisions).  This patch makes it possible to select which of these
> > three estimates should be returned (by passing the structure containing
> > costs of various constructs to it).

One thing that I didn't like with this patch was exposing the extra
parameter at all call sites like estimate_num_insns (cfun,
&eni_inlining_weights).
Can we at least have wrappers around that like
estimate_num_insns_for_inlining (cfun) or whatever better we come up with?

Otherwise splitting the cost metrics is the only sane way to go - it's being on
my todo for splitting optimize-size and optimize-speed counts for inlining as
well.

I think I cannot approve this change though ;)

Thanks,
Richard.

Patch ping

[Zdenek Dvorak]

Hello,

http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01495.html

> estimate_num_insns is currently used for several things:
> 
> -- on several places (loop unrolling, unswitching, exception
>    handling expansion), to estimate the size of the code
> -- in prefetching, to estimate time necessary to execute the
>    code
> -- in inlining for magic heuristic (that pretends to do the
>    former, but in fact turns out to be closer to the latter)
> 
> Not surprisingly, it cannot work well enough for all these usages
> (in particular, the optimizations that rely on it being the size of
> the code suffer by the unrealistical values returned for calls and
> divisions).  This patch makes it possible to select which of these
> three estimates should be returned (by passing the structure containing
> costs of various constructs to it).

Zdenek

Re: Patch Ping

[Mark Mitchell]

Tom Tromey wrote:
> Could someone review this please?
> 
> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01584.html
> 
> It changes gcov to consistently use get_gcov_unsigned_t(), instead of
> relying on unsigned_type_node, which gcj does not define.

This is OK.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Patch Ping

[Tom Tromey]

Could someone review this please?

http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01584.html

It changes gcov to consistently use get_gcov_unsigned_t(), instead of
relying on unsigned_type_node, which gcj does not define.

Tom

Patch ping

[Zdenek Dvorak]

Hello,

http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01424.html
  -- patch for PR 23855, to produce more efficient and
     easier to optimize code for nested for-loops

http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00345.html
  -- makes affine combinations use the new double_int
     infrastructure

Zdenek

Re: Patch ping

[Steve Ellcey]

> Grrr!  I was most of the way through an IA-64 bootstrap of a fix
> (along the lines of Andrew Pinski's suggestion), when someone at
> OpenEye decided to switch off the SGI Altix box I was using (as
> the air conditioning in the machine room just gave up).
> 
> I suspect (hope?) that someone will post/commit a fix soon, but
> if not I'll get back to it once my Itanium boxes are back online.
> 
> Roger
> --

Roger,

I did a bootstrap by just removing the last 'if (p_false) free
(p_false);' like Grigory suggested and that builds but of course it
reintroduces the memory leak.  When I did a 'if (predicable_false) free
(predicable_false);' before setting predicable_false, I got the
following warning that becomes an error when we use -Werror later in the
bootstrap:

gcc/gensupport.c: In function 'identify_predicable_attribute':
gcc/gensupport.c:478: warning: passing argument 1 of 'free' discards qualifiers from pointer target type

The declaration of predicable_false is:

	static const char *predicable_false;

I am not sure how to address that.

Steve Ellcey
sje@cup.hp.com

Re: Patch ping

[Grigory Zagorodnev]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

Steve Ellcey wrote:
> I think that this patch may be breaking the IA64 bootstrap (HP-UX and
> I am guessing this may be related to the change made to
> identify_predicable_attribute.  Is anyone seeing this?

Hi!
I do see the same on ia64 trunk builds since this commit. Arm build 
failures are expected as well because attribute "predicable" is used 
there too.

It seems to be wrong to free p_false memory at the end of 
'identify_predicable_attribute' routine when it returns with success - 
the pointer is assigned to predicable_true and predicable_false 
variables for the future use. Therefore there is no memory leak.

The fix is just back out a part of original commit. Do you think it is ok?

- Grigory

[-- Attachment #2: gensupport.c.patch --]
[-- Type: text/plain, Size: 366 bytes --]

Index: gcc/gensupport.c
===================================================================
--- gcc/gensupport.c	(revision 112077)
+++ gcc/gensupport.c	(working copy)
@@ -511,9 +511,6 @@ identify_predicable_attribute (void)
 			 value);
       errors = 1;
     }
-
-  if (p_false)
-    free (p_false);
 }
 
 /* Return the number of alternatives in constraint S.  */

Re: Patch ping

[Andreas Schwab]

Uttam Pawar <uttamp@us.ibm.com> writes:

> *************** identify_predicable_attribute (void)
> *** 501,506 ****
> --- 507,515 ----
>                          value);
>         errors = 1;
>       }
> +
> +   if (p_false)
> +     free (p_false);
>   }

This is broken.  Checked in this patch as obvious fix to the bootstrap
failure.

Andreas.

2006-03-15  Andreas Schwab  <schwab@suse.de>

	* gensupport.c (identify_predicable_attribute): Don't free p_false
	when it is still in use.

Index: gcc/gensupport.c
===================================================================
--- gcc/gensupport.c	(revision 112080)
+++ gcc/gensupport.c	(working copy)
@@ -510,10 +510,9 @@ identify_predicable_attribute (void)
 			 "unknown value `%s' for `predicable' attribute",
 			 value);
       errors = 1;
+      if (p_false)
+	free (p_false);
     }
-
-  if (p_false)
-    free (p_false);
 }
 
 /* Return the number of alternatives in constraint S.  */

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Patch ping

[Roger Sayle]

On Tue, 14 Mar 2006, Steve Ellcey wrote:
> > 2006-03-13  Uttam Pawar  <uttamp@us.ibm.com>
> >
> >         * gensupport.c (identify_predicable_attribute): Free
> >         p_false pointer.
> >         * gcov.c (create_file_names): Free name pointer.
> >
> >         PR rtl-optimization/25739
> >         * bt-load.c (augment_live_range): Free tos pointer.
>
> I think that this patch may be breaking the IA64 bootstrap (HP-UX and
> Linux).  It is dying with:
>
> build/genmddeps /proj/opensrc/nightly/src/trunk/gcc/config/ia64/ia64.md > tmp-mddeps
> /proj/opensrc/nightly/src/trunk/gcc/config/ia64/ia64.md:792: unknown value `no' for `predicable' attribute
> /proj/opensrc/nightly/src/trunk/gcc/config/ia64/ia64.md:1992: unknown value `no' for `predicable' attribute
>
> (and a bunch more)
>
> I am guessing this may be related to the change made to
> identify_predicable_attribute.  Is anyone seeing this?

Grrr!  I was most of the way through an IA-64 bootstrap of a fix
(along the lines of Andrew Pinski's suggestion), when someone at
OpenEye decided to switch off the SGI Altix box I was using (as
the air conditioning in the machine room just gave up).

I suspect (hope?) that someone will post/commit a fix soon, but
if not I'll get back to it once my Itanium boxes are back online.

Roger
--

Re: Patch ping

[Andrew Pinski]

On Mar 14, 2006, at 11:49 AM, Steve Ellcey wrote:
> I am guessing this may be related to the change made to
> identify_predicable_attribute.  Is anyone seeing this?

No but it does look wrong.

   predicable_false = p_false;

So it is not leaked at the end of the function but rather when it is 
replaced.
Maybe doing a free right before the assignment to predicable_false and 
removing
the free at the end of identify_predicable_attribute will keep the leak 
fixed
and fix the bootstrap bug.

-- Pinski

Re: Patch ping

[Steve Ellcey]

> 2006-03-13  Uttam Pawar  <uttamp@us.ibm.com>
> 
>         * gensupport.c (identify_predicable_attribute): Free
>         p_false pointer.
>         * gcov.c (create_file_names): Free name pointer.
> 
>         PR rtl-optimization/25739
>         * bt-load.c (augment_live_range): Free tos pointer.

I think that this patch may be breaking the IA64 bootstrap (HP-UX and
Linux).  It is dying with:

build/genmddeps /proj/opensrc/nightly/src/trunk/gcc/config/ia64/ia64.md > tmp-mddeps
/proj/opensrc/nightly/src/trunk/gcc/config/ia64/ia64.md:792: unknown value `no' for `predicable' attribute
/proj/opensrc/nightly/src/trunk/gcc/config/ia64/ia64.md:1992: unknown value `no' for `predicable' attribute

(and a bunch more)

I am guessing this may be related to the change made to
identify_predicable_attribute.  Is anyone seeing this?

Steve Ellcey
sje@cup.hp.com

Re: Patch ping

[Roger Sayle]

On Mon, 13 Mar 2006, Uttam Pawar wrote:
> Here is a complete patch again. This has been regtest on powerpc64-linux
> with no new regressions.  If it looks ok, could you commit it please, as
> I do not have commit access.

No problem.  Committed to mainline as revision 112039.

Thanks,

Roger
--

Re: Patch ping

[Uttam Pawar]

Roger,

Thanks for reviewing the patches and for your feedback.

> The bt-load.c fix is OK, to close PR rtl-optimiztion/25739.
> I think the other changes are suitably obvious enough, even if
> not part of the middle-end, that I can approve them.  Remember
> to commit the version with the "if" checks before the calls to
> free, and mention the above PR number in the ChangeLog entry.

Here is a complete patch again. This has been regtest on powerpc64-linux
with no new regressions.
If it looks ok, could you commit it please, as I do not have commit
access.

Thanks,

Uttam

2006-03-13  Uttam Pawar  <uttamp@us.ibm.com>

        * gensupport.c (identify_predicable_attribute): Free
        p_false pointer.
        * gcov.c (create_file_names): Free name pointer.

        PR rtl-optimization/25739
        * bt-load.c (augment_live_range): Free tos pointer.

Index: gcc/gensupport.c
===================================================================
*** gcc/gensupport.c    (revision 111144)
--- gcc/gensupport.c    (working copy)
*************** identify_predicable_attribute (void)
*** 464,469 ****
--- 464,471 ----
        message_with_line (elem->lineno,
                         "attribute `predicable' is not a boolean");
        errors = 1;
+       if (p_false)
+         free (p_false);
        return;
      }
    p_true[-1] = '\0';
*************** identify_predicable_attribute (void)
*** 481,492 ****
--- 483,498 ----
        message_with_line (elem->lineno,
                         "attribute `predicable' cannot be const");
        errors = 1;
+       if (p_false)
+         free (p_false);
        return;

      default:
        message_with_line (elem->lineno,
                         "attribute `predicable' must have a constant default");
        errors = 1;
+       if (p_false)
+         free (p_false);
        return;
      }

*************** identify_predicable_attribute (void)
*** 501,506 ****
--- 507,515 ----
                         value);
        errors = 1;
      }
+
+   if (p_false)
+     free (p_false);
  }

  /* Return the number of alternatives in constraint S.  */
Index: gcc/gcov.c
===================================================================
*** gcc/gcov.c  (revision 111144)
--- gcc/gcov.c  (working copy)
*************** create_file_names (const char *file_name
*** 658,663 ****
--- 658,664 ----
    strcpy (da_file_name, name);
    strcpy (da_file_name + length, GCOV_DATA_SUFFIX);

+   free (name);
    return;
  }

Index: gcc/bt-load.c
===================================================================
*** gcc/bt-load.c       (revision 111144)
--- gcc/bt-load.c       (working copy)
*************** augment_live_range (bitmap live_range, H
*** 911,916 ****
--- 911,917 ----
        {
          if (full_range)
            IOR_HARD_REG_SET (*btrs_live_in_range, btrs_live[new_bb->index]);
+         free (tos);
          return;
        }
        *tos++ = new_bb;

Re: Patch ping

[Roger Sayle]

On Fri, 10 Mar 2006, Uttam Pawar wrote:
> Ping. Can anybody review the following patches again, please?
> http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01484.html

The bt-load.c fix is OK, to close PR rtl-optimiztion/25739.
I think the other changes are suitably obvious enough, even if
not part of the middle-end, that I can approve them.  Remember
to commit the version with the "if" checks before the calls to
free, and mention the above PR number in the ChangeLog entry.


> http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01377.html

This one is also OK for mainline.

Thanks,

Roger
--

Patch ping

[Uttam Pawar]

Ping. Can anybody review the following patches again, please?

http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01484.html

http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01377.html


- Uttam

Re: Patch ping

[Zdenek Dvorak]

Hello,

> On Wed, Feb 22, 2006 at 12:04:37AM +0100, Zdenek Dvorak wrote:
> > If w <= HOST_BITS_PER_WIDE_INT, the functions returns just CONST_INT, not
> > CONST_DOUBLE.  In this case, rule (b) -- filling bits above w with s --
> > is used.
> 
> Yep.
> 
> > Suppose now w > HOST_BITS_PER_WIDE_INT.  If i1 == 0 and i0 >=0, or
> > i1 == -1 and i1 < 0, we return CONST_INT for i0, anyway.
> 
> Sure.  It saves memory.
> 
> > Otherwise, the components i0 and i1 are put into the constant unchanged.
> 
> Note that there exists no rtl mode for which w > HBPWI and w < 2*HBPWI.
> That is, if w > HBPWI, then w == 2*HBPWI.  So the point you're trying to
> make here doesn't actually apply, so rule (b) continues to hold.

ehm... immed_double_const would really need clean up, and pruning of
completely missleading comments... I will send patch once it passes
testing.

Anyway, here is the patch for double_ints with rule (b).

Zdenek

	* gengtype.c (main): Handle double_int type.
	* tree.h (struct tree_int_cst): Make type of int_cst double_int.
	* doubleint.c: New file.
	* doubleint.h: New file.
	* system.h: Include doubleint.h.
	* Makefile.in (SYSTEM_H): Include doubleint.
	(doubleint.o): Add.

Index: gengtype.c
===================================================================
*** gengtype.c	(revision 111309)
--- gengtype.c	(working copy)
*************** main(int ARG_UNUSED (argc), char ** ARG_
*** 3037,3042 ****
--- 3037,3043 ----
  
    do_scalar_typedef ("CUMULATIVE_ARGS", &pos);
    do_scalar_typedef ("REAL_VALUE_TYPE", &pos);
+   do_scalar_typedef ("double_int", &pos);
    do_scalar_typedef ("uint8", &pos);
    do_scalar_typedef ("jword", &pos);
    do_scalar_typedef ("JCF_u2", &pos);
Index: tree.h
===================================================================
*** tree.h	(revision 111309)
--- tree.h	(working copy)
*************** extern void omp_clause_range_check_faile
*** 1239,1251 ****
  struct tree_int_cst GTY(())
  {
    struct tree_common common;
!   /* A sub-struct is necessary here because the function `const_hash'
!      wants to scan both words as a unit and taking the address of the
!      sub-struct yields the properly inclusive bounded pointer.  */
!   struct tree_int_cst_lowhi {
!     unsigned HOST_WIDE_INT low;
!     HOST_WIDE_INT high;
!   } int_cst;
  };
  
  /* In a REAL_CST node.  struct real_value is an opaque entity, with
--- 1239,1245 ----
  struct tree_int_cst GTY(())
  {
    struct tree_common common;
!   double_int int_cst;
  };
  
  /* In a REAL_CST node.  struct real_value is an opaque entity, with
Index: doubleint.c
===================================================================
*** doubleint.c	(revision 0)
--- doubleint.c	(revision 0)
***************
*** 0 ****
--- 1,298 ----
+ /* Operations with long integers.
+    Copyright (C) 2006 Free Software Foundation, Inc.
+    
+ This file is part of GCC.
+    
+ GCC is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the
+ Free Software Foundation; either version 2, or (at your option) any
+ later version.
+    
+ GCC is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ for more details.
+    
+ You should have received a copy of the GNU General Public License
+ along with GCC; see the file COPYING.  If not, write to the Free
+ Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
+ 02110-1301, USA.  */
+ 
+ #include "config.h"
+ #include "system.h"
+ #include "coretypes.h"
+ #include "tm.h"
+ #include "tree.h"
+ 
+ /* Restricts constant CST to the precision given by MASK.  */
+ 
+ static inline double_int
+ restrict_cst_to_precision (double_int mask, double_int cst)
+ {
+   double_int r;
+   bool negative;
+   unsigned HOST_WIDE_INT sbit, snum;
+  
+   /* Copy the sign bit to the bits outside of mask.  */
+   if (DI_HIGH (mask))
+     {
+       sbit = (DI_HIGH (mask) >> 1) + 1;
+       snum = DI_HIGH (cst);
+     }
+   else
+     {
+       sbit = (DI_LOW (mask) >> 1) + 1;
+       snum = DI_LOW (cst);
+     }
+   negative = (snum & sbit) != 0;
+ 
+   if (negative)
+     {
+       DI_LOW_SET (r, DI_LOW (cst) | ~DI_LOW (mask));
+       DI_HIGH_SET (r, DI_HIGH (cst) | ~DI_HIGH (mask));
+     }
+   else
+     {
+       DI_LOW_SET (r, DI_LOW (cst) & DI_LOW (mask));
+       DI_HIGH_SET (r, DI_HIGH (cst) & DI_HIGH (mask));
+     }
+ 
+   return r;
+ }
+ 
+ /* Zeros bits of CST outside of MASK.  */
+ 
+ static inline double_int
+ zero_excess_bits (double_int mask, double_int cst)
+ {
+   double_int r;
+  
+   DI_LOW_SET (r, DI_LOW (cst) & DI_LOW (mask));
+   DI_HIGH_SET (r, DI_HIGH (cst) & DI_HIGH (mask));
+ 
+   return r;
+ }
+ 
+ /* Constructs double_int from tree CST.  */
+ 
+ double_int
+ tree_to_double_int (tree cst)
+ {
+   tree type = TREE_TYPE (cst);
+   double_int mask = double_int_mask (TYPE_PRECISION (type));
+   return restrict_cst_to_precision (mask, TREE_INT_CST (cst));
+ }
+ 
+ /* Returns true if X fits in HOST_WIDE_INT.  */
+ 
+ bool
+ double_int_fits_in_hwi_p (double_int x)
+ {
+   return ((DI_HIGH (x) == 0 && (HOST_WIDE_INT) DI_LOW (x) >= 0)
+ 	  || (DI_HIGH (x) == ALL_ONES && (HOST_WIDE_INT) DI_LOW (x) < 0));
+ }
+ 
+ /* Returns true if X fits in unsigned HOST_WIDE_INT.  */
+ 
+ bool
+ double_int_fits_in_unsigned_hwi_p (double_int x)
+ {
+   return DI_HIGH (x) == 0;
+ }
+ 
+ /* Returns true if SCALE is negative.  */
+ 
+ bool
+ double_int_negative_p (double_int scale)
+ {
+   return (HOST_WIDE_INT) DI_HIGH (scale) < 0;
+ }
+ 
+ /* Returns value of X as a signed number.  X must satisfy
+    double_int_fits_in_hwi_p.  */
+ 
+ HOST_WIDE_INT
+ double_int_to_hwi (double_int x)
+ {
+   return DI_LOW (x);
+ }
+ 
+ /* Returns value of X as an unsigned number.  X must satisfy
+    double_int_fits_in_unsigned_hwi_p.  */
+ 
+ unsigned HOST_WIDE_INT
+ double_int_to_unsigned_hwi (double_int x)
+ {
+   return DI_LOW (x);
+ }
+ 
+ /* Returns A * B, in precision given by MASK.  */
+ 
+ double_int
+ double_int_mul (double_int mask, double_int a, double_int b)
+ {
+   unsigned HOST_WIDE_INT lo;
+   HOST_WIDE_INT hi;
+   double_int ret;
+ 
+   mul_double (DI_LOW (a), DI_HIGH (a),
+ 	      DI_LOW (b), DI_HIGH (b), &lo, &hi);
+   DI_LOW_SET (ret, lo);
+   DI_HIGH_SET (ret, hi);
+ 
+   return restrict_cst_to_precision (mask, ret);
+ }
+ 
+ /* Returns A + B, in precision given by MASK.  */
+ 
+ double_int
+ double_int_add (double_int mask, double_int a, double_int b)
+ {
+   unsigned HOST_WIDE_INT lo;
+   HOST_WIDE_INT hi;
+   double_int ret;
+ 
+   add_double (DI_LOW (a), DI_HIGH (a),
+ 	      DI_LOW (b), DI_HIGH (b), &lo, &hi);
+   DI_LOW_SET (ret, lo);
+   DI_HIGH_SET (ret, hi);
+ 
+   return restrict_cst_to_precision (mask, ret);
+ }
+ 
+ /* Returns -A, in precision given by MASK.  */
+ 
+ double_int
+ double_int_negate (double_int mask, double_int a)
+ {
+   unsigned HOST_WIDE_INT lo;
+   HOST_WIDE_INT hi;
+   double_int ret;
+ 
+   neg_double (DI_LOW (a), DI_HIGH (a), &lo, &hi);
+   DI_LOW_SET (ret, lo);
+   DI_HIGH_SET (ret, hi);
+ 
+   return restrict_cst_to_precision (mask, ret);
+ }
+ 
+ /* Returns A / B (computed as unsigned in precision given by MASK, rounded
+    down).  */
+ 
+ double_int
+ double_int_divide (double_int mask, double_int a, double_int b)
+ {
+   unsigned HOST_WIDE_INT lo, rem_lo;
+   HOST_WIDE_INT hi, rem_hi;
+   double_int ret;
+ 
+   a = zero_excess_bits (mask, a);
+   b = zero_excess_bits (mask, b);
+   div_and_round_double (FLOOR_DIV_EXPR, true,
+ 			DI_LOW (a), DI_HIGH (a),
+ 			DI_LOW (b), DI_HIGH (b),
+ 			&lo, &hi, &rem_lo, &rem_hi);
+   DI_LOW_SET (ret, lo);
+   DI_HIGH_SET (ret, hi);
+ 
+   return restrict_cst_to_precision (mask, ret);
+ }
+ 
+ /* Constructs tree in type TYPE from with value given by CST (precision of CST
+    is the same as the precision of TYPE).  */
+ 
+ tree
+ double_int_to_tree (tree type, double_int cst)
+ {
+   unsigned HOST_WIDE_INT lo = DI_LOW (cst);
+   HOST_WIDE_INT hi = DI_HIGH (cst);
+ 
+   if (TYPE_UNSIGNED (type))
+     cst = zero_excess_bits (double_int_mask (TYPE_PRECISION (type)), cst);
+   return build_int_cst_wide (type, lo, hi);
+ }
+ 
+ /* Returns true if A < B, unsigned comparison, in precision given by MASK.  */
+ 
+ bool
+ double_int_smaller_p (double_int mask, double_int a, double_int b)
+ {
+   a = zero_excess_bits (mask, a);
+   b = zero_excess_bits (mask, b);
+   if (DI_HIGH (a) < DI_HIGH (b))
+     return true;
+   if (DI_HIGH (a) > DI_HIGH (b))
+     return false;
+   return DI_LOW (a) < DI_LOW (b);
+ }
+ 
+ /* Splits last digit of *X (taken as unsigned in precision
+    of 2 * HOST_BITS_PER_WIDE_INT bits) in BASE and returns it.  */
+ 
+ static unsigned
+ double_int_split_digit (double_int *x, unsigned base)
+ {
+   unsigned HOST_WIDE_INT resl, reml;
+   HOST_WIDE_INT resh, remh;
+ 
+   div_and_round_double (FLOOR_DIV_EXPR, true, x->low, x->high, base, 0,
+ 			&resl, &resh, &reml, &remh);
+   x->high = resh;
+   x->low = resl;
+ 
+   return reml;
+ }
+ 
+ /* Dumps X (in precision given by MASK) to FILE.  If SIGN is true, X is
+    considered to be signed.  */
+ 
+ void
+ dump_double_int (FILE *file, double_int mask, double_int x, bool sign)
+ {
+   unsigned digits[100], n;
+   int i;
+ 
+   if (double_int_zero_p (x))
+     {
+       fprintf (file, "0");
+       return;
+     }
+ 
+   if (double_int_negative_p (x))
+     {
+       if (sign)
+ 	{
+ 	  fprintf (file, "-");
+ 	  x = double_int_negate (mask, x);
+ 	}
+       else
+ 	x = zero_excess_bits (mask, x);
+     }
+ 
+   for (n = 0; !double_int_zero_p (x); n++)
+     digits[n] = double_int_split_digit (&x, 10);
+   for (i = n - 1; i >= 0; i--)
+     fprintf (file, "%u", digits[i]);
+ }
+ 
+ /* Returns a MASK for precision of PREC bits.  */
+ 
+ double_int 
+ double_int_mask (unsigned prec)
+ {
+   double_int mask;
+ 
+   if (prec > HOST_BITS_PER_WIDE_INT)
+     {
+       prec -= HOST_BITS_PER_WIDE_INT;
+       DI_HIGH_SET (mask, (((unsigned HOST_WIDE_INT) 2 << (prec - 1)) - 1));
+       DI_LOW_SET (mask, ~(unsigned HOST_WIDE_INT) 0);
+     }
+   else
+     {
+       DI_HIGH_SET (mask, 0);
+       DI_LOW_SET (mask, (((unsigned HOST_WIDE_INT) 2 << (prec - 1)) - 1));
+     }
+ 
+   return mask;
+ }
Index: doubleint.h
===================================================================
*** doubleint.h	(revision 0)
--- doubleint.h	(revision 0)
***************
*** 0 ****
--- 1,126 ----
+ /* Operations with long integers.
+    Copyright (C) 2006 Free Software Foundation, Inc.
+    
+ This file is part of GCC.
+    
+ GCC is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the
+ Free Software Foundation; either version 2, or (at your option) any
+ later version.
+    
+ GCC is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ for more details.
+    
+ You should have received a copy of the GNU General Public License
+ along with GCC; see the file COPYING.  If not, write to the Free
+ Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
+ 02110-1301, USA.  */
+ 
+ #ifndef DOUBLE_INT_H
+ #define DOUBLE_INT_H
+ 
+ /* A large integer.  The precision of the represented number is between
+    1 and 2 * HOST_BITS_PER_WIDE_INT and it must be provided in each
+    operation in form of mask that prescribes the significant bits
+    (such mask is also double_int and can be obtained using
+    double_int_mask).  Signedness is only relevant for some operations
+    (comparisons, division), in these cases the description of
+    the function states whether the numbers are assumed to be signed
+    or unsigned.  The bits outside of the precision of the number are
+    set to be equal to the sign bit, for compatibility with rtl
+    representation (and tree representation of numbers in signed types;
+    in unsigned ones, such bits are zeroed).  */
+ 
+ typedef struct
+ {
+   unsigned HOST_WIDE_INT low;
+   HOST_WIDE_INT high;	/* High is signed for historical reasons (it replaces
+ 			   a similar structure that was used previously).  It
+ 			   makes manipulation with the numbers more cumbersome,
+ 			   so it would be nice to change it.  */
+ } double_int;
+ #define DI_LOW(X) (X).low
+ #define DI_HIGH(X) ((unsigned HOST_WIDE_INT) (X).high)
+ #define DI_LOW_SET(X, L) ((X).low = (unsigned HOST_WIDE_INT) (L))
+ #define DI_HIGH_SET(X, L) ((X).high = (HOST_WIDE_INT) (L))
+ #define ALL_ONES (~((unsigned HOST_WIDE_INT) 0))
+ 
+ union tree_node;
+ 
+ union tree_node *double_int_to_tree (union tree_node *, double_int);
+ double_int tree_to_double_int (union tree_node *tree);
+ bool double_int_fits_in_hwi_p (double_int);
+ HOST_WIDE_INT double_int_to_hwi (double_int);
+ bool double_int_fits_in_unsigned_hwi_p (double_int);
+ unsigned HOST_WIDE_INT double_int_to_unsigned_hwi (double_int);
+ double_int double_int_mul (double_int, double_int, double_int);
+ double_int double_int_add (double_int, double_int, double_int);
+ double_int double_int_negate (double_int, double_int);
+ double_int double_int_divide (double_int, double_int, double_int);
+ bool double_int_negative_p (double_int);
+ bool double_int_smaller_p (double_int, double_int, double_int);
+ void dump_double_int (FILE *, double_int, double_int, bool);
+ double_int double_int_mask (unsigned);
+ 
+ /* Constructs double_int from integer CST.  Note that this number may need to
+    be masked for a given precison in order to be valid.  */
+ 
+ static inline double_int
+ hwi_to_double_int (HOST_WIDE_INT cst)
+ {
+   double_int r;
+   
+   DI_LOW_SET (r, cst);
+   DI_HIGH_SET (r, cst < 0 ? ALL_ONES : 0);
+ 
+   return r;
+ }
+ 
+ /* Constructs mask with all bits 1.  */
+ 
+ static inline double_int
+ double_int_all (void)
+ {
+   double_int r;
+ 
+   DI_LOW_SET (r, ALL_ONES);
+   DI_HIGH_SET (r, ALL_ONES);
+ 
+   return r;
+ }
+ 
+ /* Returns true if CST is zero.  */
+ 
+ static inline bool
+ double_int_zero_p (double_int cst)
+ {
+   return DI_LOW (cst) == 0 && DI_HIGH (cst) == 0;
+ }
+ 
+ /* Returns true if CST is one.  */
+ 
+ static inline bool
+ double_int_one_p (double_int cst)
+ {
+   return DI_LOW (cst) == 1 && DI_HIGH (cst) == 0;
+ }
+ 
+ /* Returns true if CST is minus one.  */
+ 
+ static inline bool
+ double_int_minus_one_p (double_int cst)
+ {
+   return (DI_LOW (cst) == ALL_ONES && DI_HIGH (cst) == ALL_ONES);
+ }
+ 
+ /* Returns true if CST1 == CST2.  */
+ 
+ static inline bool
+ double_int_equal_p (double_int cst1, double_int cst2)
+ {
+   return DI_LOW (cst1) == DI_LOW (cst2) && DI_HIGH (cst1) == DI_HIGH (cst2);
+ }
+ 
+ #endif /* DOUBLE_INT_H */
Index: system.h
===================================================================
*** system.h	(revision 111309)
--- system.h	(working copy)
*************** extern void fancy_abort (const char *, i
*** 609,614 ****
--- 609,616 ----
  # define FALSE false
  #endif /* !__cplusplus */
  
+ /* Get definition of double_int.  */
+ #include "doubleint.h"
  
  /* Some compilers do not allow the use of unsigned char in bitfields.  */
  #define BOOL_BITFIELD unsigned int
Index: Makefile.in
===================================================================
*** Makefile.in	(revision 111309)
--- Makefile.in	(working copy)
*************** INSN_ATTR_H = insn-attr.h $(srcdir)/insn
*** 773,779 ****
  C_COMMON_H = c-common.h $(SPLAY_TREE_H) $(CPPLIB_H) $(GGC_H)
  C_PRAGMA_H = c-pragma.h $(CPPLIB_H)
  C_TREE_H = c-tree.h $(C_COMMON_H) toplev.h $(DIAGNOSTIC_H)
! SYSTEM_H = system.h hwint.h $(srcdir)/../include/libiberty.h
  PREDICT_H = predict.h predict.def
  CPPLIB_H = $(srcdir)/../libcpp/include/line-map.h \
  	$(srcdir)/../libcpp/include/cpplib.h
--- 773,779 ----
  C_COMMON_H = c-common.h $(SPLAY_TREE_H) $(CPPLIB_H) $(GGC_H)
  C_PRAGMA_H = c-pragma.h $(CPPLIB_H)
  C_TREE_H = c-tree.h $(C_COMMON_H) toplev.h $(DIAGNOSTIC_H)
! SYSTEM_H = system.h hwint.h doubleint.h $(srcdir)/../include/libiberty.h
  PREDICT_H = predict.h predict.def
  CPPLIB_H = $(srcdir)/../libcpp/include/line-map.h \
  	$(srcdir)/../libcpp/include/cpplib.h
*************** prefix.o: prefix.c $(CONFIG_H) $(SYSTEM_
*** 1779,1784 ****
--- 1779,1786 ----
  convert.o: convert.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) \
     $(FLAGS_H) convert.h toplev.h langhooks.h real.h
  
+ doubleint.o: doubleint.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H)
+ 
  langhooks.o : langhooks.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \
     $(TREE_H) toplev.h $(TREE_INLINE_H) $(RTL_H) insn-config.h $(INTEGRATE_H) \
     langhooks.h $(LANGHOOKS_DEF_H) $(FLAGS_H) $(GGC_H) $(DIAGNOSTIC_H) intl.h \

Re: Patch ping

[Richard Henderson]

On Wed, Feb 22, 2006 at 12:04:37AM +0100, Zdenek Dvorak wrote:
> If w <= HOST_BITS_PER_WIDE_INT, the functions returns just CONST_INT, not
> CONST_DOUBLE.  In this case, rule (b) -- filling bits above w with s --
> is used.

Yep.

> Suppose now w > HOST_BITS_PER_WIDE_INT.  If i1 == 0 and i0 >=0, or
> i1 == -1 and i1 < 0, we return CONST_INT for i0, anyway.

Sure.  It saves memory.

> Otherwise, the components i0 and i1 are put into the constant unchanged.

Note that there exists no rtl mode for which w > HBPWI and w < 2*HBPWI.
That is, if w > HBPWI, then w == 2*HBPWI.  So the point you're trying to
make here doesn't actually apply, so rule (b) continues to hold.


r~

Re: Patch ping

[Zdenek Dvorak]

Hello,

> On Tue, Feb 21, 2006 at 04:43:17PM +0100, Zdenek Dvorak wrote:
> > yes, this is about the only real advantage of the representation (b).
> 
> The fact that rtl uses (b) for its const_int lends support for using
> that representation elsewhere.  It's surely less confusing to have 
> one rule instead of two.

rtl (function immed_double_const) usses the following rules:
the function takes two HOST_WIDE_INTs i0 and i1 (where i1 corresponds to higher
bits).  Let w be precision of the mode of the constructed constant, and
s the sign bit of the represented number (i.e. the one at position
1 << (w - 1)).

If w <= HOST_BITS_PER_WIDE_INT, the functions returns just CONST_INT, not
CONST_DOUBLE.  In this case, rule (b) -- filling bits above w with s --
is used.

Suppose now w > HOST_BITS_PER_WIDE_INT.  If i1 == 0 and i0 >=0, or
i1 == -1 and i1 < 0, we return CONST_INT for i0, anyway.

Otherwise, the components i0 and i1 are put into the constant unchanged.

In particular, this means that the rtl semantics allows multiple
representations for the same number, in case
HOST_BITS_PER_WIDE_INT < w < 2 * HOST_BITS_PER_WIDE_INT.

I do not really have very strong preferences whether to use semantics
(a) or (b), as long as we do not use the semantics we use for rtl :-)
I slightly prefer (a), as

1) normalization is slightly simpler
2) it is the more senseful one if the components of double_int are
   manipulated as unsigned numbers (which I prefer as it makes it
   less likely to run into problems with undefined semantics of
   overflow for signed types).

Zdenek

patch Ping

[Uttam Pawar]

ping,

1) http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01377.html, this is for pr# 26327

2) http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01485.html


Thanks,

Re: Patch ping

[Richard Henderson]

On Tue, Feb 21, 2006 at 04:43:17PM +0100, Zdenek Dvorak wrote:
> yes, this is about the only real advantage of the representation (b).

The fact that rtl uses (b) for its const_int lends support for using
that representation elsewhere.  It's surely less confusing to have 
one rule instead of two.


r~

Re: Patch ping

[Zdenek Dvorak]

Hello,

> I believe that the last sixty years of digital computation have
> decisively shown the superiority of two's complement arithmetic
> for representing signed integers as binary, and convenient for
> interconversion with unsigned values.

yes, this is why I have chosen to use it (well, why I haven't considered
any other in the first place).

> You should treat double_int like you would a TImode.  For example, -1
> should be represented by both the high an low words containing all one
> bits.

This is quite orthogonal issue to whether to use two's complement
arithmetic or something else.  As far as I understand, this is the
main point of your objection, so I will focus on it.  There are several
basic properties I want double_int to satisfy:

1) it is possible to represent numbers with smaller precision than
   2 * HOST_BITS_PER_WIDE_INT
2) it is not neccessary to distinguish between signed and unsigned
   values in functions that perform arithmetics modulo 2^precision
   (+, -, *, negation,...)
3) each number has only one possible representation.

I will for now assume that we agree on that these are desirable; if not,
I will present my arguments on this issue in the followup mail(s).

1) and 3) leave us with basically three choices of how to represent the
numbers; avoiding long explanation, let us demonstrate these on
examples, say we want to represent 8-bit values:

-- (a):
   unsigned 127 = signed 127 = {0, 127}
   unsigned 255 = signed -1 = {0, 255}
-- (b)
   unsigned 127 = signed 127 = {0, 127}
   unsigned 255 = signed -1 = {-1, -1}
-- (c)
   unsigned 127 = signed 127 = {0, 127}
   unsigned 255 = {0,255}
   signed -1 = {-1, -1}

My choice is (a).  Your choice seems to be either (b) or (c), you are
not quite clear about it.  By property 2, it would be nice for signed
and unsigned numbers with the same precision to have the same
representation (use the same range of numbers); this leaves only (a) and
(b) as possibilities.

Regardless of the choice, because of 3) you need to have some normalization of the
results of the operation -- e.g., in representation (b), 127 + 127 = 254 = {-1, -2},
but add_double would return {0,254}.  In representation (a), -1 + -1 = -2 = {0,254},
but add_double would return {0, 510}.

For (a), this normalization is X & MASK.  For (b), it is
if (X & (1<< (prec - 1)) == 0) ? X & MASK : X | ~MASK.
Between (a) and (b), I have chosen (a) as the normalization is simpler.

> + /* Returns true if CST is minus one in precision of MASK.  */
> +
> + static inline bool
> + double_int_minus_one_p (double_int mask, double_int cst)
> + {
> +   return (DI_LOW (cst) == DI_LOW (mask)
> + 	  && DI_HIGH (cst) == DI_HIGH (mask));
> + }
> 
> Then you wouldn't need a mask to test for minus one!
>
> + /* Returns true if SCALE is negative in precision of MASK.  */
> +
> + bool
> + double_int_negative_p (double_int mask, double_int scale)
> + {
> +   if (DI_HIGH (mask))
> +     return (DI_HIGH (scale) & ~(DI_HIGH (mask) >> 1)) != 0;
> +   else
> +     return (DI_LOW (scale) & ~(DI_LOW (mask) >> 1)) != 0;
> + }
> 
> And you wouldn't have to do pass in a mask to determine whether
> a value is negative.

yes, this is about the only real advantage of the representation (b).

> You would be able to implement a signed comparison, which is
> not so mysteriously missing from from your patch.

You would still need to distinguish between signed and unsigned versions
of the comparison, at the very least for numbers whose precision is
exactly 2 * HOST_BITS_PER_WIDE_INT.

The reason I do not implement signed comparison is that I do not need it
anywhere, not because it would be somehow fundamentally harder than the
unsigned case.

> But most importantly....
> 
> +   mul_double (DI_LOW (a), DI_HIGH (a),
> +               DI_LOW (b), DI_HIGH (b), &lo, &hi);
> ...
> +   add_double (DI_LOW (a), DI_HIGH (a),
> + 	      DI_LOW (b), DI_HIGH (b), &lo, &hi);
> ...
> +   neg_double (DI_LOW (a), DI_HIGH (a), &lo, &hi);
> ...
> +   div_and_round_double (FLOOR_DIV_EXPR, true,
> + 			DI_LOW (a), DI_HIGH (a),
> + 			DI_LOW (b), DI_HIGH (b),
> + 			&lo, &hi, &rem_lo, &rem_hi);
> 
> You'll now get the correct results out of all of these routines, which
> assume the same sign-extended two's complement representation of
> integers as used in the rest of the compiler, and the vast majority
> of the rest of the planet.

Regardless of whether the representation you choose is (a), (b), or (c),
you need to do some normalization of the result.  This is simplest for
(a) -- just mask out bits outside of the precision, more complicated for
(b) -- you need to do sign extension, and even more quite complex for (c)
(you need to distinguish between the signed and unsigned cases).

Zdenek

Re: Patch ping

[Roger Sayle]

Hi Zdenek,

On Tue, 21 Feb 2006, Zdenek Dvorak wrote:
>
> 	* gengtype.c (main): Handle double_int type.
> 	* tree.h (struct tree_int_cst): Make type of int_cst double_int.
> 	* doubleint.c: New file.
> 	* doubleint.h: New file.
> 	* system.h: Include doubleint.h.
> 	* Makefile.in (SYSTEM_H): Include doubleint.h.
> 	(doubleint.o): Add.

Hmmm, not quite.


> + /* A large integer.  The precision of the represented number is between
> +    1 and 2 * HOST_BITS_PER_WIDE_INT and it must be provided in each
> +    operation in form of mask that prescribes the significant bits
> +    (such mask is also double_int and can be obtained using
> +    double_int_mask).  Signedness is only relevant for some operations
> +    (comparisons, division), in these cases the description of
> +    the function states whether the numbers are assumed to be signed
> +    or unsigned.  */
> +
> + typedef struct
> + {
> +   unsigned HOST_WIDE_INT low;
> +   HOST_WIDE_INT high;	/* High is signed for historical reasons (it replaces
> + 			   a similar structure that was used previously).  It
> + 			   makes manipulation with the numbers more cumbersome,
> + 			   so it would be nice to change it.  */
> + } double_int;
> + #define DI_LOW(X) (X).low
> + #define DI_HIGH(X) ((unsigned HOST_WIDE_INT) (X).high)
> + #define DI_LOW_SET(X, L) ((X).low = (unsigned HOST_WIDE_INT) (L))
> + #define DI_HIGH_SET(X, L) ((X).high = (HOST_WIDE_INT) (L))


I believe that the last sixty years of digital computation have
decisively shown the superiority of two's complement arithmetic
for representing signed integers as binary, and convenient for
interconversion with unsigned values.  You should treat double_int
like you would a TImode.  For example, -1 should be represented by
both the high an low words containing all one bits.


+ /* Returns true if CST is minus one in precision of MASK.  */
+
+ static inline bool
+ double_int_minus_one_p (double_int mask, double_int cst)
+ {
+   return (DI_LOW (cst) == DI_LOW (mask)
+ 	  && DI_HIGH (cst) == DI_HIGH (mask));
+ }

Then you wouldn't need a mask to test for minus one!

+ /* Returns true if SCALE is negative in precision of MASK.  */
+
+ bool
+ double_int_negative_p (double_int mask, double_int scale)
+ {
+   if (DI_HIGH (mask))
+     return (DI_HIGH (scale) & ~(DI_HIGH (mask) >> 1)) != 0;
+   else
+     return (DI_LOW (scale) & ~(DI_LOW (mask) >> 1)) != 0;
+ }

And you wouldn't have to do pass in a mask to determine whether
a value is negative.

You would be able to implement a signed comparison, which is
not so mysteriously missing from from your patch.

But most importantly....

+   mul_double (DI_LOW (a), DI_HIGH (a),
+               DI_LOW (b), DI_HIGH (b), &lo, &hi);
...
+   add_double (DI_LOW (a), DI_HIGH (a),
+ 	      DI_LOW (b), DI_HIGH (b), &lo, &hi);
...
+   neg_double (DI_LOW (a), DI_HIGH (a), &lo, &hi);
...
+   div_and_round_double (FLOOR_DIV_EXPR, true,
+ 			DI_LOW (a), DI_HIGH (a),
+ 			DI_LOW (b), DI_HIGH (b),
+ 			&lo, &hi, &rem_lo, &rem_hi);

You'll now get the correct results out of all of these routines, which
assume the same sign-extended two's complement representation of
integers as used in the rest of the compiler, and the vast majority
of the rest of the planet.


The most bizarre thing is that all of the code that you want/need
to perform 2*HOST_WIDE_INT arithmetic is already in the compiler.



Perhaps I'm thinking about this all wrong.  Anyone whose done a
first-year Computer Science course would be aware of my side of
the argument above, and I'd hope its safe to say you'd be able
to predict these objections.  Maybe you could describe the benefits
of your novel approach?  Why not normalize mask to double_int_all,
which allows values to be represented independently of their
precision?


Roger
--

Re: Patch ping

[Zdenek Dvorak]

Hello,

> > While I agree on the code duplication issues, on the other hand, I like
> > the struct double_int much more than HOST_WIDE_INT pairs.
> >
> > Don't hold your breath, but if Zdenek's patch goes in I might work on
> > using his struct double_int in fold-const.c as well.  That's probably 4.3.
> 
> Ok, I see a plan...
> 
> The new double_int bears more than a passing similarity to tree.h's struct
> tree_int_cst_lowhi.  It looks like we already have a suitable double_int,
> we're just not using it as the basis of our low-level arithmetic routines.
> 
> Ok, Zdenek, it looks like the way to proceed is to break out all of
> your new wrappers into their own doubleint.h and doubleint.c, and
> to change tree.h:tree_int_cst.int_cst to be of type double_int as a
> single preparatory patch.  For compatability with the existing usage,
> you'll probably want to keep the high word signed.    Clearly these
> prototypes don't belong in tree-affine.h, and I'd prefer to leave
> hwint.h untouched so it can potentially be used in other projects
> (generator programs?) without a hwint.c (i.e. like longlong.h).

here is the proposed patch; bootstrapped & regtested on x86_64.

Zdenek

	* gengtype.c (main): Handle double_int type.
	* tree.h (struct tree_int_cst): Make type of int_cst double_int.
	* doubleint.c: New file.
	* doubleint.h: New file.
	* system.h: Include doubleint.h.
	* Makefile.in (SYSTEM_H): Include doubleint.h.
	(doubleint.o): Add.

Index: gengtype.c
===================================================================
*** gengtype.c	(revision 111309)
--- gengtype.c	(working copy)
*************** main(int ARG_UNUSED (argc), char ** ARG_
*** 3037,3042 ****
--- 3037,3043 ----
  
    do_scalar_typedef ("CUMULATIVE_ARGS", &pos);
    do_scalar_typedef ("REAL_VALUE_TYPE", &pos);
+   do_scalar_typedef ("double_int", &pos);
    do_scalar_typedef ("uint8", &pos);
    do_scalar_typedef ("jword", &pos);
    do_scalar_typedef ("JCF_u2", &pos);
Index: tree.h
===================================================================
*** tree.h	(revision 111309)
--- tree.h	(working copy)
*************** extern void omp_clause_range_check_faile
*** 1239,1251 ****
  struct tree_int_cst GTY(())
  {
    struct tree_common common;
!   /* A sub-struct is necessary here because the function `const_hash'
!      wants to scan both words as a unit and taking the address of the
!      sub-struct yields the properly inclusive bounded pointer.  */
!   struct tree_int_cst_lowhi {
!     unsigned HOST_WIDE_INT low;
!     HOST_WIDE_INT high;
!   } int_cst;
  };
  
  /* In a REAL_CST node.  struct real_value is an opaque entity, with
--- 1239,1245 ----
  struct tree_int_cst GTY(())
  {
    struct tree_common common;
!   double_int int_cst;
  };
  
  /* In a REAL_CST node.  struct real_value is an opaque entity, with
Index: doubleint.c
===================================================================
*** doubleint.c	(revision 0)
--- doubleint.c	(revision 0)
***************
*** 0 ****
--- 1,288 ----
+ /* Operations with long integers.
+    Copyright (C) 2006 Free Software Foundation, Inc.
+    
+ This file is part of GCC.
+    
+ GCC is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the
+ Free Software Foundation; either version 2, or (at your option) any
+ later version.
+    
+ GCC is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ for more details.
+    
+ You should have received a copy of the GNU General Public License
+ along with GCC; see the file COPYING.  If not, write to the Free
+ Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
+ 02110-1301, USA.  */
+ 
+ #include "config.h"
+ #include "system.h"
+ #include "coretypes.h"
+ #include "tm.h"
+ #include "tree.h"
+ 
+ /* Constructs double_int from tree CST.  */
+ 
+ double_int
+ tree_to_double_int (tree cst)
+ {
+   return TREE_INT_CST (cst);
+ }
+ 
+ /* Restricts constant CST to the precision given by MASK.  */
+ 
+ static inline double_int
+ restrict_cst_to_precision (double_int mask, double_int cst)
+ {
+   double_int r;
+   
+   DI_LOW_SET (r, DI_LOW (cst) & DI_LOW (mask));
+   DI_HIGH_SET (r, DI_HIGH (cst) & DI_HIGH (mask));
+ 
+   return r;
+ }
+ 
+ /* Returns true if X (whose precision is given by MASK) fits in
+    HOST_WIDE_INT.  */
+ 
+ bool
+ double_int_fits_in_hwi_p (double_int mask, double_int x)
+ {
+   if (double_int_negative_p (mask, x))
+     return DI_HIGH (x) == DI_HIGH (mask);
+   else
+     return DI_HIGH (x) == 0 && (HOST_WIDE_INT) DI_LOW (x) >= 0;
+ }
+ 
+ /* Returns true if X fits in unsigned HOST_WIDE_INT.  */
+ 
+ bool
+ double_int_fits_in_unsigned_hwi_p (double_int x)
+ {
+   return DI_HIGH (x) == 0;
+ }
+ 
+ /* Returns true if SCALE is negative in precision of MASK.  */
+ 
+ bool
+ double_int_negative_p (double_int mask, double_int scale)
+ {
+   if (DI_HIGH (mask))
+     return (DI_HIGH (scale) & ~(DI_HIGH (mask) >> 1)) != 0;
+   else
+     return (DI_LOW (scale) & ~(DI_LOW (mask) >> 1)) != 0;
+ }
+ 
+ /* Returns value of X, whose precision is given by MASK.  X must satisfy
+    double_int_fits_in_hwi_p.  */
+ 
+ HOST_WIDE_INT
+ double_int_to_hwi (double_int mask, double_int x)
+ {
+   if (DI_HIGH (mask) || !double_int_negative_p (mask, x))
+     return DI_LOW (x);
+   else
+     return DI_LOW (x) | ~DI_LOW (mask);
+ }
+ 
+ /* Returns value of X.  X must satisfy double_int_fits_in_unsigned_hwi_p.  */
+ 
+ unsigned HOST_WIDE_INT
+ double_int_to_unsigned_hwi (double_int x)
+ {
+   return DI_LOW (x);
+ }
+ 
+ /* Returns A * B, truncated so that it fits into precision given by MASK.  */
+ 
+ double_int
+ double_int_mul (double_int mask, double_int a, double_int b)
+ {
+   unsigned HOST_WIDE_INT lo;
+   HOST_WIDE_INT hi;
+   double_int ret;
+ 
+   mul_double (DI_LOW (a), DI_HIGH (a),
+ 	      DI_LOW (b), DI_HIGH (b), &lo, &hi);
+   DI_LOW_SET (ret, lo);
+   DI_HIGH_SET (ret, hi);
+ 
+   return restrict_cst_to_precision (mask, ret);
+ }
+ 
+ /* Returns A + B, truncated so that it fits into precision given by MASK.  */
+ 
+ double_int
+ double_int_add (double_int mask, double_int a, double_int b)
+ {
+   unsigned HOST_WIDE_INT lo;
+   HOST_WIDE_INT hi;
+   double_int ret;
+ 
+   add_double (DI_LOW (a), DI_HIGH (a),
+ 	      DI_LOW (b), DI_HIGH (b), &lo, &hi);
+   DI_LOW_SET (ret, lo);
+   DI_HIGH_SET (ret, hi);
+ 
+   return restrict_cst_to_precision (mask, ret);
+ }
+ 
+ /* Returns -A, truncated so that it fits into precision given by MASK.  */
+ 
+ double_int
+ double_int_negate (double_int mask, double_int a)
+ {
+   unsigned HOST_WIDE_INT lo;
+   HOST_WIDE_INT hi;
+   double_int ret;
+ 
+   neg_double (DI_LOW (a), DI_HIGH (a), &lo, &hi);
+   DI_LOW_SET (ret, lo);
+   DI_HIGH_SET (ret, hi);
+ 
+   return restrict_cst_to_precision (mask, ret);
+ }
+ 
+ /* Returns A / B (computed as unsigned, rounded down).  */
+ 
+ double_int
+ double_int_divide (double_int a, double_int b)
+ {
+   unsigned HOST_WIDE_INT lo, rem_lo;
+   HOST_WIDE_INT hi, rem_hi;
+   double_int ret;
+ 
+   div_and_round_double (FLOOR_DIV_EXPR, true,
+ 			DI_LOW (a), DI_HIGH (a),
+ 			DI_LOW (b), DI_HIGH (b),
+ 			&lo, &hi, &rem_lo, &rem_hi);
+   DI_LOW_SET (ret, lo);
+   DI_HIGH_SET (ret, hi);
+ 
+   return ret;
+ }
+ 
+ /* Constructs tree in type TYPE from with value given by CST (precision of CST
+    is the same as the precision of TYPE -- in particular, it must satisfy
+    double_int_fits_to_type_p).  */
+ 
+ tree
+ double_int_to_tree (tree type, double_int cst)
+ {
+   unsigned HOST_WIDE_INT lo = DI_LOW (cst);
+   HOST_WIDE_INT hi = DI_HIGH (cst);
+   unsigned prec = TYPE_PRECISION (type);
+   bool negative;
+ 
+   if (prec > HOST_BITS_PER_WIDE_INT)
+     {
+       prec -= HOST_BITS_PER_WIDE_INT;
+       negative = (hi >> (prec - 1)) & 1;
+       if (negative)
+ 	hi |= (~(unsigned HOST_WIDE_INT) 0) << (prec - 1) << 1;
+     }
+   else
+     {
+       negative = (DI_LOW (cst) >> (prec - 1)) & 1;
+       if (negative)
+ 	{
+ 	  lo |= (~(unsigned HOST_WIDE_INT) 0) << (prec - 1) << 1;
+ 	  hi = ~(unsigned HOST_WIDE_INT) 0;
+ 	}
+     }
+ 
+   return build_int_cst_wide (type, lo, hi);
+ }
+ 
+ /* Returns true if VAL is smaller or equal to the maximal value
+    representable in TYPE.  */
+ 
+ bool
+ double_int_fits_to_type_p (tree type, double_int val)
+ {
+   unsigned prec = TYPE_PRECISION (type);
+   double_int mask = double_int_mask (TYPE_UNSIGNED (type) ? prec : prec - 1);
+ 
+   return (((DI_LOW (val) & DI_LOW (mask)) == DI_LOW (val))
+ 	  && ((DI_HIGH (val) & DI_HIGH (mask)) == DI_HIGH (val)));
+ }
+ 
+ /* Returns true if A < B, unsigned comparison.  */
+ 
+ bool
+ double_int_smaller_p (double_int a, double_int b)
+ {
+   if (DI_HIGH (a) < DI_HIGH (b))
+     return true;
+   if (DI_HIGH (a) > DI_HIGH (b))
+     return false;
+   return DI_LOW (a) < DI_LOW (b);
+ }
+ 
+ /* Splits last digit of *X in BASE and returns it.  */
+ 
+ static unsigned
+ double_int_split_digit (double_int *x, unsigned base)
+ {
+   unsigned HOST_WIDE_INT resl, reml;
+   HOST_WIDE_INT resh, remh;
+ 
+   div_and_round_double (FLOOR_DIV_EXPR, true, x->low, x->high, base, 0,
+ 			&resl, &resh, &reml, &remh);
+   x->high = resh;
+   x->low = resl;
+ 
+   return reml;
+ }
+ 
+ /* Dumps X (in precision given by MASK) to FILE.  If SIGN is true, X is
+    considered to be signed.  */
+ 
+ void
+ dump_double_int (FILE *file, double_int mask, double_int x, bool sign)
+ {
+   unsigned digits[100], n;
+   int i;
+ 
+   if (double_int_zero_p (x))
+     {
+       fprintf (file, "0");
+       return;
+     }
+ 
+   if (sign && double_int_negative_p (mask, x))
+     {
+       fprintf (file, "-");
+       x = double_int_negate (mask, x);
+     }
+ 
+   for (n = 0; !double_int_zero_p (x); n++)
+     digits[n] = double_int_split_digit (&x, 10);
+   for (i = n - 1; i >= 0; i--)
+     fprintf (file, "%u", digits[i]);
+ }
+ 
+ /* Returns a MASK for precision of PREC bits.  */
+ 
+ double_int 
+ double_int_mask (unsigned prec)
+ {
+   double_int mask;
+ 
+   if (prec > HOST_BITS_PER_WIDE_INT)
+     {
+       prec -= HOST_BITS_PER_WIDE_INT;
+       DI_HIGH_SET (mask, (((unsigned HOST_WIDE_INT) 2 << (prec - 1)) - 1));
+       DI_LOW_SET (mask, ~(unsigned HOST_WIDE_INT) 0);
+     }
+   else
+     {
+       DI_HIGH_SET (mask, 0);
+       DI_LOW_SET (mask, (((unsigned HOST_WIDE_INT) 2 << (prec - 1)) - 1));
+     }
+ 
+   return mask;
+ }
Index: doubleint.h
===================================================================
*** doubleint.h	(revision 0)
--- doubleint.h	(revision 0)
***************
*** 0 ****
--- 1,118 ----
+ /* Operations with long integers.
+    Copyright (C) 2006 Free Software Foundation, Inc.
+    
+ This file is part of GCC.
+    
+ GCC is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the
+ Free Software Foundation; either version 2, or (at your option) any
+ later version.
+    
+ GCC is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ for more details.
+    
+ You should have received a copy of the GNU General Public License
+ along with GCC; see the file COPYING.  If not, write to the Free
+ Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
+ 02110-1301, USA.  */
+ 
+ #ifndef DOUBLE_INT_H
+ #define DOUBLE_INT_H
+ 
+ /* A large integer.  The precision of the represented number is between
+    1 and 2 * HOST_BITS_PER_WIDE_INT and it must be provided in each
+    operation in form of mask that prescribes the significant bits
+    (such mask is also double_int and can be obtained using
+    double_int_mask).  Signedness is only relevant for some operations
+    (comparisons, division), in these cases the description of
+    the function states whether the numbers are assumed to be signed
+    or unsigned.  */
+ 
+ typedef struct
+ {
+   unsigned HOST_WIDE_INT low;
+   HOST_WIDE_INT high;	/* High is signed for historical reasons (it replaces
+ 			   a similar structure that was used previously).  It
+ 			   makes manipulation with the numbers more cumbersome,
+ 			   so it would be nice to change it.  */
+ } double_int;
+ #define DI_LOW(X) (X).low
+ #define DI_HIGH(X) ((unsigned HOST_WIDE_INT) (X).high)
+ #define DI_LOW_SET(X, L) ((X).low = (unsigned HOST_WIDE_INT) (L))
+ #define DI_HIGH_SET(X, L) ((X).high = (HOST_WIDE_INT) (L))
+ 
+ union tree_node;
+ 
+ union tree_node *double_int_to_tree (union tree_node *, double_int);
+ bool double_int_fits_to_type_p (union tree_node *, double_int);
+ double_int tree_to_double_int (union tree_node *tree);
+ bool double_int_fits_in_hwi_p (double_int, double_int);
+ HOST_WIDE_INT double_int_to_hwi (double_int, double_int);
+ bool double_int_fits_in_unsigned_hwi_p (double_int);
+ unsigned HOST_WIDE_INT double_int_to_unsigned_hwi (double_int);
+ double_int double_int_mul (double_int, double_int, double_int);
+ double_int double_int_add (double_int, double_int, double_int);
+ double_int double_int_negate (double_int, double_int);
+ double_int double_int_divide (double_int, double_int);
+ bool double_int_negative_p (double_int, double_int);
+ bool double_int_smaller_p (double_int, double_int);
+ void dump_double_int (FILE *, double_int, double_int, bool);
+ double_int double_int_mask (unsigned);
+ 
+ /* Constructs double_int from integer CST.  */
+ 
+ static inline double_int
+ hwi_to_double_int (HOST_WIDE_INT cst)
+ {
+   double_int r;
+   
+   DI_LOW_SET (r, cst);
+   DI_HIGH_SET (r, cst < 0 ? ~(unsigned HOST_WIDE_INT) 0 : 0);
+ 
+   return r;
+ }
+ 
+ /* Constructs mask with all bits 1.  */
+ 
+ static inline double_int
+ double_int_all (void)
+ {
+   return hwi_to_double_int (-1);
+ }
+ 
+ /* Returns true if CST is zero.  */
+ 
+ static inline bool
+ double_int_zero_p (double_int cst)
+ {
+   return DI_LOW (cst) == 0 && DI_HIGH (cst) == 0;
+ }
+ 
+ /* Returns true if CST is one.  */
+ 
+ static inline bool
+ double_int_one_p (double_int cst)
+ {
+   return DI_LOW (cst) == 1 && DI_HIGH (cst) == 0;
+ }
+ 
+ /* Returns true if CST is minus one in precision of MASK.  */
+ 
+ static inline bool
+ double_int_minus_one_p (double_int mask, double_int cst)
+ {
+   return (DI_LOW (cst) == DI_LOW (mask)
+ 	  && DI_HIGH (cst) == DI_HIGH (mask));
+ }
+ 
+ /* Returns true if CST1 == CST2.  */
+ 
+ static inline bool
+ double_int_equal_p (double_int cst1, double_int cst2)
+ {
+   return DI_LOW (cst1) == DI_LOW (cst2) && DI_HIGH (cst1) == DI_HIGH (cst2);
+ }
+ 
+ #endif /* DOUBLE_INT_H */
Index: system.h
===================================================================
*** system.h	(revision 111309)
--- system.h	(working copy)
*************** extern void fancy_abort (const char *, i
*** 609,614 ****
--- 609,616 ----
  # define FALSE false
  #endif /* !__cplusplus */
  
+ /* Get definition of double_int.  */
+ #include "doubleint.h"
  
  /* Some compilers do not allow the use of unsigned char in bitfields.  */
  #define BOOL_BITFIELD unsigned int
Index: Makefile.in
===================================================================
*** Makefile.in	(revision 111309)
--- Makefile.in	(working copy)
*************** INSN_ATTR_H = insn-attr.h $(srcdir)/insn
*** 773,779 ****
  C_COMMON_H = c-common.h $(SPLAY_TREE_H) $(CPPLIB_H) $(GGC_H)
  C_PRAGMA_H = c-pragma.h $(CPPLIB_H)
  C_TREE_H = c-tree.h $(C_COMMON_H) toplev.h $(DIAGNOSTIC_H)
! SYSTEM_H = system.h hwint.h $(srcdir)/../include/libiberty.h
  PREDICT_H = predict.h predict.def
  CPPLIB_H = $(srcdir)/../libcpp/include/line-map.h \
  	$(srcdir)/../libcpp/include/cpplib.h
--- 773,779 ----
  C_COMMON_H = c-common.h $(SPLAY_TREE_H) $(CPPLIB_H) $(GGC_H)
  C_PRAGMA_H = c-pragma.h $(CPPLIB_H)
  C_TREE_H = c-tree.h $(C_COMMON_H) toplev.h $(DIAGNOSTIC_H)
! SYSTEM_H = system.h hwint.h doubleint.h $(srcdir)/../include/libiberty.h
  PREDICT_H = predict.h predict.def
  CPPLIB_H = $(srcdir)/../libcpp/include/line-map.h \
  	$(srcdir)/../libcpp/include/cpplib.h
*************** prefix.o: prefix.c $(CONFIG_H) $(SYSTEM_
*** 1779,1784 ****
--- 1779,1786 ----
  convert.o: convert.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) \
     $(FLAGS_H) convert.h toplev.h langhooks.h real.h
  
+ doubleint.o: doubleint.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H)
+ 
  langhooks.o : langhooks.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \
     $(TREE_H) toplev.h $(TREE_INLINE_H) $(RTL_H) insn-config.h $(INTEGRATE_H) \
     langhooks.h $(LANGHOOKS_DEF_H) $(FLAGS_H) $(GGC_H) $(DIAGNOSTIC_H) intl.h \

Re: Patch ping

[Roger Sayle]

On Fri, 17 Feb 2006, Paolo Bonzini wrote:
> While I agree on the code duplication issues, on the other hand, I like
> the struct double_int much more than HOST_WIDE_INT pairs.
>
> Don't hold your breath, but if Zdenek's patch goes in I might work on
> using his struct double_int in fold-const.c as well.  That's probably 4.3.

Ok, I see a plan...

The new double_int bears more than a passing similarity to tree.h's struct
tree_int_cst_lowhi.  It looks like we already have a suitable double_int,
we're just not using it as the basis of our low-level arithmetic routines.

Ok, Zdenek, it looks like the way to proceed is to break out all of
your new wrappers into their own doubleint.h and doubleint.c, and
to change tree.h:tree_int_cst.int_cst to be of type double_int as a
single preparatory patch.  For compatability with the existing usage,
you'll probably want to keep the high word signed.    Clearly these
prototypes don't belong in tree-affine.h, and I'd prefer to leave
hwint.h untouched so it can potentially be used in other projects
(generator programs?) without a hwint.c (i.e. like longlong.h).

Then as time permits, probably mostly in 4.3, we'll move over
fold-const.c, tree.c, tree-ssa and the RTL optimizers to use these new
APIs.  This can also lead into a longer term plan to disambiguate
CONST_DOUBLE in our RTL, by distinguishing CONST_DOUBLE (which should
only need two words), from a hypothetical CONST_REAL (which currently
needs about six).

Presumably folks are happy with taking and returning double_int
structures rather than pointers to them, or pairs of HWIs as is
done with the current APIs?  During the transition the pairs of
HWIs routines will remain.  I suspect that we'll end up with
two sets of low-level interfaces, for with and without over
overflow detection, with overflow being returned as a bool rather
than stored in the double_int representation.  INTEGER_CSTs then
become augmented double_int's with types, overflow, signedness,
etc...

The first patch is simple enough, it's the transition that it
prompts...

Roger
--

Re: Patch ping

[Paolo Bonzini]

>> Similar double word arithmetic routines
>> are already duplicated in the tree-ssa optimizers.  The middle-end
>> handling of TREE_OVERFLOW/TREE_CONSTANT_OVERFLOW and representation
>> of INTEGER_CST, REAL_CST, CONST_INT and CONST_DOUBLE in trees and
>> RTL are already "weeping sores" in GCC's infrastructure.  Rather
>> than add another set of hacks, or get embroiled in the inevitable
>> clean-up, might I recommend using HOST_WIDE_INT pairs for the time
>> being?

While I agree on the code duplication issues, on the other hand, I like 
the struct double_int much more than HOST_WIDE_INT pairs.

Don't hold your breath, but if Zdenek's patch goes in I might work on 
using his struct double_int in fold-const.c as well.  That's probably 4.3.

Paolo

Re: Patch ping

[Zdenek Dvorak]

Hello,

> On Thu, 16 Feb 2006, Zdenek Dvorak wrote:
> > http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00676.html
> >   -- patch to improve the functions to work affine combinations;  this
> >      patch blocks further ivopts cleanups (in particular, it keeps
> >      decl_rtl_to_reset alive -- I would really like to get rid of this
> >      ugly hack).
> 
> 
> I'm a bit uncomfortable with the code duplication introduced by your
> new double_int structure.

what code duplication?  It just introduces a few simple wrapper functions,
so that the manipulation is simpler and the code is cleaner.

> Similar double word arithmetic routines
> are already duplicated in the tree-ssa optimizers.  The middle-end
> handling of TREE_OVERFLOW/TREE_CONSTANT_OVERFLOW and representation
> of INTEGER_CST, REAL_CST, CONST_INT and CONST_DOUBLE in trees and
> RTL are already "weeping sores" in GCC's infrastructure.  Rather
> than add another set of hacks, or get embroiled in the inevitable
> clean-up, might I recommend using HOST_WIDE_INT pairs for the time
> being?

I am really uncomfortable with this suggestion :-( Yep, it is certainly
possible; however, keeping two parts of the same object separate
strikes me as wrong design.

> Entangling your iv-opts clean-ups with the nightmare of GCC's
> multi-precision integer handling might result in delaying your
> changes until 4.3 or later :-(  For example it isn't clear whether
> your new structure is a constructive step in the right direction.

Well, as long as ivopts must handle the case of short and long integers
separately, it is very hard to make any progress in it.

Zdenek

Re: Patch ping

[Roger Sayle]

On Thu, 16 Feb 2006, Zdenek Dvorak wrote:
> http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00676.html
>   -- patch to improve the functions to work affine combinations;  this
>      patch blocks further ivopts cleanups (in particular, it keeps
>      decl_rtl_to_reset alive -- I would really like to get rid of this
>      ugly hack).


I'm a bit uncomfortable with the code duplication introduced by your
new double_int structure.  Similar double word arithmetic routines
are already duplicated in the tree-ssa optimizers.  The middle-end
handling of TREE_OVERFLOW/TREE_CONSTANT_OVERFLOW and representation
of INTEGER_CST, REAL_CST, CONST_INT and CONST_DOUBLE in trees and
RTL are already "weeping sores" in GCC's infrastructure.  Rather
than add another set of hacks, or get embroiled in the inevitable
clean-up, might I recommend using HOST_WIDE_INT pairs for the time
being?

Entangling your iv-opts clean-ups with the nightmare of GCC's
multi-precision integer handling might result in delaying your
changes until 4.3 or later :-(  For example it isn't clear whether
your new structure is a constructive step in the right direction.

Roger
--

Patch ping

[Zdenek Dvorak]

Hello,

http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00676.html
  -- patch to improve the functions to work affine combinations;  this
     patch blocks further ivopts cleanups (in particular, it keeps
     decl_rtl_to_reset alive -- I would really like to get rid of this
     ugly hack).

Zdenek

Patch ping

[Jakub Jelinek]

Hi!

--with{,out}-long-double-128 configure option:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00664.html

(together with the already approved remaining parts of:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00274.html
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00271.html
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00263.html).

Ok for trunk?

	Jakub

Patch ping

[Zdenek Dvorak]

Hello,

I would like to ping the following two patches, that block followup
cleanup patches to ivopts and other parts of the loop optimizer.

http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00676.html
  -- improves, cleans up, and moves to the separate file functions
     for work with affine combinations

http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01259.html
  -- removes final value replacement from ivopts

Zdenek

Patch ping

[Jakub Jelinek]

Hi!

Ping:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01957.html
- fix debuginfo for preprocessed fortran sources

	Jakub

Re: Patch ping...

[Ian Lance Taylor]

Jan Hubicka <hubicka@ucw.cz> writes:

> the patch:
> http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01877.html
> used to rearrange saving code in inliner is needed to proceed further on
> IPA branch merging.  Would be possible to take a look on it, please?

OK, I tried to wrap my head around it.

The update_clones_p field in inline_data needs a comment.

The update_clones parameter to tree_function_versioning needs a
comment.

The comment "This means not lowering some constructs such as exception
handling" in tree_rest_of_compilation no longer seems accurate.  It
now calls save_inline_function_body, which does appear to lower
exception handling.

OK with those changes.

Thanks.

Ian

Patch ping...

[Jan Hubicka]

Hi,
the patch:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01877.html
used to rearrange saving code in inliner is needed to proceed further on
IPA branch merging.  Would be possible to take a look on it, please?

Honza

Re: Patch ping

[Zdenek Dvorak]

Hello,

> > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00670.html
> >   -- a patch to make dumps in several loop optimization passes (ivopts,
> >      vectorizer, ...) easier to read, by having scev & data dependence
> >      analysis dumps disabled by default
> >
> Not completely OK.  When I specify -details, I want every piece of 
> information produced by the pass.
> It's fine with me if you want to add a specific -analysis switch that is 
> orthogonal from -details.  But with your patch, -details would not print 
> everything in the scev and data dependence dumps.
> 
> A simple tweak to this patch would give us both things.  Make TDF_DETAILS 
> include TDF_ANALYSIS in its bitmask.  In fact, we could even have:
> 
> #define TDF_DETAILS	(1<<3) | TDF_ANALYSIS | TDF_STATS

the point of this patch is that I want to be able to show everything
-details shows now, except for what -analysis does (because the dumps
covered by -analysis are almost never useful, except for the case there
is a bug in one of those analyses).  I do not really care whether
-analysis dumps are shown by default, I just want to have a simple way
how to disable them while still preserving the other -details dumps.  Is
that possible in the solution you propose?

Zdenek

> > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01820.html
> >   -- an updated version of one of tree-ssa-operands.c
> >      cleanup patches; it was approved by Diego except for one
> >      suspicious place, which is changed in this version
> >
> OK.

Re: Patch ping

[Diego Novillo]

On Tuesday 10 January 2006 09:03, Zdenek Dvorak wrote:
> Hello,
>
> http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00670.html
>   -- a patch to make dumps in several loop optimization passes (ivopts,
>      vectorizer, ...) easier to read, by having scev & data dependence
>      analysis dumps disabled by default
>
Not completely OK.  When I specify -details, I want every piece of 
information produced by the pass.

It's fine with me if you want to add a specific -analysis switch that is 
orthogonal from -details.  But with your patch, -details would not print 
everything in the scev and data dependence dumps.

A simple tweak to this patch would give us both things.  Make TDF_DETAILS 
include TDF_ANALYSIS in its bitmask.  In fact, we could even have:

#define TDF_DETAILS	(1<<3) | TDF_ANALYSIS | TDF_STATS

> http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01820.html
>   -- an updated version of one of tree-ssa-operands.c
>      cleanup patches; it was approved by Diego except for one
>      suspicious place, which is changed in this version
>
OK.

Patch ping

[Zdenek Dvorak]

Hello,

http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00670.html
  -- a patch to make dumps in several loop optimization passes (ivopts,
     vectorizer, ...) easier to read, by having scev & data dependence
     analysis dumps disabled by default

http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01820.html
  -- an updated version of one of tree-ssa-operands.c
     cleanup patches; it was approved by Diego except for one
     suspicious place, which is changed in this version

Zdenek

Patch ping...

[Jan Hubicka]

Hi,
the patch:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01877.html
used to rearrange saving code in inliner is needed to proceed further on
IPA branch merging.  Would be possible to take a look on it, please?

Honza

Re: patch ping

[Gerald Pfeifer]

On Mon, 19 Dec 2005, Jan Beulich wrote:
> Is there any chance to get a review for
> 
> http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00166.html 
> http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00181.html 
> http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00659.html

Jan, and others pinging patches: I strongly recommend to provide
the original Subject line or a short description in addition to 
the URL for such pings -- that'll make it much more likely that
the responsible maintainers look into them.

Gerald

patch ping

[Jan Beulich]

Is there any chance to get a review for

http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00166.html 
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00181.html 
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00659.html

(the last one being of particular importance, and at the same time
almost to be considered trivial, as it fixes a number of testsuite
failures)?

Thanks, Jan

Re: patch ping

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]

Rafael Ávila de Espíndola <rafael.espindola@gmail.com> writes:

> approved
> http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00134.html

Please see:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00539.html

and then a new patch, Alexandre promised to check it in.

Please adjust your ChangeLog entries, they are not according to our
policies and include them in the updated patch.

You have:
                  * gcc/configure: Removed the all.build target
                  * gcc/configure.ac:  Removed the all.build target
                  * gcc/cp/Make-lang.in:  Removed the all.build target
                  * gcc/doc/sourcebuild.texi:  Removed the all.build target
                  * gcc/fortran/Make-lang.in: Removed the all.build target

But most of these directories have their own ChangeLog file and the
entry should go there.  Also, you should give the function in the
line as full name, e.g. for cp/Make-lang.in your entry for
gcc/cp/ChangeLog would be:

	* Make-lang.in (c++.all.build): Remove.


> approved
> http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01734.html

> approved for treelang. Fortran approval is missing
> http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00017.html
>
> Rafael

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

patch ping

[Rafael Ávila de Espíndola]

[-- Attachment #1: Type: text/plain, Size: 247 bytes --]

approved
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00134.html

approved
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01734.html

approved for treelang. Fortran approval is missing
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00017.html

Rafael

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: patch ping

[Richard Kenner]

    I am also somewhat troubled that I can't find any documentation on
    what TREE_TYPE of a INTEGER_TYPE, ENUMERAL_TYPE, or CHAR_TYPE is
    supposed to mean.  Is that usage specific to the Ada frontend?  What
    is the general meaning?

It's used more often by the Ada front end, but I think others generate it as
well, since it wasn't added for Ada.  It means that the given type is a
*subtype* of its TREE_TYPE, which means that we are saying that the values
of an object of that type are restricted to a subset of the values of the
type in TREE_TYPE.  The range is given by TYPE_MIN_VALUE and TYPE_MAX_VALUE.

Re: patch ping

[Ian Lance Taylor]

Andrew Pinski <pinskia@physics.uc.edu> writes:

> +	  /* If we have a type which is a subtype use the
> +	     subtype instead.  */
> +	  if (TREE_TYPE (etype))
> +	    etype = TREE_TYPE (etype);

This makes me a bit nervous simply because I can't see anything else
in fold-const.c which does anything like this.

I am also somewhat troubled that I can't find any documentation on
what TREE_TYPE of a INTEGER_TYPE, ENUMERAL_TYPE, or CHAR_TYPE is
supposed to mean.  Is that usage specific to the Ada frontend?  What
is the general meaning?

What if you simply don't do the optimization if range_binop returns
NULL?

Ian

Re: patch ping

[Andrew Pinski]

[-- Attachment #1: Type: text/plain, Size: 1888 bytes --]

> 
> > 
> > > 
> > > Andrew Pinski <pinskia@physics.uc.edu> writes:
> > > 
> > > > I thought that I would not have to ping patches any more
> > > > with the patch queue but I am wrong, oh well.
> > > > 
> > > > http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00879.html
> > > > [PATCH] Fix PR middle-end/22429, fold building tree which depends on signed overflow
> > > > 
> > > > This fixes one of the wrong-code regressions in 4.1, basicially
> > > > fold was building a tree which depends on signed overflowing
> > > > being defined as wrapping which is only true with -fwrapv.
> > > 
> > > Setting etype to TREE_TYPE (etype) looks wrong to me.  And I suspect
> > > that the reason you have to do it is that your patch doesn't set value
> > > back to zero.  The old code would work because it checks TREE_OVERFLOW
> > > again.  But your patch effectively does not--it is possible for value
> > > to fall through without TREE_OVERFLOW being set.
> > > 
> > > Also, I think the patch makes the code more confusing.  In the case of
> > > flag_wrapv && !TYPE_UNSIGNED (type), the first computation of value is
> > > of no importance.
> > > 
> > > How about something like this?  I haven't tested it.
> > This works except it introduces two Ada test failures,  I am going to look
> > into them.  They are both ICEs.
> 
> Both of the failure is due to range_binop returning NULL in:
> 4047              if (integer_zerop (range_binop (NE_EXPR, integer_type_node,
> 4048                                              minv, 1, maxv, 1)))
> 
> This is due to minv being a non-constant value.
> 
> Let me try the obvious patch to test for that case and see if it works.

Here is the patch which works for those two tests and also for my testcase
still, it adds the testcase also to the patch.  I am right now doing
a full bootstrap/test on x86_64-pc-linux-gnu with this patch.

Thanks,
Andrew Pinski

[-- Attachment #2: ASCII C program text --]
[-- Type: text/plain, Size: 2360 bytes --]

Index: fold-const.c
===================================================================
--- fold-const.c	(revision 105995)
+++ fold-const.c	(working copy)
@@ -4013,8 +4013,22 @@ build_range_check (tree type, tree exp, 
 	}
     }
 
-  value = const_binop (MINUS_EXPR, high, low, 0);
-  if (value != 0 && TREE_OVERFLOW (value) && ! TYPE_UNSIGNED (etype))
+  /* Try to build a check for whether EXP - LOW is between zero and
+     HIGH - LOW.  We can only do this safely using an unsigned type,
+     or when signed values wrap around.  Otherwise EXP - LOW might
+     overflow.  And of course it doesn't work if HIGH - LOW
+     overflows.  */
+
+  value = NULL_TREE;
+
+  if (TYPE_UNSIGNED (type) || flag_wrapv)
+    {
+      value = const_binop (MINUS_EXPR, high, low, 0);
+      if (value && TREE_OVERFLOW (value))
+	value = NULL_TREE;
+    }
+
+  if (value == NULL_TREE && !TYPE_UNSIGNED (type))
     {
       tree utype, minv, maxv;
 
@@ -4025,6 +4039,11 @@ build_range_check (tree type, tree exp, 
 	case INTEGER_TYPE:
 	case ENUMERAL_TYPE:
 	case CHAR_TYPE:
+	  /* If we have a type which is a subtype use the
+	     subtype instead.  */
+	  if (TREE_TYPE (etype))
+	    etype = TREE_TYPE (etype);
+
 	  utype = lang_hooks.types.unsigned_type (etype);
 	  maxv = fold_convert (utype, TYPE_MAX_VALUE (etype));
 	  maxv = range_binop (PLUS_EXPR, NULL_TREE, maxv, 1,
@@ -4038,6 +4057,8 @@ build_range_check (tree type, tree exp, 
 	      low = fold_convert (etype, low);
 	      exp = fold_convert (etype, exp);
 	      value = const_binop (MINUS_EXPR, high, low, 0);
+	      if (TREE_OVERFLOW (value))
+		value = NULL_TREE;
 	    }
 	  break;
 	default:
@@ -4045,7 +4066,7 @@ build_range_check (tree type, tree exp, 
 	}
     }
 
-  if (value != 0 && ! TREE_OVERFLOW (value))
+  if (value)
     return build_range_check (type,
 			      fold_build2 (MINUS_EXPR, etype, exp, low),
 			      1, fold_convert (etype, integer_zero_node),
Index: testsuite/gcc.c-torture/execute/pr22429-1.c
===================================================================
--- testsuite/gcc.c-torture/execute/pr22429-1.c	(revision 0)
+++ testsuite/gcc.c-torture/execute/pr22429-1.c	(revision 0)
@@ -0,0 +1,14 @@
+int f(int n)
+{
+  if (-1073741824 <= n && n <= 1073741823)
+    return 1;
+  return 0;
+}
+
+int main()
+{
+  if (f(1073741824))
+    abort ();
+  return 0;
+}
+

Re: patch ping

[Andrew Pinski]

> 
> > 
> > Andrew Pinski <pinskia@physics.uc.edu> writes:
> > 
> > > I thought that I would not have to ping patches any more
> > > with the patch queue but I am wrong, oh well.
> > > 
> > > http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00879.html
> > > [PATCH] Fix PR middle-end/22429, fold building tree which depends on signed overflow
> > > 
> > > This fixes one of the wrong-code regressions in 4.1, basicially
> > > fold was building a tree which depends on signed overflowing
> > > being defined as wrapping which is only true with -fwrapv.
> > 
> > Setting etype to TREE_TYPE (etype) looks wrong to me.  And I suspect
> > that the reason you have to do it is that your patch doesn't set value
> > back to zero.  The old code would work because it checks TREE_OVERFLOW
> > again.  But your patch effectively does not--it is possible for value
> > to fall through without TREE_OVERFLOW being set.
> > 
> > Also, I think the patch makes the code more confusing.  In the case of
> > flag_wrapv && !TYPE_UNSIGNED (type), the first computation of value is
> > of no importance.
> > 
> > How about something like this?  I haven't tested it.
> This works except it introduces two Ada test failures,  I am going to look
> into them.  They are both ICEs.

Both of the failure is due to range_binop returning NULL in:
4047              if (integer_zerop (range_binop (NE_EXPR, integer_type_node,
4048                                              minv, 1, maxv, 1)))

This is due to minv being a non-constant value.

Let me try the obvious patch to test for that case and see if it works.

-- Pinski

Re: patch ping

[Andrew Pinski]

> 
> Andrew Pinski <pinskia@physics.uc.edu> writes:
> 
> > I thought that I would not have to ping patches any more
> > with the patch queue but I am wrong, oh well.
> > 
> > http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00879.html
> > [PATCH] Fix PR middle-end/22429, fold building tree which depends on signed overflow
> > 
> > This fixes one of the wrong-code regressions in 4.1, basicially
> > fold was building a tree which depends on signed overflowing
> > being defined as wrapping which is only true with -fwrapv.
> 
> Setting etype to TREE_TYPE (etype) looks wrong to me.  And I suspect
> that the reason you have to do it is that your patch doesn't set value
> back to zero.  The old code would work because it checks TREE_OVERFLOW
> again.  But your patch effectively does not--it is possible for value
> to fall through without TREE_OVERFLOW being set.
> 
> Also, I think the patch makes the code more confusing.  In the case of
> flag_wrapv && !TYPE_UNSIGNED (type), the first computation of value is
> of no importance.
> 
> How about something like this?  I haven't tested it.
This works except it introduces two Ada test failures,  I am going to look
into them.  They are both ICEs.

-- Pinski

Re: patch ping

[Ian Lance Taylor]

Andrew Pinski <pinskia@physics.uc.edu> writes:

> I thought that I would not have to ping patches any more
> with the patch queue but I am wrong, oh well.
> 
> http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00879.html
> [PATCH] Fix PR middle-end/22429, fold building tree which depends on signed overflow
> 
> This fixes one of the wrong-code regressions in 4.1, basicially
> fold was building a tree which depends on signed overflowing
> being defined as wrapping which is only true with -fwrapv.

Setting etype to TREE_TYPE (etype) looks wrong to me.  And I suspect
that the reason you have to do it is that your patch doesn't set value
back to zero.  The old code would work because it checks TREE_OVERFLOW
again.  But your patch effectively does not--it is possible for value
to fall through without TREE_OVERFLOW being set.

Also, I think the patch makes the code more confusing.  In the case of
flag_wrapv && !TYPE_UNSIGNED (type), the first computation of value is
of no importance.

How about something like this?  I haven't tested it.

Ian

--- fold-const.c.~1.629.~	2005-10-21 10:15:14.000000000 -0700
+++ fold-const.c	2005-10-28 20:57:15.000000000 -0700
@@ -4013,8 +4013,22 @@ build_range_check (tree type, tree exp, 
 	}
     }
 
-  value = const_binop (MINUS_EXPR, high, low, 0);
-  if (value != 0 && TREE_OVERFLOW (value) && ! TYPE_UNSIGNED (etype))
+  /* Try to build a check for whether EXP - LOW is between zero and
+     HIGH - LOW.  We can only do this safely using an unsigned type,
+     or when signed values wrap around.  Otherwise EXP - LOW might
+     overflow.  And of course it doesn't work if HIGH - LOW
+     overflows.  */
+
+  value = NULL_TREE;
+
+  if (TYPE_UNSIGNED (type) || flag_wrapv)
+    {
+      value = const_binop (MINUS_EXPR, high, low, 0);
+      if (value && TREE_OVERFLOW (value))
+	value = NULL_TREE;
+    }
+
+  if (value == NULL_TREE && !TYPE_UNSIGNED (type))
     {
       tree utype, minv, maxv;
 
@@ -4038,6 +4052,8 @@ build_range_check (tree type, tree exp, 
 	      low = fold_convert (etype, low);
 	      exp = fold_convert (etype, exp);
 	      value = const_binop (MINUS_EXPR, high, low, 0);
+	      if (TREE_OVERFLOW (value))
+		value = NULL_TREE;
 	    }
 	  break;
 	default:
@@ -4045,7 +4061,7 @@ build_range_check (tree type, tree exp, 
 	}
     }
 
-  if (value != 0 && ! TREE_OVERFLOW (value))
+  if (value)
     return build_range_check (type,
 			      fold_build2 (MINUS_EXPR, etype, exp, low),
 			      1, fold_convert (etype, integer_zero_node),

patch ping

[Andrew Pinski]

I thought that I would not have to ping patches any more
with the patch queue but I am wrong, oh well.

http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00879.html
[PATCH] Fix PR middle-end/22429, fold building tree which depends on signed overflow

This fixes one of the wrong-code regressions in 4.1, basicially
fold was building a tree which depends on signed overflowing
being defined as wrapping which is only true with -fwrapv.


-- Pinski

Re: Patch ping

[Richard Henderson]

On Tue, Oct 04, 2005 at 09:35:33AM -0700, Ian Lance Taylor wrote:
> Patch for 4.1 regression PR preprocessor/13726 (-dI -C -E does not
> work correctly):
>     http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01472.html

Ok.


r~

Patch ping

[Ian Lance Taylor]

Patch for 4.1 regression PR preprocessor/13726 (-dI -C -E does not
work correctly):
    http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01472.html

Patch for 4.1 regression PR libstdc++/13583 (limited memory leak in
threaded program):
    http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01550.html

Ping!

Ian

Re: Patch ping

[Ian Lance Taylor]

Jakub Jelinek <jakub@redhat.com> writes:

> http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01187.html
> - fix __builtin_*_chk if GCC is able to figure out maxlen, but len
>   is not compile time constant and object size of destination is
>   known (bootstrapped/regtested several times on i?86-linux HEAD
>   plus on 7 linux arches in 4.0 backport)

This is OK.  Thanks.

[ My first approval as middle-end maintainer! ]

Ian

Patch ping

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01187.html
- fix __builtin_*_chk if GCC is able to figure out maxlen, but len
  is not compile time constant and object size of destination is
  known (bootstrapped/regtested several times on i?86-linux HEAD
  plus on 7 linux arches in 4.0 backport)

	Jakub

Patch ping...

[Jan Hubicka]

Hi,
this patch to avoid quadratic behaviour when duplicating EH regions:
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01052.html seems to be
pretty important for inline heavy C++ sources.  Would be possible to
take a look?

Thanks,
Honza

Re: Patch ping...

[Jan Hubicka]

> On Mon, Jun 20, 2005 at 09:37:33PM +0200, Jan Hubicka wrote:
> > fix to the -fdump-rtl-expand:
> > http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02126.html
> 
> Ok.
> 
> > and also the -fwhole-program patch:
> > http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00267.html
> 
> The documentation for -fwhole-program still mentions "used",
> instead of "externally_visible".

Fixed in my local copy, I will commit it from summit after testing.
> 
> Otherwise ok.

Thanks a lot!
Honza
> 
> 
> r~

Re: Patch ping...

[Richard Henderson]

On Mon, Jun 20, 2005 at 09:37:33PM +0200, Jan Hubicka wrote:
> fix to the -fdump-rtl-expand:
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02126.html

Ok.

> and also the -fwhole-program patch:
> http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00267.html

The documentation for -fwhole-program still mentions "used",
instead of "externally_visible".

Otherwise ok.


r~

Patch ping...

[Jan Hubicka]

Hi,
There are two patches that apparently got suck..
fix to the -fdump-rtl-expand:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02126.html
and also the -fwhole-program patch:
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00267.html

Honza

patch ping

[Eric Christopher]

Fixes %b for languages other than C.

http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00166.html

-eric

Patch ping

[Tobias Schlüter]

This is a patch that somehow got lost:

[gfortran] Minor cleanup to trans-intrinsic.c
http://gcc.gnu.org/ml/fortran/2005-02/msg00048.html

- Tobi

Patch ping

[Jakub Jelinek]

Hi!

Fix FORALL:
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02960.html

Bootstrapped/regtested on HEAD on {x86_64,ppc64}-redhat-linux
and on 4.0 branch on {i386,x86_64,ia64,ppc,ppc64,s390,s390x}-redhat-linux.

	Jakub

Re: Patch ping

[Richard Henderson]

On Mon, Apr 04, 2005 at 11:13:43AM -0400, Ian Lance Taylor wrote:
>     http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02460.html

Ok.


r~

Patch ping

[Ian Lance Taylor]

Patch ping:
    http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02460.html

This is a patch to the Windows code to fix PR 9963.  The current code
uses TREE_ASM_WRITTEN without ever setting it.  My proposed patch
tests TREE_ASM_WRITTEN on a decl rather than a string.

Thanks to Danny Smith for testing the patch.

Ian

Re: Patch ping

[Geoffrey Keating]

Dale Johannesen <dalej@apple.com> writes:

> Handle STATEMENT_LIST in debug_tree
> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02470.html

OK.

Re: Patch ping

[Tom Tromey]

>>>>> "Dale" == Dale Johannesen <dalej@apple.com> writes:

Dale> Handle STATEMENT_LIST in debug_tree
Dale> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02470.html

Yeah, this would be really helpful when debugging gcjx.
Thanks for pointing it out, I'm going to apply it to my branch :-)

Tom

Patch ping

[Dale Johannesen]

Handle STATEMENT_LIST in debug_tree
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02470.html
Objective C hooks for OBJ_TYPE_REF_EXPR
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02473.html
Fix PR 19225
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02530.html

Thanks!

Patch ping

[Zdenek Dvorak]

Hello,

a few patches for that I did not get answer for and consider them nice
or important enough to bother...

http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01644.html
  -- the patch to include ggc memory consumption report
     to the standard timevar report

http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00205.html
  -- tree level store motion speed up (PR 17790)

http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00450.html
  -- TARGET_MEM_REF patch (representation for target-specific
     addressing modes on tree level).

Zdenek

Patch ping

[Jakub Jelinek]

Hi!

Fix try_combine splitting (PR target/20322)
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00647.html

Bootstrapped/regtested on {i386,x86_64,ia64,ppc,ppc64,s390,s390x}-linux,
no regressions.

	Jakub

Patch ping

[Zdenek Dvorak]

Hello,

the radical cleanup and rewrite of store motion, that addresses
the compile time problems (PR17790)

http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00205.html

Zdenek

Patch ping

[H. J. Lu]

Could someone please take a look at the patch

http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01352.html

for

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18508

Thanks.


H.J.

Patch ping

[H. J. Lu]

Could someone please take a look at patch for

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18153

> 
> PR18153 has a wrong AC_MSG_RESULT line, should be:
> 
> AC_MSG_RESULT($gcc_cv_ld_static_dynamic)

Thanks.  Here is an updated one.


H.J.
----
2004-12-10  H.J. Lu  <hongjiu.lu@intel.com>

	PR target/18153
	* configure.ac: Define HAVE_LD_STATIC_DYNAMIC if linker supports
	-Bstatic/-Bdynamic option.
	* config.in: Regenerated.
	* configure: Likewise.

	* gcc.c (init_spec): Pass -Bstatic/-Bdynamic to ld for static
	-lunwind if possible.

--- gcc/config.in.static	2004-10-25 17:37:13.000000000 -0700
+++ gcc/config.in	2004-10-26 10:06:38.270754696 -0700
@@ -322,6 +322,9 @@
    a read-write section. */
 #undef HAVE_LD_RO_RW_SECTION_MIXING
 
+/* Define if your linker supports -Bstatic/-Bdynamic option. */
+#undef HAVE_LD_STATIC_DYNAMIC
+
 /* Define to 1 if you have the <limits.h> header file. */
 #undef HAVE_LIMITS_H
 
--- gcc/configure.ac.static	2004-10-25 17:37:13.000000000 -0700
+++ gcc/configure.ac	2004-10-26 10:11:49.451512210 -0700
@@ -2645,6 +2645,25 @@ if test x"$gcc_cv_ld_pie" = xyes; then
 fi
 AC_MSG_RESULT($gcc_cv_ld_pie)
 
+AC_MSG_CHECKING(linker -Bstatic/-Bdynamic option)
+gcc_cv_ld_static_dynamic=no
+if test $in_tree_ld = yes ; then
+  if test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" -ge 10; then
+    gcc_cv_ld_static_dynamic=yes
+  fi
+elif test x$gcc_cv_ld != x; then
+	# Check if linker supports -Bstatic/-Bdynamic option
+	if $gcc_cv_ld --help 2>/dev/null | grep -- -Bstatic > /dev/null \
+	  && $gcc_cv_ld --help 2>/dev/null | grep -- -Bdynamic > /dev/null; then
+		gcc_cv_ld_static_dynamic=yes
+	fi
+fi
+if test x"$gcc_cv_ld_static_dynamic" = xyes; then
+	AC_DEFINE(HAVE_LD_STATIC_DYNAMIC, 1,
+[Define if your linker supports -Bstatic/-Bdynamic option.])
+fi
+AC_MSG_RESULT($gcc_cv_ld_static_dynamic)
+
 if test x"$demangler_in_ld" = xyes; then
   AC_MSG_CHECKING(linker --demangle support)
   gcc_cv_ld_demangle=no
--- gcc/gcc.c.static	2004-09-08 08:17:29.000000000 -0700
+++ gcc/gcc.c	2004-10-26 10:21:48.880992852 -0700
@@ -1647,7 +1647,11 @@ init_spec (void)
 			    "-lgcc",
 			    "-lgcc_eh"
 #ifdef USE_LIBUNWIND_EXCEPTIONS
+# ifdef HAVE_LD_STATIC_DYNAMIC
+			    " %{!static:-Bstatic} -lunwind %{!static:-Bdynamic}"
+# else
 			    " -lunwind"
+# endif
 #endif
 			    );
 

Re: Patch Ping

[Geoffrey Keating]

Tom Tromey <tromey@redhat.com> writes:

> Andrew approved the gcj part of this patch, but I think it still
> needs an approval for the gcc.c bit:
> 
> http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02420.html

OK.

Patch Ping

[Tom Tromey]

Andrew approved the gcj part of this patch, but I think it still
needs an approval for the gcc.c bit:

http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02420.html

Tom

Re: Patch ping

[Richard Henderson]

On Fri, Sep 03, 2004 at 04:28:09PM -0700, H. J. Lu wrote:
> http://gcc.gnu.org/ml/gcc-patches/2004-07/msg02650.html

Ok.


r~

Patch ping

[H. J. Lu]

Here is a patch to disable branch hint for P4 and EM64T:

http://gcc.gnu.org/ml/gcc-patches/2004-07/msg02650.html

Could someone please review it?

Thanks.


H.J.

Re: Patch ping

[Paul Brook]

[-- Attachment #1: Type: text/plain, Size: 3144 bytes --]

On Saturday 31 July 2004 17:30, Steve Kargl wrote:
> http://gcc.gnu.org/ml/gcc-patches/2004-07/msg02001.html

I made gfc_mpfr_to_mpz use the mprf->integer conversion routines rather than 
going via a string.

Applied as attached.

Paul

2004-08-06  Steven G. Kargl  <kargls@comcast.net>

	* arith.c: Add #define for model numbers.  Remove global GMP variables.
	(natural_logarithm,common_logarithm,exponential,sine,
	cosine,arctangent,hypercos,hypersine ): Remove.
	(gfc_mpfr_to_mpz,gfc_set_model_kind,gfc_set_model): New functions.
	(arctangent2,gfc_arith_init_1,gfc_arith_done_1
	gfc_check_real_range, gfc_constant_result, gfc_range_check,
	gfc_arith_uminus,gfc_arith_plus, gfc_arith_minus, gfc_arith_times,
	gfc_arith_divide,complex_reciprocal,complex_pow_ui,
	gfc_arith_power,gfc_compare_expr,compare_complex,gfc_convert_real,
	gfc_convert_complex,gfc_int2real,gfc_int2complex,
	gfc_real2int,gfc_real2real,gfc_real2complex,
	gfc_complex2int,gfc_complex2real,gfc_complex2complex): Convert GMP
	to MPFR, use new functions.
	* arith.h: Remove extern global variables.
	(natural_logarithm,common_logarithm,exponential, sine, cosine,
	arctangent,hypercos,hypersine): Remove prototypes.
	(arctangent2): Update prototype from GMP to MPFR.
	(gfc_mpfr_to_mpz, gfc_set_model_kind,gfc_set_model): Add prototypes.
	* dump-parse-tree.c (gfc_show_expr): Convert GMP to MPFR.
	* expr.c (free_expr0,gfc_copy_expr): Convert GMP to MPFR.
	* gfortran.h (GFC_REAL_BITS): Remove.
	(arith): Add ARITH_NAN.
	Include mpfr.h.  Define GFC_RND_MODE.
	Rename GCC_GFORTRAN_H GFC_GFC_H.
	(gfc_expr): Convert GMP to MPFR.
	* module.c: Add arith.h, correct type in comment.
	(mio_gmp_real): Convert GMP to MPFR.
	(mio_expr):  Use gfc_set_model_kind().
	* primary.c:  Update copyright date with 2004.
	(match_real_constant,match_const_complex_part): Convert GMP to MPFR.
	* simplify.c: Remove global GMP variables
	(gfc_simplify_abs,gfc_simplify_acos,gfc_simplify_aimag,
	gfc_simplify_aint,gfc_simplify_dint,gfc_simplify_anint,
	gfc_simplify_dnint,gfc_simplify_asin,gfc_simplify_atan,
	gfc_simplify_atan2,gfc_simplify_ceiling,simplify_cmplx,
	gfc_simplify_conjg,gfc_simplify_cos,gfc_simplify_cosh,
	gfc_simplify_dim,gfc_simplify_dprod,gfc_simplify_epsilon,
	gfc_simplify_exp,gfc_simplify_exponent,gfc_simplify_floor,
	gfc_simplify_fraction,gfc_simplify_huge,gfc_simplify_int,
	gfc_simplify_ifix,gfc_simplify_idint,gfc_simplify_log,
	gfc_simplify_log10,simplify_min_max,gfc_simplify_mod,
	gfc_simplify_modulo,gfc_simplify_nearest,simplify_nint,
	gfc_simplify_rrspacing,gfc_simplify_scale,
	gfc_simplify_set_exponent,gfc_simplify_sign,gfc_simplify_sin,
	gfc_simplify_sinh,gfc_simplify_spacing,gfc_simplify_sqrt,
	gfc_simplify_tan,gfc_simplify_tanh,gfc_simplify_tiny,
	gfc_simplify_init_1,gfc_simplify_done_1):  Convert GMP to MPFR.
	Use new functions.
	* trans-const.c (gfc_conv_mpfr_to_tree): Rename from
	gfc_conv_mpf_to_tree.  Convert it to use MPFR
	(gfc_conv_constant_to_tree): Use it.
	* trans-const.h: Update prototype for gfc_conv_mpfr_to_tree().
	* trans-intrinsic.c: Add arith.h, remove gmp.h
	(gfc_conv_intrinsic_aint,gfc_conv_intrinsic_mod): Convert GMP to MPFR.

[-- Attachment #2: patch.mpfr.gz --]
[-- Type: application/x-gzip, Size: 19909 bytes --]

Re: Patch ping

[Paolo Bonzini]

> http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00217.html
> 
> Ok for mainline?

I cannot approve anything but I'd suggest that, the next time you have 
such a series of mechanical patches, you may want to ask for preapproval.

Paolo

Re: Patch ping

[Roger Sayle]

On Thu, 8 Jul 2004 jlquinn@optonline.net wrote:
> http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00217.html

This is Ok for mainline.

Roger
--

Patch ping

[jlquinn]

http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00217.html

Ok for mainline?

patch ping

[Ziemowit Laski]

   http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01528.html

Or is fixing PRs unimportant? :-)

--Zem

--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477

patch ping

[Josef Zlomek]

Hello,

1. Fix bug in var-tracking WRT location list for DW_AT_frame_base
http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01730.html


2. PR/15242 - Duplicate computed gotos
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01670.html


Thanks,

Josef

patch ping

[Pat Haugen]

The following patches fix problems with not maintaining profile counts
correctly when modifying the CFG.


http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01558.html
Fix for value profile transformations.


http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01595.html
Fix edge redirection in make_forwarder_block.


http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01850.html
Fix for split_block which was regressed with tree-ssa merge.


-Pat

patch ping

[Jerry Quinn]

http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01280.html

Re: Patch ping

[Roger Sayle]

On Mon, 21 Jun 2004, Paolo Bonzini wrote:
> http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01844.html
> [PATCH] Say that LTGT may trap

This is OK for mainline.

Thanks,

Roger
--

Patch ping

[Paolo Bonzini]

http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01844.html
[PATCH] Say that LTGT may trap

http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01531.html
[PATCH] remove dead code from gcc.c

http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00049.html
Re: [Patch/RFC] Enable PCH for mingw32

All patches bootstrapped/regtested i686-pc-linux-gnu.

Paolo

Re: Patch ping

[Richard Henderson]

On Tue, Jun 15, 2004 at 04:12:56PM +0100, Paul Brook wrote:
> My motivation for generating CIE version 3 entries is compatibility
> with third party tools which can't read CIE version 1 entries.

Grr.  Ok I guess.  Please pressure these third parties to DTRT
and add two lines of code to accept version 1 as well.


r~

Re: Patch ping

[Paul Brook]

On Monday 14 June 2004 23:56, Richard Henderson wrote:
> On Mon, Jun 14, 2004 at 12:10:23PM +0100, Paul Brook wrote:
> > Create DWARF3 cie frame entries:
> > http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00845.html
>
> Hum.  Given that this is the only difference between the two
> formats, I don't see the point of this particular test.
>
> Instead, test DWARF_FRAME_RETURN_COLUMN >= 256 and set the
> CIE version to 3 in that case, and output the uleb128.

My motivation for generating CIE version 3 entries is compatibility with third 
party tools which can't read CIE version 1 entries.

This affects targets where 128 <= DWARF_FRAME_RETURN_COLUMN < 256.
I don't know if there are any supported gcc targets where this is the case.

Paul

Re: Patch ping

[Richard Henderson]

On Mon, Jun 14, 2004 at 12:10:23PM +0100, Paul Brook wrote:
> Create DWARF3 cie frame entries:
> http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00845.html

Hum.  Given that this is the only difference between the two
formats, I don't see the point of this particular test.  

Instead, test DWARF_FRAME_RETURN_COLUMN >= 256 and set the
CIE version to 3 in that case, and output the uleb128.


r~

Re: Patch ping

[Daniel Jacobowitz]

On Mon, Jun 14, 2004 at 04:27:24PM +0100, Paul Brook wrote:
> On Monday 14 June 2004 16:16, Daniel Jacobowitz wrote:
> > On Mon, Jun 14, 2004 at 07:47:35AM -0700, Mark Mitchell wrote:
> > > Paul Brook wrote:
> > > >The following patch seems to have slipped past without comment.
> > > >
> > > >Create DWARF3 cie frame entries:
> > > >http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00845.html
> > > >
> > > >The infrastructure to support this change (ie. unwinder and debugger)
> > > >should now be in place.
> > >
> > > OK.
> >
> > Must we?  This will silently regress debugging support for anyone using
> > the most recent released version of GDB or the upcoming GDB 6.1.1.
> 
> It should have exactly zero impact because DW_CIE_VERSION is still 1. Unless 
> I'm missing something of course...

Oops, you're right.  Silly me, I assumed the patch did something :)

-- 
Daniel Jacobowitz

Re: Patch ping

[Paul Brook]

On Monday 14 June 2004 16:16, Daniel Jacobowitz wrote:
> On Mon, Jun 14, 2004 at 07:47:35AM -0700, Mark Mitchell wrote:
> > Paul Brook wrote:
> > >The following patch seems to have slipped past without comment.
> > >
> > >Create DWARF3 cie frame entries:
> > >http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00845.html
> > >
> > >The infrastructure to support this change (ie. unwinder and debugger)
> > >should now be in place.
> >
> > OK.
>
> Must we?  This will silently regress debugging support for anyone using
> the most recent released version of GDB or the upcoming GDB 6.1.1.

It should have exactly zero impact because DW_CIE_VERSION is still 1. Unless 
I'm missing something of course...

Paul

Re: Patch ping

[Daniel Jacobowitz]

On Mon, Jun 14, 2004 at 07:47:35AM -0700, Mark Mitchell wrote:
> Paul Brook wrote:
> 
> >The following patch seems to have slipped past without comment.
> >
> >Create DWARF3 cie frame entries:
> >http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00845.html
> >
> >The infrastructure to support this change (ie. unwinder and debugger) 
> >should now be in place.
> 
> OK.

Must we?  This will silently regress debugging support for anyone using
the most recent released version of GDB or the upcoming GDB 6.1.1.

I don't see any point in generating DWARF3 CIEs unless we actually have
a need for the uleb128.

-- 
Daniel Jacobowitz

Re: Patch ping

[Mark Mitchell]

Paul Brook wrote:

> The following patch seems to have slipped past without comment.
> 
> Create DWARF3 cie frame entries:
> http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00845.html
> 
> The infrastructure to support this change (ie. unwinder and debugger) should 
> now be in place.

OK.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Patch ping

[Paul Brook]

The following patch seems to have slipped past without comment.

Create DWARF3 cie frame entries:
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00845.html

The infrastructure to support this change (ie. unwinder and debugger) should 
now be in place.

Paul

Re: Patch ping

[Steve Kargl]

On Thu, Jun 10, 2004 at 04:54:44PM +0200, Tobias Schl?ter wrote:
> 
> These patches went unreviewed so far:
> 
> 1. Fix ICE with LEN intrinsic, PR 15211
> http://gcc.gnu.org/ml/fortran/2004-05/msg00402.html
> 
> 2. Passing NULL to a subroutine, PR 12841
> http://gcc.gnu.org/ml/fortran/2004-05/msg00408.html
> 
> 3. Alphabetize objects in Make-lang.in
> http://gcc.gnu.org/ml/fortran/2004-06/msg00023.html
> (I could commit this under the obviously correct rule, but I'd prefer if 
> someone had a second look on it, there might be a reason for the current 
> build order)
> 
> 4. Implement DATE_AND_TIME, PR14923
> http://gcc.gnu.org/ml/fortran/2004-06/msg00025.html
> (If this gets approved, I'd prefer if someone with a more recent 
> automake than I have could regenerate Makefile.in, I get a bunch of 
> warnings, but everything works)
> 
> 5. Fix two-argument variant of MINLOC/MAXLOC, PR14928
> http://gcc.gnu.org/ml/fortran/2004-06/msg00026.html
> 

Join the crowd.

http://gcc.gnu.org/ml/fortran/2004-06/msg00001.html

and I have another patch to fix random.c. that I
submit this week.

-- 
Steve

Patch ping

[Tobias Schlüter]

These patches went unreviewed so far:

1. Fix ICE with LEN intrinsic, PR 15211
http://gcc.gnu.org/ml/fortran/2004-05/msg00402.html

2. Passing NULL to a subroutine, PR 12841
http://gcc.gnu.org/ml/fortran/2004-05/msg00408.html

3. Alphabetize objects in Make-lang.in
http://gcc.gnu.org/ml/fortran/2004-06/msg00023.html
(I could commit this under the obviously correct rule, but I'd prefer if 
someone had a second look on it, there might be a reason for the current 
build order)

4. Implement DATE_AND_TIME, PR14923
http://gcc.gnu.org/ml/fortran/2004-06/msg00025.html
(If this gets approved, I'd prefer if someone with a more recent 
automake than I have could regenerate Makefile.in, I get a bunch of 
warnings, but everything works)

5. Fix two-argument variant of MINLOC/MAXLOC, PR14928
http://gcc.gnu.org/ml/fortran/2004-06/msg00026.html

- Tobi

patch ping

[jlquinn]

http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01712.html

Patch ping

[Ben Elliston]

Any comments?

http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00812.html

Ben

Patch ping

[Richard Guenther]

http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00187.html
[PATCH] Add leafify function attribute

Re: Patch Ping

[Ranjit Mathew]

(Note: Andrew's mails haven't been showing up on the lists for some reason.)

On Thu, 6 May 2004 13:58:42 +0100, Andrew Haley <aph@redhat.com> wrote:
> 
> Ranjit Mathew writes:
>  > Hi,
>  >
>  >     Can someone please review this patch:
>  >
>  > http://gcc.gnu.org/ml/java-patches/2004-q2/msg00230.html
>  >
>  > This fixes two PRs related to illegal package-private
>  > access.
> 
> Sorry, I thought this was already discussed and approved.  It is now.

Thanks, I have committed it.

Ranjit.

Patch ping

[Andrew Pinski]

http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02335.html
[patch] TSP based bb reordering

Re: Patch ping

[Richard Earnshaw]

On Wed, 2004-04-28 at 14:56, Paul Brook wrote:
> On Wednesday 28 April 2004 14:47, Richard Earnshaw wrote:
> > On Wed, 2004-04-28 at 14:33, Paul Brook wrote:
> > > Patch ping: Output dwarf expressions for memory locations involving
> > > shifts.
> > >
> > > http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00856.html
> > >
> > > Paul
> >
> > I don't think this is quite right.  The MULT code had some
> > simplifications when one of the operands was 0.  However, a shift by
> > zero is not the same as a multiply by zero -- the later results in zero,
> > the former is a NOP.
> 
> Are you sure?
> I see a check for (op0==0 || op1=0), but this is testing for successful 
> evaluation, not actual values.

Sorry, my mistake.  I'd misread the code.

Patch approved.

R.

Re: Patch ping

[Paul Brook]

On Wednesday 28 April 2004 14:47, Richard Earnshaw wrote:
> On Wed, 2004-04-28 at 14:33, Paul Brook wrote:
> > Patch ping: Output dwarf expressions for memory locations involving
> > shifts.
> >
> > http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00856.html
> >
> > Paul
>
> I don't think this is quite right.  The MULT code had some
> simplifications when one of the operands was 0.  However, a shift by
> zero is not the same as a multiply by zero -- the later results in zero,
> the former is a NOP.

Are you sure?
I see a check for (op0==0 || op1=0), but this is testing for successful 
evaluation, not actual values.

Paul

Re: Patch ping

[Roger Sayle]

On Wed, 28 Apr 2004, Paul Brook wrote:
> Patch ping: Output dwarf expressions for memory locations involving shifts.
> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00856.html

Fortunately, this is simple enough to understand even with my limited
knowledge of dwarf.  Ok for mainline.

Roger
--

Re: Patch ping

[Richard Earnshaw]

On Wed, 2004-04-28 at 14:33, Paul Brook wrote:
> Patch ping: Output dwarf expressions for memory locations involving shifts.
> 
> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00856.html
> 
> Paul

I don't think this is quite right.  The MULT code had some
simplifications when one of the operands was 0.  However, a shift by
zero is not the same as a multiply by zero -- the later results in zero,
the former is a NOP.

R.

Patch ping

[Paul Brook]

Patch ping: Output dwarf expressions for memory locations involving shifts.

http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00856.html

Paul

Re: Patch ping

[Zdenek Dvorak]

Hello,

>  >> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01148.html
>  >> -- the patch to prevent code with -fprofile-arcs and
>  >> -fbranch-probabilities from diverging before the
>  >> profile feedback pass (which may cause profile missmatches)
>  > this one is ok, wrt the libgcov bits
> 
> Hi Nathan.  Hi Zdenek.
> 
> The gcov changes broke powerpc-eabi*, and possibly all embedded
> targets.  See below.  "pid_t" is not declared where you think it is.
> 
> Aldy
> 
> In file included from
> /home/cygnus/aldyh/source/untainted-sources/uber/gcc/libgcov.c:51:
> /home/cygnus/aldyh/source/untainted-sources/uber/gcc/gcov-io.h:452:
> error: parse error before "__gcov_fork"
> /home/cygnus/aldyh/source/untainted-sources/uber/gcc/gcov-io.h:452:
> warning: type defaults to nt' in declaration of _gcov_fork'
> /home/cygnus/aldyh/source/untainted-sources/uber/gcc/gcov-io.h:452:
> warning: data definition has no type or storage class
> make[1]: *** [libgcc/./_gcov.o] Error 1

this patch fixes the problem, by not declaring the functions when
inhibit_libc is defined.  Commited as obvious.

Zdenek

	* gcov-io.h (__gcov_fork, __gcov_execl, __gcov_execlp,
	* __gcov_execle,
	__gcov_execv, __gcov_execvp, __gcov_execve): Do not
	declare when inhibit_libc is defined.

Index: gcov-io.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/gcov-io.h,v
retrieving revision 1.49
diff -c -3 -p -r1.49 gcov-io.h
*** gcov-io.h	23 Apr 2004 22:50:16 -0000	1.49
--- gcov-io.h	25 Apr 2004 16:33:30 -0000
*************** extern void __gcov_merge_single (gcov_ty
*** 448,453 ****
--- 448,454 ----
     consecutive values.  */
  extern void __gcov_merge_delta (gcov_type *, unsigned);
  
+ #ifndef inhibit_libc
  /* The wrappers around some library functions..  */
  extern pid_t __gcov_fork (void);
  extern int __gcov_execl (const char *, const char *, ...);
*************** extern int __gcov_execle (const char *, 
*** 456,461 ****
--- 457,463 ----
  extern int __gcov_execv (const char *, char *const []);
  extern int __gcov_execvp (const char *, char *const []);
  extern int __gcov_execve (const char *, char  *const [], char *const []);
+ #endif
  
  #endif /* IN_LIBGCOV */
  

Re: Patch ping

[Aldy Hernandez]

> does this help?

No.  The error is while including gcov-io.h, and your suggested fix
includes sys/types.h after gcov-io.h is included.

Even if I move the inclusion up, the build fails because sys/types.h
is not available:

/home/cygnus/aldyh/source/untainted-sources/uber/gcc/libgcov.c:51:23:
sys/types.h: No such file or directory

Can you try a cross build of powerpc-eabispe?

cheers.
Aldy

Re: Patch ping

[Zdenek Dvorak]

Hello,

> >>>>> "Nathan" == Nathan Sidwell <nathan@codesourcery.com> writes:
> 
>  >> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01148.html
>  >> -- the patch to prevent code with -fprofile-arcs and
>  >> -fbranch-probabilities from diverging before the
>  >> profile feedback pass (which may cause profile missmatches)
>  > this one is ok, wrt the libgcov bits
> 
> Hi Nathan.  Hi Zdenek.
> 
> The gcov changes broke powerpc-eabi*, and possibly all embedded
> targets.  See below.  "pid_t" is not declared where you think it is.

does this help?

Zdenek

Index: libgcov.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/libgcov.c,v
retrieving revision 1.25
diff -c -3 -p -r1.25 libgcov.c
*** libgcov.c	23 Apr 2004 22:50:16 -0000	1.25
--- libgcov.c	24 Apr 2004 19:39:12 -0000
*************** void __gcov_merge_delta (gcov_type *coun
*** 81,86 ****
--- 81,87 ----
  #include <errno.h>
  #include <sys/stat.h>
  #endif
+ #include <sys/types.h>
  
  #ifdef L_gcov
  #include "gcov-io.c"

Re: Patch ping

[Aldy Hernandez]

>>>>> "Nathan" == Nathan Sidwell <nathan@codesourcery.com> writes:

 >> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01148.html
 >> -- the patch to prevent code with -fprofile-arcs and
 >> -fbranch-probabilities from diverging before the
 >> profile feedback pass (which may cause profile missmatches)
 > this one is ok, wrt the libgcov bits

Hi Nathan.  Hi Zdenek.

The gcov changes broke powerpc-eabi*, and possibly all embedded
targets.  See below.  "pid_t" is not declared where you think it is.

Aldy

In file included from
/home/cygnus/aldyh/source/untainted-sources/uber/gcc/libgcov.c:51:
/home/cygnus/aldyh/source/untainted-sources/uber/gcc/gcov-io.h:452:
error: parse error before "__gcov_fork"
/home/cygnus/aldyh/source/untainted-sources/uber/gcc/gcov-io.h:452:
warning: type defaults to nt' in declaration of _gcov_fork'
/home/cygnus/aldyh/source/untainted-sources/uber/gcc/gcov-io.h:452:
warning: data definition has no type or storage class
make[1]: *** [libgcc/./_gcov.o] Error 1

Re: Patch ping

[Roger Sayle]

On Fri, 23 Apr 2004, Zdenek Dvorak wrote:
> > >http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01148.html
> > >  -- the patch to prevent code with -fprofile-arcs and
> > >     -fbranch-probabilities from diverging before the
> > >     profile feedback pass (which may cause profile missmatches)
> > this one is ok, wrt the libgcov bits
>
> but you cannot approve the builtins.c/calls.c changes, right?

These bits are OK for mainline, too.

Roger
--

Re: Patch ping

[Zdenek Dvorak]

Hello,

> >http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01148.html
> >  -- the patch to prevent code with -fprofile-arcs and
> >     -fbranch-probabilities from diverging before the
> >     profile feedback pass (which may cause profile missmatches)
> this one is ok, wrt the libgcov bits

but you cannot approve the builtins.c/calls.c changes, right?

Zdenek

Re: Patch ping

[Nathan Sidwell]

Zdenek Dvorak wrote:
> Hello,
> 
> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00177.html
>   -- enables unrolling of loops with <= n exit condition
> 
> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00802.html
>   -- [tree-ssa] fixes kill_redundant_phi_nodes
> 
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01148.html
>   -- the patch to prevent code with -fprofile-arcs and
>      -fbranch-probabilities from diverging before the
>      profile feedback pass (which may cause profile missmatches)
this one is ok, wrt the libgcov bits

> 
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01150.html
>   -- speculative prefetching
> 
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02335.html
>   -- tsp based bb reordering
> 
> Zdenek


-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Patch ping

[Zdenek Dvorak]

Hello,

http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00177.html
  -- enables unrolling of loops with <= n exit condition

http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00802.html
  -- [tree-ssa] fixes kill_redundant_phi_nodes

http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01148.html
  -- the patch to prevent code with -fprofile-arcs and
     -fbranch-probabilities from diverging before the
     profile feedback pass (which may cause profile missmatches)

http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01150.html
  -- speculative prefetching

http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02335.html
  -- tsp based bb reordering

Zdenek

Patch ping

[Paolo Bonzini]

http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00911.html
Fix PR/14899 by having comptypes recurse on vector types

Paolo

Re: Patch ping

[Roger Sayle]

On Mon, 19 Apr 2004, Josef Zlomek wrote:
> Fix ICE when building glibc on ppc64
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg00045.html

This is OK for mainline.


> Fix bug in varible tracking - wrong location lists in some situations
> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00272.html

As is this.


Thanks.

Roger
--

Patch ping

[Josef Zlomek]

Please could someone review following patches?


Fix ICE when building glibc on ppc64
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg00045.html


Fix bug in varible tracking - wrong location lists in some situations
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00272.html


Thanks,

josef

Re: Patch ping

[Richard Earnshaw]

On Mon, 2004-04-19 at 14:16, Paul Brook wrote:
> On Monday 19 April 2004 13:57, Andreas Schwab wrote:
> > "Paolo Bonzini" <bonzini@gnu.org> writes:
> > >> Paolo,
> > >>
> > >> on which platform did you bootstrap this?
> > >
> > > i686-pc-linux-gnu, all languages except Ada/treelang.
> > >
> > >> It causes build errors on
> > >> both Linux/x86-64 and Linux/ia64 as reported by Andreas Schwab and
> > >> myself on the main GCC list yesterday.
> > >>
> > >> Please fix the regressions that your patch has caused.
> > >
> > > As I wrote on gcc, I don't think I can be blamed on this.  The bugs are
> > > not in the code I touched, but only in the code I enabled.  All I can do
> > > is disabling -frename-registers on the affected archs, as per the
> > > attached patch disable-ada-rename-regs.patch.
> >
> > This has nothing to do with Ada, the same error happens with libstdc++ as
> > well, see <http://gcc.gnu.org/ml/gcc/2004-04/msg00830.html>. It seems like
> > -frename-registers is generally broken, or triggers generally broken code.
> 
> It also breaks libstdc++ on arm/thumb.
> 
> Paul

If you are seeing this bug:

/work/rearnsha/gnu/egcs/gcc/xgcc -shared-libgcc -B/work/rearnsha/gnu/egcs/gcc/ -
nostdinc++ -L/work/rearnsha/gnu/egcs/arm-elf/libstdc++-v3/src -L/work/rearnsha/g
nu/egcs/arm-elf/libstdc++-v3/src/.libs -nostdinc -B/work/rearnsha/gnu/egcs/arm-e
lf/newlib/ -isystem /work/rearnsha/gnu/egcs/arm-elf/newlib/targ-include -isystem
 /home/rearnsha/gnusrc/egcs-cross/newlib/libc/include -B/work/rearnsha/gnu/testi
nstall/arm-elf/bin/ -B/work/rearnsha/gnu/testinstall/arm-elf/lib/ -isystem /work
/rearnsha/gnu/testinstall/arm-elf/include -isystem /work/rearnsha/gnu/testinstal
l/arm-elf/sys-include -L/work/rearnsha/gnu/egcs/ld -I/work/rearnsha/gnu/egcs/arm
-elf/libstdc++-v3/include/arm-elf -I/work/rearnsha/gnu/egcs/arm-elf/libstdc++-v3
/include -I/home/rearnsha/gnusrc/egcs-cross/libstdc++-v3/libsupc++ -O2 -g -O2 -g
 -O2 -fno-implicit-templates -Wall -W -Wwrite-strings -Wcast-qual -fdiagnostics-
show-location=once -c /home/rearnsha/gnusrc/egcs-cross/libstdc++-v3/src/complex_
io.cc -o complex_io.o
/work/rearnsha/gnu/egcs/arm-elf/libstdc++-v3/include/complex: In function `std::
basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Trai
ts>&, conststd::complex<_Tp>&) [with _Tp = float, _CharT = char, _Traits = std::
char_traits<char>]':
/work/rearnsha/gnu/egcs/arm-elf/libstdc++-v3/include/complex:1455: error: insn d
oes not satisfy its constraints:
(insn:HI 2559 6401 6402 47 /work/rearnsha/gnu/egcs/arm-elf/libstdc++-v3/include/
streambuf:187 (set (mem/s:SI (post_modify:SI (reg:SI 12 ip)
                (plus:SI (reg:SI 12 ip)
                    (const_int 28 [0x1c]))) [9 <variable>._vptr.basic_streambuf+
0 S4 A32])
        (reg/f:SI 3 r3 [314])) 140 {*arm_movsi_insn} (insn_list 2558 (nil))
    (expr_list:REG_DEAD (reg/f:SI 3 r3 [314])
        (expr_list:REG_INC (reg:SI 12 ip)
            (nil))))

Then I think this is because arm_legitimate_address_p is doing something
wrong.  Probably this test:

  else if ((GET_CODE (x) == POST_MODIFY || GET_CODE (x) == PRE_MODIFY)
	   && GET_MODE_SIZE (mode) <= 4
	   && arm_address_register_rtx_p (XEXP (x, 0), strict_p)
	   && GET_CODE (XEXP (x, 1)) == PLUS
	   && XEXP (XEXP (x, 1), 0) == XEXP (x, 0))

That final equivalence should probably be using rtx_equal_p(), but I
haven't tested that yet.

R.

Re: Patch ping

[Richard Earnshaw]

On Mon, 2004-04-19 at 13:57, Andreas Schwab wrote:
> "Paolo Bonzini" <bonzini@gnu.org> writes:
> 
> >> Paolo,
> >>
> >> on which platform did you bootstrap this?
> >
> > i686-pc-linux-gnu, all languages except Ada/treelang.
> >
> >> It causes build errors on
> >> both Linux/x86-64 and Linux/ia64 as reported by Andreas Schwab and
> >> myself on the main GCC list yesterday.
> >>
> >> Please fix the regressions that your patch has caused.
> >
> > As I wrote on gcc, I don't think I can be blamed on this.  The bugs are not
> > in the code I touched, but only in the code I enabled.  All I can do is
> > disabling -frename-registers on the affected archs, as per the attached
> > patch disable-ada-rename-regs.patch.
> 
> This has nothing to do with Ada, the same error happens with libstdc++ as
> well, see <http://gcc.gnu.org/ml/gcc/2004-04/msg00830.html>. It seems like
> -frename-registers is generally broken, or triggers generally broken code.

Not to mention the fact that it also appears to be a major CPU hog. 
Depending on the platform this can cause up to about 4% increase in
compile times.

R.

Re: Patch ping

[Paul Brook]

On Monday 19 April 2004 13:57, Andreas Schwab wrote:
> "Paolo Bonzini" <bonzini@gnu.org> writes:
> >> Paolo,
> >>
> >> on which platform did you bootstrap this?
> >
> > i686-pc-linux-gnu, all languages except Ada/treelang.
> >
> >> It causes build errors on
> >> both Linux/x86-64 and Linux/ia64 as reported by Andreas Schwab and
> >> myself on the main GCC list yesterday.
> >>
> >> Please fix the regressions that your patch has caused.
> >
> > As I wrote on gcc, I don't think I can be blamed on this.  The bugs are
> > not in the code I touched, but only in the code I enabled.  All I can do
> > is disabling -frename-registers on the affected archs, as per the
> > attached patch disable-ada-rename-regs.patch.
>
> This has nothing to do with Ada, the same error happens with libstdc++ as
> well, see <http://gcc.gnu.org/ml/gcc/2004-04/msg00830.html>. It seems like
> -frename-registers is generally broken, or triggers generally broken code.

It also breaks libstdc++ on arm/thumb.

Paul

Re: Patch ping

[Andreas Schwab]

"Paolo Bonzini" <bonzini@gnu.org> writes:

>> Paolo,
>>
>> on which platform did you bootstrap this?
>
> i686-pc-linux-gnu, all languages except Ada/treelang.
>
>> It causes build errors on
>> both Linux/x86-64 and Linux/ia64 as reported by Andreas Schwab and
>> myself on the main GCC list yesterday.
>>
>> Please fix the regressions that your patch has caused.
>
> As I wrote on gcc, I don't think I can be blamed on this.  The bugs are not
> in the code I touched, but only in the code I enabled.  All I can do is
> disabling -frename-registers on the affected archs, as per the attached
> patch disable-ada-rename-regs.patch.

This has nothing to do with Ada, the same error happens with libstdc++ as
well, see <http://gcc.gnu.org/ml/gcc/2004-04/msg00830.html>. It seems like
-frename-registers is generally broken, or triggers generally broken code.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Patch ping

[Paolo Bonzini]

> I just tested all patches together and now is build fine for me.
> Testresults will soon be on the testresults list.


Thanks.  Of course the problem will have to be looked at more carefully, and
the workarounds are in general insufficient.  Also, on ia64-pc-linux-gnu C++
fails which is more severe, so I'm setting up a combined tree for ia64.

Paolo

Re: Patch ping

[Arnaud Charlet]

> Dense MS Outlook Express. :-(

You first patch causes cpu usage problem as mentioned by Laurent,
so that's probably not reasonable. In addition, maintaining a
baseline of all failures on all these levels of switches will also be
very painful.

-O0 was clearly the simplest (in particular on platforms where optimizations
are somewhat fragile), and has the advantage of being clean on a few
platforms, making it easier to perform comparisons.

-O2 is a good compromise, since as shown recently, it is often the
case that middle-end or optimization bugs only show up in the context of
Ada code, although not specifically Ada related.

As for your second patch, that's really a temporary work around, since the
bugs shown are most likely general bugs not Ada specific, and that
will likely appear in complex C/C++ code as well. As such, it should
really be marked with comments explaining why the code is there, and
that it's temporary. A bugzilla PR should also be opened to remind us
that you've put in place this temporary work around.

Arno

Re: Patch ping

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

"Paolo Bonzini" <bonzini@gnu.org> writes:

>> Paolo,
>>
>> on which platform did you bootstrap this?
>
> i686-pc-linux-gnu, all languages except Ada/treelang.
>
>> It causes build errors on
>> both Linux/x86-64 and Linux/ia64 as reported by Andreas Schwab and
>> myself on the main GCC list yesterday.
>>
>> Please fix the regressions that your patch has caused.
>
> As I wrote on gcc, I don't think I can be blamed on this.  The bugs are not
> in the code I touched, but only in the code I enabled.  All I can do is
> disabling -frename-registers on the affected archs, as per the attached
> patch disable-ada-rename-regs.patch.
>
> Also, I guess would have been found earlier if the Ada testsuite had tested
> all optimization levels instead of -O2 only (and it used to be -O0, which
> seems really strange to me!).  Can you please try the attached
> ada-testsuite.patch on a two-three days old gcc, on Linux/x86-64 and/or
> Linux/ia64?

I just tested all patches together and now is build fine for me.
Testresults will soon be on the testresults list.

But this should be fixed properly instead of worked around.

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Patch ping

[Paolo Bonzini]

> > Also, I guess would have been found earlier if the Ada testsuite had
tested
> > all optimization levels [...]
>
> Well, if you don't include Ada in the build, the Ada testsuite flags
> don't matter much :).

Well, failures on ia64 will go unnoticed on i686 even if I include Ada in
the build.

> Any reason that Ada is not running on your
> i686-pc-linux-gnu machine? (most distribution have Ada lying around
> these days)

I've not spent much time looking at it, but all I could find in Debian
(apt-get install gnat) is a gcc-2.8.1 based gnat which is not picked up by
configure (its gnatmake does not invoke the installed gcc).

> For Ada we have to make a trade-off, running once the Ada testsuite
> takes more time the whole C language test suite (28 minutes vs 17
> minutes on my Athlon 2600+), so running 5 times the Ada testsuite
> is not something that will go unnoticed :).

I see.

Paolo

Re: Patch ping

[Laurent GUERBY]

On Mon, 2004-04-19 at 11:48, Paolo Bonzini wrote:
> i686-pc-linux-gnu, all languages except Ada/treelang.
...
> Also, I guess would have been found earlier if the Ada testsuite had tested
> all optimization levels [...]

Well, if you don't include Ada in the build, the Ada testsuite flags
don't matter much :). Any reason that Ada is not running on your
i686-pc-linux-gnu machine? (most distribution have Ada lying around
these days)

I suggested some time ago to use -O2 instead of -O0 but the proposition
was rejected, hopefully it's now in.

For Ada we have to make a trade-off, running once the Ada testsuite
takes more time the whole C language test suite (28 minutes vs 17
minutes on my Athlon 2600+), so running 5 times the Ada testsuite
is not something that will go unnoticed :).

Laurent

Re: Patch ping

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 4155 bytes --]

"Paolo Bonzini" <bonzini@gnu.org> writes:

>> Paolo,
>>
>> on which platform did you bootstrap this?
>
> i686-pc-linux-gnu, all languages except Ada/treelang.
>
>> It causes build errors on
>> both Linux/x86-64 and Linux/ia64 as reported by Andreas Schwab and
>> myself on the main GCC list yesterday.
>>
>> Please fix the regressions that your patch has caused.
>
> As I wrote on gcc, I don't think I can be blamed on this.  The bugs are not
> in the code I touched, but only in the code I enabled.  All I can do is
> disabling -frename-registers on the affected archs, as per the attached
> patch disable-ada-rename-regs.patch.

The GCC development rules state that you have to fix the code.  Even
if it's a latent bug that is only introduced by your changes.

> Also, I guess would have been found earlier if the Ada testsuite had tested
> all optimization levels instead of -O2 only (and it used to be -O0, which
> seems really strange to me!).  Can you please try the attached
> ada-testsuite.patch on a two-three days old gcc, on Linux/x86-64 and/or
> Linux/ia64?

I'll test the complete patch now,

Andreas

> Ok to commit both patches?
>
> Paolo
>
>
>
> Index: run_acats
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/testsuite/ada/acats/run_acats,v
> retrieving revision 1.5
> diff -u -r1.5 run_acats
> --- run_acats	8 Jan 2004 15:19:36 -0000	1.5
> +++ run_acats	19 Apr 2004 09:34:16 -0000
> @@ -51,4 +51,8 @@
>  
>  chmod +x host_gnatmake
>  
> -exec $testdir/run_all.sh "$@"
> +gccflags=-O0 $testdir/run_all.sh "$@"
> +gccflags=-O1 $testdir/run_all.sh "$@"
> +gccflags=-O2 $testdir/run_all.sh "$@"
> +gccflags=-O3 $testdir/run_all.sh "$@"
> +gccflags=-Os $testdir/run_all.sh "$@"
> Index: run_all.sh
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/testsuite/ada/acats/run_all.sh,v
> retrieving revision 1.15
> diff -u -r1.15 run_all.sh
> --- run_all.sh	17 Apr 2004 17:14:18 -0000	1.15
> +++ run_all.sh	19 Apr 2004 09:34:16 -0000
> @@ -9,8 +9,8 @@
>  # gccflags="-O3 -fomit-frame-pointer -funroll-all-loops -finline-functions"
>  # gnatflags="-gnatN"
>  
> -gccflags="-O2"
> -gnatflags="-gnatws"
> +: ${gccflags="-O2"}
> +: ${gnatflags="-gnatws"}
>  
>  target_run () {
>  $*
> @@ -78,6 +78,9 @@
>  display `type gnatmake`
>  gnatls -v >> $dir/acats.log
>  display ""
> +display gcc options are "${gccflags}"
> +display gnatmake options are "${gccflags} ${gnatflags}"
> +display ""
>  
>  display "		=== acats support ==="
>  display_noeol "Generating support files..."
> @@ -152,6 +155,9 @@
>  display " done."
>  display ""
>  display "		=== acats tests ==="
> +display ""
> +display gcc options are "${gccflags}"
> +display gnatmake options are "${gccflags} ${gnatflags}"
>  
>  if [ $# -eq 0 ]; then
>     chapters=`cd $dir/tests; echo [a-z]*`
>
> Index: i386/t-linux64
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/config/i386/t-linux64,v
> retrieving revision 1.5
> diff -u -r1.5 t-linux64
> --- i386/t-linux64	28 Nov 2002 14:47:02 -0000	1.5
> +++ i386/t-linux64	19 Apr 2004 09:43:41 -0000
> @@ -18,3 +18,5 @@
>  # because then __FRAME_END__ might not be the last thing in .eh_frame
>  # section.
>  CRTSTUFF_T_CFLAGS = -fno-omit-frame-pointer -fno-asynchronous-unwind-tables
> +
> +T_ADA_CFLAGS = -fno-rename-registers
> Index: ia64/t-ia64
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/config/ia64/t-ia64,v
> retrieving revision 1.21
> diff -u -r1.21 t-ia64
> --- ia64/t-ia64	29 Oct 2003 16:21:36 -0000	1.21
> +++ ia64/t-ia64	19 Apr 2004 09:43:41 -0000
> @@ -49,3 +49,5 @@
>  
>  # genattrtab generates very long string literals.
>  insn-attrtab.o-warn = -Wno-error
> +
> +T_ADA_CFLAGS = -fno-rename-registers

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Patch ping

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 148 bytes --]

> uuencoded format is kind of antiquated these days, and not easily
> dealt without painful manual processing.

Dense MS Outlook Express. :-(

Paolo

[-- Attachment #2: ada-testsuite.patch --]
[-- Type: application/octet-stream, Size: 1646 bytes --]

Index: run_acats
===================================================================
RCS file: /cvs/gcc/gcc/gcc/testsuite/ada/acats/run_acats,v
retrieving revision 1.5
diff -u -r1.5 run_acats
--- run_acats	8 Jan 2004 15:19:36 -0000	1.5
+++ run_acats	19 Apr 2004 09:34:16 -0000
@@ -51,4 +51,8 @@
 
 chmod +x host_gnatmake
 
-exec $testdir/run_all.sh "$@"
+gccflags=-O0 $testdir/run_all.sh "$@"
+gccflags=-O1 $testdir/run_all.sh "$@"
+gccflags=-O2 $testdir/run_all.sh "$@"
+gccflags=-O3 $testdir/run_all.sh "$@"
+gccflags=-Os $testdir/run_all.sh "$@"
Index: run_all.sh
===================================================================
RCS file: /cvs/gcc/gcc/gcc/testsuite/ada/acats/run_all.sh,v
retrieving revision 1.15
diff -u -r1.15 run_all.sh
--- run_all.sh	17 Apr 2004 17:14:18 -0000	1.15
+++ run_all.sh	19 Apr 2004 09:34:16 -0000
@@ -9,8 +9,8 @@
 # gccflags="-O3 -fomit-frame-pointer -funroll-all-loops -finline-functions"
 # gnatflags="-gnatN"
 
-gccflags="-O2"
-gnatflags="-gnatws"
+: ${gccflags="-O2"}
+: ${gnatflags="-gnatws"}
 
 target_run () {
 $*
@@ -78,6 +78,9 @@
 display `type gnatmake`
 gnatls -v >> $dir/acats.log
 display ""
+display gcc options are "${gccflags}"
+display gnatmake options are "${gccflags} ${gnatflags}"
+display ""
 
 display "		=== acats support ==="
 display_noeol "Generating support files..."
@@ -152,6 +155,9 @@
 display " done."
 display ""
 display "		=== acats tests ==="
+display ""
+display gcc options are "${gccflags}"
+display gnatmake options are "${gccflags} ${gnatflags}"
 
 if [ $# -eq 0 ]; then
    chapters=`cd $dir/tests; echo [a-z]*`

[-- Attachment #3: disable-ada-rename-regs.patch --]
[-- Type: application/octet-stream, Size: 947 bytes --]

Index: i386/t-linux64
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/i386/t-linux64,v
retrieving revision 1.5
diff -u -r1.5 t-linux64
--- i386/t-linux64	28 Nov 2002 14:47:02 -0000	1.5
+++ i386/t-linux64	19 Apr 2004 09:43:41 -0000
@@ -18,3 +18,5 @@
 # because then __FRAME_END__ might not be the last thing in .eh_frame
 # section.
 CRTSTUFF_T_CFLAGS = -fno-omit-frame-pointer -fno-asynchronous-unwind-tables
+
+T_ADA_CFLAGS = -fno-rename-registers
Index: ia64/t-ia64
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/ia64/t-ia64,v
retrieving revision 1.21
diff -u -r1.21 t-ia64
--- ia64/t-ia64	29 Oct 2003 16:21:36 -0000	1.21
+++ ia64/t-ia64	19 Apr 2004 09:43:41 -0000
@@ -49,3 +49,5 @@
 
 # genattrtab generates very long string literals.
 insn-attrtab.o-warn = -Wno-error
+
+T_ADA_CFLAGS = -fno-rename-registers

Re: Patch ping

[Arnaud Charlet]

> Ok to commit both patches?

Could you resubmit your patch in plain text, and/or as standard
mime attachments ? thanks.

uuencoded format is kind of antiquated these days, and not easily
dealt without painful manual processing.

Arno

Re: Patch ping

[Paolo Bonzini]

> Paolo,
>
> on which platform did you bootstrap this?

i686-pc-linux-gnu, all languages except Ada/treelang.

> It causes build errors on
> both Linux/x86-64 and Linux/ia64 as reported by Andreas Schwab and
> myself on the main GCC list yesterday.
>
> Please fix the regressions that your patch has caused.

As I wrote on gcc, I don't think I can be blamed on this.  The bugs are not
in the code I touched, but only in the code I enabled.  All I can do is
disabling -frename-registers on the affected archs, as per the attached
patch disable-ada-rename-regs.patch.

Also, I guess would have been found earlier if the Ada testsuite had tested
all optimization levels instead of -O2 only (and it used to be -O0, which
seems really strange to me!).  Can you please try the attached
ada-testsuite.patch on a two-three days old gcc, on Linux/x86-64 and/or
Linux/ia64?

Ok to commit both patches?

Paolo


begin 666 ada-testsuite.patch
M26YD97@Z(')U;E]A8V%T<PH]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]"E)#4R!F
M:6QE.B O8W9S+V=C8R]G8V,O9V-C+W1E<W1S=6ET92]A9&$O86-A=',O<G5N
M7V%C871S+'8*<F5T<FEE=FEN9R!R979I<VEO;B Q+C4*9&EF9B M=2 M<C$N
M-2!R=6Y?86-A=',*+2TM(')U;E]A8V%T<PDX($IA;B R,# T(#$U.C$Y.C,V
M("TP,# P"3$N-0HK*RL@<G5N7V%C871S"3$Y($%P<B R,# T(# Y.C,T.C$V
M("TP,# P"D! ("TU,2PT("LU,2PX($! "B *(&-H;6]D("MX(&AO<W1?9VYA
M=&UA:V4*( HM97AE8R D=&5S=&1I<B]R=6Y?86QL+G-H("(D0"(**V=C8V9L
M86=S/2U/," D=&5S=&1I<B]R=6Y?86QL+G-H("(D0"(**V=C8V9L86=S/2U/
M,2 D=&5S=&1I<B]R=6Y?86QL+G-H("(D0"(**V=C8V9L86=S/2U/,B D=&5S
M=&1I<B]R=6Y?86QL+G-H("(D0"(**V=C8V9L86=S/2U/,R D=&5S=&1I<B]R
M=6Y?86QL+G-H("(D0"(**V=C8V9L86=S/2U/<R D=&5S=&1I<B]R=6Y?86QL
M+G-H("(D0"(*26YD97@Z(')U;E]A;&PN<V@*/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/0I20U,@9FEL93H@+V-V<R]G8V,O9V-C+V=C8R]T97-T<W5I=&4O861A
M+V%C871S+W)U;E]A;&PN<V@L=@IR971R:65V:6YG(')E=FES:6]N(#$N,34*
M9&EF9B M=2 M<C$N,34@<G5N7V%L;"YS: HM+2T@<G5N7V%L;"YS: DQ-R!!
M<'(@,C P-" Q-SHQ-#HQ." M,# P, DQ+C$U"BLK*R!R=6Y?86QL+G-H"3$Y
M($%P<B R,# T(# Y.C,T.C$V("TP,# P"D! ("TY+#@@*SDL."! 0 H@(R!G
M8V-F;&%G<STB+4\S("UF;VUI="UF<F%M92UP;VEN=&5R("UF=6YR;VQL+6%L
M;"UL;V]P<R M9FEN;&EN92UF=6YC=&EO;G,B"B C(&=N871F;&%G<STB+6=N
M871.(@H@"BUG8V-F;&%G<STB+4\R(@HM9VYA=&9L86=S/2(M9VYA='=S(@HK
M.B D>V=C8V9L86=S/2(M3S(B?0HK.B D>V=N871F;&%G<STB+6=N871W<R)]
M"B *('1A<F=E=%]R=6X@*"D@>PH@)"H*0$ @+3<X+#8@*S<X+#D@0$ *(&1I
M<W!L87D@8'1Y<&4@9VYA=&UA:V5@"B!G;F%T;',@+78@/CX@)&1I<B]A8V%T
M<RYL;V<*(&1I<W!L87D@(B(**V1I<W!L87D@9V-C(&]P=&EO;G,@87)E("(D
M>V=C8V9L86=S?2(**V1I<W!L87D@9VYA=&UA:V4@;W!T:6]N<R!A<F4@(B1[
M9V-C9FQA9W-]("1[9VYA=&9L86=S?2(**V1I<W!L87D@(B(*( H@9&ES<&QA
M>2 B"0D]/3T@86-A=',@<W5P<&]R=" ]/3TB"B!D:7-P;&%Y7VYO96]L(")'
M96YE<F%T:6YG('-U<'!O<G0@9FEL97,N+BXB"D! ("TQ-3(L-B K,34U+#D@
M0$ *(&1I<W!L87D@(B!D;VYE+B(*(&1I<W!L87D@(B(*(&1I<W!L87D@(@D)
M/3T](&%C871S('1E<W1S(#T]/2(**V1I<W!L87D@(B(**V1I<W!L87D@9V-C
M(&]P=&EO;G,@87)E("(D>V=C8V9L86=S?2(**V1I<W!L87D@9VYA=&UA:V4@
M;W!T:6]N<R!A<F4@(B1[9V-C9FQA9W-]("1[9VYA=&9L86=S?2(*( H@:68@
M6R D(R M97$@,"!=.R!T:&5N"B @("!C:&%P=&5R<SU@8V0@)&1I<B]T97-T
0<SL@96-H;R!;82UZ72I@"@``
`
end

begin 666 disable-ada-rename-regs.patch
M26YD97@Z(&DS.#8O="UL:6YU>#8T"CT]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T*
M4D-3(&9I;&4Z("]C=G,O9V-C+V=C8R]G8V,O8V]N9FEG+VDS.#8O="UL:6YU
M>#8T+'8*<F5T<FEE=FEN9R!R979I<VEO;B Q+C4*9&EF9B M=2 M<C$N-2!T
M+6QI;G5X-C0*+2TM(&DS.#8O="UL:6YU>#8T"3(X($YO=B R,# R(#$T.C0W
M.C R("TP,# P"3$N-0HK*RL@:3,X-B]T+6QI;G5X-C0),3D@07!R(#(P,#0@
M,#DZ-#,Z-#$@+3 P,# *0$ @+3$X+#,@*S$X+#4@0$ *(",@8F5C875S92!T
M:&5N(%]?1E)!345?14Y$7U\@;6EG:'0@;F]T(&)E('1H92!L87-T('1H:6YG
M(&EN("YE:%]F<F%M90H@(R!S96-T:6]N+@H@0U)44U151D9?5%]#1DQ!1U,@
M/2 M9FYO+6]M:70M9G)A;64M<&]I;G1E<B M9FYO+6%S>6YC:')O;F]U<RUU
M;G=I;F0M=&%B;&5S"BL**U1?041!7T-&3$%'4R ]("UF;F\M<F5N86UE+7)E
M9VES=&5R<PI);F1E>#H@:6$V-"]T+6EA-C0*/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/0I20U,@9FEL93H@+V-V<R]G8V,O9V-C+V=C8R]C;VYF:6<O:6$V-"]T
M+6EA-C0L=@IR971R:65V:6YG(')E=FES:6]N(#$N,C$*9&EF9B M=2 M<C$N
M,C$@="UI838T"BTM+2!I838T+W0M:6$V- DR.2!/8W0@,C P,R Q-CHR,3HS
M-B M,# P, DQ+C(Q"BLK*R!I838T+W0M:6$V- DQ.2!!<'(@,C P-" P.3HT
M,SHT,2 M,# P, I 0" M-#DL,R K-#DL-2! 0 H@"B C(&=E;F%T=')T86(@
M9V5N97)A=&5S('9E<GD@;&]N9R!S=')I;F<@;&ET97)A;',N"B!I;G-N+6%T
M=')T86(N;RUW87)N(#T@+5=N;RUE<G)O<@HK"BM47T%$05]#1DQ!1U,@/2 M
59FYO+7)E;F%M92UR96=I<W1E<G,*
`
end

Re: Patch ping

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

Geoff Keating <geoffk@geoffk.org> writes:

> "Paolo Bonzini" <bonzini@gnu.org> writes:
>
>> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00384.html
>> Enables -fweb at -O2 and -frename-registers at -O1 if variable
>> tracking is available for the target's default debugging information
>> format.
>> 
>> Ok for mainline?
>
> This is OK, assuming you bootstrapped it on at least one platform.

Paolo,

on which platform did you bootstrap this?  It causes build errors on
both Linux/x86-64 and Linux/ia64 as reported by Andreas Schwab and
myself on the main GCC list yesterday.

Please fix the regressions that your patch has caused.

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Patch ping

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

Geoff Keating <geoffk@geoffk.org> writes:

> "Paolo Bonzini" <bonzini@gnu.org> writes:
>
>> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00384.html
>> Enables -fweb at -O2 and -frename-registers at -O1 if variable
>> tracking is available for the target's default debugging information
>> format.
>> 
>> Ok for mainline?
>
> This is OK, assuming you bootstrapped it on at least one platform.

Paolo,

on which platform did you bootstrap this?  It causes build errors on
both Linux/x86-64 and Linux/ia64 as reported by Andreas Schwab and
myself on the main GCC list yesterday.

Please fix the regressions that your patch has caused.

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Patch ping

[Geoff Keating]

"Paolo Bonzini" <bonzini@gnu.org> writes:

> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00384.html
> Enables -fweb at -O2 and -frename-registers at -O1 if variable
> tracking is available for the target's default debugging information
> format.
> 
> Ok for mainline?

This is OK, assuming you bootstrapped it on at least one platform.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Patch ping

[Paolo Bonzini]

http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00384.html
Enables -fweb at -O2 and -frename-registers at -O1 if variable
tracking is available for the target's default debugging information
format.

Ok for mainline?

Paolo

Patch ping

[Ian Lance Taylor]

Patch ping:

http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01585.html
  Fix PR target/14548, clean up USE_COLLECT2 and make it
  host-dependent rather than target-dependent

http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01445.html
  Change collect2 to not call vfork, as a step toward making it
  buildable on hosts which can not fork

Thanks.

Ian

patch ping...

[Eric Christopher]

http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01649.html

Thanks.

-eric

-- 
Eric Christopher <echristo@redhat.com>

Patch ping

[Zdenek Dvorak]

Hello,

http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01733.html
  -- doloop optimization rewrite

http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01548.html
  -- removal of unused code from simple loop analysis

Zdenek

Re: Patch ping

[Zack Weinberg]

Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> writes:

> Hello,
>
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01733.html
>   -- doloop optimization rewrite

not qualified to review this one, sorry.

> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01548.html
>   -- removal of unused code from simple loop analysis

this, however, is ok.

zw

Re: Patch ping

[Zack Weinberg]

Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> writes:

> Hello,
>
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01733.html
>   -- doloop optimization rewrite

not qualified to review this one, sorry.

> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01548.html
>   -- removal of unused code from simple loop analysis

this, however, is ok.

zw

Patch ping

[Zdenek Dvorak]

Hello,

http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01733.html
  -- doloop optimization rewrite

http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01548.html
  -- removal of unused code from simple loop analysis

Zdenek

patch ping

[Alan Modra]

Move special treatment of relative prefixes into add_sysrooted_prefix.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00634.html

rs6000 va_arg support for long double
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00632.html

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

patch ping

[Alan Modra]

I know it's only been a few days, but the rs6000 bit has been OK'd
and the rest is just a mechanical change.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00071.html

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: patch ping

[Alan Modra]

On Fri, Feb 06, 2004 at 11:40:23AM +0100, Andreas Schwab wrote:
> ../../gcc/ada/misc.c:867:52: macro "INIT_CUMULATIVE_ARGS" requires 5 arguments, but only 4 given

Oops.  Fixed with the obvious patch.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Patch ping

[Zdenek Dvorak]

Hello,

http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01348.html
  -- a rewrite of mark_irreducible_loops function (since I found out
     that I no longer understand how it works, and was unable to fix
     a bug in it).

Zdenek

Patch ping

[Paolo Bonzini]

Please review these two patches.

http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03481.html
1.3% speed improvement on bootstrap

http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02845.html
Split a 1080-line function

Paolo

Re: patch ping

[Andreas Schwab]

Alan Modra <amodra@bigpond.net.au> writes:

> I know it's only been a few days, but the rs6000 bit has been OK'd
> and the rest is just a mechanical change.
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00071.html

Breaks bootstrap.

gcc -c   -O2 -g -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes     -fno-common   -DHAVE_CONFIG_H    -I. -Iada -I../../gcc -I../../gcc/ada -I../../gcc/../include  ../../gcc/ada/misc.c -o ada/misc.o
../../gcc/ada/misc.c:867:52: macro "INIT_CUMULATIVE_ARGS" requires 5 arguments, but only 4 given
../../gcc/ada/misc.c: In function `default_pass_by_ref':
../../gcc/ada/misc.c:867: error: `INIT_CUMULATIVE_ARGS' undeclared (first use in this function)
../../gcc/ada/misc.c:867: error: (Each undeclared identifier is reported only once
../../gcc/ada/misc.c:867: error: for each function it appears in.)
make[2]: *** [ada/misc.o] Error 1
make[2]: Leaving directory `/tmp/cvs/gcc-20040206/Build/gcc'
make[1]: *** [stage1_build] Error 2
make[1]: Leaving directory `/tmp/cvs/gcc-20040206/Build/gcc'
make: *** [bootstrap] Error 2

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: patch ping

[Roger Sayle]

On Fri, 6 Feb 2004, Alan Modra wrote:
> I know it's only been a few days, but the rs6000 bit has been OK'd
> and the rest is just a mechanical change.
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00071.html

Ok for mainline.

Roger
--

patch ping

[Alan Modra]

Move special treatment of relative prefixes into add_sysrooted_prefix.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00634.html

rs6000 va_arg support for long double
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00632.html

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Patch ping

[Zdenek Dvorak]

Hello,

http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01348.html
  -- a rewrite of mark_irreducible_loops function (since I found out
     that I no longer understand how it works, and was unable to fix
     a bug in it).

Zdenek

Re: patch ping

[Alan Modra]

On Fri, Feb 06, 2004 at 11:40:23AM +0100, Andreas Schwab wrote:
> ../../gcc/ada/misc.c:867:52: macro "INIT_CUMULATIVE_ARGS" requires 5 arguments, but only 4 given

Oops.  Fixed with the obvious patch.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: patch ping

[Andreas Schwab]

Alan Modra <amodra@bigpond.net.au> writes:

> I know it's only been a few days, but the rs6000 bit has been OK'd
> and the rest is just a mechanical change.
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00071.html

Breaks bootstrap.

gcc -c   -O2 -g -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes     -fno-common   -DHAVE_CONFIG_H    -I. -Iada -I../../gcc -I../../gcc/ada -I../../gcc/../include  ../../gcc/ada/misc.c -o ada/misc.o
../../gcc/ada/misc.c:867:52: macro "INIT_CUMULATIVE_ARGS" requires 5 arguments, but only 4 given
../../gcc/ada/misc.c: In function `default_pass_by_ref':
../../gcc/ada/misc.c:867: error: `INIT_CUMULATIVE_ARGS' undeclared (first use in this function)
../../gcc/ada/misc.c:867: error: (Each undeclared identifier is reported only once
../../gcc/ada/misc.c:867: error: for each function it appears in.)
make[2]: *** [ada/misc.o] Error 1
make[2]: Leaving directory `/tmp/cvs/gcc-20040206/Build/gcc'
make[1]: *** [stage1_build] Error 2
make[1]: Leaving directory `/tmp/cvs/gcc-20040206/Build/gcc'
make: *** [bootstrap] Error 2

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstra\xDFe 5, 90409 N\xFCrnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: patch ping

[Roger Sayle]

On Fri, 6 Feb 2004, Alan Modra wrote:
> I know it's only been a few days, but the rs6000 bit has been OK'd
> and the rest is just a mechanical change.
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00071.html

Ok for mainline.

Roger
--

patch ping

[Alan Modra]

I know it's only been a few days, but the rs6000 bit has been OK'd
and the rest is just a mechanical change.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00071.html

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Patch ping

[Paolo Bonzini]

Please review these two patches.

http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03481.html
1.3% speed improvement on bootstrap

http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02845.html
Split a 1080-line function

Paolo

Re: Patch ping

[Zack Weinberg]

Andreas Jaeger <aj@suse.de> writes:

>> The actual interface to profiling code came in earlier with separate
>> patch.  This patch has no consequences to the profiling, just uses the
>> interface we agreed on earlier, so I would say that there is no problem
>> from profiler side. (this is also why I don't feel this belong to area I
>> can approve as gcov maintainer)
>
> Zack, since the profiler code is ok, I interpret your message that
> this is approved.  Correct?

Mm.. yeah, I guess so.

zw

Re: Patch ping

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]

Jan Hubicka <hubicka@ucw.cz> writes:

>> Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> writes:
>> 
>> > Hello,
>> >
>> > could someone please review
>> >
>> > http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02991.html?
>> >
>> > I would like to get this in, since it uses value profiling, and I feel
>> > wrong about having a piece of unused and therefore untested code in gcc.
>> > And of course, it also makes a nice improvement in benchmarks.
>> 
>> I don't see anything wrong with the code, but I would like someone
>> more familiar with the profiler to comment.  Since this was submitted
>> well before the deadline and only affects a non-default optimization
>> mode, I think it can go in now if (say) Nathan Sidwell thinks the code
>> is sound.
>
> The actual interface to profiling code came in earlier with separate
> patch.  This patch has no consequences to the profiling, just uses the
> interface we agreed on earlier, so I would say that there is no problem
> from profiler side. (this is also why I don't feel this belong to area I
> can approve as gcov maintainer)

Zack, since the profiler code is ok, I interpret your message that
this is approved.  Correct?

Thanks,
Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Patch ping

[Jan Hubicka]

> Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> writes:
> 
> > Hello,
> >
> > could someone please review
> >
> > http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02991.html?
> >
> > I would like to get this in, since it uses value profiling, and I feel
> > wrong about having a piece of unused and therefore untested code in gcc.
> > And of course, it also makes a nice improvement in benchmarks.
> 
> I don't see anything wrong with the code, but I would like someone
> more familiar with the profiler to comment.  Since this was submitted
> well before the deadline and only affects a non-default optimization
> mode, I think it can go in now if (say) Nathan Sidwell thinks the code
> is sound.

The actual interface to profiling code came in earlier with separate
patch.  This patch has no consequences to the profiling, just uses the
interface we agreed on earlier, so I would say that there is no problem
from profiler side. (this is also why I don't feel this belong to area I
can approve as gcov maintainer)

Honza
> 
> You have some English grammar issues with the documentation.
> 
> zw

Re: Patch ping

[Zack Weinberg]

Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> writes:

> Hello,
>
> could someone please review
>
> http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02991.html?
>
> I would like to get this in, since it uses value profiling, and I feel
> wrong about having a piece of unused and therefore untested code in gcc.
> And of course, it also makes a nice improvement in benchmarks.

I don't see anything wrong with the code, but I would like someone
more familiar with the profiler to comment.  Since this was submitted
well before the deadline and only affects a non-default optimization
mode, I think it can go in now if (say) Nathan Sidwell thinks the code
is sound.

You have some English grammar issues with the documentation.

zw

Patch ping

[Zdenek Dvorak]

Hello,

could someone please review

http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02991.html?

I would like to get this in, since it uses value profiling, and I feel
wrong about having a piece of unused and therefore untested code in gcc.
And of course, it also makes a nice improvement in benchmarks.

Zdenek

Re: Patch ping

[Jim Wilson]

Jerry Quinn wrote:
> http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00013.html

You should include a few words about the patch.  Otherwise people may 
assume it isn't their area and not bother to click through.

The patch looks correct to me.  I checked it in.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Patch ping

[Jerry Quinn]

http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00013.html

Patch ping

[Dale Johannesen]

Is anybody considering this one?  It fixes a crash on legal code.

http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00616.html

patch ping...

[Eric Christopher]

Chris submitted this a few days ago... any hope for an approval:

http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00219.html

-eric

-- 
I will not grease the monkey bars