ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
The following program
```
#include
#include
struct uuid
{
std::uint8_t data[ 16 ] = {};
};
struct __attribute__((packed)) X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #19 from Peter Dimov ---
This should work.
I still don't understand why JF so insisted on all these padding shenanigans.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #13 from Peter Dimov ---
(In reply to Andrew Pinski from comment #10)
> #if __cplusplus >= 201402L && __has_builtin(__builtin_clear_padding)
> if _GLIBCXX17_CONSTEXPR (__atomic_impl::__maybe_has_padding<_Tp>())
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #11 from Peter Dimov ---
So, basically, C++14 and above initialize the padding of
```
std::atomic state{{ 0, 0x }};
```
in `main` to zero, which masks the problem in `generate`. (The problem in
`generate` still exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #9 from Peter Dimov ---
Oh, my mistake. C++14 does mov QWORD, and C++11 does mov WORD.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #8 from Peter Dimov ---
(In reply to Andrew Pinski from comment #6)
> No it is dependent on the standard level. C++11 fails but C++14, C++17 and
> C++20 all pass.
That's interesting because I see basically no difference in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #4 from Peter Dimov ---
This
https://raw.githubusercontent.com/boostorg/uuid/feature/gcc_pr_114865/test/test_gcc_pr114865.cpp
exhibits the problem for me on GCC 13/14. I'm only seeing the hang with
-std=c++11 -m32 in the CI run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #2 from Peter Dimov ---
The issue is also present for GCC 14 on Ubuntu 24.04:
https://github.com/boostorg/uuid/actions/runs/8853249656/job/24313667955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #1 from Peter Dimov ---
> The problem may well be inside libatomic, of course; I have no way to tell.
Narrator: but he did, in fact, have a way to tell.
This is a GHA run with GCC 9 to 13 tested on both Ubuntu 23.04 and Ubuntu
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
I'm getting weird hangs on Github Actions when using
`std::atomic::compare_exchange_strong` under GCC 13 on Ubuntu
++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
The following code
```
#include
#include
template auto bind( M T::* pm, A a )
{
return [=]( auto&& x ) -> M const& { return x.*pm; };
}
template struct arg {};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113200
--- Comment #4 from Peter Dimov ---
I didn't notice your subsequent comment, sorry. :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113200
--- Comment #3 from Peter Dimov ---
I think that the compiler is correct; string literal address comparisons aren't
constant expressions. Clang gives the same error:
https://godbolt.org/z/xPWEf4z63.
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
```
#include
#include
template struct S
{
char data_[ N ];
using traits_type = std::char_traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #10 from Peter Dimov ---
Maybe the right thing to do is to use dynamic_cast only for virtual inheritance
(either have a trait or check whether static_cast isn't a valid expression),
otherwise static_cast, in both cases (standard and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #7 from Peter Dimov ---
You don't necessarily need dynamic_cast because facets are always installed and
obtained by their exact type, not via a reference to base. You can store the
Facet* as given (like shared_ptr does), and return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86355
--- Comment #14 from Peter Dimov ---
Should I open another bug for the failure to compile the original example?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110476
--- Comment #2 from Peter Dimov ---
Discussion of FLT_EVAL_METHOD notwithstanding, I think that this behavior is
not allowed by https://eel.is/c++draft/lex.fcon#3.
"If the scaled value is not in the range of representable values for its type,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #8 from Peter Dimov ---
As I commented on the duplicate bug, I don't think this behavior is allowed by
https://eel.is/c++draft/lex.fcon#3.
"If the scaled value is not in the range of representable values for its type,
the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
--- Comment #13 from Peter Dimov ---
I think that https://eel.is/c++draft/lex.fcon#3 disagrees.
"If the scaled value is not in the range of representable values for its type,
the program is ill-formed. Otherwise, the value of a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #6 from Peter Dimov ---
I suppose this is unfixable because there's all sorts of code assuming that the
value of (long double)3.14 is 3.14L and not (long double)(double)3.14L.
I doubt that anyone sane expects this from (long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #3 from Peter Dimov ---
That's true, but the normal expectation of anyone using
-fexcess-precision=standard would be for it to apply consistently everywhere
(that is, as if FLT_EVAL_METHOD is 0.)
Of course given that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110476
--- Comment #1 from Peter Dimov ---
As discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742, this is a
consequence of applying the FLT_EVAL_METHOD=2 rules, and can be fixed by
casting 3.14f to (float).
That's... incredibly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #1 from Peter Dimov ---
Looks like a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
and is fixed by casting the rhs to (float), but any ordinary programmer would
be baffled.
For context, I encountered this
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
The following program
float f( float x, int y )
{
return x + y;
}
int main()
{
return f( 3.14f, 1 ) == 3.14f + 1;
}
returns different values with -std=c++XX
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
The following program
#define STATIC_ASSERT(...) static_assert(__VA_ARGS__, #__VA_ARGS__)
struct X
{
float f;
};
int main()
{
constexpr X x{ 3.14f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110096
--- Comment #13 from Peter Dimov ---
Even if we assume that WFE on lock (and SEV on unlock) is the correct approach
on ARM instead of YIELD (though this seems very much domain-specific, depending
on the expected amount of contention and who
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110096
--- Comment #9 from Peter Dimov ---
I don't think I want WFE here, based on what I read about it. Putting the core
to sleep seems like something to do in an embedded system where I have full
control of what cores do, not something to do on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110096
--- Comment #7 from Peter Dimov ---
These intrinsics are typically used in spinlocks as in
```
while( flag_.test_and_set() )
{
// issue a power-saving NOP here
}
```
(where `flag_` is `std::atomic_flag`) and this use is generic and not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110096
--- Comment #5 from Peter Dimov ---
This works for the specific case of ARM, even though I don't find it
substantially better than just using `asm("yield")`, but the benefit of having
a portable intrinsic for this functionality is that as such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110096
--- Comment #3 from Peter Dimov ---
How does the user know when to include `arm_acle.h`?
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
This is more of a feature request than a bug.
Currently `__builtin_ia32_pause()` only applies to Intel/AMD
++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
We are investigating a Boost.Unordered performance regression with GCC 12,
on the following benchmark:
https://github.com/boostorg/boost_unordered_benchmarks/blob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108952
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108836
--- Comment #4 from Peter Dimov ---
A compromise between no mutex at all, and a mutex that is silently a no-op,
could be a no-op mutex with [[deprecated]] members, although the atomic_flag is
probably better.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108836
--- Comment #2 from Peter Dimov ---
That's good to hear, but I don't think the issue is specific to mingw32. The
other report, https://github.com/boostorg/system/issues/92, was about "B
PLC", whatever this means. :-)
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
We've been getting reports in Boost that our uses of and std::mutex
don't work in a single-threaded build of libstdc++, so we had to add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100157
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #9 from Peter Dimov ---
The easiest way to reproduce the issue is with the following test:
https://github.com/boostorg/smart_ptr/blob/c577d68b0272fd0bddc88ea60a8db07219391589/test/spinlock_test.cpp
This crashes because -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105545
--- Comment #9 from Peter Dimov ---
My Godbolt link above no longer reproduces the warning because of
https://github.com/boostorg/describe/commit/c8c46bfdf78022a8a7e9e06983d8b04ccb921991,
but this one does: https://godbolt.org/z/oT1M31osa.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105545
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #7
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
bool eq( char const* p )
{
return __builtin_memcmp( p, "literal", 7 ) == 0;
}
generates
eq(char const*):
cmp DWORD PTR [rdi], 1702127980
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102168
--- Comment #6 from Peter Dimov ---
Yes, I suppose you're right. The warning warns that Derived _can be_ deleted
via Base*, and that's correct - if not very useful in practice in this specific
case.
In fact the private destructor case is even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102168
--- Comment #4 from Peter Dimov ---
Warning on a private destructor + a friend declaration makes sense, because a
private destructor implies that the type is not intended to be derived from.
But warning on a protected destructor + a friend does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102168
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #1
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
The current GCC trunk in C++11 or C++14 mode gives an error when including
boost/mp11/algorithm.hpp (from Boost 1.79):
opt/compiler-explorer/libs/boost_1_79_0/boost/m
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
A benchmark in Boost.Unordered uses uint64_t keys of the form `i << 40`:
https://github.com/boostorg/unordere
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
The following program
```
enum class Foo
{
A1
};
enum class Bar
{
B1
};
template struct enum_
{
};
template struct list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104426
--- Comment #4 from Peter Dimov ---
FWIW, I agree with everything Martin Sebor says in PR71962.
-fallow-address-zero is an entirely separate feature, and shouldn't be implied
by -fsanitize=undefined.
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
The following program
```
struct category
{
constexpr bool failed() const noexcept
{
return true;
}
};
inline constexpr category s_cat;
struct condition
++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
Using f.ex. `typeid(std:pair**)` tries to instantiate
`std::pair` and fails: https://godbolt.org/z/GhbYe3P8j
(One asterisk should be enough, but doesn't work either.)
The example without pair
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
As the title says. https://godbolt.org/z/er7qsjvoo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #18 from Peter Dimov ---
I would use it like this: https://godbolt.org/z/1eqEx6678
#include
struct error_category
{
};
error_category const& system_category();
struct error_code
{
error_code( int v, error_category const&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #16 from Peter Dimov ---
(In reply to Jakub Jelinek from comment #14)
> But we haven't done that that way and how would headers know if the
> __builtin_source_location that is available is the old or new one?
The header could do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #15 from Peter Dimov ---
(In reply to Jonathan Wakely from comment #13)
> It wouldn't work correctly in all cases, as Jakub points out, because
> std::source_location::current() is part of the magic.
>
> And I'm not convinced we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #10 from Peter Dimov ---
(In reply to Jakub Jelinek from comment #9)
> That would be an aliasing violation.
> The artificial vars created by __builtin_source_location have the
> std::source_location::__impl type, so accessing those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #8 from Peter Dimov ---
(In reply to Jakub Jelinek from comment #6)
> Note, having the struct somewhere else isn't that useful unless you know
> exactly how its non-static data members are named and what they mean, so
> ideally a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #7 from Peter Dimov ---
(In reply to Jonathan Wakely from comment #5)
> Sure. It's just a question of whether we're trying to provide a general
> purpose extension available for users, or an internal helper for the
> std::lib. IIRC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #4 from Peter Dimov ---
On the surface this looks not hard to fix - use ::__source_location_impl (or
std::__source_location_impl) instead of std::source_location:__impl as the
layout struct - but I'm not sure whether this would pose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #2 from Peter Dimov ---
(In reply to Jakub Jelinek from comment #1)
> __builtin_source_location doesn't require -std=c++20, but indeed does
> require or some compatible definition of
> std::source_location::__impl class, and as it
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
Currently, `__builtin_source_location` requires (a) `` to be
included and (b) -std=c++20. Are there good reasons for these restrictions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100827
--- Comment #1 from Peter Dimov ---
Update: GCC 10.2 doesn't have the issue, but 10.1 and 10.3 do. :-)
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
I'm seeing a compiler crash with g++ 10/11 in -std=c++03 mode
https://godbolt.org/z/h4dY9oKGc
https://godbolt.org/z/o1P6nrhqG
when compiling one file from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99495
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14721
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #5
++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
Trivial jump tables where all entries are the same are sometimes not
eliminated. E.g. the following example
```
struct Base { virtual void run( float f ) = 0; };
struct T0: Base { void run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63707
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #14
++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
The code
void f( int& x, float& y )
{
++x;
y = 1;
--x;
}
compiles to
f(int&, float&):
mov eax, DWORD PTR [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92985
--- Comment #2 from Peter Dimov ---
Two more reformulations that activate the linear transformation are:
int operator[]( std::size_t i ) const noexcept
{
std::ptrdiff_t offset;
switch( i )
{
case 0:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92985
--- Comment #1 from Peter Dimov ---
Reformulating the switch in terms of integral offsets
struct X2
{
int x, y, z;
int operator[]( std::size_t i ) const noexcept
{
std::ptrdiff_t k0 = -
std::ptrdiff_t k1 = -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92005
--- Comment #2 from Peter Dimov ---
r276416 makes -O2 inline less, and -O3 does fix this specific case. However,
there appears to be some deeper issue here. I've reduced the number of cases
from 10 to 5 for the example, but when I increase them
++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
The following code:
```
template struct overloaded : Ts... { using Ts::operator()...; };
template overloaded(Ts...) -> overloaded;
struct T0 {};
struct T1 {};
struct T2 {};
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89029
--- Comment #4 from Peter Dimov ---
(In reply to Jonathan Wakely from comment #3)
> c.f. https://gcc.gnu.org/ml/libstdc++/2018-03/msg00031.html and the replies
Yes, pretty much.
> I doubt we would catch many bugs that way, as most bugs would
++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
In the following code:
```
inline bool assert_static_check( bool ev )
{
return __builtin_constant_p( ev ) && !ev;
}
struct X1
{
int v1_;
};
inline bool operator==( X1 c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87205
--- Comment #9 from Peter Dimov ---
For more context, see https://godbolt.org/z/SzfpKr
```
#include
template struct variant
{
std::aligned_union_t<0, T...> storage_;
unsigned index_;
};
template
auto visit( variant& v, F f )
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87205
--- Comment #8 from Peter Dimov ---
(In reply to Martin Liška from comment #7)
> I'm not sure here Y are different types here and member access based on
> the type is distinct.
Yes, one could argue that, I suppose. But in the `return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87205
--- Comment #5 from Peter Dimov ---
Another:
```
struct X
{
int v;
};
template struct Y: X
{
};
void f( int v );
void h( unsigned ix, void* p )
{
switch( ix )
{
case 0: f( ((Y<0>*)p)->v ); break;
case 1: f(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87205
--- Comment #4 from Peter Dimov ---
If the code is not the same the jump table is not optimized out and there's no
extra check. But it also happens with code that is not the same on the C++
side, for example:
```
struct X
{
int v;
};
++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
For the following code:
```
void f( int x );
void h( unsigned ix )
{
switch( ix )
{
case 0: f(42); break;
case 1: f(42); break;
case 2: f(42); break
iority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
The code
```
#include
template using mp_bool = std::integral_constant;
template using mp_all = mp_bool<(static_cast(T::value) &&
...)>;
templat
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
The following code
```
#include
template using mp_bool = std::integral_constant;
using mp_true = mp_bool;
template using mp_all = mp_bool
++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
The following code:
```
struct X {};
struct Y: X {};
struct Z: X {};
extern Y y;
extern Z z;
constexpr X const& x1() { return y; }
constexpr X const& x2() {
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
This code:
```
class X
{
public:
virtual ~X();
};
class Y
{
private:
class Z: public X
{
private:
Y const * p_
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
In the following code:
```
#include
#include
struct function
{
function()
{
std::cout
--- Comment #7 from pdimov at gmail dot com 2010-05-17 19:10 ---
(In reply to comment #6)
Basically the middle-end sees this the same as
int i = 1, j;
float *p = new (i) float(0.0);
j = i;
return *reinterpret_castfloat *(j);
and you expect to return 0.0.
The int/float
--- Comment #9 from pdimov at gmail dot com 2010-05-17 20:12 ---
But the standard says in [basic.types] that For any trivially copyable type T,
if two pointers to T point to distinct T objects obj1 and obj2, where neither
obj1 nor obj2 is a base-class subobject, if the underlying bytes
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pdimov at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http
--- Additional Comments From pdimov at gmail dot com 2005-05-12 08:42
---
Created an attachment (id=8871)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8871action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
90 matches
Mail list logo
