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.
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 #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.
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 #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
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=edit
Test case
We are looking at bringing
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.
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 #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.
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 mentioned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991
Pierre Ossman ossman at cendio dot se changed:
What|Removed |Added
CC||ossman at cendio
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66587
--- Comment #2 from Pierre Ossman ossman at cendio dot se ---
Note that darwin12.h also exists on trunk that needs to be modified as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66587
--- Comment #1 from Pierre Ossman ossman at cendio dot se ---
Created attachment 35802
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35802action=edit
possible patch
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955
--- Comment #9 from Pierre Ossman ossman at cendio dot se ---
(In reply to Andreas Schwab from comment #5)
linux/aio_abi.h was added in 2.5.32.
https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/
?id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955
Pierre Ossman ossman at cendio dot se changed:
What|Removed |Added
CC||ossman at cendio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955
--- Comment #11 from Pierre Ossman ossman at cendio dot se ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
--- Comment #32 from Pierre Ossman ossman at cendio dot se ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
--- Comment #33 from Pierre Ossman ossman at cendio dot se ---
Created attachment 35198
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35198action=edit
Remove unwinder on OS X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
--- Comment #30 from Pierre Ossman ossman at cendio dot se ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
Pierre Ossman ossman at cendio dot se changed:
What|Removed |Added
CC||ossman at cendio
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64051
--- Comment #3 from Pierre Ossman ossman at cendio dot se ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64051
--- Comment #4 from Pierre Ossman ossman at cendio dot se ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64051
--- Comment #6 from Pierre Ossman ossman at cendio dot se ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60428
--- Comment #3 from Pierre Ossman ossman at cendio dot se ---
Comments?
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60428
--- Comment #1 from Pierre Ossman ossman at cendio dot se ---
Created attachment 32266
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32266action=edit
patch to weaken unwind symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60428
--- Comment #2 from Pierre Ossman ossman at cendio dot se ---
Created attachment 32267
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32267action=edit
test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083
--- Comment #11 from Pierre Ossman ossman at cendio dot se ---
Created attachment 30419
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30419action=edit
main.c
We've also been hitting this, so here is a reduced test case to provoke the
bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083
--- Comment #12 from Pierre Ossman ossman at cendio dot se ---
Created attachment 30420
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30420action=edit
Makefile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083
--- Comment #13 from Pierre Ossman ossman at cendio dot se ---
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 ossman at cendio dot se changed:
What|Removed |Added
CC||ossman at cendio
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47608
--- Comment #1 from Pierre Ossman ossman at cendio dot se 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
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
--- 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
--- 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
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/show_bug.cgi?id
40 matches
Mail list logo
