On 12/5/19 6:18 AM, Wilco Dijkstra wrote:
> Hi,
>
> I have updated the documentation patch here and added relevant maintainers
> so hopefully this can go in soon:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00311.html
>
> I moved the paragraph in changes.html to the C section like you
On 12/5/19 2:16 AM, Martin Liška wrote:
>
>>
>> Of the ~450 packages affected I'd estimate that even with the opt-out
>> mechanism we're still going to have to fix ~100 packages immediately
>> because they don't honor the flags injection mechanisms which the
>> opt-out approach relies upon.
>
>
Hi,
I have updated the documentation patch here and added relevant maintainers
so hopefully this can go in soon:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00311.html
I moved the paragraph in changes.html to the C section like you suggested. Would
it make sense to link to the porting_to
On 12/5/19 10:16 AM, Martin Liška wrote:
I would like to mention here that key work is to report and explain that
to upstream. Only that will help for the future to reduce number of
packages
that will need the -fcommon option. That's the biggest effort in my
opinion.
For this, it would help
On 12/4/19 6:27 PM, Jeff Law wrote:
On 12/4/19 8:24 AM, Wilco Dijkstra wrote:
Hi Jeff,
I've noticed quite significant package failures caused by the revision.
Would you please consider documenting this change in porting_to.html
(and in changes.html) for GCC 10 release?
I'm not in the office
On 12/4/19 2:03 PM, Joseph Myers wrote:
> On Wed, 4 Dec 2019, Jeff Law wrote:
>
>>> So what normally happens with the numerous new warnings/errors in GCC
>>> releases? I suppose that could cause package failures too. Would it be
>>> feasible
>>> to override the options for any failing packages?
On Wed, 4 Dec 2019, Jeff Law wrote:
> > So what normally happens with the numerous new warnings/errors in GCC
> > releases? I suppose that could cause package failures too. Would it be
> > feasible
> > to override the options for any failing packages?
> Usually we're talking about a few dozen
On 12/4/19 8:24 AM, Wilco Dijkstra wrote:
> Hi Jeff,
>
>>> I've noticed quite significant package failures caused by the revision.
>>> Would you please consider documenting this change in porting_to.html
>>> (and in changes.html) for GCC 10 release?
>>
>> I'm not in the office right now, but
Hi Jeff,
>> I've noticed quite significant package failures caused by the revision.
>> Would you please consider documenting this change in porting_to.html
>> (and in changes.html) for GCC 10 release?
>
> I'm not in the office right now, but figured I'd chime in. I'd estimate
> 400-500 packages
On 11/29/19, Wilco Dijkstra wrote:
> Hi Martin,
>
>> I've noticed quite significant package failures caused by the revision.
>
> How significant? Is it mostly the common mistake of forgetting extern?
>
>> Would you please consider documenting this change in porting_to.html
>> (and in
On 11/29/19 3:43 PM, Wilco Dijkstra wrote:
How significant? Is it mostly the common mistake of forgetting extern?
Likely, I see it in at least 400 packages out of 11000 which we have
in openSUSE:Factory. Plus there are many 'nm -B' configure script
defects:
Hi Martin,
> I've noticed quite significant package failures caused by the revision.
How significant? Is it mostly the common mistake of forgetting extern?
> Would you please consider documenting this change in porting_to.html
> (and in changes.html) for GCC 10 release?
Sure, I already had a
Hello.
I've noticed quite significant package failures caused by the revision.
Would you please consider documenting this change in porting_to.html
(and in changes.html) for GCC 10 release?
Thank you
Hi Wilco,
Wilco Dijkstra wrote:
>> Testsuite fails are order “a few hundred” mostly seem to be related to
>> tree-prof
>> and vector tests (plus the anticipated scan-asm stuff, where code-gen will
>> have
>> changed). I don’t have cycles to analyse the causes right now - but that
>> gives
Hi Iain,
> for the record, Darwin bootstraps OK with the change (which is to be
> expected,
> since the preferred setting for it is -fno-common).
That's good to hear.
> Testsuite fails are order “a few hundred” mostly seem to be related to
> tree-prof
> and vector tests (plus the anticipated
On Mon, Oct 28, 2019 at 10:39 PM Iain Sandoe wrote:
>
> Wilco Dijkstra wrote:
> >>>
> >>> I suppose targets can override this decision.
> >> I think they probably could via the override_options mechanism.
> >
> > Yes, it's trivial to add this to target_option_override():
> >
> > if
Wilco Dijkstra wrote:
>>>
>>> I suppose targets can override this decision.
>> I think they probably could via the override_options mechanism.
>
> Yes, it's trivial to add this to target_option_override():
>
> if (!global_options_set.x_flag_no_common)
>flag_no_common = 0;
for the
Hi,
>> I suppose targets can override this decision.
> I think they probably could via the override_options mechanism.
Yes, it's trivial to add this to target_option_override():
if (!global_options_set.x_flag_no_common)
flag_no_common = 0;
Cheers,
Wilco
On 10/28/19 1:43 PM, Richard Biener wrote:
> On October 28, 2019 7:43:33 PM GMT+01:00, David Edelsohn
> wrote:
Has this been bootstrapped and regression tested?
>>>
>>> Yes, it bootstraps OK of course. I ran regression over the weekend,
>> there
>>> are a few minor regressions in lto due to
On October 28, 2019 7:43:33 PM GMT+01:00, David Edelsohn
wrote:
>>> Has this been bootstrapped and regression tested?
>>
>> Yes, it bootstraps OK of course. I ran regression over the weekend,
>there
>> are a few minor regressions in lto due to relying on tentative
>definitions
>> and a few
>> Has this been bootstrapped and regression tested?
>
> Yes, it bootstraps OK of course. I ran regression over the weekend, there
> are a few minor regressions in lto due to relying on tentative definitions
> and a few latent bugs. I'd expect there will be a few similar failures on
> other
On Mon, Oct 28, 2019 at 03:05:58PM +, Wilco Dijkstra wrote:
> > Has this been bootstrapped and regression tested?
>
> Yes, it bootstraps OK of course. I ran regression over the weekend, there
> are a few minor regressions in lto due to relying on tentative definitions
> and a few latent bugs.
Hi Jeff,
> Has this been bootstrapped and regression tested?
Yes, it bootstraps OK of course. I ran regression over the weekend, there
are a few minor regressions in lto due to relying on tentative definitions
and a few latent bugs. I'd expect there will be a few similar failures on
other
On 25/10/2019 16:47, Wilco Dijkstra wrote:
GCC currently defaults to -fcommon. As discussed in the PR, this is an ancient
C feature which is not conforming with the latest C standards.
The PR references C99/C11 6.9p5, but that is not a constraint. Any
violation merely renders the behaviour
On 10/25/19 9:47 AM, Wilco Dijkstra wrote:
> GCC currently defaults to -fcommon. As discussed in the PR, this is an
> ancient
> C feature which is not conforming with the latest C standards. On many
> targets
> this means global variable accesses have a codesize and performance penalty.
> This
On Sat, Oct 26, 2019 at 12:21:15PM +0100, Iain Sandoe wrote:
> Georg-Johann Lay wrote:
> > Wilco Dijkstra schrieb:
> >> GCC currently defaults to -fcommon. As discussed in the PR, this is an
> >> ancient
> >> C feature which is not conforming with the latest C standards. On many
> >> targets
Georg-Johann Lay wrote:
> Wilco Dijkstra schrieb:
>> GCC currently defaults to -fcommon. As discussed in the PR, this is an
>> ancient
>> C feature which is not conforming with the latest C standards. On many
>> targets
>> this means global variable accesses have a codesize and performance
On Fri, Oct 25, 2019 at 03:47:10PM +, Wilco Dijkstra wrote:
> GCC currently defaults to -fcommon. As discussed in the PR, this is an
> ancient
> C feature which is not conforming with the latest C standards. On many
> targets
> this means global variable accesses have a codesize and
Wilco Dijkstra schrieb:
GCC currently defaults to -fcommon. As discussed in the PR, this is an ancient
C feature which is not conforming with the latest C standards. On many targets
this means global variable accesses have a codesize and performance penalty.
This applies to C code only, C++
GCC currently defaults to -fcommon. As discussed in the PR, this is an ancient
C feature which is not conforming with the latest C standards. On many targets
this means global variable accesses have a codesize and performance penalty.
This applies to C code only, C++ code is not affected by
30 matches
Mail list logo
