https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115274
--- Comment #4 from Boris Kolpackov ---
> Please try compress it.
I did try with xz -9e and it was still 1.5M (the limit is 1M). I doubt any
compression method will be able to shave those 50% off.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115274
--- Comment #2 from Boris Kolpackov ---
Ok, I couldn't attach the source file due to size limits, but you can get it
from https://sqlite.org/download.html . I get this warning with the latest
version, which is 3.46.0 at the time of this
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
Compiled attached sqlite3.c from recent SQLite release with GCC 14 and -O3
produces the following bogus (according to our analysis) warning:
$ gcc-14 -O3 -c sqlite3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86441
--- Comment #5 from Boris Kolpackov ---
Sorry, somehow I missed the request for more information.
This is happening on the first PLUGIN_OVERRIDE_GATE callback call. I looked
thought the GCC source code and it appears free_lang_data happens on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86358
--- Comment #3 from Boris Kolpackov ---
Still the case as of GCC 14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106852
--- Comment #4 from Boris Kolpackov ---
FWIW, this project contains a subset of module interface files that
(reportedly) can be used to build a (probably incomplete) `std` module with
`libstdc++` using Clang (the README says it requires
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
Created attachment 58185
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58185=edit
Reproducer
With the attached module interf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113400
--- Comment #2 from Boris Kolpackov ---
Created attachment 57084
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57084=edit
Reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113400
--- Comment #1 from Boris Kolpackov ---
Created attachment 57083
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57083=edit
Reproducer
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
We are getting this ICE since upgrading to 13.2.1.
$ g++ --version
g++ (GCC) 13.2.1 20231205 (Red Hat 13.2.1-6
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
[Submitting this on behalf of a build2 user who is still waiting for the
bugzilla login[1].]
GCC 12,13,14 all have compilation errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110213
--- Comment #1 from Boris Kolpackov ---
Created attachment 55304
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55304=edit
reproducer
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
I have a call that, AFAICS, doesn't involve any binding of references to
temporaries but which nevertheless still produces this warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532
Boris Kolpackov changed:
What|Removed |Added
CC||boris at kolpackov dot net
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
The static module mapper format (-fmodule-mapper=[?], as described
here[1] and implemented in c++tools/resolver.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109534
--- Comment #7 from Boris Kolpackov ---
BTW, my understanding of the rationale for the original patch (the one that
forces -fno-directives-only) is to paper over some underlying issue with
-fdirectives-only when used on .S files, potentially
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109534
--- Comment #6 from Boris Kolpackov ---
> The documentation says specifically-fdirectives-only is ignored if
> -fpreprocessed is supplied.
Hm, that's not how it works, IME. Specifically, just "-fpreprocessed" means the
source code is fully
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109534
--- Comment #4 from Boris Kolpackov ---
Thanks for the link to the patch submission though I find the
"-fdirectives-only option is incompatible with assembly" statement puzzling.
> So from what I understand this part is what you want:
>
> -
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
I've noticed that -fdirectives-only has no effect when preprocessing
assembler-with-cpp files. Instead, one always get a fully preprocessed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84583
Boris Kolpackov changed:
What|Removed |Added
Version|10.2.0 |12.2.0
--- Comment #2 from Boris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107555
--- Comment #6 from Boris Kolpackov ---
I was under the impression that only something runnable would be useful, but if
all that's need is a preprocessed translation unit, then that's no problem at
all. I've also attached the translation unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107555
--- Comment #5 from Boris Kolpackov ---
Created attachment 53850
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53850=edit
Preprocessed translation unit with workaround
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107555
--- Comment #4 from Boris Kolpackov ---
Created attachment 53849
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53849=edit
Preprocessed translation unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107555
--- Comment #2 from Boris Kolpackov ---
There is a way to reproduce it but it requires building the actual source code
rather than a minimal reproducer. It's not that difficult. Should I provide the
instructions?
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
I have a fairly complex function (nested loops, try-catch blocks, etc) that on
throwing an exceptions tries to destroy a stack object
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
With GCC 10 when trying to extract dependency information with -MG we get
diagnostics if the input file does not exist:
$ g++-10 -M -MG /tmp/no-such-file.cxx
g++-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64234
Boris Kolpackov changed:
What|Removed |Added
CC||boris at kolpackov dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101978
Boris Kolpackov changed:
What|Removed |Added
CC||boris at kolpackov dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98417
--- Comment #3 from Boris Kolpackov ---
I also no longer see this with GCC 12.0.1 20220421.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 98760, which changed state.
Bug 98760 Summary: [modules] ICE in add_module_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98760
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98760
Boris Kolpackov changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
When compiling my codebase (build2) with GCC 12 (12.0.1 20220421) the output is
littered with new bogus (AFAICS) -Wrestrict
++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
The following translation unit now (since 12.0) causes a bogus (AFAICS)
use-after-free warning:
$ cat <use-after-free.cxx
#include
template
class pointer_traits;
templ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164
Boris Kolpackov changed:
What|Removed |Added
CC||boris at kolpackov dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84583
Boris Kolpackov changed:
What|Removed |Added
Component|preprocessor|c++
Version|7.2.0
++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
Created attachment 51113
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51113=edit
reproducer
g++ -Wall -Wextra -O3 -std=c++2a -o driver.o -c -fdirectives-only driver
: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
cat <test.cxx
#include "test.hxx"
#include
int main () {}
EOF
echo -n "// no newline" >tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100115
--- Comment #2 from Boris Kolpackov ---
> I'm trying to reduce the test case to something manageable but that can take
> many hours, even days.
Right. On our side we have spent hours, even days trying to suppress this
warning (both by
++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
Created attachment 50615
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50615=edit
Reproducer
The attached translation unit produces a bogus "may be used unini
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99377
Boris Kolpackov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98760
--- Comment #2 from Boris Kolpackov ---
This still reproduces as of 11.0.1 20210304 (f3641ac70e) though the location
has changed:
hello.cxx:18:25: internal compiler error: in lookup_mark, at cp/tree.c:2403
18 | o << format_hello (n) <<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99051
--- Comment #1 from Boris Kolpackov ---
As of 11.0.1 20210304 (f3641ac70e) this no longer reproduces for me.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
A change between 11.0.0 20210217 and 11.0.1 20210304 causes an unexpected
MODULE-EXPORT request when partially
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99072
--- Comment #8 from Boris Kolpackov ---
Can confirm works for me, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98741
--- Comment #4 from Boris Kolpackov ---
Can confirm works for me, thanks!
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
cat <hello.mxx
export module hello;
import ;
export namespace hello
{
inline bool check (const std::string_v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98718
--- Comment #7 from Boris Kolpackov ---
Can confirm works for me, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99023
--- Comment #5 from Boris Kolpackov ---
Can confirm works for me, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99072
--- Comment #4 from Boris Kolpackov ---
You need to use different .ii file names on the first and second header unit
builds. Using your original command lines as a reference:
# first build of header-unit
devvm1702:45>./xg++ [...] -o 99072_a.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99072
--- Comment #2 from Boris Kolpackov ---
This has something to do with a different .ii file name the second time we
compile the header. Try to make this change to your command lines (notice .so
before .ii):
# second build of string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99050
--- Comment #2 from Boris Kolpackov ---
Can confirm now works for me, thanks!
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
With partial preprocessing (-E -fdirectives-only) compiling the same header
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
cat <hello.hxx
#pragma once
#if 1
import ;
#else
#include
#endif
void say_hello (const std::string_view& name);
EOF
g++ -std=c++2a -fmodules-ts -fmodule-head
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98882
--- Comment #8 from Boris Kolpackov ---
Done, bug 99050.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
After the fix in bug 98882 I now get an ICE (that same assert) when partially
preprocessing (-E -fdirectives-only) a TU that has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99000
--- Comment #2 from Boris Kolpackov ---
Thanks for pointing this out. Am I correct in interpreting the SUSPENDED status
as unlikely to be fixed for GCC 11?
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
Compiling the following two header units causes GCC to catch SIGSEGV in
module_state::write_define():
cat <check.hxx
#pragma once
#include
EOF
cat <hello.hxx
#
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
The following header unit import causes the "declaration conflicts with import"
error:
cat <hello.hxx
#pragma once
#includ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98882
--- Comment #6 from Boris Kolpackov ---
After this change I now get an ICE (that same assert) when partially
preprocessing (-E -fdirectives-only) a TU that has an include directive that is
translated to an import:
cat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98753
--- Comment #14 from Boris Kolpackov ---
If this cannot be fixed for 11 (and judging by the age of 54202 I feel it's not
likely), perhaps it makes sense not to enable this warning by default? Now that
C++ operator delete() is covered by this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98753
--- Comment #13 from Boris Kolpackov ---
Created attachment 50081
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50081=edit
Reproducer test-simplified.cxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98753
--- Comment #12 from Boris Kolpackov ---
Created attachment 50080
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50080=edit
Reproducer test.cxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98753
Boris Kolpackov changed:
What|Removed |Added
CC||boris at kolpackov dot net
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
I get an internal compiler error when preprocessing with -fdirectives-only an
empty translation unit:
touch test.cxx
g++ -std=c++2a -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98761
--- Comment #1 from Boris Kolpackov ---
Created attachment 50011
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50011=edit
Reproducer
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
The attached executable catches SIGSEGV when built with a module:
$ g++ -std=c++2a -fmodules-ts -x c++ -c format.mxx
$ g++ -std=c++2a -fmodules-ts -x c++ -c driver.cxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98760
--- Comment #1 from Boris Kolpackov ---
Created attachment 50009
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50009=edit
Reproducer
++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
The attached set of modules cause an internal compiler error:
c++ mxx{format}
c++ mxx{check}
c++ mxx{hello}
c++ cxx{hello}
/home/boris/work/build2/tests/modules/gcc2/bugs/x
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
Created attachment 49998
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49998=edit
Build transcript
The following simple module causes ICE/SIGSEGV:
// hello.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98718
--- Comment #1 from Boris Kolpackov ---
Perhaps this is the same bug but with a simpler reproducer (it points to the
same location):
cat
++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
It is currently 201810 while it should be 201907.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98719
--- Comment #1 from Boris Kolpackov ---
Created attachment 49991
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49991=edit
build transcript
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
Created attachment 49989
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49989=edit
build transcript
An attempt to ena
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
Created attachment 49988
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49988=edit
Reproducer
The attached set of translation un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98417
Boris Kolpackov changed:
What|Removed |Added
CC||boris at kolpackov dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86441
Boris Kolpackov changed:
What|Removed |Added
Version|8.1.0 |10.1.0
--- Comment #2 from Boris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86441
--- Comment #1 from Boris Kolpackov ---
Created attachment 44366
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44366=edit
Test case that shows the problem if compiled with ODB
For the record, a test case that triggers the error if
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
I have a GCC plugin (ODB) that calls instantiate_class_template() to
"post-instantiate" some types that haven't been in
Priority: P3
Component: plugins
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
As of GCC 8, the default plugin extension on Mac OS is .dylib. However, the
plugin machinery uses strip_off_ending() to remove
: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
Created attachment 43515
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43515=edit
reproducing source code
The attached archive contains foo.c (as w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47047
Boris Kolpackov changed:
What|Removed |Added
CC||boris at kolpackov dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77704
--- Comment #5 from Boris Kolpackov ---
For anyone interested, here is the workaround we came up with:
// A data race happens in the libstdc++ (as of GCC 7.2) implementation of the
// ctype::narrow() function (bug #77704). The issue is easily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77704
Boris Kolpackov changed:
What|Removed |Added
CC||boris at kolpackov dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268
--- Comment #13 from Boris Kolpackov ---
No, I was not aware, thanks for the pointer. I skimmed through it and I agree,
the environment variable is a bad idea. In fact, if you look at the patch that
I've proposed, it has a unified option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268
--- Comment #11 from Boris Kolpackov ---
Third revision of the patch:
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00544.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268
--- Comment #10 from Boris Kolpackov ---
Second revision of the patch:
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00379.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268
--- Comment #9 from Boris Kolpackov ---
I've proposed a different implementation (and a bit different options names)
here:
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01451.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79046
--- Comment #4 from Boris Kolpackov ---
Another question is whether GCC guarantees that its APIs (as can be used by a
plugin; e.g., AST) are binary compatible across Y.Z in GCC X.Y.Z?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #26 from Boris Kolpackov ---
> If breaking the old ABI was an option we wouldn't be in this situation in the
> first place.
By throwing the new version you are breaking the ABI. The point I was trying to
make is that maybe in this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #24 from Boris Kolpackov ---
Some more speculation/crazy ideas about the potential fix:
If just throwing the new version and forgetting about the old one is an option,
then perhaps we could "de-inherit" old from std::exception and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #21 from Boris Kolpackov ---
Speaking of possible fixes, I had this crazy idea, not sure if it is
technically possible though: what if libstdc++ throws some custom exception
that derives from both version of ios::failure? This way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #17 from Boris Kolpackov ---
> if (is >> x >> y >> z)
And what should happen in the else part of such statements?
if (is >> x >> y >> z)
...
else
throw something();
Also note that if the 'is >> x' call in the above chain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69880
--- Comment #3 from Boris Kolpackov ---
Ok, I've added support for embedding custom manifests in build2. The resulting
.exe's work as expected: custom manifest is used instead of (or in addition to)
the default one. However, with grep I can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #15 from Boris Kolpackov ---
> And I still think using exceptions in iostreams is dumb in the first place.
I am interested to hear what is your recommendation to do instead, call good()
after every IO operation?
In fact, I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69880
Boris Kolpackov changed:
What|Removed |Added
CC||boris at kolpackov dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
Boris Kolpackov changed:
What|Removed |Added
CC||boris at kolpackov dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60871
Boris Kolpackov boris at kolpackov dot net changed:
What|Removed |Added
CC||boris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48425
Summary: installed plugin headers fail to compile, include
non-existent files
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
--- Comment #44 from boris at kolpackov dot net 2010-09-02 08:23 ---
I just ran into the same issue building (native) mingw32 GCC 4.5.1 using a
x86-64 to mingw32 cross compiler. Adding -nostdinc++ to PCHFLAGS fixed this for
me as well.
I also would like to point out that when building
at gcc dot gnu dot org
ReportedBy: boris at kolpackov dot net
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
1 - 100 of 121 matches
Mail list logo
