Re: typos

[Veres Lajos]

On Wed, 3 Jul 2013, Ondrej Bilka wrote:

> On Wed, Jul 03, 2013 at 12:41:42AM +0200, Veres Lajos wrote:
> > Hi,
> >
> > I wrote a small misspell finder/fixer script and when I have a little
> > spare time I clean OS projects with it. 
> > (https://github.com/vlajos/misspell_fixer)
> > I ran it on this repository:
> > svn://gcc.gnu.org/svn/gcc/trunk
> > The patch is around 800kb.
> > What is the best way to handle this modifications?
> > I mean most of the modifications are in the comments and in the
> > documentations, but a code-review is needed anyway. The script itself
> > isn't enough intelligent.
> > So how could I smooth the way to land these modifications?

> I am writing similar tool, that checks more style issues.
> I could try to integrate that.
>
> My idea is run this as pre-commit hook, separate comments from diff, check it 
> with aspell and print
> misspelings in standard output so user can filter them.

Classic spellchekers are not really efficient for finding typos in program
sources. There are too many false positives.
Anyway can I help somehow?

And if the script will be done you should run it for the whole
codebase. Otherwise the issues won't be fixed until anybody touches them.

-- 
Veres Lajos
vla...@gmail.com
+36 20 438 5909

Re: [boost] lots of warning with gcc-4.8.1 + boost-1.54.0

[Jonathan Wakely]

On 3 July 2013 02:41, Nathan Ridge wrote:
>> Lots of warnings like this:
>>
>> ./boost/bind/arg.hpp:37:22: warning: typedef ‘T_must_be_placeholder’ locally
>> defined but not used [-Wunused-local-typedefs]
>>
>> when building 1.54.0 with gcc-4.8.1 (fedora f19)
>
> This warning is new in GCC 4.8, and I have been seeing a ton of them
> not just in boost, but in every codebase I've built.

It was new in GCC 4.7, http://gcc.gnu.org/gcc-4.7/changes.html

It affects Boost more than most code because of the prevalent use of
concept checks and static assertions which are usually implemented
using typedefs but only conditionally compiled.

I keep being surprised noone's disabled it in gcc.jam yet.

Re: [boost] lots of warning with gcc-4.8.1 + boost-1.54.0

[Jonathan Wakely]

On 3 July 2013 02:41, Nathan Ridge wrote:
>> Lots of warnings like this:
>>
>> ./boost/bind/arg.hpp:37:22: warning: typedef ‘T_must_be_placeholder’ locally
>> defined but not used [-Wunused-local-typedefs]
>>
>> when building 1.54.0 with gcc-4.8.1 (fedora f19)
>
> This warning is new in GCC 4.8, and I have been seeing a ton of them
> not just in boost, but in every codebase I've built.

It was new in GCC 4.7, http://gcc.gnu.org/gcc-4.7/changes.html

It affects Boost more than most code because of the prevalent use of
concept checks and static assertions which are usually implemented
using typedefs but only conditionally compiled.

I keep being surprised noone's disabled it in gcc.jam yet.

> CC'ing the gcc folks.

That's not very helpful because posting to the Boost list is
subscription only (you'll have two copies of this mail, because the
first one I sent from an address subscribed to the GCC list but not
this one.)

Re: [boost] lots of warning with gcc-4.8.1 + boost-1.54.0

[Daniel James]

On 3 July 2013 09:32, Jonathan Wakely  wrote:
>
> I keep being surprised noone's disabled it in gcc.jam yet.

That wouldn't work for headers, as they get included when building
with other build systems. Since this is new, I guess we can use
pragmas to disable the warning, but that's a pain.

Re: typos

[Martin Jambor]

Hi,

On Wed, Jul 03, 2013 at 09:55:14AM +0200, Veres Lajos wrote:
> On Wed, 3 Jul 2013, Ondrej Bilka wrote:
> 
> > On Wed, Jul 03, 2013 at 12:41:42AM +0200, Veres Lajos wrote:
> > > Hi,
> > >
> > > I wrote a small misspell finder/fixer script and when I have a little
> > > spare time I clean OS projects with it. 
> > > (https://github.com/vlajos/misspell_fixer)
> > > I ran it on this repository:
> > > svn://gcc.gnu.org/svn/gcc/trunk
> > > The patch is around 800kb.
> > > What is the best way to handle this modifications?
> > > I mean most of the modifications are in the comments and in the
> > > documentations, but a code-review is needed anyway. The script itself
> > > isn't enough intelligent.
> > > So how could I smooth the way to land these modifications?
> 
> > I am writing similar tool, that checks more style issues.
> > I could try to integrate that.
> >
> > My idea is run this as pre-commit hook, separate comments from diff, check 
> > it with aspell and print
> > misspelings in standard output so user can filter them.
> 
> Classic spellchekers are not really efficient for finding typos in program
> sources. There are too many false positives.
> Anyway can I help somehow?
> 
> And if the script will be done you should run it for the whole
> codebase. Otherwise the issues won't be fixed until anybody touches them.
> 

perhaps you should be aware that there are people who prefer exactly
that, though the discussions so far have been about
formatting/whitespace problems only.  The reason is simpler history
browsing which such changes complicate for little gain (I personally
can cope with it but I see the point).

On the other hand, I think that this would matter much less for lines
where there are only comments.  So I'd suggest cherry-picking these
and submitting fixes in them.  If the patch is large, split it into a
number of patches for easier review.  If there are errors in
identifiers etc. I assume that needs to be handled on case by case
basis, although some related cases can certainly be dealt with
together (and it would upset history a bit so there might even be
opposition to that).

Thanks,

Martin

RE: [boost] lots of warning with gcc-4.8.1 + boost-1.54.0

[Nathan Ridge]

> On 3 July 2013 02:41, Nathan Ridge wrote:
>>> Lots of warnings like this:
>>>
>>> ./boost/bind/arg.hpp:37:22: warning: typedef ‘T_must_be_placeholder’ locally
>>> defined but not used [-Wunused-local-typedefs]
>>>
>>> when building 1.54.0 with gcc-4.8.1 (fedora f19)
>>
>> This warning is new in GCC 4.8, and I have been seeing a ton of them
>> not just in boost, but in every codebase I've built.
>
> It was new in GCC 4.7, http://gcc.gnu.org/gcc-4.7/changes.html

I stand corrected. (What's new in 4.8 is it being included in -Wall,
which is why I never noticed it in 4.7).

> It affects Boost more than most code because of the prevalent use of
> concept checks and static assertions which are usually implemented
> using typedefs but only conditionally compiled.

I've seen spews of that warning for other large projects, such as
clang or wxWidgets, not just boost.

Would GCC consider removing it from -Wall?

>> CC'ing the gcc folks.
>
> That's not very helpful because posting to the Boost list is
> subscription only (you'll have two copies of this mail, because the
> first one I sent from an address subscribed to the GCC list but not
> this one.)

My apologies.

Regards,
Nate  

Re: typos

[Veres Lajos]

On Wed, 3 Jul 2013, Martin Jambor wrote:

> > And if the script will be done you should run it for the whole
> > codebase. Otherwise the issues won't be fixed until anybody touches them.
> >
>
> perhaps you should be aware that there are people who prefer exactly
> that, though the discussions so far have been about
> formatting/whitespace problems only.  The reason is simpler history
> browsing which such changes complicate for little gain (I personally
> can cope with it but I see the point).
>
> On the other hand, I think that this would matter much less for lines
> where there are only comments.  So I'd suggest cherry-picking these
> and submitting fixes in them.  If the patch is large, split it into a
> number of patches for easier review.  If there are errors in
> identifiers etc. I assume that needs to be handled on case by case
> basis, although some related cases can certainly be dealt with
> together (and it would upset history a bit so there might even be
> opposition to that).

Around 99% of the typos are in comments and documentations a few of them
are only in function/variable names (living code).
I think it is not really history obtrusive.

I will create a small subset for preview and send it for reviewing.
(I would not do the whole before getting a green signal... It could take
me at least 4-5 hours to review the whole patch...)

-- 
Veres Lajos
vla...@gmail.com
+36 20 438 5909

Re: Git mirror: asan branch

[Thomas Schwinge]

Hi!

On Wed, 3 Jul 2013 00:18:17 +0200, Andreas Schwab  wrote:
> Thomas Schwinge  writes:
> 
> > If I configure my local Git checkout of the GCC Git mirror to include all
> > branches, per ,
> > then I get:
> >
> > fatal: refs/remotes/origin/asan tracks both refs/heads/asan and 
> > refs/remotes/asan
> >
> > Is that a local problem of mine, or a glitch in the gcc.gnu.org Git
> > repository configuration?
> 
> It's a bug in the remotes configuration.  The two remotes should be
> stored into different namespaces (eg refs/remotes/origin/heads/* and
> refs/remotes/origin/remotes/*), instead of trying to merge them
> together.

OK, that of course works, but from the wiki page I got the idea that it
explicitly was meant to merge these together.  So assuming this used to
work in the past, I wonder what so that it no longer does; such as Git
allowing such duplicates merging in the past, and/or was the intersection
of refs/remotes/* and refs/heads/* meant to be the empty set (then I
assume the merging would work, too), but no longer is?


Grüße,
 Thomas


pgp_ptpHtlMiu.pgp
Description: PGP signature

Re: Git mirror: asan branch

[Jason Merrill]

On 07/03/2013 02:47 AM, Thomas Schwinge wrote:

OK, that of course works, but from the wiki page I got the idea that it
explicitly was meant to merge these together.  So assuming this used to
work in the past, I wonder what so that it no longer does; such as Git
allowing such duplicates merging in the past, and/or was the intersection
of refs/remotes/* and refs/heads/* meant to be the empty set (then I
assume the merging would work, too), but no longer is?


Hmm, it looks like I wrote that up without actually doing it myself, 
oops.  I'll correct the wiki.


Jason

GNU Tools Cauldron 2013 - Registrations are now closed (plus FAQ)

[Diego Novillo]

An update on this year's Cauldron.

We have reached the maximum number of attendees that we can
accept.  Registrations are now closed.  If you still wish to
attend, contact us at tools-cauldron-ad...@googlegroups.com.
We have started a waiting list and will let you know if a slot
opens up

If you had registered but will no longer be able to attend,
please let us know so we can free up that slot for someone else.

Some miscellaneous notes for recent questions:

- The first night, we will meet at the Computer History Museum
  (http://www.computerhistory.org/directions/).  Registration
  starts at 18:30.  There will be a buffet dinner from 19:00 to
  21:00.

- Public transit directions from the Hotel Avante to the Google
  Campus are available online (e.g., http://goo.gl/maps/uKMUH)

- The conference will be held at Building 1200 (1200 Charleston
  Rd, Mountain View).  We will be using the conference rooms
  Tambourine and Triangle.

- We will likely be able to record all the presentations.  More
  details to follow.

- If you are presenting, you may bring your laptop or a usb stick
  with your presentation in pdf format.  There is wireless
  connectivity available.



Diego.

Remove the __GXX_EXPERIMENTAL_CXX0X__?

[Ed Smith-Rowland]

While thinking about C++ n3694 feature test macros I noticed we still define 
__GXX_EXPERIMENTAL_CXX0X__ macro in c-family/c-cppbuiltin.c.
We got rid of all uses of it in libstdc++.
I propose we get rid of it here too.
User's shouldn't be relying on it.  No?

OTOH, it may have been a proxy for __cplusplus for users for a good while.  
People may still be using it even if the library no longer uses it.

What do folks think?

Error: no such instruction: `eovq -32(%rbp),%rdx'

[Dmitry Mikushin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear all,

With gcc-4.7-20130629 and binutils-2.23.2 I'm getting

Error: no such instruction: `eovq -32(%rbp),%rdx'

There was no such issue with May' gcc snapshot and binutils-2.22. Is it
a binutils-specific problem? Which version of binutils is known to work
well with gcc-4.7-20130629 ?

Thanks,
- - D.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJR1JpTAAoJENwm3+sbf/pMvYoH/2/eao48G2782OaR3654uvJU
xdFODidyTMFQXDIF3KXqYFl1AplPN5q95Te71RiAuuqyZLcIjPP3QzrYprgqmtaW
RaOLYZ+qHjBlaBK7R8nsERZEGw+C2wcafHah9SFYTTJJWRl2kdita+z/KytlGPlc
qhpv64sT0nSeQxDzLca2bzEmveIYfXM/FdPC9GD8tH5tMKeKawwaqN4pnKR9Y9DM
9LyRKWW/CcjisJrrks2UotrlcMuyfw92VWYEj4G80ildDA3ISLfgeX3z3z9lK688
ugmJxKxghuzr988MILPXzqsFI5+0OF3OVqg+7Mc5Rl6A9HnRFj16fj+c+OtAJB4=
=fivA
-END PGP SIGNATURE-

Re: Remove the __GXX_EXPERIMENTAL_CXX0X__?

[Marc Glisse]

On Wed, 3 Jul 2013, Ed Smith-Rowland wrote:

While thinking about C++ n3694 feature test macros I noticed we still define 
__GXX_EXPERIMENTAL_CXX0X__ macro in c-family/c-cppbuiltin.c.

We got rid of all uses of it in libstdc++.
I propose we get rid of it here too.
User's shouldn't be relying on it.  No?

OTOH, it may have been a proxy for __cplusplus for users for a good while. 
People may still be using it even if the library no longer uses it.


What do folks think?


Please keep it. Removing it won't gain you anything, and people do rely on 
it.


--
Marc Glisse

Re: Error: no such instruction: `eovq -32(%rbp),%rdx'

[H.J. Lu]

On Wed, Jul 3, 2013 at 2:40 PM, Dmitry Mikushin  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dear all,
>
> With gcc-4.7-20130629 and binutils-2.23.2 I'm getting
>
> Error: no such instruction: `eovq -32(%rbp),%rdx'
>
> There was no such issue with May' gcc snapshot and binutils-2.22. Is it
> a binutils-specific problem? Which version of binutils is known to work
> well with gcc-4.7-20130629 ?
>

I assume it is x86-64.  Do you have a testcase?
I couldn't find anything in GCC x86 backend to
generate "eovq".  Do you have a typo in asm
statement?

--
H.J.

Re: Remove the __GXX_EXPERIMENTAL_CXX0X__?

[Gabriel Dos Reis]

On Wed, Jul 3, 2013 at 4:39 PM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> While thinking about C++ n3694 feature test macros I noticed we still define
> __GXX_EXPERIMENTAL_CXX0X__ macro in c-family/c-cppbuiltin.c.
> We got rid of all uses of it in libstdc++.
> I propose we get rid of it here too.
> User's shouldn't be relying on it.  No?
>
> OTOH, it may have been a proxy for __cplusplus for users for a good while.
> People may still be using it even if the library no longer uses it.
>
> What do folks think?

Deprecate it for 4.9.x.
Remove it later.  We don't need to keep around
this macro which has been obsolete for at least
two releases.

-- Gaby

Re: typos

[Veres Lajos]

On Wed, 3 Jul 2013, Veres Lajos wrote:

> Around 99% of the typos are in comments and documentations a few of them
> are only in function/variable names (living code).
> I think it is not really history obtrusive.
>
> I will create a small subset for preview and send it for reviewing.
> (I would not do the whole before getting a green signal... It could take
> me at least 4-5 hours to review the whole patch...)

http://lavela.hu/gcc.misspell-fixer.20130704.notrevised.patch.bz2
This is the patch generated by the misspell fixer script.
(This is the patch against the whole tree.)
I did NOT reviewed it yet.
What do you think could it be usefull? Should I review the file?
Probably I could remove some false positives, but I am not a C expert.

-- 
Veres Lajos
vla...@gmail.com
+36 20 438 5909

Re: Error: no such instruction: `eovq -32(%rbp),%rdx'

[Anthony Foiani]

Dmitry Mikushin  writes:

> Error: no such instruction: `eovq -32(%rbp),%rdx'

That's only a one-bit error away from "movq ..."

('m' = 0x6d = 0b 0110 1101,
 'e' = 0x65 = 0b 0110 0101)

Maybe run memory tester overnight?

(This is from personal experience -- I had a bad stick of RAM that
caused all sorts of bizarre compile problems.  I eventually isolated
the problem and replaced the DIMM; the compile problems went away.)

Good luck!

Best regards,
Anthony Foiani

La mejor base de datos de Mexico

[Su Empresa]

La mejor base de datos Mexicana a su alcance

10 millones de registros mayores de edad
765 mil empresas con datos completos

Y por si fuera poco:

3 suites de software para windows y Mac
150 servidores SMTP ilimitados para envio masivo de correos
Videotutoriales de uso

Todo actualizado a Julio 2013

Lo invitamos a conocer lo que podemos hacer a favor de su empresa en:
http://fur.ly/9mwh