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

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

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

[libatomic PATCH] [PING] Fix libatomic behavior for big endian toolchain

[Shiva Chen]

PING

https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01763.html

2014-10-17 Shiva Chen 

Fix libatomic behavior for big endian toolchain
* cas_n.c: Fix shift amount for big endian toolchain
* config/arm/exch_n.c: Fix shift amount for big endian toolchain
* exch_n.c: Fix shift amount for big endian toolchain
* fop_n.c: Fix shift amount for big endian toolchain


Shiva

Re: Patch ping and question about copyright assignment

[Joseph Myers]

On Tue, 6 Jan 2015, Mikhail Maltsev wrote:

> Hi, all!
> I'm pinging about this patch:
> https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01925.html (PR c/48956)
> I know that maybe it's too early for sending a ping (less than 2
> weeks), but I also have a question regarding my patch:
> Is this patch considered small enough to be accepted without copyright
> assignment? If it is not, I need some instructions about signing such
> an assignment.

I think this needs an assignment.  As a new feature it would also best be 
considered after GCC 5 branches rather than while trunk is in bug-fix 
mode.

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

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

Patch ping and question about copyright assignment

[Mikhail Maltsev]

Hi, all!
I'm pinging about this patch:
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01925.html (PR c/48956)
I know that maybe it's too early for sending a ping (less than 2
weeks), but I also have a question regarding my patch:
Is this patch considered small enough to be accepted without copyright
assignment? If it is not, I need some instructions about signing such
an assignment.
Anyway, I hope, I will be able to contribute more to the GCC project, so
I'm sending this message to ass...@gnu.org also.

-- 
Regards,
Mikhail Maltsev

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

Re: [PATCH][PING] libobjc: Properly handle classes without instance variables in class_copyIvarList ().

[Dimitris Papavasiliou]

Ping!

On 12/24/2014 07:28 PM, Dimitris Papavasiliou wrote:

Hello,

The attached patch fixes an issue reported a couple of years ago in Bug
51891 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51891).  The problem
is caused because classes without instance variables have no ivar list
at all, so that their ivars pointer is NULL, but the code in
class_copyIvarList () is unaware of this.

That this is in fact so can be easily verified by checking the code of
class_addIvar in the same source file, where the ivars list is allocated
when the first ivar is added.  The code there also checks for a NULL
ivars pointer.

The patch also adds a simple test-case for this issue.  I think that the
ChangeLog entry should be something along the lines of:

2014-12-24  Dimitris Papavasiliou  

  PR libobjc/51891
  * libobjc/ivars.c: Add a check for classes without instance
 variables, which have a NULL ivar list pointer.
  * gcc/testsuite/objc.dg/gnu-api-2-class.m: Add a test case
 for the above change.

I hope I got the formatting right.  I've run make -k check-objc and all
tests pass without problems.

Let me know if there are any problems, or if I can do anything else to
facilitate the acceptance of the patch.

Regards,
Dimitris

[C++ PATCH PING] Reject trailing return type for operator auto()

[Ville Voutilainen]

Any comments on this?

On 19 December 2014 at 09:21, Ville Voutilainen
 wrote:
> Tested on Linux-x64.
>
> /cp
> 2014-12-19  Ville Voutilainen  
>
> Reject trailing return type for an operator auto().
> * decl.c (grokdeclarator): Reject trailing return types for
> all conversion operators, don't handle conversion operators
> in the previous checks that deal with auto.
>
> /testsuite
> 2014-12-19  Ville Voutilainen  
>
> Reject trailing return type for an operator auto().
> * g++.dg/cpp0x/auto9.C: Adjust.

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

Re: Patch ping: Fix building of gengtype

[Richard Biener]

On Wed, Dec 3, 2014 at 11:45 AM, Jakub Jelinek  wrote:
> Hi!
>
> I'd like to ping this patch to fix gcc/Makefile dependencies
> for gengtype objects as well as gcc-{ar,nm,ranlib} objects.
> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03092.html

Ok.

Thanks,
Richard.

> Jakub

Patch ping: Fix building of gengtype

[Jakub Jelinek]

Hi!

I'd like to ping this patch to fix gcc/Makefile dependencies
for gengtype objects as well as gcc-{ar,nm,ranlib} objects.
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03092.html

Jakub

Patch ping^2: [PATCH] -fsanitize=vptr instrumentation (take 2)

[Jakub Jelinek]

On Wed, Nov 12, 2014 at 03:05:46PM +0100, Jakub Jelinek wrote:
> On Tue, Oct 28, 2014 at 01:44:50PM +0100, Jakub Jelinek wrote:
> > On Mon, Oct 27, 2014 at 05:16:05PM +0100, Jakub Jelinek wrote:
> > > Here is an updated patch, ok if bootstrap/testing passes (so far just
> > > checked with
> > > make -j16 -k check RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} 
> > > asan.exp tsan.exp ubsan.exp'
> > > )?
> 
> I'd like to ping the
> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02945.html
> patch.

Ping.

Jakub

Re: [GRAPHITE, PATCH] Ping: Loop unroll and jam optimization

[Mircea Namolaru]

> New optimization flags and new params need documentation in
> gcc/doc/invoke.texi.
> 

Thanks. Added description in invoke.texi. The patch is in trunk.

> The description of the --params suggest they provide fixed values - is
> there no way to autodetect sensible values with a cost-model?  I
> hardly doubt that you can find two fixed values that apply for a whole
> program...

There are a lot of models/heuristics, but in the general case tile sizes remain
kind of an open problem. For the time being, this option and its parameters are 
intended 
mostly to compiler developers interested to bring the loop to a specific form 
enabling
further optimizations.

Mircea.

Re: [GRAPHITE, PATCH] Ping: Loop unroll and jam optimization

[Richard Biener]

On Sat, Nov 15, 2014 at 11:57 AM, Mircea Namolaru
 wrote:
> The close of stage 1 is getting close (very close). Even there is not so much 
> new code (basically
> the new code computes the separation class option for AST build), I am not 
> sure that the patch
> qualify for stage 2.
>
> There is very nice code generated by unroll-and-jam (stride mining) for small 
> kernels both for constant
> or non-constant bound loops, and is an argument for the new isl based code 
> generator. Otherwise I'm afraid
> that the code generated looks very similar with the cloog generated one, an 
> inner loop
> with bounds of min/max that GCC doesn't further optimize, preventing 
> perceived advantages of
> strip mining (register reuse and scalar reduction, instruction scheduling 
> etc).
>
> ok for trunk ?

New optimization flags and new params need documentation in
gcc/doc/invoke.texi.

The description of the --params suggest they provide fixed values - is
there no way to autodetect sensible values with a cost-model?  I
hardly doubt that you can find two fixed values that apply for a whole
program...

Richard.

> Thanks, Mircea
>

Re: [GRAPHITE, PATCH] Ping: Loop unroll and jam optimization

[Mircea Namolaru]

The close of stage 1 is getting close (very close). Even there is not so much 
new code (basically
the new code computes the separation class option for AST build), I am not sure 
that the patch 
qualify for stage 2.

There is very nice code generated by unroll-and-jam (stride mining) for small 
kernels both for constant 
or non-constant bound loops, and is an argument for the new isl based code 
generator. Otherwise I'm afraid 
that the code generated looks very similar with the cloog generated one, an 
inner loop
with bounds of min/max that GCC doesn't further optimize, preventing perceived 
advantages of 
strip mining (register reuse and scalar reduction, instruction scheduling etc).

ok for trunk ?

Thanks, Mircea

Index: gcc/graphite-poly.h
===
--- gcc/graphite-poly.h	(revision 217013)
+++ gcc/graphite-poly.h	(working copy)
@@ -349,6 +349,9 @@
   poly_scattering_p _saved;
   isl_map *saved;
 
+  /* For tiling, the map for computing the separating class.  */
+  isl_map *map_sepclass;
+
   /* True when this PBB contains only a reduction statement.  */
   bool is_reduction;
 };
Index: gcc/graphite.c
===
--- gcc/graphite.c	(revision 217013)
+++ gcc/graphite.c	(working copy)
@@ -383,7 +383,8 @@
   || flag_loop_strip_mine
   || flag_graphite_identity
   || flag_loop_parallelize_all
-  || flag_loop_optimize_isl)
+  || flag_loop_optimize_isl
+  || flag_loop_unroll_jam)
 flag_graphite = 1;
 
   return flag_graphite != 0;
Index: gcc/common.opt
===
--- gcc/common.opt	(revision 217013)
+++ gcc/common.opt	(working copy)
@@ -1328,6 +1328,10 @@
 Common Report Var(flag_loop_block) Optimization
 Enable Loop Blocking transformation
 
+floop-unroll-and-jam
+Common Report Var(flag_loop_unroll_jam) Optimization
+Enable Loop Unroll Jam transformation
+ 
 fgnu-tm
 Common Report Var(flag_tm)
 Enable support for GNU transactional memory
Index: gcc/graphite-optimize-isl.c
===
--- gcc/graphite-optimize-isl.c	(revision 217013)
+++ gcc/graphite-optimize-isl.c	(working copy)
@@ -186,7 +186,7 @@
   PartialSchedule = isl_band_get_partial_schedule (Band);
   *Dimensions = isl_band_n_member (Band);
 
-  if (DisableTiling)
+  if (DisableTiling || flag_loop_unroll_jam)
 return PartialSchedule;
 
   /* It does not make any sense to tile a band with just one dimension.  */
@@ -241,7 +241,9 @@
constant number of iterations, if the number of loop iterations at
DimToVectorize can be devided by VectorWidth. The default VectorWidth is
currently constant and not yet target specific. This function does not reason
-   about parallelism.  */
+   about parallelism.
+
+  */
 static isl_map *
 getPrevectorMap (isl_ctx *ctx, int DimToVectorize,
 		 int ScheduleDimensions,
@@ -305,8 +307,98 @@
   isl_constraint_set_constant_si (c, VectorWidth - 1);
   TilingMap = isl_map_add_constraint (TilingMap, c);
 
-  isl_map_dump (TilingMap);
+  return TilingMap;
+}
 
+/* Compute an auxiliary map to getPrevectorMap, for computing the separating 
+   class defined by full tiles.  Used in graphite_isl_ast_to_gimple.c to set the 
+   corresponding option for AST build.
+
+   The map (for VectorWidth=4):
+
+   [i,j] -> [it,j,ip] : it % 4 = 0 and it <= ip <= it + 3 and it + 3 = i and
+ip >= 0
+
+   The image of this map is the separation class. The range of this map includes
+   all the i that are multiple of 4 in the domain beside the greater one. 
+
+ */ 
+static isl_map *
+getPrevectorMap_full (isl_ctx *ctx, int DimToVectorize,
+		 int ScheduleDimensions,
+		 int VectorWidth)
+{
+  isl_space *Space;
+  isl_local_space *LocalSpace, *LocalSpaceRange;
+  isl_set *Modulo;
+  isl_map *TilingMap;
+  isl_constraint *c;
+  isl_aff *Aff;
+  int PointDimension; /* ip */
+  int TileDimension;  /* it */
+  isl_val *VectorWidthMP;
+  int i;
+
+  /* assert (0 <= DimToVectorize && DimToVectorize < ScheduleDimensions);*/
+
+  Space = isl_space_alloc (ctx, 0, ScheduleDimensions, ScheduleDimensions + 1);
+  TilingMap = isl_map_universe (isl_space_copy (Space));
+  LocalSpace = isl_local_space_from_space (Space);
+  PointDimension = ScheduleDimensions;
+  TileDimension = DimToVectorize;
+
+  /* Create an identity map for everything except DimToVectorize and the 
+ point loop. */
+  for (i = 0; i < ScheduleDimensions; i++)
+{
+  if (i == DimToVectorize)
+continue;
+
+  c = isl_equality_alloc (isl_local_space_copy (LocalSpace));
+
+  isl_constraint_set_coefficient_si (c, isl_dim_in, i, -1);
+  isl_constraint_set_coefficient_si (c, isl_dim_out, i, 1);
+
+  TilingMap = isl_map_add_constraint (TilingMap, c);
+}
+
+  /* it % 'VectorWidth' = 0  */
+  LocalSpaceRange = isl_local_space_range (isl_local_space_copy (LocalSpace));
+  

Patch ping: [PATCH] -fsanitize=vptr instrumentation (take 2)

[Jakub Jelinek]

Hi!

On Tue, Oct 28, 2014 at 01:44:50PM +0100, Jakub Jelinek wrote:
> On Mon, Oct 27, 2014 at 05:16:05PM +0100, Jakub Jelinek wrote:
> > Here is an updated patch, ok if bootstrap/testing passes (so far just
> > checked with
> > make -j16 -k check RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp 
> > tsan.exp ubsan.exp'
> > )?

I'd like to ping the
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02945.html
patch.

Jakub

Re: [PATCH PING]Improve induction variable elimination

[Mike Stump]

On Oct 15, 2014, at 6:36 AM, Richard Biener  wrote:
> +  wide_int max_wi = wi::max_value (TYPE_PRECISION (type), UNSIGNED);
> +  max_val = wi::to_widest (wide_int_to_tree (type, max_wi));
> 
> ick - there must be a better way to "extend" max_wi to "infinite"
> precision.  Mike?

  widest_int::from (mem_ref_offset (base), SIGNED);

is an example in the compiler of converting a wide_int to a widest_int.  If the 
value is signed, you convert with SIGNED, if unsigned, you convert it with 
UNSIGNED.

Re: [PATCH PING]Improve induction variable elimination

[Richard Biener]

On Wed, Oct 8, 2014 at 5:35 AM, Bin Cheng  wrote:
> Hi,
> This patch is posted long before in a series of patches at
> https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01392.html .  Since the
> preceding patch is changed according to review comments, also because it's
> long time not reviewed, I rebased and updated this patch as attached.
>
> With this patch, spec2k/fp can be improved a little on aarch64.
> Bootstrap and test on x86_64 and x86, I am also prepared to fix any
> regression in the future.  Is it OK?

+  wide_int max_wi = wi::max_value (TYPE_PRECISION (type), UNSIGNED);
+  max_val = wi::to_widest (wide_int_to_tree (type, max_wi));

ick - there must be a better way to "extend" max_wi to "infinite"
precision.  Mike?

   /* We need to know that the candidate induction variable does not overflow.
- While more complex analysis may be used to prove this, for now just
- check that the variable appears in the original program and that it
- is computed in a type that guarantees no overflows.  */
+ Apart from checking that the variable appears in the original program
+ and that is is computed in a type that guarantees no overflows, we also
+ check no wrapping periord of the variable covers the niter if it has
+ unsigned type.  More complex analysis may be used to prove this.  */
   cand_type = TREE_TYPE (cand->iv->base);
-  if (cand->pos != IP_ORIGINAL || !nowrap_type_p (cand_type))
+  if ((cand->pos != IP_ORIGINAL || !nowrap_type_p (cand_type))
+  && !nowrap_cand_for_loop_niter_p (data, use, cand, niter))
 return false;

After reading this (and the two functions related) I still don't get
what you are after ;)  What is "no wrapping period of the variable
covers the niter"?  Somehow if nowrap_cand_for_loop_niter_p
you proved that the IV cannot wrap.  You compute this "period"
as (max-val-of-IV-type - initial-IV-value + IV-step - 1) / IV-step,
that is, after how many iterations the IV will have overflowed
(testcase that covers the corner cases to make sure you didn't introduce
an off-by-one error here?).  I think the naming of the functions
is unfortunate here (max_nowrap_iter?).

Btw, you do not seem to handle a negative IV-step in any special
way even though that would wrap around zero at some point?
(if step is always the same type as the IV you are of course fine
as it will be never negative that way - but you'll pessimize things
then because those wrappings are not really wrappings?)

And btw, in period_greater_niter_exit I don't see why you need to
check the overall max iterations for the non-constant niter case.
Isn't the upper bound recorded for the particular exit enough?

You should not use TYPE_MAX_VALUE anywhere but only
the maximum value based on TYPE_PRECISION.

