Re: [PATCH v4 1/3] IFN: Implement IFN_VEC_SET for ARRAY_REF with VIEW_CONVERT_EXPR

2020-09-26 Thread xionghu luo via Gcc-patches
On 2020/9/25 21:28, Richard Sandiford wrote: > xionghu luo writes: >> @@ -2658,6 +2659,45 @@ expand_vect_cond_mask_optab_fn (internal_fn, gcall >> *stmt, convert_optab optab) >> >> #define expand_vec_cond_mask_optab_fn expand_vect_cond_mask_optab_fn >> >> +/* Expand VEC_SET internal

[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled

2020-09-26 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789 --- Comment #23 from Hongtao.liu --- > _813 = {_437, _448, _459, _470, _490, _501, _512, _523, _543, _554, _565, > _576, _125, _143, _161, _179}; The cost of vec_construct in i386 backend is 64, calculated as 16 x 4 cut from i386.c --- /* N

[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled

2020-09-26 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789 --- Comment #22 from Hongtao.liu --- >One of my workmates found that if we disable vectorization for SPEC2017 >>525.x264_r function sub4x4_dct in source file x264_src/common/dct.c with >?>explicit function attribute

[Bug c/97215] Possible fread() malfunction of GCC 7.3.0 (Windows)

2020-09-26 Thread sanmayce at sanmayce dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215 --- Comment #5 from Georgi --- (In reply to Andrew Pinski from comment #3) > fopen/fread/fwrite DOES NOT come from GCC, but rather than in this case > mingw. Ugh, thanks, will alert them about this issue by giving the link to this tracker.

[Bug c/97215] Possible fread() malfunction of GCC 7.3.0 (Windows)

2020-09-26 Thread sanmayce at sanmayce dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215 --- Comment #4 from Georgi --- (In reply to Andrew Pinski from comment #2) > You need b if you don't want \r\n to be turned into just \n. At 11,945th line I use: ``` if ((fp = fopen(argv[1], "rb")) == NULL) {

Re: [PATCH v7] genemit.c (main): split insn-emit.c for compiling parallelly

2020-09-26 Thread Jojo R
Hi, Has this patch been merged ? Jojo 在 2020年9月15日 +0800 PM5:16,Jojo R ,写道: > gcc/ChangeLog: > > * genemit.c (main): Print 'split line'. > * Makefile.in (insn-emit.c): Define split count and file > > --- > gcc/Makefile.in | 19 + > gcc/genemit.c | 104

Re: Wrong optimization from ‘fwprop’ pass

2020-09-26 Thread Jojo R
Hi, Got it, Thanks :) Jojo 在 2020年9月27日 +0800 AM3:22,Segher Boessenkool ,写道: > Hi! > > On Wed, Sep 23, 2020 at 10:50:52AM +0800, Jojo R wrote: > > insn seqs: > > > > s1: > > > > __builtin_set_float_convert_mode(0); > > r1 = __builtin_load(a1, a2); > > r2 = __builtin_float_convert(r1); >

[Bug c/97215] Possible fread() malfunction of GCC 7.3.0 (Windows)

2020-09-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215 --- Comment #3 from Andrew Pinski --- fopen/fread/fwrite DOES NOT come from GCC, but rather than in this case mingw.

[Bug c/97215] Possible fread() malfunction of GCC 7.3.0 (Windows)

2020-09-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED

[Bug c/97215] Possible fread() malfunction of GCC 7.3.0 (Windows)

2020-09-26 Thread sanmayce at sanmayce dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215 --- Comment #1 from Georgi --- Oops, here are the mentioned files: www.sanmayce.com/Nakamichi/Satanichi_aka_Nakamichi_2020-Jun-09_BUG_ZEROED-END.zip

[Bug c/97215] New: Possible fread() malfunction of GCC 7.3.0 (Windows)

2020-09-26 Thread sanmayce at sanmayce dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215 Bug ID: 97215 Summary: Possible fread() malfunction of GCC 7.3.0 (Windows) Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3

The dust seems to have settled from the repository conversion

2020-09-26 Thread Eric S. Raymond
The dust seems to have settled from the GCC repository conversion. I haven't seen any complaints about the conversion since it was finalized in January, so I'm gathering there have not been any significant problems with it. Unfortunately, it left *me* with a problem. If you're on this list,

gcc-10-20200926 is now available

2020-09-26 Thread GCC Administrator via Gcc
Snapshot gcc-10-20200926 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20200926/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch

[Bug c/97208] [gcc 10.2.0] Microblaze regression

2020-09-26 Thread romain.naour at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97208 --- Comment #1 from Romain Naour --- Hello, I had to disable -ftree-loop-distribute-patterns while building the kernel on microblaze (using -Os). The regression appear since the commit [1] that moved -ftree-loop-distribute-patterns from -O3

[Bug fortran/97210] Intrinsic function get_team() does not work

2020-09-26 Thread kargl at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97210 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC|

Re: Fix handling of gimple_clobber in ipa_modref

2020-09-26 Thread Jan Hubicka
> On September 26, 2020 12:04:24 AM GMT+02:00, Jan Hubicka > wrote: > >Hi, > >while adding check for gimple_clobber I reversed the return value > >so instead of ignoring the statement ipa-modref gives up. Fixed thus. > >This explains the drop between originally reported disambinguations >

[committed] libstdc++: Use __libc_single_threaded to optimise atomics [PR 96817]

2020-09-26 Thread Jonathan Wakely via Gcc-patches
Glibc 2.32 adds a global variable that says whether the process is single-threaded. We can use this to decide whether to elide atomic operations, as a more precise and reliable indicator than __gthread_active_p. This means that guard variables for statics and reference counting in shared_ptr can

[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread

2020-09-26 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817 --- Comment #17 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e6923541fae5081b646f240d54de2a32e17a0382 commit r11-3484-ge6923541fae5081b646f240d54de2a32e17a0382 Author: Jonathan Wakely

Re: Wrong optimization from ‘fwprop’ pass

2020-09-26 Thread Segher Boessenkool
Hi! On Wed, Sep 23, 2020 at 10:50:52AM +0800, Jojo R wrote: > insn seqs: > > s1: > > __builtin_set_float_convert_mode(0); > r1 = __builtin_load(a1, a2); > r2 = __builtin_float_convert(r1); > __builtin_store(a3, r2); > __builtin_set_float_convert_mode(0); > > s2: >

[Bug middle-end/94195] missing warning reading a smaller object via an lvalue of a larger type

2020-09-26 Thread dimhen at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94195 Dmitry G. Dyachenko changed: What|Removed |Added CC||dimhen at gmail dot com ---

[Patch][nvptx] return true in libc_has_function for function_sincos

2020-09-26 Thread Tobias Burnus
Found when looking at PR97203 (but having no effect there). The GCC ME optimizes with -O1 (or higher) the a = sinf(x) b = cosf(x) to __builtin_cexpi(x, , ) (...i as in internal; like cexp(z) but with with __real__ z == 0) In expand_builtin_cexpi, that is handles as: if (optab_handler

[Bug target/97044] Undefined format macros because of include order on AIX

2020-09-26 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97044 --- Comment #5 from CVS Commits --- The master branch has been updated by David Edelsohn : https://gcc.gnu.org/g:081b3517b4df826ac917147eb906bbb8fc6528b1 commit r11-3482-g081b3517b4df826ac917147eb906bbb8fc6528b1 Author: David Edelsohn Date:

[Bug c++/97214] New: ICE in lookup_template_class_1, at cp/pt.c:9896

2020-09-26 Thread sfranzen85 at hotmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97214 Bug ID: 97214 Summary: ICE in lookup_template_class_1, at cp/pt.c:9896 Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[PATCH] AIX: collect2 visibility

2020-09-26 Thread David Edelsohn via Gcc-patches
The code that collect2 generates, compiles and links into applications and shared libraries to initialize constructors and register DWARF tables is built with the compiler options used to invoke the linker. If the compiler options change the visibility from default, the library initialization

[Bug libgomp/97213] OpenMP "if" is dramatically slower than code-level "if" - why?

2020-09-26 Thread ttsiodras at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97213 Thanassis Tsiodras changed: What|Removed |Added Resolution|--- |FIXED

[Bug libgomp/97213] OpenMP "if" is dramatically slower than code-level "if" - why?

2020-09-26 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97213 --- Comment #3 from Jakub Jelinek --- Note, I think significant speedup is in tail recursion optimization which will be prevented even with mergeable task. Computing fibonacci this way is not efficient.

[Bug libgomp/97213] OpenMP "if" is dramatically slower than code-level "if" - why?

2020-09-26 Thread ttsiodras at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97213 --- Comment #2 from Thanassis Tsiodras --- I see. I was not aware of "mergeable", TBH - thanks for pointing it out (it led me to reading about "data environments"). Thanks, Jakub.

[Bug libgomp/97213] OpenMP "if" is dramatically slower than code-level "if" - why?

2020-09-26 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97213 --- Comment #1 from Jakub Jelinek --- Even with if(false) the implementation has to create a new data environment etc. if(false) just means the task will be included, i.e. the generating task will only continue when the included task finishes

[Bug libgomp/97213] New: OpenMP "if" is dramatically slower than code-level "if" - why?

2020-09-26 Thread ttsiodras at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97213 Bug ID: 97213 Summary: OpenMP "if" is dramatically slower than code-level "if" - why? Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal

Re: dg-options after board/cflags

2020-09-26 Thread Maciej W. Rozycki
On Wed, 2 Sep 2020, Jose E. Marchesi via Gcc-patches wrote: > Your patch dealt with board/multilib_flags, but the same problem exists > for board/cflags and many other flag-containing options. What's the use case for that? IIUC board flags are supposed to be ones that are absolutely required

Re: [PATCH] optabs: Don't reuse target for multi-word expansions if it overlaps operand(s) [PR97073]

2020-09-26 Thread Eric Botcazou
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and > release branches? > > 2020-09-18 Jakub Jelinek > > PR middle-end/97073 > * optabs.c (expand_binop, expand_absneg_bit, expand_unop, > expand_copysign_bit): Check reg_overlap_mentioned_p between target

[Bug fortran/96495] [gfortran] Composition of user-defined operators does not copy ALLOCATABLE property of derived type

2020-09-26 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96495 --- Comment #6 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:5b26b3b3f5c75a86a5a3e851866247ac7fcb6c8b commit r11-3480-g5b26b3b3f5c75a86a5a3e851866247ac7fcb6c8b Author: Paul Thomas Date: Sat

[Bug libgomp/97212] New: [OpenMP] 'depend' clause with 'target nowait' (!) + 'task' does not work

2020-09-26 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97212 Bug ID: 97212 Summary: [OpenMP] 'depend' clause with 'target nowait' (!) + 'task' does not work Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords:

Re: Fix handling of gimple_clobber in ipa_modref

2020-09-26 Thread Jan Hubicka
> On September 26, 2020 12:04:24 AM GMT+02:00, Jan Hubicka > wrote: > >Hi, > >while adding check for gimple_clobber I reversed the return value > >so instead of ignoring the statement ipa-modref gives up. Fixed thus. > >This explains the drop between originally reported disambinguations >

Re: Implement iterative dataflow in modref to track parameters

2020-09-26 Thread Richard Biener
On September 26, 2020 10:20:20 AM GMT+02:00, Jan Hubicka wrote: >Hi, >this patchs finishes the parameter tracking by implementing the >iterative >dataflow in propagation stage. This is necessary since we now can >propagate how the pointers are passed around recursive calls (as done >in >a

Implement iterative dataflow in modref to track parameters

2020-09-26 Thread Jan Hubicka
Hi, this patchs finishes the parameter tracking by implementing the iterative dataflow in propagation stage. This is necessary since we now can propagate how the pointers are passed around recursive calls (as done in a testcase) and thus it is no-longer safe to simply merge all summaries in one

[committed] openmp: Improve #pragma omp simd vectorization

2020-09-26 Thread Jakub Jelinek via Gcc-patches
Hi! As mentioned earlier, the vectorizer punts on vectorization of loops with non-constant steps. As for OpenMP loops it is by the language restriction always possible to compute the number of loop iterations before the loop, this change helps those cases by computing it and using an alternate

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

2020-09-26 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97163 --- Comment #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d00b1b023ecfc3ddc3fe952c0063dab7529d5f7a commit r11-3476-gd00b1b023ecfc3ddc3fe952c0063dab7529d5f7a Author: Jakub Jelinek Date:

Re: Fix handling of gimple_clobber in ipa_modref

2020-09-26 Thread Jan Hubicka
> On September 26, 2020 12:04:24 AM GMT+02:00, Jan Hubicka > wrote: > >Hi, > >while adding check for gimple_clobber I reversed the return value > >so instead of ignoring the statement ipa-modref gives up. Fixed thus. > >This explains the drop between originally reported disambinguations >

Re: Add support for iterative dataflow to ipa-modref-tree.h

2020-09-26 Thread Jan Hubicka
Hi, this is variant i comitted. Some further testing has shown a problem in merge operation returing true even if summary was cleanuped to its original form. This resulted in infinite loop building firefox. Second problem was that for recurisve functions we need to merge summary to itself and