Re: Status of m32c target?
On Fri, Jan 12, 2018 at 08:02:40AM +0100, Sebastian Huber wrote: > what is the status of the m32c target? There are some open bugs that > prevent the C/C++ compiler build: > > https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&list_id=197687&product=gcc&query_format=advanced&short_desc=m32c&short_desc_type=allwordssubstr The latest posted testresults seems to be https://gcc.gnu.org/ml/gcc-testresults/2013-03/msg03028.html Segher
Re: Status of m32c target?
On 01/12/2018 07:24 AM, Segher Boessenkool wrote: > On Fri, Jan 12, 2018 at 08:02:40AM +0100, Sebastian Huber wrote: >> what is the status of the m32c target? There are some open bugs that >> prevent the C/C++ compiler build: >> >> https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&list_id=197687&product=gcc&query_format=advanced&short_desc=m32c&short_desc_type=allwordssubstr > > The latest posted testresults seems to be > https://gcc.gnu.org/ml/gcc-testresults/2013-03/msg03028.html A change in reload back in 2016 (IIRC) has effectively made m32c unusable. The limits of the register file create horrible problems for reload. I was going to suggest deprecation for gcc-8 given how badly it was broken in gcc-7 and the lack of maintenance on the target. jeff
Re: Status of m32c target?
Jeff Law writes: > I was going to suggest deprecation for gcc-8 given how badly it was > broken in gcc-7 and the lack of maintenance on the target. As much as I use the m32c target, I have to agree. I've tried many times to fix its reload problems to no avail, and just don't have time to work on gcc ports much any more.
I extracted Ast from gcc .tu file and will it be useful?
Hi! I am a beginner in compiler and I extracted Ast from the .tu files. It can be viewed in pdf format and I tested it on gcc 7.2 and 4.9.3. This is my source code. https://github.com/alapha23/Ast-Extracter_gcc Will it be useful? Or how can I make my tryout useful to the project? Thank you. Gao Zhiyuan
Unstable build/host qsorts causing differing generated target code
Quick disclaimer: I'm 100% new to GCC code and the dev process, so there are bound to be some faulty assumptions below. I recently worked on a build of gcc, x86_64-pc-linux-gnu -> x86_64-pc-linux-musl. In order to boost my confidence in musl, I decided that I'd like to ensure that 3 (and 4) stage bootstraps succeed and compare equal. I quickly ran into failed object comparisons at stage3. The issue, as it turned out, was that musl's qsort algorithm differs significantly from gcc's, though both (as far as I can tell) are perfectly legal. The c spec allows for different results in the cast of unstable arrays. So otherwise-identical gcc builds linked against differing libc's potentially produce different binaries for the target. And at least in the case of glibc/musl, I've verified that it's happening. Due to the qsorts used in the gen* build programs, I assume it's even possible for cross-compiled target code to vary based libc used by the native system compiler that builds the cross-compiler. After tracking down the issue, I set out to fix the unstable sorts. This turned out to be tricky, given the dozens or hundreds of uses of qsort in the code-base. As someone not familiar with the gcc code or typical debugging procedures, my big-hammer solution was to copy glibc's qsort implementation into musl, run both versions for every call to qsort, and assert that the resulting arrays are equal. This turned up dozens of failures, which I fixed case-by-case until a bootstrap succeeded. I then removed the patches one-by-one to narrow down exactly which ones were causing compilation differences. This ended up only being 2 small changes for trunk, 4 for 7.2.x. I will submit those to the -patches list as a follow-up. More generally, many of these unstable sorts remain, and fixing them up individually seems futile. Before working on this further, I'm wondering if it makes sense to pull a qsort into libiberty and poison the libc function. That way if unstable sorts do sneak in, at least they would be consistently unstable. Input would be much appreciated. Regards, Cory Fields
Re: Unstable build/host qsorts causing differing generated target code
On 01/12/2018 11:26 AM, Cory Fields wrote: > Quick disclaimer: I'm 100% new to GCC code and the dev process, so > there are bound to be some faulty assumptions below. > > I recently worked on a build of gcc, x86_64-pc-linux-gnu -> > x86_64-pc-linux-musl. In order to boost my confidence in musl, I > decided that I'd like to ensure that 3 (and 4) stage bootstraps > succeed and compare equal. > > I quickly ran into failed object comparisons at stage3. The issue, as > it turned out, was that musl's qsort algorithm differs significantly > from gcc's, though both (as far as I can tell) are perfectly legal. > The c spec allows for different results in the cast of unstable > arrays. THe key here is the results can differ if the comparison function is not stable. That's inherent in the qsort algorithms. But, if the comparison functions are fixed, then the implementation differences between the qsorts won't matter. Alexander Monokov has led an effort to identify cases where the comparison functions do not provide a stable ordering and to fix them. Some remain, but the majority have been addressed over the last year. His work also includes a qsort checking implementation to try and spot these problems as part of GCC's internal consistency checking mechanisms. His work is on the development trunk and will show up in the upcoming gcc-8 release. jeff
Re: Unstable build/host qsorts causing differing generated target code
On Fri, Jan 12, 2018 at 1:45 PM, Jeff Law wrote: > On 01/12/2018 11:26 AM, Cory Fields wrote: >> Quick disclaimer: I'm 100% new to GCC code and the dev process, so >> there are bound to be some faulty assumptions below. >> >> I recently worked on a build of gcc, x86_64-pc-linux-gnu -> >> x86_64-pc-linux-musl. In order to boost my confidence in musl, I >> decided that I'd like to ensure that 3 (and 4) stage bootstraps >> succeed and compare equal. >> >> I quickly ran into failed object comparisons at stage3. The issue, as >> it turned out, was that musl's qsort algorithm differs significantly >> from gcc's, though both (as far as I can tell) are perfectly legal. >> The c spec allows for different results in the cast of unstable >> arrays. > THe key here is the results can differ if the comparison function is not > stable. That's inherent in the qsort algorithms. > > But, if the comparison functions are fixed, then the implementation > differences between the qsorts won't matter. > > Alexander Monokov has led an effort to identify cases where the > comparison functions do not provide a stable ordering and to fix them. > Some remain, but the majority have been addressed over the last year. > His work also includes a qsort checking implementation to try and spot > these problems as part of GCC's internal consistency checking mechanisms. > > His work is on the development trunk and will show up in the upcoming > gcc-8 release. > > jeff Hi Jeff Thanks for letting me know about this effort. That's great news! Indeed, I ran into less of these issues on trunk. I'll go ahead and submit patches for the cases that turned up there. Regards, Cory
Re: Unstable build/host qsorts causing differing generated target code
On Fri, Jan 12, 2018 at 01:54:25PM -0500, Cory Fields wrote: > Thanks for letting me know about this effort. That's great news! > > Indeed, I ran into less of these issues on trunk. I'll go ahead and > submit patches for the cases that turned up there. The qsort checking failures are tracked in http://gcc.gnu.org/PR82407 meta bug, 8 bugs in there are fixed, 2 known ones remain. Jakub
Re: Unstable build/host qsorts causing differing generated target code
On Fri, 12 Jan 2018, Jakub Jelinek wrote:
> The qsort checking failures are tracked in http://gcc.gnu.org/PR82407
> meta bug, 8 bugs in there are fixed, 2 known ones remain.
Note that qsort_chk only catches really bad issues where the compiler
invokes undefined behavior by passing an invalid comparator to qsort;
differences between Glibc and musl-hosted compilers may remain because
qsort is not quaranteed to be a stable sort: when sorting an array {A, B} where
A and B are not bitwise-identical but cmp(A, B) returns 0, the implementation of
qsort may yield either {B, A} or {A, B}, and that may cause codegen differences.
(in other words, bootstrapping on a libc with randomized qsort has
a good chance to run into bootstrap miscompares even if qsort_chk-clean)
Alexander
Re: Unstable build/host qsorts causing differing generated target code
On Fri, 12 Jan 2018, Jeff Law wrote: > THe key here is the results can differ if the comparison function is not > stable. That's inherent in the qsort algorithms. I'm afraid 'stable' is unclear/ambiguous in this context. I'd rather say 'if the comparator returns 0 if and only if the items being compared are bitwise identical'. Otherwise qsort, not being a guaranteed-stable sort, has a choice as to how reorder non-identical items that compare equal. > But, if the comparison functions are fixed, then the implementation > differences between the qsorts won't matter. > > Alexander Monokov has led an effort to identify cases where the > comparison functions do not provide a stable ordering and to fix them. No. The qsort_chk effort was limited to catching instances where comparators are invalid, i.e. lack anti-commutativity (may indicate A < B < A) or transitivity property (may indicate A < B < C < A). Fixing them doesn't imply making corresponding qsort invocations stable. > Some remain, but the majority have been addressed over the last year. > His work also includes a qsort checking implementation to try and spot > these problems as part of GCC's internal consistency checking mechanisms. Well, currently qsort_chk only checks for validity. It could in principle check for stability, but for each unstable sort it's rather hard to analyze whether it may ultimately cause codegen changes, and as a result patches may be impossible to justify. Alexander
Re: Unstable build/host qsorts causing differing generated target code
Yes, this is the issue that I ran into.
I took the check further by asserting that if cmp(A, B) == 0,
memcmp(A, B) == 0 as well. But that''s tricky because the structure
may contain data that differs from A to B, but ultimately isn't used
after the sort. So it leads to a bunch of false-ish-positives. Though
arguably even those cases should be fixed as well.
Out of curiosity, other than bloat, what would be the downside of
using an internal sort? It would also have the benefit of allowing
more rigorous stability checks.
On Fri, Jan 12, 2018 at 2:37 PM, Alexander Monakov wrote:
> On Fri, 12 Jan 2018, Jakub Jelinek wrote:
>> The qsort checking failures are tracked in http://gcc.gnu.org/PR82407
>> meta bug, 8 bugs in there are fixed, 2 known ones remain.
>
> Note that qsort_chk only catches really bad issues where the compiler
> invokes undefined behavior by passing an invalid comparator to qsort;
> differences between Glibc and musl-hosted compilers may remain because
> qsort is not quaranteed to be a stable sort: when sorting an array {A, B}
> where
> A and B are not bitwise-identical but cmp(A, B) returns 0, the implementation
> of
> qsort may yield either {B, A} or {A, B}, and that may cause codegen
> differences.
>
> (in other words, bootstrapping on a libc with randomized qsort has
> a good chance to run into bootstrap miscompares even if qsort_chk-clean)
>
> Alexander
Re: Unstable build/host qsorts causing differing generated target code
On Fri, 12 Jan 2018, Alexander Monakov wrote: > No. The qsort_chk effort was limited to catching instances where comparators > are invalid, i.e. lack anti-commutativity (may indicate A < B < A) or > transitivity property (may indicate A < B < C < A). Fixing them doesn't > imply making corresponding qsort invocations stable. Incidentally, does it detect being invalid because of comparing A != A? (I don't know if qsort implementations ever do compare an element to itself, but I did once notice in a patch review that a comparator could have compared an element unequal to itself). -- Joseph S. Myers jos...@codesourcery.com
Re: Unstable build/host qsorts causing differing generated target code
On Fri, 12 Jan 2018, Joseph Myers wrote: > On Fri, 12 Jan 2018, Alexander Monakov wrote: > > > No. The qsort_chk effort was limited to catching instances where comparators > > are invalid, i.e. lack anti-commutativity (may indicate A < B < A) or > > transitivity property (may indicate A < B < C < A). Fixing them doesn't > > imply making corresponding qsort invocations stable. > > Incidentally, does it detect being invalid because of comparing A != A? If A appears twice at different positions in the array yes, otherwise no: qsort_chk never passes two equal pointers to the comparator. This is intentional: an earlier effort by Yuri Gribov tried to enforce reflexivity, but that caught instances where input arrays could not contain identical items. So under the assumption that qsort would never compare an element to itself, catching and fixing that wouldn't make a difference in practice - apart from complicating the comparator. Alexander
Re: Status of m32c target?
On Fri, 12 Jan 2018, Jeff Law wrote: > I was going to suggest deprecation for gcc-8 given how badly it was > broken in gcc-7 and the lack of maintenance on the target. While we're considering deprecations, what happened to the idea of setting a timescale by which cc0 targets need to be converted away from cc0 or be removed? -- Joseph S. Myers jos...@codesourcery.com
Re: Status of m32c target?
On 01/12/2018 04:07 PM, Joseph Myers wrote: > On Fri, 12 Jan 2018, Jeff Law wrote: > >> I was going to suggest deprecation for gcc-8 given how badly it was >> broken in gcc-7 and the lack of maintenance on the target. > > While we're considering deprecations, what happened to the idea of setting > a timescale by which cc0 targets need to be converted away from cc0 or be > removed? I don't think we ever really hashed through what that might look like. I'd be comfortable saying gcc-8 is the deprecation point. I know some folks won't like that (someone already said so WRT the m68k, but didn't step up to do the conversion), but I think that unless we set a point nothing is likely to happen. jeff ps. And since I maintain multiple affected ports, I'm a bit biased.
Re: Status of m32c target?
On 1/12/2018 5:16 PM, Jeff Law wrote: On 01/12/2018 04:07 PM, Joseph Myers wrote: On Fri, 12 Jan 2018, Jeff Law wrote: I was going to suggest deprecation for gcc-8 given how badly it was broken in gcc-7 and the lack of maintenance on the target. While we're considering deprecations, what happened to the idea of setting a timescale by which cc0 targets need to be converted away from cc0 or be removed? I don't think we ever really hashed through what that might look like. I'd be comfortable saying gcc-8 is the deprecation point. I know some folks won't like that (someone already said so WRT the m68k, but didn't step up to do the conversion), but I think that unless we set a point nothing is likely to happen What's the list of targets under consideration? I understand needing to deprecate targets that don't get updated. And I also know that the RTEMS community doesn't have anyone who can step up. Our collective efforts are more on the run-time side. It should be obvious that one of the reasons we remove a target from RTEMS is that the tools disappear. That would impact other OS type projects as well. FWIW I will say I considered removing BSPs for various VMEbus 68040 boards during this RTEMS release cycle. I didn't do it because multiple national labs still had 100s of these boards and used them. They still do new RTEMS software deployments to them. They would like to have newer, better hardware and do have PowerPC board (and the PowerPC has its own issues) but with a rack every 50m down a 1.5km linear accelerator, they use what they have until it breaks. That said, it shouldn't impact GCC deprecation decisions. --joel jeff ps. And since I maintain multiple affected ports, I'm a bit biased.
Re: Status of m32c target?
On Fri, Jan 12, 2018 at 05:29:29PM -0600, Joel Sherrill wrote: > What's the list of targets under consideration? Anything that still uses cc0 when the cull is made. Current targets using cc0 are: h8300, v850, cris, pdp11, vax, cr16, m68k, avr. Segher
Re: Status of m32c target?
On 1/12/2018 5:40 PM, Segher Boessenkool wrote: On Fri, Jan 12, 2018 at 05:29:29PM -0600, Joel Sherrill wrote: What's the list of targets under consideration? Anything that still uses cc0 when the cull is made. Current targets using cc0 are: h8300, v850, cris, pdp11, vax, cr16, m68k, avr. Thanks. We killed the RTEMS h8300 and avr ports but we have active v850 and m68k ports. We do not have cris, pdp11, vax and cr16 ports. --joel Segher
