On Jun 27, 2012, Mike Stump wrote:
> On Jun 27, 2012, at 2:07 AM, Alexandre Oliva wrote:
>> Why? We don't demand a working plugin. Indeed, we disable the use of
>> the plugin if we find a linker that doesn't support it. We just don't
>> account for the possibility of finding a linker that supp
On Thu, Jun 28, 2012 at 04:16:55AM -0300, Alexandre Oliva wrote:
> On Jun 27, 2012, Mike Stump wrote:
>
> > On Jun 27, 2012, at 2:07 AM, Alexandre Oliva wrote:
> >> Why? We don't demand a working plugin. Indeed, we disable the use of
> >> the plugin if we find a linker that doesn't support it.
On 06/28/2012 07:43 AM, Georg-Johann Lay wrote:
The admin logs look clean now, but the generated documents still didn't
make it to the website, e.g. changes after 2012-05-29 like the
mentioned SVN 188070.
The admin log still shows the following issue for libgomp, cf.
http://gcc.gnu.org/ml/gcca
libgomp.texi is still using gpl.texi, although libgomp has been
relicensed to GPLv3 in 2009. OK?
(This is the last use of gpl.texi in the gcc sources. Perhaps it should
be removed and gpl_v3.texi renamed back to gpl.texi?)
Andreas.
* libgomp.texi: Include gpl_v3.texi instead of gpl.tex
On Thu, Jun 28, 2012 at 10:18:49AM +0200, Andreas Schwab wrote:
> libgomp.texi is still using gpl.texi, although libgomp has been
> relicensed to GPLv3 in 2009. OK?
Yes.
>
> * libgomp.texi: Include gpl_v3.texi instead of gpl.texi.
Jakub
On Thu, 28 Jun 2012, Andreas Schwab wrote:
> libgomp.texi is still using gpl.texi, although libgomp has been
> relicensed to GPLv3 in 2009. OK?
Looks good, thank you.
> (This is the last use of gpl.texi in the gcc sources. Perhaps it
> should be removed and gpl_v3.texi renamed back to gpl.texi?
On Jun 28, 2012, Jakub Jelinek wrote:
> On Thu, Jun 28, 2012 at 04:16:55AM -0300, Alexandre Oliva wrote:
>> I'd very be surprised if I asked for an i686 native build to package and
>> install elsewhere, and didn't get a plugin just because the build-time
>> linker wouldn't have been able to run t
Gerald Pfeifer writes:
> If it's not used any more, yes, please go ahead an remove it.
Done as this, tested with make info.
Andreas.
* doc/include/gpl.texi: Remove.
* doc/sourcebuild.texi (Texinfo Manuals): Don't mention gpl.texi.
diff --git a/gcc/doc/include/gpl.texi b/gcc/do
On Thu, Jun 28, 2012 at 1:39 PM, Alexandre Oliva wrote:
> On Jun 28, 2012, Jakub Jelinek wrote:
>
>> On Thu, Jun 28, 2012 at 04:16:55AM -0300, Alexandre Oliva wrote:
>>> I'd very be surprised if I asked for an i686 native build to package and
>>> install elsewhere, and didn't get a plugin just be
This looks good. I just have one wordsmithing comment.
I would have listed the STB_SECONDARY differences in a different
order -- maybe (3 1 2 4). That puts the most general difference
first, and it matches the order used for the description of
STB_WEAK.
Randy
> -Original Message-
>
On Jun 28, 2012, at 12:16 AM, Alexandre Oliva wrote:
> On Jun 27, 2012, Mike Stump wrote:
>> On Jun 27, 2012, at 2:07 AM, Alexandre Oliva wrote:
>>> Why? We don't demand a working plugin. Indeed, we disable the use of
>>> the plugin if we find a linker that doesn't support it. We just don't
>>
On Thu, Jun 28, 2012 at 6:43 AM, Lowell, Randy wrote:
> This looks good. I just have one wordsmithing comment.
>
> I would have listed the STB_SECONDARY differences in a different
> order -- maybe (3 1 2 4). That puts the most general difference
> first, and it matches the order used for the des
On Jun 28, 2012, at 4:39 AM, Alexandre Oliva wrote:
> On Jun 28, 2012, Jakub Jelinek wrote:
>
>> On Thu, Jun 28, 2012 at 04:16:55AM -0300, Alexandre Oliva wrote:
>>> I'd very be surprised if I asked for an i686 native build to package and
>>> install elsewhere, and didn't get a plugin just becau
On Thu, Jun 28, 2012 at 07:03:37AM -0700, Mike Stump wrote:
> > Also, this scenario of silently deciding whether or not to use the
> > linker plugin could bring us to different test results for the same
> > command lines. I don't like that.
>
> Right, which is why the static configuration of the
The write-up looks good.
Two typos:
1. An instance of "week" instead of "weak"
2. Some text mention "linker" and some other mention "link editor".
Question: will this be part of the current gABI draft soon?
--
Supra
> -Original Message-
> From: generic-...@googlegroups.com [mailto:gene
On Thu, Jun 28, 2012 at 7:12 AM, Suprateeka R Hegde
wrote:
> The write-up looks good.
>
> Two typos:
> 1. An instance of "week" instead of "weak"
> 2. Some text mention "linker" and some other mention "link editor".
Fixed in the revised proposal.
> Question: will this be part of the current gABI
> -Original Message-
> From: generic-...@googlegroups.com [mailto:generic-
> a...@googlegroups.com] On Behalf Of H.J. Lu
> Sent: 28 June 2012 07:55 PM
> To: generic-...@googlegroups.com
> Cc: GCC Development; Binutils; GNU C Library; Ansari, Zia
> Subject: Re: Add STB_SECONDARY to gABI
>
>
On Thu, Jun 28, 2012 at 7:34 AM, Suprateeka R Hegde
wrote:
>> -Original Message-
>> From: generic-...@googlegroups.com [mailto:generic-
>> a...@googlegroups.com] On Behalf Of H.J. Lu
>> Sent: 28 June 2012 07:55 PM
>> To: generic-...@googlegroups.com
>> Cc: GCC Development; Binutils; GNU C
On Thu, 28 Jun 2012, H.J. Lu wrote:
> Can someone take gABI draft html files and put them on
> github?
That requires permission from the copyright holder.
--
Joseph S. Myers
jos...@codesourcery.com
On Thu, Jun 28, 2012 at 4:08 PM, Jakub Jelinek wrote:
> On Thu, Jun 28, 2012 at 07:03:37AM -0700, Mike Stump wrote:
>> > Also, this scenario of silently deciding whether or not to use the
>> > linker plugin could bring us to different test results for the same
>> > command lines. I don't like tha
Hello,
I faced a problem with usage of force_gimple_operand function for
specific tree. I have a TARGET_MEM_REF tree node whose address I want
to pass as argument to the function call. I use build_fold_addr_expr
to get address tree and then pass it to force_gimple_operand which
generates strange s
I'd like to add an inverse definition to an existing BOOL/bool type, one which
the compiler is natively aware of.
Example:
bool isSystemOpen;
I can reference this in the manner in which it's defined:
if (isSystemOpen)
if (!isSystemOpen)
However, there are times when it's more desirable to refer
Note1: I am not subscribed to the gcc list, please use reply-all.
Note2: I think the clang list is moderated for the first post, but it
is usually really fast. Sorry about that.
I recently implemented an optimization in LLVM to hide symbols that
the we "know" are available in every DSO that uses t
On Thu, Jun 28, 2012 at 02:13:47PM -0400, Rafael Espíndola wrote:
[ problem with visibility for bar::~bar for testcase ]
> $ cat test.h
> struct foo {
> virtual ~foo();
> };
> struct bar : public foo {
> virtual void zed();
> };
> $ cat def.cpp
> #include "test.h"
> void bar::zed() {
> }
> $ ca
On 28 June 2012 17:00, Rick Hodgin wrote:
> I'd like to add an inverse definition to an existing BOOL/bool type, one
> which the compiler is natively aware of.
>
> Example:
> bool isSystemOpen;
>
> I can reference this in the manner in which it's defined:
> if (isSystemOpen)
> if (!isSystemOpen)
>
> Why do you want to bother with a non-standard,
> unportable extension instead of just writing:
>
> inline bool isSystemClosed()
> { return !isSystemOpen; }
>
> Which is simple, conventional, easy to understand
> and portable.
>
> Or in C++ just define a suitable type, instead of
> needing chan
On Jun 28, 2012, at 12:12 PM, Joe Buck wrote:
> On Thu, Jun 28, 2012 at 02:13:47PM -0400, Rafael Espíndola wrote:
> [ problem with visibility for bar::~bar for testcase ]
>> $ cat test.h
>> struct foo {
>> virtual ~foo();
>> };
>> struct bar : public foo {
>> virtual void zed();
>> };
>> $ cat de
On Thu, Jun 28, 2012 at 12:39 PM, Rick Hodgin wrote:
>> Why do you want to bother with a non-standard,
>> unportable extension instead of just writing:
>>
>> inline bool isSystemClosed()
>> { return !isSystemOpen; }
>>
>> Which is simple, conventional, easy to understand
>> and portable.
>>
>> Or
The core development team is very pleased to announce the availability
of PPL 1.0, a new release of the Parma Polyhedra Library.
This release includes support for the optimized representation of
sparse vectors of coefficients, achieving significant performance
improvements, e.g., when dealing wi
On 06/28/2012 02:03 PM, Mark Butler wrote:
On Tuesday, June 26, 2012 1:53:01 PM UTC-6, H. Peter Anvin wrote:
It's worth noting that there are *no* Linux platforms that are not
ILP32
or LP64, so adding a third memory model is likely to cause even more
problems...
Care to comment
How would you handle:
isSystemClosed = true;
You're getting into nasty looking/non-obvious code to use language-existing
features for an ability that 1) is fundamental to software and 2) should have
native support without kludges.
Many CPUs even support the write-back NOT of a flag condition n
On Thu, 2012-06-28 at 18:08 -0400, Rick C. Hodgin wrote:
> How would you handle:
>
> isSystemClosed = true;
By adding one line to inv_bool
struct inv_bool {
bool& b;
operator bool() const { return !b; }
inv_bool& operator = (bool _b) { b = !_b; return *this; }
};
Cheers,
Oleg
On Jun 28, 2012, Mike Stump wrote:
> On Jun 28, 2012, at 4:39 AM, Alexandre Oliva wrote:
>> That still doesn't sound right to me: why should the compiler refrain
>> from using a perfectly functional linker plugin on the machine where
>> it's installed (not where it's built?
> See your point bel
On Thu, Jun 28, 2012 at 3:08 PM, Rick C. Hodgin wrote:
> How would you handle:
>
> isSystemClosed = true;
A good clean error message is ideal, and should be easy. (A proxy
object such as inv_bool can do this easily enough, but it's still
going to hurt readability.)
> You're getting into nasty
Snapshot gcc-4.5-20120628 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20120628/
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
In a boolean variable, there are two fundamental ways to examine: as it is, or
!(as it is).
Using the same memory location to access those two base / fundamental extents
of its very nature, while new in concept to C/C++ hackers, is not new in any
degree of concept. Five year olds use this in s
36 matches
Mail list logo
