Re: Removing "Severity" from New Bug form
On 12/8/2015 4:26 PM, Frédéric Buclin wrote: > Le 08. 12. 15 14:16, Jonathan Wakely a écrit : >>> Dropping it is ok I think. >> >> Yes, even for the valid "enhancement" cases a maintainer who triages >> the report could set that easily enough. > > If maintainers still use the severity field to triage bugs, then it > should not be dropped. It would be much easier to restrict the ability > to edit the severity field to users with editbugs privs (basically users > with a @gcc.gnu.org account + a few other accounts). > If the person submitting the PR gets to set the severity field, it should be dropped. If anybody sets the severity, it should be the people *doing* the triage or the person to whom the PR is eventually assigned. John
Re: Rename C files to .c in GCC source
On 1/31/2015 02:55, Jonathan Wakely wrote:
> On 30 January 2015 at 21:39, DJ Delorie wrote:
>>
>> pins...@gmail.com writes:
>>> No because they are c++ code so capital C is correct.
>>
>> However, we should avoid relying on case-sensitive file systems
>> (Windows) and use .cc or .cxx for C++ files ("+" is not a valid file
>> name character on Windows, so we can't use .c++).
>
> These files are only compiled by GCC's own build system, with GCC's
> own makefiles, so we know we invoke the C++ compiler and so the
> language isn't inferred from the file extension, and so we aren't
> relying on case-sensitive file systems.
To give a counter-perspective, having files that need to be compiled
with c++ driver having the extension ".c" gives external build systems
fits. Case in point, I'm working on bringing gcc5 into DragonFly as a
next base compiler and the make's base scripts all immediately use the c
driver for c files -- I had to apply hacks everywhere and even create
new local equivalents of "bsd.*.mk" files in some cases. (vendor
makefiles are never used by policy, new "bmake" ones have to be created
and imported -- this seems to be common to all BSD)
Even if this issue is normally hidden due to gcc's makefiles accounting
for it, having misleading file names can only cause problems.I'll
add a "+1" to the suggestion to go rename everything consistently and
accurately.
Sorry about butting in, but I thought that my recent experience with
this might be relevant to the topic.
John
Re: is it time to mass change from .c to .cc in gcc/ ?
On 4/15/2015 10:09, Richard Biener wrote: > On Wed, Apr 15, 2015 at 2:09 AM, Trevor Saunders > wrote: > I don't buy this kind of argument given that the switch to C++ has > complicated things instead of simplifying them. I've written before about how problematic having c++ files with .c extensions was for importing gcc into DragonFly's base. The system .mk files have targets based on extension (e.g. .c=.o) and it chooses cc or c++ based on those targets. We had to install difficult hacks to work around it. Honestly, mandatory renaming of the files should have been a condition of allowing c++ in the code base. e.g. "guys, if we do this, we have to rename all files requiring compilation by c++ compiler". I know you can wave this off as "we provide a build system for gcc, this isn't a valid reason" but the fact is this is counter-intuitive and confusing. I also think this should be fixed properly, and ripping off the band-aid seems reasonable to me. Regards, John
gcc 8.3 estimated release date?
Hi Guys, I guess back in July, the release of 8.3 was expected by the end of 2018. Now it's February. Is the next release of the 8 series imminent? if not, any idea when it might come? Thanks, John
Re: timeouts/malloc failures in ada tests?
On 7/7/2017 17:38, Eric Botcazou wrote: I see large numbers of timeouts in Ada tests on trunk in parallel run s (make -j96) on x86_64. Messages like the one below appear in the logs, suggesting some sort of heap corruption. I'm having trouble reproducing it outside the rest of the test suite (i.e., by just running the Ada tests by themselves) but maybe I'm doing it wrong. Unless this is a known problem I can try to pinpoint it closer if someone could share the magic spell to run just Ada tests to speed up the debugging. Is it (a known problem)? No, but regressions were recently introduced in the ACATS testsuite: === acats tests === FAIL: cb4008a FAIL: cb41001 so this could be related. Ada is not enabled by default so this is not surprising. It's OK for small changes and bug fixes, but people making extensive changes to the compiler should really consider enabling it (and it's a very good testbed). Good timing on this post! I just finished my first test build in a while using a new unwind patch for dragonfly (it moved the signal trampoline, breaking the previous unwind) and I saw these exact two failures. Even though the new patch has been in use for months, I was still thinking it caused the test failures. Thanks for piping up, Eric! :) John P.S. I'll post the dragonfly-specific unwind patch to the patches mail list later today. It's been tested internally for weeks.
Is Ada 2005 Issue AI-0157 implemented correctly in GCC 4.6.0?
This Ada 2012 amendment titled "Calling Unchecked Deallocation is illegal for zero-sized pools" has been implemented in GCC 4.6.0 recently (ada/sem_intr.adb). However, the restriction is enforced even when -gnat2005 (or -gnat95) switched are explicitly passed to gcc. Shouldn't this check only be enforced with the -gnat2012 switch? I discovered this trying to build Adacore's gprbuild_gpl_2010 package. The build fails with GCC 4.6.0 with the message "sinput.adb:808:19: deallocation from empty storage pool" The -gnat05 switch is explicitly used in the gpr settings, so I would expect AI-0157 to not be in effect. Am I wrong? Regards, John
Re: Is Ada 2005 Issue AI-0157 implemented correctly in GCC 4.6.0?
Thanks for the explanation, Robert. To be clear, it's code maintained by Adacore that has run afoul of the change. I don't believe gprbuild is part of Adacore's public repository, so I'm not quite sure how I'm supposed to obtain a version of gprbuild that will compile with GCC 4.6.0. This version was released with GNAT GPL 2010 recently, rather than separately, so I'm afraid that I'll need to wait until around July 2011 before the next release! :( Maybe a patch for gprbuild_gpl_2010 can be made available? Regards, John On 28/10/2010 15:47, Robert Dewar wrote: On 10/28/2010 9:37 AM, John Marino wrote: This Ada 2012 amendment titled "Calling Unchecked Deallocation is illegal for zero-sized pools" has been implemented in GCC 4.6.0 recently (ada/sem_intr.adb). However, the restriction is enforced even when -gnat2005 (or -gnat95) switched are explicitly passed to gcc. Shouldn't this check only be enforced with the -gnat2012 switch? I discovered this trying to build Adacore's gprbuild_gpl_2010 package. The build fails with GCC 4.6.0 with the message "sinput.adb:808:19: deallocation from empty storage pool" The -gnat05 switch is explicitly used in the gpr settings, so I would expect AI-0157 to not be in effect. Am I wrong? This is a binding interpretation, which means that it is something that should have been there all along and is reasonable to include in earlier versions, so this change is indeed deliberate and fine. If your code runs afoul of the change, you were doing erroneous things anyway.
Re: Rename unwind.h to unwind-gcc.h
On 4/16/2014 03:22, Ian Lance Taylor wrote: > On Tue, Apr 15, 2014 at 4:45 AM, Douglas B Rupp wrote: >> On 04/14/2014 02:01 PM, Ian Lance Taylor wrote: >> >> No I considered that but I think that number will be very small. Will you >> concede, in hindsight, that it would be better had the name been chosen to >> be more unique? > > No, I won't concede that. The unwind.h file provides the interface > for the C++ exception handling interface > (http://mentorembedded.github.io/cxx-abi/abi-eh.html). That interface > is implemented by several different compilers, not just GCC. The header can provide the exact same interface with a different, better file name. He's basically asking, "If you had it to do all over again, would you still call it unwind.h or would you call it something different?" It's just an academic discussion because answering yes or no changes nothing, but I think the majority of the people would give it a different file name if they could do it all over again. It's not a big concession. John
Re: Deprecate i386 for GCC 4.8?
On 12/13/2012 11:11, Richard Biener wrote: They are stuck with pre-GPLv3 GCC compilers anyway. ISTR we changed the default i?86 triple from i386 to i586 for 4.6, so we are already half-way through the deprecation. I'd say simply go ahead. Note that i386-freebsd is still listed as primary architecture though, so something has to be done about that first. Steering Commitee please? (I'd say drop *-freebsd from the list of primary/secondary archs entirely given that they are not at all happy with GPLv3 and not using still maintained compilers) Both NetBSD and DragonFly BSD use GPLv3 compilers in their base systems. FreeBSD ports have every modern version of GCC in them, nothing stops a user from building and using the latest GCC on FreeBSD (Note the ports are well maintained). FreeBSD and DragonFly (at least) have already dropped i386 support, it's an alias for i486. I don't know about NetBSD or OpenBSD. I don't speak for FreeBSD, but dropping them from Tier 1 support because they don't use a GPLv3 *BASE* compiler is a bit vindictive. John
Re: Deprecate i386 for GCC 4.8?
On 12/13/2012 12:38, David Brown wrote: On 13/12/2012 12:24, Steven Bosscher wrote: On Thu, Dec 13, 2012 at 11:43 AM, John Marino wrote: I don't speak for FreeBSD, but dropping them from Tier 1 support because they don't use a GPLv3 *BASE* compiler is a bit vindictive. FreeBSD has dropped GCC for future releases so there's no reason for it to be a primary platform. Yes there is good reason for keeping bsd targets. FreeBSD and others may be moving to llvm, or using older gcc's, for their official binary builds - but /users/ are still free to pick whatever tools they want. They are also free to download the source of FreeBSD and compile it themselves with gcc 4.8 fresh from svn. This is exactly right and what I attempted to say earlier. Also, the FreeBSD ports collection contains entries for gcc 3.4, 4.2, 4.4, 4.6, 4.7, and 4.8 (development) so the users would build from ports since gcc typically needs a few patches on *BSD. Dropping bsd as a target architecture just because the BSD distributions don't use it is a bit like dropping support for targeting windows just because Microsoft didn't use gcc to compile Windows 8. It needs to be pointed out that while the base system can be built without gcc, literally thousands of ports require GCC to build. It's still in widespread use. John
Re: Deprecate i386 for GCC 4.8?
On 12/13/2012 13:09, Steven Bosscher wrote: On Thu, Dec 13, 2012 at 12:38 PM, David Brown wrote: Dropping bsd as a target architecture just because the BSD distributions don't use it is a bit like dropping support for targeting windows just because Microsoft didn't use gcc to compile Windows 8. You're confused. Dropping something as a target is not the same as dropping it from the list of primary platforms. See http://gcc.gnu.org/gcc-4.8/criteria.html Which clause are you invoking to remove it from the primary tier list? Richard claimed "they are not at all happy with GPLv3". That's not a reason listed on your reference. He also claimed they "not using still maintained compilers" which is also clearly false. Maybe FreeBSD violates the "Primary platforms are popular systems" clause (of course "popular" is not quantified so no way to defend accusations of being not popular enough). GCC is certainly "frequently used" on FreeBSD so that's not in violation. John
Re: Deprecate i386 for GCC 4.8?
On 12/13/2012 13:32, Steven Bosscher wrote: On Thu, Dec 13, 2012 at 1:21 PM, John Marino wrote: Which clause are you invoking to remove it from the primary tier list? Richard claimed "they are not at all happy with GPLv3". That's not a reason listed on your reference. He also claimed they "not using still maintained compilers" which is also clearly false. Maybe FreeBSD violates the "Primary platforms are popular systems" clause (of course "popular" is not quantified so no way to defend accusations of being not popular enough). GCC is certainly "frequently used" on FreeBSD so that's not in violation. The "it's 386, nobody uses it" clause? I wouldn't mind if some other freebsd tripled would stay on the list, e.g. i686-freebsd. Stop being so emotional and look at the facts. Nobody is taking away your favorite toys. Everything I have said is a fact, please illustrate which statement I made seems emotional. Quote from Richard: "(I'd say drop *-freebsd from the list of primary/secondary archs entirely given that they are not at all happy with GPLv3 and not using still maintained compilers)" As you can see, the "*" means all triplets, not only i386. He has since clarified that another triplet could take its place, but not before you tried to revise what he said. Those are the facts. Some FreeBSD triplet should be on the primary tier as those tiers are defined today. If nobody disagrees with that, that part of the discussion is over.
