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 sugges
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.
>
> F
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 entry
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 t
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 pac
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 figur
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 a
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 changes.html)
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:
https://lists.gnu.org/archive/html/bu
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 pa
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 (!global_opti
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 record,
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 latent
>> 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 targets
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 targets
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 of
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 pe
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 perform
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++ cod
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 -fcom
30 matches
Mail list logo