+  else if (TREE_CODE (mbz) == EQ_EXPR)
+{
+  /* Check whether may_be_zero is in below three forms:
+  1) b' == TYPE_MAX_VALUE (TREE_TYPE (b'))
+ where b' is of type nit_type.  The expression could be
+ folded from "b' + 1 < 1".  In this case, A is "0" and B
+ is "b' + 1".
...

this looks like a separate "feature" - please commit it separately
(same comment about TYPE_MAX_VALUE applies).

   /* Finally, check that CAND->IV->BASE - CAND->IV->STEP * A does not
- overflow.  */
-  offset = fold_build2 (MULT_EXPR, TREE_TYPE (cand->iv->step),
-   cand->iv->step,
-   fold_convert (TREE_TYPE (cand->iv->step), a));
+ overflow.  It is uncessary to build offset when A equals to ZERO.  */
+  if (a != integer_zero_node)
+offset = fold_build2 (MULT_EXPR, TREE_TYPE (cand->iv->step),
+ cand->iv->step,
+ fold_convert (TREE_TYPE (cand->iv->step), a));
+  else
+offset = a;
+

looks like premature optimization to me?  It should use
integer_zerop (a) anyway.

  This is the case iff the period of the induction variable is greater
  than the number of iterations for which the exit condition is true.  */
   period = iv_period (cand->iv);
+  if (!period_greater_niter_exit (data, use, cand, period, desc))
+return false;

huh, and there is already a iv_period function...?  (which doesn't
take into account the IV initial value - but at least it's a true
"period")

Overall this looks good, but the wide-int use at the beginning looks
odd to me and I'd like you not use TYPE_MAX_VALUE.

Richard.


> 2014-09-30  Bin Cheng  
>
> * tree-ssa-loop-ivopts.c (iv_nowrap_period)
> (nowrap_cand_for_loop_niter_p): New functions.
> (period_greater_niter_exit): New function refactored from
> may_eliminate_iv.
> (difference_cannot_overflow_p): Handle zero offset.
> (iv_elimination_compare_lt): New parameter.  Check wrapping
> behavior for candidate of wrapping type.  Handle folded forms
> of may_be_zero expression.
> (may_eliminate_iv): Call period_greater_niter_exit.  Pass new
> argument for iv

[PATCH PING]Improve induction variable elimination

[Bin Cheng]

Hi,
This patch is posted long before in a series of patches at
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01392.html .  Since the
preceding patch is changed according to review comments, also because it's
long time not reviewed, I rebased and updated this patch as attached.  

With this patch, spec2k/fp can be improved a little on aarch64.
Bootstrap and test on x86_64 and x86, I am also prepared to fix any
regression in the future.  Is it OK?

2014-09-30  Bin Cheng  

* tree-ssa-loop-ivopts.c (iv_nowrap_period)
(nowrap_cand_for_loop_niter_p): New functions.
(period_greater_niter_exit): New function refactored from
may_eliminate_iv.
(difference_cannot_overflow_p): Handle zero offset.
(iv_elimination_compare_lt): New parameter.  Check wrapping
behavior for candidate of wrapping type.  Handle folded forms
of may_be_zero expression.
(may_eliminate_iv): Call period_greater_niter_exit.  Pass new
argument for iv_elimination_compare_lt.

gcc/testsuite/ChangeLog
2014-09-30  Bin Cheng  

* gcc.dg/tree-ssa/ivopts-lt-3.c: New test.
* gcc.dg/tree-ssa/ivopts-lt-4.c: New test.Index: gcc/tree-ssa-loop-ivopts.c
===
--- gcc/tree-ssa-loop-ivopts.c  (revision 215108)
+++ gcc/tree-ssa-loop-ivopts.c  (working copy)
@@ -4451,6 +4451,44 @@ iv_period (struct iv *iv)
   return period;
 }
 
+/* Returns no wrapping period of induction variable IV.  For now
+   only unsigned type IV is handled, we could extend it in case
+   of non-overflow for signed ones.  Return zero if it can't be
+   decided.  */
+
+static tree
+iv_nowrap_period (struct iv *iv)
+{
+  bool overflow;
+  tree type;
+  tree base = iv->base, step = iv->step;
+  widest_int base_val, step_val, max_val, span, period;
+
+  gcc_assert (step && TREE_CODE (step) == INTEGER_CST);
+
+  type = TREE_TYPE (base);
+  if (!TYPE_UNSIGNED (type) || TREE_CODE (base) != INTEGER_CST)
+return integer_zero_node;
+
+  base_val = wi::to_widest (base);
+  step_val = wi::to_widest (step);
+  if (!POINTER_TYPE_P (type) && TYPE_MAX_VALUE (type)
+  && TREE_CODE (TYPE_MAX_VALUE (type)) == INTEGER_CST)
+max_val = wi::to_widest (TYPE_MAX_VALUE (type));
+  else
+{
+  wide_int max_wi = wi::max_value (TYPE_PRECISION (type), UNSIGNED);
+  max_val = wi::to_widest (wide_int_to_tree (type, max_wi));
+}
+
+  span = max_val - base_val + step_val - 1;
+  period = wi::div_trunc (span, step_val, UNSIGNED, &overflow);
+  if (overflow)
+return integer_zero_node;
+
+  return wide_int_to_tree (type, period);
+}
+
 /* Returns the comparison operator used when eliminating the iv USE.  */
 
 static enum tree_code
@@ -4483,6 +4521,10 @@ difference_cannot_overflow_p (struct ivopts_data *
   tree e1, e2;
   aff_tree aff_e1, aff_e2, aff_offset;
 
+  /* No overflow if offset is zero.  */
+  if (integer_zerop (offset))
+return true;
+
   if (!nowrap_type_p (TREE_TYPE (base)))
 return false;
 
@@ -4538,7 +4580,84 @@ difference_cannot_overflow_p (struct ivopts_data *
 }
 }
 
