Re: [C++0x]: non-public defaulted copy c-tor

[Jonathan Wakely]

2009/11/26 Piotr Wyderski:
>
> Clean, simple and GCC used to happily accept that.

Only with the experimental C++0x mode, which is a moving target and
you shouldn't really complain if it changes.

> But now it is illegal because of 3 draft violations:
>
> Base() shall be public, but is not
> ~Base() shall be public, but is not
> ~Base() shall not be virtual, but it is
>
> IMHO this severely cripples defaulted functions,
> making them almost useless -- the set of allowed
> cases is too narrow. Is there any chance to fix the DR?

It's under discussion, but relax, notice it says "If it is explicitly
defaulted on its first declaration,"

Have you tried:

class Base {
protected:

Base();
virtual ~Base();
};

inline Base::Base() = default;
inline Base::~Base() = default;

This still lets you use defaulted functions, but the base is not
trivially copyable. (I haven't tested this with GCC, but I believe it
should work.)

Re: [C++0x]: non-public defaulted copy c-tor

[Jonathan Wakely]

2009/11/26 Jonathan Wakely:
>
> This still lets you use defaulted functions, but the base is not
> trivially copyable.

Oops, I meant the base is not a trivial class ... but then it can't be
anyway as you have a virtual function.

Re: WTF?

[Paolo Bonzini]

On 11/26/2009 12:20 AM, Alexandre Oliva wrote:

sed -i 's,[ \t]*$,,' probably won't work, if there are all-blanks lines
being left alone in the patch (so the rx will match the patch markers
too), but something slightly more elaborate preserving a fixed number of
leading blanks dependng on the patch type (context or unified) should:


Actually an empty line is considered by patch(1) the same way as a line 
containing only a space (or two spaces for context diffs), because there 
are many mailers that strip trailing whitespace.


Paolo

Re: [C++0x]: non-public defaulted copy c-tor

[Piotr Wyderski]

Jonathan Wakely wrote:

> It's under discussion

That's certainly a good news. Anyway, I'll wait
with porting my framework to the newest GCC,
until this issue is settled, as:

a) "= default" works as I expect on gcc 4.5-20090604
and maybe it will still do in the future;
b) gcc 4.5-20091119 reports so many ICEs it is almost
useless;
c) it seems to have problems with overload resolution.

I wanted lambdas, but it can wait -- the top of my
wish list, i.e. constructor inheritance/delegation is
not implemented yet anyway.

> but relax, notice it says "If it is explicitly
> defaulted on its first declaration,"
[...]
> inline Base::Base() = default;
> inline Base::~Base() = default;

Of course, I tried that and it works to some
extent, as on 20090604 defaulted virtual
destructors are not DLL-exported for some
reasons, but their {} counterparts are).

The point is that the only reason to have
defaulted functions is to provide comprehensive
syntax for obvious things. However:

inline Base::Base() {};
inline Base::~Base() {};

is even shorter than the defaulted version, not to mention:

class Base {
protected:

   Base() {};
   virtual ~Base() {};
};

which is the reason I dare to say the crippled version is useless.
What is the point of doing simple things in a complex way?

Best regards
Piotr Wyderski

Re: WTF?

[Richard Guenther]

On Thu, Nov 26, 2009 at 9:56 AM, Paolo Bonzini  wrote:
> On 11/26/2009 12:20 AM, Alexandre Oliva wrote:
>>
>> sed -i 's,[ \t]*$,,' probably won't work, if there are all-blanks lines
>> being left alone in the patch (so the rx will match the patch markers
>> too), but something slightly more elaborate preserving a fixed number of
>> leading blanks dependng on the patch type (context or unified) should:
>
> Actually an empty line is considered by patch(1) the same way as a line
> containing only a space (or two spaces for context diffs), because there are
> many mailers that strip trailing whitespace.

Does svn rely on patch for merging and can it be taught to use -l?

Richard.

Re: WTF?

[Philip Martin]

Richard Guenther  writes:

> Does svn rely on patch for merging

No, it uses an internal diff3 algorithm.  You can make it use an
external diff3 program via the command line or the config file.

> and can it be taught to use -l?

The internal diff/merge will ignore whitespace if you use -x -w.

-- 
Philip

Re: WTF?

[Vincent Lefevre]

