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
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
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
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
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
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
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
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
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 / -
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
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
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
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
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
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
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
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
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
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:
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
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
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
>
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.
>
>
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
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
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
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
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
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
---
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:
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)
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
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
> >
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.
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.
> >
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
--- -
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
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,
>
>
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
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 (&
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
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
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
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
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
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
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
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
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
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
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
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),
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
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/
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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");
>
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
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
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
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
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
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
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
>
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
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
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
>
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,
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
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
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
--- ---
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:
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
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
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
401 - 500 of 1650 matches
Mail list logo
