http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47608
Summary: libstdc++ links to bad libgcc_s on OS X (libgcc_s
rebuilt needlessly and incorrectly)
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47608
--- Comment #1 from Pierre Ossman 2011-02-04 18:12:26
UTC ---
Created attachment 23246
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23246
Hackish workaround
This is what I've done here to workaround the problem. Compiles fine, but I
haven
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47609
Summary: libstdc++ depends on libgcc_s.10.5 but gets linked to
libgcc_s.10.4
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083
--- Comment #11 from Pierre Ossman ---
Created attachment 30419
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30419&action=edit
main.c
We've also been hitting this, so here is a reduced test case to provoke the
bug. Output in the failing ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083
--- Comment #12 from Pierre Ossman ---
Created attachment 30420
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30420&action=edit
Makefile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083
--- Comment #13 from Pierre Ossman ---
This was tested using gcc 4.7.2 and gcc 4.5.3.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48881
Pierre Ossman changed:
What|Removed |Added
CC||ossman at cendio dot se
--- Comment #4
--- Comment #2 from ossman at cendio dot se 2010-02-09 09:35 ---
Like so:
/usr/sparc-sun-solaris2.10/bin/gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.4.3/configure --prefix=/usr --mandir=/usr/share/man
--target=sparc-sun-solaris2.10
--with
--- Comment #3 from ossman at cendio dot se 2010-02-09 09:36 ---
Btw, my workaround for now is to remove the binaries in
/usr/sparc-sun-solaris2.10/bin and replace them with symlinks as gcc will
resolve any symlinks before trying to determine its runtime prefix.
--
http
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
Pierre Ossman changed:
What|Removed |Added
CC||ossman at cendio dot se
--- Comment #28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
--- Comment #30 from Pierre Ossman ---
(In reply to Dominique d'Humieres from comment #29)
> I can reopen the PR, but I don't see the point:
> (1) I can reproduce the problem only on x86_64-apple-darwin10 with gcc
> version 4.4.7
> (I get 'CAUGHT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
--- Comment #32 from Pierre Ossman ---
(In reply to Jack Howarth from comment #31)
>
> You might check out the original posting on this issue...
>
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html
>
I believe that was on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
--- Comment #33 from Pierre Ossman ---
Created attachment 35198
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35198&action=edit
Remove unwinder on OS X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955
Pierre Ossman changed:
What|Removed |Added
CC||ossman at cendio dot se
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955
--- Comment #9 from Pierre Ossman ---
(In reply to Andreas Schwab from comment #5)
> was added in 2.5.32.
>
> https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/
> ?id=ea5097be4e814a2a9457e60653052306295941e8
How can it be mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955
--- Comment #11 from Pierre Ossman ---
Not really. :)
I stumbled upon this trying to use 2.4 headers, so I honestly haven't tried
2.6.9, RHEL variant or otherwise.
Priority: P3
Component: plugins
Assignee: unassigned at gcc dot gnu.org
Reporter: ossman at cendio dot se
Target Milestone: ---
The GCC_ENABLE_PLUGINS macro references the variables gcc_cv_nm and
gcc_cv_objdump which will not be set outside of gcc/configure
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ossman at cendio dot se
When compiling a C program for ARM Linux, you can easily end up with
dependencies on libgcc_s. This is very annoying as it is not how other targets
behave and it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60428
--- Comment #1 from Pierre Ossman ---
Created attachment 32266
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32266&action=edit
patch to weaken unwind symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60428
--- Comment #2 from Pierre Ossman ---
Created attachment 32267
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32267&action=edit
test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60428
--- Comment #3 from Pierre Ossman ---
Comments?
ormal
Priority: P3
Component: libobjc
Assignee: unassigned at gcc dot gnu.org
Reporter: ossman at cendio dot se
The configure script for libobjc tries to determine if the compiler is using
setjmp/longjmp (SJLJ) for exception handling. But it does this by checking the
output o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64051
--- Comment #3 from Pierre Ossman ---
libstdc++ compiles fine though, but the previous stage did indeed include a C++
compiler. But even with that requirement, it still seems a bit dangerous. What
if the previous compiler uses a different excepti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64051
--- Comment #4 from Pierre Ossman ---
I assumed that this would be what happened:
Given --build=B --host=H and --target=T:
1. A gcc would be configured with --build=B --host=H --target=T and put in the
installation directory.
2. A second gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64051
--- Comment #6 from Pierre Ossman ---
Just to make sure I understand you perfectly. This is not supported:
../configure --build=A --host=B --target=B
Instead you have to do:
../configure --build=A --host=A --target=B
Then use that to:
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ossman at cendio dot se
Target Milestone: ---
As the summary states, you will get bitten by bug 41260 if you happen to
specify -nodefaultlibs or -nostdlib as -no_compact_unwind is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66587
--- Comment #1 from Pierre Ossman ---
Created attachment 35802
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35802&action=edit
possible patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66587
--- Comment #2 from Pierre Ossman ---
Note that darwin12.h also exists on trunk that needs to be modified as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991
Pierre Ossman changed:
What|Removed |Added
CC||ossman at cendio dot se
--- Comment #19
ils to find cc1
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ossman at cendio dot se
http://gcc.gnu.org/bugzilla/
Assignee: unassigned at gcc dot gnu.org
Reporter: ossman at cendio dot se
Target Milestone: ---
Some programs designed for clang want this flag. I'm unsure exactly how
important it is. The description sounds like it's just some optimization.
To make things worse, it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743
--- Comment #2 from Pierre Ossman ---
Great news. And that is the same thing as clang's -fconstant-cfstrings?
Unfortunately, I couldn't see -mconstant-cfstrings in gcc's documentation, but
I may be looking in the wrong place.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743
--- Comment #4 from Pierre Ossman ---
I am indeed trying to compile for macOS. Specifically Qt5, which is designed
with just Xcode in mind.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743
--- Comment #5 from Pierre Ossman ---
Could you consider adding -fconstant-cfstrings as an alias? It would make life
easier for making build systems compiler agnostic.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ossman at cendio dot se
Target Milestone: ---
Created attachment 57857
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57857&action=edit
Test case
We are looking at bringing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114571
--- Comment #1 from Pierre Ossman ---
Hmm.. I found bug 77513, and r9-873. So I guess this is intentional?
This makes the warning somewhat pointless. We want to make sure developers
standardise on nullptr, both for style and since the behaviour
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ossman at cendio dot se
Target Milestone: ---
g++ complains about the following code when -Wzero-as-null-pointer-constant is
given:
> enum { ZERO, ONE, TWO };
>
> e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114571
--- Comment #2 from Pierre Ossman ---
Found another case that neither gcc 5, gcc 13, nor clang complain about for
some odd reason:
> assert(thing == NULL);
All three complain about:
> assert(thing == 0);
Not sure what's going on here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114573
--- Comment #2 from Pierre Ossman ---
Indeed. It is part of an effort to have a more modern C++ style in TigerVNC.
One item was preferring nullptr over NULL, and this issue became an obstacle
there.
Right now, we did a #pragma, but if there is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114571
--- Comment #3 from Pierre Ossman ---
And another odd case; gcc 5 complains about this:
> const char *a;
> a = NULL;
but not:
> const char *a = NULL;
gcc 13 complains about neither, and clang about both.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ossman at cendio dot se
Target Milestone: ---
A templated method has this protection in it to check that a given argument is
a subclass:
template
Object::method(void (*callback)(T*))
{
if (dynamic_cast(this) == nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115664
--- Comment #6 from Pierre Ossman ---
Is there a cleaner way to can work around this than duplicating the affected
methods? I tried adding a #pragma, but that breaks older versions of gcc that
don't have -Wnonnull-compare.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115664
--- Comment #9 from Pierre Ossman ---
Thank you! That worked nicely!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114571
--- Comment #5 from Pierre Ossman ---
That may be, but -Wzero-as-null-pointer-constant is documented as facilitating
conversion to "nullptr", which means it definitely should be complaining about
NULL, since that might not be the same thing.
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56556
Pierre Ossman changed:
What|Removed |Added
CC||ossman at cendio dot se
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78147
Pierre Ossman changed:
What|Removed |Added
CC||ossman at cendio dot se
--- Comment #9
46 matches
Mail list logo