On 2009-11-25 17:49:39 +0100, Richard Guenther wrote:
> On Wed, 25 Nov 2009, Richard Kenner wrote:
> > Why the latter? I agree with the problems this can cause, but if
> > they can't be fixed by removing it from the database, why revert
> > it? All things being equal, trailing blanks in fact aren't a good
> > idea.
> 
> Because it makes branch merging a nightmare and all patches people
> keep are hosed and won't apply anymore.

Except if patches come from some web page (e.g. mailing-list archives)
where trailing spaces are stripped out. In that case, patches will
magically apply without any problem, whereas before the change they
wouldn't. :)

I've had such problems in the past with other projects, where I was
told to apply some patch only available on the web, but it wouldn't
apply since the source had trailing whitespace and the patch didn't
(because some tool not specifically written to handle patches
stripped such whitespace).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: WTF?

[Vincent Lefevre]

On 2009-11-26 10:12:39 +1100, Ben Elliston wrote:
> On Wed, 2009-11-25 at 15:17 -0500, Kaveh R. GHAZI wrote:
> > Finally, we have a process for reverting a patch.  If anyone wants to
> > revert some part, it needs to be followed.  Otherwise *that* would be
> > breaking the rules...
> 
> Won't reverting the patch just attribute all of the lines to the
> username of the reverter?

Probably not if this is done with "svn cp" from the previous revision
(and the patch won't appear in the log anymore). But I don't know the
side effects of such a "svn cp" on merges and so on.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: WTF?

[Michael Matz]

Hi,

On Wed, 25 Nov 2009, Richard Kenner wrote:

> > In my mind it's very simple: trailing whitespace poses exactly _no_ 
> > problem (except of being against the coding standard), 
> 
> It's against the coding standards for a very good reason, which is that it
> makes patching harder because you have lines that compare differently but
> look identical.

Wow I like this creative twisting of arguments.  So in order to not make 
patching harder in theory you make patching harder in practice?!
Brilliant.

> So removing them, while making some patches harder to
> apply, makes others easier into the future.

Except if you produce patches by hand this change doesn't make the 
slightest thing easier in the future.  patch and diff will consume and 
generate applyable .diff files no matter if the material did or didn't 
contain trailing white space as long as this isn't changed between 
producing and applying the patch, hence future patch processing is not 
affected in any way.

I also didn't want to know how to make patch work around this commit by 
loosening it's apply algorithm, neither did I want to know how to mold 
the patches I have into a form that now applies again.  The point is That 
I Don't Want To Work Around useless unapproved mass changes.

I'm also surprised by the hair splitting and bike shedding if the patch 
was or wasn't obvious.  To any reasonable person it must be clear that due 
to the ripple effect it has it is not obvious and hence has to be reverted 
already just out of policy reasons.  Then we perhaps can discuss further 
about the merits of the change, and then, after reaching agreement, commit 
it again; but only then.

I'll note that conveniently nobody of the supporters of this change 
answered Richards question about the positive effects of the change and 
the seeming absence of real GCC bugs so that we can waste our time on this 
type of thing.


Ciao,
Michael.

Re: trivial trailing whitespace issue

[Michael Matz]

Hi,

On Wed, 25 Nov 2009, Basile STARYNKEVITCH wrote:

> >   1. What to do in the immediate term with the repo.  I've got no strong
> > opinions here.
> 
> I do understand most of the opinions, but I would rather prefer that we 
> don't revert the trailing whitespace patch. I definitely can live with 
> them, and they probably cleaned up a bit the code.

How, for goodness sake, can pure trailing whitespace changes, which by 
necessity you can't even _see_ in an editor (except if you activate modes 
that explicitely show them e.g. in different color) clean up code?  Have 
you looked at the patch or fallout from it?  If not, why do you speak in 
favor of it?


Ciao,
Michael.

Re: WTF?

[Jeff Law]

On 11/25/09 16:51, Lu, Hongjiu wrote:

Sorry for that. I did send an email and though it was an obvious fix. I guess the 
patch may be too big,>  400K with bz2.

   
Did you get a reject message?  If so, that should have caused you to 
stop and think a little...


Jeff

Re: WTF?

[Dave Korn]

Michael Matz wrote:

> I Don't Want To Work Around useless unapproved mass changes.

  Hey, nor do I.  (In fact, I don't even like having to work around useful
approved mass changes, merging is always dull and tedious work.  But I think
of it as just something that goes with the territory.)

> To any reasonable person it must be clear 

  I'm a reasonable person.  It is not clear to me.

> the seeming absence of real GCC bugs so that we can waste our time on this 
> type of thing.

  Actually, I made a quick judgement call when Richard G. first posted about