-/* Tries to replace loop exit by one formulated in terms of a LT_EXPR
+/* Check whether PERIOD of CAND is greater than the number of iterations
+   described by DESC for which the exit condition is true.  The exit
+   condition is comparison against USE.  */
+
+static bool
+period_greater_niter_exit (struct ivopts_data *data,
+  struct iv_use *use, struct iv_cand *cand,
+  tree period, struct tree_niter_desc *desc)
+{
+  struct loop *loop = data->current_loop;
+
+  /* If the number of iterations is constant, compare against it directly.  */
+  if (TREE_CODE (desc->niter) == INTEGER_CST)
+{
+  /* See cand_value_at.  */
+  if (stmt_after_increment (loop, cand, use->stmt))
+{
+  if (!tree_int_cst_lt (desc->niter, period))
+return false;
+}
+  else
+{
+  if (tree_int_cst_lt (period, desc->niter))
+return false;
+}
+}
+
+  /* If not, and if this is the only possible exit of the loop, see whether
+ we can get a conservative estimate on the number of iterations of the
+ entire loop and compare against that instead.  */
+  else
+{
+  widest_int period_value, max_niter;
+
+  max_niter = desc->max;
+  if (stmt_after_increment (loop, cand, use->stmt))
+max_niter += 1;
+  period_value = wi::to_widest (period);
+  if (wi::gtu_p (max_niter, period_value))
+{
+  /* See if we can take advantage of inferred loop bound information.  
*/
+  if (data->loop_single_exit_p)
+{
+  if (!max_loop_iterations (loop, &max_niter))
+return false;
+  /* The loop bound is already adjusted by adding 1.  */
+  if (wi::gtu_p (max_niter, period_value))
+return false;
+}
+  else
+ 

Re: [C++ Patch PING] Re: [PATCH] make excessive template instantiation depth a fatal error

[Paolo Carlini]

Hi,

On 09/30/2014 04:51 PM, Manuel López-Ibáñez wrote:

I don't want to cause you more work Paolo, but perhaps this should be
documented in https://gcc.gnu.org/gcc-5/changes.html. ?

Something like:

* Excessive template instantiation depth is now a fatal error. This
prevents excessive diagnostics that usually do not help to identify
the problem.

Thanks for taking care of this!
You are welcome. No problem about the changes.html bits, I'll take care 
of that too.


Paolo.

Re: [C++ Patch PING] Re: [PATCH] make excessive template instantiation depth a fatal error

[Manuel López-Ibáñez]

I don't want to cause you more work Paolo, but perhaps this should be
documented in https://gcc.gnu.org/gcc-5/changes.html. ?

Something like:

* Excessive template instantiation depth is now a fatal error. This
prevents excessive diagnostics that usually do not help to identify
the problem.

Thanks for taking care of this!

Cheers,

Manuel.

On 30 September 2014 16:38, Jason Merrill  wrote:
> OK.
>
> Jason

Re: [C++ Patch PING] Re: [PATCH] make excessive template instantiation depth a fatal error

[Jason Merrill]

OK.

Jason

Re: [C++ Patch PING] Re: [PATCH] make excessive template instantiation depth a fatal error

[Paolo Carlini]

... forgot to attach the complete patch ;)

Paolo.


Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 215710)
+++ cp/cp-tree.h(working copy)
@@ -5418,7 +5418,6 @@ extern const char *lang_decl_name (tree, int, boo
 extern const char *lang_decl_dwarf_name(tree, int, bool);
 extern const char *language_to_string  (enum languages);
 extern const char *class_key_or_enum_as_string (tree);
-extern void print_instantiation_context(void);
 extern void maybe_warn_variadic_templates   (void);
 extern void maybe_warn_cpp0x   (cpp0x_warn_str str);
 extern bool pedwarn_cxx98   (location_t, int, const char 
*, ...) ATTRIBUTE_GCC_DIAG(3,4);
@@ -5633,7 +5632,7 @@ extern tree tsubst_copy_and_build (tree, tree, ts
 tree, bool, bool);
 extern tree most_general_template  (tree);
 extern tree get_mostly_instantiated_function_type (tree);
-extern int problematic_instantiation_changed   (void);
+extern bool problematic_instantiation_changed  (void);
 extern void record_last_problematic_instantiation (void);
 extern struct tinst_level *current_instantiation(void);
 extern tree maybe_get_template_decl_from_type_decl (tree);
@@ -5661,7 +5660,8 @@ extern tree fold_non_dependent_expr_sfinae(tree,
 extern bool alias_type_or_template_p(tree);
 extern bool alias_template_specialization_p (const_tree);
 extern bool explicit_class_specialization_p (tree);
-extern int push_tinst_level (tree);
+extern bool push_tinst_level(tree);
+extern bool push_tinst_level_loc(tree, location_t);
 extern void pop_tinst_level (void);
 extern struct tinst_level *outermost_tinst_level(void);
 extern void init_template_processing   (void);
Index: cp/error.c
===
--- cp/error.c  (revision 215710)
+++ cp/error.c  (working copy)
@@ -3360,16 +3360,6 @@ maybe_print_instantiation_context (diagnostic_cont
   record_last_problematic_instantiation ();
   print_instantiation_full_context (context);
 }
-
-/* Report the bare minimum context of a template instantiation.  */
-void
-print_instantiation_context (void)
-{
-  print_instantiation_partial_context
-(global_dc, current_instantiation (), input_location);
-  pp_newline (global_dc->printer);
-  diagnostic_flush_buffer (global_dc);
-}
 
 /* Report what constexpr call(s) we're trying to expand, if any.  */
 
Index: cp/pt.c
===
--- cp/pt.c (revision 215710)
+++ cp/pt.c (working copy)
@@ -8347,26 +8347,26 @@ static GTY(()) struct tinst_level *last_error_tins
 /* We're starting to instantiate D; record the template instantiation context
for diagnostics and to restore it later.  */
 
-int
+bool
 push_tinst_level (tree d)
 {
+  return push_tinst_level_loc (d, input_location);
+}
+
+/* We're starting to instantiate D; record the template instantiation context
+   at LOC for diagnostics and to restore it later.  */
+
+bool
+push_tinst_level_loc (tree d, location_t loc)
+{
   struct tinst_level *new_level;
 
   if (tinst_depth >= max_tinst_depth)
 {
-  last_error_tinst_level = current_tinst_level;
-  if (TREE_CODE (d) == TREE_LIST)
-   error ("template instantiation depth exceeds maximum of %d (use "
-  "-ftemplate-depth= to increase the maximum) substituting %qS",
-  max_tinst_depth, d);
-  else
-   error ("template instantiation depth exceeds maximum of %d (use "
-  "-ftemplate-depth= to increase the maximum) instantiating %qD",
-  max_tinst_depth, d);
-
-  print_instantiation_context ();
-
-  return 0;
+  fatal_error ("template instantiation depth exceeds maximum of %d"
+   " (use -ftemplate-depth= to increase the maximum)",
+   max_tinst_depth);
+  return false;
 }
 
   /* If the current instantiation caused problems, don't let it instantiate
@@ -8373,11 +8373,11 @@ push_tinst_level (tree d)
  anything else.  Do allow deduction substitution and decls usable in
  constant expressions.  */
   if (limit_bad_template_recursion (d))
-return 0;
+return false;
 
   new_level = ggc_alloc ();
   new_level->decl = d;
-  new_level->locus = input_location;
+  new_level->locus = loc;
   new_level->errors = errorcount+sorrycount;
   new_level->in_system_header_p = in_system_header_at (input_location);
   new_level->next = current_tinst_level;
@@ -8387,7 +8387,7 @@ push_tinst_level (tree d)
   if (GATHER_STATISTICS && (tinst_depth > depth_reached))
 depth_reached = tinst_depth;
 
-  return 1;
+  return true;
 }
 
 /* We're done instantiating this template; return to the instantiation
@@ -2

[C++ Patch PING] Re: [PATCH] make excessive template instantiation depth a fatal error

[Paolo Carlini]

Hi all, hi Jason,

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

PING: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01709.html
Today, I picked this unreviewed patch prepared by Manuel back in August 
and trivially completed it by adjusting the testcases (all the tweaks 
seem the expected ones given the patch proper, no surprises). How does 
it look?


Thanks!
Paolo.

//
2014-09-30  Paolo Carlini  

* g++.dg/cpp0x/decltype26.C: Adjust.
* g++.dg/cpp0x/decltype28.C: Likewise.
* g++.dg/cpp0x/decltype29.C: Likewise.
* g++.dg/cpp0x/decltype32.C: Likewise.
* g++.dg/cpp0x/enum11.C: Likewise.
* g++.dg/template/arrow1.C: Likewise.
* g++.dg/template/pr23510.C: Likewise.
* g++.dg/template/recurse.C: Likewise.
* g++.dg/template/recurse2.C: Likewise.
* g++.dg/template/vtable2.C: Likewise.
* g++.old-deja/g++.pt/infinite1.C: Likewise.

Re: [PATCH][PING] PR62120

[Jakub Jelinek]

On Tue, Sep 30, 2014 at 02:44:21PM +0400, Ilya Tocar wrote:
> > 2014-09-15  Ilya Tocar  
> > 
> >PR middle-end/62120
> >* varasm.c (decode_reg_name_and_count): Check availability for
> >registers from ADDITIONAL_REGISTER_NAMES.
> > 
> > Testsuite/
> > 
> > 2014-09-15  Ilya Tocar  
> > 
> >PR middle-end/62120
> >* gcc.target/i386/avx512f-additional-reg-names.c: Use register vaild

s/vaild/valid/

> >in 32-bit mode.
> >* gcc.target/i386/pr62120.c: New.
> > 
> > ---
> >  gcc/testsuite/gcc.target/i386/avx512f-additional-reg-names.c | 2 +-
> >  gcc/testsuite/gcc.target/i386/pr62120.c  | 8 
> >  gcc/varasm.c | 5 +++--
> >  3 files changed, 12 insertions(+), 3 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr62120.c
> > 
> > diff --git a/gcc/testsuite/gcc.target/i386/avx512f-additional-reg-names.c 
> > b/gcc/testsuite/gcc.target/i386/avx512f-additional-reg-names.c
> > index 164a1de..98a9052 100644
> > --- a/gcc/testsuite/gcc.target/i386/avx512f-additional-reg-names.c
> > +++ b/gcc/testsuite/gcc.target/i386/avx512f-additional-reg-names.c
> > @@ -3,7 +3,7 @@
> >  
> >  void foo ()
> >  {
> > -  register int zmm_var asm ("zmm9") __attribute__((unused));
> > +  register int zmm_var asm ("zmm7") __attribute__((unused));
> >  
> >__asm__ __volatile__("vxorpd %%zmm0, %%zmm0, %%zmm7\n" : : : "zmm7" );

Please use zmm6 instead, zmm7 is clobbered in the following statement.

Otherwise LGTM.

Jakub

Re: [PATCH][PING] PR62120

[Ilya Tocar]

Ping.

On 15 Sep 18:43, Ilya Tocar wrote:
> On 01 Sep 18:38, Ilya Tocar wrote:
> > > Please mention the PR in the ChangeLog entry and add some testcases
> > > (can be gcc.target/i386/, but we should have it tested).
> > > Does this change anything on say register short sil __asm ("sil"); in 
> > > 32-bit
> > > mode (when it IMHO should be rejected too?)?
> > >
> > Do we support "sil" at all? In i386.h i see:
> > 
> > /* Note we are omitting these since currently I don't know how
> > to get gcc to use these, since they want the same but different
> > number as al, and ax.
> > */
> > #define QI_REGISTER_NAMES \
> > {"al", "dl", "cl", "bl", "sil", "dil", "bpl", "spl",}
> > 
> > And gcc doesn't recognize sil.
> > 
> > Added testcase, and fixed avx512f-additional-reg-names.c to be valid on
> > 32 bits. Ok for trunk?
> >
> 
> Slightly updated tests.
> Ok for trunk?
> 
> gcc/
> 
> 2014-09-15  Ilya Tocar  
> 
>PR middle-end/62120
>* varasm.c (decode_reg_name_and_count): Check availability for
>registers from ADDITIONAL_REGISTER_NAMES.
> 
> Testsuite/
> 
> 2014-09-15  Ilya Tocar  
> 
>PR middle-end/62120
>* gcc.target/i386/avx512f-additional-reg-names.c: Use register vaild
>in 32-bit mode.
>* gcc.target/i386/pr62120.c: New.
> 
> ---
>  gcc/testsuite/gcc.target/i386/avx512f-additional-reg-names.c | 2 +-
>  gcc/testsuite/gcc.target/i386/pr62120.c  | 8 
>  gcc/varasm.c | 5 +++--
>  3 files changed, 12 insertions(+), 3 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr62120.c
> 
> diff --git a/gcc/testsuite/gcc.target/i386/avx512f-additional-reg-names.c 
> b/gcc/testsuite/gcc.target/i386/avx512f-additional-reg-names.c
> index 164a1de..98a9052 100644
> --- a/gcc/testsuite/gcc.target/i386/avx512f-additional-reg-names.c
> +++ b/gcc/testsuite/gcc.target/i386/avx512f-additional-reg-names.c
> @@ -3,7 +3,7 @@
>  
>  void foo ()
>  {
> -  register int zmm_var asm ("zmm9") __attribute__((unused));
> +  register int zmm_var asm ("zmm7") __attribute__((unused));
>  
>__asm__ __volatile__("vxorpd %%zmm0, %%zmm0, %%zmm7\n" : : : "zmm7" );
>  }
> diff --git a/gcc/testsuite/gcc.target/i386/pr62120.c 
> b/gcc/testsuite/gcc.target/i386/pr62120.c
> new file mode 100644
> index 000..bfb8c47
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr62120.c
> @@ -0,0 +1,8 @@
> +/* { dg-do compile } */
> +/* { dg-options "-mno-sse" } */
> +
> +void foo ()
> +{
> +  register int zmm_var asm ("ymm9");/* { dg-error "invalid register name" } 
> */
> +  register int zmm_var2 asm ("23");/* { dg-error "invalid register name" } */
> +}
> diff --git a/gcc/varasm.c b/gcc/varasm.c
> index cd4a230..9c12b81 100644
> --- a/gcc/varasm.c
> +++ b/gcc/varasm.c
> @@ -888,7 +888,7 @@ decode_reg_name_and_count (const char *asmspec, int 
> *pnregs)
>if (asmspec[0] != 0 && i < 0)
>   {
> i = atoi (asmspec);
> -   if (i < FIRST_PSEUDO_REGISTER && i >= 0)
> +   if (i < FIRST_PSEUDO_REGISTER && i >= 0 && reg_names[i][0])
>   return i;
> else
>   return -2;
> @@ -925,7 +925,8 @@ decode_reg_name_and_count (const char *asmspec, int 
> *pnregs)
>  
>   for (i = 0; i < (int) ARRAY_SIZE (table); i++)
> if (table[i].name[0]
> -   && ! strcmp (asmspec, table[i].name))
> +   && ! strcmp (asmspec, table[i].name)
> +   && reg_names[table[i].number][0])
>   return table[i].number;
>}
>  #endif /* ADDITIONAL_REGISTER_NAMES */
> -- 
> 1.8.3.1
> 

Re: [PATCH][PING] Keep patch file permissions in mklog

[Diego Novillo]

On Fri, Sep 19, 2014 at 6:41 AM, Tom de Vries  wrote:

> So it's a question of predictability (always do the same or do nothing) vs.
> robustness (do as much as you can given the circumstances). I'm not sure
> which one is better in this case.

I think it's fine the way it is now. Thanks for the patch. Looks fine to me.


Diego.

Re: [PATCH][PING] Keep patch file permissions in mklog

[Segher Boessenkool]

On Fri, Sep 19, 2014 at 12:41:53PM +0200, Tom de Vries wrote:
> I've followed up on the explanation by Segher about 2.15 File module 
> version and fixed the comment.
> 
> I've not added the 2.15 file module version check on copy Segher also 
> mentioned, since I'm not sure about that one. AFAIU the tradeoff is:
> - without the check the mklog still works ok for older versions of perl, 
> apart
>   from the permissions (the situation we're in for all versions of perl 
>   without
>   the patch)

Sounds good then.  The module is called File::Copy fwiw, not File.

The patch looks to me like it should work fine.


Segher

Re: [PATCH][PING] Keep patch file permissions in mklog

[Tom de Vries]

On 18-09-14 19:46, Diego Novillo wrote:

On Thu, Sep 18, 2014 at 10:56 AM, Yury Gribov  wrote:


On 08/04/2014 12:14 PM, Tom de Vries wrote:


On 04-08-14 08:45, Yury Gribov wrote:


Thanks! My 2 (actually 4) cents below.



Hi Yuri,

thanks for the review.


  > +if ($#ARGV == 1 && ("$ARGV[0]" eq "-i" || "$ARGV[0]" eq
"--inline")) {
  > +$diff = $ARGV[1];

Can we shift here and then just set $diff to $ARGV[0] unconditionally?



Done.


  > +if ($diff eq "-") {
  > +die "Reading from - and using -i are not compatible";
  > +}

Hm, can't we dump ChangeLog to stdout in that case?
The limitation looks rather strange.



My original idea here was that --inline means 'in the patch file', which
is not possible if the patch comes from stdin.

I've now interpreted it such that --inline prints to stdout what it
would print to the patch file otherwise, that is, both log and patch.
Printing just the log to stdout can be already be achieved by not using
--inline.


  > +open (FILE1, '>', $tmp) or die "Could not open temp file";

Could we use more descriptive name?



I've used the slightly more descriptive 'OUTPUTFILE'.


  > +system ("cat $diff >>$tmp") == 0
  > +or die "Could not append patch to temp file";
  > ...
  > +unlink ($tmp) == 1 or die "Could not remove temp file";

The checks look like an overkill given that we don't check for result
of mktemp...



I've added a check for the result of mktemp, and removed the unlink
result check. I've left in the "Could not append patch to temp file"
check because the patch file might be read-only.

OK for trunk?

Thanks,
- Tom



Pinging the patch for Tom.



Apologies for the delay. Could someone post the latest patch. I see
it's gone through a cycle of reviews and changes.




Hi Diego,

here it is.

I've followed up on the explanation by Segher about 2.15 File module version and 
fixed the comment.


I've not added the 2.15 file module version check on copy Segher also mentioned, 
since I'm not sure about that one. AFAIU the tradeoff is:

- without the check the mklog still works ok for older versions of perl, apart
  from the permissions (the situation we're in for all versions of perl without
  the patch)
- with the check the script won't work at all for older perl version.
So it's a question of predictability (always do the same or do nothing) vs. 
robustness (do as much as you can given the circumstances). I'm not sure which 
one is better in this case.


Thanks,
- Tom
2014-08-11  Tom de Vries  

	* mklog: Add --inline option.

diff --git a/contrib/mklog b/contrib/mklog
index 3d17dc5..1352e99 100755
--- a/contrib/mklog
+++ b/contrib/mklog
@@ -26,6 +26,9 @@
 # Author: Diego Novillo  and
 # Cary Coutant 
 
+use File::Temp;
+use File::Copy qw(cp mv);
+
 # Change these settings to reflect your profile.
 $username = $ENV{'USER'};
 $name = `finger $username | grep -o 'Name: .*'`;
@@ -56,14 +59,22 @@ if (-d "$gcc_root/.git") {
 # Program starts here. You should not need to edit anything below this
 # line.
 #-
-if ($#ARGV != 0) {
+$inline = 0;
+if ($#ARGV == 1 && ("$ARGV[0]" eq "-i" || "$ARGV[0]" eq "--inline")) {
+	shift;
+	$inline = 1;
+} elsif ($#ARGV != 0) {
 $prog = `basename $0`; chop ($prog);
 print <', $tmp) or die "Could not open temp file: $!";
+} else {
+	*OUTPUTFILE = STDOUT;
+}
+
+# Print the log
 foreach my $clname (keys %cl_entries) {
-	print "$clname:\n\n$hdrline\n\n$cl_entries{$clname}\n";
+	print OUTPUTFILE "$clname:\n\n$hdrline\n\n$cl_entries{$clname}\n";
+}
+
+if ($inline) {
+	# Append the patch to the log
+	foreach (@diff_lines) {
+		print OUTPUTFILE "$_\n";
+	}
+}
+
+if ($inline && $diff ne "-") {
+	# Close $tmp
+	close(OUTPUTFILE);
+
+	# Write new contents to $diff atomically
+	mv $tmp, $diff or die "Could not move temp file to patch file: $!";
 }
 
 exit 0;
-- 
1.9.1

Re: [PATCH][PING] Enable -fsanitize-recover for KASan

[Joseph S. Myers]

On Thu, 18 Sep 2014, Jakub Jelinek wrote:

> Seems for -fdelete-null-pointer-checks we got it wrong too,
> IMHO for -fsanitize={null,{,returns-}nonnull-attribute,undefined}
> we want to disable it unconditionally, regardless of whether
> that option appears on the command line or not.
> And we handle it right for 
> -fdelete-null-pointer-checks -fsanitize=undefined
> but not for
> -fsanitize=undefined -fdelete-null-pointer-checks
> Joseph, thoughts where to override it instead (I mean, after all
> options are processed)?

finish_options is the obvious place to do that.

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

Re: [PATCH][PING] Keep patch file permissions in mklog

[Diego Novillo]

On Thu, Sep 18, 2014 at 10:56 AM, Yury Gribov  wrote:
>
> On 08/04/2014 12:14 PM, Tom de Vries wrote:
>>
>> On 04-08-14 08:45, Yury Gribov wrote:
>>>
>>> Thanks! My 2 (actually 4) cents below.
>>>
>>
>> Hi Yuri,
>>
>> thanks for the review.
>>
>>>  > +if ($#ARGV == 1 && ("$ARGV[0]" eq "-i" || "$ARGV[0]" eq
>>> "--inline")) {
>>>  > +$diff = $ARGV[1];
>>>
>>> Can we shift here and then just set $diff to $ARGV[0] unconditionally?
>>>
>>
>> Done.
>>
>>>  > +if ($diff eq "-") {
>>>  > +die "Reading from - and using -i are not compatible";
>>>  > +}
>>>
>>> Hm, can't we dump ChangeLog to stdout in that case?
>>> The limitation looks rather strange.
>>>
>>
>> My original idea here was that --inline means 'in the patch file', which
>> is not possible if the patch comes from stdin.
>>
>> I've now interpreted it such that --inline prints to stdout what it
>> would print to the patch file otherwise, that is, both log and patch.
>> Printing just the log to stdout can be already be achieved by not using
>> --inline.
>>
>>>  > +open (FILE1, '>', $tmp) or die "Could not open temp file";
>>>
>>> Could we use more descriptive name?
>>>
>>
>> I've used the slightly more descriptive 'OUTPUTFILE'.
>>
>>>  > +system ("cat $diff >>$tmp") == 0
>>>  > +or die "Could not append patch to temp file";
>>>  > ...
>>>  > +unlink ($tmp) == 1 or die "Could not remove temp file";
>>>
>>> The checks look like an overkill given that we don't check for result
>>> of mktemp...
>>>
>>
>> I've added a check for the result of mktemp, and removed the unlink
>> result check. I've left in the "Could not append patch to temp file"
>> check because the patch file might be read-only.
>>
>> OK for trunk?
>>
>> Thanks,
>> - Tom
>>
>
> Pinging the patch for Tom.


Apologies for the delay. Could someone post the latest patch. I see
it's gone through a cycle of reviews and changes.


Thanks. Diego.

[PATCH][PING] Keep patch file permissions in mklog

[Yury Gribov]

On 08/04/2014 12:14 PM, Tom de Vries wrote:

On 04-08-14 08:45, Yury Gribov wrote:

Thanks! My 2 (actually 4) cents below.



Hi Yuri,

thanks for the review.


 > +if ($#ARGV == 1 && ("$ARGV[0]" eq "-i" || "$ARGV[0]" eq
"--inline")) {
 > +$diff = $ARGV[1];

Can we shift here and then just set $diff to $ARGV[0] unconditionally?



Done.


 > +if ($diff eq "-") {
 > +die "Reading from - and using -i are not compatible";
 > +}

Hm, can't we dump ChangeLog to stdout in that case?
The limitation looks rather strange.



My original idea here was that --inline means 'in the patch file', which
is not possible if the patch comes from stdin.

I've now interpreted it such that --inline prints to stdout what it
would print to the patch file otherwise, that is, both log and patch.
Printing just the log to stdout can be already be achieved by not using
--inline.


 > +open (FILE1, '>', $tmp) or die "Could not open temp file";

Could we use more descriptive name?



I've used the slightly more descriptive 'OUTPUTFILE'.


 > +system ("cat $diff >>$tmp") == 0
 > +or die "Could not append patch to temp file";
 > ...
 > +unlink ($tmp) == 1 or die "Could not remove temp file";

The checks look like an overkill given that we don't check for result
of mktemp...



I've added a check for the result of mktemp, and removed the unlink
result check. I've left in the "Could not append patch to temp file"
check because the patch file might be read-only.

OK for trunk?

Thanks,
- Tom



Pinging the patch for Tom.

Re: [PATCH][PING] Enable -fsanitize-recover for KASan

[Yury Gribov]

Added Marek to comment on proposed UBSan option change.

On 09/18/2014 02:52 PM, Jakub Jelinek wrote:

--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -1551,6 +1551,12 @@ common_handle_option (struct gcc_options *opts,
 | SANITIZE_RETURNS_NONNULL_ATTRIBUTE))
  opts->x_flag_delete_null_pointer_checks = 0;

+   /* UBSan and KASan enable recovery by default.  */
+   opts->x_flag_sanitize_recover
+ = !!(flag_sanitize & (SANITIZE_UNDEFINED
+   | SANITIZE_UNDEFINED_NONDEFAULT
+   | SANITIZE_KERNEL_ADDRESS));
+


Doesn't this override even user supplied -fsanitize-recover or
-fno-sanitize-recover ?  Have you tried both
-fno-sanitize-recover -fsanitize=kernel-address
and
-fsanitize=kernel-address -fno-sanitize-recover
option orders?


I did and this worked in a seemingly logical way:
* -fsanitize=address (disable recovery)
* -fsanitize-recover -fsanitize=address (disable recovery)
* -fsanitize=address -fsanitize-recover (enable recovery)
* -fsanitize=kernel-address (enable recovery)
* -fno-sanitize-recover -fsanitize=kernel-address (enable recovery)
* -fsanitize=kernel-address -fno-sanitize-recover (enable recovery)


Seems for -fdelete-null-pointer-checks we got it wrong too,
IMHO for -fsanitize={null,{,returns-}nonnull-attribute,undefined}
we want to disable it unconditionally, regardless of whether
that option appears on the command line or not.


My understanding is that all 
-fsanitize=(address|kernel-address|undefined|you-name-it) are simply 
packs of options to enable. User may override any selected option from 
the pack if he so desires.



I don't think your proposal will work properly though,
if one compiles with
-fsanitize=undefined -fsanitize=address
you'll just get userland asan with error recovery, which is highly
undesirable


Now that's a problem. Looks like I'll need a separate flag to achieve 
what I need (-fasan-recover? And maybe then rename -fsanitize-recover to 
-fubsan-recover for consistency?).



or asan.c needs to limit it to flag_sanitize & SANITIZE_KERNEL_ADDRESS
mode only.


We may want to UBsanitize kernel in future and this may cause the same 
problem as for userspace Asan/UBSan interaction you described above.


> Depends if you ever want to add recovery for userland
> sanitization.

Also kernel developers want both recoverable (more user-friendly) and 
non-recoverable (faster) Asan error handling.


-Y

Re: [PATCH][PING] Enable -fsanitize-recover for KASan

[Jakub Jelinek]

On Mon, Sep 15, 2014 at 01:38:42PM +0400, Yury Gribov wrote:
> --- a/gcc/builtins.def
> +++ b/gcc/builtins.def
> @@ -176,7 +176,7 @@ along with GCC; see the file COPYING3.  If not see
>DEF_BUILTIN (ENUM, "__builtin_" NAME, BUILT_IN_NORMAL, TYPE, TYPE,\
>  true, true, true, ATTRS, true, \
> (flag_sanitize & (SANITIZE_ADDRESS | SANITIZE_THREAD \
> - | SANITIZE_UNDEFINED | SANITIZE_NONDEFAULT)))
> + | SANITIZE_UNDEFINED | 
> SANITIZE_UNDEFINED_NONDEFAULT)))

This is too long line after the change.

