On i686-apple-darwin (secondary target) and x86_64-apple-darwin, GCC trunk does not bootstrap with the system compiler due 4 occurrences of this failure: ../../trunk/gcc/wide-int.cc:1274:23: error: invalid use of a cast in a inline asm context requiring an l-value: remove the cast or build with -fheinous-gnu-extensions umul_ppmm (val[1], val[0], op1.ulow (), op2.ulow ()); ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thus, either the flag should be added to the default flags, or the code should be amended (this was PR61146, but it was resolved in INVALID).
The problem is clang is saying it understands GNU C but it does not fully; if instead they would define __GNUC__ only if -fheinous-gnu-extensions is used you would not have seen this bug in first place. So again this is a bug in clang and we should not change the default options for a broken compiler.
GCC fails to build on a secondary target, with its default configuration. Wherever the bug is, does not change the fact that GCC should work around it one way or another, as it does work around many build/host/target bugs through configury. Even if a decision is made to drop darwin as a secondary target, this would remain at the very least a documentation bug. Both Marc Glisse and I suggest this is more serious than you think, so please leave it open at least til a maintainer can get a look at it.
Still does not matter, the compiler is broken and should be reported to Apple. The time for work around in broken compilers is so 90s and really should not be done. This is clang being broken and really should be fixed there instead.
This sounds a lot like believing you can build the better product by assigning "blame" to others, not by building something that works for users. I'm sorry if that's become the GCC philosophy. I'n not reopening because I don't play that game, but: honestly?
(In reply to Andrew Pinski from comment #3) > Still does not matter, the compiler is broken and should be reported to > Apple. The time for work around in broken compilers is so 90s and really > should not be done. This is clang being broken and really should be fixed > there instead. Is the object here to burn all bridges with the darwin target and leave those users only the option of using llvm based compilers as of gcc 4.10? While I realize you are all frustrated with the abandonment of post-GPLv2 tools in darwin., this action simply makes it extremely easy for Apple to depreciate their ancient gas assembler in the next Xcode for darwin14 since Apple can rightly say that FSF gcc no longer bootstraps on darwin anyway. I am certain that gas will be depreciated from some future darwin but hopefully will be replaced by a stand-alone assembler based on the clang built-in assembler. However, if FSF gcc starts to get overly self-self-rightous about the compiler details of clang, we might as well fold up our tents on the darwin target. ps Be careful what you wish for. I just updated the llvm34-3.4.1-0e package in fink to use the openmp svn trunk and a back port of the current clang-omp github based on clang 3.4. The resulting clang/clang++ compilers have excellent OpenMP performance defaulted to -fopenmp as -liomp5 rather than -lgomp. http://fink.9193.n7.nabble.com/llvm34-3-4-1-0e-and-OpenMP3-1-Validation-tt46118.html While you are still lucky that there has been little effort on a fortran llvm-based compiler, the rest is a work in rapid progress. So go ahead and dismiss that user base if that is what you desire.
I would also add that you are playing with fire here. Currently no company has a motivation to expend money or resources for fortran development on llvm as long as FSF gcc is buildable. If you start removing competing compilers from bootstrapping FSF gcc, it is much more likely that someone will fund such a llvm-based fortran compiler project. You may get some short-term satisfaction from walling off FSF-gcc from clang, the long-term outcome for the FSF gcc project might not be so happy.
A patch has been posted at https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02173.html.
(In reply to Jack Howarth from comment #5) > (In reply to Andrew Pinski from comment #3) > > Still does not matter, the compiler is broken and should be reported to > > Apple. The time for work around in broken compilers is so 90s and really > > should not be done. This is clang being broken and really should be fixed > > there instead. > > Is the object here to burn all bridges with the darwin target and leave > those users only the option of using llvm based compilers as of gcc 4.10? Well they burned a bridge with saying to the user of their front-end they support GNU C when they do not.
(In reply to Andrew Pinski from comment #8) > > Is the object here to burn all bridges with the darwin target and leave > > those users only the option of using llvm based compilers as of gcc 4.10? > > Well they burned a bridge with saying to the user of their front-end they > support GNU C when they do not. Well it is kind of late in the game to decide that this is a show-stopper for supporting any target which uses clang as the system compiler. At this point closing bug reports and refusing to even discuss a simple workaround via preprocessor statements in FSF gcc bugzilla just looks petty.
This is a duplicate of 61146. Non-technical content to gnu.misc.discuss please. *** This bug has been marked as a duplicate of bug 61146 ***
(In reply to Francois-Xavier Coudert from comment #4) > This sounds a lot like believing you can build the better product by > assigning "blame" to others, not by building something that works for users. > I'm sorry if that's become the GCC philosophy. To be a GCC dev you don't have to adhere to some kind of apple^Mgnu-fandom, and each of them may have a different opinion on a particular subject, so do not mistake the opinion of one developer for a general "GCC philosophy". There is no such thing.
(In reply to Jack Howarth from comment #6) > I would also add that you are playing with fire here. Currently no company > has a motivation to expend money or resources for fortran development on > llvm as long as FSF gcc is buildable. If you start removing competing > compilers from bootstrapping FSF gcc, it is much more likely that someone > will fund such a llvm-based fortran compiler project. You may get some > short-term satisfaction from walling off FSF-gcc from clang, the long-term > outcome for the FSF gcc project might not be so happy. Is any company spending money on GCC Fortran development? That would be awesome if it were true! I also doubt that somebody will decide to fund a whole llvm-fortran compiler instead of simply installing GCC 4.2, which should still be able to bootstrap GCC trunk. It would be a strange business decision, unless the goal was to build a proprietary compiler by leeching off volunteer unpaid developers. That would make sense then. Since you are offering advice, let me humbly offer some back to you: Why not instead of starting a confrontation with Andrew and invoking some strange-sounding threats, you propose a patch to fix the problem? That seems to me much more constructive. Moreover, you don't even need to convince Andrew (or me), you just need your patch to be approved by one of the Global Reviewers (or the maintainers responsible for that part of the compiler). See gcc/MAINTAINERS. I don't see your name in that list, perhaps it would be a good time to start the steps to add it: https://gcc.gnu.org/contribute.html BTW, having a user-base without developers coming out of that user-base is useless. If no one from apple-darwin is interested in developing GCC, then it doesn't matter how big the user base is: GCC for apple-darwin will not get developed by magic gnomes (or by people that don't even own Apple hardware). So perhaps it would be in your own interest to do a bit of recruiting in the apple-darwin camp.
> BTW, having a user-base without developers coming out of that user-base is > useless. If no one from apple-darwin is interested in developing GCC, then > it doesn't matter how big the user base is: GCC for apple-darwin will not get > developed by magic gnomes (or by people that don't even own Apple hardware). > So perhaps it would be in your own interest to do a bit of recruiting in the > apple-darwin camp. In my paranoid days I have the feeling that I don't exist on the gcc lists!-(although I am only interested by gfortran and optimization, I do what I can to keep the test suite as clean as possible for darwin: bug reports, debugging when I can, ...). Iain Sandoe may have a similar feeling too, even if he has a significant contribution in fixing darwin problem. I also acknowledge that most of the GCC developers are quite helpful and that some of them consider their duty to fix their bugs even on darwin. However I consider that comments such that "darwin is broken by design", "darwin sucks", ... are unprofessional. Last thing I want to say, I have seen several bugs blamed to drawing that were gcc bugs and also several "unfixable on darwin" features that got fixed by gcc improvements.
(In reply to Dominique d'Humieres from comment #13) > In my paranoid days I have the feeling that I don't exist on the gcc > lists!-(although I am only interested by gfortran and optimization, I do > what I can to keep the test suite as clean as possible for darwin: bug > reports, debugging when I can, ...). Iain Sandoe may have a similar feeling > too, even if he has a significant contribution in fixing darwin problem. Why is that so? Do you mean your patches aren't reviewed fast enough? There are three darwin maintainers. If you are unsatisfied with their work, I would suggest to try to approach them in private. Perhaps they will be happy to delegate some maintainership duties or suggest some way to improve communication. Patches going unreviewed is a general problem in GCC not restricted to Darwin. Nobody has found a good solution to this problem yet. > I also acknowledge that most of the GCC developers are quite helpful and > that some of them consider their duty to fix their bugs even on darwin. > However I consider that comments such that "darwin is broken by design", > "darwin sucks", ... are unprofessional. So ignore those comments. Even smart people say stupid things from time to time. Many people that write in the GCC lists (or bug reports) don't even contribute to GCC. When I started working on GCC diagnostics, many GCC devs told me that there will never be native color diagnostics. Now we have colors and the Apocalypse hasn't arrived. See also points 1 and 9 at https://gcc.gnu.org/wiki/GCC_Research about negative feedback. I think the approach of FX was exactly right: Expose your case and send a patch. If you cannot convince someone, then convince others. > Last thing I want to say, I have seen several bugs blamed to drawing that > were gcc bugs and also several "unfixable on darwin" features that got fixed > by gcc improvements. Sure. I personally think that GCC is better off supporting Darwin than not, but I wouldn't personally work on Darwin since I only care about Linux. It is only logical that people using Darwin are the ones working on it. The quality of Darwin support in GCC is only a function of the number of people working on it, not a hidden agenda, design or philosophy. (The same is true for every other language or port or part of the compiler. The only reason why Clang has better diagnostics than GCC is that there were 191 contributors to Clang last year, while I would be surprised if more than 20 people contributed to the C/C++ FEs during the same time.)
On Wed, 28 May 2014, manu at gcc dot gnu.org wrote: > Is any company spending money on GCC Fortran development? That would be awesome > if it were true! It's true for OpenACC support.