this, and decided that the quickest and most efficient thing I could possibly
do to deal with this problem using the least effort and wasting the least time
would be to just not care and simply get on with my work.

  If this thread goes on much longer, there will presumably come a crossover
point at which it would have been more worth your while too 

cheers,
  DaveK

Re: trivial trailing whitespace issue

[Basile STARYNKEVITCH]

Michael Matz wrote:

Hi,

On Wed, 25 Nov 2009, Basile STARYNKEVITCH wrote:


  1. What to do in the immediate term with the repo.  I've got no strong
opinions here.
I do understand most of the opinions, but I would rather prefer that we 
don't revert the trailing whitespace patch. I definitely can live with 
them, and they probably cleaned up a bit the code.


How, for goodness sake, can pure trailing whitespace changes, which by 
necessity you can't even _see_ in an editor (except if you activate modes 
that explicitely show them e.g. in different color) clean up code?  Have 
you looked at the patch or fallout from it?  If not, why do you speak in 
favor of it?


I was speaking in favor of the patch because it apparently make the GCC code 
more conformant to GCC coding styles.


Regards.


--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: trivial trailing whitespace issue

[Mark Mielke]

On 11/26/2009 08:18 AM, Michael Matz wrote:

How, for goodness sake, can pure trailing whitespace changes, which by
necessity you can't even _see_ in an editor (except if you activate modes
that explicitely show them e.g. in different color) clean up code?  Have
you looked at the patch or fallout from it?  If not, why do you speak in
favor of it?


I'm an outside observer with professional ties to SCM.

This issue is similar in scope to TAB vs SPACE for indenting. Whether 
you can see it or not is not indicative of whether it has downstream 
effects or not.


Generally, whitespace on the end of lines is bad, and cleanup eventually 
becomes necessary. It is "bad" because people will accidentally change 
lines without realizing them, and these changed lines show up in patches 
and annotations. This goes both ways - a lot of people browse code in vi,
and accidentally add space to the end of lines they don't even intend to 
change. Or, maybe their editor automatically strips whitespace at end of 
line when they re-indent. Who knows? Same happens with TAB changed to 
SPACE or back and forth. Once these start to accumulate - they create 
downstream consequences that multiply. You can't see it, but every 
program that the file passes through *does* see them.


Is cleanup in bulk the right approach? You either clean up over time or 
you do it in bulk. In my own projects, some of the designers I worked 
with had horrible habits in this regard. Every second line would have 
whitespace on the end. The longer it is left, the worse the effect.


As software architect for our project, I notified the team I was doing a 
cleanup, and did it in bulk. Due to the notification, everything went 
smooth.


It sounds like the idea should have been proposed and accepted. 
Everybody would have been ready for it, and nobody would be upset. Oh well.


It's been entertaining. gcc@gcc.gnu.org is normally pretty dull to 
read... :-)


Cheers,
mark

--
Mark Mielke

gcc-4.5-20091126 is now available

[gccadmin]

Snapshot gcc-4.5-20091126 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20091126/
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/trunk revision 154692

You'll find:

gcc-4.5-20091126.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.5-20091126.tar.bz2 C front end and core compiler

gcc-ada-4.5-20091126.tar.bz2  Ada front end and runtime

gcc-fortran-4.5-20091126.tar.bz2  Fortran front end and runtime

gcc-g++-4.5-20091126.tar.bz2  C++ front end and runtime

gcc-java-4.5-20091126.tar.bz2 Java front end and runtime

gcc-objc-4.5-20091126.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.5-20091126.tar.bz2The GCC testsuite

Diffs from 4.5-20091119 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

RE: WTF?

[Lu, Hongjiu]

> >
> Did you get a reject message?  If so, that should have caused you to
> stop and think a little...
> 

I sent:


Date: Wed, 25 Nov 2009 02:53:21 -0800
From: "H.J. Lu" 
To: gcc-patc...@gcc.gnu.org
Subject: PATCH: Remove trailing white spaces
User-Agent: Mutt/1.5.19 (2009-01-05)

Hi,

I am checking in this patch to remove trailing white spaces.


I didn't get any reject. But apparently it never showed up.


H.J.

Re: No .got section in ELF

[yunfeng zhang]

The rsult is also same, you go too far.

Code I want to show a fact in Linux, when a process load a library into memory,
such as 0x1000

 foo.so 0x1000
ELF header
.text section
.data section
.bss section
...