> --- a/gcc/gcc.c
> +++ b/gcc/gcc.c
> @@ -8236,7 +8236,7 @@ sanitize_spec_function (int argc, const char **argv)
>if (strcmp (argv[0], "thread") == 0)
>  return (flag_sanitize & SANITIZE_THREAD) ? "" : NULL;
>if (strcmp (argv[0], "undefined") == 0)
> -return ((flag_sanitize & (SANITIZE_UNDEFINED | SANITIZE_NONDEFAULT))
> +return ((flag_sanitize & (SANITIZE_UNDEFINED | 
> SANITIZE_UNDEFINED_NONDEFAULT))

Likewise.

> --- a/gcc/opts.c
> +++ b/gcc/opts.c
> @@ -1551,6 +1551,12 @@ common_handle_option (struct gcc_options *opts,
>| SANITIZE_RETURNS_NONNULL_ATTRIBUTE))
> opts->x_flag_delete_null_pointer_checks = 0;
>  
> + /* UBSan and KASan enable recovery by default.  */
> + opts->x_flag_sanitize_recover
> +   = !!(flag_sanitize & (SANITIZE_UNDEFINED
> + | SANITIZE_UNDEFINED_NONDEFAULT
> + | SANITIZE_KERNEL_ADDRESS));
> +

Doesn't this override even user supplied -fsanitize-recover or
-fno-sanitize-recover ?  Have you tried both
-fno-sanitize-recover -fsanitize=kernel-address
and
-fsanitize=kernel-address -fno-sanitize-recover
option orders?

Seems for -fdelete-null-pointer-checks we got it wrong too,
IMHO for -fsanitize={null,{,returns-}nonnull-attribute,undefined}
we want to disable it unconditionally, regardless of whether
that option appears on the command line or not.
And we handle it right for 
-fdelete-null-pointer-checks -fsanitize=undefined
but not for
-fsanitize=undefined -fdelete-null-pointer-checks
Joseph, thoughts where to override it instead (I mean, after all
options are processed)?

In the -fsanitize-recover case, I'd on the other side think that
it should just override the default and not override explicit
user's decision.  Which could be done here, but supposedly guarded
with if (!opts_set->x_flag_sanitize_recover)?

I don't think your proposal will work properly though,
if one compiles with
-fsanitize=undefined -fsanitize=address
you'll just get userland asan with error recovery, which is highly
undesirable (not just that it changes the behavior from how it
behaved before, but especially because libasan doesn't contain
such entrypoints at all).
-fsanitize=undefined,address
or
-fsanitize=address,undefined
is normal supported mode and thus I think you either can't reuse
-fsanitize-recover option for what you want to do, or
asan.c needs to limit it to flag_sanitize & SANITIZE_KERNEL_ADDRESS
mode only.  Depends if you ever want to add recovery for userland
sanitization.

Jakub

[PATCH][PING] Enable -fsanitize-recover for KASan

[Yury Gribov]

On 09/05/2014 10:54 AM, Yury Gribov wrote:

Hi all,

This patch enables -fsanitize-recover for KASan by default. This causes
KASan to continue execution after error in case of inline
instrumentation. This feature is needed because
- reports during early bootstrap won't even be printed
- needed to run all tests w/o rebooting machine for every test
- needed for interactive work on desktop

Bootstrapped and regtested on x64.

Ok to commit?

-Y


Rebased patch to current trunk.

-Y
2014-09-15  Yury Gribov  

gcc/
	* asan.c (report_error_func): Optionally call recoverable
	routines.
	(asan_expand_check_ifn): Likewise.
	(check_func): Fix formatting.
	* common.opt (fsanitize-recover): Disable by default.
	* sanitizer.def: New builtins.
	* opts.c (common_handle_option): Enable flag_sanitize_recover
	for UBSan and KASan by default.
	* flag-types.h (SANITIZE_UNDEFINED_NONDEFAULT): Rename.
	* gcc.c (sanitize_spec_function): Likewise.
	* opts.c (common_handle_option): Likewise.

gcc/testsuite/
	* c-c++-common/asan/recovery-1.c: New test.
	* c-c++-common/asan/recovery-2.c: New test.
	* c-c++-common/asan/recovery-common.inc: New file.

commit 080184e321b49641cd1e3bab2615eaf82164c683
Author: Yury Gribov 
Date:   Fri Aug 29 16:43:42 2014 +0400

2014-09-04  Yury Gribov  

gcc/
	* asan.c (report_error_func): Optionally call recoverable
	routines.
	(asan_expand_check_ifn): Likewise.
	(check_func): Fix formatting.
	* common.opt (fsanitize-recover): Disable by default.
	* sanitizer.def: New builtins.
	* opts.c (common_handle_option): Enable flag_sanitize_recover
	for UBSan and KASan by default.
	* flag-types.h (SANITIZE_UNDEFINED_NONDEFAULT): Rename.
	* gcc.c (sanitize_spec_function): Likewise.
	* opts.c (common_handle_option): Likewise.

gcc/testsuite/
	* c-c++-common/asan/recovery-1.c: New test.
	* c-c++-common/asan/recovery-2.c: New test.
	* c-c++-common/asan/recovery-common.inc: New file.

diff --git a/gcc/asan.c b/gcc/asan.c
index e6820ea..1d0a26a 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -1373,22 +1373,36 @@ asan_protect_global (tree decl)
IS_STORE is either 1 (for a store) or 0 (for a load).  */
 
 static tree
-report_error_func (bool is_store, HOST_WIDE_INT size_in_bytes, int *nargs)
-{
-  static enum built_in_function report[2][6]
-= { { BUILT_IN_ASAN_REPORT_LOAD1, BUILT_IN_ASAN_REPORT_LOAD2,
-	  BUILT_IN_ASAN_REPORT_LOAD4, BUILT_IN_ASAN_REPORT_LOAD8,
-	  BUILT_IN_ASAN_REPORT_LOAD16, BUILT_IN_ASAN_REPORT_LOAD_N },
-	{ BUILT_IN_ASAN_REPORT_STORE1, BUILT_IN_ASAN_REPORT_STORE2,
-	  BUILT_IN_ASAN_REPORT_STORE4, BUILT_IN_ASAN_REPORT_STORE8,
-	  BUILT_IN_ASAN_REPORT_STORE16, BUILT_IN_ASAN_REPORT_STORE_N } };
+report_error_func (bool is_store, bool recover_p, HOST_WIDE_INT size_in_bytes,
+		   int *nargs)
+{
+  static enum built_in_function report[2][2][6]
+= { { { BUILT_IN_ASAN_REPORT_LOAD1, BUILT_IN_ASAN_REPORT_LOAD2,
+	BUILT_IN_ASAN_REPORT_LOAD4, BUILT_IN_ASAN_REPORT_LOAD8,
+	BUILT_IN_ASAN_REPORT_LOAD16, BUILT_IN_ASAN_REPORT_LOAD_N },
+	  { BUILT_IN_ASAN_REPORT_STORE1, BUILT_IN_ASAN_REPORT_STORE2,
+	BUILT_IN_ASAN_REPORT_STORE4, BUILT_IN_ASAN_REPORT_STORE8,
+	BUILT_IN_ASAN_REPORT_STORE16, BUILT_IN_ASAN_REPORT_STORE_N } },
+	{ { BUILT_IN_ASAN_REPORT_RECOVER_LOAD1,
+	BUILT_IN_ASAN_REPORT_RECOVER_LOAD2,
+	BUILT_IN_ASAN_REPORT_RECOVER_LOAD4,
+	BUILT_IN_ASAN_REPORT_RECOVER_LOAD8,
+	BUILT_IN_ASAN_REPORT_RECOVER_LOAD16,
+	BUILT_IN_ASAN_REPORT_RECOVER_LOAD_N },
+	  { BUILT_IN_ASAN_REPORT_RECOVER_STORE1,
+	BUILT_IN_ASAN_REPORT_RECOVER_STORE2,
+	BUILT_IN_ASAN_REPORT_RECOVER_STORE4,
+	BUILT_IN_ASAN_REPORT_RECOVER_STORE8,
+	BUILT_IN_ASAN_REPORT_RECOVER_STORE16,
+	BUILT_IN_ASAN_REPORT_RECOVER_STORE_N } } };
   if (size_in_bytes == -1)
 {
   *nargs = 2;
-  return builtin_decl_implicit (report[is_store][5]);
+  return builtin_decl_implicit (report[recover_p][is_store][5]);
 }
   *nargs = 1;
-  return builtin_decl_implicit (report[is_store][exact_log2 (size_in_bytes)]);
+  int size_log2 = exact_log2 (size_in_bytes);
+  return builtin_decl_implicit (report[recover_p][is_store][size_log2]);
 }
 
 /* Construct a function tree for __asan_{load,store}{1,2,4,8,16,_n}.
@@ -1399,11 +1413,11 @@ check_func (bool is_store, int size_in_bytes, int *nargs)
 {
   static enum built_in_function check[2][6]
 = { { BUILT_IN_ASAN_LOAD1, BUILT_IN_ASAN_LOAD2,
-  BUILT_IN_ASAN_LOAD4, BUILT_IN_ASAN_LOAD8,
-  BUILT_IN_ASAN_LOAD16, BUILT_IN_ASAN_LOADN },
+	  BUILT_IN_ASAN_LOAD4, BUILT_IN_ASAN_LOAD8,
+	  BUILT_IN_ASAN_LOAD16, BUILT_IN_ASAN_LOADN },
 	{ BUILT_IN_ASAN_STORE1, BUILT_IN_ASAN_STORE2,
-  BUILT_IN_ASAN_STORE4, BUILT_IN_ASAN_STORE8,
-  BUILT_IN_ASAN_STORE16, BUILT_IN_ASAN_STOREN } };
+	  BUILT_IN_ASAN_STORE4, BUILT_IN_ASAN_STORE8,
+	  BUILT_IN_ASAN_STORE16, BUILT_IN_ASAN_STOREN } };
   if (size_in_bytes == -1)
 {
   *nargs = 2;
@@ -2574,9 +2588,10 @@ asan_expand_ch

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

[Jakub Jelinek]

On Mon, Sep 01, 2014 at 11:22:12AM +0400, Yury Gribov wrote:
> BTW regarding ChangeLog: should I mention both bugs (they are
> duplicates) or just one of them?

You can mention both if you want (on separate lines), or just the
one the other has been DUPed to.

> commit e3324d8d3528f0cb1a56e784f0887a4743a3e0f2
> Author: Yury Gribov 
> Date:   Wed Aug 20 13:56:03 2014 +0400
> 
> 2014-08-22  Yury Gribov  
> 
> gcc/
>   PR sanitizer/62140
>   * asan.c (asan_mem_ref_get_end): Handle non-ptroff_t lengths.
>   (build_check_stmt): Likewise.
>   (instrument_strlen_call): Likewise.
>   (asan_expand_check_ifn): Likewise and fix types.
>   (maybe_cast_to_ptrmode): New function.
> 
> gcc/testsuite/
>   PR sanitizer/62140
>   * c-c++-common/asan/pr62140-1.c: New test.
>   * c-c++-common/asan/pr62140-2.c: New test.

Ok, thanks.

Jakub

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

[Yury Gribov]

---
From: Yury Gribov
Sent:  Friday, August 22, 2014 12:47PM
To: GCC Patches
Cc: Jakub Jelinek, Marek Polacek, t...@alumni.duke.edu, sabrina...@gmail.com
Subject: [PATCH] Fix Asan ICEs on unexpected types (PR62140, PR61897)

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

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

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

This was bootstrapped on x64 and regtested for x64 and i686 and also 
Asan-bootstrapped for x64.


Ok to commit?

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

-Y

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

2014-08-22  Yury Gribov  

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

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

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

Re: [PATCH][Ping v5] Add patch for debugging compiler ICEs

[Maxim Ostapenko]

Thanks Jeff and Jakub, I've reposted ICE debugging patch into 
gcc-patches mailing list 
(https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00285.html).


-Maxim
On 08/01/2014 11:29 PM, Jeff Law wrote:

On 08/01/14 02:00, Jakub Jelinek wrote:

On Thu, Jul 24, 2014 at 04:39:28PM +0400, Maxim Ostapenko wrote:

Ping.


Don't want to review a patch I wrote partially, so just a few comments:
1) IMHO it should be configure time selectable (not sure about the 
default,

but for non-release branches IMHO it should default to off, for release
branches I don't know).  The point is that while it is useful for
people to report gcc bugs in production compilers, it is not useful for
gcc developers on their boxes, having ICEs take 3 times as long is not
desirable for people who deal with those all the time
We definitely want the ability to select.  Waiting on an ICE to 
trigger 3 times would be painful for the developers.  So I'd think 
that enabled for the release branches and disabled for the trunk would 
be the right default.




2) recently a bug has been reported that some ICEs which print RTL
to stderr are considered non-reproduceable, because the addresses e.g.
in call_insn fndecl change through address space randomization. For the
retries the driver should supposedly append -fdump-noaddr.

Right.  I think we discussed this at Cauldron.

I think it's conceptually ok with those two changes, then it's just 
reviewing the details.


If you or Maxim could make those changes and repost, I'll cover the 
review.


jeff

Re: [PATCH][Ping v5] Add patch for debugging compiler ICEs

[Yury Gribov]

On 08/01/2014 07:53 PM, Jakub Jelinek wrote:

I think we should use David Malcolm's approach i.e. add some --report-bug
flag
to driver. This could be enabled by default at configure time via
--with-spec.

-freport-bug or whatever we call it should not be, at least if it attempts
to communicate over the network, should not be required though, lots of
people do e.g. package builds in various chroots etc. and you really don't
want to perform any network activity from there.


Oh sure, the actual "backend" of --report-bug could vary from just
generating the repro and storing it in /tmp (what your patch did in the 
first place)

to David's full blown automatic Bugzilla submission.

-Y

Re: [PATCH][Ping v5] Add patch for debugging compiler ICEs

[Jeff Law]

On 08/01/14 02:00, Jakub Jelinek wrote:

On Thu, Jul 24, 2014 at 04:39:28PM +0400, Maxim Ostapenko wrote:

Ping.


Don't want to review a patch I wrote partially, so just a few comments:
1) IMHO it should be configure time selectable (not sure about the default,
but for non-release branches IMHO it should default to off, for release
branches I don't know).  The point is that while it is useful for
people to report gcc bugs in production compilers, it is not useful for
gcc developers on their boxes, having ICEs take 3 times as long is not
desirable for people who deal with those all the time
We definitely want the ability to select.  Waiting on an ICE to trigger 
3 times would be painful for the developers.  So I'd think that enabled 
for the release branches and disabled for the trunk would be the right 
default.




2) recently a bug has been reported that some ICEs which print RTL
to stderr are considered non-reproduceable, because the addresses e.g.
in call_insn fndecl change through address space randomization.  For the
retries the driver should supposedly append -fdump-noaddr.

Right.  I think we discussed this at Cauldron.

I think it's conceptually ok with those two changes, then it's just 
reviewing the details.


If you or Maxim could make those changes and repost, I'll cover the review.

jeff

Re: [PATCH][Ping v5] Add patch for debugging compiler ICEs

[Jakub Jelinek]

On Fri, Aug 01, 2014 at 12:13:18PM +0400, Yury Gribov wrote:
> On 08/01/2014 12:00 PM, Jakub Jelinek wrote:
> >Don't want to review a patch I wrote partially, so just a few comments:
> >1) IMHO it should be configure time selectable (not sure about the default,
> >but for non-release branches IMHO it should default to off, for release
> >branches I don't know).  The point is that while it is useful for
> >people to report gcc bugs in production compilers, it is not useful for
> >gcc developers on their boxes, having ICEs take 3 times as long is not
> >desirable for people who deal with those all the time
> 
> I think we should use David Malcolm's approach i.e. add some --report-bug
> flag
> to driver. This could be enabled by default at configure time via
> --with-spec.

-freport-bug or whatever we call it should not be, at least if it attempts
to communicate over the network, should not be required though, lots of
people do e.g. package builds in various chroots etc. and you really don't
want to perform any network activity from there.  Still, having
info whether an ICE was reproduceable or not is useful in that case, and
having preprocessed source left in /tmp with the path printed to stderr
is also useful, you can e.g. grab those /tmp/cc*.out files from the chroot
and allow people to report later on.  The ICE message can of course suggest
an option or script or command line to run to report the bug or navigate the
user through bug reporting process.

Jakub

Re: [PATCH][Ping v5] Add patch for debugging compiler ICEs

[Jakub Jelinek]

On Fri, Aug 01, 2014 at 08:43:27AM -0700, Andi Kleen wrote:
> Jakub Jelinek  writes:
> > Don't want to review a patch I wrote partially, so just a few comments:
> > 1) IMHO it should be configure time selectable (not sure about the default,
> > but for non-release branches IMHO it should default to off, for release
> > branches I don't know).  The point is that while it is useful for
> > people to report gcc bugs in production compilers, it is not useful for
> > gcc developers on their boxes, having ICEs take 3 times as long is not
> > desirable for people who deal with those all the time
> 
> It may also not be desirable for LTO builds, which can take very long
> by themselves.

Indeed, and preparing preprocessed sources for all the files is hard in that
case anyway.  But as it is keyed on cc1 substring being present in the
compiler's name and lto uses lto1, it shouldn't trigger for that.
Only if you get ICEs with -flto already when compiling from C/C++ source,
but then it doesn't take very long usually and there is preprocessed source
available.

Jakub

Re: [PATCH][Ping v5] Add patch for debugging compiler ICEs

[Andi Kleen]

Jakub Jelinek  writes:
> Don't want to review a patch I wrote partially, so just a few comments:
> 1) IMHO it should be configure time selectable (not sure about the default,
> but for non-release branches IMHO it should default to off, for release
> branches I don't know).  The point is that while it is useful for
> people to report gcc bugs in production compilers, it is not useful for
> gcc developers on their boxes, having ICEs take 3 times as long is not
> desirable for people who deal with those all the time

It may also not be desirable for LTO builds, which can take very long
by themselves.

-Andi
-- 
a...@linux.intel.com -- Speaking for myself only

Re: [PATCH][Ping v5] Add patch for debugging compiler ICEs

[Yury Gribov]

On 08/01/2014 12:00 PM, Jakub Jelinek wrote:

Don't want to review a patch I wrote partially, so just a few comments:
1) IMHO it should be configure time selectable (not sure about the default,
but for non-release branches IMHO it should default to off, for release
branches I don't know).  The point is that while it is useful for
people to report gcc bugs in production compilers, it is not useful for
gcc developers on their boxes, having ICEs take 3 times as long is not
desirable for people who deal with those all the time


I think we should use David Malcolm's approach i.e. add some 
--report-bug flag
to driver. This could be enabled by default at configure time via 
--with-spec.



2) recently a bug has been reported that some ICEs which print RTL
to stderr are considered non-reproduceable, because the addresses e.g.
in call_insn fndecl change through address space randomization.  For the
etries the driver should supposedly append -fdump-noaddr.


+1

-Y

Re: [PATCH][Ping v5] Add patch for debugging compiler ICEs

[Jakub Jelinek]

On Thu, Jul 24, 2014 at 04:39:28PM +0400, Maxim Ostapenko wrote:
> Ping.

Don't want to review a patch I wrote partially, so just a few comments:
1) IMHO it should be configure time selectable (not sure about the default,
but for non-release branches IMHO it should default to off, for release
branches I don't know).  The point is that while it is useful for
people to report gcc bugs in production compilers, it is not useful for
gcc developers on their boxes, having ICEs take 3 times as long is not
desirable for people who deal with those all the time
2) recently a bug has been reported that some ICEs which print RTL
to stderr are considered non-reproduceable, because the addresses e.g.
in call_insn fndecl change through address space randomization.  For the
retries the driver should supposedly append -fdump-noaddr.

Jakub

Re: [PATCH][PING] Add support for KernelAddressSanitizer

[Yury Gribov]

On 07/31/2014 08:49 AM, Jeff Law wrote:

This is fine.  Thanks,


Commited in r213367.

Re: [PATCH][PING] Add support for KernelAddressSanitizer

[Jeff Law]

On 07/30/14 08:34, Yury Gribov wrote:

On 07/18/2014 05:38 PM, Jakub Jelinek wrote:

Do you error out on -fsanitize=thread -fsanitize=kernel-address ?
Perhaps -fsanitize=kernel-address -fsanitize=address should be
invalid too?


Yes, all these combinations are invalid.


But you don't error out on that.


Ok, fixed.


Then in sanitize_spec_function supposedly for "address" check
SANITIZE_USER_ADDRESS bit, for "kernel-address" added there
SANITIZE_KERNEL_ADDRESS, add all the incompatibility diagnostics for
the new
invalid combinations.


This delayed detection until link phase (and even then was disabled if
-nostdlib was on)
so I decided to perform this check in finish_options (after passing
cmdline options).


Plus, toplev.c has e.g.:


Fixed as well.

This is fine.  Thanks,
Jeff

[PATCH][PING] Add support for KernelAddressSanitizer

[Yury Gribov]

On 07/18/2014 05:38 PM, Jakub Jelinek wrote:

Do you error out on -fsanitize=thread -fsanitize=kernel-address ?
Perhaps -fsanitize=kernel-address -fsanitize=address should be invalid too?


Yes, all these combinations are invalid.


But you don't error out on that.


Ok, fixed.


Then in sanitize_spec_function supposedly for "address" check
SANITIZE_USER_ADDRESS bit, for "kernel-address" added there
SANITIZE_KERNEL_ADDRESS, add all the incompatibility diagnostics for the new
invalid combinations.


This delayed detection until link phase (and even then was disabled if
-nostdlib was on)
so I decided to perform this check in finish_options (after passing
cmdline options).


Plus, toplev.c has e.g.:


Fixed as well.

-Y




commit bd51cdb807c2cf5ada0101ca7db89076b54ed18e
Author: Yury Gribov 
Date:   Tue Jul 22 11:02:03 2014 +0400

2014-07-23  Yury Gribov  

	* doc/cpp.texi (__SANITIZE_ADDRESS__): Updated description.
	* doc/invoke.texi (-fsanitize=kernel-address): Describe new option.
	* flag-types.h (SANITIZE_USER_ADDRESS, SANITIZE_KERNEL_ADDRESS):
	New enums.
	* gcc.c (sanitize_spec_function): Support new option.
	(SANITIZER_SPEC): Remove now redundant check.
	* opts.c (common_handle_option): Support new option.
	(finish_options): Check for incompatibilities.
	* toplev.c (process_options): Split userspace-specific checks.

diff --git a/gcc/doc/cpp.texi b/gcc/doc/cpp.texi
index aaed739..0a6e50c 100644
--- a/gcc/doc/cpp.texi
+++ b/gcc/doc/cpp.texi
@@ -2354,8 +2354,8 @@ This macro is defined, with value 3, when @option{-fstack-protector-strong} is
 in use.
 
 @item __SANITIZE_ADDRESS__
-This macro is defined, with value 1, when @option{-fsanitize=address} is
-in use.
+This macro is defined, with value 1, when @option{-fsanitize=address}
+or @option{-fsanitize=kernel-address} are in use.
 
 @item __TIMESTAMP__
 This macro expands to a string constant that describes the date and time
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index b5e8d98..391daf8 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -5405,6 +5405,11 @@ more details.  The run-time behavior can be influenced using the
 @url{https://code.google.com/p/address-sanitizer/wiki/Flags#Run-time_flags} for
 a list of supported options.
 
+@item -fsanitize=kernel-address
+@opindex fsanitize=kernel-address
+Enable AddressSanitizer for Linux kernel.
+See @uref{http://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel} for more details.
+
 @item -fsanitize=thread
 @opindex fsanitize=thread
 Enable ThreadSanitizer, a fast data race detector.
diff --git a/gcc/flag-types.h b/gcc/flag-types.h
index 2849455..bf813b6 100644
--- a/gcc/flag-types.h
+++ b/gcc/flag-types.h
@@ -214,23 +214,25 @@ enum vect_cost_model {
 enum sanitize_code {
   /* AddressSanitizer.  */
   SANITIZE_ADDRESS = 1 << 0,
+  SANITIZE_USER_ADDRESS = 1 << 1,
+  SANITIZE_KERNEL_ADDRESS = 1 << 2,
   /* ThreadSanitizer.  */
-  SANITIZE_THREAD = 1 << 1,
+  SANITIZE_THREAD = 1 << 3,
   /* LeakSanitizer.  */
-  SANITIZE_LEAK = 1 << 2,
+  SANITIZE_LEAK = 1 << 4,
   /* UndefinedBehaviorSanitizer.  */
-  SANITIZE_SHIFT = 1 << 3,
-  SANITIZE_DIVIDE = 1 << 4,
-  SANITIZE_UNREACHABLE = 1 << 5,
-  SANITIZE_VLA = 1 << 6,
-  SANITIZE_NULL = 1 << 7,
-  SANITIZE_RETURN = 1 << 8,
-  SANITIZE_SI_OVERFLOW = 1 << 9,
-  SANITIZE_BOOL = 1 << 10,
-  SANITIZE_ENUM = 1 << 11,
-  SANITIZE_FLOAT_DIVIDE = 1 << 12,
-  SANITIZE_FLOAT_CAST = 1 << 13,
-  SANITIZE_BOUNDS = 1 << 14,
+  SANITIZE_SHIFT = 1 << 5,
+  SANITIZE_DIVIDE = 1 << 6,
+  SANITIZE_UNREACHABLE = 1 << 7,
+  SANITIZE_VLA = 1 << 8,
+  SANITIZE_NULL = 1 << 9,
+  SANITIZE_RETURN = 1 << 10,
+  SANITIZE_SI_OVERFLOW = 1 << 11,
+  SANITIZE_BOOL = 1 << 12,
+  SANITIZE_ENUM = 1 << 13,
+  SANITIZE_FLOAT_DIVIDE = 1 << 14,
+  SANITIZE_FLOAT_CAST = 1 << 15,
+  SANITIZE_BOUNDS = 1 << 16,
   SANITIZE_UNDEFINED = SANITIZE_SHIFT | SANITIZE_DIVIDE | SANITIZE_UNREACHABLE
 		   | SANITIZE_VLA | SANITIZE_NULL | SANITIZE_RETURN
 		   | SANITIZE_SI_OVERFLOW | SANITIZE_BOOL | SANITIZE_ENUM
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 6cd08ea..c0fde8c 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -779,8 +779,7 @@ proper position among the other output files.  */
 #ifndef SANITIZER_SPEC
 #define SANITIZER_SPEC "\
 %{!nostdlib:%{!nodefaultlibs:%{%:sanitize(address):" LIBASAN_SPEC "\
-%{static:%ecannot specify -static with -fsanitize=address}\
-%{%:sanitize(thread):%e-fsanitize=address is incompatible with -fsanitize=thread}}\
+%{static:%ecannot specify -static with -fsanitize=address}}\
 %{%:sanitize(thread):" LIBTSAN_SPEC "\
 %{!pie:%{!shared:%e-fsanitize=thread linking must be done with -pie or -shared}}}\
 %{%:sanitize(undefined):" LIBUBSAN_SPEC "}\
@@ -8224,7 +8223,9 @@ sanitize_spec_function (int argc, const char **argv)
 return NULL;
 
   if (strcmp (argv[0], "address") == 0)
-return (flag_sanitize & SANITIZE_ADDRESS) ? "" : NULL;
+return (flag_sanitize & SANITIZE_USER_

[patch, ping] fix build failure of x86_64-mingw32, missing crtbegin/crtend.o

[Olivier Hainque]

Hello,

Ping for https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00237.html

Thanks in advance for your feedback,

With Kind Regards,

Olivier

On Jul 3, 2014, at 16:57 , Olivier Hainque  wrote:
> From gcc/i386/config/mingw32.h, STARTFILE_SPEC and ENDFILE_SPEC include
> crtbegin.o and crtend.o unconditionally.
> 
> libgcc/config.host includes crtbegin.o and crtend.o in extra_parts for
> i[34567]86-*-mingw* but not for x86_64-*-mingw*.
> 
> Building a toolchain for x86_64-pc-mingw32 then rapidly fails with complaints
> about crtbegin.o and crtend.o missing.
> 
> This patch is a proposal to fix this by adding the objects to extra_parts,
> as well as i386/t-cygming to tmake_file so rules are available to build the
> objects.
> 
> Tested by verifying that a build with --target=x86_64-pc-mingw32
> proceeds to completion after the change.
> 
> OK to commit ?
> 
> Thanks in advance for your feedback,
> 
> With Kind Regards,
> 
> Olivier
> 
> 2014-07-02  Olivier Hainque  
> 
> libgcc/
>* config.host (x86_64-*-mingw*): Add i386/t-cygming to tmake_file
>and crtbegin.o + crtend.o to extra_parts.
> 
> 

[PATCH][PING] Fix mklog to support running from arbitrary folder

[Yury Gribov]

 Forwarded Message 
Subject: [PATCH] Fix mklog to support running from arbitrary folder
Date: Mon, 21 Jul 2014 12:32:45 +0400
From: Yury Gribov 
To: GCC Patches 
CC: Diego Novillo , Trevor Saunders 



Hi all,

Current mklog works only if run from GCC top-level folder. The patch
allows running from arbitrary directory.

I've used Linux directory separators which is probably ok because script
already expects Linux environment (dirname, basename, etc.).

Ok to commit?

-Y



commit aa8d7cd3db1f1eba8ee77b902cff1b2ab2a3f83a
Author: Yury Gribov 
Date:   Mon Jul 21 12:05:10 2014 +0400

2014-07-21  Yury Gribov  

	* mklog: Allow running from arbitrary folder.

diff --git a/contrib/mklog b/contrib/mklog
index cdc6455..3d17dc5 100755
--- a/contrib/mklog
+++ b/contrib/mklog
@@ -30,16 +30,15 @@
 $username = $ENV{'USER'};
 $name = `finger $username | grep -o 'Name: .*'`;
 @n = split(/: /, $name);
-$name = @n[1]; chop($name);
+$name = $n[1]; chop($name);
 $addr = $username . "\@my.domain.org";
 $date = `date +%Y-%m-%d`; chop ($date);
 
 $gcc_root = $0;
 $gcc_root =~ s/[^\\\/]+$/../;
-chdir $gcc_root;
 
 # if this is a git tree then take name and email from the git configuration
-if (-d .git) {
+if (-d "$gcc_root/.git") {
   $gitname = `git config user.name`;
   chomp($gitname);
   if ($gitname) {
@@ -80,7 +79,7 @@ sub get_clname ($) {
 	my $dirname = $_[0];
 	while ($dirname) {
 		my $clname = "$dirname/ChangeLog";
-		if (-f $clname) {
+		if (-f "$gcc_root/$clname") {
 			my $relname = substr ($_[0], length ($dirname) + 1);
 			return ($clname, $relname);
 		} else {

[PATCH][Ping v5] Add patch for debugging compiler ICEs

[Maxim Ostapenko]

Ping.

 Original Message 
Subject:[PATCH][Ping v4] Add patch for debugging compiler ICEs
Date:   Fri, 11 Jul 2014 17:44:28 +0400
From:   Maxim Ostapenko 
To: GCC Patches 
CC: 	Yury Gribov , Slava Garbuzov 
, Jakub Jelinek , 
tsaund...@mozilla.com, Maxim Ostapenko 




Ping. Added small changes due to previous discussion in community.


 Original Message 
Subject:[PATCH][Ping v3] Add patch for debugging compiler ICEs
Date:   Fri, 04 Jul 2014 18:32:44 +0400
From:   Maxim Ostapenko 
To: GCC Patches 
CC: Yury Gribov , Slava Garbuzov
, Jakub Jelinek ,
tsaund...@mozilla.com, Maxim Ostapenko 



Ping.


 Original Message 
Subject:[PATCH][Ping v2] Add patch for debugging compiler ICEs
Date:   Thu, 26 Jun 2014 19:46:08 +0400
From:   Maxim Ostapenko 
To: GCC Patches 
CC: Yury Gribov , Slava Garbuzov
, Jakub Jelinek ,
tsaund...@mozilla.com, Maxim Ostapenko 



Ping.


 Original Message 
Subject:[PATCH][Ping] Add patch for debugging compiler ICEs
Date:   Wed, 11 Jun 2014 18:15:27 +0400
From:   Maxim Ostapenko 
To: GCC Patches 
CC: Yury Gribov , Slava Garbuzov
, Jakub Jelinek ,
tsaund...@mozilla.com, chefm...@gmail.com



Ping.


 Original Message 
Subject:[PATCH] Add patch for debugging compiler ICEs
Date:   Mon, 02 Jun 2014 19:21:14 +0400
From:   Maxim Ostapenko 
To: GCC Patches 
CC: Yury Gribov , Slava Garbuzov
, Jakub Jelinek ,
tsaund...@mozilla.com, chefm...@gmail.com



Hi,

A years ago there was a discussion 
(https://gcc.gnu.org/ml/gcc-patches/2004-01/msg02437.html) about debugging 
compiler ICEs that resulted in a patch from Jakub, which dumps
useful information into temporary file, but for some reasons this patch wasn't 
applied to trunk.

This is the resurrected patch with added GCC version information into generated 
repro file.

-Maxim













2014-06-02  Jakub Jelinek  
	Max Ostapenko  

	* diagnostic.c (diagnostic_action_after_output): Exit with
	ICE_EXIT_CODE instead of FATAL_EXIT_CODE.
	* gcc.c (execute): Don't free first string early, but at the end
	of the function.  Call retry_ice if compiler exited with
	ICE_EXIT_CODE.
	(main): Factor out common code.
	(print_configuration): New function.
	(try_fork): Likewise.
	(redirect_stdout_stderr): Likewise.
	(files_equal_p): Likewise.
	(check_repro): Likewise.
	(run_attempt): Likewise.
	(generate_preprocessed_code): Likewise.
	(append_text): Likewise.
	(try_generate_repro): Likewise.

diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
index 0cc7593..67b8c5b 100644
--- a/gcc/diagnostic.c
+++ b/gcc/diagnostic.c
@@ -492,7 +492,7 @@ diagnostic_action_after_output (diagnostic_context *context,
 	real_abort ();
   diagnostic_finish (context);
   fnotice (stderr, "compilation terminated.\n");
-  exit (FATAL_EXIT_CODE);
+  exit (ICE_EXIT_CODE);
 
 default:
   gcc_unreachable ();
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 6cd08ea..045363c 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -43,6 +43,13 @@ compilation is specified by a string called a "spec".  */
 #include "params.h"
 #include "vec.h"
 #include "filenames.h"
+#ifdef HAVE_UNISTD_H
+#include 
+#endif
+
+#if !(defined (__MSDOS__) || defined (OS2) || defined (VMS))
+#define RETRY_ICE_SUPPORTED
+#endif
 
 /* By default there is no special suffix for target executables.  */
 /* FIXME: when autoconf is fixed, remove the host check - dj */
@@ -253,6 +260,9 @@ static void init_gcc_specs (struct obstack *, const char *, const char *,
 static const char *convert_filename (const char *, int, int);
 #endif
 
+#ifdef RETRY_ICE_SUPPORTED
+static void try_generate_repro (const char *prog, const char **argv);
+#endif
 static const char *getenv_spec_function (int, const char **);
 static const char *if_exists_spec_function (int, const char **);
 static const char *if_exists_else_spec_function (int, const char **);
@@ -2850,7 +2860,7 @@ execute (void)
 	}
 	}
 
-  if (string != commands[i].prog)
+  if (i && string != commands[i].prog)
 	free (CONST_CAST (char *, string));
 }
 
@@ -2903,6 +2913,16 @@ execute (void)
 	else if (WIFEXITED (status)
 		 && WEXITSTATUS (status) >= MIN_FATAL_STATUS)
 	  {
+#ifdef RETRY_ICE_SUPPORTED
+	/* For ICEs in cc1, cc1obj, cc1plus see if it is
+	   reproducible or not.  */
+	const char *p;
+	if (WEXITSTATUS (status) == ICE_EXIT_CODE
+		&& i == 0
+		&& (p = strrchr (commands[0].argv[0], DIR_SEPARATOR))
+		&& ! strncmp (p + 1, "cc1", 3))
+	  try_generate_repro (commands[0].prog, commands[0].argv);
+#endif
 	if (WEXITSTATUS (status) > greatest_status)
 	  greatest_status = WEXITSTATUS (status);
 	ret_code = -1;
@@ -2960,6 +2980,9 @@ execute (void)
 	  }
   }
 
+   if (commands[0].argv[0] != commands[0].prog)
+ free (CONST_CAST (char *, commands[0

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

[PATCH][Ping v4] Add patch for debugging compiler ICEs

[Maxim Ostapenko]

Ping. Added small changes due to previous discussion in community.


 Original Message 
Subject:[PATCH][Ping v3] Add patch for debugging compiler ICEs
Date:   Fri, 04 Jul 2014 18:32:44 +0400
From:   Maxim Ostapenko 
To: GCC Patches 
CC: 	Yury Gribov , Slava Garbuzov 
, Jakub Jelinek , 
tsaund...@mozilla.com, Maxim Ostapenko 




Ping.


 Original Message 
Subject:[PATCH][Ping v2] Add patch for debugging compiler ICEs
Date:   Thu, 26 Jun 2014 19:46:08 +0400
From:   Maxim Ostapenko 
To: GCC Patches 
CC: Yury Gribov , Slava Garbuzov
, Jakub Jelinek ,
tsaund...@mozilla.com, Maxim Ostapenko 



Ping.


 Original Message 
Subject:[PATCH][Ping] Add patch for debugging compiler ICEs
Date:   Wed, 11 Jun 2014 18:15:27 +0400
From:   Maxim Ostapenko 
To: GCC Patches 
CC: Yury Gribov , Slava Garbuzov
, Jakub Jelinek ,
tsaund...@mozilla.com, chefm...@gmail.com



Ping.


 Original Message 
Subject:[PATCH] Add patch for debugging compiler ICEs
Date:   Mon, 02 Jun 2014 19:21:14 +0400
From:   Maxim Ostapenko 
To: GCC Patches 
CC: Yury Gribov , Slava Garbuzov
, Jakub Jelinek ,
tsaund...@mozilla.com, chefm...@gmail.com



Hi,

A years ago there was a discussion 
(https://gcc.gnu.org/ml/gcc-patches/2004-01/msg02437.html) about debugging 
compiler ICEs that resulted in a patch from Jakub, which dumps
useful information into temporary file, but for some reasons this patch wasn't 
applied to trunk.

This is the resurrected patch with added GCC version information into generated 
repro file.

-Maxim










2014-06-02  Jakub Jelinek  
	Max Ostapenko  

	* diagnostic.c (diagnostic_action_after_output): Exit with
	ICE_EXIT_CODE instead of FATAL_EXIT_CODE.
	* gcc.c (execute): Don't free first string early, but at the end
	of the function.  Call retry_ice if compiler exited with
	ICE_EXIT_CODE.
	(main): Factor out common code.
	(print_configuration): New function.
	(try_fork): Likewise.
	(redirect_stdout_stderr): Likewise.
	(files_equal_p): Likewise.
	(check_repro): Likewise.
	(run_attempt): Likewise.
	(generate_preprocessed_code): Likewise.
	(append_text): Likewise.
	(try_generate_repro): Likewise.

diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
index 0cc7593..67b8c5b 100644
--- a/gcc/diagnostic.c
+++ b/gcc/diagnostic.c
@@ -492,7 +492,7 @@ diagnostic_action_after_output (diagnostic_context *context,
 	real_abort ();
   diagnostic_finish (context);
   fnotice (stderr, "compilation terminated.\n");
-  exit (FATAL_EXIT_CODE);
+  exit (ICE_EXIT_CODE);
 
 default:
   gcc_unreachable ();
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 6cd08ea..045363c 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -43,6 +43,13 @@ compilation is specified by a string called a "spec".  */
 #include "params.h"
 #include "vec.h"
 #include "filenames.h"
+#ifdef HAVE_UNISTD_H
+#include 
+#endif
+
+#if !(defined (__MSDOS__) || defined (OS2) || defined (VMS))
+#define RETRY_ICE_SUPPORTED
+#endif
 
 /* By default there is no special suffix for target executables.  */
 /* FIXME: when autoconf is fixed, remove the host check - dj */
@@ -253,6 +260,9 @@ static void init_gcc_specs (struct obstack *, const char *, const char *,
 static const char *convert_filename (const char *, int, int);
 #endif
 
+#ifdef RETRY_ICE_SUPPORTED
+static void try_generate_repro (const char *prog, const char **argv);
+#endif
 static const char *getenv_spec_function (int, const char **);
 static const char *if_exists_spec_function (int, const char **);
 static const char *if_exists_else_spec_function (int, const char **);
@@ -2850,7 +2860,7 @@ execute (void)
 	}
 	}
 
-  if (string != commands[i].prog)
+  if (i && string != commands[i].prog)
 	free (CONST_CAST (char *, string));
 }
 
@@ -2903,6 +2913,16 @@ execute (void)
 	else if (WIFEXITED (status)
 		 && WEXITSTATUS (status) >= MIN_FATAL_STATUS)
 	  {
+#ifdef RETRY_ICE_SUPPORTED
+	/* For ICEs in cc1, cc1obj, cc1plus see if it is
+	   reproducible or not.  */
+	const char *p;
+	if (WEXITSTATUS (status) == ICE_EXIT_CODE
+		&& i == 0
+		&& (p = strrchr (commands[0].argv[0], DIR_SEPARATOR))
+		&& ! strncmp (p + 1, "cc1", 3))
+	  try_generate_repro (commands[0].prog, commands[0].argv);
+#endif
 	if (WEXITSTATUS (status) > greatest_status)
 	  greatest_status = WEXITSTATUS (status);
 	ret_code = -1;
@@ -2960,6 +2980,9 @@ execute (void)
 	  }
   }
 
+   if (commands[0].argv[0] != commands[0].prog)
+ free (CONST_CAST (char *, commands[0].argv[0]));
+
 return ret_code;
   }
 }
@@ -6151,6 +6174,341 @@ give_switch (int switchnum, int omit_first_word)
   switches[switchnum].validated = true;
 }
 
+static void
+print_configuration (void)
+{
+  int n;
+  const char *thrmod;
+
+  fnotice (stderr, "Target: %s\n", spec_ma

[PATCH][Ping v3] Add patch for debugging compiler ICEs

[Maxim Ostapenko]

Ping.


 Original Message 
Subject:[PATCH][Ping v2] Add patch for debugging compiler ICEs
Date:   Thu, 26 Jun 2014 19:46:08 +0400
From:   Maxim Ostapenko 
To: GCC Patches 
CC: 	Yury Gribov , Slava Garbuzov 
, Jakub Jelinek , 
tsaund...@mozilla.com, Maxim Ostapenko 




Ping.


 Original Message 
Subject:[PATCH][Ping] Add patch for debugging compiler ICEs
Date:   Wed, 11 Jun 2014 18:15:27 +0400
From:   Maxim Ostapenko 
To: GCC Patches 
CC: Yury Gribov , Slava Garbuzov
, Jakub Jelinek ,
tsaund...@mozilla.com, chefm...@gmail.com



Ping.


 Original Message 
Subject:[PATCH] Add patch for debugging compiler ICEs
Date:   Mon, 02 Jun 2014 19:21:14 +0400
From:   Maxim Ostapenko 
To: GCC Patches 
CC: Yury Gribov , Slava Garbuzov
, Jakub Jelinek ,
tsaund...@mozilla.com, chefm...@gmail.com



Hi,

A years ago there was a discussion 
(https://gcc.gnu.org/ml/gcc-patches/2004-01/msg02437.html) about debugging 
compiler ICEs that resulted in a patch from Jakub, which dumps
useful information into temporary file, but for some reasons this patch wasn't 
applied to trunk.

This is the resurrected patch with added GCC version information into generated 
repro file.

-Maxim







2014-06-02  Jakub Jelinek  
	Max Ostapenko  

	* diagnostic.c (diagnostic_action_after_output): Exit with
	ICE_EXIT_CODE instead of FATAL_EXIT_CODE.
	* gcc.c (execute): Don't free first string early, but at the end
	of the function.  Call retry_ice if compiler exited with
	ICE_EXIT_CODE.
	(main): Factor out common code.
	(print_configuration): New function.
	(try_fork): Likewise.
	(redirect_stdout_stderr): Likewise.
	(files_equal_p): Likewise.
	(check_repro): Likewise.
	(run_attempt): Likewise.
	(generate_preprocessed_code): Likewise.
	(append_text): Likewise.
	(try_generate_repro): Likewise.

diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
index 0cc7593..67b8c5b 100644
--- a/gcc/diagnostic.c
+++ b/gcc/diagnostic.c
@@ -492,7 +492,7 @@ diagnostic_action_after_output (diagnostic_context *context,
 	real_abort ();
   diagnostic_finish (context);
   fnotice (stderr, "compilation terminated.\n");
-  exit (FATAL_EXIT_CODE);
+  exit (ICE_EXIT_CODE);
 
 default:
   gcc_unreachable ();
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 9ac18e6..86dce03 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -43,6 +43,13 @@ compilation is specified by a string called a "spec".  */
 #include "params.h"
 #include "vec.h"
 #include "filenames.h"
+#ifdef HAVE_UNISTD_H
+#include 
+#endif
+
+#if !(defined (__MSDOS__) || defined (OS2) || defined (VMS))
+#define RETRY_ICE_SUPPORTED
+#endif
 
 /* By default there is no special suffix for target executables.  */
 /* FIXME: when autoconf is fixed, remove the host check - dj */
@@ -253,6 +260,9 @@ static void init_gcc_specs (struct obstack *, const char *, const char *,
 static const char *convert_filename (const char *, int, int);
 #endif
 
+#ifdef RETRY_ICE_SUPPORTED
+static void try_generate_repro (const char *prog, const char **argv);
+#endif
 static const char *getenv_spec_function (int, const char **);
 static const char *if_exists_spec_function (int, const char **);
 static const char *if_exists_else_spec_function (int, const char **);
@@ -2797,7 +2807,7 @@ execute (void)
 	}
 	}
 
-  if (string != commands[i].prog)
+  if (i && string != commands[i].prog)
 	free (CONST_CAST (char *, string));
 }
 
@@ -2850,6 +2860,16 @@ execute (void)
 	else if (WIFEXITED (status)
 		 && WEXITSTATUS (status) >= MIN_FATAL_STATUS)
 	  {
+#ifdef RETRY_ICE_SUPPORTED
+	/* For ICEs in cc1, cc1obj, cc1plus see if it is
+	   reproducible or not.  */
+	const char *p;
+	if (WEXITSTATUS (status) == ICE_EXIT_CODE
+		&& i == 0
+		&& (p = strrchr (commands[0].argv[0], DIR_SEPARATOR))
+		&& ! strncmp (p + 1, "cc1", 3))
+	  try_generate_repro (commands[0].prog, commands[0].argv);
+#endif
 	if (WEXITSTATUS (status) > greatest_status)
 	  greatest_status = WEXITSTATUS (status);
 	ret_code = -1;
@@ -2907,6 +2927,9 @@ execute (void)
 	  }
   }
 
+   if (commands[0].argv[0] != commands[0].prog)
+ free (CONST_CAST (char *, commands[0].argv[0]));
+
 return ret_code;
   }
 }
@@ -6098,6 +6121,342 @@ give_switch (int switchnum, int omit_first_word)
   switches[switchnum].validated = true;
 }
 
+static void
+print_configuration (void)
+{
+  int n;
+  const char *thrmod;
+
+  fnotice (stderr, "Target: %s\n", spec_machine);
+  fnotice (stderr, "Configured with: %s\n", configuration_arguments);
+
+#ifdef THREAD_MODEL_SPEC
+  /* We could have defined THREAD_MODEL_SPEC to "%*" by default,
+  but there's no point in doing all this processing just to get
+  thread_model back.  */
+  obstack_init (&obstack);
+  do_spec_1 (THREAD_MODEL_SPEC, 0, thre

[PATCH][Ping v2] Add patch for debugging compiler ICEs

[Maxim Ostapenko]

Ping.


 Original Message 
Subject:[PATCH][Ping] Add patch for debugging compiler ICEs
Date:   Wed, 11 Jun 2014 18:15:27 +0400
From:   Maxim Ostapenko 
To: GCC Patches 
CC: 	Yury Gribov , Slava Garbuzov 
, Jakub Jelinek , 
tsaund...@mozilla.com, chefm...@gmail.com




Ping.


 Original Message 
Subject:[PATCH] Add patch for debugging compiler ICEs
Date:   Mon, 02 Jun 2014 19:21:14 +0400
From:   Maxim Ostapenko 
To: GCC Patches 
CC: Yury Gribov , Slava Garbuzov
, Jakub Jelinek ,
tsaund...@mozilla.com, chefm...@gmail.com



Hi,

A years ago there was a discussion 
(https://gcc.gnu.org/ml/gcc-patches/2004-01/msg02437.html) about debugging 
compiler ICEs that resulted in a patch from Jakub, which dumps
useful information into temporary file, but for some reasons this patch wasn't 
applied to trunk.

This is the resurrected patch with added GCC version information into generated 
repro file.

-Maxim




2014-06-02  Jakub Jelinek  
	Max Ostapenko  

	* diagnostic.c (diagnostic_action_after_output): Exit with
	ICE_EXIT_CODE instead of FATAL_EXIT_CODE.
	* gcc.c (execute): Don't free first string early, but at the end
	of the function.  Call retry_ice if compiler exited with
	ICE_EXIT_CODE.
	(main): Factor out common code.
	(print_configuration): New function.
	(try_fork): Likewise.
	(redirect_stdout_stderr): Likewise.
	(files_equal_p): Likewise.
	(check_repro): Likewise.
	(run_attempt): Likewise.
	(generate_preprocessed_code): Likewise.
	(append_text): Likewise.
	(try_generate_repro): Likewise.

diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
index 0cc7593..67b8c5b 100644
--- a/gcc/diagnostic.c
+++ b/gcc/diagnostic.c
@@ -492,7 +492,7 @@ diagnostic_action_after_output (diagnostic_context *context,
 	real_abort ();
   diagnostic_finish (context);
   fnotice (stderr, "compilation terminated.\n");
-  exit (FATAL_EXIT_CODE);
+  exit (ICE_EXIT_CODE);
 
 default:
   gcc_unreachable ();
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 9ac18e6..86dce03 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -43,6 +43,13 @@ compilation is specified by a string called a "spec".  */
 #include "params.h"
 #include "vec.h"
 #include "filenames.h"
+#ifdef HAVE_UNISTD_H
+#include 
+#endif
+
+#if !(defined (__MSDOS__) || defined (OS2) || defined (VMS))
+#define RETRY_ICE_SUPPORTED
+#endif
 
 /* By default there is no special suffix for target executables.  */
 /* FIXME: when autoconf is fixed, remove the host check - dj */
@@ -253,6 +260,9 @@ static void init_gcc_specs (struct obstack *, const char *, const char *,
 static const char *convert_filename (const char *, int, int);
 #endif
 
+#ifdef RETRY_ICE_SUPPORTED
+static void try_generate_repro (const char *prog, const char **argv);
+#endif
 static const char *getenv_spec_function (int, const char **);
 static const char *if_exists_spec_function (int, const char **);
 static const char *if_exists_else_spec_function (int, const char **);
@@ -2797,7 +2807,7 @@ execute (void)
 	}
 	}
 
-  if (string != commands[i].prog)
+  if (i && string != commands[i].prog)
 	free (CONST_CAST (char *, string));
 }
 
@@ -2850,6 +2860,16 @@ execute (void)
 	else if (WIFEXITED (status)
 		 && WEXITSTATUS (status) >= MIN_FATAL_STATUS)
 	  {
+#ifdef RETRY_ICE_SUPPORTED
+	/* For ICEs in cc1, cc1obj, cc1plus see if it is
+	   reproducible or not.  */
+	const char *p;
+	if (WEXITSTATUS (status) == ICE_EXIT_CODE
+		&& i == 0
+		&& (p = strrchr (commands[0].argv[0], DIR_SEPARATOR))
+		&& ! strncmp (p + 1, "cc1", 3))
+	  try_generate_repro (commands[0].prog, commands[0].argv);
+#endif
 	if (WEXITSTATUS (status) > greatest_status)
 	  greatest_status = WEXITSTATUS (status);
 	ret_code = -1;
@@ -2907,6 +2927,9 @@ execute (void)
 	  }
   }
 
+   if (commands[0].argv[0] != commands[0].prog)
+ free (CONST_CAST (char *, commands[0].argv[0]));
+
 return ret_code;
   }
 }
@@ -6098,6 +6121,342 @@ give_switch (int switchnum, int omit_first_word)
   switches[switchnum].validated = true;
 }
 
+static void
+print_configuration (void)
+{
+  int n;
+  const char *thrmod;
+
+  fnotice (stderr, "Target: %s\n", spec_machine);
+  fnotice (stderr, "Configured with: %s\n", configuration_arguments);
+
+#ifdef THREAD_MODEL_SPEC
+  /* We could have defined THREAD_MODEL_SPEC to "%*" by default,
+  but there's no point in doing all this processing just to get
+  thread_model back.  */
+  obstack_init (&obstack);
+  do_spec_1 (THREAD_MODEL_SPEC, 0, thread_model);
+  obstack_1grow (&obstack, '\0');
+  thrmod = XOBFINISH (&obstack, const char *);
+#else
+  thrmod = thread_model;
+#endif
+
+  fnotice (stderr, "Thread model: %s\n", thrmod);
+
+  /* compiler_version is truncated at the first space when initialized
+  from version st

Re: [PATCH][PING] Fix for PR 61422

[Yury Gribov]

Have already been done in r211699. Does it work for you? Adding a test 
would still be useful.


-Y

[PATCH][PING] Fix for PR 61422

[Marat Zakirov]

-Original Message-
From: Marat Zakirov [mailto:m.zaki...@samsung.com] 
Sent: Friday, June 06, 2014 3:43 PM
To: 'gcc-patches@gcc.gnu.org'
Cc: 'Konstantin Serebryany'; 'Jakub Jelinek'; 'Slava Garbuzov'; Gribov Yury;
'Marat Zakirov'
Subject: [PATCH] Fix for PR 61422

Hi all,

Here's a patch for PR 61422
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61422). 

It fixes false positive on 16 byte access in ffmpeg standard library opus
file NLSF_del_dec_quant.c.  

Reg. tested on x64.

--Marat


PR61422.diff
Description: Binary data

[PATCH][Ping] Add patch for debugging compiler ICEs

[Maxim Ostapenko]

Ping.


 Original Message 
Subject:[PATCH] Add patch for debugging compiler ICEs
Date:   Mon, 02 Jun 2014 19:21:14 +0400
From:   Maxim Ostapenko 
To: GCC Patches 
CC: 	Yury Gribov , Slava Garbuzov 
, Jakub Jelinek , 
tsaund...@mozilla.com, chefm...@gmail.com




Hi,

A years ago there was a discussion 
(https://gcc.gnu.org/ml/gcc-patches/2004-01/msg02437.html) about debugging 
compiler ICEs that resulted in a patch from Jakub, which dumps
useful information into temporary file, but for some reasons this patch wasn't 
applied to trunk.

This is the resurrected patch with added GCC version information into generated 
repro file.

-Maxim

2014-06-02  Jakub Jelinek  
	Max Ostapenko  

	* diagnostic.c (diagnostic_action_after_output): Exit with
	ICE_EXIT_CODE instead of FATAL_EXIT_CODE.
	* gcc.c (execute): Don't free first string early, but at the end
	of the function.  Call retry_ice if compiler exited with
	ICE_EXIT_CODE.
	(main): Factor out common code.
	(print_configuration): New function.
	(try_fork): Likewise.
	(redirect_stdout_stderr): Likewise.
	(files_equal_p): Likewise.
	(check_repro): Likewise.
	(run_attempt): Likewise.
	(generate_preprocessed_code): Likewise.
	(append_text): Likewise.
	(try_generate_repro): Likewise.

diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
index 0cc7593..67b8c5b 100644
--- a/gcc/diagnostic.c
+++ b/gcc/diagnostic.c
@@ -492,7 +492,7 @@ diagnostic_action_after_output (diagnostic_context *context,
 	real_abort ();
   diagnostic_finish (context);
   fnotice (stderr, "compilation terminated.\n");
-  exit (FATAL_EXIT_CODE);
+  exit (ICE_EXIT_CODE);
 
 default:
   gcc_unreachable ();
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 9ac18e6..86dce03 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -43,6 +43,13 @@ compilation is specified by a string called a "spec".  */
 #include "params.h"
 #include "vec.h"
 #include "filenames.h"
+#ifdef HAVE_UNISTD_H
+#include 
+#endif
+
+#if !(defined (__MSDOS__) || defined (OS2) || defined (VMS))
+#define RETRY_ICE_SUPPORTED
+#endif
 
 /* By default there is no special suffix for target executables.  */
 /* FIXME: when autoconf is fixed, remove the host check - dj */
@@ -253,6 +260,9 @@ static void init_gcc_specs (struct obstack *, const char *, const char *,
 static const char *convert_filename (const char *, int, int);
 #endif
 
+#ifdef RETRY_ICE_SUPPORTED
+static void try_generate_repro (const char *prog, const char **argv);
+#endif
 static const char *getenv_spec_function (int, const char **);
 static const char *if_exists_spec_function (int, const char **);
 static const char *if_exists_else_spec_function (int, const char **);
@@ -2797,7 +2807,7 @@ execute (void)
 	}
 	}
 
-  if (string != commands[i].prog)
+  if (i && string != commands[i].prog)
 	free (CONST_CAST (char *, string));
 }
 
@@ -2850,6 +2860,16 @@ execute (void)
 	else if (WIFEXITED (status)
 		 && WEXITSTATUS (status) >= MIN_FATAL_STATUS)
 	  {
+#ifdef RETRY_ICE_SUPPORTED
+	/* For ICEs in cc1, cc1obj, cc1plus see if it is
+	   reproducible or not.  */
+	const char *p;
+	if (WEXITSTATUS (status) == ICE_EXIT_CODE
+		&& i == 0
+		&& (p = strrchr (commands[0].argv[0], DIR_SEPARATOR))
+		&& ! strncmp (p + 1, "cc1", 3))
+	  try_generate_repro (commands[0].prog, commands[0].argv);
+#endif
 	if (WEXITSTATUS (status) > greatest_status)
 	  greatest_status = WEXITSTATUS (status);
 	ret_code = -1;
@@ -2907,6 +2927,9 @@ execute (void)
 	  }
   }
 
+   if (commands[0].argv[0] != commands[0].prog)
+ free (CONST_CAST (char *, commands[0].argv[0]));
+
 return ret_code;
   }
 }
@@ -6098,6 +6121,342 @@ give_switch (int switchnum, int omit_first_word)
   switches[switchnum].validated = true;
 }
 
