GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode
Status == GCC 8 is in regression and documentation fixes stage now similar as if trunk was a release branch. We're still in pretty bad shape regression-wise. Please also take the opportunity to check the state of your favorite host/target combination to make sure building and testing works appropriately. Quality Data Priority # Change from last report --- --- P1 36 + 27 P2 133 - 1 P3 57 - 51 P4 158 - 3 P5 27 --- --- Total P1-P3 226 - 25 Total 411 - 28 Previous Report === https://gcc.gnu.org/ml/gcc/2018-01/msg00033.html
Re: Status of m32c target?
On 13/01/18 00:16, 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. How much work is it to convert the m68k to LRA. Is this person days, weeks, months or years? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Status of m32c target?
On Mon, 15 Jan 2018, Sebastian Huber wrote: > On 13/01/18 00:16, 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. > > How much work is it to convert the m68k to LRA. Is this person days, weeks, > months or years? My understanding is that moving away from cc0 is much more work than moving to LRA once you've moved away from cc0 (both moves are desirable to modernize a port, the move away from cc0 needs to be done first). But I don't have any more specific estimates. https://gcc.gnu.org/wiki/CC0Transition https://gcc.gnu.org/wiki/LRAIsDefault -- Joseph S. Myers jos...@codesourcery.com
Re: Status of m32c target?
On 01/15/2018 05:46 AM, Joseph Myers wrote: On Mon, 15 Jan 2018, Sebastian Huber wrote: On 13/01/18 00:16, 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. How much work is it to convert the m68k to LRA. Is this person days, weeks, months or years? My understanding is that moving away from cc0 is much more work than moving to LRA once you've moved away from cc0 (both moves are desirable to modernize a port, the move away from cc0 needs to be done first). But I don't have any more specific estimates. https://gcc.gnu.org/wiki/CC0Transition https://gcc.gnu.org/wiki/LRAIsDefault Based on my experience with Nios II last summer, enabling LRA is easy, but it exposes missing patterns/constraints in the machine description that the old reload let you get away with. The nastiest type of these problems is where LRA thinks it has to do a bogus memory spill, which doesn't get fully optimized away again afterwards; tests still pass, but there's a code size regression. :-( So I think "how much work" is hard to quantify or predict in general. -Sandra
Re: Status of m32c target?
On Mon, Jan 15, 2018 at 01:39:43PM +0100, Sebastian Huber wrote: > On 13/01/18 00:16, 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. > > How much work is it to convert the m68k to LRA. Is this person days, > weeks, months or years? Converting m68k to cc0 is a daunting task. This is a prerequisite to enabling LRA, as mentioned. As Sandra says, switching to LRA is easy in principle, and for simple targets that is all really. For more complex and unusual targets you run into situations LRA does not yet handle. Also, debugging LRA is its own set of skills. Segher
Re: Status of m32c target?
On 1/15/2018 11:31 AM, Segher Boessenkool wrote: On Mon, Jan 15, 2018 at 01:39:43PM +0100, Sebastian Huber wrote: On 13/01/18 00:16, 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. How much work is it to convert the m68k to LRA. Is this person days, weeks, months or years? Converting m68k to cc0 is a daunting task. This is a prerequisite to enabling LRA, as mentioned. I don't know if the Coldfire changes things but my recollection is that all the m68xxx instructions you expect to modify %sr do so. That doesn't make the task smaller but at least the m68k proper is simpler CISC as described in the linked page. As Sandra says, switching to LRA is easy in principle, and for simple targets that is all really. For more complex and unusual targets you run into situations LRA does not yet handle. Also, debugging LRA is its own set of skills. I know the m68k is an ugly beast with many years of architectural evolution from m68000 to m68060 and then all the Coldfire variants. It is one of the machine description files[1]. And I don't think there are free simulators already in use for testing it. But I **think** Sebastian is trying to figure out if this is something he can do or if we (RTEMS, GCC, etc communities) can fund from m68k and Coldfire users. Assuming this discussion isn't enough to chase the embedded users to another architecture. Old school folks keeping Amiga alive are a different animal Is cc0 conversion enough to get m68k off the chopping block? [1] Interestingly, the sparc, arm, powerpcspe, rs6000, and i386 are all larger .md files. The i386 is 2.5 times larger. --joel Segher
Re: Status of m32c target?
On 01/15/2018 11:11 AM, Joel Sherrill wrote: > > > On 1/15/2018 11:31 AM, Segher Boessenkool wrote: >> On Mon, Jan 15, 2018 at 01:39:43PM +0100, Sebastian Huber wrote: >>> On 13/01/18 00:16, 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. >>> >>> How much work is it to convert the m68k to LRA. Is this person days, >>> weeks, months or years? >> >> Converting m68k to cc0 is a daunting task. This is a prerequisite to >> enabling LRA, as mentioned. > > I don't know if the Coldfire changes things but my recollection is that > all the m68xxx instructions you expect to modify %sr do so. That > doesn't make the task smaller but at least the m68k proper is simpler > CISC as described in the linked page. Coldfire doesn't change anything in a significant way from an architectural standpoint WRT cc0. THe only impact was that there's more patterns that have to be audited and converted. > > I know the m68k is an ugly beast with many years of architectural > evolution from m68000 to m68060 and then all the Coldfire variants. > It is one of the machine description files[1]. And I don't think there > are free simulators already in use for testing it. I've actually wondered if starting from scratch with an eye towards just the 060, Coldfires and an emulated target would be easier. Drop the 68000, 010, 020, 030, 040, and some of the old embedded mmu-less parts I've forgotten. The reason I mention an emulated target is aranym which does system level simulation of the m68k -- enough you can boot debian, bootstrap gcc and do all the usual things -- and on a reasonably modern system it's faster than any m68k hardware that was ever built. For that target I strongly suspect you'd throw away all the micro-architectural crap and optimize strictly for # of instructions that have to be fetched -- the fetch & dispatch loop likely dominates over actual simulation of the instruction from a performance standpoint. > > But I **think** Sebastian is trying to figure out if this is something > he can do or if we (RTEMS, GCC, etc communities) can fund from m68k > and Coldfire users. Assuming this discussion isn't enough to chase > the embedded users to another architecture. Old school folks keeping > Amiga alive are a different animal > > Is cc0 conversion enough to get m68k off the chopping block? I would think so for this round. I suspect there'd be another round in the future to convert to LRA, but I suspect that'd be *much* smaller. > > [1] Interestingly, the sparc, arm, powerpcspe, rs6000, and i386 are > all larger .md files. The i386 is 2.5 times larger :-) Jeff
Re: Status of m32c target?
On Mon, Jan 15, 2018 at 11:28:25AM -0700, Jeff Law wrote: > > Is cc0 conversion enough to get m68k off the chopping block? > I would think so for this round. I suspect there'd be another round in > the future to convert to LRA, but I suspect that'd be *much* smaller. Yeah. And converting to LRA is a more gradual change: you can support both LRA and old reload at the same time (with an -mlra switch). Segher
Re: Status of m32c target?
Jeff Law writes:
> 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.
I gave this another shot Friday, I was thinking maybe we could retire
the m32cm cpu and keep the r8c cpu, since the M32C family is essentially
dead part-wise but there are still new R8C chips being made.
The reload problems for r8c are still there, but I also discovered a bug
in the m32cm cpu that might be generic...
Are there any other targets that push large structures on the call stack
via memcpy? I'm seeing failures due to mis-calculating stack
adjustments in that case.
$ m32c-elf-gcc -c -mcpu=m32cm -O3 dj.c
typedef struct {
void *a, *b, *c, *d;
void *e, *f, *g;
} cookie_io_functions_t;
void *_impure_ptr;
void *
_fopencookie_r (void *ptr, void *cookie, const char *mode,
cookie_io_functions_t functions);
void *
fopencookie ( void *cookie , const char *mode , cookie_io_functions_t functions)
{
return _fopencookie_r ( _impure_ptr , cookie, mode, functions);
}
dj.c: In function ‘fopencookie’:
dj.c:16:10: internal compiler error: in expand_call, at calls.c:4426
return _fopencookie_r ( _impure_ptr , cookie, mode, functions);
^~~
printf("%x %x, %d %d %d\n", flags, ECF_NORETURN, old_stack_allocated,
stack_pointer_delta, pending_stack_adjust);
/* Verify that we've deallocated all the stack we used. */
gcc_assert ((flags & ECF_NORETURN)
|| (old_stack_allocated
== stack_pointer_delta - pending_stack_adjust));
IIRC when this happens, "stack_pointer_delta" doesn't account for the
size of the large-structure-argument - it has all the push'd args, but
not the memcpy'd one. I.e. that printf I added prints this:
0 8, 0 12 40
Bugzilla timing out
I'm having trouble bringing up bugs or updating them. Has anyone else noticed Bugzilla (and/or other services running on gcc.gnu.org) being very slow or timing out? Thanks Martin
Re: Bugzilla timing out
On Mon, 15 Jan 2018, Martin Sebor wrote: > I'm having trouble bringing up bugs or updating them. Has > anyone else noticed Bugzilla (and/or other services running > on gcc.gnu.org) being very slow or timing out? I'm presuming this comes from the read errors on sdi that I just reported to overseers (if reads keep having to fail / time out before the RAID gives up on sdi and reads the data from another disk in the RAID instead). [710507.350074] sd 0:2:8:0: [sdi] CDB: Read(10): 28 00 07 e0 1c 50 00 00 08 00 [710507.350301] end_request: I/O error, dev sdi, sector 132127824 [710507.529984] md/raid:md3: read error corrected (8 sectors at 132125776 on sdi1) [710507.530346] md/raid:md3: read error corrected (8 sectors at 132125784 on sdi1) [710507.530704] md/raid:md3: read error corrected (8 sectors at 132125792 on sdi1) etc. -- Joseph S. Myers jos...@codesourcery.com
Re: Bugzilla timing out
On Mon, Jan 15, 2018 at 12:58 PM, Joseph Myers wrote: > On Mon, 15 Jan 2018, Martin Sebor wrote: > >> I'm having trouble bringing up bugs or updating them. Has >> anyone else noticed Bugzilla (and/or other services running >> on gcc.gnu.org) being very slow or timing out? > > I'm presuming this comes from the read errors on sdi that I just reported > to overseers (if reads keep having to fail / time out before the RAID > gives up on sdi and reads the data from another disk in the RAID instead). > > [710507.350074] sd 0:2:8:0: [sdi] CDB: Read(10): 28 00 07 e0 1c 50 00 00 08 00 > [710507.350301] end_request: I/O error, dev sdi, sector 132127824 > [710507.529984] md/raid:md3: read error corrected (8 sectors at 132125776 on > sdi1) > [710507.530346] md/raid:md3: read error corrected (8 sectors at 132125784 on > sdi1) > [710507.530704] md/raid:md3: read error corrected (8 sectors at 132125792 on > sdi1) > It took a long time to do "svn ci". -- H.J.
Copyright assignment form
Hello GCC maintainer, Our team at Qualcomm Datacenter Technologies, Inc. is interested in contributing patches to the upstream GCC compiler project. To get the process started, we'd like to request a copyright assignment form as per contribution guidelines outlined at https://gcc.gnu.org/contribute.html. Please let me know if there are additional steps we need to take to become an effective contributor to the GCC community. Thanks, Shahid
Local class name conflict
Hello all,
I encountered a problem on "local class name conflict",
I searched on net and found that years ago, some people also encoutered this
kind of problem.
https://stackoverflow.com/questions/10671956/same-class-name-in-different-c-files
http://www.cplusplus.com/forum/general/32010/
Please see the following code, (BTW, it seems that the maillist can not attach
files)
When I ran the code(Ubuntu 64bis, gcc vesion:5.4.0, the amazing result is :
localClassXInData.cpp in Data.cpp
localClassXInData.cpp in Data.cpp
I think there is an error in Link phrase:
1. if comment out the LocalClassX definition in main.cpp, the compile will not
compile the code --- this is as expected.
2. however, if run the code(not comment out any code), the code actually ran is
in the Data.cpp, that is not consistent with compile phase.
Thanks!
code
//~
// main.cpp
//~
#include
#include
#include
using namespace std;
class LocalClassX
{
public:
string name;
LocalClassX() {
name = "localClassXInMain.cpp" ;
}
virtual ~LocalClassX() {
}
virtual void f() {
printf("%s in main.cpp \n ", name.c_str());
}
};
#include "Data.h"
Data data;
int main(int argc, char* argv[])
{
try {
LocalClassX x;
x.f();
data.add(1);
}
catch (...) {
printf("error \n");
return 1;
}
return 0;
}
//~~
// Data.h"
//~~
#ifndef DataH
#define DataH
#include
#include
using namespace std;
class Data {
protected:
vector data;
public:
Data();
virtual ~Data();
void add(int i);
};
#endif
//~~
// Data.cpp
//~~
#include
#include "Data.h"
Data::Data()
{
}
Data::~Data()
{
}
class LocalClassX
{
public:
string name;
LocalClassX() {
name = "localClassXInData.cpp" ;
}
virtual ~LocalClassX() {
}
virtual void f() {
printf("%s in Data.cpp \n ", name.c_str());
}
};
void Data::add(int i)
{
LocalClassX x;
x.f();
data.push_back(i);
}
Re: Local class name conflict
On Mon, Jan 15, 2018 at 10:35 PM, chenzhelu wrote:
> Hello all,
> I encountered a problem on "local class name conflict",
> I searched on net and found that years ago, some people also encoutered this
> kind of problem.
The correct name for this is One Definition Rule (or ODR for short).
Basically a violation of this rule causes the code to be invalid (with
no diagnostic required; therefor undefined code). If you use LTO, GCC
sometimes will warn about this violation.
If you want a truly local class, then use anonymous namespaces which
is designed to fix this issue.
Thanks,
Andrew
>
> https://stackoverflow.com/questions/10671956/same-class-name-in-different-c-files
> http://www.cplusplus.com/forum/general/32010/
>
>
> Please see the following code, (BTW, it seems that the maillist can not
> attach files)
>
> When I ran the code(Ubuntu 64bis, gcc vesion:5.4.0, the amazing result is :
> localClassXInData.cpp in Data.cpp
> localClassXInData.cpp in Data.cpp
>
>
> I think there is an error in Link phrase:
> 1. if comment out the LocalClassX definition in main.cpp, the compile will
> not compile the code --- this is as expected.
> 2. however, if run the code(not comment out any code), the code actually ran
> is in the Data.cpp, that is not consistent with compile phase.
>
>
> Thanks!
>
>
> code
> //~
> // main.cpp
>
> //~
> #include
> #include
>
> #include
> using namespace std;
>
> class LocalClassX
> {
> public:
> string name;
>
> LocalClassX() {
> name = "localClassXInMain.cpp" ;
> }
>
> virtual ~LocalClassX() {
> }
>
> virtual void f() {
> printf("%s in main.cpp \n ", name.c_str());
> }
> };
>
> #include "Data.h"
> Data data;
>
> int main(int argc, char* argv[])
> {
> try {
> LocalClassX x;
> x.f();
> data.add(1);
> }
> catch (...) {
> printf("error \n");
> return 1;
> }
> return 0;
> }
>
>
> //~~
> // Data.h"
> //~~
> #ifndef DataH
> #define DataH
>
> #include
> #include
> using namespace std;
>
>
> class Data {
> protected:
> vector data;
> public:
> Data();
> virtual ~Data();
>
> void add(int i);
> };
>
> #endif
>
>
> //~~
> // Data.cpp
>
> //~~
>
> #include
>
> #include "Data.h"
>
> Data::Data()
> {
> }
> Data::~Data()
> {
> }
>
> class LocalClassX
> {
> public:
> string name;
>
> LocalClassX() {
> name = "localClassXInData.cpp" ;
> }
>
> virtual ~LocalClassX() {
> }
>
> virtual void f() {
> printf("%s in Data.cpp \n ", name.c_str());
> }
> };
>
> void Data::add(int i)
> {
> LocalClassX x;
> x.f();
>
> data.push_back(i);
> }
>
Re:Re: Local class name conflict
On 2018-01-16 14:45, Andrew Pinski wrote: On Mon, Jan 15, 2018 at 10:35 PM, chenzhelu wrote: Hello all, I encountered a problem on "local class name conflict", I searched on net and found that years ago, some people also encoutered this kind of problem. The correct name for this is One Definition Rule (or ODR for short). Basically a violation of this rule causes the code to be invalid (with no diagnostic required; therefor undefined code). If you use LTO, GCC sometimes will warn about this violation. Thanks for suggestion! Yes, this test code is intent to create local classes with same name, for a small project, it's easy to find out this error, consider a big project... The root cause is, it's possible that two local classes with same name in a namespace, (or the default anonymous namespace), I know that it violate with ODR, however, the point is, it seems that compiler is somehow not consistent in the Compile and Link phase, that's what I confused of. If you want a truly local class, then use anonymous namespaces which is designed to fix this issue. This will rely on human to keep local class name unique within a namspace, or the default anonymous namespace. consider a project with hundreds of files, as a precise software, I think it'd better not allow this undefined hehavior open, whether the compile better give some warning/error on this name conflicts, or link with the "nearest" local class ? Thanks, Andrew
