[Bug bootstrap/61315] New: wide-int.cc cannot be built by darwin system compiler

[Bug bootstrap/61315] New: wide-int.cc cannot be built by darwin system compiler

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315

            Bug ID: 61315
           Summary: wide-int.cc cannot be built by darwin system compiler
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fxcoudert at gcc dot gnu.org

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).

[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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.

[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |NEW
   Last reconfirmed|                            |2014-05-26
         Resolution|INVALID                     |---
     Ever confirmed|0                           |1

--- Comment #2 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
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.

[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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.

[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315

--- Comment #4 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
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?

[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler

[howarth at nitro dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315

Jack Howarth <howarth at nitro dot med.uc.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |howarth at nitro dot med.uc.edu

--- Comment #5 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
(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.

[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler

[howarth at nitro dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315

--- Comment #6 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
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.

[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315

--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
A patch has been posted at
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02173.html.

[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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.

[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler

[howarth at nitro dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315

--- Comment #9 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
(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.

[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler

[mrs at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315

mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrs at gcc dot gnu.org
         Resolution|INVALID                     |DUPLICATE

--- Comment #10 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> ---
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 ***

[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #11 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(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.
>From gcc-bugs-return-452671-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 28 08:21:20 2014
Return-Path: <gcc-bugs-return-452671-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31500 invoked by alias); 28 May 2014 08:21:19 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 31460 invoked by uid 48); 28 May 2014 08:21:14 -0000
From: "mcree at orcon dot net.nz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/61336] New: ICE on alpha: in print_operand_address, at config/alpha/alpha.c:5454
Date: Wed, 28 May 2014 08:21:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mcree at orcon dot net.nz
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cf_gcctarget attachments.created
Message-ID: <bug-61336-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg02363.txt.bz2
Content-length: 3109

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61336

            Bug ID: 61336
           Summary: ICE on alpha: in print_operand_address, at
                    config/alpha/alpha.c:5454
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mcree at orcon dot net.nz
            Target: alpha

Created attachment 32869
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32869&action=edit
Failing preprocessed source being malloc/malloc.c from glibc

ICE noted with Debian gcc-4.8.3 and now verified with trunk when compiling
malloc.c from glibc on alpha.  Preprocessed source attached.

/home/mjc/toolchain/gcc-build/./gcc/xgcc -B/home/mjc/toolchain/gcc-build/./gcc/
ccjDEL1Z.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wwrite-strings
-fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes
-mlong-double-128 -mieee -mfp-rounding-mode=d  -fpic
In file included from malloc.c:1878:0:
arena.c: In function ‘ptmalloc_unlock_all2’:
arena.c:303:33: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
arena.c:313:25: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
In file included from malloc.c:1878:0:
arena.c: In function ‘_int_new_arena’:
arena.c:768:24: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
malloc.c: In function ‘__libc_mallopt’:
malloc.c:4833:1: internal compiler error: in print_operand_address, at
config/alpha/alpha.c:5468
0x120a110cf print_operand_address(_IO_FILE*, rtx_def*)
    ../../gcc.git/gcc/config/alpha/alpha.c:5468
0x1206b3aa7 default_print_operand_address(_IO_FILE*, rtx_def*)
    ../../gcc.git/gcc/targhooks.c:344
0x12039cc87 output_address(rtx_def*)
    ../../gcc.git/gcc/final.c:3838
0x120a10e83 print_operand(_IO_FILE*, rtx_def*, int)
    ../../gcc.git/gcc/config/alpha/alpha.c:5345
0x1206b3a77 default_print_operand(_IO_FILE*, rtx_def*, int)
    ../../gcc.git/gcc/targhooks.c:330
0x12039cb87 output_operand(rtx_def*, int)
    ../../gcc.git/gcc/final.c:3822
0x12039d267 output_asm_insn
    ../../gcc.git/gcc/final.c:3720
0x12039ec2f output_asm_insn
    ../../gcc.git/gcc/final.c:2643
0x12039ec2f final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
    ../../gcc.git/gcc/final.c:2594
0x12039ef23 final(rtx_def*, _IO_FILE*, int)
    ../../gcc.git/gcc/final.c:2025
0x12039f533 rest_of_handle_final
    ../../gcc.git/gcc/final.c:4444
0x12039f533 execute
    ../../gcc.git/gcc/final.c:4518
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
{standard input}: Assembler messages:
{standard input}:14226: Warning: end of file in string; '"' inserted
{standard input}: Warning: .ent directive without matching .end
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
>From gcc-bugs-return-452672-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 28 08:26:37 2014
Return-Path: <gcc-bugs-return-452672-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9930 invoked by alias); 28 May 2014 08:26:37 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9463 invoked by uid 48); 28 May 2014 08:26:31 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler
Date: Wed, 28 May 2014 08:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: critical
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61315-4-MYuN8Bpgkr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61315-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61315-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg02364.txt.bz2
Content-length: 2142

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315

--- Comment #12 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(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.
>From gcc-bugs-return-452673-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 28 08:26:43 2014
Return-Path: <gcc-bugs-return-452673-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10442 invoked by alias); 28 May 2014 08:26:43 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 10052 invoked by uid 48); 28 May 2014 08:26:38 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/61123] With LTO, -fno-short-enums is ignored, resulting in ABI mis-matching in linking.
Date: Wed, 28 May 2014 08:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: lto
X-Bugzilla-Keywords: ABI, lto
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61123-4-Rs6mal26zy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61123-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61123-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg02365.txt.bz2
Content-length: 456

https://gcc.gnu.org/bugzilla/show_bug.cgi?ida123

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
It seems that Tag_ABI_PCS_wchar_t is emitted from the C-family frontends only
via config/arm/arm-c.c (as opposed to any other Tags).  Probably because
the option is c-family specific.  This code needs to move to generic handling
(the option enum is shared across all frontends, so that's not a reason to
keep it in a C specific file).

[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315

--- Comment #13 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> 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.

[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315

--- Comment #14 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(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.)
>From gcc-bugs-return-452710-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 28 11:25:53 2014
Return-Path: <gcc-bugs-return-452710-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3132 invoked by alias); 28 May 2014 11:25:53 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 3101 invoked by uid 48); 28 May 2014 11:25:50 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/61300] powerpc64le miscompile with K&R-style function definition at -O0
Date: Wed, 28 May 2014 11:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: other
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: amodra at gmail dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61300-4-pxzCOMKT0p@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61300-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61300-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg02402.txt.bz2
Content-length: 1247

https://gcc.gnu.org/bugzilla/show_bug.cgi?ida300

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Alan Modra from comment #1)
> So, the "writes way past this" is writing into the parameter save area.
>
> compare_kr is assuming that it was called with a parameter save area because
> it isn't prototyped, but that is quite wrong because when compiling the
> function body we don't know how the function was called.  A call may well
> have a prototype in scope, and thus not set up a parameter save area.
>
> It's a bug in rs6000_function_parms_need_stack.  This function can't blindly
> test !prototype_p (fun).

So you can simply drop that check instead as it seems to be an optimization
only?  Thus

Index: gcc/config/rs6000/rs6000.c
==================================================================--- gcc/config/rs6000/rs6000.c  (revision 211011)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -10492,7 +10492,7 @@ rs6000_function_parms_need_stack (tree f
     fun = TREE_TYPE (fun);

   /* Varargs functions need the parameter save area.  */
-  if (!prototype_p (fun) || stdarg_p (fun))
+  if (stdarg_p (fun))
     return true;

   INIT_CUMULATIVE_INCOMING_ARGS (args_so_far_v, fun, NULL_RTX);

?

[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315

--- Comment #15 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
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.