Here data in 0x1000 and its follower have an *exact* map to foo.so in disk, you
need review my code, so which can bring an optimization is offsetof(C - A) is
const. Further, everything in data/bss section has a fixed offset to text
section.


2009/11/26 Alexandre Oliva :
> On Nov 26, 2009, yunfeng zhang  wrote:
>
>> The result is the same
>
> But the code isn't.  See how, with hidden, we use the fixed offset.
>
> Now remove the hidden attribute, define g also in the main program, and
> see what it prints.
>
> --
> Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
> You must be the change you wish to see in the world. -- Gandhi
> Be Free! -- http://FSFLA.org/   FSF Latin America board member
> Free Software Evangelist      Red Hat Brazil Compiler Engineer
>

Re: No .got section in ELF

[Dave Korn]

yunfeng zhang wrote:

> have an *exact* map to foo.so in disk

  This is where your misunderstanding arises.  Just as 5+3 can add up to the
same result as 4+4, so you cannot ignore that the final mapped addresses you
are seeing add up to the same result via different routes.  Compile your
sources using --save-temps, and look at the differences in the generated
assembly files.  By looking only at the final results, you are losing
information about how those results are arrived at.

cheers,
  DaveK

Re: No .got section in ELF

[yunfeng zhang]

You can run a.out several times

24>>a5e0<<, 249>>41c<<
11>>15e0<<, 110>>41c<<
c7>>85e0<<, c77>>41c<<
8c>>35e0<<, 8c2>>41c<<
...

Now open f.map
g = 0x15e0, foo = 0x41c

is it 5 + 3 = 4 + 4?


2009/11/27 Dave Korn :
> yunfeng zhang wrote:
>
>> have an *exact* map to foo.so in disk
>
>  This is where your misunderstanding arises.  Just as 5+3 can add up to the
> same result as 4+4, so you cannot ignore that the final mapped addresses you
> are seeing add up to the same result via different routes.  Compile your
> sources using --save-temps, and look at the differences in the generated
> assembly files.  By looking only at the final results, you are losing
> information about how those results are arrived at.
>
>    cheers,
>      DaveK
>
>
>
>

Re: No .got section in ELF

[Dave Korn]

yunfeng zhang wrote:
> a.out 

> f.map

> is it 5 + 3 = 4 + 4?

  If you refuse to look at the source code that gcc generates, you will never
know what the difference is.

  I cannot make that decision for you.

cheers,
  DaveK

Re: No .got section in ELF

[Dmitry Gorbachev]

Yunfeng Zhang, please try this example.


elf.tar.gz
Description: GNU Zip compressed data

Re: No .got section in ELF

[Jie Zhang]

On 11/26/2009 02:04 PM, yunfeng zhang wrote:

The result is the same

#include

extern int g __attribute__((visibility("hidden")));
int g;

int foo(int a, int b)
{
 g = a + b;
 printf("%x, %x",&g, foo);
 return g;
}

load and call `foo' in the library, an outputting (with vdso) is
 cc15bc, cc03fc
and open f.map
 0x15bc, 0x3fc

It shows Linux simply maps the library to memory *using* library segment layout.

Using e.cc to call it

#include
#include
#include
#include
#include

int main(void)
{
 void* handle = dlopen("./f.so", RTLD_NOW);
 typedef int (*gso)(int, int);
 gso f;
 *(void**) (&f) = dlsym(handle, "foo");
 f(1, 2);
 return 0;
}


You got the bad test case. Please try the following:

$ cat f.c
#include 
int g;

int foo(int a, int b)
{
  g = a + b;
  printf("&g = 0x%x, foo = 0x%x\n", &g, foo);
  return g;
}

$ cat e.c
int g;
extern int foo(int a, int b);

int main(void)
{
  foo(1, 2);
  return 0;
}

$ gcc -shared -fPIC -Wl,-soname,./libf.so,-Map,f.map -o libf.so f.c
$ gcc -o e e.c -ldl -L. -lf
$ ./e
&g = 0x600a30, foo = 0x294a2614

Then comment out the "int g;" in e.c. and do the same steps as above:

$ ./e
&g = 0x58294948, foo = 0x58094614

You can see that "C-A" is *not* a constant. Your premise is wrong.


Jie

Re: No .got section in ELF

[yunfeng zhang]

Sorry! I've made a mistake! But using LD_PRELOAD to force to reposition a
variable/function from a module is violating software engineer. And the more
important is, as the result, all user *all* pay the bill for this even they
make sure they don't need the feature, such as, glibc itself.