Re: Committing via git
On 26 February 2016 at 20:34, Jeff Law wrote: > Yup. Many folks are successfully using git-svn. There' instructions > somewhere on the gcc.gnu.org site for setting that up. At https://gcc.gnu.org/wiki/GitMirror
Re: Warning for converting (possibly) negative float/double to unsigned int
On 26/02/16 21:28, Bradley Lucier wrote: > Any advice on how to proceed? I'd be willing to write and test the few > lines of code myself if I knew where to put them. The best thing, rather than warning, would be to define this conversion as a GCC extension and implement it consistently everywhere. Then we wouldn't need a warning, and there'd be one fewer trap. Andrew.
Re: Warning for converting (possibly) negative float/double to unsigned int
On Sat, Feb 27, 2016 at 10:39:59AM +, Andrew Haley wrote: > On 26/02/16 21:28, Bradley Lucier wrote: > > Any advice on how to proceed? I'd be willing to write and test the few > > lines of code myself if I knew where to put them. > > The best thing, rather than warning, would be to define this > conversion as a GCC extension and implement it consistently > everywhere. Then we wouldn't need a warning, and there'd be > one fewer trap. I disagree. That would slow down most of uses that use it when they know the floating point value must be non-negative, for the benefit of the few that invoke implementation defined behavior. Just use -fsanitize=float-cast-overflow and you will be notified at runtime when you run into this. E.g. (/lib64/libubsan.so.0+0x9202): runtime error: value -2 is outside the range of representable values of type 'unsigned int' Jakub
Re: Warning for converting (possibly) negative float/double to unsigned int
On 02/26/2016 09:28 PM, Bradley Lucier wrote: Perhaps this question is appropriate for the gcc mail list. Converting a float/double to unsigned int is undefined if the result would be negative when converted to a signed int. x86-64 and arm treat this condition differently---x86-64 returns a value whose bit pattern is the same as the bit pattern for converting to signed int, and arm returns zero. So it would be nice to have a warning that this will (or could) happen. I couldn't find such a warning in the GCC manual or in the GCC code base. prog.cc:4:23: warning: overflow in implicit constant conversion [-Woverflow] unsigned int z = -2.0; ^~~ prog.cc:5:12: warning: conversion to 'unsigned int' from 'double' may alter its value [-Wfloat-conversion] return x; ^ Both warnings exist since quite a long time (10 years?), the latter under the more general -Wconversion: https://gcc.gnu.org/wiki/NewWconversion#Frequently_Asked_Questions Cheers, Manuel.
Re: [isocpp-parallel] Proposal for new memory_order_consume definition
On Thu, Feb 25, 2016 at 04:46:50PM -0800, Hans Boehm wrote:
> If carries_dependency affects semantics, then it should not be an attribute.
I am not picky about the form of the marking.
> The original design, or at least my understanding of it, was that it not
> have semantics; it was only a suggestion to the compiler that it should
> preserve dependencies instead of inserting a fence at the call site.
> Dependency-based ordering would be preserved in either case. But I think
> we're moving away from that view towards something that doesn't quietly add
> fences.
Yes, we do need to allow typical implementations to avoid quiet fence
addition.
> I do not think we can quite get away with defining a dependency in a way
> that is unconditionally preserved by existing compilers, and thus I think
> that we do probably need annotations along the dependency path. I just
> don't see a way to otherwise deal with the case in which a compiler infers
> an equivalent pointer and dereferences that instead of the original. This
> can happen under so many (unlikely but) hard-to-define conditions that it
> seems undefinable in an implementation-independent manner. "If the
> implementation is able then " is, in my opinion, not
> acceptable standards text.
Hmmm...
But we do already have something very similar with signed integer
overflow. If the compiler can see a way to generate faster code that
does not handle the overflow case, then the semantics suddenly change
from twos-complement arithmetic to something very strange. The standard
does not specify all the ways that the implementation might deduce that
faster code can be generated by ignoring the overflow case, it instead
simply says that signed integer overflow invoked undefined behavior.
And if that is a problem, you use unsigned integers instead of signed
integers.
So it seems that we should be able to do something very similar here.
If you don't use marking, and the compiler deduces that a given pointer
that carries a given dependency is equal to some other pointer not
carrying that same dependency, there is no dependency ordering. And,
just as with the signed-integer-overflow case, if that is a problem for
you, you can mark the pointers that you intend to carry dependencies.
In both the signed-integer-overflow and pointer-value-deduction cases,
most use cases don't need to care. In the integer case, this is because
most use cases have small integer values that don't overflow. In the
pointer case, this is because when the data structure is composed of
lots of heap-allocated data items, the compiler really cannot deduce
anything.
Other safe pointer use cases involve statically allocated data items
whose contents are compile-time constants (thus avoiding the need for
any sort of ordering) and sentinel data items (as in the Linux kernel's
cicular linked lists) where there is no dereferencing.
> Thus I see no way to both avoid adding syntax to functions that preserve
> dependencies and continue to allow existing transformations that remove
> dependencies we care about, e.g. due to equality comparisons. We can
> hopefully ensure that without annotations compilers break things with very
> low probability, so that there is a reasonable path forward for existing
> code relying on dependency ordering (which currently also breaks with very
> low probability unless you understand what the compiler is doing). But I
> don't see a way for the standard to guarantee correctness without the added
> syntax (or added optimization constraints that effectively assume all
> functions were annotated).
Your second sentence ("We can hopefully ensure...") does give me hope
that we might be able to reach agreement. The intent of P0190R0 is
to define a subset of operations where dependencies will be carried.
Note that P0190R0 does call out comparisons as potentially unsafe.
Thanx, Paul
> On Sat, Feb 20, 2016 at 11:53 AM, Paul E. McKenney <
> paul...@linux.vnet.ibm.com> wrote:
>
> > On Fri, Feb 19, 2016 at 09:15:16PM -0500, Tony V E wrote:
> > > There's at least one easy answer in there:
> > >
> > > > If implementations must support annotation, what form should that
> > > annotation take? P0190R0 recommends the [[carries_dependency]]
> > > attribute, but I am not picky as long as it can be (1) applied
> > > to all relevant pointer-like objects and (2) used in C as well
> > > as C++. ;-)
> > >
> > > If an implementation must support it, then it is not an annotation but a
> > keyword. So no [[]]
> >
> > I would be good with that approach, especially if the WG14 continues
> > to stay away from annotations.
> >
> > For whatever it is worth, the introduction of intrinsics for comparisons
> > that avoid breaking dependencies enables the annotation to remain
> > optional.
> >
> > Thanx, Paul
> >
> > > Sent from my BlackBerry portable Babbage De
Re: Warning for converting (possibly) negative float/double to unsigned int
On 27/02/16 11:53, Jakub Jelinek wrote: > On Sat, Feb 27, 2016 at 10:39:59AM +, Andrew Haley wrote: >> On 26/02/16 21:28, Bradley Lucier wrote: >>> Any advice on how to proceed? I'd be willing to write and test the few >>> lines of code myself if I knew where to put them. >> >> The best thing, rather than warning, would be to define this >> conversion as a GCC extension and implement it consistently >> everywhere. Then we wouldn't need a warning, and there'd be >> one fewer trap. > > I disagree. That would slow down most of uses that use it when they know > the floating point value must be non-negative, for the benefit > of the few that invoke implementation defined behavior. Would it really slow things down significantly? If so, perhaps I can see the point of this restriction. Andrew.
Re: [isocpp-parallel] Proposal for new memory_order_consume definition
On Sat, Feb 27, 2016 at 11:16:51AM -0800, Linus Torvalds wrote: > On Feb 27, 2016 09:06, "Paul E. McKenney" > wrote: > > > > > > But we do already have something very similar with signed integer > > overflow. If the compiler can see a way to generate faster code that > > does not handle the overflow case, then the semantics suddenly change > > from twos-complement arithmetic to something very strange. The standard > > does not specify all the ways that the implementation might deduce that > > faster code can be generated by ignoring the overflow case, it instead > > simply says that signed integer overflow invoked undefined behavior. > > > > And if that is a problem, you use unsigned integers instead of signed > > integers. > > Actually, in the case of there Linux kernel we just tell the compiler to > not be an ass. We use > > -fno-strict-overflow That is the one! > or something. I forget the exact compiler flag needed for "the standard is > as broken piece of shit and made things undefined for very bad reasons". > > See also there idiotic standard C alias rules. Same deal. For which we use -fno-strict-aliasing. > So no, standards aren't that important. When the standards screw up, the > right answer is not to turn the other cheek. Agreed, hence my current (perhaps quixotic and insane) attempt to get the standard to do something useful for dependency ordering. But if that doesn't work, yes, a fallback position is to get the relevant compilers to provide flags to avoid problematic behavior, similar to -fno-strict-overflow. Thanx, Paul > And undefined behavior is pretty much *always* a sign of "the standard is > wrong". > > Linus
[patch] bug report 69733
I was looking for an easy task to start contributing to gcc, so I
choose a "trivial" bug (69733) from this list (cited in an old message
of Manuel López-Ibáñez):
https://gcc.gnu.org/bugzilla/buglist.cgi?keywords=diagnostic&limit=0&li
st_id=99232&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&query_fo
rmat=advanced&resolution=---
Attached there is the patch with the bugfix and a testcase.
So far so good, but what's the preferred workflow to propose a patch? A
message on this list it's fine, or gcc-pacthes is better suited? Or,
maybe, an attachment to the bug report is the right thing to do?
--daviddiff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 30eef5c..955867c 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -10010,8 +10010,18 @@ grokdeclarator (const cp_declarator *declarator,
if (type_quals != TYPE_UNQUALIFIED)
{
if (SCALAR_TYPE_P (type) || VOID_TYPE_P (type))
- warning (OPT_Wignored_qualifiers,
- "type qualifiers ignored on function return type");
+ {
+source_location loc = input_location;
+if (type_quals & TYPE_QUAL_CONST)
+ loc = declspecs->locations[ds_const];
+else if (type_quals & TYPE_QUAL_VOLATILE)
+ loc = declspecs->locations[ds_volatile];
+else if (type_quals & TYPE_QUAL_RESTRICT)
+ loc = declspecs->locations[ds_restrict];
+
+warning_at (loc, OPT_Wignored_qualifiers,
+"type qualifiers ignored on function return type");
+ }
/* We now know that the TYPE_QUALS don't apply to the
decl, but to its return type. */
type_quals = TYPE_UNQUALIFIED;
diff --git a/gcc/testsuite/g++.dg/diagnostic/pr69733.C b/gcc/testsuite/g++.dg/diagnostic/pr69733.C
new file mode 100644
index 000..4694356
--- /dev/null
+++ b/gcc/testsuite/g++.dg/diagnostic/pr69733.C
@@ -0,0 +1,17 @@
+// PR c++/69733
+// { dg-do compile }
+// { dg-options "-Wall -Wextra -fdiagnostics-show-caret" }
+
+class A {
+private:
+ double val;
+
+public:
+ double const value() const { return val; } // { dg-warning "type qualifiers ignored on function return type" }
+
+/* { dg-begin-multiline-output "" }
+ double const value() const { return val; }
+ ^
+ { dg-end-multiline-output "" } */
+
+};
signature.asc
Description: This is a digitally signed message part
Re: [patch] bug report 69733
Hi, On 28/02/2016 00:29, David Mugnai wrote: I was looking for an easy task to start contributing to gcc, so I choose a "trivial" bug (69733) from this list (cited in an old message of Manuel López-Ibáñez): See: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00720.html Note that in any case patches should go to gcc-patches. Paolo.