+static void
+print_configuration (void)
+{
+  int n;
+  const char *thrmod;
+
+  fnotice (stderr, "Target: %s\n", spec_machine);
+  fnotice (stderr, "Configured with: %s\n", configuration_arguments);
+
+#ifdef THREAD_MODEL_SPEC
+  /* We could have defined THREAD_MODEL_SPEC to "%*" by default,
+  but there's no point in doing all this processing just to get
+  thread_model back.  */
+  obstack_init (&obstack);
+  do_spec_1 (THREAD_MODEL_SPEC, 0, thread_model);
+  obstack_1grow (&obstack, '\0');
+  thrmod = XOBFINISH (&obstack, const char *);
+#else
+  thrmod = thread_model;
+#endif
+
+  fnotice (stderr, "Thread model: %s\n", thrmod);
+
+  /* compiler_version is truncated at the first space when initialized
+  from version string, so truncate version_string at the first space
+  before comparing.  */
+  for (n = 0; version_string[n]; n++)
+if (version_string[n] == ' ')
+  break;
+
+  if (! strncmp (version_string, compiler_version, n)
+  && compiler_version[n] == 0)
+fnotice (stderr, "gcc version %s %s\n\n", version_string,
+ pkgversion_string);
+  else
+fnotice (stderr, "gcc driver version %s %sexecuting gcc version %s\n\n",
+ version_string, pkgversion_st

Re: [patch ping] libstdc++ testsuite cxxflags

[Jonathan Wakely]

On 30/05/14 08:53 +0100, Ramana Radhakrishnan wrote:

With all the other build breakages in the past week,  I've just
started seeing the first set of testresults from an auto-tester. It
looks like on a cross test using rhe5 / x86_64  with the version of
tcl8.4 I'm using I see the same errors that David saw.

The testsuite starts running if I tried the above

regexp ".*-O" $cxxflags

Is this going to be applied - what gives ?


Fixed with the attached patch.

Tested x86_64-linux (but onnly with Tcl 8.5), committed to trunk.


commit 8e72d35ed67a51df88c359249590e266c476044e
Author: Jonathan Wakely 
Date:   Fri May 30 11:10:57 2014 +0100

* testsuite/lib/libstdc++.exp (libstdc++_init): Adjust regexp to
work with previous versions of Tcl.

diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
b/libstdc++-v3/testsuite/lib/libstdc++.exp
index 2b2a38b..d91bed6 100644
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -283,7 +283,7 @@ proc libstdc++_init { testfile } {
 append cxxflags " "
 append cxxflags [getenv CXXFLAGS]
 
-if ![regexp "\-O" $cxxflags] {
+if ![regexp ".*-O" $cxxflags] {
append cxxflags " -g -O2"
 }
 

Re: [patch ping] libstdc++ testsuite cxxflags

[Ramana Radhakrishnan]

On Sat, May 24, 2014 at 5:54 PM, Jonathan Wakely  wrote:
> On 24 May 2014 17:07, David Edelsohn wrote:
>> This patch broke the ability to run the libstdc++ testsuite on AIX.
>>
>> I now see the following errors:
>>
>> bad switch "-O": must be -all, -about, -indices, -inline, -expanded, -line, 
>> -lin
>> estop, -lineanchor, -nocase, -start, or --
>> while executing
>> "regexp "\-O" $cxxflags"
>
> Would this work instead?
>
>regexp ".*-O" $cxxflags


With all the other build breakages in the past week,  I've just
started seeing the first set of testresults from an auto-tester. It
looks like on a cross test using rhe5 / x86_64  with the version of
tcl8.4 I'm using I see the same errors that David saw.

The testsuite starts running if I tried the above

regexp ".*-O" $cxxflags

Is this going to be applied - what gives ?

regards
Ramana

Re: [patch ping] libstdc++ testsuite cxxflags

[David Edelsohn]

On Sat, May 24, 2014 at 12:54 PM, Jonathan Wakely  wrote:
> On 24 May 2014 17:07, David Edelsohn wrote:
>> This patch broke the ability to run the libstdc++ testsuite on AIX.
>>
>> I now see the following errors:
>>
>> bad switch "-O": must be -all, -about, -indices, -inline, -expanded, -line, 
>> -lin
>> estop, -lineanchor, -nocase, -start, or --
>> while executing
>> "regexp "\-O" $cxxflags"
>
> Would this work instead?
>
>regexp ".*-O" $cxxflags

That change does seem to fix the problem as seen by libstdc++ in
latest AIX testresults.

Thanks, David

Re: [patch ping] libstdc++ testsuite cxxflags

[Jonathan Wakely]

On 24 May 2014 17:07, David Edelsohn wrote:
> This patch broke the ability to run the libstdc++ testsuite on AIX.
>
> I now see the following errors:
>
> bad switch "-O": must be -all, -about, -indices, -inline, -expanded, -line, 
> -lin
> estop, -lineanchor, -nocase, -start, or --
> while executing
> "regexp "\-O" $cxxflags"

Would this work instead?

   regexp ".*-O" $cxxflags

Re: [patch ping] libstdc++ testsuite cxxflags

[David Edelsohn]

This patch broke the ability to run the libstdc++ testsuite on AIX.

I now see the following errors:

bad switch "-O": must be -all, -about, -indices, -inline, -expanded, -line, -lin
estop, -lineanchor, -nocase, -start, or --
while executing
"regexp "\-O" $cxxflags"
(procedure "libstdc++_init" line 183)
invoked from within
"${tool}_init $test_file_name"
invoked from within
"if [info exists tool] {
if { [info procs "${tool}_init"] != "" } {
${tool}_init $test_file_name
}
}"
invoked from within
"if [file exists $test_file_name] {
set timestart [timestamp]

if [info exists tool] {
if { [info procs "${tool}_init"] != "" } {
${tool}_init..."
(procedure "runtest" line 14)
invoked from within
"runtest $test_name"
("foreach" body line 42)
invoked from within
"foreach test_name [lsort [find ${dir} *.exp]] {
if { ${test_name} == "" } {
continue
}
# Ignore this one if asked to.
if { ${ignore..."
("foreach" body line 54)
invoked from within
"foreach dir "${test_top_dirs}" {
if { ${dir} != ${srcdir} } {
# Ignore this directory if is a directory to be
# ignored.
if {[info..."
("foreach" body line 121)
invoked from within
"foreach pass $multipass {

# multipass_name is set for `record_test' to use (see framework.exp).
if { [lindex $pass 0] != "" } {
set multipass_..."
("foreach" body line 51)
invoked from within
"foreach current_target $target_list {
verbose "target is $current_target"
set current_target_name $current_target
set tlist [split $curren..."
(file "/gsa/yktgsa/home/e/d/edelsohn/share/dejagnu/runtest.exp" line 1625)

Re: [patch ping] libstdc++ testsuite cxxflags

[Cesar Philippidis]

On 05/20/2014 02:11 AM, Jonathan Wakely wrote:
> On 19/05/14 14:57 -0600, Sandra Loosemore wrote:
>> On 05/17/2014 04:07 AM, Jonathan Wakely wrote:
>>> On 17 May 2014 10:50, Jonathan Wakely wrote:
 On 17 May 2014 01:16, Sandra Loosemore wrote:
> It appears that this patch from last fall never got reviewed.
>
> https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02340.html
>
> Can someone take a look?  I'll commit the patch on Cesar's behalf
> if it's
> approved.

 Libstdc++ patches need to go to the libstdc++ list, which this did, in
 a separate mail that broke the threading:
 https://gcc.gnu.org/ml/libstdc++/2013-10/msg00224.html
 Then archives's inability to thread betweem months broke it again:
 https://gcc.gnu.org/ml/libstdc++/2013-11/msg00113.html

 I approved it then withdrew that approval:
 https://gcc.gnu.org/ml/libstdc++/2013-11/msg00120.html
 then the patch got revised:
 https://gcc.gnu.org/ml/libstdc++/2013-11/msg00122.html

 I'll have to refresh my memory about it.
>>
>> Whoops, I totally missed that there was already a separate thread on
>> the libstdc++ mailing list only.  My bad.  :-(
>>
>>> I think I'm happiest with the second version of the patch, in
>>> https://gcc.gnu.org/ml/libstdc++/2013-11/msg00114.html
>>>
>>> It does mean a change that might affect people using CXXFLAGS when
>>> running the tests, so we might want to update
>>> https://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html where it says
>>> "Or, just run the testsuites with CXXFLAGS set to -D_GLIBCXX_DEBUG or
>>> -D_GLIBCXX_PARALLEL."
>>
>> I came up with the attached patch for the wording change.  I'm having
>> trouble regenerating the HTML version of the manual, though; it looks
>> like I have a different version of the DocBook stylesheets around that
>> are introducing lots of extraneous changes, and I'm not sure what the
>> "right" version is.  :-S  Any suggestions?
> 
> You always get hundreds of changes, DocBook generates unique numeric
> id attributes, which are different every run. Don't worr yabout the
> docs, I can sort them out. If you and Cesar are happy with the patch
> in https://gcc.gnu.org/ml/libstdc++/2013-11/msg00114.html then please
> go ahead and commit that version, thanks.

Looking back at my notes, this patch addresses the libstdc++ atomics
test failures when using a custom site.exp. Without the -O2 flag, those
tests would fail to link because of the dependency on libatomic.

I'm happy with the second patch. Sandra please commit it.

Thanks,
Cesar

Re: [PATCH] [PING^2] Fix for PR libstdc++/60758

[Alexey Merzlyakov]

On 20.05.2014 17:16, Richard Earnshaw wrote:

On 20/05/14 14:12, Ramana Radhakrishnan wrote:

The following PR is opened for this problem:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61223

Thumb1 failure was also detected and reported in pr60758.
I've proposed a thumb1 bugfix there. Regtest for the fix currently is in
progress.

Patches must be proposed on gcc-patches and / or in this case

Never OR.  Patches must always go to gcc-patches.  They may *also* go to
other lists, if appropriate.

R.


libstdc++-patches mailing list. Attaching patches to bugzilla does not
ensure review.

Thanks,
Ramana


Best regards,
Merzlyakov Alexey


Thanks, created a thread with proposed fix:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01640.html

Best regards,
Merzlyakov Alexey

Re: [PATCH] [PING^2] Fix for PR libstdc++/60758

[Richard Earnshaw]

On 20/05/14 14:12, Ramana Radhakrishnan wrote:
> 
>>
>> The following PR is opened for this problem:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61223
>>
>> Thumb1 failure was also detected and reported in pr60758.
>> I've proposed a thumb1 bugfix there. Regtest for the fix currently is in
>> progress.
> 
> Patches must be proposed on gcc-patches and / or in this case 

Never OR.  Patches must always go to gcc-patches.  They may *also* go to
other lists, if appropriate.

R.

> libstdc++-patches mailing list. Attaching patches to bugzilla does not 
> ensure review.
> 
> Thanks,
> Ramana
> 
>>
>> Best regards,
>> Merzlyakov Alexey
>>
> 

Re: [PATCH] [PING^2] Fix for PR libstdc++/60758

[Ramana Radhakrishnan]

The following PR is opened for this problem:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61223

Thumb1 failure was also detected and reported in pr60758.
I've proposed a thumb1 bugfix there. Regtest for the fix currently is in
progress.


Patches must be proposed on gcc-patches and / or in this case 
libstdc++-patches mailing list. Attaching patches to bugzilla does not 
ensure review.


Thanks,
Ramana



Best regards,
Merzlyakov Alexey

Re: [PATCH] [PING^2] Fix for PR libstdc++/60758

[Alexey Merzlyakov]

On 20.05.2014 16:25, Richard Earnshaw wrote:

On 16/05/14 14:56, Alexey Merzlyakov wrote:

On 07.05.2014 13:28, Ramana Radhakrishnan wrote:

On 05/07/14 09:19, Yury Gribov wrote:

 Original Message 
Subject: [PING] [PATCH] Fix for PR libstdc++/60758
Date: Thu, 17 Apr 2014 17:48:12 +0400
From: Alexey Merzlyakov 
To: Ramana Radhakrishnan 
CC: gcc-patches@gcc.gnu.org , Viacheslav
Garbuzov , Yury Gribov 

Hi,

This fixes infinite backtrace in __cxa_end_cleanup().
Regtest was finished with no regressions on arm-linux-gnueabi(sf).

The patch posted at:
 http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00496.html

This is OK to apply if no regressions.

Thanks,
Ramana


Thanks in advance.

Best regards,
Merzlyakov Alexey



I have re-tested it again on arm-linux-gnueabi(sf) - no regressions.
The change was committed to mainline as revision 210515.

Best regards,
Merzlyakov Alexey



Unfortunately, this breaks thumb1.  Pop instructions there can only
contain low registers and the PC.

R.



The following PR is opened for this problem:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61223

Thumb1 failure was also detected and reported in pr60758.
I've proposed a thumb1 bugfix there. Regtest for the fix currently is in 
progress.


Best regards,
Merzlyakov Alexey

Re: [PATCH] [PING^2] Fix for PR libstdc++/60758

[Richard Earnshaw]

On 16/05/14 14:56, Alexey Merzlyakov wrote:
> On 07.05.2014 13:28, Ramana Radhakrishnan wrote:
>> On 05/07/14 09:19, Yury Gribov wrote:
>>>  Original Message 
>>> Subject: [PING] [PATCH] Fix for PR libstdc++/60758
>>> Date: Thu, 17 Apr 2014 17:48:12 +0400
>>> From: Alexey Merzlyakov 
>>> To: Ramana Radhakrishnan 
>>> CC: gcc-patches@gcc.gnu.org , Viacheslav
>>> Garbuzov , Yury Gribov 
>>>
>>> Hi,
>>>
>>> This fixes infinite backtrace in __cxa_end_cleanup().
>>> Regtest was finished with no regressions on arm-linux-gnueabi(sf).
>>>
>>> The patch posted at:
>>> http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00496.html
>>
>> This is OK to apply if no regressions.
>>
>> Thanks,
>> Ramana
>>
>>>
>>> Thanks in advance.
>>>
>>> Best regards,
>>> Merzlyakov Alexey
>>>
>>>
>>
> I have re-tested it again on arm-linux-gnueabi(sf) - no regressions.
> The change was committed to mainline as revision 210515.
> 
> Best regards,
> Merzlyakov Alexey
> 
> 

Unfortunately, this breaks thumb1.  Pop instructions there can only
contain low registers and the PC.

R.

Re: [patch ping] libstdc++ testsuite cxxflags

[Jonathan Wakely]

On 19/05/14 14:57 -0600, Sandra Loosemore wrote:

On 05/17/2014 04:07 AM, Jonathan Wakely wrote:

On 17 May 2014 10:50, Jonathan Wakely wrote:

On 17 May 2014 01:16, Sandra Loosemore wrote:

It appears that this patch from last fall never got reviewed.

https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02340.html

Can someone take a look?  I'll commit the patch on Cesar's behalf if it's
approved.


Libstdc++ patches need to go to the libstdc++ list, which this did, in
a separate mail that broke the threading:
https://gcc.gnu.org/ml/libstdc++/2013-10/msg00224.html
Then archives's inability to thread betweem months broke it again:
https://gcc.gnu.org/ml/libstdc++/2013-11/msg00113.html

I approved it then withdrew that approval:
https://gcc.gnu.org/ml/libstdc++/2013-11/msg00120.html
then the patch got revised:
https://gcc.gnu.org/ml/libstdc++/2013-11/msg00122.html

I'll have to refresh my memory about it.


Whoops, I totally missed that there was already a separate thread on 
the libstdc++ mailing list only.  My bad.  :-(



I think I'm happiest with the second version of the patch, in
https://gcc.gnu.org/ml/libstdc++/2013-11/msg00114.html

It does mean a change that might affect people using CXXFLAGS when
running the tests, so we might want to update
https://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html where it says
"Or, just run the testsuites with CXXFLAGS set to -D_GLIBCXX_DEBUG or
-D_GLIBCXX_PARALLEL."


I came up with the attached patch for the wording change.  I'm having 
trouble regenerating the HTML version of the manual, though; it looks 
like I have a different version of the DocBook stylesheets around that 
are introducing lots of extraneous changes, and I'm not sure what the 
"right" version is.  :-S  Any suggestions?


You always get hundreds of changes, DocBook generates unique numeric
id attributes, which are different every run. Don't worr yabout the
docs, I can sort them out. If you and Cesar are happy with the patch
in https://gcc.gnu.org/ml/libstdc++/2013-11/msg00114.html then please
go ahead and commit that version, thanks.

Re: [patch ping] libstdc++ testsuite cxxflags

[Sandra Loosemore]

On 05/17/2014 04:07 AM, Jonathan Wakely wrote:

On 17 May 2014 10:50, Jonathan Wakely wrote:

On 17 May 2014 01:16, Sandra Loosemore wrote:

It appears that this patch from last fall never got reviewed.

https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02340.html

Can someone take a look?  I'll commit the patch on Cesar's behalf if it's
approved.


Libstdc++ patches need to go to the libstdc++ list, which this did, in
a separate mail that broke the threading:
https://gcc.gnu.org/ml/libstdc++/2013-10/msg00224.html
Then archives's inability to thread betweem months broke it again:
https://gcc.gnu.org/ml/libstdc++/2013-11/msg00113.html

I approved it then withdrew that approval:
https://gcc.gnu.org/ml/libstdc++/2013-11/msg00120.html
then the patch got revised:
https://gcc.gnu.org/ml/libstdc++/2013-11/msg00122.html

I'll have to refresh my memory about it.


Whoops, I totally missed that there was already a separate thread on the 
libstdc++ mailing list only.  My bad.  :-(



I think I'm happiest with the second version of the patch, in
https://gcc.gnu.org/ml/libstdc++/2013-11/msg00114.html

It does mean a change that might affect people using CXXFLAGS when
running the tests, so we might want to update
https://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html where it says
"Or, just run the testsuites with CXXFLAGS set to -D_GLIBCXX_DEBUG or
-D_GLIBCXX_PARALLEL."


I came up with the attached patch for the wording change.  I'm having 
trouble regenerating the HTML version of the manual, though; it looks 
like I have a different version of the DocBook stylesheets around that 
are introducing lots of extraneous changes, and I'm not sure what the 
"right" version is.  :-S  Any suggestions?


-Sandra
Index: libstdc++-v3/doc/xml/manual/test.xml
===
--- libstdc++-v3/doc/xml/manual/test.xml	(revision 210575)
+++ libstdc++-v3/doc/xml/manual/test.xml	(working copy)
@@ -478,9 +478,11 @@ runtest --tool libstdc++ --srcdir=/path/
 
 
 
-  Or, just run the testsuites with CXXFLAGS
-  set to -D_GLIBCXX_DEBUG or
-  -D_GLIBCXX_PARALLEL.
+  You can also run the testsuites by setting
+  CXXFLAGS in the environment.  In this case,
+  however, you should also make sure that CXXFLAGS
+  includes -g -O2, since some tests assume the
+  presence of these options.
 
   
 

Re: [PATCH PING^2] Simplify a VEC_SELECT fed by its own inverse

[Jeff Law]

On 05/19/14 07:10, Bill Schmidt wrote:

Hi,

I'd like to once again ping this patch from 2014-04-22:

 http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01319.html

OK for the trunk.  Thanks for your patience.

jeff

[PATCH PING^2] Simplify a VEC_SELECT fed by its own inverse

[Bill Schmidt]

Hi,

I'd like to once again ping this patch from 2014-04-22: 

http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01319.html

Thanks!

Bill

Re: [patch ping] libstdc++ testsuite cxxflags

[Jonathan Wakely]

On 17 May 2014 10:50, Jonathan Wakely wrote:
> On 17 May 2014 01:16, Sandra Loosemore wrote:
>> It appears that this patch from last fall never got reviewed.
>>
>> https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02340.html
>>
>> Can someone take a look?  I'll commit the patch on Cesar's behalf if it's
>> approved.
>
> Libstdc++ patches need to go to the libstdc++ list, which this did, in
> a separate mail that broke the threading:
> https://gcc.gnu.org/ml/libstdc++/2013-10/msg00224.html
> Then archives's inability to thread betweem months broke it again:
> https://gcc.gnu.org/ml/libstdc++/2013-11/msg00113.html
>
> I approved it then withdrew that approval:
> https://gcc.gnu.org/ml/libstdc++/2013-11/msg00120.html
> then the patch got revised:
> https://gcc.gnu.org/ml/libstdc++/2013-11/msg00122.html
>
> I'll have to refresh my memory about it.

I think I'm happiest with the second version of the patch, in
https://gcc.gnu.org/ml/libstdc++/2013-11/msg00114.html

It does mean a change that might affect people using CXXFLAGS when
running the tests, so we might want to update
https://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html where it says
"Or, just run the testsuites with CXXFLAGS set to -D_GLIBCXX_DEBUG or
-D_GLIBCXX_PARALLEL."

Re: [patch ping] libstdc++ testsuite cxxflags

[Jonathan Wakely]

On 17 May 2014 10:50, Jonathan Wakely wrote:
> Then archives's inability...

Oof, not sure what my fingers were thinking there, I meant "Then the
archive's inability..."  :)

Re: [patch ping] libstdc++ testsuite cxxflags

[Jonathan Wakely]

On 17 May 2014 01:16, Sandra Loosemore wrote:
> It appears that this patch from last fall never got reviewed.
>
> https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02340.html
>
> Can someone take a look?  I'll commit the patch on Cesar's behalf if it's
> approved.

Libstdc++ patches need to go to the libstdc++ list, which this did, in
a separate mail that broke the threading:
https://gcc.gnu.org/ml/libstdc++/2013-10/msg00224.html
Then archives's inability to thread betweem months broke it again:
https://gcc.gnu.org/ml/libstdc++/2013-11/msg00113.html

I approved it then withdrew that approval:
https://gcc.gnu.org/ml/libstdc++/2013-11/msg00120.html
then the patch got revised:
https://gcc.gnu.org/ml/libstdc++/2013-11/msg00122.html

I'll have to refresh my memory about it.

Re: [patch ping] libstdc++ testsuite cxxflags

[Mike Stump]

On May 16, 2014, at 5:16 PM, Sandra Loosemore  wrote:
> It appears that this patch from last fall never got reviewed.

> Can someone take a look?

Tentative Ok.  Let’s let the library people have a chance to weigh in…  I’d 
say, let’s give them til Tuesday…  should be enough time...

[patch ping] libstdc++ testsuite cxxflags

[Sandra Loosemore]

It appears that this patch from last fall never got reviewed.

https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02340.html

Can someone take a look?  I'll commit the patch on Cesar's behalf if 
it's approved.


-Sandra

Re: [PATCH] [PING^2] Fix for PR libstdc++/60758

[Alexey Merzlyakov]

On 07.05.2014 13:28, Ramana Radhakrishnan wrote:

On 05/07/14 09:19, Yury Gribov wrote:

 Original Message 
Subject: [PING] [PATCH] Fix for PR libstdc++/60758
Date: Thu, 17 Apr 2014 17:48:12 +0400
From: Alexey Merzlyakov 
To: Ramana Radhakrishnan 
CC: gcc-patches@gcc.gnu.org , Viacheslav
Garbuzov , Yury Gribov 

Hi,

This fixes infinite backtrace in __cxa_end_cleanup().
Regtest was finished with no regressions on arm-linux-gnueabi(sf).

The patch posted at:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00496.html


This is OK to apply if no regressions.

Thanks,
Ramana



Thanks in advance.

Best regards,
Merzlyakov Alexey





I have re-tested it again on arm-linux-gnueabi(sf) - no regressions.
The change was committed to mainline as revision 210515.

Best regards,
Merzlyakov Alexey

Re: [PATCH Ping v2] Extend -fstack-protector-strong to cover calls with return slot

[Jeff Law]

On 05/05/14 05:58, Florian Weimer wrote:

On 02/03/2014 10:05 AM, Florian Weimer wrote:

On 01/17/2014 11:26 AM, Florian Weimer wrote:

On 01/08/2014 03:57 PM, Florian Weimer wrote:


What about the attached version?  It still does not exactly match your
original suggestion because gimple_call_lhs (stmt) can be NULL_TREE if
the result is ignored and this case needs instrumentation, as you
explained, so I use the function return type in the aggregate_value_p
check.

Testing is still under way, but looks good so far.  I'm bootstrapping
with BOOT_CFLAGS="-O2 -g -fstack-protector-strong" with Ada enabled,
for
additional coverage.


Testing passed without new regressions.  Is this okay for trunk?


Ping?  Thanks.


Now that 4.9 is released, I'd like to propose again this fix for inclusion:



OK for the trunk.

jeff

Re: [PATCH] [PING^2] Fix for PR libstdc++/60758

[Ramana Radhakrishnan]

On 05/07/14 09:19, Yury Gribov wrote:

 Original Message 
Subject: [PING] [PATCH] Fix for PR libstdc++/60758
Date: Thu, 17 Apr 2014 17:48:12 +0400
From: Alexey Merzlyakov 
To: Ramana Radhakrishnan 
CC: gcc-patches@gcc.gnu.org , Viacheslav
Garbuzov , Yury Gribov 

Hi,

This fixes infinite backtrace in __cxa_end_cleanup().
Regtest was finished with no regressions on arm-linux-gnueabi(sf).

The patch posted at:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00496.html


This is OK to apply if no regressions.

Thanks,
Ramana



Thanks in advance.

Best regards,
Merzlyakov Alexey

Re: [PATCH] [PING^2] Fix for PR libstdc++/60758

[Paolo Carlini]

Hi,

On 05/07/2014 10:19 AM, Yury Gribov wrote:

 Original Message 
Subject: [PING] [PATCH] Fix for PR libstdc++/60758
Date: Thu, 17 Apr 2014 17:48:12 +0400
From: Alexey Merzlyakov 
To: Ramana Radhakrishnan 
CC: gcc-patches@gcc.gnu.org , Viacheslav 
Garbuzov , Yury Gribov 


Hi,

This fixes infinite backtrace in __cxa_end_cleanup().
Regtest was finished with no regressions on arm-linux-gnueabi(sf).

The patch posted at:
  http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00496.html
I think you want an ARM maintainer for this. I'm adding some in CC. 
Also, remember to send patches touching the C++ library to the mailing 
list too.


Paolo.

[PATCH] [PING^2] Fix for PR libstdc++/60758

[Yury Gribov]

 Original Message 
Subject: [PING] [PATCH] Fix for PR libstdc++/60758
Date: Thu, 17 Apr 2014 17:48:12 +0400
From: Alexey Merzlyakov 
To: Ramana Radhakrishnan 
CC: gcc-patches@gcc.gnu.org , Viacheslav 
Garbuzov , Yury Gribov 


Hi,

This fixes infinite backtrace in __cxa_end_cleanup().
Regtest was finished with no regressions on arm-linux-gnueabi(sf).

The patch posted at:
  http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00496.html

Thanks in advance.

Best regards,
Merzlyakov Alexey



2014-05-07  Alexey Merzlyakov 

	PR libstdc++/60758
	* libsupc++/eh_arm.cc (__cxa_end_cleanup): Change r4 to lr in save/restore
	and add unwind directives.

diff --git a/libstdc++-v3/libsupc++/eh_arm.cc b/libstdc++-v3/libsupc++/eh_arm.cc
index aa453dd..6a45af5 100644
--- a/libstdc++-v3/libsupc++/eh_arm.cc
+++ b/libstdc++-v3/libsupc++/eh_arm.cc
@@ -199,27 +199,33 @@ asm (".global __cxa_end_cleanup\n"
 "	nop		5\n");
 #else
 // Assembly wrapper to call __gnu_end_cleanup without clobbering r1-r3.
-// Also push r4 to preserve stack alignment.
+// Also push lr to preserve stack alignment and to allow backtracing.
 #ifdef __thumb__
 asm ("  .pushsection .text.__cxa_end_cleanup\n"
 "	.global __cxa_end_cleanup\n"
 "	.type __cxa_end_cleanup, \"function\"\n"
 "	.thumb_func\n"
 "__cxa_end_cleanup:\n"
-"	push\t{r1, r2, r3, r4}\n"
+"	.fnstart\n"
+"	push\t{r1, r2, r3, lr}\n"
+"	.save\t{r1, r2, r3, lr}\n"
 "	bl\t__gnu_end_cleanup\n"
-"	pop\t{r1, r2, r3, r4}\n"
+"	pop\t{r1, r2, r3, lr}\n"
 "	bl\t_Unwind_Resume @ Never returns\n"
+"	.fnend\n"
 "	.popsection\n");
 #else
 asm ("  .pushsection .text.__cxa_end_cleanup\n"
 "	.global __cxa_end_cleanup\n"
 "	.type __cxa_end_cleanup, \"function\"\n"
 "__cxa_end_cleanup:\n"
-"	stmfd\tsp!, {r1, r2, r3, r4}\n"
+"	.fnstart\n"
+"	stmfd\tsp!, {r1, r2, r3, lr}\n"
+"	.save\t{r1, r2, r3, lr}\n"
 "	bl\t__gnu_end_cleanup\n"
-"	ldmfd\tsp!, {r1, r2, r3, r4}\n"
+"	ldmfd\tsp!, {r1, r2, r3, lr}\n"
 "	bl\t_Unwind_Resume @ Never returns\n"
+"	.fnend\n"
 "	.popsection\n");
 #endif
 #endif

Re: [PATCH Ping v2] Extend -fstack-protector-strong to cover calls with return slot

[Florian Weimer]

On 02/03/2014 10:05 AM, Florian Weimer wrote:

On 01/17/2014 11:26 AM, Florian Weimer wrote:

On 01/08/2014 03:57 PM, Florian Weimer wrote:


What about the attached version?  It still does not exactly match your
original suggestion because gimple_call_lhs (stmt) can be NULL_TREE if
the result is ignored and this case needs instrumentation, as you
explained, so I use the function return type in the aggregate_value_p
check.

Testing is still under way, but looks good so far.  I'm bootstrapping
with BOOT_CFLAGS="-O2 -g -fstack-protector-strong" with Ada enabled, for
additional coverage.


Testing passed without new regressions.  Is this okay for trunk?


Ping?  Thanks.


Now that 4.9 is released, I'd like to propose again this fix for inclusion:



--
Florian Weimer / Red Hat Product Security Team

[PATCH PING] Simplify a VEC_SELECT fed by its own inverse

[Bill Schmidt]

Hi,

I'd like to ping this patch: 

http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01319.html

Thanks!

Bill
-- 
Bill Schmidt, Ph.D.
IBM Advance Toolchain for PowerLinux
IBM Linux Technology Center
wschm...@linux.vnet.ibm.com
wschm...@us.ibm.com

Re: Patch ping

[Uros Bizjak]

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

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

Uros.