Gary
> ____
> From: Richard Biener
> Sent: Monday, January 13, 2020 2:30 AM
> To: Gary Oblock ; Jan Hubicka
> Cc: gcc@gcc.gnu.org
> Subject: [EXT] Re: Option processing question
>
> External Email
>
>
On Tue, Jan 14, 2020 at 11:44 AM Jonathan Wakely wrote:
>
> On Tue, 14 Jan 2020 at 10:38, Uros Bizjak wrote:
> >
> > On Tue, Jan 14, 2020 at 11:34 AM Jonathan Wakely
> > wrote:
> > >
> > > On Tue, 14 Jan 2020 at 09:22, Uros Bizjak wrote:
> > > >
> > > > gcc_update, when called from newly initi
On Tue, Jan 14, 2020 at 5:51 PM Eric S. Raymond wrote:
>
> Peter Bergner :
> > At this point, I get a little confused. :-) I know to submit my patch
> > for review, I'll want to squash my commits down into one patch, but how
> > does one do that? Should I do that now or only when I'm ready to
>
On Wed, Jan 15, 2020 at 10:33 AM Jonathan Wakely wrote:
>
> On Wed, 15 Jan 2020 at 08:40, Richard Biener
> wrote:
> >
> > On Tue, Jan 14, 2020 at 5:51 PM Eric S. Raymond wrote:
> > >
> > > Peter Bergner :
> > > > At this point, I ge
On Thu, Jan 16, 2020 at 4:54 PM GT wrote:
>
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, January 15, 2020 3:20 PM, GT wrote:
>
> > ‐‐‐ Original Message ‐‐‐
> > On Thursday, January 9, 2020 8:42 AM, Richard Biener
> > richard.guent...@gmail.com
On Wed, 15 Jan 2020, Fāng-ruì Sòng wrote:
> H.J. Lu's https://sourceware.org/ml/binutils/2019-11/msg00174.html
> assembler patch series added -mbranches-within-32B-boundaries and some
> fine-grained tuning options to GNU as, which are considered a pretty
> important performance mitigation of a ser
On Tue, Jan 21, 2020 at 8:58 PM Martin Liška wrote:
>
> On 1/21/20 6:30 PM, Jonathan Wakely wrote:
> > Whether they make it to trunk or not doesn't really change the fact
> > that a one-word message is poor. If it's only on your local machine,
> > do what you like. The hook only complains when suc
On Mon, Jan 27, 2020 at 6:41 PM Erick Ochoa
wrote:
>
> Hello,
>
> I have a problem with a transformation I'm working on and I would appreciate
> some help. The transformation I am working on removes fields in structs early
> during link-time. For the purposes of development and this example, my
>
On January 30, 2020 5:05:09 PM GMT+01:00, Martin Sebor wrote:
>On 1/30/20 2:59 AM, Jonathan Wakely wrote:
>> On Thu, 30 Jan 2020, 05:44 Nicholas Krause wrote:
>>>
>>> Greetings,
>>>
>>> I was looking into starting to cleaning up the SSA trees for various
>>> reasons and iterators
>>> seem to be th
On Fri, 31 Jan 2020, Bin.Cheng wrote:
> Hi,
> In tree.c:build2 there is following code/comment:
>
> if ((code == MINUS_EXPR || code == PLUS_EXPR || code == MULT_EXPR)
> && arg0 && arg1 && tt && POINTER_TYPE_P (tt)
> /* When sizetype precision doesn't match that of pointers
>
On Thu, Feb 6, 2020 at 2:51 PM Segher Boessenkool
wrote:
>
> On Wed, Feb 05, 2020 at 06:43:54PM -0700, Jeff Law wrote:
> > On Wed, 2020-02-05 at 15:18 -0600, Segher Boessenkool wrote:
> > > As a reviewer, the changelog is priceless still. We shouldn't drop the
> > > changelog before people write
On Thu, Feb 6, 2020 at 11:25 PM Segher Boessenkool
wrote:
>
> On Thu, Feb 06, 2020 at 03:01:20PM +0100, Richard Biener wrote:
> > On Thu, Feb 6, 2020 at 2:51 PM Segher Boessenkool
> > wrote:
> > > If you rebase changelog files, then yes, it's a bloody pain ;-)
On Fri, Feb 7, 2020 at 4:43 PM Richard Earnshaw (lists)
wrote:
>
> On 07/02/2020 15:32, Segher Boessenkool wrote:
> > On Fri, Feb 07, 2020 at 01:56:08PM +, Richard Earnshaw (lists) wrote:
> >> On 07/02/2020 13:48, Segher Boessenkool wrote:
> >>> Should we require some simple markup in the comm
On February 11, 2020 9:32:14 PM GMT+01:00, "Uecker, Martin"
wrote:
>
>In the following example, it seems
>that 'bar' could be optimized to
>return '1' and every else could be
>optimized away. Or am I missing
>something?
p might be still NULL when bar is called.
Do I need to add
>some specif
On Tue, Feb 11, 2020 at 10:27 PM Uecker, Martin
wrote:
>
> Am Dienstag, den 11.02.2020, 21:43 +0100 schrieb Richard Biener:
> > On February 11, 2020 9:32:14 PM GMT+01:00, "Uecker, Martin"
> >
> > wrote:
> > >
> > > In the following exam
On Sun, Feb 16, 2020 at 7:22 PM Dennis Luehring wrote:
>
> Am 16.02.2020 um 18:42 schrieb David Edelsohn:
> > If you are trying to forward-port your own, proprietary features into
> > a newer release of GCC for your own, internal use, that's your
> > responsibility.
>
> that is my case, i ask for
On Tue, Feb 18, 2020 at 8:37 PM Bernd Edlinger
wrote:
>
> > It has been almost a year since GCC 8.3 has been released and GCC 8.4
> > release should have been released already, so we should concentrate on
> > getting it out soon. Unfortunately we have two P1s, one of them is
> > waiting for repor
On Fri, Feb 21, 2020 at 9:18 AM shivam tiwari
wrote:
>
> I have New Project Idea for GSOC 2020 Where Can I discuss about New
> Project idea.OR Can I share my project idea Proposal on this mail.
You can share your proposal on this mailing-list, the existing project
ideas list
is not meant to be
On Thu, Feb 27, 2020 at 6:56 PM Giuliano Belinassi
wrote:
>
> Hi, all.
>
> I am tying to fix an issue with a global variable in the parallel gcc
> project. For this, I am trying to move some global variables from
> tree-ssa-operands to struct function. One of this variable is a
> vec type, and gen
On Mon, 2 Mar 2020, Alexander Monakov wrote:
> Hi,
>
> following the conversation in PR 90348, I wonder if it would make sense
> to suggest the idea presented there as a potential GSoC topic? Like this:
>
> **Enhance GIMPLE IR to represent lifetimes explicitly** At the moment,
> GCC internal re
On Mon, 2 Mar 2020, Alexander Monakov wrote:
> On Mon, 2 Mar 2020, Richard Biener wrote:
>
> > PR90348 is certainly entertaining. But I guess for a GSoC project
> > we need a more elaborate implementation plan. The above suggesting
> > of a "lifetime start&quo
On Tue, Mar 10, 2020 at 7:52 AM Kewen.Lin wrote:
>
> Hi all,
>
> I'm investigating whether GCC can vectorize the below case on ppc64le.
>
> extern void test(unsigned int t[4][4]);
>
> void foo(unsigned char *p1, int i1, unsigned char *p2, int i2)
> {
> unsigned int tmp[4][4];
> unsig
On Tue, Mar 10, 2020 at 12:12 PM Richard Biener
wrote:
>
> On Tue, Mar 10, 2020 at 7:52 AM Kewen.Lin wrote:
> >
> > Hi all,
> >
> > I'm investigating whether GCC can vectorize the below case on ppc64le.
> >
> > extern void test(unsigned int t[4]
for real-world usage for GCC 11!
Thanks,
Richard.
> - Week 12 -- July 13 to 17: **Second Evaluation**\
> Deliver a more optimized version of the project. Here we should
> filter files that would compile fast from files that would require
> partitioning, and therefore we shou
On Tue, 17 Mar 2020, Giuliano Belinassi wrote:
> Hi, Richi
>
> Thank you for your review!
>
> On 03/16, Richard Biener wrote:
> > On Fri, 13 Mar 2020, Giuliano Belinassi wrote:
> >
> > > Hi, all
> > >
> > > I want to propose and apply for
efore it should interact with GNU Make Jobserver.
> >
> > - Week 8 -- June 15 to 19: **First Evaluation**\
> > Deliver a non-optimized version of the project. Some programs ought
> > to be compiled correctly, but probably there will be a huge overhead
> > because so far there will not be any criteria about when to
> > partition. Some tests are also planned for this evaluation.
> >
> > - Week \[9, 11\] -- June 22 to July 10:\
> > Implement a criteria about when to partition, and interactively
> > improve it based on data.
> >
> > - Week 12 --- July 13 to 17: **Second Evaluation**\
> > Deliver a more optimized version of the project. Here we should
> > filter files that would compile fast from files that would require
> > partitioning, and therefore we should see some speedup.
> >
> > - Week \[13, 15\] --- July 20 to August 10:\
> > Develop adequate tests coverage and address unexpected issues so
> > that this feature can be merged to trunk for the next GCC release.
> >
> > - Week 16: **Final evaluation**\
> > Deliver the final product as a series of patches for trunk.
> >
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Mon, 23 Mar 2020, Giuliano Belinassi wrote:
> Hi, Richi
>
> On 03/18, Richard Biener wrote:
> > On Tue, 17 Mar 2020, Giuliano Belinassi wrote:
> >
> > > Hi, all
> > >
> > > I have applied some revews to the project. Please see the new proposal
Status
==
GCC trunk is in regression and documentation fixing mode, stage 4.
There's still quite some work to do before we reach the zero-P1
milestone and thus qualify for a first release candidate of GCC 10.
Please help in making this happen soon, historical data would
predict a RC to be av
On Wed, 3 Jun 2020, Uros Bizjak wrote:
> I would like to inform GCC community, that I decided to step down from
> maintaining x86 vector ISA part. x86 vector ISA has its own
> non-responsive maintainer, but I have filled the maintainers role
> nevertheless, until gcc-10 was released.
>
> Unfortun
I'm facing the issue that we have vector type dependent information
stored in dr_vec_info (the misalignment at least) and that with
BB vectorization (at least) we want to be able to access a DR group with
two different vector types.
I've run into this with
https://gcc.gnu.org/pipermail/gcc-patc
TF ("last %d %d %d\n", i, j, x);
> if (i != 16 || j != 4 || x != 5 * 1024 - 11)
> abort ();
> DPRINTF ("===\n");
> x = i = j = -1;
> #pragma omp parallel num_threads(15)
> bar (v + 4, v + 8, v + 12, v - 8, v - 9, v - 3, v + 6, v + 15);
> DPRINTF
Status
==
The GCC 10 branch is in regression and documentation fixing mode.
We're close to two months after the GCC 10.1 release which means
a first bugfix release is about to happen. The plan is to release
mid July and I am targeting for a release candidate mid next
week, no later than Ju
On Mon, 29 Jun 2020, Richard Biener wrote:
>
> Status
> ==
>
> The GCC 10 branch is in regression and documentation fixing mode.
>
> We're close to two months after the GCC 10.1 release which means
> a first bugfix release is about to happen. The plan is t
Status
==
The GCC 10 branch is now frozen for the GCC 10.2 release, all changes
to he branch require a RM approval.
Quality Data
Priority # Change from last report
--- ---
P1
P2 218 + 2
P3
The first release candidate for GCC 10.2 is available from
https://gcc.gnu.org/pub/gcc/snapshots/10.2.0-RC-20200715/
ftp://gcc.gnu.org/pub/gcc/snapshots/10.2.0-RC-20200715/
and shortly its mirrors. It has been generated from git commit
932e9140d3268cf2033c1c3e93219541c53fcd29.
I have so far
On Fri, 17 Jul 2020, Thomas Schwinge wrote:
> Hi!
>
> On 2020-07-15T13:50:35+0200, Richard Biener wrote:
> > The first release candidate for GCC 10.2 is available from
> >
> > https://gcc.gnu.org/pub/gcc/snapshots/10.2.0-RC-20200715/
> > ftp://gcc.gnu.org/pub
On Fri, 17 Jul 2020, Romain Naour wrote:
> Hello,
>
> Le 15/07/2020 à 13:50, Richard Biener a écrit :
> >
> > The first release candidate for GCC 10.2 is available from
> >
> > https://gcc.gnu.org/pub/gcc/snapshots/10.2.0-RC-20200715/
> > ftp://
Status
==
The GCC 10.2 release process has been completed and the GCC 10 branch
is now again open for regression and documentation fixes.
Quality Data
Priority # Change from last report
--- ---
P1
P2
The GNU Compiler Collection version 10.2 has been released.
GCC 10.2 is a bug-fix release from the GCC 10 branch
containing important fixes for regressions and serious bugs in
GCC 10.1 with more than 94 bugs fixed since the previous release.
This release is available from the FTP servers listed a
{
> j = 0;
> curend = start + (end - start > 128 ? 128 : end - start);
> doit:;
> /* I'd use start < curend && j < 128 as condition here, but
>the vectorizer doesn't like that either. So I went to
>using a single IV. */
> for (; start < curend; start++, j++)
> a[i][j] += 3;
> }
> }
>
> This isn't vectorized with -O3 either for the same reason.
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imend
Status
==
GCC trunk which eventually will become GCC 11 is still open for general
development. Stage 1 will end on the end of Sunday, Nov 15th 2020
at which point we will transition into Stage 3 which allows for general
bugfixing.
We have accumulated quite a number of regressions, a lot of
oints-to non-local, points-to NULL, points-to vars: { }
>
> Flow-insensitive points-to information
>
> -i3p.1_3, points-to NULL, points-to vars: { D.1947 D.1948 }
> +i3p.1_3, points-to non-local, points-to escaped, points-to NULL, points-to
> vars: { D.1947 }
> i4p.2_4, points-to NULL, points-to vars: { D.1948 }
>
> main ()
>
> Honza
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imend
for each INSERT with this
mismatch)
Note that ::empty () also oddly uses too_empty_p (m_n_elements)
(maybe we should rename m_n_elements to m_n_elements_with_deleted)
Thanks,
Richard.
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imend
Current description
> "Nonzero if the argument does not escape."
> reads to me that it is about ptr itself, not about *ptr and also it does
> not speak of the escaping to return value etc.
Well, if 'ptr' escapes then obvoiously all memory reachable from 'ptr'
escapes - escaping is always transitive.
And as escaping is in the context of the caller sth escaping to the
caller itself (via return) can hardly be considered escaping (again
this was designed for PTA ...).
I guess it makes sense to be able to separate escaping from the rest.
Richard.
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imend
+ for (tree parm = DECL_ARGUMENTS (current_function_decl); parm;
> parm_index++,
> + parm = TREE_CHAIN (parm))
> +{
> + tree name = ssa_default_def (cfun, parm);
> + if (!name)
> + continue;
looks like the vec might be quite sparse ...
> + int
s are not considered escape points
> > > + by tree-ssa-structalias. */
> > > + else if (gimple_code (use_stmt) == GIMPLE_COND)
> > > + ;
> > > + else
> > > + {
> > > + if (dump_file)
> > > + fprintf (dump_file, "%*s
local mode
> (false) or the IPA mode (true). */
>
> @@ -1174,6 +1531,10 @@ analyze_function (function *f, bool ipa)
> param_modref_max_accesses);
>summary_lto->writes_errno = false;
> }
> +
> + if (!ipa)
> +analyze_parms (summary);
> +
>int ecf_flags = flags_from_decl_or_type (current_function_decl);
>auto_vec recursive_calls;
>
> @@ -1191,8 +1552,9 @@ analyze_function (function *f, bool ipa)
> || ((!summary || !summary->useful_p (ecf_flags))
> && (!summary_lto || !summary_lto->useful_p (ecf_flags
> {
> - remove_summary (lto, nolto, ipa);
> - return;
> + collapse_loads (summary, summary_lto);
> + collapse_stores (summary, summary_lto);
> + break;
> }
> }
> }
> @@ -1957,7 +2319,7 @@ compute_parm_map (cgraph_edge *callee_edge,
> vec *parm_map)
> : callee_edge->caller);
>callee_pi = IPA_NODE_REF (callee);
>
> - (*parm_map).safe_grow_cleared (count);
> + (*parm_map).safe_grow_cleared (count, true);
>
>for (i = 0; i < count; i++)
> {
> diff --git a/gcc/ipa-modref.h b/gcc/ipa-modref.h
> index 31ceffa8d34..59872301cd6 100644
> --- a/gcc/ipa-modref.h
> +++ b/gcc/ipa-modref.h
> @@ -29,6 +29,7 @@ struct GTY(()) modref_summary
>/* Load and stores in function (transitively closed to all callees) */
>modref_records *loads;
>modref_records *stores;
> + auto_vec GTY((skip)) arg_flags;
>
>modref_summary ();
>~modref_summary ();
> diff --git a/gcc/params.opt b/gcc/params.opt
> index a33a371a395..70152bf59bb 100644
> --- a/gcc/params.opt
> +++ b/gcc/params.opt
> @@ -931,6 +931,10 @@ Maximum number of accesse stored in each modref
> reference.
> Common Joined UInteger Var(param_modref_max_tests) Init(64)
> Maximum number of tests performed by modref query.
>
> +-param=modref-max-depth=
> +Common Joined UInteger Var(param_modref_max_depth) Init(256)
> +Maximum depth of DFS walk used by modref escape analysis
> +
> -param=tm-max-aggregate-size=
> Common Joined UInteger Var(param_tm_max_aggregate_size) Init(9) Param
> Optimization
> Size in bytes after which thread-local aggregates should be instrumented
> with the logging functions instead of save/restore pairs.
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imend
rn_pass_by_reference (stmt, wlims);
> + if (gcall *call = dyn_cast (stmt))
> + maybe_warn_pass_by_reference (call, wlims);
> else if (gimple_assign_load_p (stmt)
> && gimple_has_location (stmt))
> {
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imend
L_FUNCTION_CODE (fndecl) : (built_in_function)BUILT_IN_LAST);
> @@ -523,6 +527,10 @@ maybe_warn_pass_by_reference (gimple *stmt, wlimits
> &wlims)
> (but not definitive) read access. */
> wlims.always_executed = false;
>
> + /* Ignore args we are not going to rea
Status
==
GCC trunk which eventually will become GCC 11 is now in Stage 3
which means open for general bugfixing.
We have accumulated quite a number of regressions, a lot of the
untriaged and eventually stale. Please help in cleaning up.
Quality Data
Priority # C
_COND_EXPR into nop ?
Would everything match-up for a .VEC_CMP IFN producing a non-mask
vector type? ISEL could special case the a ? -1 : 0 case this way.
> Thanks,
> Prathamesh
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Thu, 3 Dec 2020, Prathamesh Kulkarni wrote:
> On Tue, 1 Dec 2020 at 16:39, Richard Biener wrote:
> >
> > On Tue, 1 Dec 2020, Prathamesh Kulkarni wrote:
> >
> > > Hi,
> > > For the test mentioned in PR, I was trying to see if we could do
> > >
On Fri, 4 Dec 2020, Prathamesh Kulkarni wrote:
> On Thu, 3 Dec 2020 at 16:35, Richard Biener wrote:
> >
> > On Thu, 3 Dec 2020, Prathamesh Kulkarni wrote:
> >
> > > On Tue, 1 Dec 2020 at 16:39, Richard Biener wrote:
> > > >
> > &
On Mon, 7 Dec 2020, Prathamesh Kulkarni wrote:
> On Fri, 4 Dec 2020 at 17:18, Richard Biener wrote:
> >
> > On Fri, 4 Dec 2020, Prathamesh Kulkarni wrote:
> >
> > > On Thu, 3 Dec 2020 at 16:35, Richard Biener wrote:
> > > >
> > &
On Mon, 7 Dec 2020, Prathamesh Kulkarni wrote:
> On Mon, 7 Dec 2020 at 13:01, Richard Biener wrote:
> >
> > On Mon, 7 Dec 2020, Prathamesh Kulkarni wrote:
> >
> > > On Fri, 4 Dec 2020 at 17:18, Richard Biener wrote:
> > > >
> > &
On Thu, 10 Dec 2020, Dinar Temirbulatov wrote:
> Hi,
> I have observed that STV2 pass added ~20% on CPU2006 456.hmmer with mostly
> by transforming V4SI operations. Looking at the pass itself, it looks like
> it might be transformed into RTL architecture-independent, and the pass
> deals only not
t; > >
> > > > On Mon, 7 Dec 2020 at 16:15, Hongtao Liu wrote:
> > > > >
> > > > > On Mon, Dec 7, 2020 at 5:47 PM Richard Biener
> > > > > wrote:
> > > > > >
> > > > > > On Mon, 7 Dec 2020, Prathamesh
On December 23, 2020 2:29:48 PM GMT+01:00, "Martin Liška"
wrote:
>On 12/23/20 11:49 AM, FX via Gcc wrote:
>> Hi all,
>>
>> The gcc 10.2 release was 5 months ago today. A lot has happened in
>the gcc-10 branch since, in particular on aarch64. Could a new release
>be issued? It would make efforts
Status
==
GCC trunk which eventually will become GCC 11 is nearing the
end of Stage 3 which will happen on Jan 17th which is when
Stage 4 starts (aka regression and documentation fixes only).
We have accumulated quite a number of regressions, where
P1 classified regressions should be fixed
Status
==
GCC trunk which eventually will become GCC 11 is now in
regression and documentation fixes only mode (Stage 4).
Please help triaging and fixing regressions to make a timely
release of GCC 11 possible.
Quality Data
Priority # Change from last report
-
Status
==
GCC trunk which eventually will become GCC 11 is still in
regression and documentation fixes only mode (Stage 4).
If history should repeat itself then a first release candidate
of GCC 11 will be released mid April. For this to happen
we need to resolve the remaining 17 P1 regress
Status
==
The GCC 10 branch is open for regression and documentation fixes.
It's time to do the GCC 10.3 release and barring arrival of P1
priority regressions the plan is to do a release candidate in
two weeks, around Mar 31th with a release following a week later.
Please see to backport reg
On Wed, 24 Mar 2021, guojiufu wrote:
> On 2021-03-24 15:55, Richard Biener wrote:
> > On Wed, Mar 24, 2021 at 3:55 AM guojiufu wrote:
> >>
> >> On 2021-03-23 16:25, Richard Biener via Gcc wrote:
> >> > On Tue, Mar 23, 2021 at 4:33 AM guojiufu
> >&
On Wed, 24 Mar 2021, guojiufu wrote:
> On 2021-03-24 20:33, Richard Biener wrote:
> > On Wed, 24 Mar 2021, guojiufu wrote:
> >
> >> On 2021-03-24 15:55, Richard Biener wrote:
> >> > On Wed, Mar 24, 2021 at 3:55 AM guojiufu wrote:
> >> >>
> &
The GCC 10 branch is now frozen in preparation for the GCC 10.3 release
which will see a first release candidate built soon.
All changes from now on require release manager approval.
Status
==
The GCC 10 branch is frozen for the release of GCC 10.3 with
a first release candidate published. All changes require
release manager approval.
Quality Data
Priority # Change from last report
--- ---
P1
The first release candidate for GCC 10.3 is available from
https://gcc.gnu.org/pub/gcc/snapshots/10.3.0-RC-20210401/
ftp://gcc.gnu.org/pub/gcc/snapshots/10.3.0-RC-20210401/
and shortly its mirrors. It has been generated from git commit
892024d4af83b258801ff7484bf28f0cf1a1a999.
I have so far
On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou
wrote:
>> I have so far bootstrapped and tested the release candidate on
>> x86_64-linux. Please test it and report any issues to bugzilla.
>
>It does not build for Windows:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567582.html
On April 4, 2021 10:26:37 PM GMT+02:00, Christophe Lyon
wrote:
>On Thu, 1 Apr 2021 at 14:35, Richard Biener wrote:
>>
>>
>> The first release candidate for GCC 10.3 is available from
>>
>> https://gcc.gnu.org/pub/gcc/snapshots/10.3.0-RC-20210401/
>> ftp
Status
==
GCC 10.3.0 tarballs have been generated and uploaded and the
GCC 10 branch is again open for regression and documentation fixes.
Quality Data
Priority # Change from last report
--- ---
P1
P2
The GNU Compiler Collection version 10.3 has been released.
GCC 10.3 is a bug-fix release from the GCC 10 branch
containing important fixes for regressions and serious bugs in
GCC 10.2 with more than 178 bugs fixed since the previous release.
This release is available from the FTP servers listed
Status
==
GCC trunk which is to become GCC 11 is in regression and documentation
fixes only mode. We're nearing the date planned for branching and
releasing GCC 11 but as usual the goal is to have zero release blockers
(aka P1 priority regressions) before doing so.
Please help in addressin
On June 5, 2015 9:06:01 PM GMT+02:00, Aldy Hernandez wrote:
>The debug-early work has been merged into mainline.
>
>There is a known Ada failure which Eric B. knows about and approved,
>and
>for which there is an appropriate FIXME note in the Ada sources:
>
>+FAIL: gnat.dg/specs/debug1.ads scan-a
On June 7, 2015 5:03:30 PM GMT+02:00, Aldy Hernandez wrote:
>On 06/06/2015 05:49 AM, Andreas Schwab wrote:
>> Bootstrap fails on aarch64:
>>
>> Comparing stages 2 and 3
>> warning: gcc/cc1objplus-checksum.o differs
>> warning: gcc/cc1obj-checksum.o differs
>> warning: gcc/cc1plus-checksum.o differ
On June 7, 2015 6:00:05 PM GMT+02:00, Aldy Hernandez wrote:
>On 06/07/2015 11:25 AM, Richard Biener wrote:
>> On June 7, 2015 5:03:30 PM GMT+02:00, Aldy Hernandez
> wrote:
>>> On 06/06/2015 05:49 AM, Andreas Schwab wrote:
>>>> Bootstrap fails on aarch64:
&
On Thu, Jun 4, 2015 at 1:17 PM, Thomas Koenig wrote:
> Hello world,
>
> Assume I want to calculate a dot product,
>
> s = sum(a[i]*b[i], i=1..n)
>
> The order of summation in this case should be arbitrary.
>
> Currently, the way to do this is to write out an explicit loop
> (either by by the user
On Mon, Jun 8, 2015 at 10:05 AM, Eric Botcazou wrote:
> Hi,
>
> I'd like to propose merging the scalar-storage-order branch that I have been
> maintaining for a couple of years into mainline. Original announcement at:
> https://gcc.gnu.org/ml/gcc/2013-05/msg00249.html
>
> It implements an attri
On Tue, Jun 9, 2015 at 12:33 PM, Jakub Jelinek wrote:
> On Tue, Jun 09, 2015 at 12:17:49PM +0200, Eric Botcazou wrote:
>> > How is this represented in DWARF?
>>
>> This is not represented on the branch, because this cannot be done in pure
>> DWARF. DW_AT_endianity only applies to base types or st
On Tue, Jun 9, 2015 at 12:39 PM, Eric Botcazou wrote:
>> What's the reason to not expose the byte swapping operations earlier, like
>> on GIMPLE? (or even on GENERIC?)
>
> That would be too heavy, every load and store in GENERIC/GIMPLE would have an
> associated byte swapping operation, although
On Tue, Jun 9, 2015 at 1:12 PM, Eric Botcazou wrote:
>> Yes, but I'd expect them to be optimized away (well, hopefully).
>
> OK, but you cannot reasonably expose everything in GENERIC/GIMPLE, for example
> the mask-and-shift operations to extract bitfields in reverse SSO, only the
> RTL expander h
The GCC 4.8 branch is now frozen for preparing of a release candidate for
GCC 4.8.5. All changes to the branch require release manager approval
from now on.
I'll announce the GCC 4.8.5 release candidate once it is ready.
The first release candidate for the last release from the GCC 4.8
branch, GCC 4.8.5, is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8.5-RC-20150614
and shortly its mirrors.
I have so far bootstrapped and tested the release candidate
on x86_64-unknown-linux-gnu. Please test it and repo
Status
==
I plan to release GCC 5.2.0 around July 10th which means a release
candidate being done around July 3rd.
Please check your open regression bugs for ones that eligible for
backporting. Also please help getting the P1 bug count to zero
(there is still the ARM aligned argument passin
I am rolling the GCC 4.8.5 release right now, the branch is now closed.
Richard.
The GNU Compiler Collection version 4.8.5 has been released.
GCC 4.8.5 is the fifth bug-fix release containing important fixes for
regressions and serious bugs in GCC 4.8.4 with more than 82 bugs fixed
since the previous release. This is also the last release from the
GCC 4.8 branch, GCC continu
On Thu, Jun 25, 2015 at 7:03 PM, Jeff Law wrote:
> On 06/09/2015 10:20 AM, Eric Botcazou wrote:
>>>
>>> Because some folks don't want to audit their code to where to add
>>> byteswaps.
>>> I am serious people have legacy big-endian code they want to run little
>>> endian. There is a reason this is
On Thu, Jun 25, 2015 at 10:44 PM, Jeff Law wrote:
> On 06/25/2015 12:28 PM, Richard Sandiford wrote:
>>
>> Sorry in advance for inviting a bikeshed discussion, but while making
>> the hashing changes that I just committed, I noticed that the C++ification
>> has been done in a variety of different
we do, and
> I've added a -Wabi warning for the field alignment change.
>
> Does this make sense to you?
Yes, that makes sense to me.
Richard.
> Jason
>
>
--
Richard Biener
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham
Norton, HRB 21284 (AG Nuernberg)
On Thu, 2 Jul 2015, Matthew Wahab wrote:
> On 22/06/15 12:56, Richard Biener wrote:
> >
> > I plan to release GCC 5.2.0 around July 10th which means a release
> > candidate being done around July 3rd.
> >
> > Please check your open regression bugs for ones
On Thu, Jul 2, 2015 at 5:57 PM, Armin Rigo wrote:
> Hi all,
>
> I implemented support for %fs and %gs segment prefixes on the x86 and
> x86-64 platforms, in what turns out to be a small patch.
>
> For those not familiar with it, at least on x86-64, %fs and %gs are
> two special registers that a us
On Fri, Jul 3, 2015 at 3:10 PM, Vineet Gupta wrote:
> Hi,
>
> I have the following test case (reduced from Linux kernel sources) and it
> seems
> gcc is optimizing away the first loop iteration.
>
> arc-linux-gcc -c -O2 star-9000857057.c -fno-branch-count-reg --save-temps -mA7
>
> --->8--
On Mon, Jul 6, 2015 at 7:30 AM, Vineet Gupta wrote:
> On Friday 03 July 2015 07:15 PM, Richard Biener wrote:
>> On Fri, Jul 3, 2015 at 3:10 PM, Vineet Gupta
>> wrote:
>>> Hi,
>>>
>>> I have the following test case (reduced from Linux kernel sources) an
The GCC 5 branch is now frozen for the release of GCC 5.2, all changes
require release manager approval from now on.
I will shortly announce a first release candidate for GCC 5.2.
Previous Report
===
https://gcc.gnu.org/ml/gcc/2015-06/msg00202.html
The first release candidate for GCC 5.2 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/5.2.0-RC-20150707
and shortly its mirrors. It has been generated from SVN revision 225500.
I have sofar bootstrapped the release candidate on
{i586,ia64,ppc,ppc64,x86_64,aarch64}-suse-linux-gnu.
Ple
On Wed, Jul 8, 2015 at 8:52 AM, Bin.Cheng wrote:
> Hi,
> Function fill_always_executed_in_1 computes basic blocks' always
> executed information, and it has below code and comment:
>
> /* In a loop that is always entered we may proceed anyway.
> But record that we entered it and
On Wed, Jul 8, 2015 at 12:01 PM, Bin.Cheng wrote:
> On Wed, Jul 8, 2015 at 5:58 PM, Bin.Cheng wrote:
>> On Wed, Jul 8, 2015 at 5:51 PM, Richard Biener
>> wrote:
>>> On Wed, Jul 8, 2015 at 8:52 AM, Bin.Cheng wrote:
>>>> Hi,
>>>> Function fill_al
On Wed, Jul 8, 2015 at 4:46 PM, Ajit Kumar Agarwal
wrote:
> All:
>
> While/For ( condition1)
> {
>Some code here.
> If(condition2 )
> continue;
> Some code here.
> }
>
> Fig(1)
>
> For the above loop in Fig(1) there will be two backedges and multiple
> latches. The below code can be
On Tue, Jul 7, 2015 at 10:55 PM, Abe wrote:
> [Alan wrote:]
>
>> My understanding is that any decision as to whether one or both of y or z
>> is evaluated (when 'evaluation' involves doing any work,
>> e.g. a load), has already been encoded into the gimple/tree IR. Thus, if
>> we are to only evalu
On Fri, Jul 3, 2015 at 11:37 AM, Alan Lawrence wrote:
> Abe wrote:
>
>> In other words, the problem about which I was concerned is not going to be
>> triggered by e.g. "if (c) x = ..."
>> which lacks an attached "else x = ..." in a multithreaded program without
>> enough locking just because 'x'
On Thu, Apr 9, 2015 at 9:52 AM, Richard Biener
wrote:
> On Wed, Apr 8, 2015 at 5:14 PM, James Greenhalgh
> wrote:
>> On Thu, Apr 02, 2015 at 04:20:06AM +0100, Ekanathan, Saravanan wrote:
>>> (I had sent this mail to gcc-help a week ago. Not sure, all GCC developers
>>&
1 - 100 of 2613 matches
Mail list logo
