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&b
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&bu
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 o
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.
G
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
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
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
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 h
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 compa
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 c
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-positiv
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 correspondin
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 <
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
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
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 h
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
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
18 matches
Mail list logo
