Re: git conversion in progress

2020-01-11 Thread Jakub Jelinek
On Sat, Jan 11, 2020 at 02:51:21PM +, Richard Earnshaw wrote: > https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/vendors/redhat/heads/gcc-9-branch > > Works > > Or for tags s/heads/tags/ Indeed, this works, but if one doesn't know what branches there are for particular vendor or what ven

Re: git conversion in progress

2020-01-11 Thread Jakub Jelinek
On Sat, Jan 11, 2020 at 02:39:43PM +, Joseph Myers wrote: > > On 11/01/2020 01:18, Joseph Myers wrote: > > > The GCC SVN repository is now read-only for the move to git, as is the > > > old > > > git-svn mirror; the cron job updating that mirror has been disabled, as > > > have gccadmin's cr

Re: GIT: Monotonically increasing trunk and release branch ids

2020-01-11 Thread Jakub Jelinek
On Sat, Jan 11, 2020 at 09:15:11AM -0500, Jason Merrill wrote: > > On Fri, Jan 10, 2020 at 10:47:47PM +0100, Jakub Jelinek wrote: > > > Ah, you suggested g: rather than just g. > > > We could then support > > > rN (1-6 decimal digits) - the svn revs, either

Re: GIT: Monotonically increasing trunk and release branch ids

2020-01-11 Thread Jakub Jelinek
On Sat, Jan 11, 2020 at 07:43:17AM -0600, Segher Boessenkool wrote: > On Fri, Jan 10, 2020 at 07:50:02PM +0100, Jakub Jelinek wrote: > > Maybe even add https://gcc.gnu.org/gNNN for 7-40 hexadecimal digits > > redirect to https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=NNN &g

Re: GIT: Monotonically increasing trunk and release branch ids

2020-01-11 Thread Jakub Jelinek
On Fri, Jan 10, 2020 at 10:47:47PM +0100, Jakub Jelinek wrote: > Ah, you suggested g: rather than just g. > We could then support > rN (1-6 decimal digits) - the svn revs, either for old repo, or > transformed > g:X (X is any [0-9a-zA-Z_-], something else?, 1 or more

Re: GIT: Monotonically increasing trunk and release branch ids

2020-01-11 Thread Jakub Jelinek
On Fri, Jan 10, 2020 at 07:50:02PM +0100, Jakub Jelinek wrote: > The changes I was asking for is, for gcc master and releases/gcc-* branch > commits to have the monotonically increasing short ids (printed by git descr > with the git aliases I've posted) both somewhere early &g

Re: GIT: Monotonically increasing trunk and release branch ids

2020-01-10 Thread Jakub Jelinek
On Fri, Jan 10, 2020 at 02:15:30PM -0500, Jason Merrill wrote: > Yep, this is a lot like I was suggesting at > >https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01015.html > > except I didn't think it was necessary to trim the trailing SHA. I > also suggested creating a tag for the beginning of

Re: GIT: Monotonically increasing trunk and release branch ids

2020-01-10 Thread Jakub Jelinek
On Fri, Jan 10, 2020 at 10:09:08PM +0400, Joel Brobecker wrote: > > > As it is short, could it be something we'd put as first thing in the > > > gcc-cvs > > > mail subjects (of course, only for trunk and release branch commits; like > > > the current svn mails start with rNN - ), and somewhere

Re: GIT: Monotonically increasing trunk and release branch ids

2020-01-10 Thread Jakub Jelinek
On Fri, Jan 10, 2020 at 05:47:16PM +, Joseph Myers wrote: > > Ok, so what about basepoints instead? > > That seems a better name to me. Ok. > > > I think the existing git hook configuration expects you to push only > > > annotated tags, not lightweight tags (so you'd need to use -a / -s / -

Re: GIT: Monotonically increasing trunk and release branch ids

2020-01-10 Thread Jakub Jelinek
On Fri, Jan 10, 2020 at 05:05:04PM +, Joseph Myers wrote: > On Fri, 10 Jan 2020, Jakub Jelinek wrote: > > > We would need to add some tags (I wouldn't bother with pre-GCC 5 era, > > because that doesn't have single number version numbers in the branch > > nam

GIT: Monotonically increasing trunk and release branch ids

2020-01-10 Thread Jakub Jelinek
Hi! As I said earlier, one thing I find useful in svn compared to git are the monotonically increasing revision numbers that we at Red Hat e.g. use in our gcc bisect seed but I find it useful even in bugzilla everyday use. With the help of various folks on IRC, I have something that seems to work

Re: Git conversion: fixing email addresses from ChangeLog files

2019-12-28 Thread Jakub Jelinek
On Fri, Dec 27, 2019 at 07:47:02PM +, Richard Earnshaw (lists) wrote: > Email addresses from the ChangeLog files are not validated during > commits, so a number of typos exist in the extracted data. I've > extracted the 'Author:' entry from a prototype conversion and then piped > that through

Re: Proposal for the transition timetable for the move to GIT

2019-12-26 Thread Jakub Jelinek
On Thu, Dec 26, 2019 at 04:58:22PM +, Joseph Myers wrote: > If we don't want merge commits on git master for the cases where people > put merge properties on trunk in the past, we can use a reposurgeon > "unmerge" command in gcc.lift to stop the few commits in question from > being merge com

Re: Proposal for the transition timetable for the move to GIT

2019-12-26 Thread Jakub Jelinek
On Thu, Dec 26, 2019 at 11:04:29AM +, Joseph Myers wrote: Is there some easy way (e.g. file in the conversion scripts) to correct spelling and other mistakes in the commit authors? E.g. there are misspelled surnames, etc. (e.g. looking at my name, I see Jakub Jakub Jelinek (1): Jakub Jeilnek

Re: Need sanity check on DSE vs expander issue

2019-12-20 Thread Jakub Jelinek
On Fri, Dec 20, 2019 at 08:09:26AM +0100, Richard Biener wrote: > >That (of course) only writes 80 bits of data because of XFmode, leaving > >48 bits uninitialized. We then read those bits, or-ing the > >uninitialized data into ored_words and all hell breaks loose later. > > > >Am I losing my mind

Re: Commit messages and the move to git

2019-12-19 Thread Jakub Jelinek
On Thu, Dec 19, 2019 at 12:01:28AM +, Joseph Myers wrote: > re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: > tree-optimization SVN r277822]) > re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: > tree-optimization SVN r277955]) > re PR

[PATCH] Re: Minimal GCC version to compile the trunk

2019-12-07 Thread Jakub Jelinek
f lines), so something like this? I've tested the workaround back to GCC r8. Note, not accepting the code as is clearly has been a regression in GCC 3.4 to 4.4, as GCC 3.2 or 3.3 happily accept that. Ok for trunk if it passes bootstrap/regtest? 2019-12-07 Jakub Jelinek * cvt.c

