Re: One more path to fix PR70478

On 11 April 2017 at 21:43, Vladimir Makarov wrote: > > > On 04/11/2017 03:30 AM, Christophe Lyon wrote: >> >> Hi Vladimir, >> >> On 10 April 2017 at 17:05, Vladimir Makarov wrote: >>> >>>This is the second try to fix >>> >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70478 >>> >>>The fi

Re: [PATCH] Fix fold_binary_loc BIT_IOR_EXPR folding (PR sanitizer/80349)

On April 11, 2017 10:54:10 PM GMT+02:00, Jakub Jelinek wrote: >Hi! > >This is another case where we miss needed folding from argN or their >arguments to the expected expression type (type has to be compatible >with opN's type, but argN is after STRIP_NOPS). > >Bootstrapped/regtested on x86_64-linu

libgo patch committed: Fix support for vendor directories

Vendor directories are a concept supported by the go tool (https://golang.org/cmd/go/#hdr-Vendor_Directories). They have never worked properly for gccgo, as has been reported as PR 77857 and https://golang.org/issue/15628. This patch by Lynn Boger fixes vendor support for gccgo by adding appropri

Re: [PATCH], Fix PR 80098, Add better checking for disabling features

Hi! On Tue, Apr 11, 2017 at 05:32:41PM -0400, Michael Meissner wrote: > PR 80098 is an interaction between -mmodulo (ISA 3.0/power9 GPR modulo > instructions) and -mno-vsx where the -mmodulo option enables some of the ISA > 3.0 vector features, even though -mno-vsx was specified. > > To do this,

[wwwdocs,fortran] Update link to CHKSYS

This one has been failing for quite a while, and I found http://flibs.sourceforge.net/chksys.html as a potential replacement link. Thoughts? Gerald Index: readings.html === RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retriev

[libstdc++] Adjust to the new location of the C++ ABI

On Thu, 30 Mar 2017, Gerald Pfeifer wrote: > (Jonathan, I'm going to take care of the libstdc++/doc links as > well in case you wonder.) Done thusly. Jonathan, do you think one of the three references in doc/xml/manual/abi.xml could be avoided? That'll make it easier next time this document mo

Re: [wwwdocs] Adjust to the new location of the C++ ABI

On Thu, 30 Mar 2017, Gerald Pfeifer wrote: > For gcc-4.0/ and faq.html I did adjust the link, for gcc-3.2/ I > figured we can as well avoid it. And here was another one... Applied. Gerald Index: readings.html === RCS file: /cvs/gcc

Re: [wwwdocs,C++] wg21.link's on projects/cxx-status.html

I applied this now. Gerald On Sat, 1 Apr 2017, Gerald Pfeifer wrote: > is there a particular reason you used uppercase for this one > link, unlike the others? > > Not a problem per se, just for the sake of consistency (also to > minimize exception rules I maintain for my link checker ;-). > > A

[wwwdocs] Adjust 2015 ACM Award link

Applied. Gerald Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.1047 diff -u -r1.1047 index.html --- index.html 15 Mar 2017 14:31:25 - 1.1047 +++ index.html 11 Apr 2017 22:10:19 -

Re: [PATCH, rs6000] Fix PR80376 and PR80315

Hi! On Tue, Apr 11, 2017 at 04:27:05PM -0500, Bill Schmidt wrote: > The real secondary problem is that we produce a const0_rtx instead of > a mode-compatible CONST0_RTX, so the assignment of the built-in result to its > target rtx fails with an ICE. I've gone through rs6000.c and fixed the places

[PATCH], Fix PR 80098, Add better checking for disabling features

PR 80098 is an interaction between -mmodulo (ISA 3.0/power9 GPR modulo instructions) and -mno-vsx where the -mmodulo option enables some of the ISA 3.0 vector features, even though -mno-vsx was specified. To do this, I added a table for disabling other vector options when the major vector options

[PATCH, rs6000] Fix PR80376 and PR80315

Hi, The previous patch for PR80376 produced a different sort of ICE, which wasn't a terribly great solution. I looked into Segher's suggestion based on code in x86, but that wasn't appropriate here as the problem happens at a different place. The real secondary problem is that we produce a const

Re: [libcp1] handle anon aggregates linkage-named by typedefs

On Apr 10, 2017, Jeff Law wrote: > On 03/21/2017 05:32 PM, Alexandre Oliva wrote: >> * libcp1plugin.cc (plugin_build_decl): Propagate typedef name to >> anonymous aggregate target type. > Can you put some kind of pointer in the code you copied from cp/decl.c > so that there's some chance anyone c

C++ PATCH for c++/80294, ICE with constexpr and inheritance

Here, when we look at the value of an empty base, we would first make sure that the complete object is constant. But we were in the middle of initializing one of the fields of the complete object, so the corresponding CONSTRUCTOR value was NULL, leading to a crash when trying to determine if it's

[PATCH] Fix fold_binary_loc BIT_IOR_EXPR folding (PR sanitizer/80349)

Hi! This is another case where we miss needed folding from argN or their arguments to the expected expression type (type has to be compatible with opN's type, but argN is after STRIP_NOPS). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2017-04-11 Jakub Jelinek

[PATCH, i386]: Improve STV convert gain function when shifts are involved

2017-04-11 Uros Bizjak * config/i386/i386.c (dimode_scalar_chain::compute_convert_gain): Use shift_const cost parameter when calculating gain of STV shifts. Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}. Committed to mainline SVN. Uros. Index: config/i386/i386.c

Re: One more path to fix PR70478

On 04/11/2017 03:30 AM, Christophe Lyon wrote: Hi Vladimir, On 10 April 2017 at 17:05, Vladimir Makarov wrote: This is the second try to fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70478 The first try patch triggered a latent bug and broke one Fortran testcase on x86-64. The

One more patch for PR70478

A recent patch for PR70478 introduced a regression on ARM. Here is an additional patch to fix it. The patch was successfully tested and bootstrapped on x86-64. Committed as rev. 246854. Index: ChangeLog === --- ChangeLog (revis

[PATCH] handle enumerated types in -Wformat-overflow (PR 80397)

In a review of my fix for bug 80364 Jakub pointed out that to determine whether an argument to an integer directive is of an integer type the gimple-ssa-sprintf pass tests the type code for equality to INTEGER_TYPE when it should instead be using INTEGRAL_TYPE_P(). This has the effect of the pass

Re: [PATCH] Add a new type attribute always_alias (PR79671)

On Tue, Apr 11, 2017 at 9:35 AM, Richard Biener wrote: > On Tue, 11 Apr 2017, Richard Biener wrote: > >> On Tue, 11 Apr 2017, Richard Biener wrote: >> >> > On Mon, 10 Apr 2017, Jason Merrill wrote: >> > >> > > On Mon, Apr 10, 2017 at 11:30 AM, Richard Biener >> > > wrote: >> > > > On Mon, 10 Apr

Re: [C++ PATCH] Fix decomp ICEs in templates (PR c++/80370, take 3)

OK. On Tue, Apr 11, 2017 at 1:13 PM, Jakub Jelinek wrote: > On Tue, Apr 11, 2017 at 03:41:39PM +0200, Jakub Jelinek wrote: >> So like this? Or just type_dependent_expression_p check rather than >> both? > > To answer myself, testing there both type_dependent_expression_p > and value_dependent_ex

[PATCH, GCC, stage4] Fix type for .init_array.* and .fini_array.* sections

Hi, Several tests started failing for ARM targets (eg. gcc.dg/initpri1.c) after change 6f9dbcd42f2cf034a9a21f46842c08d2e88449db in binutils. This is because the non-default priority init_array and fini_array sections are not created with NOTYPE flag as is the case for default priority init_array

Re: One more path to fix PR70478

On 04/11/2017 11:42 AM, Vladimir Makarov wrote: Yes, Christophe. It would be helpful. I've tried to reproduce it but I don't see the difference in the generated code. Never mind. I've reproduced it. Thanks.

[committed] Fix UB in simplify-rtx.c (PR middle-end/80100)

Hi! The following testcase triggers UB in simplify_binary_operation_1, in particular trueop1 is 2 and it is shifted up by 63. Later we want to shift it down (arithmetically) again by 63 and compare against the original value and only optimize if there is match, i.e. if trueop1 can be safely shift

[committed] Don't optimize away OpenMP tasks with empty bodies, but with depend clauses (PR libgomp/80394)

Hi! Tasks that have depend clauses can't be optimized away even if they have empty body, the depend clause still has important side-effects. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk, queued for backporting. 2017-04-11 Jakub Jelinek PR li

[C++ PATCH] Fix decomp ICEs in templates (PR c++/80370, take 3)

On Tue, Apr 11, 2017 at 03:41:39PM +0200, Jakub Jelinek wrote: > So like this? Or just type_dependent_expression_p check rather than > both? To answer myself, testing there both type_dependent_expression_p and value_dependent_expression_p for value_expr breaks the lambda-generic-const2.C testcase

Re: port contrib/download_prerequisites script to macOS

On 04/10/2017 11:59 AM, Damian Rouson wrote: Thanks! I'm asking Jerry to commit it. Damian On April 10, 2017 at 9:48:01 AM, Mike Stump (mikest...@comcast.net ) wrote: On Apr 4, 2017, at 6:10 PM, Damian Rouson wrote: > > The attached patch modifies the contrib/d

Re: [PATCH] avoid using types wider than int for width and precision (PR 80364)

if (TREE_CODE (arg) == SSA_NAME - && TREE_CODE (type) == INTEGER_TYPE) + && TREE_CODE (argtype) == INTEGER_TYPE I think you want && INTEGRAL_TYPE_P (argtype) here instead of that last line, the middle-end considers conversions between integral types useless (exce

Re: One more path to fix PR70478

On Tue, Apr 11, 2017 at 5:26 PM, Christophe Lyon wrote: > On 11 April 2017 at 17:42, Vladimir Makarov wrote: >> >> >> On 04/11/2017 03:30 AM, Christophe Lyon wrote: >>> >>> Hi Vladimir, >>> >>> On 10 April 2017 at 17:05, Vladimir Makarov wrote: This is the second try to fix >>>

Re: One more path to fix PR70478

On 11 April 2017 at 17:42, Vladimir Makarov wrote: > > > On 04/11/2017 03:30 AM, Christophe Lyon wrote: >> >> Hi Vladimir, >> >> On 10 April 2017 at 17:05, Vladimir Makarov wrote: >>> >>>This is the second try to fix >>> >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70478 >>> >>>The fi

Re: [RFC] S/390: Alignment peeling prolog generation

On April 11, 2017 4:57:29 PM GMT+02:00, "Bin.Cheng" wrote: >On Tue, Apr 11, 2017 at 3:38 PM, Robin Dapp >wrote: >> Hi, >> >> when looking at various vectorization examples on s390x I noticed >that >> we still peel vf/2 iterations for alignment even though vectorization >> costs of unaligned load

Re: One more path to fix PR70478

On 04/11/2017 03:30 AM, Christophe Lyon wrote: Hi Vladimir, On 10 April 2017 at 17:05, Vladimir Makarov wrote: This is the second try to fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70478 The first try patch triggered a latent bug and broke one Fortran testcase on x86-64. The

Re: [PATCH 0/3] ARC patches series

* Claudiu Zissulescu [2017-04-04 11:58:58 +0200]: > Hi Andrew, > > Please find a number of small patches which are adding support to for CRT > long calls, and fixes some errors when generating dwarf information and > addresses. > > Please let me know if more info is required, > Claudiu > >

Re: [RFC] S/390: Alignment peeling prolog generation

On Tue, Apr 11, 2017 at 4:03 PM, Robin Dapp wrote: > Hi Bin, > >> Seems Richi added code like below comparing costs between aligned and >> unsigned loads, and only peeling if it's beneficial: >> >> /* In case there are only loads with different unknown misalignments, >> use >> peel

Re: [RFC] S/390: Alignment peeling prolog generation

Hi Bin, > Seems Richi added code like below comparing costs between aligned and > unsigned loads, and only peeling if it's beneficial: > > /* In case there are only loads with different unknown misalignments, > use > peeling only if it may help to align other accesses in the loop

[arm] PR 80389 - if architecture and cpu mismatch, don't print an architecture name as a CPU name

In this PR we incorrectly print the architecture name in a .cpu directive in the assembly file when the -mcpu and -march options conflict (don't target the same base architecture). In this case the .arch overrides the .cpu directive and we should emit a .arch option. Fixed thusly. PR target/8038

Re: [RFC] S/390: Alignment peeling prolog generation

On Tue, Apr 11, 2017 at 3:38 PM, Robin Dapp wrote: > Hi, > > when looking at various vectorization examples on s390x I noticed that > we still peel vf/2 iterations for alignment even though vectorization > costs of unaligned loads and stores are the same as normal loads/stores. > > A simple exampl

Re: [patch, libgfortran] Fix pointer declarations per coding standard

On 04/10/2017 11:05 PM, Janne Blomqvist wrote: > On Tue, Apr 11, 2017 at 7:54 AM, Jerry DeLisle wrote: >> All, >> >> Attached patch is removing the space after * in many pointer declarations and >> references in the files in the io sub-directory. > > Hmm, I always considered having a space both b

Re: [PATCH, GCC/ARM, gcc-5-branch] Fix PR80082: LDRD erronously used for 64bit load on ARMv7-R

On 10/04/17 13:12, Thomas Preudhomme wrote: Hi, Currently GCC is happy to use LDRD to perform a 64bit load on ARMv7-R, as shown by the testcase on this patch. However, LDRD is only atomic when LPAE extensions is available, which they are not for ARMv7-R. This commit solve the issue by introducin

[RFC] S/390: Alignment peeling prolog generation

Hi, when looking at various vectorization examples on s390x I noticed that we still peel vf/2 iterations for alignment even though vectorization costs of unaligned loads and stores are the same as normal loads/stores. A simple example is void foo(int *restrict a, int *restrict b, unsigned int n)

Re: [PATCH] Add function part to a same comdat group (PR ipa/80212).

> Hello. > > This is my second attempt to fix the PR I worked on with Honza and Martin > Jambor. > > Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. > Apart from that > octoploid confirmed it can survive LLVM build. And I can build Firefox and > boost with the > patc

Re: [PATCH v5] S/390: Optimize atomic_compare_exchange and atomic_compare builtins.

On Mon, Mar 27, 2017 at 09:27:35PM +0100, Dominik Vogt wrote: > The attached patch optimizes the atomic_exchange and > atomic_compare patterns on s390 and s390x (mostly limited to > SImode and DImode). Among general optimizaation, the changes fix > most of the problems reported in PR 80080: > http

Re: [PATCH] Add function part to a same comdat group (PR ipa/80212).

Hello. This is my second attempt to fix the PR I worked on with Honza and Martin Jambor. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. Apart from that octoploid confirmed it can survive LLVM build. And I can build Firefox and boost with the patch on x86_64-linux-gn

[C++ PATCH] Fix decomp ICEs in templates (PR c++/80370, take 2)

Hi! On Mon, Apr 10, 2017 at 04:48:43PM -0400, Jason Merrill wrote: > On Mon, Apr 10, 2017 at 4:35 PM, Jakub Jelinek wrote: > > - store_decomp_type (v[i], eltype); > > + if (!processing_template_decl) > > + store_decomp_type (v[i], eltype); > > This spot shouldn't change

Re: [PATCH] Add a new type attribute always_alias (PR79671)

On Tue, 11 Apr 2017, Richard Biener wrote: > On Tue, 11 Apr 2017, Richard Biener wrote: > > > On Mon, 10 Apr 2017, Jason Merrill wrote: > > > > > On Mon, Apr 10, 2017 at 11:30 AM, Richard Biener > > > wrote: > > > > On Mon, 10 Apr 2017, Jason Merrill wrote: > > > >> On Mon, Apr 10, 2017 at 8:5

Re: [PATCH] Do not instrument register variables in object-size sanitizer (PR sanitizer/80387).

On 04/11/2017 02:52 PM, Jakub Jelinek wrote: > On Tue, Apr 11, 2017 at 02:33:52PM +0200, Martin Liška wrote: >> --- /dev/null >> +++ b/gcc/testsuite/gcc.dg/ubsan/pr70878.c >> @@ -0,0 +1,9 @@ >> +/* PR sanitizer/80878 */ >> +/* { dg-do compile { target { x86_64-*-* } } } */ > > The target looks wro

Re: [PATCH] Do not instrument register variables in object-size sanitizer (PR sanitizer/80387).

On Tue, Apr 11, 2017 at 02:33:52PM +0200, Martin Liška wrote: > --- /dev/null > +++ b/gcc/testsuite/gcc.dg/ubsan/pr70878.c > @@ -0,0 +1,9 @@ > +/* PR sanitizer/80878 */ > +/* { dg-do compile { target { x86_64-*-* } } } */ The target looks wrong. In any case, it should be i?86-*-* x86_64-*-*, e.g.

[PATCH] Do not instrument register variables in object-size sanitizer (PR sanitizer/80387).

Hello. Even though the original test-case is slp target-specific, one can easily come up with a test-case which fails on arbitrary target. Problem is a register variable that is used wrongly in a function call that expects an address to be given. Fixed by not instrumenting such declarations. P

Re: [PATCH] Add a new type attribute always_alias (PR79671)

On Tue, 11 Apr 2017, Richard Biener wrote: > On Mon, 10 Apr 2017, Jason Merrill wrote: > > > On Mon, Apr 10, 2017 at 11:30 AM, Richard Biener wrote: > > > On Mon, 10 Apr 2017, Jason Merrill wrote: > > >> On Mon, Apr 10, 2017 at 8:50 AM, Richard Biener > > >> wrote: > > >> > * tree.c (b

Re: [PATCH] Fix simplify-rtx.c ICE with vector float (not (neg)) (PR rtl-optimization/80385)

On Tue, 11 Apr 2017, Jakub Jelinek wrote: > Hi! > > The x86 intrinsics allow andnot on MODE_VECTOR_FLOAT modes, but > such modes have NULL CONSTM1_RTX and are not appropriate for the > transformation anyway. > > The following patch fixes that, ok if bootstrap/regtest passes? > Or would you prefe

[PATCH 2/3] Use BUILD_PATH_PREFIX_MAP envvar to transform __FILE__

Use the BUILD_PATH_PREFIX_MAP environment variable when expanding the __FILE__ macro, in the same way that debug-prefix-map works for debugging symbol paths. This patch follows similar lines to the earlier patch for SOURCE_DATE_EPOCH. Specifically, we read the environment variable not in libcpp bu

[PATCH v2] Generate reproducible output independently of the build-path

(Please keep me on CC, I am not subscribed) Background == Previous background is here: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00182.html Upon further discussion, we decided to add support for multiple mappings and to rename the environment variable to BUILD_PATH_PREFIX_MAP. We ha

[PATCH 1/3] Use BUILD_PATH_PREFIX_MAP envvar for debug-prefix-map

Define the BUILD_PATH_PREFIX_MAP environment variable, and treat it as implicit -fdebug-prefix-map CLI options specified before any explicit such options. Much of the generic code for applying and parsing prefix-maps is implemented in libiberty instead of the dwarf2 parts of the code, in order to

[PATCH 3/3] When remapping paths, only match whole path components

Change the remapping algorithm so that each old_prefix only matches paths that have old_prefix as a whole path component prefix. (A whole path component is a part of a path that begins and ends at a directory separator or at either end of the path string.) This remapping algorithm is more predict

[PATCH] Fix simplify-rtx.c ICE with vector float (not (neg)) (PR rtl-optimization/80385)

Hi! The x86 intrinsics allow andnot on MODE_VECTOR_FLOAT modes, but such modes have NULL CONSTM1_RTX and are not appropriate for the transformation anyway. The following patch fixes that, ok if bootstrap/regtest passes? Or would you prefer to replace the && CONSTM1_RTX (mode) check with e.g. && (

Re: [PATCH] Add a new type attribute always_alias (PR79671)

On Tue, 11 Apr 2017, Florian Weimer wrote: > On 04/06/2017 09:12 PM, Richard Biener wrote: > > > Right. The kernel also has many APIs which return multiple > > > variable-length data blocks, such as getdents64, and many more > > > interfaces in combination with read/recv system calls. Variable l

Re: [PATCH] Add a new type attribute always_alias (PR79671)

On 04/06/2017 09:12 PM, Richard Biener wrote: Right. The kernel also has many APIs which return multiple variable-length data blocks, such as getdents64, and many more interfaces in combination with read/recv system calls. Variable length means that you cannot declare the appropriate type afte

Re: [PATCH] Add a new type attribute always_alias (PR79671)

On Mon, 10 Apr 2017, Jason Merrill wrote: > On Mon, Apr 10, 2017 at 11:30 AM, Richard Biener wrote: > > On Mon, 10 Apr 2017, Jason Merrill wrote: > >> On Mon, Apr 10, 2017 at 8:50 AM, Richard Biener wrote: > >> > * tree.c (build_cplus_array_type): Set TYPE_TYPELESS_STORAGE > >> >

Re: [PATCH] avoid using types wider than int for width and precision (PR 80364)

On Mon, Apr 10, 2017 at 04:16:42PM -0600, Martin Sebor wrote: > gcc/ChangeLog: > > PR middle-end/80364 > * gimple-ssa-sprintf.c (get_int_range): Remove second argument and > always use the int type. > (directive::set_width, directive::set_precision, format_character): >

Re: [PATCH] S/390: Optimize atomic_compare_exchange and atomic_compare builtins.

On 04/10/2017 11:37 PM, Ulrich Weigand wrote: > Dominik Vogt wrote: > >> So, we could add a special case for const0_rtx that generates the >> LT pattern and does not rely on Combine, and get rid of the >> peephole. I'm not sure this is worthwhile thoug, because the >> peephole has other beneficia

Re: [PATCH] Add a new type attribute always_alias (PR79671)

On Mon, 10 Apr 2017, Pedro Alves wrote: > On 04/10/2017 01:50 PM, Richard Biener wrote: > > > +void *operator new(__SIZE_TYPE__, void *p2) { return p2; } > > +struct B { B(int i_) : i(i_) {} int i; }; > > +struct X > > +{ > > + unsigned char buf[sizeof (B)]; > > +}; > > Pedantically, shouldn't

Re: [P1] [PATCH] [PR tree-optimization/80374] Do not try to convert integer_zero_node to undesirable types

On Mon, Apr 10, 2017 at 9:20 PM, Jeff Law wrote: > > fold_convert can fail for certain types. It can fail either by returning a > error_mark_node or triggering a gcc_assert depending on the exact situation. > > Both are problematical. This patch checks that we can convert > integer_zero_node to

Re: One more path to fix PR70478

Hi Vladimir, On 10 April 2017 at 17:05, Vladimir Makarov wrote: > This is the second try to fix > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70478 > > The first try patch triggered a latent bug and broke one Fortran testcase > on x86-64. > > The patch was successfully bootstrapped on x8

Re: [PATCH] Partially revert undesirable widest literal type changes from 1999 (PR middle-end/79788, PR middle-end/80375)

On Mon, Apr 10, 2017 at 10:42 PM, Jakub Jelinek wrote: > Hi! > > The http://gcc.gnu.org/ml/gcc-patches/1999-07/msg00031.html change > appears to be IMHO highly undesirable loophole around the lack of > TImode support on 32-bit targets. Those targets return > false from targetm.scalar_mode_support

Re: [C++ PATCH] Fix ICE when dumping VEC_COND_EXPR (PR c++/80363)

On Mon, Apr 10, 2017 at 10:34 PM, Jakub Jelinek wrote: > Hi! > > The following testcase emits vec_cond_expr not supported by dump_expr > inside of error message. > > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, > ok for trunk? Ok. Richard. > 2017-04-10 Jakub Jelinek >