http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55965
Bug #: 55965
Summary: gcc -std=c99 emits code for inline even without extern
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806
Jeremy Huddleston jeremyhu at macports dot org changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806
--- Comment #9 from Jeremy Huddleston jeremyhu at macports dot org 2012-10-05
17:47:02 UTC ---
The one build config change on MP side that accompanied the version bump was
that we now build with --enable-libstdcxx-time for
http
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806
--- Comment #13 from Jeremy Huddleston Sequoia jeremyhu at macports dot org
2012-10-06 06:38:54 UTC ---
I see this issue with older gcc47 versions that predate the bump to 4.7.2 and
addition of --enable-libstdcxx-time, specifically:
$ g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806
--- Comment #16 from Jeremy Huddleston Sequoia jeremyhu at macports dot org
2012-10-06 17:47:52 UTC ---
(In reply to comment #14)
Interestingly Macports' libgomp shows the same expected emutls related symbols
as fink...
% nm libgomp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806
--- Comment #18 from Jeremy Huddleston Sequoia jeremyhu at macports dot org
2012-10-06 19:53:25 UTC ---
(In reply to comment #17)
(In reply to comment #16)
These changes will certainly keep config.h in the libstdc++-v3 build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806
--- Comment #21 from Jeremy Huddleston Sequoia jeremyhu at macports dot org
2012-10-06 21:14:30 UTC ---
(In reply to comment #19)
(In reply to comment #18)
Note that the libgcc_ext.10.[45] are not actually needed if we're going
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806
--- Comment #22 from Jeremy Huddleston Sequoia jeremyhu at macports dot org
2012-10-06 21:15:02 UTC ---
In any event, this is a MacPorts bug for which I have a fix. This upstream bug
should be closed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
Jeremy Huddleston Sequoia jeremyhu at macports dot org changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #4 from Jeremy Huddleston Sequoia jeremyhu at macports dot org
2012-10-07 18:35:24 UTC ---
(In reply to comment #3)
As far as Darwin is concerned, simply, somebody knowing the target well has to
work out the details. So far
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #7 from Jeremy Huddleston Sequoia jeremyhu at macports dot org
2012-10-07 19:04:12 UTC ---
Yeah, Jack... your copying them and pasting them here just makes it easier for
me to accidentally read them. Please don't do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #9 from Jeremy Huddleston Sequoia jeremyhu at macports dot org
2012-10-07 19:38:18 UTC ---
(In reply to comment #8)
(In reply to comment #7)
Yeah, Jack... your copying them and pasting them here just makes it easier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #14 from Jeremy Huddleston Sequoia jeremyhu at macports dot org
2012-10-07 22:49:50 UTC ---
Your patch looks wrong to me. You should just get rid of the '#if
_POSIX_TIMERS 0' check and always use 'struct timespec' :
http
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #16 from Jeremy Huddleston Sequoia jeremyhu at macports dot org
2012-10-07 23:07:04 UTC ---
(In reply to comment #15)
Note that the autoconf test is built by the C++ compiler, thus there is no
real
difference between
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #20 from Jeremy Huddleston Sequoia jeremyhu at macports dot org
2012-10-07 23:25:54 UTC ---
(In reply to comment #18)
To repeat what I meant: the autoconf test is built by the C++ compiler. Given
that, writing 'timespec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #22 from Jeremy Huddleston Sequoia jeremyhu at macports dot org
2012-10-08 03:48:00 UTC ---
Well we'll go with it for now. I've bumped gcc48 in MacPorts using Rob's
version of the patch. I'll update gcc47 and gcc46 after
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #40 from Jeremy Huddleston Sequoia jeremyhu at macports dot org
2012-10-08 18:33:37 UTC ---
(In reply to comment #25)
N.B. prior to POSIX 2008 nanosleep was part of the Timers option, if OS X
supports that it should define
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #42 from Jeremy Huddleston Sequoia jeremyhu at macports dot org
2012-10-08 20:10:26 UTC ---
(In reply to comment #41)
(In reply to comment #40)
I still don't see why the _POSIX_TIMERS 0 check exists at all. On systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54160
Bug #: 54160
Summary: gcc should not define __OBJC2__ when lang is not set
to ObjC (gcc 4.6 and later)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: jeremyhu at macports dot org
If one builds a dylib using static libgcc.a, the libgcc symbols will be
exported by that library. One can mitigate this using an
-unexported_symbols_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268
Jeremy Huddleston Sequoia jeremyhu at macports dot org changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268
--- Comment #10 from Jeremy Huddleston Sequoia jeremyhu at macports dot org
---
Ah, gotcha. In that case, please retitle as well to indicate such. Prior to
gcc-4.5, even support via emutls was not available on darwin, so some people
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47309
Summary: gcc-4.4.5 fails to build on darwin/ppc due to issues
in boehm-gc GC_test_and_set
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: major
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55965
--- Comment #3 from Jeremy Huddleston Sequoia jeremyhu at macports dot org ---
On OSX, the _isalnum symbol corresponds to the isalnum() function and the
__isalnum symbol would correspond to the _isalnum() function. It is emitting
the _isalnum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
Jeremy Huddleston Sequoia jeremyhu at macports dot org changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #43 from Jeremy Huddleston Sequoia jeremyhu at macports dot org
---
Created attachment 33824
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33824action=edit
gcc 4.2 based patch which handles tiny version numbers properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #49 from Jeremy Huddleston Sequoia jeremyhu at macports dot org
---
(In reply to Francois-Xavier Coudert from comment #45)
(In reply to Jeremy Huddleston Sequoia from comment #42)
The committed patch is incorrect. It makes
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: jeremyhu at macports dot org
Even after the change for bug #61407, gcc is not setting up the deployment
target macro correctly. gcc always sets the tiny version to 0 which is not
always the case. For example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #50 from Jeremy Huddleston Sequoia jeremyhu at macports dot org
---
As this bug is now marked as resolved, I've filed #63810 to address the
remaining issues. Lawrence Velázquez lar...@macports.org is working on a
patch to address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810
--- Comment #1 from Jeremy Huddleston Sequoia jeremyhu at macports dot org ---
Larry said that he's working on a patch to fix this for gcc trunk, and I
suspect he's pretty close to having something since that was about a week ago.
The algorithm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848
--- Comment #16 from Jeremy Huddleston Sequoia
---
(In reply to Jack Howarth from comment #14)
> I finally got around to rebuilding the Apple open source release of
> libunwind-35.3 from 10.10.5 under Xcode 7 on 10.10.5. The results are rather
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767
--- Comment #11 from Jeremy Huddleston Sequoia
---
(In reply to Jeffrey Walton from comment #5)
># port install clang-3.8
># port install gcc6
># ln -s /opt/local/bin/clang /opt/local/bin/clang-3.8
You probably meant:
$ ln -s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767
--- Comment #12 from Jeremy Huddleston Sequoia
---
(In reply to Iain Sandoe from comment #9)
> we ought not be in a position where we detect that the ld64 is too old at
> the same time as trying to use the LLVM back end as the assembler.
It is
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jeremyhu at macports dot org
Target Milestone: ---
During a build of gcc6, libiberty fails to compile because -isysroot is not
passed to the compiler. gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
Jeremy Huddleston Sequoia changed:
What|Removed |Added
Summary|fix-includes does not honor |--with-build-sysroot= does
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jeremyhu at macports dot org
Target Milestone: ---
If gcc-6.3.0 is configured with
--with-build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
--- Comment #1 from Jeremy Huddleston Sequoia ---
And note that I'm not using --with-sysroot because I don't want this to affect
the compiler installed by 'make install', just what is used to build gcc
itself.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
--- Comment #3 from Jeremy Huddleston Sequoia ---
I'm not sure what you mean by using --prefix "instead" ... I'm using --prefix
to establish where I want the tools to be installed to.
As an example, if I wanted to install gcc to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
--- Comment #5 from Jeremy Huddleston Sequoia ---
I don't really understand what you mean by "Try --with-build-sysroot= instead."
... --with-build-sysroot= *is* being used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
--- Comment #6 from Jeremy Huddleston Sequoia ---
Got farther with the Makefile.in edit and setting of CPP and CXXCPP, but
failing now because --sysroot=... is not getting passed to xg++ during
configure-stage2-gcc:
from gcc/config.log:
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jeremyhu at macports dot org
Target Milestone: ---
Snapshot 8-20170604 (trunk r248863) builds fine on darwin.
Snapshot 8-20170611 (trunk r249106) and later (through at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80203
Jeremy Huddleston Sequoia changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #12 from Jeremy Huddleston Sequoia
---
(In reply to Francois-Xavier Coudert from comment #11)
> (In reply to Jeremy Huddleston Sequoia from comment #10)
> > Given those, gcc only builds if we have the DevSDK ("headers at /" package)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
--- Comment #9 from Jeremy Huddleston Sequoia ---
Because of this issue, gcc only builds if we have the DevSDK ("headers at /"
package) installed. That package is being provided as a workaround for any
projects that fail to build without it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #10 from Jeremy Huddleston Sequoia
---
FWIW, I don't have much power other than nagging to move along the OSS drops.
Those are managed by a process, and prioritization is given to those making
explicit requests to the OSS mailing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243
Jeremy Huddleston Sequoia changed:
What|Removed |Added
CC||jeremyhu at macports dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #13 from Jeremy Huddleston Sequoia
---
Also note that also already does the following:
/*
* Compatibility with compilers and environments that don't support compiler
* feature checking function-like macros.
*/
#ifndef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
Jeremy Huddleston Sequoia changed:
What|Removed |Added
CC||jeremyhu at macports dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
--- Comment #13 from Jeremy Huddleston Sequoia
---
1. clang honors $SDKROOT from the environment if it is not passed via -isysroot
on the command line. That's all gcc needs to do, and then users running 'xcrun
gcc' would ge this behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #15 from Jeremy Huddleston Sequoia
---
(In reply to John Marshall from comment #14)
> [In reply to Jeremy Huddleston Sequoia in comment #12]
>
> In the future, please file radars for these problems and ping me directly if
> you
50 matches
Mail list logo
