On 14 June 2012 14:14, Matthias Klose wrote:
> So what could be done for a distribution?
>
> - For this particular issue, ask upstreams to work around this
> particular incompatibility. This might work better, if the
> upstream sits "closer" to the distribution, but doesn't seem
> to be a g
On 06/14/2012 06:14 AM, Matthias Klose wrote:
While PR53646 claims that c++98 and c++11 should be ABI
compatible (modulo bugs), the addition of the _M_size member
to std::_List_base::_List_impl makes libraries using
std::list in headers incompatible, when built in c++98 and
c++11 mode.
So it do
Snapshot gcc-4.5-20120614 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20120614/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hello Everyone,
I thought you might be interested in some C++ expression template
benchmarks I have done.
http://www.wlandry.net/Projects/FTensor#Benchmarks
I found that GCC optimized the expression template code better than
unrolling expressions by hand. In fact, GCC was far, far better at
o
On Thu, 2012-06-14 at 16:34 -0400, Rick C. Hodgin wrote:
> David,
>
> Well, I probably don't have a NEED for it. I've gotten along for 25+
> years without it. :-)
>
> However, what prompted my inquiry is using it would've saved me tracking
> down a few bugs in recent weeks. Some prior code wa
Andreas,
That would work. But now I'm back to remembering to fix something when
I copy / re-use code.
I'll admit it's minor. But we have tools to help us for a reason,
right? :-)
Best regards,
Rick C. Hodgin
On 06/14/2012 04:38 PM, Andreas Schwab wrote:
"Rick C. Hodgin" writes:
I can
"Rick C. Hodgin" writes:
> I can also see a use for generated code where there's a base source code
> template in use with an embedded include file reference that changes as
> it's generated per pass, such as:
>
> int step1(int a, int b)
> {
#define self step1
> #include "\current_task\
On 06/14/2012 02:33 PM, Paweł Sikora wrote:
from the others side, someone can use -frecord-gcc-switches to detect mixed
'-std=...'
after final linking and report error in such cases.
Given that we have -fabi= to go along with the -std= options, ISTM that
we'd really be better off recording the
David,
Well, I probably don't have a NEED for it. I've gotten along for 25+
years without it. :-)
However, what prompted my inquiry is using it would've saved me tracking
down a few bugs in recent weeks. Some prior code was re-used for a
similar function, but the name of the recursive call
On Thursday 31 of May 2012 22:58:32 Jonathan Wakely wrote:
> On 31 May 2012 22:39, Jonathan Wakely wrote:
> > On 31 May 2012 22:35, James Y Knight wrote:
> >> I understand that the ABI changes generally cannot be avoided, but a lot
> >> of pain for a lot of people could be avoided by making things
On 14/06/12 19:31, Joe Buck wrote:
It only saves one character in any case: your "self" is just "*this".
No, "this" points to the object in C++. The OP's "self" is referring to
the function being compiled. So here "self" would be the same as "foo".
I don't think there is any way to get thi
It only saves one character in any case: your "self" is just "*this".
From: gcc-ow...@gcc.gnu.org [gcc-ow...@gcc.gnu.org] on behalf of Ian Lance
Taylor [i...@google.com]
Sent: Thursday, June 14, 2012 10:19 AM
To: Rick C. Hodgin
Cc: gcc@gcc.gnu.org
Subject:
"Rick C. Hodgin" writes:
> I was thinking C and C++.
>
> int myclass::foo(int a)
> {
> // recursion
> self(a + 1);
> }
>
> Just out of curiosity, why wouldn't it be accepted back into mainline?
In general these days GCC discourages language extensions. They would
have to have a compelli
David,
Oh! Well, it doesn't have to be called self. :-) It could be __self__
or whatever would be fine. I see C99 has __FUNC__ for the current
function name used in strings. But, I was thinking more of an actual
reference to the current function as a function entity, sort of like a
name s
FWIW "self" today is a perfectly good variable name, and practically all
C and C++ code that interacts with Python (including the C
implementation of Python itself) uses "self" to name variables
throughout: many thousands of projects, many millions of lines of code.
Having this snatched away as a k
Ian,
I was thinking C and C++.
int myclass::foo(int a)
{
// recursion
self(a + 1);
}
Just out of curiosity, why wouldn't it be accepted back into mainline?
Thanks for your help. :-)
Best regards,
Rick C. Hodgin
On 06/14/2012 12:48 PM, Ian Lance Taylor wrote:
"Rick C. Hodgin" writes
Mohammad Katmawi writes:
> I have gcc-4.6.1. Now I am trying to install gcc-3.4.6 for sake of msp430x. I
> received many errors. The last one was following:
This message is not appropriate for the mailing list gcc@gcc.gnu.org,
which is about the development of GCC itself. It would be appropria
"Rick C. Hodgin" writes:
> How hard would it be to implement a "self" keyword extension which
> references the contextual function name wherein it was referenced?
>
> int foo(int a)
> {
> // recursion
> self(a + 1);
> }
>
> int food(int a)
> {
> // recursion
> self(a + 1);
> }
>
>
On Thu, Jun 14, 2012 at 5:41 AM, Uros Bizjak wrote:
> Hello!
>
> I would like to point out that in libjava/sysdep/*/locks.h many
> targets still implement atomics in assembly. These utility functions
> can be implemented with new atomic builtins, avoiding quite some
> compexity.
>
> Maintaniers of
Hello All,
I have gcc-4.6.1. Now I am trying to install gcc-3.4.6 for sake of msp430x. I
received many errors. The last one was following:
./crtstuff.c:300: error: syntax error before '{' token
These what I could copy from my terminal:
/usr/include/unistd.h:1019: error: syntax error before "
How hard would it be to implement a "self" keyword extension which
references the contextual function name wherein it was referenced?
int foo(int a)
{
// recursion
self(a + 1);
}
int food(int a)
{
// recursion
self(a + 1);
}
Obviously not a useful example, but demonstrates that
On 31 May 2012 22:35, James Y Knight wrote:
> You've missed at least one ABI incompatibility in GCC 4.7 and later, as
> demonstrated in real life by (at least) libboost_python, and distilled
> into this test case.
>
> At least these bug reports are probably caused by this ABI incompatibility:
> htt
While PR53646 claims that c++98 and c++11 should be ABI
compatible (modulo bugs), the addition of the _M_size member
to std::_List_base::_List_impl makes libraries using
std::list in headers incompatible, when built in c++98 and
c++11 mode. Currently seen in libsigc++ (Signal Framework
for C++) an
I forgot to mention this is in 4.7.0.
4.6.3 happily assigns the right classes to the registers. I wonder if
there's any new macro in 4.7 that I haven't defined...
On 14/06/12 13:47, Paulo J. Matos wrote:
Hi,
I found a problem with my port where IRA generates a spill error. After
looking at t
Hi,
I found a problem with my port where IRA generates a spill error. After
looking at the logs I get this kind of output for the best class for the
pseudo regs:
Pass 0 for finding pseudo/allocno costs
a2 (r30,l0) best NO_REGS, allocno NO_REGS
a3 (r29,l0) best NO_REGS, allocno NO_REG
The GNU Compiler Collection version 4.7.1 has been released.
GCC 4.7.1 is the first bug-fix release containing important fixes
for regressions and serious bugs in GCC 4.7.0 with over 100 bugs
fixed since the previous release. This release is available from
the FTP servers listed at:
http://ww
On Thu, Jun 14, 2012 at 2:32 PM, niXman wrote:
> 2012/6/14 Richard Guenther:
>> The GCC 4.7.1 release tarballs have been created and are being uploaded
>> to ftp.gnu.org right now.
>
> Tell me please, where I can see a list of changes/fixes for GCC-4.7.1?
If you look at changes.html for GCC 4.7,
2012/6/14 Richard Guenther:
> The GCC 4.7.1 release tarballs have been created and are being uploaded
> to ftp.gnu.org right now.
Tell me please, where I can see a list of changes/fixes for GCC-4.7.1?
Thanks!
--
Regards,
niXman
___
Dual-target(32
Status
==
The GCC 4.7.1 release tarballs have been created and are being uploaded
to ftp.gnu.org right now. The GCC 4.7 branch is thus open again for
regression and documentation fixes.
Quality Data
Priority # Change from Last Report
--- -
Hello!
I would like to point out that in libjava/sysdep/*/locks.h many
targets still implement atomics in assembly. These utility functions
can be implemented with new atomic builtins, avoiding quite some
compexity.
Maintaniers of unconverted targets (m68k, pa, powerpc, s390, sh and sparc) CC'd.
On 14/06/2012 04:05, Chris Jones wrote:
David Brown wrote:
On 11/06/2012 09:45, Chris Jones wrote:
Is it possible to modify the source code of gcc to enable to compilation
of a completely new programming language, as yet unrecognized? How much
of a big job would I be looking at for such a task?
31 matches
Mail list logo