Re: PPC64 libmvec implementation of sincos

2019-12-06 Thread Jakub Jelinek
On Fri, Dec 06, 2019 at 11:48:03AM +0100, Richard Biener wrote: > So I used > > void sincos(double x, double *sin, double *cos); > _Complex double __attribute__((__simd__("notinbranch"))) > __builtin_cexpi (double); While Intel-ABI-Vector-Function-2015-v0.9.8.pdf talks about complex numbers, the

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

2019-12-05 Thread Jakub Jelinek
On Thu, Dec 05, 2019 at 04:46:45PM +0100, Thomas Schwinge wrote: > Hi! > > ;-P Jakub, thanks for furnishing me a fit occasion here: > > On 2019-12-05T16:15:15+0100, Jakub Jelinek wrote: > > [...] much more indented though, but you could > > use a temporary, like:

Re: libsanitizer in GCC 10 is dropping symbols without bumping the soversions

2019-11-29 Thread Jakub Jelinek
On Fri, Nov 29, 2019 at 12:28:51PM +0100, Matthias Klose wrote: > libsanitizer on trunk only bumps the soversion for asan, but the other > libraries > drop some symbols without bumping the soname, Are these changes intended, and > should the soversions be bumped? libsanitizer libs have upstream t

Re: GCC selftest improvements

2019-11-22 Thread Jakub Jelinek
On Fri, Nov 22, 2019 at 04:01:43PM -0600, Segher Boessenkool wrote: > On Fri, Nov 22, 2019 at 09:02:05PM +, Andrew Dean wrote: > > > > Many systems do not have a system compiler newer than this *four years > > > > old* one. GCC 4.8 is the first GCC version that supports all of > > > > C++11, w

Re: GCC selftest improvements

2019-10-28 Thread Jakub Jelinek
On Mon, Oct 28, 2019 at 03:41:13PM -0600, Jeff Law wrote: > On 10/28/19 2:27 PM, Segher Boessenkool wrote: > > On Mon, Oct 28, 2019 at 01:40:03PM -0600, Jeff Law wrote: > >> On 10/25/19 6:01 PM, Gabriel Dos Reis wrote: > >>> Jason, Jonathan - is the situation on the terrain really that dire that >

Re: general_operand not validating "(const_int 65535 [0xffff])"

2019-10-16 Thread Jakub Jelinek
On Wed, Oct 16, 2019 at 05:51:11PM +0100, Jozef Lawrynowicz wrote: > We call expand_expr_real_2 from expand_mul_overflow (internal-fn.c:1604). > When we process the arguments to: > __builtin_umul_overflow ((unsigned int) (-1), y, &r); > at expr.c:8952, they go through a few transformations. > >

Re: general_operand not validating "(const_int 65535 [0xffff])"

