Marco Correia wrote:
hi,
The following is a simplification of my problem:
struct Base { virtual void func() = 0; };
struct Derived : Base { inline void func() {...} };
Derived& d = ...;
d.func();
This last call is not being inlined. Is this normal?
Yes. The compiler cannot know that d doesn'
Michel Van den Bergh wrote:
That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu
8.10 (Intel core2 duo)
I get
stest.c: In function ‘main’:
stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2
has type ‘char[20]’
The resulting binary does not segfault but prin
Laurent GUERBY wrote:
> Just curious: is there a "portable" way to read from memory
> address zero in C code? "portable" here means likely to work
> on most compilers without exotic compile flags in 2009.
>
For C++, in *theory*, a reinterpret_cast(0) yields a pointer with
the value 0 that is not
Ian Lance Taylor wrote:
> LLVM byte code is generated by LLVM, not gcc. The question here is
> whether it is desirable to permit using LLVM to generate LLVM byte
> code and to then use GCC to turn that byte code into machine code.
> (It will not be desirable to apply the exception if GCC i
Simon Hill wrote:
> g++ doesn't seem able to match a template ctor of a template class
> where the ctor input is an internal class defined inside any template
> class.
>
> I briefly skimmed the titles of the current regression issues and I
> didn't notice any that matched this, but I'm not 100% sur
Joseph S. Myers wrote:
> On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
>
>
>> 2009/4/29 Joseph S. Myers :
>>
>>> On Wed, 29 Apr 2009, Ian Lance Taylor wrote:
>>>
>>>
* The C++ frontend warns about "while (true);" when there is no
whitespace between the ')' and the ';'.
Michael Eager wrote:
> Ian Lance Taylor wrote:
>> Michael Eager writes:
>>
>>> Is there any documentation on the contents of .eh_frame
>>> and the augmentations used? IIRC, the data describes the
>>> try blocks and the catch handlers, but I'm looking for
>>> the gory details.
>>
>> I don't know o
Richard Guenther wrote:
> On Thu, May 21, 2009 at 1:50 PM, Andreas Schwab wrote:
>
>> Ian Lance Taylor writes:
>>
>>
>>> Consider this C/C++ program:
>>>
>>> extern void **f1();
>>> void f2(const char *p) { *(const void **)f1() = p; }
>>>
>>> If I compile this program with g++ -Wcast-qual
This list is really for the development of GCC, not for getting help in C.
That said ...
On Sep 15, 2010, at 11:15 PM, ir_idjit wrote:
> but whatever i do it i just can't get it to work
> code:
>
> some_header.h:
> static void *(*oper_table)(void **);
That's a pointer to a function taking
Hi,
I'm currently trying to implement the C++09 exception propagation
proposal (N2179). See the thread at
http://gcc.gnu.org/ml/libstdc++/2008-05/msg00079.html
in the libstdc++ list for details.
As I say in my first follow-up, I need a copy constructor for any type
with a consistent signature
Paolo Carlini wrote:
Hi all, hi Joseph,
on x86_64-linux I'm seeing many new warnings which didn't exist until a few
days ago, see below.
Is that known? Joseph, can it have something to do with your recent libsupc++
changes?
I noticed them too. These warnings say that the unwind-cxx.h
dec
Hi,
Checkin r139050 broke the build. In the file gcc/toplev.h, the new
declaration pedwarn_at is incomplete, leading to syntax errors.
Sebastian
Index: gcc/toplev.h
===
--- gcc/toplev.h(revision 139053)
+++ gcc/toplev.h
H.J. Lu wrote:
On Fri, Aug 22, 2008 at 8:59 AM, Paolo Carlini <[EMAIL PROTECTED]> wrote:
Hi,
apparently, between Revisions 139407 and 139411, this test started failing
the build:
FAIL: abi/cxx_runtime_only_linkage.cc (test for excess errors)
Any idea what's going wrong? Maybe HJ can post
Balogh, Ray wrote:
Dear GCC folks:
I'm having a problem with GCC 2.95.3 that appears to be a compiler bug. It
seems to be optimizing out inlined function code with side effects, and is
related to binding a non-const pointer to a const pointer reference function
parameter. The problem only h
Paolo Carlini wrote:
H.J. Lu wrote:
/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_throw.o):
In function `__exchange_and_add_dispatch':^M
/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/ext/atomic
Paolo Carlini wrote:
Anwyay, one way or the other, l porpose for now let's just support the
new facility only for targets providing the sync builtins and be done
with it. Agreed?
I have no objection to doing that in principle, but it basically means
programming effort in order to remove somethi
Paolo Carlini wrote:
Sebastian Redl wrote:
Could we simply export __exchange_and_add and __atomic_add from
libsupc++ instead of libstdc++? They are pretty basic building blocks
in my opinion.
I agree, in principle. However, sorry, I don't feel like doing that,
it's a non triv
Paolo Carlini wrote:
I think you should consider also the option of having less stuff
exported from libsupc++: if you somehow manage to have the different
code paths in the headers
That's impossible without exposing unwind-cxx.h to the public, and
that's a can of worms I don't even want to look
H.J. Lu wrote:
Can we declare that Linux/ia32 generates i486 insn by default?
Even if we do that, we'll still get errors if someone forces i386. And
the people doing that are more likely to want to link against the
standalone libsupc++, too, since i386 is mostly used in embedded systems
now
Paolo Carlini wrote:
Paolo Carlini wrote:
Sebastian Redl wrote:
Could we simply export __exchange_and_add and __atomic_add from
libsupc++ instead of libstdc++? They are pretty basic building
blocks in my opinion.
I agree, in principle.
Well, thinking more about it, I don't see how you c
Paolo Carlini wrote:
Paolo Carlini wrote:
I'm going to revert again the whole thing and wait for a different,
safe, approach, sorry.
In the short time frame, i.e., something solid for 4.4.0, I would
suggest two possible strategies:
1- Try to re-organize the new code in order to make possible
21 matches
Mail list logo
