Re: [Mpc-discuss] GNU MPC 1.0 release candidate

[Andreas Enge]

Hi Rob,

thanks for your report.

> Math::MPC (perl) no longer builds against this library because of undefined 
> references to 'mpc_mul_2exp' and 'mpc_div_2exp'.
> Looks like those functions are no longer present - which doesn't bother me 
> greatly.

They have been renamed to mpc_mul_2ui and mpc_div_2ui, to be in line with mpfr.

> Is there a list from which one can easily find *all* alterations that have 
> been made to the API ?

These are all; all important changes are given in the NEWS file in the tarball.

Andreas

G++ namespace association extension

[Jonathan Wakely]

http://gcc.gnu.org/onlinedocs/gcc/Namespace-Association.html says:

"Caution: The semantics of this extension are not fully defined. Users
should refrain from using this extension as its semantics may change
subtly over time. It is possible that this extension will be removed
in future versions of G++. "

Is it safe to assume that the semantics are now fixed to match those
of C++11 inline namespaces and will not change unless removed?

If so I'll prepare a patch for the manual.

Re: G++ namespace association extension

[Jason Merrill]

On 07/09/2012 01:26 PM, Jonathan Wakely wrote:

http://gcc.gnu.org/onlinedocs/gcc/Namespace-Association.html says:

"Caution: The semantics of this extension are not fully defined. Users
should refrain from using this extension as its semantics may change
subtly over time. It is possible that this extension will be removed
in future versions of G++. "

Is it safe to assume that the semantics are now fixed to match those
of C++11 inline namespaces and will not change unless removed?


Yes, but people should use inline namespaces instead; we should 
deprecate this form and then remove it in 4.9.


Jason

Re: [Mpc-discuss] GNU MPC 1.0 release candidate

[Sisyphus]

- Original Message - 
From: "Andreas Enge" 

To: ; 
Sent: Monday, July 09, 2012 5:12 PM
Subject: Re: [Mpc-discuss] GNU MPC 1.0 release candidate



Hi Rob,

thanks for your report.

Math::MPC (perl) no longer builds against this library because of 
undefined references to 'mpc_mul_2exp' and 'mpc_div_2exp'.
Looks like those functions are no longer present - which doesn't bother 
me greatly.


They have been renamed to mpc_mul_2ui and mpc_div_2ui, to be in line with 
mpfr.


Is there a list from which one can easily find *all* alterations that 
have been made to the API ?


These are all; all important changes are given in the NEWS file in the 
tarball.


Thanks.

I notice, too, that the way the availability of the 'double _Complex' and 
'long double _Complex' types is detected has changed. (I don't know if any 
of that should be mentioned in the NEWS file.)
How do we now (portably) determine whether the mpc library we're using 
provides the four mpc_set/get_dc and mpc_set/get/_ldc functions ?

Is it simply a matter of:

#include 
#include 
#ifdef _Complex_I
/* the  four _dc and _ldc functions are available */
#else
/* the four _dc and_ldc functions are unavailable */
#endif

I'm wondering whether it's feasible that, even though complex.h defines 
_Complex_I, the four functions in question might be unavailable.


Cheers,
Rob 

Re: gcc plugin problem

[Ludovic Courtès]

Hi,

mahdi hamzeh  skribis:

> I compiled and built gcc 4.7.0 myself. I am not sure if I build gcc on
> my machine, it would be compiled as c++. How would I check that?

You could run:

  nm /path/to/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/cc1 | \
grep loop_optimizer_init

and check whether you see the C++-mangled symbol or not.

HTH,
Ludo’.

Re: gcc-4.8-20120708 is now available

[Dimitrios Apostolou]

On Mon, 8 Jul 2012, gccad...@gcc.gnu.org wrote:


Snapshot gcc-4.8-20120708 is now available on
 ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120708/



Any idea who's responsible for this massive decrease in memory usage? :-)
Valgrind's massif isn't really helping me to track this one. See the 
"memory usage" graph here:


http://teras-ics.mooo.com:8003


Thanks,
Dimitris

Re: gcc plugin problem

[mahdi hamzeh]

Thanks. The problem was naming indeed. I managed to recompile gcc with
c compiler only and the problem is gone.

On Mon, Jul 9, 2012 at 9:35 AM, Ludovic Courtès
 wrote:
> Hi,
>
> mahdi hamzeh  skribis:
>
>> I compiled and built gcc 4.7.0 myself. I am not sure if I build gcc on
>> my machine, it would be compiled as c++. How would I check that?
>
> You could run:
>
>   nm /path/to/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/cc1 | \
> grep loop_optimizer_init
>
> and check whether you see the C++-mangled symbol or not.
>
> HTH,
> Ludo’.
>



-- 
Mahdi Hamzeh
Graduate Research Associate
School of Computing, Informatics, and Decision Systems Engineering (CIDSE)
Arizona State University
http://www.public.asu.edu/~mhamzeh1/

Ad-hoc notes from the "pending patches" BOF at the GNU tools cauldron.

[Hans-Peter Nilsson]

On a whim I hosted a BOF at the GNU tools cauldron yesterday,
titled "pending patches" (no compliance with RFC5434 intended).

This was originally only out of egotistic motives: BUMPing the
"Fix gcc.dg/lower-subreg-1.c failure, revisited" patch at
 (2
months from original) and "Ping again: [RFA:] Caveat for ARM in
gcc-4.7/changes.html: unaligned accesses, take 2" at
, but I
also imagined there was a general need and opportunity to share
grief and maybe discuss patch handling a bit more off-the-record
than through the mailing-lists.

No pretense-silver-bullets were presented, but some of the ideas
that were aired seem worth pursuing.  I'm sure I don't remember
all good ideas (for one, I didn't actually take notes) and my
recollection might not match that of the consensus, so if you
were there (or if you were not) feel very free (as in software)
to follow-up.


Revive DannyB's patch tracker (deceased)?
No; (most) people actually reviewing patches didn't use it.

Automatic testing of submitted patches, with feedback?  Maybe;
might give added confidence in the patch, but not strictly a
patch-review issue.  Might be easier to implement for patches
entered in Bugzilla, where patches are more likely to have
machine-usable mark-up.

Volunteers making sure patches reach the right reviewer as
sometimes good patches aren't CCed to the right people?  This
might even be helped by a tool, somebody mentioned the Linux
scripts/get_maintainer.pl, with proper formatting of the
MAINTAINERS file (file globs to go with the domain of approval).
Also, volunteers (or more tools) to make sure that patches in
Bugzilla are also sent to the gcc-patches list.

More tools' suggestions to simplify patch handling: a tool or
archive-list function to find the archive entry for a certain
message-id.  I know this would help people writing pings.

There were also unspecified suggestions of improvements for
 but on revisiting that
page, I can't see anything I'd like to change ...except maybe
adding a call for volunteers for tasks not requiring paperwork,
for example patch follow-up as per above.  Oh, and instructions
on how to format ping messages to help speedy review;
specifically with the ChangeLog entry, a few lines explaining
the patch and archive URL to the original message.

More context (lines) in patches?  Not as a rule: people doing
review will look up the context anyway.  Mostly up to the patch
author to make any obviousness obvious.

Unfortunately no specific ideas on how to simplify reviewing for
approval-status reviewers, or how to get more reviewers, besides
of course that people are always welcome to comment on patches,
regardless of actual approver status.

brgds, H-P

Re: Ad-hoc notes from the "pending patches" BOF at the GNU tools cauldron.

[Dimitrios Apostolou]

Hi hp, thanks for the notes, I'm just going to highlight my point of view.

Regarding patch pinging, my take is that is should be seldom necessary, 
for example I tend to forget my small patches after sometime. So IMHO 
anyone replying anything is good, especially if he CCs the maintainer 
(Dodji-style :-). As you said, a get_maintainer script would come handy.


It's also the case that I often send RFC patches: patches with comments 
discussing a controversial idea, probably without changelog or regression 
testing. Sometimes I don't even CC anyone since I don't really expect a 
review, I only want to raise discussion.


Unfortunately such patches are 80% probable to be completely ignored. What 
do you think?


Finally, as I mentioned in the BOF it would be useful to be able to 
connect somehow the two patch management systems: bugzilla and ML. I'm not 
quite sure of the way, but here are the ideas:


* Automatically post bugzilla diffs to the ML, but then there is the 
problem of who answers where (hopefully not a problem if the automated 
mail has all subscribed to the bug CC'd).


* Have a field in the bugzilla keeping "related ML threads" URLs. What I 
do now is post a separate comment saying "discussed here" or "posted patch 
here". Not sure if good enough, but on bugs I've not seen it in cases I 
needed to.



Thanks,
Dimitris