2019-10-09 Thread Jakub Jelinek
On Wed, Oct 09, 2019 at 02:40:42PM +0100, Jozef Lawrynowicz wrote: > I've added a new define_expand for msp430 to handle "mulhisi", but when > testing > the changes, some builtin tests (e.g. builtin-arith-overflow-{1,5,p-1}.c) > fail. > > I've narrowed a test case down to: > > void > foo (unsig

Re: [PATCH] Update comment of removed options.

2019-09-09 Thread Jakub Jelinek
On Mon, Sep 09, 2019 at 01:24:53PM +0200, Martin Liška wrote: > You are right. What about the suggested patch? Can you please quickly (say with svn blame) double check whether the descriptions weren't actually right but misleading (an option could be deprecated in N and removed in N+1 or so, so se

Re: [PATCH] Deprecate -frepo option.

2019-09-09 Thread Jakub Jelinek
On Mon, Sep 09, 2019 at 01:02:32PM +0200, Martin Liška wrote: > On 9/6/19 4:56 PM, Jakub Jelinek wrote: > > On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote: > >> On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote: > >>> Ok, hopefully nobody

Re: [PATCH] Deprecate -frepo option.

2019-09-06 Thread Jakub Jelinek
On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote: > On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote: > > Ok, hopefully nobody is strongly against. I've just retested the > > patch and installed it as r275450. > > --- a/gcc/c-family/c.opt > +++ b/gcc/c-family/c.opt > @@ -1

Re: Deprecate -traditional-cpp?

2019-09-05 Thread Jakub Jelinek
On Thu, Sep 05, 2019 at 02:33:35PM +0200, Andreas Schwab wrote: > On Sep 05 2019, Nathan Sidwell wrote: > > > Is it time to deprecate traditional preprocessing? It's been 30 years > > since C89. Are (non-compiler) tools that use it still things? > > It's probably still used together with -xas

GCC 9.3 Status Report (2019-08-12)

2019-08-12 Thread Jakub Jelinek
Status == GCC 9.2 has been released and the branch is again open for regression and documentation fixes. History makes us expect a GCC 9.3 release at the end of this or the beginning of next year. Quality Data Priority # Change from last report ---

GCC 9.2 Released

2019-08-12 Thread Jakub Jelinek
The GNU Compiler Collection version 9.2 has been released. GCC 9.2 is a bug-fix release from the GCC 9 branch containing important fixes for regressions and serious bugs in GCC 9.1 with more than 68 bugs fixed since the previous release. This release is available from the FTP servers listed at:

Re: Using gcc/ChangeLog instead of gcc/testsuite/ChangeLog?

2019-08-10 Thread Jakub Jelinek
nglish./ -* objc-next-runtime-abi-02.c (objc_next_runtime_abi_02_init): Spell -out "greater" in English. + * objc-act.c (objc_begin_catch_clause): Quote keywords and options + in diagnostics. + (objc_build_throw_stmt): Same. + (objc_finish_message_expr)

Re: Use predicates for RTL objects

2019-08-08 Thread Jakub Jelinek
On Thu, Aug 08, 2019 at 02:35:27PM -0400, Arvind Sankar wrote: > Surely there's general agreement on using REG_P etc? I don't see anyone No objections from me for using REG_P and other *_P macros more. > objecting to it, and that's all the patchset does: to avoid any > confusion the second half o

Re: Use predicates for RTL objects

2019-08-08 Thread Jakub Jelinek
On Thu, Aug 08, 2019 at 01:12:33PM -0400, Arvind Sankar wrote: > On Thu, Aug 08, 2019 at 03:04:53PM +, Michael Matz wrote: > > Hi, > > > > On Wed, 7 Aug 2019, Arvind Sankar wrote: > > > > > => x->is_a (REG) > > > > Oh god, please no. Currently at least the RTL parts of GCC still have > >

Re: GCC 9.2 Status Report (2019-08-05), branch frozen for release

2019-08-08 Thread Jakub Jelinek
On Thu, Aug 08, 2019 at 10:49:41AM -0400, Tom Honermann wrote: > > Status > > == > > > > The first 9.2 release candidate has been released. > > The GCC 9 branch is frozen for preparation of the GCC 9.2 release. > > All changes to the branch now require release manager approval. > > Hi, Jakub.

Re: GCC 9.2 Status Report (2019-08-05), branch frozen for release

2019-08-06 Thread Jakub Jelinek
On Mon, Aug 05, 2019 at 11:03:02AM -0600, Martin Sebor wrote: > On 8/5/19 7:21 AM, Jakub Jelinek wrote: > > Status > > == > > > > The first 9.2 release candidate has been released. > > The GCC 9 branch is frozen for preparation of the GCC 9.2 release. > >

GCC 9.2 Status Report (2019-08-05), branch frozen for release

2019-08-05 Thread Jakub Jelinek
Status == The first 9.2 release candidate has been released. The GCC 9 branch is frozen for preparation of the GCC 9.2 release. All changes to the branch now require release manager approval. Quality Data Priority # Change from last report --- -

GCC 9.2 Release Candidate available from gcc.gnu.org

2019-08-05 Thread Jakub Jelinek
The first release candidate for GCC 9.2 is available from https://gcc.gnu.org/pub/gcc/snapshots/9.2.0-RC-20190805/ ftp://gcc.gnu.org/pub/gcc/snapshots/9.2.0-RC-20190805 and shortly its mirrors. It has been generated from SVN revision 274111. I have so far bootstrapped and tested the release c

Re: Re: [GSoC'19, libgomp work-stealing] Task parallelism runtime

2019-08-05 Thread Jakub Jelinek
On Sat, Aug 03, 2019 at 06:11:58PM +0900, 김규래 wrote: > I'm currently having trouble implementing the thread sleeping mechanism when > the queue is out of tasks. > Problem is, it's hard to maintain consistency between the thread sleeping > routine and the queues. > See the pseudocode below, > >

GCC 9.1.1 Status Report (2019-07-31)

2019-07-31 Thread Jakub Jelinek
Status == The GCC 9 branch is open for regression and documentation fixes. We intend to release GCC 9.2 soon starting with a release candidate on Monday, August 5th. This gives you some time to go over your assigned regression bug reports and consider backports. If there are any unreported i

Re: Re: [GSoC'19, libgomp work-stealing] Task parallelism runtime

2019-07-22 Thread Jakub Jelinek
On Sun, Jul 21, 2019 at 04:46:33PM +0900, 김규래 wrote: > About the snippet below, > > if (gomp_barrier_last_thread (state)) > { > if (team->task_count == 0) > { > gomp_team_barrier_done (&team->barrier, state); > gomp_mutex_unlock (&team->task_lock); > gomp_team_barrier_wake (&

Re: Re: [GSoC'19, libgomp work-stealing] Task parallelism runtime

2019-07-12 Thread Jakub Jelinek
On Tue, Jul 09, 2019 at 09:56:00PM +0900, 김규래 wrote: > Hi, > This is an update about my status. > I've been working on unifying the three queues into a single queue. > I'm almost finished and passed all the tests except for the dependency > handling part. For dependencies, I can imagine taking a

Re: [PATCH] Deprecate -frepo on gcc-9 branch (PR c++/91125).

2019-07-11 Thread Jakub Jelinek
On Thu, Jul 11, 2019 at 08:48:52AM +0200, Martin Liška wrote: > --- a/gcc/c-family/c-opts.c > +++ b/gcc/c-family/c-opts.c > @@ -501,6 +501,8 @@ c_common_handle_option (size_t scode, const char *arg, > HOST_WIDE_INT value, >flag_use_repository = value; >if (value) > flag_impli

Re: [PATCH] Deprecate -frepo option.

2019-07-10 Thread Jakub Jelinek
On Wed, Jul 10, 2019 at 02:53:35PM +0200, Martin Liška wrote: > On 7/10/19 2:48 PM, Nathan Sidwell wrote: > > On 7/10/19 7:28 AM, Martin Liška wrote: > > > >> Great, thank you. > >> > >> There's a patch for deprecating of the option in GCC 9 changes. > >> > >> May I install the patch right now or

Re: Doubts regarding the _Dependent_ptr keyword

2019-07-04 Thread Jakub Jelinek
On Thu, Jul 04, 2019 at 10:40:15AM -0700, Paul E. McKenney wrote: > > I think fully guaranteeing this is hard (besides when you use > > volatile), we have the very same issue when dealing with > > pointer provenance rules, known for years and not fixed > > (and I don't see a good way to fix these i

Re: [GSoC'19] First Evaluations: Implementing OpenMP Work Stealing Scheduling

2019-06-27 Thread Jakub Jelinek
On Thu, Jun 27, 2019 at 05:20:56AM +0900, 김규래 wrote: > I'll share my status for GSoC first evaluation. > > Current status of libgomp task system: > I'll first summarize my understanding of libgomp. > Please correct me if I'm wrong. > Currently libgomp has 3 different queues: children_queue, taskl

Re: Re: [GSoC'19, libgomp work-stealing] Task parallelism runtime

2019-06-24 Thread Jakub Jelinek
On Tue, Jun 25, 2019 at 04:55:17AM +0900, 김규래 wrote: > I'm not very familiar with the gomp plugin system. > However, looking at 'GOMP_PLUGIN_target_task_completion' seem like tasks have > to go in and out of the runtime. > In that case, is it right that the tasks have to know from which queue they

Re: [PATCH] Deprecate -frepo option.

2019-06-21 Thread Jakub Jelinek
On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote: > On 6/21/19 1:58 PM, Jakub Jelinek wrote: > > On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote: > >> On 6/21/19 1:47 PM, Jonathan Wakely wrote: > >>> On Fri, 21 Jun 2019 at 11:40, Martin Liška

Re: [PATCH] Deprecate -frepo option.

2019-06-21 Thread Jakub Jelinek
On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote: > On 6/21/19 1:47 PM, Jonathan Wakely wrote: > > On Fri, 21 Jun 2019 at 11:40, Martin Liška wrote: > >> Yes, I would be fine to deprecate that for GCC 10.1 > > > > Would it be appropriate to issue a warning in GCC 10.x if the option is

Re: Long compile time of 'insn-extract.c'

2019-06-18 Thread Jakub Jelinek
On Tue, Jun 18, 2019 at 06:40:15PM +0200, Thomas Schwinge wrote: > I normally don't pay too much attention to how GCC builds proceed, but > here, I was waiting for it to complete... ;-) > > Doing a native bootstrap build on x86_64-pc-linux-gnu, with > '--enable-checking=yes,extra,df,fold,rtl' (is

Re: [GSoC'19] How to test lock-free code?

2019-06-17 Thread Jakub Jelinek
On Mon, Jun 17, 2019 at 05:16:18PM +0900, 김규래 wrote: > Currently, gcc (specifically libgomp) contains some amount of lock-free code. > Does gcc test for the correctness of the lock-free sections? No. Well, there is thread sanitizer, -fsanitize=thread, but it isn't able to understand the futex etc

Re: [PATCH] Do not warn with warn_unused_result for alloca(0).

2019-06-13 Thread Jakub Jelinek
On Thu, Jun 13, 2019 at 03:59:33PM +, Michael Matz wrote: > without running the risk of unlimited stack use. But of course this would > promote a programming style that'd only work with our alloca (and not even > C-alloca), and we want to avoid that. I thought it a cute idea, but was > car

Re: [PATCH] Do not warn with warn_unused_result for alloca(0).

2019-06-12 Thread Jakub Jelinek
On Wed, Jun 12, 2019 at 10:13:57AM -0600, Martin Sebor wrote: > But GCC doesn't support such an implementation, does it? Why would that be relevant? The warning would cause people to make portable code less portable (by removing the alloca (0) calls that were added there for portability reasons),

Re: [PATCH] Do not warn with warn_unused_result for alloca(0).

2019-06-12 Thread Jakub Jelinek
On Wed, Jun 12, 2019 at 01:30:14PM +0200, Martin Liška wrote: > @@ -9447,10 +9448,19 @@ do_warn_unused_result (gimple_seq seq) > location_t loc = gimple_location (g); > > if (fdecl) > - warning_at (loc, OPT_Wunused_result, > - "ignoring

Re: [PATCH] Do not warn with warn_unused_result for alloca(0).

2019-06-12 Thread Jakub Jelinek
On Wed, Jun 12, 2019 at 01:11:09PM +0200, Martin Liška wrote: > 2019-06-12 Martin Liska > > * calls.c (special_function_p): Make it global. > * calls.h (special_function_p): Declare. Why? > * tree-cfg.c (do_warn_unused_result): Do not > warn for alloca(0). > --- a/gcc/

Re: alloca (0) in include/libiberty.h

2019-06-11 Thread Jakub Jelinek
On Tue, Jun 11, 2019 at 03:58:27PM +, Michael Matz wrote: > On Tue, 11 Jun 2019, Martin Liška wrote: > > > I see 3 occurrences of the alloca (0) in libiberty/regex.c, but there are > > properly > > guarded within: > > > > # ifdef C_ALLOCA > > alloca (0); > > # endif > > > > and then I

Re: [GSoC'19, libgomp work-stealing] Task parallelism runtime

2019-06-05 Thread Jakub Jelinek
On Thu, Jun 06, 2019 at 03:25:24AM +0900, 김규래 wrote: > Hi, thanks for the detailed explanation. > I think I now get the picture. > Judging from my current understanding, the task-parallelism currently works > as follows: > 1. Tasks are placed in a global shared queue. It isn't a global shared qu

Re: [GSoC'19, libgomp work-stealing] Task parallelism runtime

2019-06-03 Thread Jakub Jelinek
On Tue, Jun 04, 2019 at 03:01:13AM +0900, 김규래 wrote: > Hi, > I've been studying the libgomp task parallelism system. > I have a few questions. > First, Tracing the events shows that only the main thread calls GOMP_task. No, any thread can call GOMP_task, in particular the thread that encountered t

Re: Fixing inline expansion of overlapping memmove and non-overlapping memcpy

2019-05-15 Thread Jakub Jelinek
On Wed, May 15, 2019 at 12:59:01PM -0500, Aaron Sawdey wrote: > On 5/15/19 11:31 AM, Jakub Jelinek wrote: > > On Wed, May 15, 2019 at 11:23:54AM -0500, Aaron Sawdey wrote: > >> My goals for this are: > >> * memcpy() call becomes __builtin_memcpy and goes to optab[cpy

Re: Fixing inline expansion of overlapping memmove and non-overlapping memcpy

2019-05-15 Thread Jakub Jelinek
On Wed, May 15, 2019 at 11:23:54AM -0500, Aaron Sawdey wrote: > We currently have gimple_fold_builtin_memory_op() figuring out where there > is no overlap and converging __builtin_memmove() to __builtin_memcpy(). Would > you forsee looking for converting __builtin_memmove() with overlap into > a ca

Re: Fixing inline expansion of overlapping memmove and non-overlapping memcpy

2019-05-15 Thread Jakub Jelinek
On Wed, May 15, 2019 at 02:02:32PM +, Michael Matz wrote: > > Yes this would be a nice thing to get to, a single move/copy underlying > > builtin, to which we communicate what the compiler's analysis tells us > > about whether the operands overlap and by how much. > > > > Next question would

Re: GCC 9 linker error, missing GOMP_loop_nonmonotonic_dynamic_next

2019-05-07 Thread Jakub Jelinek
On Tue, May 07, 2019 at 10:47:40AM +0200, FX wrote: > >> Those are certainly exported from my GCC 9 libgomp.so.1.0.0 (at least on > >> Linux but I don't see how it could not be elsewhere). > > I can confirm they are present. > > The issue I am having is indeed due to GCC 9 trying to link against

Re: GCC 9 linker error, missing GOMP_loop_nonmonotonic_dynamic_next

2019-05-06 Thread Jakub Jelinek
On Mon, May 06, 2019 at 02:41:41PM +0200, FX wrote: > Hi gcc and gfortran developers, > > While testing GCC 9.1.0 before shipping it as part of Homebrew for macOS, > we’re seeing the following OpenMP-based failure when recompiling several > software packages with GCC 9. It includes both C++ and

GCC 9.1 Released

2019-05-03 Thread Jakub Jelinek
We are proud to announce the next, major release of the GNU Compiler Collection. If you want to boost your software with a fresh new compiler, with new language features, various new optimizations, improvements to old optimizations, GCC 9.1 is here for you! GCC 9.1 is a major release containing s

Second GCC 9.1 Release Candidate available from gcc.gnu.org

2019-04-30 Thread Jakub Jelinek
The second release candidate for GCC 9.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/9.0.1-RC-20190430/ ftp://gcc.gnu.org/pub/gcc/snapshots/9.0.1-RC-20190430 and shortly its mirrors. It has been generated from SVN revision 270689. I have so far bootstrapped and tested the release

Re: [9/10 Regression] [PR87833] Intel MIC (emulated) offloading still broken (was: GCC 9.0.1 Status Report (2019-04-25))

2019-04-30 Thread Jakub Jelinek
On Tue, Apr 30, 2019 at 01:02:40PM +0200, Thomas Schwinge wrote: > Hi Jakub! > > On Tue, 30 Apr 2019 12:56:52 +0200, Jakub Jelinek wrote: > > On Tue, Apr 30, 2019 at 12:47:54PM +0200, Thomas Schwinge wrote: > > > Email to apparently is no longer gets delivered. > &g

Re: [9/10 Regression] [PR87833] Intel MIC (emulated) offloading still broken (was: GCC 9.0.1 Status Report (2019-04-25))

2019-04-30 Thread Jakub Jelinek
On Tue, Apr 30, 2019 at 12:47:54PM +0200, Thomas Schwinge wrote: > Email to apparently is no longer gets delivered. > Is there anyone else from Intel who'd take over maintenance? As your patch is to LTO option handling, I think you want a review from Honza. At this point I'd lean towards fixing

GCC 9.1 Release Candidate available from gcc.gnu.org

2019-04-26 Thread Jakub Jelinek
The first release candidate for GCC 9.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/9.0.1-RC-20190426/ ftp://gcc.gnu.org/pub/gcc/snapshots/9.0.1-RC-20190426 and shortly its mirrors. It has been generated from SVN revision 270601. I have so far bootstrapped and tested the release c

GCC 10.0.0 Status Report (2019-04-25)

2019-04-25 Thread Jakub Jelinek
Status == The trunk has branched for the GCC 9 release and is now open again for general development, stage 1. Please consider not disrupting it too much during the RC phase of GCC 9 so it is possible to test important fixes for 9.1 on it. Quality Data Priority # Ch

GCC 9.0.1 Status Report (2019-04-25)

2019-04-25 Thread Jakub Jelinek
Status == We have reached zero P1 regressions today and branches/gcc-9-branch has been created; GCC 9.1-rc1 will be built and announced likely tomorrow. The branch is now frozen for blocking regressions and documentation fixes only, all changes to the branch require a RM approval now. If no

Re: C provenance semantics proposal

2019-04-24 Thread Jakub Jelinek
On Wed, Apr 24, 2019 at 12:41:25PM -0600, Jeff Law wrote: > >>> 4.) Compilers make sure that exposed objects never > >>> are allocated next to each other (as Jens proposed). > >> Ugh. Not sure how you enforce that. Consider that the compiler may > >> ultimately have no control over layout of data

Re: C provenance semantics proposal

2019-04-19 Thread Jakub Jelinek
On Fri, Apr 19, 2019 at 11:09:27AM +0200, Jens Gustedt wrote: > > similarly, if one of the > > pointers is &object or &object + sizeof (object). > > Here I don't follow. Why would one waste brain and ressources to > optimize code that does such tricks? What tricks? A normal pointer comparison ei

Re: C provenance semantics proposal

2019-04-19 Thread Jakub Jelinek
On Fri, Apr 19, 2019 at 10:19:28AM +0200, Jens Gustedt wrote: > > OTOH GCC transforms > > (uintptr_t)&a != (uintptr_t)(&b+1) > > into &a != &b + 1 (for equality compares) and then > > doesn't follow this C rule anyways. > > Actually our proposal we are discussing here goes exactly the other > way

Re: C provenance semantics proposal

2019-04-18 Thread Jakub Jelinek
On Thu, Apr 18, 2019 at 02:47:18PM +0200, Jakub Jelinek wrote: > On Thu, Apr 18, 2019 at 02:42:22PM +0200, Richard Biener wrote: > > > 1.) Compilers do not use conditional equivalences for > > > optimizations of pointers (or only when additional > > > condi

Re: C provenance semantics proposal

2019-04-18 Thread Jakub Jelinek
On Thu, Apr 18, 2019 at 02:42:22PM +0200, Richard Biener wrote: > > 1.) Compilers do not use conditional equivalences for > > optimizations of pointers (or only when additional > > conditions apply which make it safe) > > > > 2.) We make pointer comparison between a pointer > > and a one-after poin

Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

2019-04-16 Thread Jakub Jelinek
On Tue, Apr 16, 2019 at 03:44:44PM +0200, Jakub Jelinek wrote: > I can't reproduce this on my Fedora 29 x86_64-linux bootstrap box though, > the *.log files are complete there. > > And I have no idea if it was introduced with your change or earlier. Actually, I managed to repr

Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

2019-04-16 Thread Jakub Jelinek
On Tue, Apr 16, 2019 at 02:49:13PM +0200, Christophe Lyon wrote: > > I executed the dg-extract-results.sh manually in the gcc/testsuite > > directory after a complete testsuite run which didn't give the correct > > results. Rev. 240429 gives the expected results, where rev 268511 fails. > > I'm on

Re: GCC 8 vs. GCC 9 speed and size comparison

2019-04-16 Thread Jakub Jelinek
On Tue, Apr 16, 2019 at 01:25:38PM +0200, Richard Biener wrote: > So for the parser it's small differences that accumulate, for example > a lot more comptype calls via null_ptr_cst_p (via char_type_p) via the new > conversion_null_warnings which is called even without any warning option. > > Possi

Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

2019-04-15 Thread Jakub Jelinek
On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote: > There seems to be a generic issue with the tests in gcc/testsuite. The > log files do not contain the logs. Perhaps contrib/dg-extract-results* misbehaved? Can you look for the testsuite/g++*/g++.log.sep files? Do they contain every

Re: GCC 8 vs. GCC 9 speed and size comparison

2019-04-15 Thread Jakub Jelinek
On Mon, Apr 15, 2019 at 12:12:13PM +, Michael Matz wrote: > Hi, > > On Mon, 15 Apr 2019, Martin Liška wrote: > > > There's a similar comparison that I did for the official openSUSE gcc > > packages. gcc8 is built with PGO, while the gcc9 package is built in 2 > > different configurations: P

Re: GSoC OMPD

2019-04-08 Thread Jakub Jelinek
On Thu, Apr 04, 2019 at 02:24:09PM +0200, Martin Jambor wrote: > > I know my first email is vague. I wanted to throw it out there since > > the April 9th deadline is coming up. > > I was hoping Jakub Jelinek, who would be the mentor, would chime in > earlier. But unfortun

Re: Function pointers to a nested function / contained procedure

2019-03-27 Thread Jakub Jelinek
On Wed, Mar 27, 2019 at 10:02:21AM +0100, Richard Biener wrote: > On Wed, Mar 27, 2019 at 8:48 AM Thomas König wrote: > > > > Hi Eric, > > > There is an entire machinery in the middle-end and the back-ends to > > > support this (look for trampolines/descriptors in the manual and the > > > source

Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]

2019-03-26 Thread Jakub Jelinek
On Tue, Mar 26, 2019 at 01:30:28PM +0530, sameeran joshi wrote: > > I'd need to see an example of what you are talking about. > > int i; > #pragma omp parallel for > for (i = (0) ; (i< (20)) ; i++) { > printf ("\ntest expression fails due to brackets"); >

Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]

2019-03-26 Thread Jakub Jelinek
On Mon, Mar 25, 2019 at 05:41:26PM -0700, Andi Kleen wrote: > sameeran joshi writes: > > > On 3/24/19, Andi Kleen wrote: > >> On Sat, Mar 23, 2019 at 11:49:11PM +0530, sameeran joshi wrote: > >>> 1) check_structured_block_conditions() > >>> checks for the conditions related to a structured blo

Re: GSoC

2019-03-25 Thread Jakub Jelinek
On Tue, Mar 26, 2019 at 01:05:37AM +0100, Martin Jambor wrote: > On Sun, Mar 10 2019, Martin Emil wrote: > > Hello , > > I am Martin Emil last year computer engineering student from Egypt . > > I came through your project in GSoC and i am very interested about it and > > want to work on it. > > I

Re: GCC turns &~ into | due to undefined bit-shift without warning

2019-03-22 Thread Jakub Jelinek
On Fri, Mar 22, 2019 at 01:28:39PM +0100, David Brown wrote: > If you compile a "hello, world!" C program, then the C standards do not > define how those words get on your screen. As far as /C/ is concerned, > the workings of "printf" are undefined behaviour - because the C > standard does not def

Re: GCC turns &~ into | due to undefined bit-shift without warning

2019-03-22 Thread Jakub Jelinek
On Fri, Mar 22, 2019 at 10:27:38AM +0100, Allan Sandfeld Jensen wrote: > But getting back to the question, well GCC carry such information further, > and > thus break code that is otherwise correct behaving on all known > architectures, > just because the C standard hasn't decided on one of two

Re: GCC turns &~ into | due to undefined bit-shift without warning

2019-03-21 Thread Jakub Jelinek
On Thu, Mar 21, 2019 at 11:19:54PM +0100, Allan Sandfeld Jensen wrote: > Hmm, I am curious. How strongly would gcc assume x is 0? If x is not 0, then it is undefined behavior and anything can happen, so yes, it can assume x is 0, sometimes gcc does that, sometimes not, it is not required to do tha

Re: GCC turns &~ into | due to undefined bit-shift without warning

2019-03-20 Thread Jakub Jelinek
On Wed, Mar 20, 2019 at 02:08:09PM +, Moritz Strübe wrote: > Ok, I played around a bit. Interestingly, if I set -fsanitize=udefined and > -fsanitize-undefined-trap-on-error the compiler detects that it will always > trap, and optimizes the code accordingly (the code after the trap is > remov

Re: GCC turns &~ into | due to undefined bit-shift without warning

2019-03-11 Thread Jakub Jelinek
On Mon, Mar 11, 2019 at 11:06:37AM +, Moritz Strübe wrote: > On 11.03.2019 at 10:14 Jakub Jelinek wrote: > > You could build with -fsanitize=undefined, that would tell you at runtime > > you > > have undefined behavior in your code (if the SingleDiff has bit ever 0x20 >

Re: GCC turns &~ into | due to undefined bit-shift without warning

2019-03-11 Thread Jakub Jelinek
On Mon, Mar 11, 2019 at 08:49:30AM +, Moritz Strübe wrote: > Considering that C11 6.5.7#3 ("If  the  value  of  the  right operand  > is  negative  or  is greater than or equal to the width of the promoted > left operand, the behavior is undefined.") is not very widely known, as > it "normal

Re: GSoC Project Ideas

2019-03-04 Thread Jakub Jelinek
On Mon, Mar 04, 2019 at 01:13:29PM +0100, Richard Biener wrote: > > > * Make TREE_NO_WARNING more fine-grained > > > (inspired by comment #7 of PR74762 [3]) > > > TREE_NO_WARNING is currently used as a catch-all marker that > > > inhibits all > > > warnings related to the marked

Re: Implementing an algorithm in place of gomp 'auto'

2019-03-02 Thread Jakub Jelinek
On Sat, Mar 02, 2019 at 10:05:25PM +0900, 김규래 wrote: > > It is on the wish list, but I'm afraid I won't have cycles for it in the > > next year or two at least (once GCC 9 is released, I need to work on the > > remaining OpenMP 5.0 features). Of course if somebody implements it and > > submits >

Re: Implementing an algorithm in place of gomp 'auto'

2019-03-01 Thread Jakub Jelinek
On Sat, Mar 02, 2019 at 02:40:35AM +0900, 김규래 wrote: > Nice to meet you Jacob. > > > Another option is to add further schedules as extensions (say starting with > > gnu_ prefix or similar). > > In this case, I believe that modifying the frontend would be necessary? Yes. > Last time I looked,

Re: Implementing an algorithm in place of gomp 'auto'

2019-03-01 Thread Jakub Jelinek
On Fri, Mar 01, 2019 at 11:40:50PM +0900, 김규래 wrote: > Hello everyone, > I'm an EE student at Sogang University Korea. > I have recently submitted a paper on parallel loop scheduling algorithm and > had to modify libgomp a bit in the process. > It is known that the... > > > > /* For now map

Re: [RFC] Change PCH "checksum"

2019-02-22 Thread Jakub Jelinek
On Fri, Feb 22, 2019 at 08:47:09AM -0700, Jeff Law wrote: > > 2019-02-22 Richard Biener > > > > c/ > > * Make-lang.in (cc1-checksum.c): Checksum only gtype-desc.o. > > > > cp/ > > * Make-lang.in (cc1plus-checksum.c): Checksum only gtype-desc.o. > > > > objc/ > > * Make

GCC 8.4 Status Report (2019-02-22)

2019-02-22 Thread Jakub Jelinek
Status == GCC 8.3 has been released and the branch is again open for regression and documentation fixes. History makes us expect a GCC 8.4 release at the end of this year. Quality Data Priority # Change from last report --- ---

GCC 8.3 Released

2019-02-22 Thread Jakub Jelinek
The GNU Compiler Collection version 8.3 has been released. GCC 8.3 is a bug-fix release from the GCC 8 branch containing important fixes for regressions and serious bugs in GCC 8.2 with more than 153 bugs fixed since the previous release. This release is available from the FTP servers listed at:

GCC 8.3 Status Report (2019-02-15)

2019-02-15 Thread Jakub Jelinek
Status == The GCC 8 branch is now frozen for blocking regressions and documentation fixes only, all changes to the branch require a RM approval now. Quality Data Priority # Change from last report --- --- P10 P2

GCC 8.3 Release Candidate available from gcc.gnu.org

2019-02-15 Thread Jakub Jelinek
The first release candidate for GCC 8.3 is available from https://gcc.gnu.org/pub/gcc/snapshots/8.3.0-RC-20190215/ ftp://gcc.gnu.org/pub/gcc/snapshots/8.3.0-RC-20190215/ and shortly its mirrors. It has been generated from SVN revision 268935. I have so far bootstrapped and tested the release

Re: GCC missing -flto optimizations? SPEC lbm benchmark

2019-02-15 Thread Jakub Jelinek
On Fri, Feb 15, 2019 at 02:12:27PM +0100, Richard Biener wrote: > On February 15, 2019 1:45:10 PM GMT+01:00, Hi-Angel > wrote: > >I never could understand, why field reordering was removed from GCC? > > The implementation simply was seriously broken, bitrotten and unmaintained. Which of course

<    1   2   3   4   5   6   7   8   9   10   >