https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #16 from Vadim Zeitlin ---
(In reply to Jonathan Wakely from comment #15)
> (In reply to Jonathan Wakely from comment #14)
> > Or maybe the testcase makes invalid assumptions and isn't really measuring
> > what it thinks it's measurin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #13 from Vadim Zeitlin ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to Jonathan Wakely from comment #8)
> > Is this still an issue in 2022?
> >
> > Using a mingw-w64 cross-compiler and running under Wine I get:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578
--- Comment #12 from Vadim Zeitlin ---
Thanks for looking at this! I'm happy to hear that the problem is fixed in
11.2, but I'm probably not going to change our code anyhow, especially as we're
going to finally drop support for C++98 very soon an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578
--- Comment #10 from Vadim Zeitlin ---
There definitely was a change in behaviour in gcc 11 because I had to make this
change
https://github.com/wxWidgets/wxWidgets/commit/95c98a0b5ff71caca6654327bf341719c6587766
to avoid getting warnings with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106664
--- Comment #2 from Vadim Zeitlin ---
FWIW I think it's a rather useful warning as allocating 0 bytes is rarely
intentional, i.e. I haven't seen any false positive occurrences of this warning
in my own code. And in valarray case, it indicates a
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
The following simple example shows the problem with g++ 12, which didn't exist
with the previous versions:
% g++ -v
Using built-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578
Vadim Zeitlin changed:
What|Removed |Added
CC||vz-gcc at zeitlins dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234
--- Comment #23 from Vadim Zeitlin ---
(In reply to Eric Botcazou from comment #22)
> Thanks for reporting the problem.
Thanks a lot for fixing it so quickly!
And I've also appreciated the explanation in the commit message, it's nice to
underst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234
--- Comment #5 from Vadim Zeitlin ---
> Works fine on x86_64-linux.
Yes, I mentioned this :-/
> Can you attach preprocessed source (most developers don't have access to
> Windows)
If you can install MinGW cross-compiler and Wine, you don't ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234
--- Comment #4 from Vadim Zeitlin ---
Created attachment 50252
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50252&action=edit
Assembly output (-S)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234
--- Comment #3 from Vadim Zeitlin ---
Created attachment 50251
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50251&action=edit
File created by -fdump-tree-optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234
--- Comment #2 from Vadim Zeitlin ---
Created attachment 50250
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50250&action=edit
Compressed output of the preprocessor (-E)
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
Please see the following test case minimized by cvise:
-- &g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #19 from Vadim Zeitlin ---
(In reply to Jan Hubicka from comment #18)
> We need a reproducer to fix bugs.
Yes, of course, I understand this. I just didn't have time to make one yet,
we've literally discovered the issue only today (we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #17 from Vadim Zeitlin ---
I've just subscribed to this bug because we see bug slow downs in our project
when switching from 8.3 to 10.2 (89% slower in an important use case, 30%
slowdown more or less across the board), without any ot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94867
--- Comment #4 from Vadim Zeitlin ---
(In reply to Martin Liška from comment #3)
> It's gone since r10-3311-gff6686d2e5f797d6.
This commit is included in releases/gcc-10.1.0 tag, but I still see the warning
with the provided example when using g
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
Consider:
% cat -n gcc-null-deref.cpp
1 #include
2
3 void test()
4 {
5 std::vector p
ormal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
Consider the following test program:
% cat -n stream_ws.cpp
1 #include
2 #include
3
4 int main()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164
--- Comment #5 from Vadim Zeitlin ---
I obviously meant that it makes it unusable in my use case when I can't
guarantee that the input is bounded by this (smallish) size.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164
Vadim Zeitlin changed:
What|Removed |Added
CC||vz-gcc at zeitlins dot org
--- Comment
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Using Debian 8.2.0-9 the following code compiles without any errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87120
--- Comment #2 from Vadim Zeitlin ---
Thanks and sorry for a duplicate!
In my defence -- and just in case there is some problem that could be fixed
here -- Bugzilla search seems to be broken: I had searched for "double narrow
bool" (without quot
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
gcc 8.2.0 incorrectly (AFAICS) compiles the following program:
% cat -n init.cpp
1 double foo() { return 17.0; }
2
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
Consider the following test program:
% cat -n dtor_def_noexcept.cpp
1 struct B {
2 virtual ~B() noexcept(false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #32 from Vadim Zeitlin ---
(In reply to Martin Liška from comment #31)
> Created attachment 43781 [details]
> Partially reduced test-case
>
> I've got 120KB partially reduced test-case. Any further reduction is not
> much possible. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #28 from Vadim Zeitlin ---
(In reply to Martin Liška from comment #26)
> complete output of:
> diff -u nowarn.s warn.s
Attached, but most of it is just noise from the label renumbering due to the
extra label being created, as previou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #27 from Vadim Zeitlin ---
Created attachment 43777
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43777&action=edit
Diff between assembly generated with and without the warning options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #25 from Vadim Zeitlin ---
(In reply to Martin Liška from comment #24)
> > Please let me know if I can do anything else.
>
> Can you please attach full diff?
Sorry, diff between what and what?
> Am I correct that your native compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #23 from Vadim Zeitlin ---
Just to confirm that this is not specific to MinGW-w64, I've attached the test
case (and a preprocessed version of it) allowing to reproduce the same problem
with Linux x86_64 version of g++ 7.3 (7.3.0-12 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #22 from Vadim Zeitlin ---
Created attachment 43775
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43775&action=edit
Compressed preprocessed test case for native Linux gcc 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #21 from Vadim Zeitlin ---
Created attachment 43774
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43774&action=edit
Reduced test case showing the problem with native g++ 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #16 from Vadim Zeitlin ---
(In reply to Alexander Monakov from comment #13)
> It corresponds to
>
> if(!(!std::signbit(bourn_cast( From(0) {
> lmi_test::record_error(); };
> if(!(std::signbit(bourn_cast(-From(0) {
> l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #11 from Vadim Zeitlin ---
(In reply to Alexander Monakov from comment #8)
> Vadim, can you please check if the issue is reproducible on preprocessed
> (-E) input as well,
Yes, it is. I've actually started with the preprocessed input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #10 from Vadim Zeitlin ---
Created attachment 43770
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43770&action=edit
Compressed preprocessed test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #9 from Vadim Zeitlin ---
Another data point: I can also reproduce the problem with the native (i.e.
Linux) g++ 7.3 (Debian 7.3.0-12), although it looks slightly differently there:
all 3 of the following commands produce different obj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #6 from Vadim Zeitlin ---
(In reply to Jonathan Wakely from comment #4)
> I can't reproduce this with:
> gcc version 7.2.0 20170814 (Fedora MinGW 7.2.0-1.fc26) (GCC)
Thanks for testing! So this would seem to indicate that the proble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #3 from Vadim Zeitlin ---
(In reply to Richard Biener from comment #2)
> This looks like a GC / memory corruption issue to me. Can you check whether
> using -fchecking uncovers anything?
Using -fchecking doesn't change anything, usi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #1 from Vadim Zeitlin ---
Created attachment 43768
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43768&action=edit
Test script used with delta, also useful for testing
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
Created attachment 43767
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43767&action=edit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69777
--- Comment #4 from Vadim Zeitlin ---
Sorry, I've somehow forgot to provide the example, but here it is in its most
minimal form:
namespace {
struct AnonB {
virtual bool foo() const = 0;
virtual ~AnonB() {}
};
}
struct R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906
--- Comment #7 from Vadim Zeitlin ---
(In reply to Andrew Pinski from comment #6)
> https://gcc.gnu.org/wiki/FloatingPointMath
Yes, I've seen this, thanks. But do you think it's easily discoverable? I admit
I had even seen this page (and knew ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906
--- Comment #5 from Vadim Zeitlin ---
Yes, I did find this documentation myself in the meanwhile and I agree that
you're formally correct, just as gcc developers are formally correct in the
long discussion at #34678 (which I really wouldn't want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906
--- Comment #3 from Vadim Zeitlin ---
(In reply to Andrew Pinski from comment #1)
> You want -frounding-math
OK, thanks, this does indeed solve my immediate problem. However is it really
normal that the compiler behaviour silently (!) changes li
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
Here is a test case:
-- >8 --
#include
#include
#include
int m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79490
--- Comment #3 from Vadim Zeitlin ---
Created attachment 40727
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40727&action=edit
Compressed preprocessed source of a trivial example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79490
--- Comment #5 from Vadim Zeitlin ---
(In reply to Jonathan Wakely from comment #2)
> I can only reproduce this with -fsyntax-only, not when compiling.
Oops, you're right, really sorry about not realizing this. I was actually
testing warning gen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79490
--- Comment #4 from Vadim Zeitlin ---
I thought it would be simpler to use the URL I provided to download the real
header rather than downloading and uncompressing the attachment (it had to be
compressed due to its size), but, sure, here it is if
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
I can't provide a self-contained example showing the problem, unfortunately, it
involves a (huge) header implementing the rather popular CATCH unit testing
fram
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851
--- Comment #6 from Vadim Zeitlin ---
> One might complain that it only does this transformation when the second
> argument is a constant, not for casts of integer variables to long double.
Yes, in the light of new information, this is what thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851
--- Comment #4 from Vadim Zeitlin ---
Thanks for the explanation! I didn't realize the template function below was
smart enough to select __builtin_powil() automatically, this is quite
impressive (although it doesn't happen in my particular case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851
--- Comment #2 from Vadim Zeitlin ---
Sorry if I misunderstood but what exactly am I misinterpreting? Looking at the
code (and comment) at
https://github.com/gcc-mirror/gcc/blob/6514c52372bb36e555843b0419d71cf55eda0409/libstdc++-v3/include/c_glob
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
It looks like the `long double pow(long double, int)` overload in `` was
disabled because of the [DR
550](http://www.open
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71867
--- Comment #2 from Vadim Zeitlin ---
I'll try to add the preprocessed code a bit later, but, FWIW, I can already say
that there is no macro trickery whatsoever in this code itself.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
First of all, I'd like to say that I'm reporting this bug because it looks like
a rather bad problem in gcc to me, but I don't have any simple example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28810
Vadim Zeitlin changed:
What|Removed |Added
CC||vz-gcc at zeitlins dot org
--- Comment
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
For the reasons of compatibility with old compilers which don't define some
Windows COM interfaces in their he
: normal
Priority: P3
Component: pch
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
This problem had been previously reported in
https://gcc.gnu.org/ml/gcc-help/2011-12/msg00019.html and also
http
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20345
Vadim Zeitlin changed:
What|Removed |Added
CC||vz-gcc at zeitlins dot org
--- Comment
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
Consider the following example:
% cat -n deprdecl.cpp
1 struct S {
2
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Created attachment 33603
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33603&action=edit
Preprocessed source corresponding to the code provoking the error
% gcc -v
Using built-i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61214
Vadim Zeitlin changed:
What|Removed |Added
CC||vz-gcc at zeitlins dot org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #63 from Vadim Zeitlin 2011-04-21
14:04:37 UTC ---
(In reply to comment #61)
> (In reply to comment #59)
>
> > I review the patch, and found that we can add "-fno-keep-inline-dllexport"
> > to
> > the compiler option, and then, the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #48 from Vadim Zeitlin 2010-10-14
17:29:46 UTC ---
(In reply to comment #47)
> One should note that GCC's implementation of PCH is way different from
> MSVC's.
> So comparing with PCH is not the correct thing to do really.
I unders
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #46 from Vadim Zeitlin 2010-10-14
17:09:05 UTC ---
Another data point after having a closer look at .drectve section in all of the
files: as previously noticed, 4.4 generates "-export" directives for 180
symbols while 4.5 generates th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #45 from Vadim Zeitlin 2010-10-14
16:12:00 UTC ---
Here are the files.
Notice that about half of the size of the MSVC object file is taken by debug
information ("/Zi" option was used when compiling it) while all gcc versions
contain
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
Vadim Zeitlin changed:
What|Removed |Added
Attachment #22041|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #43 from Vadim Zeitlin 2010-10-14
16:01:55 UTC ---
Created attachment 22041
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22041
appbase.cpp file from wxWidgets compiled with MSVC 9 (a.k.a. 2008)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #42 from Vadim Zeitlin 2010-10-14
16:01:20 UTC ---
Created attachment 22040
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22040
appbase.cpp file from wxWidgets compiled with g++ 3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #40 from Vadim Zeitlin 2010-10-14
15:47:36 UTC ---
(In reply to comment #36)
> could Vadim and/or Cesar please add
> some of the object files we've been discussing as attachments to this bug
> report, so that we can all take a close l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
Vadim Zeitlin changed:
What|Removed |Added
Attachment #22037|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #38 from Vadim Zeitlin 2010-10-14
15:44:23 UTC ---
Created attachment 22038
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22038
appbase.cpp file from wxWidgets compiled with g++ 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #37 from Vadim Zeitlin 2010-10-14
15:42:59 UTC ---
Created attachment 22037
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22037
appbase.cpp file from wxWidgets compiled with g++ 4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #35 from Vadim Zeitlin 2010-10-14
15:24:57 UTC ---
(In reply to comment #34)
> (In reply to comment #33)
> > Because of this issue, I have been using GCC4.4.x, but do not want to
> > upgrade
> > to 4.5.x.
> > Why this issue can not b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #31 from Vadim Zeitlin 2010-09-27
22:42:55 UTC ---
(In reply to comment #30)
> Sorry, but I do not completely agree with this assessment. If you run
>
> objdump -h | c++filt
>
> you will see that 4.4 still generates one section per
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #29 from Vadim Zeitlin 2010-09-26
22:09:16 UTC ---
Thanks Cesar for your analysis, I was doing the same thing but you beat me to
it. Anyhow, I can confirm your results, i.e. that the increase in size is first
and foremost due to the i
--- Comment #12 from vz-gcc at zeitlins dot org 2010-04-03 18:17 ---
Actually I don't think --enable-checking=release changes anything. I've just
tried Cesar Strauss's suggestion to not use __attribute__((dllexport)) in the
code at all but use --enable-auto-import lin
--- Comment #11 from vz-gcc at zeitlins dot org 2010-04-03 17:46 ---
(In reply to comment #10)
> >And while the compilation time change alone
>
> How did you configure 4.5? Did you use --enable-checking=release ? If not
> then the compile time numbers are not compara
--- Comment #9 from vz-gcc at zeitlins dot org 2010-04-03 17:15 ---
Just to bring some more hard numbers into this discussion, I've installed both
4.4 and 4.5 (in addition to 3.4.5 which I'll use as a kind of baseline) on my
own machine (4/8 physical/logical CPUs, 8GB of RAM,
--- Comment #7 from vz-gcc at zeitlins dot org 2010-03-31 22:36 ---
(In reply to comment #6)
> My view this is a bug in how wxWidgets uses (abuses) dllexport and wanting not
> to export inline functions also.
Andrew, could you please provide a reasonable alternative to what
--- Comment #5 from vz-gcc at zeitlins dot org 2010-03-31 22:25 ---
(In reply to comment #3)
> And if the linker is taking a lot of memory, then it is a bug in the linker.
> The linker should not take much more memory for functions which are linked
> once.
Let's admit
--- Comment #2 from vz-gcc at zeitlins dot org 2010-03-31 22:04 ---
I'm sorry but is this really all you have to say about this? Granted, VS does
follow the same rule but the size of object files produced by it was twice
less than that of object files produced by gcc _before_
object files size in 4.5
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vz-gcc at zeitlins dot org
GCC host triplet
--- Comment #8 from vz-gcc at zeitlins dot org 2010-03-17 20:05 ---
Sorry for a late follow up but I've just discovered that this change broke
compilation of code using wxWidgets library with "-pedantic-errors -std=c++98"
switches because wxWidgets uses constructions such
--- Comment #2 from vz-gcc at zeitlins dot org 2008-09-06 22:41 ---
Andrew, thanks for your reply!
And yes, I realize this but unfortunately it really seems specific to something
that optimizer does and maybe something it does at the whole unit level and not
locally as even extracting
duct: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vz-gcc at zeitlins dot org
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37402
--- Comment #1 from vz-gcc at zeitlins dot org 2008-09-06 21:27 ---
I found this bug while searching for __thread-related problems and FWIW I can't
reproduce this on a very similar system with g++ 4.1.2 from Debian stable so
maybe this can be closed as fixed.
--
http://gcc.gn
en or not depending on
other errors
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vz-gcc at zeitlins dot
--- Comment #7 from vz-gcc at zeitlins dot org 2006-12-08 11:07 ---
Just for my personal education, could you please tell which target(s) pass
"char *" differently from "void *" in this context?
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26542
--- Comment #4 from vz-gcc at zeitlins dot org 2006-07-24 17:02 ---
I'd like to (probably uselessly but still) argue for reopening this bug and
removing this warning. The interpretation of the standard text is open to
questions: IMHO an "A *" pointer is a pointer to vo
--- Comment #5 from vz-gcc at zeitlins dot org 2006-02-19 16:50 ---
In reply to comment 4: I do realize that adding an initializer fixes the
problem. But what to do if the static member is an object of a class which only
has a default ctor? E.g.
enum V { V1, V2, V3 };
struct Int { Int
--- Comment #3 from vz-gcc at zeitlins dot org 2006-02-18 22:47 ---
First, thanks a lot Andrew for your lightning fast reply, this is really
amazing -- and incredibly helpful!
Second, really sorry, rereading the explicit specialization section once again
I see that I was indeed wrong
y: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vz-gcc at zeitlins dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26355
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vz-gcc at zeitlins dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26329
93 matches
Mail list logo
