Re: [PATCH/AARCH64] Add scheduler for vulcan.

[Virendra Pathak]

Hi James,

> Would you mind taking a look at some of these techniques to see if you can
> reduce the size of the generated automata without causing too much
> trouble for code generation for Vulcan?

Thanks for the review. I will look into this.


with regards,
Virendra Pathak


On Mon, Jul 25, 2016 at 4:03 PM, James Greenhalgh
 wrote:
> On Wed, Jul 20, 2016 at 03:07:45PM +0530, Virendra Pathak wrote:
>> Hi gcc-patches group,
>>
>> Please find the patch for adding the basic scheduler for vulcan
>> in the aarch64 port.
>>
>> Tested the patch with compiling cross aarch64-linux-gcc,
>> bootstrapped native aarch64-unknown-linux-gnu and
>> run gcc regression.
>>
>> Kindly review and merge the patch to trunk, if the patch is okay.
>>
>> There are few TODO in this patch which we have planned to
>> submit in the next submission e.g. crc and crypto
>> instructions, further improving integer & fp load/store
>> based on addressing mode of the address.
>
> Hi Virendra,
>
> Thanks for the patch, I have some concerns about the size of the
> automata that this description generates. As you can see
> (use (automata_option "stats") in the description to enable statistics)
> this scheduler description generates a 10x larger automata for Vulcan than
> the second largest description we have for AArch64 (cortex_a53_advsimd):
>
>   Automaton `cortex_a53_advsimd'
>  9072 NDFA states,  49572 NDFA arcs
>  9072 DFA states,   49572 DFA arcs
>  4050 minimal DFA states,   23679 minimal DFA arcs
>   368 all insns 11 insn equivalence classes
> 0 locked states
>   28759 transition comb vector els, 44550 trans table els: use simple vect
>   44550 min delay table els, compression factor 2
>
>   Automaton `vulcan'
> 103223 NDFA states,  651918 NDFA arcs
> 103223 DFA states,   651918 DFA arcs
> 45857 minimal DFA states,   352255 minimal DFA arcs
>   368 all insns 28 insn equivalence classes
> 0 locked states
>   429671 transition comb vector els, 1283996 trans table els: use comb vect
>   1283996 min delay table els, compression factor 2
>
> Such a large automaton increases compiler build time and memory consumption,
> often for little scheduling benefit.
>
> Normally such a large automaton comes from using a large repeat
> expression (*). For example in your modeling of divisions:
>
>> +(define_insn_reservation "vulcan_div" 13
>> +  (and (eq_attr "tune" "vulcan")
>> +   (eq_attr "type" "sdiv,udiv"))
>> +  "vulcan_i1*13")
>> +
>> +(define_insn_reservation "vulcan_fp_divsqrt_s" 16
>> +  (and (eq_attr "tune" "vulcan")
>> +   (eq_attr "type" "fdivs,fsqrts"))
>> +  "vulcan_f0*8|vulcan_f1*8")
>> +
>> +(define_insn_reservation "vulcan_fp_divsqrt_d" 23
>> +  (and (eq_attr "tune" "vulcan")
>> +   (eq_attr "type" "fdivd,fsqrtd"))
>> +  "vulcan_f0*12|vulcan_f1*12")
>
> In other pipeline models, we try to keep these repeat numbers low to avoid
> the large state-space growth they cause. For example, the Cortex-A57
> pipeline model describes them as:
>
>   (define_insn_reservation "cortex_a57_fp_divd" 16
> (and (eq_attr "tune" "cortexa57")
>  (eq_attr "type" "fdivd, fsqrtd, neon_fp_div_d, neon_fp_sqrt_d"))
> "ca57_cx2_block*3")
>
> The lower accuracy is acceptable because of the nature of the scheduling
> model. For a machine with an issue rate of "4" like Vulcan, each cycle the
> compiler models it tries to find four instructions to schedule, before it
> progresses the state of the automaton. If an instruction is modelled as
> blocking the "vulcan_i1" unit for 13 cycles, that means up to 52
> instructions that the scheduler would have to find before issuing the next
> instruction which would use vulcan_i1. Because scheduling works within
> basic-blocks, the chance of finding so many independent instructions is
> extremely low, and so you'd never see the benefit of the 13-cycle block.
>
> I tried lowering the repeat expressions as so:
>
>> +(define_insn_reservation "vulcan_div" 13
>> +  (and (eq_attr "tune" "vulcan")
>> +   (eq_attr "type" "sdiv,udiv"))
>> +  "vulcan_i1*3")
>> +
>> +(define_insn_reservation "vulcan_fp_divsqrt_s" 16
>> +  (and (eq_attr "tune" "vulcan")
>> +   (eq_attr "type" "fdivs,fsqrts"))
>> +  "vulcan_f0*3|vulcan_f1*3")
>> +
>> +(define_insn_reservation "vulcan_fp_divsqrt_d" 23
>> +  (and (eq_attr "tune" "vulcan")
>> +   (eq_attr "type" "fdivd,fsqrtd"))
>> +  "vulcan_f0*5|vulcan_f1*5")
>
> Which more than halves the size of the generated automaton:
>
>   Automaton `vulcan'
> 45370 NDFA states,  319261 NDFA arcs
> 45370 DFA states,   319261 DFA arcs
> 20150 minimal DFA states,   170824 minimal DFA arcs
>   368 all insns 28 insn equivalence classes
> 0 locked states
>   215565 transition comb vector els, 564200 trans table els: use comb vect
>   564200 min delay table els, compression factor 2
>
> The other technique we use to reduce the 

[Bug target/71869] __builtin_isgreater raises an invalid exception on PPC64 using __float128 inputs.

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71869

--- Comment #2 from Michael Meissner  ---
Author: meissner
Date: Wed Jul 27 04:45:59 2016
New Revision: 238779

URL: https://gcc.gnu.org/viewcvs?rev=238779=gcc=rev
Log:
[gcc]
2016-07-26  Michael Meissner  

PR target/71869
* config/rs6000/rs6000.c (rs6000_generate_compare): Rework
__float128 support when we don't have hardware support, so that
the IEEE built-in functions like isgreater, first call __unordkf3
to make sure neither operand is a NaN, and if both operands are
ordered, do the normal comparison.

[gcc/testsuite]
2016-07-26  Michael Meissner  

PR target/71869
* gcc.target/powerpc/float128-cmp.c: New test to make sure that
IEEE built-in functions handle quiet and signalling NaNs
correctly.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/float128-cmp.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/72708] error on anonymous union in an unnamed namespace

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72708

--- Comment #1 from Andrew Pinski  ---
I don't think so.  Static != internal linkage.  If anything you found a defect
in the C++ language.

[Bug c++/72708] New: error on anonymous union in an unnamed namespace

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72708

Bug ID: 72708
   Summary: error on anonymous union in an unnamed namespace
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In [basic.link], all versions of C++ state that:

  A name having namespace scope (3.3.6) has internal linkage if it is the name
of
  ...
  -- a data member of an anonymous union.

In addition, in [class.union.anon], C++ specifies that:

  Anonymous unions declared in a named namespace or in the global namespace
shall be declared static.

This implies that when an anonymous union is declared without the static
keyword in an unnamed namespace it has internal linkage.

However, G++ rejects the following valid program needlessly insisting that the
anonymous union declaration in the unnamed namespace use the static keyword:

$ cat xyz.c && /build/gcc-71912/gcc/xgcc -B /build/gcc-71912/gcc -S -Wall
-Wextra -Wpedantic -xc++ xyz.c
namespace {
  union { int x; };
}
xyz.c:2:18: error: namespace-scope anonymous aggregates must be static
   union { int x; };
  ^

[Bug c++/72707] New: [4.6/4.7/4.8/4.9/5/6/7 regression] local anonymous union member hides names in the same scope

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72707

Bug ID: 72707
   Summary: [4.6/4.7/4.8/4.9/5/6/7 regression] local anonymous
union member hides names in the same scope
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In [class.union], all versions of the C++ standard starting with 1998 require
that:

  The names of the members of an anonymous union shall be distinct from the
names of any other entity in the scope in which the anonymous union is
declared.

The following invalid test case is accepted by G++, implying that G++ fails to
conform to this requirement.  The test case is rejected by Clang 3.8 and EDG
eccp 4.11.

Prior to version 4.6, GCC rejected this test case with

  error: declaration of ‘int x’ shadows a parameter

This error was removed and the regression introduced in r159383.

$ cat xyz.c && /build/gcc-71912/gcc/xgcc -B /build/gcc-71912/gcc -S -Wall
-Wextra -Wpedantic -xc++ xyz.c
void f (double )
{
  union { int x; };
  x = 0;
}
xyz.c: In function ‘void f(double&)’:
xyz.c:1:17: warning: unused parameter ‘x’ [-Wunused-parameter]
 void f (double )
 ^

[Bug ada/25844] [4.9/5/6/7 regression] ICE on overloaded renames

[anhvofrcaus at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25844

Anh Vo  changed:

   What|Removed |Added

 CC||anhvofrcaus at gmail dot com

--- Comment #17 from Anh Vo  ---
These codes compile fine under GNAT-GPL-2016.

Re: [PATCH], Fix PR 71869, Correctly implement isgreater, etc. on PowerPC __float128

[Segher Boessenkool]

On Tue, Jul 26, 2016 at 08:04:32PM -0400, Michael Meissner wrote:
> > dg-do compile?  That's not testing much then, as an executable test!
> 
> Good catch.  Hopefully, third time is a charm.  I verified that changing the
> dg-do compile to dg-do run did run properly on a big endian power7 (both 
> 32-bit
> and 64-bit) and a little endian power8.
> 
> [gcc]
> 2016-07-26  Michael Meissner  
> 
>   PR target/71869
>   * config/rs6000/rs6000.c (rs6000_generate_compare): Rework
>   __float128 support when we don't have hardware support, so that
>   the IEEE built-in functions like isgreater, first call __unordkf3
>   to make sure neither operand is a NaN, and if both operands are
>   ordered, do the normal comparison.
> 
> [gcc/testsuite]
> 2016-07-26  Michael Meissner  
> 
>   PR target/71869
>   * gcc.target/powerpc/float128-cmp.c: New test to make sure that
>   IEEE built-in functions handle quiet and signalling NaNs
>   correctly.

Okay for trunk.  Okay for 6 once there is independent testing (on
gcc-testresults, say) for all affected targets and you aren't comfortable
waiting any longer ;-)


Segher

Re: [Bug tree-optimization] Fix for PR71994

[kugan]

Hi Jeff,

Thanks for your comments.




* tree-ssa-reassoc.c (maybe_optimize_range_tests): Check type
compatibility.

I'd kind of like to see some analysis of how we've got a bool here --
ISTM it ought to have been converted it to the type of the LHS of the
PHI when propagated.


You are right. The problem was with the order of checking tcc_compare 
and calling get_ops. We ended up calling get_ops where we should not.


Bootstrap and regression testing is ongoing. Is this OK for trunk if no 
regressions?


Thanks,
Kugan


gcc/testsuite/ChangeLog:

2016-07-27  Kugan Vivekanandarajah  

* gcc.dg/torture/pr71994.c: New test.

gcc/ChangeLog:

2016-07-27  Kugan Vivekanandarajah  

* tree-ssa-reassoc.c (maybe_optimize_range_tests): Check tcc_comparison
 before calling get_ops.




diff --git a/gcc/testsuite/gcc.dg/torture/pr71994.c 
b/gcc/testsuite/gcc.dg/torture/pr71994.c
index e69de29..8f5e92c 100644
--- a/gcc/testsuite/gcc.dg/torture/pr71994.c
+++ b/gcc/testsuite/gcc.dg/torture/pr71994.c
@@ -0,0 +1,14 @@
+/* PR tree-optimization/71994 */
+/* { dg-do compile } */
+int om, h6;
+
+void eo (void)
+{
+  const int tl = 1;
+  int ln;
+
+  h6 = (om + tl) > 0;
+  ln = om && (om & h6);
+  h6 = om;
+  om = ln < h6;
+}
diff --git a/gcc/tree-ssa-reassoc.c b/gcc/tree-ssa-reassoc.c
index 18cf978..8f2256f 100644
--- a/gcc/tree-ssa-reassoc.c
+++ b/gcc/tree-ssa-reassoc.c
@@ -3520,10 +3520,10 @@ maybe_optimize_range_tests (gimple *stmt)
 push into ops the individual range test arguments
 of the bitwise or resp. and, recursively.  */
  if (TREE_CODE (rhs) == SSA_NAME
- && !get_ops (rhs, code, ,
-   loop_containing_stmt (stmt))
  && (TREE_CODE_CLASS (gimple_assign_rhs_code (stmt))
  != tcc_comparison)
+ && !get_ops (rhs, code, ,
+   loop_containing_stmt (stmt))
  && has_single_use (rhs))
{
  /* Otherwise, push the _234 range test itself.  */

Re: [PATCH], Fix PR 71869, Correctly implement isgreater, etc. on PowerPC __float128

[Michael Meissner]

On Tue, Jul 26, 2016 at 06:26:19PM -0500, Segher Boessenkool wrote:
> On Tue, Jul 26, 2016 at 04:09:01PM -0400, Michael Meissner wrote:
> > > Could you test all five functions please?  Use multiple testcases, maybe.
> > 
> > I decided to write an executable test rather than do more assembly tests.  
> > The
> > patch to rs6000.c is unchanged, and the test now tests all of the comparison
> > operators and functions with various values including quiet NaNs and 
> > signalling
> > NaNs.  It passes on power7 big endian 64-bit, power7 big endian 32-bit, 
> > power8
> > little endian 64-bit, and I ran it on the power9 simulator with hardware
> > float128 support.
> 
> > --- gcc/testsuite/gcc.target/powerpc/float128-cmp.c (revision 0)
> > +++ gcc/testsuite/gcc.target/powerpc/float128-cmp.c (revision 0)
> > @@ -0,0 +1,106 @@
> > +/* { dg-do compile { target { powerpc*-*-linux* } } } */
> > +/* { dg-require-effective-target ppc_float128_sw } */
> > +/* { dg-options "-mvsx -O2 -mfloat128" } */
> 
> dg-do compile?  That's not testing much then, as an executable test!

Good catch.  Hopefully, third time is a charm.  I verified that changing the
dg-do compile to dg-do run did run properly on a big endian power7 (both 32-bit
and 64-bit) and a little endian power8.

[gcc]
2016-07-26  Michael Meissner  

PR target/71869
* config/rs6000/rs6000.c (rs6000_generate_compare): Rework
__float128 support when we don't have hardware support, so that
the IEEE built-in functions like isgreater, first call __unordkf3
to make sure neither operand is a NaN, and if both operands are
ordered, do the normal comparison.

[gcc/testsuite]
2016-07-26  Michael Meissner  

PR target/71869
* gcc.target/powerpc/float128-cmp.c: New test to make sure that
IEEE built-in functions handle quiet and signalling NaNs
correctly.


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 238730)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -21755,8 +21755,8 @@ rs6000_generate_compare (rtx cmp, machin
   else if (!TARGET_FLOAT128_HW && FLOAT128_VECTOR_P (mode))
 {
   rtx libfunc = NULL_RTX;
-  bool uneq_or_ltgt = false;
-  rtx dest = gen_reg_rtx (SImode);
+  bool check_nan = false;
+  rtx dest;
 
   switch (code)
{
@@ -21783,21 +21783,23 @@ rs6000_generate_compare (rtx cmp, machin
 
case UNGE:
case UNGT:
- libfunc = optab_libfunc (le_optab, mode);
+ check_nan = true;
+ libfunc = optab_libfunc (ge_optab, mode);
  code = (code == UNGE) ? GE : GT;
  break;
 
case UNLE:
case UNLT:
- libfunc = optab_libfunc (ge_optab, mode);
+ check_nan = true;
+ libfunc = optab_libfunc (le_optab, mode);
  code = (code == UNLE) ? LE : LT;
  break;
 
case UNEQ:
case LTGT:
- libfunc = optab_libfunc (le_optab, mode);
- uneq_or_ltgt = true;
- code = (code = UNEQ) ? NE : EQ;
+ check_nan = true;
+ libfunc = optab_libfunc (eq_optab, mode);
+ code = (code = UNEQ) ? EQ : NE;
  break;
 
default:
@@ -21805,21 +21807,56 @@ rs6000_generate_compare (rtx cmp, machin
}
 
   gcc_assert (libfunc);
-  dest = emit_library_call_value (libfunc, NULL_RTX, LCT_CONST,
- SImode, 2, op0, mode, op1, mode);
 
-  /* If this is UNEQ or LTGT, we call __lekf2, which returns -1 for less
-than, 0 for equal, +1 for greater, and +2 for nan.  We add 1, to give
-a value of 0..3, and then do and AND immediate of 1 to isolate whether
-it is 0/Nan (i.e. bottom bit is 0), or less than/greater than
-(i.e. bottom bit is 1).  */
-  if (uneq_or_ltgt)
-   {
- rtx add_result = gen_reg_rtx (SImode);
- rtx and_result = gen_reg_rtx (SImode);
- emit_insn (gen_addsi3 (add_result, dest, GEN_INT (1)));
- emit_insn (gen_andsi3 (and_result, add_result, GEN_INT (1)));
- dest = and_result;
+  if (!check_nan)
+   dest = emit_library_call_value (libfunc, NULL_RTX, LCT_CONST,
+   SImode, 2, op0, mode, op1, mode);
+
+  /* The library signals an exception for signalling NaNs, so we need to
+handle isgreater, etc. by first checking isordered.  */
+  else
+   {
+ rtx ne_rtx, normal_dest, unord_dest;
+ rtx unord_func = optab_libfunc (unord_optab, mode);
+ rtx join_label = gen_label_rtx ();
+ rtx join_ref = gen_rtx_LABEL_REF (VOIDmode, join_label);
+ rtx unord_cmp = gen_reg_rtx (comp_mode);
+
+
+ /* Test 

[Bug target/72103] ICE with gcc 7 for povray benchmark

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72103

Alan Modra  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|7.0 |5.5

--- Comment #7 from Alan Modra  ---
Fixed

Re: [PATCH], Fix PR 71869, Correctly implement isgreater, etc. on PowerPC __float128

[Segher Boessenkool]

On Tue, Jul 26, 2016 at 04:09:01PM -0400, Michael Meissner wrote:
> > Could you test all five functions please?  Use multiple testcases, maybe.
> 
> I decided to write an executable test rather than do more assembly tests.  The
> patch to rs6000.c is unchanged, and the test now tests all of the comparison
> operators and functions with various values including quiet NaNs and 
> signalling
> NaNs.  It passes on power7 big endian 64-bit, power7 big endian 32-bit, power8
> little endian 64-bit, and I ran it on the power9 simulator with hardware
> float128 support.

> --- gcc/testsuite/gcc.target/powerpc/float128-cmp.c   (revision 0)
> +++ gcc/testsuite/gcc.target/powerpc/float128-cmp.c   (revision 0)
> @@ -0,0 +1,106 @@
> +/* { dg-do compile { target { powerpc*-*-linux* } } } */
> +/* { dg-require-effective-target ppc_float128_sw } */
> +/* { dg-options "-mvsx -O2 -mfloat128" } */

dg-do compile?  That's not testing much then, as an executable test!


Segher

[PATCH 1/2] Add a STATIC_ASSERT on sizeof (struct cp_token)

[David Malcolm]

On Mon, 2016-07-25 at 10:36 +0200, Richard Biener wrote:
> On Fri, Jul 22, 2016 at 4:11 PM, Jakub Jelinek 
> wrote:
> > On Fri, Jul 22, 2016 at 10:33:50AM -0400, David Malcolm wrote:
> > > gcc/cp/ChangeLog:
> > >   * parser.h (struct cp_token): Add a STATIC_ASSERT on the
> > >   size of the struct.
> > > ---
> > >  gcc/cp/parser.h | 9 +
> > >  1 file changed, 9 insertions(+)
> > > 
> > > diff --git a/gcc/cp/parser.h b/gcc/cp/parser.h
> > > index ccbace9..8c1de57 100644
> > > --- a/gcc/cp/parser.h
> > > +++ b/gcc/cp/parser.h
> > > @@ -71,6 +71,15 @@ struct GTY (()) cp_token {
> > >  "|| (%1.type == CPP_DECLTYPE)"))) u;
> > >  };
> > > 
> > > +/* The C++ frontend lexes everything first, and keeps the tokens
> > > +   in memory, so there are possibly millions of tokens in
> > > memory.
> > > +   Ensure that we don't accidentally grow the structure.  */
> > > +STATIC_ASSERT (sizeof (cp_token) ==
> > > +(2 // "type" and "keyword"
> > > + + 1 // "flags"
> > > + + 1 // bitfields
> > > + + 4 // location_t
> > > + + sizeof (void *))); // union
> > 
> > Doesn't that assume way too much on the host data layout?
> > This can be compiled with weirdo system compilers or on weirdo
> > hosts,
> > I bet we don't really support non-8-bit char hosts, but still this
> > might
> > break somewhere...
> > 
> > The formatting is wrong BTW, == shouldn't appear at the end of
> > line.
> 
> Maybe restrict it to __GNUC__ and __x86_64__ or so.
> 
> Richard.
> 
> > Jakub

Bootstrapped on x86_64-pc-linux-gnu (in conjunction
with the followup patch)

OK for trunk if it passes testing by itself?

gcc/cp/ChangeLog:
* parser.h (struct cp_token): Add a STATIC_ASSERT on the
size of the struct.
---
 gcc/cp/parser.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/gcc/cp/parser.h b/gcc/cp/parser.h
index 2923378..bc961c5 100644
--- a/gcc/cp/parser.h
+++ b/gcc/cp/parser.h
@@ -71,6 +71,23 @@ struct GTY (()) cp_token {
   "|| (%1.type == CPP_DECLTYPE)"))) u;
 };
 
+/* The C++ frontend lexes everything first, and keeps the tokens
+   in memory, so there are possibly millions of tokens in memory.
+
+   Use a STATIC_ASSERT to ensure that we don't accidentally grow
+   the structure.
+
+   To avoid introducing too many assumptions on the host data layout,
+   only enable the assertion when compiling with GCC for a
+   known-good host.  */
+#if defined (__GNUC__) && defined (__x86_64__)
+STATIC_ASSERT (sizeof (cp_token) ==
+  (2 // "type" and "keyword"
+   + 1 // "flags"
+   + 1 // bitfields
+   + 4 // location_t
+   + sizeof (void *))); // union
+#endif /* #if defined (__GNUC__) && defined (__x86_64__) */
 
 /* We use a stack of token pointer for saving token sets.  */
 typedef struct cp_token *cp_token_position;
-- 
1.8.5.3

[PATCH 2/2] Use static_assert for STATIC_ASSERT for C++11 onwards

[David Malcolm]

C++11 has a
  static_assert (COND, MESSAGE)
which gives more readable error messages for STATIC_ASSERT than our
current implementation.

This patch makes us use it if __cplusplus >= 201103L

There's also a provisional static_assert (COND) in C++1z, but presumably
we should wait until that one is fully standardized before using it.

Bootstrapped on x86_64-pc-linux-gnu (in conjunction
with the previous patch)

OK for trunk?

gcc/ChangeLog:
* system.h (STATIC_ASSERT): Use static_assert if building
with C++11 onwards.
---
 gcc/system.h | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gcc/system.h b/gcc/system.h
index 78a7da6..8a17197 100644
--- a/gcc/system.h
+++ b/gcc/system.h
@@ -752,9 +752,14 @@ extern void fancy_abort (const char *, int, const char *) 
ATTRIBUTE_NORETURN;
 #define STATIC_CONSTANT_P(X) (false && (X))
 #endif
 
-/* Until we can use C++11's static_assert.  */
+/* static_assert (COND, MESSAGE) is available in C++11 onwards.  */
+#if __cplusplus >= 201103L
+#define STATIC_ASSERT(X) \
+  static_assert ((X), #X)
+#else
 #define STATIC_ASSERT(X) \
   typedef int assertion1[(X) ? 1 : -1] ATTRIBUTE_UNUSED
+#endif
 
 /* Provide a fake boolean type.  We make no attempt to use the
C99 _Bool, as it may not be available in the bootstrap compiler,
-- 
1.8.5.3

[Bug fortran/71862] [4.9/5/6/7 Regression] ICE in gfc_add_component_ref, at fortran/class.c:241

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71862

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|4.9.4   |7.0

--- Comment #8 from kargl at gcc dot gnu.org ---
fixed on trunk

[Bug fortran/71862] [4.9/5/6/7 Regression] ICE in gfc_add_component_ref, at fortran/class.c:241

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71862

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Jul 26 22:42:49 2016
New Revision: 238774

URL: https://gcc.gnu.org/viewcvs?rev=238774=gcc=rev
Log:
2016-07-22  Steven G. Kargl  

PR fortran/71862
* class.c: Remove assert.  Iterate over component only if non-null.

2016-07-22  Steven G. Kargl  

PR fortran/71862
* gfortran.dg/pr71862.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr71862.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/testsuite/ChangeLog

gcc-5-20160726 is now available

[gccadmin]

Snapshot gcc-5-20160726 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/5-20160726/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch 
revision 238772

You'll find:

 gcc-5-20160726.tar.bz2   Complete GCC

  MD5=eb41dc6b288564073b7a78052c4dfced
  SHA1=4db5359793fc47d1b1a9470228f5b94fa61f5939

Diffs from 5-20160719 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-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.

[Bug c/71949] ATOMIC_FLAG_INIT definition in stdatomic.h

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71949

--- Comment #1 from joseph at codesourcery dot com  ---
ATOMIC_FLAG_INIT is an initializer, not an expression that can be used in 
assignments.

The C11 model is that it may not be valid to do assignments such as

>   atomic_flag f2;
>   f2 =  ATOMIC_FLAG_INIT;

because an atomic object may need extra state that is specially 
initialized before assignments can be carried out on it (hence 
initialization using separate macros from assignment).

See the response to DR#454, explicitly saying ATOMIC_VAR_INIT is only for 
initialization.  Much the same would apply to ATOMIC_FLAG_INIT.

Now, GCC does not support the cases that require extra state to be 
initialized, but this does not make uses of *_INIT in non-initializers 
valid.

Re: [gimplefe] hacking pass manager

[Prathamesh Kulkarni]

On 27 July 2016 at 00:20, Prasad Ghangal  wrote:
> On 20 July 2016 at 18:28, Richard Biener  wrote:
>> On Wed, Jul 20, 2016 at 1:46 PM, Prathamesh Kulkarni
>>  wrote:
>>> On 20 July 2016 at 11:34, Richard Biener  wrote:
 On Tue, Jul 19, 2016 at 10:09 PM, Prasad Ghangal
  wrote:
> On 19 July 2016 at 11:04, Richard Biener  
> wrote:
>> On July 18, 2016 11:05:58 PM GMT+02:00, David Malcolm 
>>  wrote:
>>>On Tue, 2016-07-19 at 00:52 +0530, Prasad Ghangal wrote:
 On 19 July 2016 at 00:25, Richard Biener 
 wrote:
 > On July 18, 2016 8:28:15 PM GMT+02:00, Prasad Ghangal <
 > prasad.ghan...@gmail.com> wrote:
 > > On 15 July 2016 at 16:13, Richard Biener <
 > > richard.guent...@gmail.com>
 > > wrote:
 > > > On Sun, Jul 10, 2016 at 6:13 PM, Prasad Ghangal
 > > >  wrote:
 > > > > On 8 July 2016 at 13:13, Richard Biener <
 > > > > richard.guent...@gmail.com>
 > > wrote:
 > > > > > On Thu, Jul 7, 2016 at 9:45 PM, Prasad Ghangal
 > >  wrote:
 > > > > > > On 6 July 2016 at 14:24, Richard Biener
 > >  wrote:
 > > > > > > > On Wed, Jul 6, 2016 at 9:51 AM, Prasad Ghangal
 > >  wrote:
 > > > > > > > > On 30 June 2016 at 17:10, Richard Biener
 > >  wrote:
 > > > > > > > > > On Wed, Jun 29, 2016 at 9:13 PM, Prasad Ghangal
 > > > > > > > > >  wrote:
 > > > > > > > > > > On 29 June 2016 at 22:15, Richard Biener
 > >  wrote:
 > > > > > > > > > > > On June 29, 2016 6:20:29 PM GMT+02:00,
 > > > > > > > > > > > Prathamesh Kulkarni
 > >  wrote:
 > > > > > > > > > > > > On 18 June 2016 at 12:02, Prasad Ghangal
 > > 
 > > > > > > > > > > > > wrote:
 > > > > > > > > > > > > > Hi,
 > > > > > > > > > > > > >
 > > > > > > > > > > > > > I tried hacking pass manager to execute
 > > > > > > > > > > > > > only given passes.
 > > For this I
 > > > > > > > > > > > > > am adding new member as opt_pass
 > > > > > > > > > > > > > *custom_pass_list to the
 > > function
 > > > > > > > > > > > > > structure to store passes need to execute
 > > > > > > > > > > > > > and providing the
 > > > > > > > > > > > > > custom_pass_list to execute_pass_list()
 > > > > > > > > > > > > > function instead of
 > > all
 > > > > > > > > > > > > passes
 > > > > > > > > > > > > >
 > > > > > > > > > > > > > for test case like-
 > > > > > > > > > > > > >
 > > > > > > > > > > > > > int a;
 > > > > > > > > > > > > > void __GIMPLE (execute ("tree-ccp1", "tree
 > > > > > > > > > > > > > -fre1")) foo()
 > > > > > > > > > > > > > {
 > > > > > > > > > > > > > bb_1:
 > > > > > > > > > > > > >   a = 1 + a;
 > > > > > > > > > > > > > }
 > > > > > > > > > > > > >
 > > > > > > > > > > > > > it will execute only given passes i.e. ccp1
 > > > > > > > > > > > > > and fre1 pass
 > > on the
 > > > > > > > > > > > > function
 > > > > > > > > > > > > >
 > > > > > > > > > > > > > and for test case like -
 > > > > > > > > > > > > >
 > > > > > > > > > > > > > int a;
 > > > > > > > > > > > > > void __GIMPLE (startwith ("tree-ccp1"))
 > > > > > > > > > > > > > foo()
 > > > > > > > > > > > > > {
 > > > > > > > > > > > > > bb_1:
 > > > > > > > > > > > > >   a = 1 + a;
 > > > > > > > > > > > > > }
 > > > > > > > > > > > > >
 > > > > > > > > > > > > > it will act as a entry point to the
 > > > > > > > > > > > > > pipeline and will
 > > execute passes
 > > > > > > > > > > > > > starting from given pass.
 > > > > > > > > > > > > Bike-shedding:
 > > > > > > > > > > > > Would it make sense to have syntax for
 > > > > > > > > > > > > defining pass ranges
 > > to execute
 > > > > > > > > > > > > ?
 > > > > > > > > > > > > for instance:
 > > > > > > > > > > > > void __GIMPLE(execute (pass_start :
 > > > > > > > > > > > > pass_end))
 > > > > > > > > > > > > which would execute all the passes within
 > > > > > > > > > > > > range [pass_start,
 > > pass_end],
 > > > > > > > > > > > > which would be convenient if the range is
 > > > > > > > > > 

[Bug c/71939] sole flexible array member in an anonymous structure rejected

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71939

--- Comment #1 from joseph at codesourcery dot com  ---
On Wed, 20 Jul 2016, msebor at gcc dot gnu.org wrote:

> While testing a fix for bug 71912 and comparing the C++ front end results to
> those of the C front end I came across the following test case that's accepted
> in C++ but rejected in C.  By my reading of C11 the test case is valid because
> "members of an anonymous structure or union are considered to be members of 
> the
> containing structure or union" and so struct S should be treated as if it had
> been defined as:

I think the anonymous structures/unions feature is and always has been 
intended to be (in the MS and Plan 9 extensions from which the feature 
came, as well as in C++ and C11) purely a matter of a shorthand for naming 
members of a nested structure or union.  So the nested anonymous structure 
or union is subject to all the constraints applicable to one that is not 
anonymous or not nested inside another structure or union (the case in 
point here), and layout is exactly as if all those structures or unions 
were given names (the point that apparently confused some people enough to 
result in the filing of DR#499).  I.e., there is no bug here.

[Bug fortran/71961] [7 Regression] 178.galgel in SPEC CPU 2000 is miscompiled

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71961

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed|2016-07-21 00:00:00 |

--- Comment #6 from Thomas Koenig  ---
Is anybody working on reducing this?

AFAIK, none of the gfortran developers has access to SPEC.

Re: [PATCH] correct atomic_compare_exchange_n return type (c++/71675)

[Martin Sebor]

On 07/25/2016 05:03 AM, Renlin Li wrote:

Hi Martin,

I observed the following error:

ERROR: gcc.dg/atomic/pr71675.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects : syntax error in target selector "target c11" for
" dg-do 3 compile { target c11 } "

It seems we don't have a c11 effective target check available
in dejagnu target-supports.exp.


Thanks for pointing this out.  I had trouble getting this or any
of the other atomic tests to run on their own with make check-c
RUNTESTFLAGS='atomic.exp'  They simply don't.  I didn't notice
a failure in the full test suite run and since the test compiled
successfully outside DejaGnu I didn't take the time to understand
why it wouldn't run on its own or with the rest of the atomic
subset, or to confirm that the c11 target selector was understood.
Looks like I managed to run into not one but two gotchas with
this trivial test.

I've committed r238766 and replaced the unsupported target selector
with a dg-options directive as Jeff and Jason suggested.

Martin



Thanks,
Renlin


diff --git a/gcc/testsuite/gcc.dg/atomic/pr71675.c
b/gcc/testsuite/gcc.dg/atomic/pr71675.c
new file mode 100644
index 000..0e344ac
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/atomic/pr71675.c
@@ -0,0 +1,32 @@
+/* PR c++/71675 - __atomic_compare_exchange_n returns wrong type for
typed enum
+ */
+/* { dg-do compile { target c11 } } */

[Bug c++/72457] [6/7 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72457

--- Comment #6 from Markus Trippelsdorf  ---
So, perhaps simply:

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 6bcb41a..83fd9a4 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -734,7 +734,7 @@ cx_check_missing_mem_inits (tree fun, tree body, bool
complain)
  || DECL_ARTIFICIAL (index))
continue;
}
-  for (; field != index; field = DECL_CHAIN (field))
+  for (; field != NULL_TREE && field != index; field = DECL_CHAIN (field))
{
  tree ftype;
  if (TREE_CODE (field) != FIELD_DECL

[Bug c++/71833] [4.9/5 regression] ICE on valid C++11 code with nested variadic templates: tree check: accessed elt 0 of tree_vec with 1 elts in coerce_template_parameter_pack, at cp/pt.c:7439

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71833

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Tue Jul 26 20:29:12 2016
New Revision: 238765

URL: https://gcc.gnu.org/viewcvs?rev=238765=gcc=rev
Log:
PR c++/71833 - member template with two parameter packs

* pt.c (coerce_template_parameter_pack): Fix logic for
pack index.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/variadic-nested1.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/pt.c

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[Warren D Smith]

>> But it failed to fully correct the error
>> because, at least with gcc's implementation of stdint.h, only 8,16,32,
>> and 64 are provided.

>These cover the needs of virtually everyone in virtually all cases.

--a bold claim, made with zero evidence presented.  But
since we know that even 40 years ago, PASCAL felt the need to provide
packed boolean arrays, we know that 8-64 failed to cover the needs of
"virtually everyone in virtually all cases."

Looks to me like you just make stuff up.  My claim is: if you build
it, they will come.
People will like the fact that gcc provides a little more than the
bare minimum it is allowed to provide.

Also, I'm somewhat amazed how it is argued to me that a 9-bit machine
the PDP-10 is
covered by C fine, but yet, C insists on having everything a multiple
of 8 bits with padding bits disallowed, and that too is fine, and both
these facts refute me.

Oh.

I've tried to make my critics argue against themselves by giving
examples where their statements contradict decisions they already made
to put X into GCC, but those examples just appears to be ignored by
you all.  Obviously
you feel that you yourselves back when you made the decision to add X,
were being an idiot.  Which is strange, but makes it clear it
ultimately is not I who it criticizing you, it is you who are
criticizing you.

-- 
Warren D. Smith
http://RangeVoting.org  <-- add your endorsement (by clicking
"endorse" as 1st step)

[Bug fortran/72051] gfortran bug - internal compiler error

[wadud.miah at nag dot co.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72051

--- Comment #16 from wadud.miah at nag dot co.uk ---
I guess I just have to wait for a gfortran update in Fedora Core 23?

Re: [PATCH], Fix PR 71869, Correctly implement isgreater, etc. on PowerPC __float128

[Michael Meissner]

On Tue, Jul 26, 2016 at 11:05:32AM -0500, Segher Boessenkool wrote:
> > --- gcc/testsuite/gcc.target/powerpc/float128-cmp.c (revision 0)
> > +++ gcc/testsuite/gcc.target/powerpc/float128-cmp.c (revision 0)
> > @@ -0,0 +1,17 @@
> > +/* { dg-do compile { target { powerpc*-*-linux* } } } */
> > +/* { dg-require-effective-target powerpc_float128_sw_ok } */
> > +/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
> > "-mcpu=power7" } } */
> > +/* { dg-options "-O2 -mcpu=power7 -mfloat128" } */
> > +
> > +#ifndef __FLOAT128__
> > +#error "-mfloat128 is not supported."
> > +#endif
> 
> This should never trigger, it is only there for debug, right?
> 
> > +int
> > +test_isgreater (__float128 a, __float128 b)
> > +{
> > +  return __builtin_isgreater (a, b);
> > +}
> > +
> > +/* { dg-final { scan-assembler "bl __\[gl\]ekf2"} } */
> > +/* { dg-final { scan-assembler "bl __unordkf2" } } */
> 
> There are some extra spaces in that [gl]ekf2 line.
> 
> Could you test all five functions please?  Use multiple testcases, maybe.

I decided to write an executable test rather than do more assembly tests.  The
patch to rs6000.c is unchanged, and the test now tests all of the comparison
operators and functions with various values including quiet NaNs and signalling
NaNs.  It passes on power7 big endian 64-bit, power7 big endian 32-bit, power8
little endian 64-bit, and I ran it on the power9 simulator with hardware
float128 support.

[gcc]
2016-07-26  Michael Meissner  

PR target/71869
* config/rs6000/rs6000.c (rs6000_generate_compare): Rework
__float128 support when we don't have hardware support, so that
the IEEE built-in functions like isgreater, first call __unordkf3
to make sure neither operand is a NaN, and if both operands are
ordered, do the normal comparison.

[gcc/testsuite]
2016-07-26  Michael Meissner  

PR target/71869
* gcc.target/powerpc/float128-cmp.c: New test to make sure that
IEEE built-in functions handle quiet and signalling NaNs
correctly.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 238730)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -21755,8 +21755,8 @@ rs6000_generate_compare (rtx cmp, machin
   else if (!TARGET_FLOAT128_HW && FLOAT128_VECTOR_P (mode))
 {
   rtx libfunc = NULL_RTX;
-  bool uneq_or_ltgt = false;
-  rtx dest = gen_reg_rtx (SImode);
+  bool check_nan = false;
+  rtx dest;
 
   switch (code)
{
@@ -21783,21 +21783,23 @@ rs6000_generate_compare (rtx cmp, machin
 
case UNGE:
case UNGT:
- libfunc = optab_libfunc (le_optab, mode);
+ check_nan = true;
+ libfunc = optab_libfunc (ge_optab, mode);
  code = (code == UNGE) ? GE : GT;
  break;
 
case UNLE:
case UNLT:
- libfunc = optab_libfunc (ge_optab, mode);
+ check_nan = true;
+ libfunc = optab_libfunc (le_optab, mode);
  code = (code == UNLE) ? LE : LT;
  break;
 
case UNEQ:
case LTGT:
- libfunc = optab_libfunc (le_optab, mode);
- uneq_or_ltgt = true;
- code = (code = UNEQ) ? NE : EQ;
+ check_nan = true;
+ libfunc = optab_libfunc (eq_optab, mode);
+ code = (code = UNEQ) ? EQ : NE;
  break;
 
default:
@@ -21805,21 +21807,56 @@ rs6000_generate_compare (rtx cmp, machin
}
 
   gcc_assert (libfunc);
-  dest = emit_library_call_value (libfunc, NULL_RTX, LCT_CONST,
- SImode, 2, op0, mode, op1, mode);
 
-  /* If this is UNEQ or LTGT, we call __lekf2, which returns -1 for less
-than, 0 for equal, +1 for greater, and +2 for nan.  We add 1, to give
-a value of 0..3, and then do and AND immediate of 1 to isolate whether
-it is 0/Nan (i.e. bottom bit is 0), or less than/greater than
-(i.e. bottom bit is 1).  */
-  if (uneq_or_ltgt)
-   {
- rtx add_result = gen_reg_rtx (SImode);
- rtx and_result = gen_reg_rtx (SImode);
- emit_insn (gen_addsi3 (add_result, dest, GEN_INT (1)));
- emit_insn (gen_andsi3 (and_result, add_result, GEN_INT (1)));
- dest = and_result;
+  if (!check_nan)
+   dest = emit_library_call_value (libfunc, NULL_RTX, LCT_CONST,
+   SImode, 2, op0, mode, op1, mode);
+
+  /* The library signals an exception for signalling NaNs, so we need to
+handle isgreater, etc. by first checking isordered.  */
+  else
+   {
+ rtx ne_rtx, normal_dest, unord_dest;
+ rtx unord_func = optab_libfunc (unord_optab, mode);

[Bug fortran/72051] gfortran bug - internal compiler error

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72051

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #15 from kargl at gcc dot gnu.org ---
(In reply to wadud.miah from comment #11)
> this issue has not been fully resolved. Please test with gfortran version
> 5.3.1

The bug is fixed in the 5-branch!  It is fixed in all active
branches.  That is the whole point of the testing that I've
shown.

[Bug fortran/72051] gfortran bug - internal compiler error

[wadud.miah at nag dot co.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72051

--- Comment #14 from wadud.miah at nag dot co.uk ---
Do I need to compile with "-fcheck=mem" to get it working?

[Bug fortran/72051] gfortran bug - internal compiler error

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72051

--- Comment #13 from Martin Liška  ---
Created attachment 39024
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39024=edit
Pre-processed source file

Minimal command line:
gfortran-5 pr72051.f90 -fcheck=mem

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[Richard Kenner]

> And hell, GCC already includes a lot of really really obscure
> builtin functions which are one hell of a lot less common & useful
> than multiply-hi

Which exactly proves the point that people are making: whether
something is "common & useful" is rarely the criteria that's used in
deciding whether a language should include that thing.

> And that isn't because I failed to "learn basic principles about
> language design."

Sorry, but it precisely is.

[Bug fortran/72051] gfortran bug - internal compiler error

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72051

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2016-07-25 00:00:00 |2016-07-26
 Ever confirmed|0   |1

--- Comment #12 from Martin Liška  ---
I can really confirm that it fails with:

$ gcc --version
gcc-5 (SUSE Linux) 5.3.1 20160412 [gcc-5-branch revision 234894]

$ make
make -C /home/marxin/Programming/testcases/pr72051/pFUnit-3.2.7/source all
make[1]: Entering directory
'/home/marxin/Programming/testcases/pr72051/pFUnit-3.2.7/source'
gfortran-5 -c 
-I/home/marxin/Programming/testcases/pr72051/pFUnit-3.2.7/include
-I/home/marxin/Programming/testcases/pr72051/pFUnit-3.2.7/source -g -O0
-fbacktrace -fbounds-check -fcheck=mem -I../include -DBUILD_ROBUST -DGNU
-DLinux -I/home/marxin/Programming/testcases/pr72051/pFUnit-3.2.7/include
-DLONG_PTR -DGNU -o Exception.o Exception.F90
Exception.F90:325:0:

   allocate(this%exceptions(0))
 1
internal compiler error: in wide_int_to_tree, at tree.c:1464

[Bug fortran/72051] gfortran bug - internal compiler error

[wadud.miah at nag dot co.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72051

wadud.miah at nag dot co.uk changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #11 from wadud.miah at nag dot co.uk ---
this issue has not been fully resolved. Please test with gfortran version 5.3.1

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[Richard Kenner]

> It *isn't* "putting every possible feature into every language."
> Did I ever advocate that?

Yes.  When you say "X is a useful feature, therefore we should put it
into language Y", you are indeed implicitly advocating that.  Because
if that were *not* the case, then saying that X is *useful* says
nothing whatever about whether it should be put into Y: there will
be dozens, if not hundreds, of useful feature that will not be in Y.

> Am I making syntax more complicated? No. I am if anything
> suggesting making it simpler by removing arbitrary rules that only
> complicated situation.  Am I making compiler more complicated? No,
> the code to do this was already written (just with different numbers),
> and by doing what I say the compiler could actually be simplified
> in some ways.

You are making the *language* more complicated because you cannot look
at each feature in isolation, but rather must look at how they
interact with the other features of the language, among other issues.

As I said, please study language design concepts before continuing this
discussion.

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[Warren D Smith]

And hell, GCC already includes a lot of really really obscure builtin
functions which
are one hell of a lot less common & useful than multiply-hi
I merely cited div(a,b) because it was one of the least obscure among them.
How about freaking "isgraph" and "_mm_set1_epi32"?

I mean how can you justify building them in, but not this?
You cannot.  And that isn't because I failed to "learn basic principles about
language design."


-- 
Warren D. Smith
http://RangeVoting.org  <-- add your endorsement (by clicking
"endorse" as 1st step)

Re: [PATCH] Remove special streaming of builtins

[Richard Biener]

On July 26, 2016 7:26:46 PM GMT+02:00, "H.J. Lu"  wrote:
>On Mon, Jul 25, 2016 at 4:35 AM, Richard Biener 
>wrote:
>>
>> So I needed to fix that builtins appearing in BLOCK_VARs and the
>solution
>> I came up with accidentially disabled streaming via the special path.
>> Thus the following patch removes the special-casing completely and
>makes
>> the BLOCK_VARs handling work the same way as for regular externs (by
>> streaming a local copy).  We stream each builtin decl once and then
>> refer to it via the decl index (which is cheaper than the special
>> casing).
>>
>> I'm not 100% this solves for example the -fno-math-errno inlining
>> across TUs (it certainly doesn't if you use attribute optimize with
>> -fno-math-errno), but it eventually should by means of having two
>> different BUILT_IN_XXX if they have different behavior.  At least
>> if all relevant bits are set on the function _type_ rather than
>> the decl which I think we still lto-symtab replace with one
>> entity during WPA(?)
>>
>> Well.
>>
>> LTO bootstrapped and tested on x86_64-unknown-linux-gnu
>(c,c++,fortran),
>> bootstrapped on x86_64-unknown-linux-gnu (all), testing in progress.
>>
>> I might have not catched all fndecl compares.
>>
>> Will apply to trunk if testing completes.  As said, maybe followup
>> cleanups possible, at least to lto-opts.c / lto-wrapper.
>>
>> Richard.
>>
>> 2016-07-25  Richard Biener  
>>
>> * cgraph.c (cgraph_node::verify_node): Compare against
>builtin
>> by using DECL_BUILT_IN_CLASS and DECL_FUNCTION_CODE.
>> * tree-chkp.c (chkp_gimple_call_builtin_p): Likewise.
>> * tree-streamer.h (streamer_handle_as_builtin_p): Remove.
>> (streamer_get_builtin_tree): Likewise.
>> (streamer_write_builtin): Likewise.
>> * lto-streamer.h (LTO_builtin_decl): Remove.
>> * lto-streamer-in.c (lto_read_tree_1): Remove assert.
>> (lto_input_scc): Remove LTO_builtin_decl handling.
>> (lto_input_tree_1): Liekwise.
>> * lto-streamer-out.c (lto_output_tree_1): Remove special
>> handling of builtins.
>> (DFS::DFS): Likewise.
>> * tree-streamer-in.c (streamer_get_builtin_tree): Remove.
>> * tree-streamer-out.c (pack_ts_function_decl_value_fields):
>Remove
>> assert.
>> (streamer_write_builtin): Remove.
>>
>> lto/
>> * lto.c (compare_tree_sccs_1): Remove
>streamer_handle_as_builtin_p uses.
>> (unify_scc): Likewise.
>> (lto_read_decls): Likewise.
>>
>
>This caused:
>
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72683

Probably another by-decl built-in function compare in the mpx support.  I have 
fixed the one that triggered on a not mpx capable machine.  Ilya possibly knows 
where the other one(s) are lurking off his head?

Richard.

[Bug fortran/72051] gfortran bug - internal compiler error

[wadud.miah at nag dot co.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72051

--- Comment #10 from wadud.miah at nag dot co.uk ---
I find this a very unusual response :-( What's the purpose of testing other
compilers when the bug is in version 5.3.1? I'm not happy that the ticket has
been closed without asking me whether I am happy with the outcome. I would like
to re-open it and assign it to someone else.

Wadud.

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[Warren D Smith]

It *isn't* "putting every possible feature into every language."
Did I ever advocate that?

It's "putting a feature that you already put there, into the language,
just no longer
arbitrarily selecting certain integer sizes and excluding others."
Am I making syntax more complicated? No. I am if anything
suggesting making it simpler by removing arbitrary rules that only
complicated situation.  Am I making compiler more complicated? No,
the code to do this was already written (just with different numbers),
and by doing what I say the compiler could actually be simplified
in some ways.

And no, I do not think "saving a life" worth of time
is "completely meaningless."

And also, it is actually C's explicit mission to be close to the
machine, trying basically
to provide a user-friendly portable machine-model.  Given that is its
design mission,
it is rather absurd to disallow access to various common machine
primitives like
multiply-hi, shift with carry, etc.  Adding those would in no way
complicate the overall language design, it'd just be another builtin
function just like the ones you already have put in.  If I told you to
remove div(a,b) from GCC because it was a fairly silly complication
and unnecessary feature, that'd be true, and yet you would tell me I
was an idiot.
If I tell you to put in mul(a,b): then it is a less-silly,
more-useful, thing, which
you just (see previous sentence) agreed with me was worthwhile.



-- 
Warren D. Smith
http://RangeVoting.org  <-- add your endorsement (by clicking
"endorse" as 1st step)

[Bug c++/72415] [concepts] ICE in satisfy_predicate_constraint

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72415

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-26
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug fortran/72051] gfortran bug - internal compiler error

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72051

--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to wadud.miah from comment #8)
> Hi kargl,
> 
> I am getting the bug with gfortran 5.3.1. could you try to reproduce the bug
> with that version?
> 
> Regards,
> Wadud.

It compiles with
gcc version 4.9.4 20160726 (prerelease) (GCC) 
gcc version 5.4.1 20160726 (GCC) 

I don't have 5.3.1 and don't intend to install it.

[Bug fortran/72698] [5/6/7 Regression] ICE in lhd_incomplete_type_error, at langhooks.c:205

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72698

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-26
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|ICE in  |[5/6/7 Regression] ICE in
   |lhd_incomplete_type_error,  |lhd_incomplete_type_error,
   |at langhooks.c:205  |at langhooks.c:205
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed.

[Bug fortran/72699] [6/7 Regression] ICE in gfc_check_dependency, at fortran/dependency.c:1257

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72699

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-26
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |6.2
Summary|ICE in  |[6/7 Regression] ICE in
   |gfc_check_dependency, at|gfc_check_dependency, at
   |fortran/dependency.c:1257   |fortran/dependency.c:1257
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed.

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[Richard Kenner]

> OK, you just said you've used packed nybble arrays a couple of times.
> Multiplying you by 100,000 that proves if you put it in GCC,
> you'd save 200,000 programmer hours, which is equivalent to saving
> over 2 lives.

I would suggest that you spend time learning basic principles about
language design and better understand the concept that not all languages
are meant to be used in the same way and for the same purpose before
you make any more postings in this thread.

Then you'll understand that the above statement is completely
meaningless.  You very specifically *do not* want to put every possible
feature into every language.

[Bug c/72705] New: Netgear Router Tech support Number@1 800-653-1176@ Netgear Wireless router tech support number

[andrusmith20168 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72705

Bug ID: 72705
   Summary: Netgear Router Tech support Number@1 800-653-1176@
Netgear Wireless router tech support number
   Product: gcc
   Version: trans-mem
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrusmith20168 at gmail dot com
  Target Milestone: ---

Netgear Wireless Router support @1 800-653-1176@ Netgear router tech support
number, Netgear Wireless router customer service number,Netgear Wireless Router
Technical Support number, Netgear Wireless Router support phone number @@@rv
18006531176 Netgear Wireless Router Support Phone number Netgear Wireless
tech support number +++18006531176+++ Netgear Wireless Router customer service
phone number Netgear Wireless technical support number 18006531176++ Netgear
Wireless Router customer Care phone number Netgear Wireless tech support number
18006531176 Netgear Wireless helpdesk support phone number Netgear Wireless
Customer support phone number 18006531176 Netgear Wireless tech support number
, Netgear Wireless tech support phone number , Netgear Wireless customer
support phone number here $$$##@@ Netgear Wireless tech support number
18006531176 Netgear Wireless Technical support number @@ Netgear Wireless
support phone number 18006531176 Netgear Wireless customer service phone number
Netgear Wireless customer c.a.r.e number Netgear Wireless helpdesk phone number
Netgear Wireless helpline phone number 1800+653+1176 Netgear Wireless contact
phone number 18006531176 Netgear Wireless tech support number , Netgear
Wireless tech support phone number , Netgear Wireless customer support phone
number here $$$##@@ Netgear Wireless tech support number 18006531176 Netgear
Wireless Technical support number @@ Netgear Wireless support phone number
18006531176 Netgear Wireless customer service phone number Netgear Wireless
customer c.a.r.e number Netgear Wireless helpdesk phone number Netgear Wireless
helpline phone number 1800+653+1176 Netgear Wireless contact phone number
Netgear Wireless help number - Netgear Wireless helpline number ; Netgear
Wireless help phone number , Netgear Wireless helpline number , Netgear
Wireless tech support tollfree number , Netgear Wireless support Tele phone
number , Netgear Wireless tech support Tele phone number , Netgear Wireless
tech support contact number , Netgear Wireless support contact number , Netgear
Wireless Technical support contact number , Netgear Wireless support phone
number , Netgear Wireless Router support phone number . Netgear Wireless Router
customer support phone number Netgear Wireless customer service number
18006531176 Netgear Wireless call center Netgear Wireless customer service
Routeraddress Netgear Wireless customer c.a.r.e no Netgear Wireless Router
Technical support phone number 18006531176 Netgear Wireless Router tech support
phone number 18006531176 Netgear Wireless Router customer service phone number
18006531176 Netgear Wireless Technical support phone number 18006531176
symantec Technical support phone number 18006531176 Netgear Wireless Technical
support phone number 18006531176 Netgear Wireless customer service tele phone
number 18006531176 Netgear Wireless Router phone number 18006531176 Netgear
Wireless Router customer service phone number 18006531176 Netgear Wireless
Router customer service helpdesk Netgear Wireless Router phone number
18006531176 Netgear Wireless phone number 18006531176cancel subscription
Netgear Wireless Technical support phone number 18006531176 Netgear Wireless
800 phone number 18006531176 snapdeal tollfree customer c.a.r.e number
18006531176 sbi tollfree customer c.a.r.e number 18006531176 airtel tollfree
customer c.a.r.e number 18006531176 hdfc tollfree customer c.a.r.e number
18006531176 bsnl tollfree customer c.a.r.e number 18006531176 icici tollfree
customer c.a.r.e number 18006531176 flipkart tollfree customer c.a.r.e number
18006531176 vodafone tollfree customer c.a.r.e number 18006531176 Netgear
Wireless Technical support phone number 18006531176 Netgear Wireless Technical
support number 18006531176 Netgear Wireless Technical support number
18006531176 symantec Technical support number 18006531176 Netgear Wireless
Router Technical support number 18006531176 Netgear Wireless locations Netgear
Wireless online support Netgear Wireless helpdesk phone number 18006531176
Netgear Wireless customer c.a.r.e Netgear Wireless tech support phone number
18006531176 Netgear Wireless tech support phone number 18006531176 Netgear
Wireless Router tech support phone number 18006531176 Netgear Wireless
locations Netgear Wireless helpdesk phone number 18006531176 service Netgear
Wireless com Netgear Wireless login Netgear Wireless Technical support phone
number 18006531176 Netgear Wireless customer service Netgear Wireless helpdesk
phone 

[Bug c++/72457] [6/7 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72457

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|7.0 |6.2
Summary|[7 Regression] ICE: |[6/7 Regression] ICE:
   |Segmentation fault  |Segmentation fault

--- Comment #5 from Markus Trippelsdorf  ---
Since the patch was backported to gcc-6 branch immediately, gcc-6 is also
affected.

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[Christian Groessler]

Ok, I'm not affiliated with gcc, nor a committer, I just
happen to work on a port to a local architecture.

Your first posts were funny to read, and you ignored the answers,
and now it's getting old.

Not talking for the gcc community, I suggest that you go
away and come back when you have code to implement what
you propose. Then we can continue that discussion.

regards,
chris






On 07/26/16 21:06, Warren D Smith wrote:

OK, you just said you've used packed nybble arrays a couple of times.
Multiplying you by 100,000 that proves if you put it in GCC,
you'd save 200,000 programmer hours, which is equivalent to saving
over 2 lives.

You just said you've written your own double-length multiply.
Same proof.

Thank you for proving my point.

How many deaths does it take before it is worth putting into GCC?
And it isn't like I'm suggesting something hard, or which would be
unattractive to users.

And thanks for the tip on how to do add-with-carry.
That's nice.   Now I have to ask, now you've helpfully demonstrated
how nice it can be, why not put that niceness inside GCC?  I mean, if
GCC already is going to
provide div(a,b) -- it was not me who asked for that, it was GCC that
decided to provide it --
which I could have just got in plain C using  q=a/b; r=a%b;  and depended on
optimizer, zero thought required -- then how can just justify GCC
*not* providing addc(a,b) when it is trickier for the programmer, so
you are clearly providing something more helpful since was more
tricky?

Why am I bothering?  You prove my point then act as though you proved opposite.

Concrete examples?  Hell, I suggested stdint.h years and years before
it came along, and I was told I was an idiot.  I suggested making a
lot of library functions be builtins, told I was an idiot, and now lo
and behold, years and years later, gcc makes many library functions be
builtins.  I complained the stdio library was a disaster waiting to
happen with
buffer overflows, told I was an idiot, and lo and behold, years and
years later people keep trying to work around that, with at least two
people having written nonstandard replacement libraries to try for
safety, and huge billions of dollars estimated to be lost due to this
bad design.

Concerning suggestions I've made that never were adopted, I would like
C to have array-bounds checking available as a compiler option.
Also profiling.
I'd like elsif.  I'd like more sophisticated compile time stuff, like right now
they have #if, #elsif, #endif.  Ok, why not #for?  That way we could unroll
loops by "doing the loop at compile time" not runtime.  (Need to make
a language subset intentionally weakened to not be turing complete, i.e. we
want to know for sure the compile always will terminate, but still
precompiler language could be a good deal more powerful than now.) I
could discuss that.
I'd like a compile-time language giving you a fair amount of power, but
below turing-power, and
acting as though it were sensibly designed in from start with similar syntax
(within reason)  to the actual runtime language -- not intentionally
different syntax for no reason aside from trying to annoy people, and
not an obvious crude add-on.
I'd like different parts of my program to be optimized for space, or
for speed -- I get to say for which parts I want which using pragmas.
I'd like addons to support
multiple entry points for routines easy, so I can make coroutines and
"iterators."
(This can be done with present C, but it seems a much bigger pain than
it needs to be.)

Pointer arithmetic is a well known disaster-waiting-to-happen in C,
but of course there are compensating performance benefits...  but
you could get the best of both worlds with ability to declare "safe"
pointers e.g. with bounds checking of them added by compiler and the bounds
created when the pointer is.  Such safety could be turned off with a
compiler option for more speed.  Point is, C arrays and pointers are
very unsafe for a few reasons, but by
adding some compiler options and/or language extensions to allow
adding safe versions
of  that stuff, GCC could make it a lot easier on programmers to get a
lot safer with
near zero effort.

But hey, nearly all those ideas actually require work, meanwhile I
think uint4_t is
nearly trivial by comparison.

[Bug fortran/52153] REAL128 gives extended precision, not quad precision

[a.vogt at fulguritus dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153

Alexander Vogt  changed:

   What|Removed |Added

 CC||a.vogt at fulguritus dot com

--- Comment #11 from Alexander Vogt  ---
This is issue is still present on 6.1.1. Any chance that this gets fixed?
Anything I could do?

[Bug fortran/72698] New: ICE in lhd_incomplete_type_error, at langhooks.c:205

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72698

Bug ID: 72698
   Summary: ICE in lhd_incomplete_type_error, at langhooks.c:205
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

ICE with 7, 6, 5 (bailout with official releases).
Working with 4.9 and 4.8.

Valid code with a zero-length input string :


$ cat z1.f90
module m
contains
   integer function f()
  f = 4
   end
end
program p
   use m
   character(3), parameter :: c = 'abc'
   character(:), allocatable :: z
   allocate (z, source=repeat(c(2:1), f()))
   print *, len(z), '  >>' // z // '<<'
end


$ cat z2.f90
program p
   character(3), parameter :: c = 'abc'
   character(:), allocatable :: z
   allocate (z, source=repeat(c(2:1), 4))
   print *, len(z), '  >>' // z // '<<'
end



$ gfortran-7-20160724 z1.f90
z1.f90:11:0:

allocate (z, source=repeat(c(2:1), f()))

Error: size of variable 'source.3' is too large
z1.f90:11:0:

allocate (z, source=repeat(c(2:1), f()))

internal compiler error: in lhd_incomplete_type_error, at langhooks.c:205
0xa8d51f lhd_incomplete_type_error(unsigned int, tree_node const*, tree_node
const*)
../../gcc/langhooks.c:205
0xea02da size_in_bytes_loc(unsigned int, tree_node const*)
../../gcc/tree.c:2953
0x909ed4 expr_size(tree_node*)
../../gcc/expr.c:11762
0x90a27d store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
../../gcc/expr.c:5610
0x90bad7 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5168
0x7fc726 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3650
0x7fc726 expand_gimple_stmt
../../gcc/cfgexpand.c:3746
0x7feb3e expand_gimple_basic_block
../../gcc/cfgexpand.c:5753
0x804cd6 execute
../../gcc/cfgexpand.c:6368

[Bug fortran/72699] New: ICE in gfc_check_dependency, at fortran/dependency.c:1257

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72699

Bug ID: 72699
   Summary: ICE in gfc_check_dependency, at
fortran/dependency.c:1257
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

ICE with 7, 6 (releases bailout), not with 5.4, 4.9 and 4.8.
Invalid code, with "implicit none" :


$ cat z1.f90
function f() result(z)
   implicit none
   character(:), allocatable :: z
   h = z(1)
   z(1) = h
end


$ gfortran-7-20160724 z1.f90
z1.f90:4:4:

h = z(1)
1
Error: Symbol 'h' at (1) has no IMPLICIT type
z1.f90:4:7:

h = z(1)
   1
Error: The allocatable object 'z' at (1) must have an explicit function
interface or be declared as array
z1.f90:5:3:

z(1) = h
   1
Error: The allocatable object 'z' at (1) must have an explicit function
interface or be declared as array
f951: internal compiler error: in gfc_check_dependency, at
fortran/dependency.c:1257
0x71204b gfc_check_dependency(gfc_expr*, gfc_expr*, bool)
../../gcc/fortran/dependency.c:1257
0x7ad777 realloc_string_callback
../../gcc/fortran/frontend-passes.c:175
0x7b07c9 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:3381
0x7b1912 realloc_strings
../../gcc/fortran/frontend-passes.c:1015
0x6ec14a gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15707
0x6d744a resolve_all_program_units
../../gcc/fortran/parse.c:5855
0x6d744a gfc_parse_file()
../../gcc/fortran/parse.c:6107
0x719b82 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/72699] ICE in gfc_check_dependency, at fortran/dependency.c:1257

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72699

--- Comment #1 from Gerhard Steinmetz  
---

No ICE without explicit "implicit none".
But of course again with added option -fimplicit-none.


$ cat z2.f90
function f() result(z)
   character(:), allocatable :: z
   h = z(1)
   z(1) = h
end

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[Warren D Smith]

OK, you just said you've used packed nybble arrays a couple of times.
Multiplying you by 100,000 that proves if you put it in GCC,
you'd save 200,000 programmer hours, which is equivalent to saving
over 2 lives.

You just said you've written your own double-length multiply.
Same proof.

Thank you for proving my point.

How many deaths does it take before it is worth putting into GCC?
And it isn't like I'm suggesting something hard, or which would be
unattractive to users.

And thanks for the tip on how to do add-with-carry.
That's nice.   Now I have to ask, now you've helpfully demonstrated
how nice it can be, why not put that niceness inside GCC?  I mean, if
GCC already is going to
provide div(a,b) -- it was not me who asked for that, it was GCC that
decided to provide it --
which I could have just got in plain C using  q=a/b; r=a%b;  and depended on
optimizer, zero thought required -- then how can just justify GCC
*not* providing addc(a,b) when it is trickier for the programmer, so
you are clearly providing something more helpful since was more
tricky?

Why am I bothering?  You prove my point then act as though you proved opposite.

Concrete examples?  Hell, I suggested stdint.h years and years before
it came along, and I was told I was an idiot.  I suggested making a
lot of library functions be builtins, told I was an idiot, and now lo
and behold, years and years later, gcc makes many library functions be
builtins.  I complained the stdio library was a disaster waiting to
happen with
buffer overflows, told I was an idiot, and lo and behold, years and
years later people keep trying to work around that, with at least two
people having written nonstandard replacement libraries to try for
safety, and huge billions of dollars estimated to be lost due to this
bad design.

Concerning suggestions I've made that never were adopted, I would like
C to have array-bounds checking available as a compiler option.
Also profiling.
I'd like elsif.  I'd like more sophisticated compile time stuff, like right now
they have #if, #elsif, #endif.  Ok, why not #for?  That way we could unroll
loops by "doing the loop at compile time" not runtime.  (Need to make
a language subset intentionally weakened to not be turing complete, i.e. we
want to know for sure the compile always will terminate, but still
precompiler language could be a good deal more powerful than now.) I
could discuss that.
I'd like a compile-time language giving you a fair amount of power, but
below turing-power, and
acting as though it were sensibly designed in from start with similar syntax
(within reason)  to the actual runtime language -- not intentionally
different syntax for no reason aside from trying to annoy people, and
not an obvious crude add-on.
I'd like different parts of my program to be optimized for space, or
for speed -- I get to say for which parts I want which using pragmas.
I'd like addons to support
multiple entry points for routines easy, so I can make coroutines and
"iterators."
(This can be done with present C, but it seems a much bigger pain than
it needs to be.)

Pointer arithmetic is a well known disaster-waiting-to-happen in C,
but of course there are compensating performance benefits...  but
you could get the best of both worlds with ability to declare "safe"
pointers e.g. with bounds checking of them added by compiler and the bounds
created when the pointer is.  Such safety could be turned off with a
compiler option for more speed.  Point is, C arrays and pointers are
very unsafe for a few reasons, but by
adding some compiler options and/or language extensions to allow
adding safe versions
of  that stuff, GCC could make it a lot easier on programmers to get a
lot safer with
near zero effort.

But hey, nearly all those ideas actually require work, meanwhile I
think uint4_t is
nearly trivial by comparison.




-- 
Warren D. Smith
http://RangeVoting.org  <-- add your endorsement (by clicking
"endorse" as 1st step)

[Bug fortran/72698] ICE in lhd_incomplete_type_error, at langhooks.c:205

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72698

--- Comment #1 from Gerhard Steinmetz  
---

This variant seems to work :


$ cat z3.f90
program p
   character(:), allocatable :: z
   allocate (z, source=repeat('', 4))
   print *, len(z), '  >>' // z // '<<'
end


$ gfortran-7-20160724 z3.f90
$ a.out
   0   >><<

[Bug c++/72457] [7 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72457

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Markus Trippelsdorf  ---
Started with r238688.

Re: [PATCH] accept flexible arrays in struct in unions (c++/71912 - [6/7 regression])

[Jason Merrill]

On 07/23/2016 01:18 PM, Martin Sebor wrote:

+  /* A pair of the first non-static non-empty data members following
+ either the flexible array member, if found, or the zero-length
+ array member otherwise.  AFTER[1] refers to the first such data
+ member of a union that the struct containing the flexible array
+ member or zero-length array is a member, or NULL when no such
+ union exists.  AFTER[0] refers to the first such data member
+ that is not a member of such a union.  */


This is pretty hard to follow, could you add an example?  Why do we want 
to track these separately rather than look at DECL_CONTEXT at diagnostic 
time?



+  /* The type in which an anonymous struct or union containing ARRAY
+ is defined or null if no such anonymous struct or union exists.  */
+  tree anonctx;


It seems clearer to find this at diagnostic time by following TYPE_CONTEXT.


  /* Find the next non-static data member if it exists.  */
  for (next = fld;
   (next = DECL_CHAIN (next))
 && TREE_CODE (next) != FIELD_DECL; );


I think next_initializable_field would be useful here.


   if (TREE_CODE (fld) != TYPE_DECL
  && RECORD_OR_UNION_TYPE_P (fldtype)
- && TYPE_ANONYMOUS_P (fldtype))
+ && VAR_DECL != TREE_CODE (fld)
+ && (FIELD_DECL != TREE_CODE (fld) || !DECL_FIELD_IS_BASE (fld)))


Please put the constant on the RHS of comparisons.

It seems that you're only interested in FIELD_DECL here, so maybe move 
up the



  /* Skip anything that's not a (non-static) data member.  */
  if (TREE_CODE (fld) != FIELD_DECL)
continue;


and remove the checks for TYPE_DECL and VAR_DECL?  For that matter, you 
could also move up the DECL_ARTIFICIAL check so you don't need to check 
DECL_FIELD_IS_BASE.



+ /* Is the member an anonymous struct or union?  */
+ bool anon_p = (!TYPE_ANONYMOUS_P (fldtype)
+|| !DECL_NAME (fld)
+|| anon_aggrname_p (DECL_NAME (fld)));


This looks like anon_p will be true for any non-static data member of 
non-anonymous type?  Maybe you want ANON_AGGR_TYPE_P?



+ /* If this member isn't anonymous and a prior non-flexible array
+member has been seen in one of the enclosing structs, clear
+the FIRST member since it doesn't contribute to the flexible
+array struct's members.  */
+ if (first && !array && !anon_p)
+   fmem->first = NULL_TREE;


Why is this needed?  For a non-anonymous member, presumably we'll give 
an error when analyzing the type of the member on its own, so we 
shouldn't need to complain again here.



  /* Replace the zero-length array if it's been stored and
 reset the after pointer.  */
  if (TYPE_DOMAIN (TREE_TYPE (fmem->array)))
{
  fmem->after[bool (pun)] = NULL_TREE;
  fmem->array = fld;
}


So we silently allow a zero-length array followed by a flexible array?  Why?


+ msg = G_("zero-size array member %qD in an otherwise empty %q#T");
+
+   if (msg && pedwarn (DECL_SOURCE_LOCATION (fmem->array),
+   OPT_Wpedantic, msg, fmem->array, fmemctx))
+ {
+   inform (location_of (t), "in the definition of %q#T", fmemctx);
+
+   /* Prevent the same flexible array member from being diagnosed
+  more than once if it happens to be nested in more than one
+  union and overlap with another member.  This avoids multiple
+  warnings for perverse cases like the the following where
+  U::U1::X::a1 would otherwise be diagnosed first followed by
+  S::U1::X::a1:
+struct S {
+  union U {
+union U1 { struct X { int n1, a1[]; } x1; } u1;
+union U2 { struct X { int n2, a2[]; } x1; } u2;
+  } u;
+} s;
+   */
+   TREE_NO_WARNING (fmem->array) = 1;
+ }


There doesn't seem to be anything that checks TREE_NO_WARNING for the 
zero-size array case.



+   /* Avoid issuing further duiagnostics after the error above.  */


Typo.


  if (fmem == 
  && !TYPE_ANONYMOUS_P (t) && !anon_aggrname_p (TYPE_IDENTIFIER (t)))


I think you want ANON_AGGR_TYPE_P here, too.

I also wonder about integrating this with layout_class_type, since that 
is also looking at layout issues.


Jason

[Bug c/72695] New: Netgear Router Tech support Number@1 844-330-2330@ Netgear Wireless router tech support number

[ckattyperry at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72695

Bug ID: 72695
   Summary: Netgear Router Tech support Number@1 844-330-2330@
Netgear Wireless router tech support number
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ckattyperry at gmail dot com
  Target Milestone: ---

Netgear Wireless Router support @1 844-330-2330@ Netgear router tech support
number, Netgear Wireless router customer service number,Netgear Wireless Router
Technical Support number, Netgear Wireless Router support phone number @@@rv
18443302330 Netgear Wireless Router Support Phone number Netgear Wireless
tech support number +++18443302330+++ Netgear Wireless Router customer service
phone number Netgear Wireless technical support number 18443302330++ Netgear
Wireless Router customer Care phone number Netgear Wireless tech support number
18443302330 Netgear Wireless helpdesk support phone number Netgear Wireless
Customer support phone number 18443302330 Netgear Wireless tech support number
, Netgear Wireless tech support phone number , Netgear Wireless customer
support phone number here $$$##@@ Netgear Wireless tech support number
18443302330 Netgear Wireless Technical support number @@ Netgear Wireless
support phone number 18443302330 Netgear Wireless customer service phone number
Netgear Wireless customer c.a.r.e number Netgear Wireless helpdesk phone number
Netgear Wireless helpline phone number 1844+330+2330 Netgear Wireless contact
phone number 18443302330 Netgear Wireless tech support number , Netgear
Wireless tech support phone number , Netgear Wireless customer support phone
number here $$$##@@ Netgear Wireless tech support number 18443302330 Netgear
Wireless Technical support number @@ Netgear Wireless support phone number
18443302330 Netgear Wireless customer service phone number Netgear Wireless
customer c.a.r.e number Netgear Wireless helpdesk phone number Netgear Wireless
helpline phone number 1844+330+2330 Netgear Wireless contact phone number
Netgear Wireless help number - Netgear Wireless helpline number ; Netgear
Wireless help phone number , Netgear Wireless helpline number , Netgear
Wireless tech support tollfree number , Netgear Wireless support Tele phone
number , Netgear Wireless tech support Tele phone number , Netgear Wireless
tech support contact number , Netgear Wireless support contact number , Netgear
Wireless Technical support contact number , Netgear Wireless support phone
number , Netgear Wireless Router support phone number . Netgear Wireless Router
customer support phone number Netgear Wireless customer service number
18443302330 Netgear Wireless call center Netgear Wireless customer service
Routeraddress Netgear Wireless customer c.a.r.e no Netgear Wireless Router
Technical support phone number 18443302330 Netgear Wireless Router tech support
phone number 18443302330 Netgear Wireless Router customer service phone number
18443302330 Netgear Wireless Technical support phone number 18443302330
symantec Technical support phone number 18443302330 Netgear Wireless Technical
support phone number 18443302330 Netgear Wireless customer service tele phone
number 18443302330 Netgear Wireless Router phone number 18443302330 Netgear
Wireless Router customer service phone number 18443302330 Netgear Wireless
Router customer service helpdesk Netgear Wireless Router phone number
18443302330 Netgear Wireless phone number 18443302330cancel subscription
Netgear Wireless Technical support phone number 18443302330 Netgear Wireless
844 phone number 18443302330 snapdeal tollfree customer c.a.r.e number
18443302330 sbi tollfree customer c.a.r.e number 18443302330 airtel tollfree
customer c.a.r.e number 18443302330 hdfc tollfree customer c.a.r.e number
18443302330 bsnl tollfree customer c.a.r.e number 18443302330 icici tollfree
customer c.a.r.e number 18443302330 flipkart tollfree customer c.a.r.e number
18443302330 vodafone tollfree customer c.a.r.e number 18443302330 Netgear
Wireless Technical support phone number 18443302330 Netgear Wireless Technical
support number 18443302330 Netgear Wireless Technical support number
18443302330 symantec Technical support number 18443302330 Netgear Wireless
Router Technical support number 18443302330 Netgear Wireless locations Netgear
Wireless online support Netgear Wireless helpdesk phone number 18443302330
Netgear Wireless customer c.a.r.e Netgear Wireless tech support phone number
18443302330 Netgear Wireless tech support phone number 18443302330 Netgear
Wireless Router tech support phone number 18443302330 Netgear Wireless
locations Netgear Wireless helpdesk phone number 18443302330 service Netgear
Wireless com Netgear Wireless login Netgear Wireless Technical support phone
number 18443302330 Netgear Wireless customer service Netgear Wireless helpdesk
phone number 

Re: [gimplefe] hacking pass manager

[Prasad Ghangal]

On 20 July 2016 at 18:28, Richard Biener  wrote:
> On Wed, Jul 20, 2016 at 1:46 PM, Prathamesh Kulkarni
>  wrote:
>> On 20 July 2016 at 11:34, Richard Biener  wrote:
>>> On Tue, Jul 19, 2016 at 10:09 PM, Prasad Ghangal
>>>  wrote:
 On 19 July 2016 at 11:04, Richard Biener  
 wrote:
> On July 18, 2016 11:05:58 PM GMT+02:00, David Malcolm 
>  wrote:
>>On Tue, 2016-07-19 at 00:52 +0530, Prasad Ghangal wrote:
>>> On 19 July 2016 at 00:25, Richard Biener 
>>> wrote:
>>> > On July 18, 2016 8:28:15 PM GMT+02:00, Prasad Ghangal <
>>> > prasad.ghan...@gmail.com> wrote:
>>> > > On 15 July 2016 at 16:13, Richard Biener <
>>> > > richard.guent...@gmail.com>
>>> > > wrote:
>>> > > > On Sun, Jul 10, 2016 at 6:13 PM, Prasad Ghangal
>>> > > >  wrote:
>>> > > > > On 8 July 2016 at 13:13, Richard Biener <
>>> > > > > richard.guent...@gmail.com>
>>> > > wrote:
>>> > > > > > On Thu, Jul 7, 2016 at 9:45 PM, Prasad Ghangal
>>> > >  wrote:
>>> > > > > > > On 6 July 2016 at 14:24, Richard Biener
>>> > >  wrote:
>>> > > > > > > > On Wed, Jul 6, 2016 at 9:51 AM, Prasad Ghangal
>>> > >  wrote:
>>> > > > > > > > > On 30 June 2016 at 17:10, Richard Biener
>>> > >  wrote:
>>> > > > > > > > > > On Wed, Jun 29, 2016 at 9:13 PM, Prasad Ghangal
>>> > > > > > > > > >  wrote:
>>> > > > > > > > > > > On 29 June 2016 at 22:15, Richard Biener
>>> > >  wrote:
>>> > > > > > > > > > > > On June 29, 2016 6:20:29 PM GMT+02:00,
>>> > > > > > > > > > > > Prathamesh Kulkarni
>>> > >  wrote:
>>> > > > > > > > > > > > > On 18 June 2016 at 12:02, Prasad Ghangal
>>> > > 
>>> > > > > > > > > > > > > wrote:
>>> > > > > > > > > > > > > > Hi,
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > I tried hacking pass manager to execute
>>> > > > > > > > > > > > > > only given passes.
>>> > > For this I
>>> > > > > > > > > > > > > > am adding new member as opt_pass
>>> > > > > > > > > > > > > > *custom_pass_list to the
>>> > > function
>>> > > > > > > > > > > > > > structure to store passes need to execute
>>> > > > > > > > > > > > > > and providing the
>>> > > > > > > > > > > > > > custom_pass_list to execute_pass_list()
>>> > > > > > > > > > > > > > function instead of
>>> > > all
>>> > > > > > > > > > > > > passes
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > for test case like-
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > int a;
>>> > > > > > > > > > > > > > void __GIMPLE (execute ("tree-ccp1", "tree
>>> > > > > > > > > > > > > > -fre1")) foo()
>>> > > > > > > > > > > > > > {
>>> > > > > > > > > > > > > > bb_1:
>>> > > > > > > > > > > > > >   a = 1 + a;
>>> > > > > > > > > > > > > > }
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > it will execute only given passes i.e. ccp1
>>> > > > > > > > > > > > > > and fre1 pass
>>> > > on the
>>> > > > > > > > > > > > > function
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > and for test case like -
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > int a;
>>> > > > > > > > > > > > > > void __GIMPLE (startwith ("tree-ccp1"))
>>> > > > > > > > > > > > > > foo()
>>> > > > > > > > > > > > > > {
>>> > > > > > > > > > > > > > bb_1:
>>> > > > > > > > > > > > > >   a = 1 + a;
>>> > > > > > > > > > > > > > }
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > it will act as a entry point to the
>>> > > > > > > > > > > > > > pipeline and will
>>> > > execute passes
>>> > > > > > > > > > > > > > starting from given pass.
>>> > > > > > > > > > > > > Bike-shedding:
>>> > > > > > > > > > > > > Would it make sense to have syntax for
>>> > > > > > > > > > > > > defining pass ranges
>>> > > to execute
>>> > > > > > > > > > > > > ?
>>> > > > > > > > > > > > > for instance:
>>> > > > > > > > > > > > > void __GIMPLE(execute (pass_start :
>>> > > > > > > > > > > > > pass_end))
>>> > > > > > > > > > > > > which would execute all the passes within
>>> > > > > > > > > > > > > range [pass_start,
>>> > > pass_end],
>>> > > > > > > > > > > > > which would be convenient if the range is
>>> > > > > > > > > > > > > large.
>>> > > > > > > > > > > >
>>> > > > > > > > > > > > But it would rely on a particular pass
>>> > > > > > > > > > > > pipeline, f.e.
>>> > > 

[Bug c++/72457] [7 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72457

--- Comment #3 from Markus Trippelsdorf  ---
Created attachment 39023
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39023=edit
reduced testcase

[Bug c/72692] New: Netgear Tech support Number@1 844-330-2330@ Netgear Wireless router tech support number

[ckattyperry at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72692

Bug ID: 72692
   Summary: Netgear Tech support Number@1 844-330-2330@ Netgear
Wireless router tech support number
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ckattyperry at gmail dot com
  Target Milestone: ---

Netgear Wireless Router support @1 844-330-2330@ Netgear Wireless router tech
support number, Netgear Wireless router customer service number,Netgear
Wireless Router Technical Support number, Netgear Wireless Router support phone
number @@@rv 18443302330 Netgear Wireless Router Support Phone number
Netgear Wireless tech support number +++18443302330+++ Netgear Wireless Router
customer service phone number Netgear Wireless technical support number
18443302330++ Netgear Wireless Router customer Care phone number Netgear
Wireless tech support number 18443302330 Netgear Wireless helpdesk support
phone number Netgear Wireless Customer support phone number 18443302330 Netgear
Wireless tech support number , Netgear Wireless tech support phone number ,
Netgear Wireless customer support phone number here $$$##@@ Netgear Wireless
tech support number 18443302330 Netgear Wireless Technical support number @@
Netgear Wireless support phone number 18443302330 Netgear Wireless customer
service phone number Netgear Wireless customer c.a.r.e number Netgear Wireless
helpdesk phone number Netgear Wireless helpline phone number 1844+330+2330
Netgear Wireless contact phone number 18443302330 Netgear Wireless tech support
number , Netgear Wireless tech support phone number , Netgear Wireless customer
support phone number here $$$##@@ Netgear Wireless tech support number
18443302330 Netgear Wireless Technical support number @@ Netgear Wireless
support phone number 18443302330 Netgear Wireless customer service phone number
Netgear Wireless customer c.a.r.e number Netgear Wireless helpdesk phone number
Netgear Wireless helpline phone number 1844+330+2330 Netgear Wireless contact
phone number Netgear Wireless help number - Netgear Wireless helpline number ;
Netgear Wireless help phone number , Netgear Wireless helpline number , Netgear
Wireless tech support tollfree number , Netgear Wireless support Tele phone
number , Netgear Wireless tech support Tele phone number , Netgear Wireless
tech support contact number , Netgear Wireless support contact number , Netgear
Wireless Technical support contact number , Netgear Wireless support phone
number , Netgear Wireless Router support phone number . Netgear Wireless Router
customer support phone number Netgear Wireless customer service number
18443302330 Netgear Wireless call center Netgear Wireless customer service
Routeraddress Netgear Wireless customer c.a.r.e no Netgear Wireless Router
Technical support phone number 18443302330 Netgear Wireless Router tech support
phone number 18443302330 Netgear Wireless Router customer service phone number
18443302330 Netgear Wireless Technical support phone number 18443302330
symantec Technical support phone number 18443302330 Netgear Wireless Technical
support phone number 18443302330 Netgear Wireless customer service tele phone
number 18443302330 Netgear Wireless Router phone number 18443302330 Netgear
Wireless Router customer service phone number 18443302330 Netgear Wireless
Router customer service helpdesk Netgear Wireless Router phone number
18443302330 Netgear Wireless phone number 18443302330cancel subscription
Netgear Wireless Technical support phone number 18443302330 Netgear Wireless
844 phone number 18443302330 snapdeal tollfree customer c.a.r.e number
18443302330 sbi tollfree customer c.a.r.e number 18443302330 airtel tollfree
customer c.a.r.e number 18443302330 hdfc tollfree customer c.a.r.e number
18443302330 bsnl tollfree customer c.a.r.e number 18443302330 icici tollfree
customer c.a.r.e number 18443302330 flipkart tollfree customer c.a.r.e number
18443302330 vodafone tollfree customer c.a.r.e number 18443302330 Netgear
Wireless Technical support phone number 18443302330 Netgear Wireless Technical
support number 18443302330 Netgear Wireless Technical support number
18443302330 symantec Technical support number 18443302330 Netgear Wireless
Router Technical support number 18443302330 Netgear Wireless locations Netgear
Wireless online support Netgear Wireless helpdesk phone number 18443302330
Netgear Wireless customer c.a.r.e Netgear Wireless tech support phone number
18443302330 Netgear Wireless tech support phone number 18443302330 Netgear
Wireless Router tech support phone number 18443302330 Netgear Wireless
locations Netgear Wireless helpdesk phone number 18443302330 service Netgear
Wireless com Netgear Wireless login Netgear Wireless Technical support phone
number 18443302330 Netgear Wireless customer service Netgear Wireless helpdesk
phone number 

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[David Brown]

I am assuming you intended to post this on the mailing list, so I have
restored the addresses.

On 26/07/16 19:55, Warren D Smith wrote:
> To the guy who falsely claimed MIPS fails to provide an add with carry
> instruction,
> a google search in 1 minute finds this:
> 
> stackoverflow.com/questions/1281806/adding-two-64-bit-numbers-in-assembly
> 
> I defy you to find any processor not providing add with carry,
> (And I'm not talking about semantic bullshit.  MIPS provides add with
> carry, even if they do not call it that, as this answer shows.)

No, what the MIPS example shows is that you do not need an "add with
carry" instruction in order to handle multi-precision arithmetic.  MIPS
does not have a carry flag, or any sort of condition code register.
This is not an unreasonable design decision - condition code registers
are often bottlenecks that make pipelining or out-of-order scheduling
significantly harder than necessary.  Other RISC architectures without
flag registers include the Alpha and RISC-V.  You use a similar sequence
to the one you found for MIPS for doing multi-precision addition here.

You may note that the MIPS sequence here translates directly to the
sequence:

typedef struct {
  uint32_t lo;
  uint32_t hi;
} pair;

pair addPairs(pair a, pair b) {
  pair r;
  r.lo = a.lo + b.lo;
  r.hi = (r.lo < b.lo);
  r.hi += a.hi;
  r.hi += b.hi;
  return r;
}

I don't have a MIPS target gcc conveniently on hand, but I suspect this
C code would generate pretty much the same sequence of instructions.
And note that the C code here is generic - it is not MIPS specific.

> 
> Now it might be I'm wrong and some computers now not providing it.  If
> so, that is world
> damage caused by GCC.

gcc is an influential project - but not /that/ influential!

Back in the real world, people who design highly successful processor
architectures do so using good, solid technical reasons for their key
design decisions.

>  How so?  Simple.   Code out there is written on C.
> Processor designers observe real world code.  "Aha!" They say. "Real
> word code hardly ever seems to use add-with-carry! I guess we should
> eliminate it!"

Processor designers take their target audience into account.  And most
targets use C (either directly, or indirectly via libraries, VMs, etc.)
for a good deal of critical programs.  So yes, processor designers
consider "how well does this design fit C?".  They don't typically think
of gcc exclusively, but C in general.

> If and when that happens it is a disaster, and the direct cause of
> that disaster, was the
> laziness of writers of such things as GCC.   They cripple the
> programmer, then the hardware guys say "aha! programmers are crippled!
> That proves they like being crippled!" OK?  So it is not merely that
> you are providing a bad product, it is worse (if you are right about
> this) -- actually damaging the world.

But the example you posted showed that there is no need to have access
to the carry flag in C - there is no need to have a carry flag at all.

And when I compiled that code on x86, gcc used the carry flag in order
to generate optimal code with an add and an adc instruction.  It really
is hard to do better.

> 
> Now as my critic said (it is amazing the absurd lengths people will go
> to to pretend
> fossilized crud was a "good decision") a purpose of languages like C
> is to provide a nice set of portable abstractions.

I have to wonder - why are you using C at all?  And why are you using gcc?

> 
> Well, add with carry IS a nice portable abstraction.
> So is multiply Nwide*Nwide --> 2Nwide.
> 
> And as some other critic said, languages have different purposes,
> and PASCAL may have had different purposes than C.
> As usual for my critics, again this was confused, because it was an explicit
> goal of C to get close to the machine.
> 
> That was not so much a goal of PASCAL. It was a goal of C.
> That means it is absurd for C to refuse to provide packed boolean
> arrays while PASCAL does, and also while C already has made uintN_t
> types for various N.
> 
> Also, I believe the original machine was a PDP-9 not PDP-11, not that
> it matters.
> 
> Look, I could go on.  But this is getting silly.

Your first post was silly, and you have gone downhill since then.

> Basically, what happens is
> 1. compiler/language guys do a bad job.
> 2. others point it out.
> 3. CLGs then pretend it was a good decision made by very very wise
> minds for mysterious unknown reasons nobody can explain, or just make
> shit up, or complain anybody
> pointing it out is rude, or mumble about different goals of different
> languages, or invent ludicrous arguments to "justify" situation, or
> argue anybody could implement it
> themselves because language is Turing complete, so no need.
> 4. The real reason they are doing (3) is simple: they are lazy.
> 5. Pointing our their laziness and incompetence is "rude."  But due to the
> always-response of type 3 made by the CLGs to any suggestion whatever,
> 

[Bug c/72691] New: Cisco Router support @1 844-330-2330@ Cisco router tech support number

[ckattyperry at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72691

Bug ID: 72691
   Summary: Cisco Router support @1 844-330-2330@ Cisco router
tech support number
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ckattyperry at gmail dot com
  Target Milestone: ---

Cisco Router support @1 844-330-2330@ Cisco router tech support number, Cisco
router customer service number,Cisco Router Technical Support number, Cisco
Router support phone number @@@rv 18443302330 Cisco Router Support Phone
number Cisco tech support number +++18443302330+++ Cisco Router customer
service phone number Cisco technical support number 18443302330++ Cisco Router
customer Care phone number Cisco tech support number 18443302330 Cisco
helpdesk support phone number Cisco Customer support phone number 18443302330
Cisco tech support number , Cisco tech support phone number , Cisco customer
support phone number here $$$##@@ Cisco tech support number 18443302330 Cisco
Technical support number @@ Cisco support phone number 18443302330 Cisco
customer service phone number Cisco customer c.a.r.e number Cisco helpdesk
phone number Cisco helpline phone number 1844+330+2330 Cisco contact phone
number 18443302330 Cisco tech support number , Cisco tech support phone number
, Cisco customer support phone number here $$$##@@ Cisco tech support number
18443302330 Cisco Technical support number @@ Cisco support phone number
18443302330 Cisco customer service phone number Cisco customer c.a.r.e number
Cisco helpdesk phone number Cisco helpline phone number 1844+330+2330 Cisco
contact phone number Cisco help number - Cisco helpline number ; Cisco help
phone number , Cisco helpline number , Cisco tech support tollfree number ,
Cisco support Tele phone number , Cisco tech support Tele phone number , Cisco
tech support contact number , Cisco support contact number , Cisco Technical
support contact number , Cisco support phone number , Cisco Router support
phone number . Cisco Router customer support phone number Cisco customer
service number 18443302330 Cisco call center Cisco customer service
Routeraddress Cisco customer c.a.r.e no Cisco Router Technical support phone
number 18443302330 Cisco Router tech support phone number 18443302330 Cisco
Router customer service phone number 18443302330 Cisco Technical support phone
number 18443302330 symantec Technical support phone number 18443302330 Cisco
Technical support phone number 18443302330 Cisco customer service tele phone
number 18443302330 Cisco Router phone number 18443302330 Cisco Router customer
service phone number 18443302330 Cisco Router customer service helpdesk Cisco
Router phone number 18443302330 Cisco phone number 18443302330cancel
subscription Cisco Technical support phone number 18443302330 Cisco 844 phone
number 18443302330 snapdeal tollfree customer c.a.r.e number 18443302330 sbi
tollfree customer c.a.r.e number 18443302330 airtel tollfree customer c.a.r.e
number 18443302330 hdfc tollfree customer c.a.r.e number 18443302330 bsnl
tollfree customer c.a.r.e number 18443302330 icici tollfree customer c.a.r.e
number 18443302330 flipkart tollfree customer c.a.r.e number 18443302330
vodafone tollfree customer c.a.r.e number 18443302330 Cisco Technical support
phone number 18443302330 Cisco Technical support number 18443302330 Cisco
Technical support number 18443302330 symantec Technical support number
18443302330 Cisco Router Technical support number 18443302330 Cisco locations
Cisco online support Cisco helpdesk phone number 18443302330 Cisco customer
c.a.r.e Cisco tech support phone number 18443302330 Cisco tech support phone
number 18443302330 Cisco Router tech support phone number 18443302330 Cisco
locations Cisco helpdesk phone number 18443302330 service Cisco com Cisco login
Cisco Technical support phone number 18443302330 Cisco customer service Cisco
helpdesk phone number 18443302330 Cisco support tele phone number 18443302330
Cisco support phone number 18443302330 Cisco Router support phone number
18443302330 Cisco support phone number 18443302330 Cisco locations Cisco
customer service Cisco customer c.a.r.e Cisco helpdesk phone number 18443302330
Cisco customer support phone number 18443302330 Cisco customer support phone
number 18443302330 Cisco Router customer support phone number 18443302330

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[Paul_Koning]

> On Jul 26, 2016, at 2:07 PM, Warren D Smith  wrote:
> 
> To the guy who falsely claimed MIPS fails to provide an add with carry
> instruction,
> a google search in 1 minute finds this:
> 
> stackoverflow.com/questions/1281806/adding-two-64-bit-numbers-in-assembly
> 
> I defy you to find any processor not providing add with carry,
> (And I'm not talking about semantic bullshit.  MIPS provides add with
> carry, even if they do not call it that, as this answer shows.)

Nonsense.

What that example shows is the standard assembly language coding for doing 
multi-precision addition in machines that do NOT have an add-with-carry 
instruction (or, as in the case of MIPS, even the concept of carry).  The 
algorithm is simple: add low order parts, see if the result is unsigned less 
than one of the operands; if yes, add one to the sum of the high order parts.

Incidentally, note that this coding pattern only works for two's complement 
integers.

> ...
> But the thing is, I'm not willing to write that stuff for you unless
> you promise to actually add these things to GCC.  So, will anybody
> make that promise?

I very much doubt it.  You might as well stop trying.

paul

[Bug fortran/72051] gfortran bug - internal compiler error

[wadud.miah at nag dot co.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72051

--- Comment #8 from wadud.miah at nag dot co.uk ---
Hi kargl,

I am getting the bug with gfortran 5.3.1. could you try to reproduce the bug
with that version?

Regards,
Wadud.

[Bug c/72688] New: Norton antivirus tech Support(+(1-855-990-5999)))number usa customer service phone number

[ckattyperry at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72688

Bug ID: 72688
   Summary: Norton antivirus tech
Support(+(1-855-990-5999)))number usa customer service
phone number
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ckattyperry at gmail dot com
  Target Milestone: ---

Norton antivirus tech Support(+(1-855-990-5999)))number usa customer service
phone number
Norton antivirus tech Support(+(1-855-990-5999)))number usa customer service
phone number,Norton antivirus tech support number Norton customer service
number 1855-990-5999 Norton call center 1855-990-5999 Norton customer service
email address 1855-990-5999 Norton customer care no 1855-990-5999 Norton
antivirus technical support phone number 1855-990-5999 Norton antivirus tech
support phone number 1855-990-5999 Norton antivirus customer service phone
number 1855-990-5999 Norton 360 technical support phone number 1855-990-5999
symantec technical support phone number 1855-990-5999 Norton technical support
phone number 1855-990-5999 Norton customer service telephone number
1855-990-5999 ?Norton antivirus phone number 1855-990-5999 Norton antivirus
customer service phone number 1855-990-5999 Norton antivirus customer service
helpdesk Norton antivirus phone number 1855-990-5999 Norton phone number cancel
subscription 1855-990-5999 Norton technical support phone number 1855-990-5999
Norton 855 phone number 1855-990-5999 Norton toll free customer care number sbi
toll free customer care number Norton 360 toll free customer care number toll
free customer care number Norton toll free customer care number icici toll free
customer care number flipkart toll free customer care number vodafone toll free
customer care number Norton technical support phone number Norton technical
support number Norton technical support number symantec technical support
number Norton antivirus technical support number Norton locations Norton online
support Norton helpdesk phone number Norton customer care Norton tech support
phone number Norton tech support phone number Norton antivirus tech support
phone number Norton locations Norton helpdesk phone number service Norton com
Norton login Norton technical support phone number Norton customer service
Norton helpdesk phone number Norton support telephone number Norton support
phone number Norton antivirus support phone number Norton support phone number
Norton locations Norton customer service Norton customer care Norton helpdesk
phone number Norton customer support phone number Norton customer support phone
number Norton antivirus customer support phone number Norton antivirus customer
service phone number Norton antivirus technical support phone number Norton
antivirus tech support phone number Norton antivirus phone number Norton
security center phone number Norton support telephone number Norton 360
technical support phone number symantec technical support phone number Norton
tech support phone number apple technical support phone number usa microsoft
technical support phone number usa Norton technical support phone number usa
Norton technical support phone number usa lenovo technical support phone number
usa epson technical support phone number usa Norton technical support phone
number call Norton support chat with Norton support Norton customer support
Norton antivirus customer service number Norton address Norton call center
Norton helpline Norton helpdesk Norton support site Norton telephone number for
customer support Norton customer service contact number Norton customer care
Norton toll free number Norton security contact number contact Norton Norton
headquarters Norton customer service chat Norton customer service telephone
number Norton helpdesk phone number Norton customer support Norton customer
service Norton login Norton locations Norton customer service number Norton
locations Norton customer service email address Norton support site Norton
technical support phone number Norton technical support live chat Norton
technical support email address Norton technical support number Norton
technical support number symantec technical support number Norton antivirus
technical support number Norton customer support phone number Norton customer
support number Norton customer support number Norton antivirus customer support
number Norton locations Norton helpdesk phone number Norton support phone
number Norton customer service helpdesk Norton technical support phone number
Norton tech support phone number Norton tech support number Norton tech support
numberNorton 360 customer service phone number usa Norton phone number canada
Norton phone number customer services Norton helpline number Norton antivirus
contact number canada Norton phone number Norton antivirus customer service
phone number us what 

Two suggestions for gcc C compiler to extend C language (by WD Smith)

[Warren D Smith]

To the guy who falsely claimed MIPS fails to provide an add with carry
instruction,
a google search in 1 minute finds this:

stackoverflow.com/questions/1281806/adding-two-64-bit-numbers-in-assembly

I defy you to find any processor not providing add with carry,
(And I'm not talking about semantic bullshit.  MIPS provides add with
carry, even if they do not call it that, as this answer shows.)

Now it might be I'm wrong and some computers now not providing it.  If
so, that is world
damage caused by GCC.  How so?  Simple.   Code out there is written on C.
Processor designers observe real world code.  "Aha!" They say. "Real
word code hardly ever seems to use add-with-carry! I guess we should
eliminate it!"
If and when that happens it is a disaster, and the direct cause of
that disaster, was the
laziness of writers of such things as GCC.   They cripple the
programmer, then the hardware guys say "aha! programmers are crippled!
That proves they like being crippled!" OK?  So it is not merely that
you are providing a bad product, it is worse (if you are right about
this) -- actually damaging the world.

Now as my critic said (it is amazing the absurd lengths people will go
to to pretend
fossilized crud was a "good decision") a purpose of languages like C
is to provide a nice set of portable abstractions.

Well, add with carry IS a nice portable abstraction.
So is multiply Nwide*Nwide --> 2Nwide.

And as some other critic said, languages have different purposes,
and PASCAL may have had different purposes than C.
As usual for my critics, again this was confused, because it was an explicit
goal of C to get close to the machine.

That was not so much a goal of PASCAL. It was a goal of C.
That means it is absurd for C to refuse to provide packed boolean
arrays while PASCAL does, and also while C already has made uintN_t
types for various N.

Also, I believe the original machine was a PDP-9 not PDP-11, not that
it matters.

Look, I could go on.  But this is getting silly.
Basically, what happens is
1. compiler/language guys do a bad job.
2. others point it out.
3. CLGs then pretend it was a good decision made by very very wise
minds for mysterious unknown reasons nobody can explain, or just make
shit up, or complain anybody
pointing it out is rude, or mumble about different goals of different
languages, or invent ludicrous arguments to "justify" situation, or
argue anybody could implement it
themselves because language is Turing complete, so no need.
4. The real reason they are doing (3) is simple: they are lazy.
5. Pointing our their laziness and incompetence is "rude."  But due to the
always-response of type 3 made by the CLGs to any suggestion whatever,
there is no other alternative, is there?  You are forcing it upon me,
aren't you?
6. Years and years later eventually the CLGs do the right thing,
always pretending
it was their own idea and that they'd never said it was idiotic to do it.

I just wish this process could be shortcut.

Now look.  I'm actually willing to write you code to do the things I suggested,
e.g. implement packed nybble arrays in C.  It will do it with cruddy syntax,
but it'll work and pretty efficiently.  I'd also be willing to write
some assembler patches to implement, e.g. double-length multiply.
These will not be a compiler.  They will rather, be the sort of
annoying workarounds programmers like me have to do all the time, to
get around the fact that the compiler and language try to prevent you
from doing them.

But the thing is, I'm not willing to write that stuff for you unless
you promise to actually add these things to GCC.  So, will anybody
make that promise?


-- 
Warren D. Smith
http://RangeVoting.org  <-- add your endorsement (by clicking
"endorse" as 1st step)

Re: [PATCH 1/3] (v2) On-demand locations within string-literals

[Manuel López-Ibáñez]

On 26/07/16 18:11, David Malcolm wrote:


gcc/ChangeLog:
* gcc.c (cpp_options): Rename string to...
(cpp_options_): ...this, to avoid clashing with struct in
cpplib.h.


It seems to me that you need this because  now gcc.c includes cpplib.h via 
input.h, which seems wrong.


input.h was FE-independent (it depends on line-map.h but it is an accident of 
history that line-map.h is in libcpp since it doesn't depend on anything from 
libcpp [*]). Note that input.h is included in coretypes.h, so this means that 
now cpplib.h is included almost everywhere! [**]


There is the following in coretypes.h:

/* Provide forward struct declaration so that we don't have to include
   all of cpplib.h whenever a random prototype includes a pointer.
   Note that the cpp_reader and cpp_token typedefs remain part of
   cpplib.h.  */

struct cpp_reader;
struct cpp_token;

precisely to avoid including cpplib.h.


If I understand correctly, cpplib.h is needed in input.h because of this 
declaration:


+extern const char *get_source_range_for_substring (cpp_reader *pfile,
+  string_concat_db *concats,
+  location_t strloc,
+  enum cpp_ttype type,
+  int start_idx, int end_idx,
+  source_range *out_range);


Does this really need to be in input.h ?  It seems something that only C-family 
languages will be able to use. Note that you need a reader to use this 
function, and for that, you need to already include cpplib.h.


Perhaps it could live for now in c-format.c, since it is the only place using 
it?

Cheers,

Manuel.

[*] In an ideal world, we would have a language-agnostic diagnostics library 
that would include line-map and that would be used by libcpp and the rest of 
GCC, so that we can remove all the error-routines in libcpp and the awkward 
glue code that ties it into diagnostics.c.


[**] And it seems that we are slowly undoing all the work that was done by 
Andrew MacLeod to clean up the .h web and remove dependencies 
(https://gcc.gnu.org/wiki/rearch).

[Bug c/72687] New: Avg antivirus tech Support(+(1-855-990-5999)))number usa customer service phone number

[ckattyperry at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72687

Bug ID: 72687
   Summary: Avg antivirus tech Support(+(1-855-990-5999)))number
usa customer service phone number
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ckattyperry at gmail dot com
  Target Milestone: ---

Avg antivirus tech Support(+(1-855-990-5999)))number usa customer service phone
number
Avg antivirus tech Support(+(1-855-990-5999)))number usa customer service phone
number,Avg antivirus tech support number Avg customer service number
1855-990-5999 Avg call center 1855-990-5999 Avg customer service email address
1855-990-5999 Avg customer care no 1855-990-5999 Avg antivirus technical
support phone number 1855-990-5999 Avg antivirus tech support phone number
1855-990-5999 Avg antivirus customer service phone number 1855-990-5999 Avg 360
technical support phone number 1855-990-5999 symantec technical support phone
number 1855-990-5999 Avg technical support phone number 1855-990-5999 Avg
customer service telephone number 1855-990-5999 ?Avg antivirus phone number
1855-990-5999 Avg antivirus customer service phone number 1855-990-5999 Avg
antivirus customer service helpdesk Avg antivirus phone number 1855-990-5999
Avg phone number cancel subscription 1855-990-5999 Avg technical support phone
number 1855-990-5999 Avg 855 phone number 1855-990-5999 Avg toll free customer
care number sbi toll free customer care number Avg 360 toll free customer care
number toll free customer care number Avg toll free customer care number icici
toll free customer care number flipkart toll free customer care number vodafone
toll free customer care number Avg technical support phone number Avg technical
support number Avg technical support number symantec technical support number
Avg antivirus technical support number Avg locations Avg online support Avg
helpdesk phone number Avg customer care Avg tech support phone number Avg tech
support phone number Avg antivirus tech support phone number Avg locations Avg
helpdesk phone number service Avg com Avg login Avg technical support phone
number Avg customer service Avg helpdesk phone number Avg support telephone
number Avg support phone number Avg antivirus support phone number Avg support
phone number Avg locations Avg customer service Avg customer care Avg helpdesk
phone number Avg customer support phone number Avg customer support phone
number Avg antivirus customer support phone number Avg antivirus customer
service phone number Avg antivirus technical support phone number Avg antivirus
tech support phone number Avg antivirus phone number Avg security center phone
number Avg support telephone number Avg 360 technical support phone number
symantec technical support phone number Avg tech support phone number apple
technical support phone number usa microsoft technical support phone number usa
Avg technical support phone number usa Avg technical support phone number usa
lenovo technical support phone number usa epson technical support phone number
usa Avg technical support phone number call Avg support chat with Avg support
Avg customer support Avg antivirus customer service number Avg address Avg call
center Avg helpline Avg helpdesk Avg support site Avg telephone number for
customer support Avg customer service contact number Avg customer care Avg toll
free number Avg security contact number contact Avg Avg headquarters Avg
customer service chat Avg customer service telephone number Avg helpdesk phone
number Avg customer support Avg customer service Avg login Avg locations Avg
customer service number Avg locations Avg customer service email address Avg
support site Avg technical support phone number Avg technical support live chat
Avg technical support email address Avg technical support number Avg technical
support number symantec technical support number Avg antivirus technical
support number Avg customer support phone number Avg customer support number
Avg customer support number Avg antivirus customer support number Avg locations
Avg helpdesk phone number Avg support phone number Avg customer service
helpdesk Avg technical support phone number Avg tech support phone number Avg
tech support number Avg tech support numberAvg 360 customer service phone
number usa Avg phone number canada Avg phone number customer services Avg
helpline number Avg antivirus contact number canada Avg phone number Avg
antivirus customer service phone number us what is the phone number for Avg
customer service Avg contact number Avg 360 customer service phone number Avg
360 support phone number usa Avg toll free number usa Avg contact phone number
Avg antivirus phone number Avg antivirus customer service phone number Avg
support phone number Avg support phone number canada Avg technical support
phone number canada Avg abrasives 

[Bug c/72686] New: Avg Support(+(1-855-990-5999)))customer service phone number

[ckattyperry at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72686

Bug ID: 72686
   Summary: Avg Support(+(1-855-990-5999)))customer service phone
number
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ckattyperry at gmail dot com
  Target Milestone: ---

Avg Support(+(1-855-990-5999)))customer service phone number
Avg Support(+(1-855-990-5999)))customer service phone number,Avg antivirus tech
support number Avg customer service number 1855-990-5999 Avg call center
1855-990-5999 Avg customer service email address 1855-990-5999 Avg customer
care no 1855-990-5999 Avg antivirus technical support phone number
1855-990-5999 Avg antivirus tech support phone number 1855-990-5999 Avg
antivirus customer service phone number 1855-990-5999 Avg 360 technical support
phone number 1855-990-5999 symantec technical support phone number
1855-990-5999 Avg technical support phone number 1855-990-5999 Avg customer
service telephone number 1855-990-5999 ?Avg antivirus phone number
1855-990-5999 Avg antivirus customer service phone number 1855-990-5999 Avg
antivirus customer service helpdesk Avg antivirus phone number 1855-990-5999
Avg phone number cancel subscription 1855-990-5999 Avg technical support phone
number 1855-990-5999 Avg 855 phone number 1855-990-5999 Avg toll free customer
care number sbi toll free customer care number Avg 360 toll free customer care
number toll free customer care number Avg toll free customer care number icici
toll free customer care number flipkart toll free customer care number vodafone
toll free customer care number Avg technical support phone number Avg technical
support number Avg technical support number symantec technical support number
Avg antivirus technical support number Avg locations Avg online support Avg
helpdesk phone number Avg customer care Avg tech support phone number Avg tech
support phone number Avg antivirus tech support phone number Avg locations Avg
helpdesk phone number service Avg com Avg login Avg technical support phone
number Avg customer service Avg helpdesk phone number Avg support telephone
number Avg support phone number Avg antivirus support phone number Avg support
phone number Avg locations Avg customer service Avg customer care Avg helpdesk
phone number Avg customer support phone number Avg customer support phone
number Avg antivirus customer support phone number Avg antivirus customer
service phone number Avg antivirus technical support phone number Avg antivirus
tech support phone number Avg antivirus phone number Avg security center phone
number Avg support telephone number Avg 360 technical support phone number
symantec technical support phone number Avg tech support phone number apple
technical support phone number usa microsoft technical support phone number usa
Avg technical support phone number usa Avg technical support phone number usa
lenovo technical support phone number usa epson technical support phone number
usa Avg technical support phone number call Avg support chat with Avg support
Avg customer support Avg antivirus customer service number Avg address Avg call
center Avg helpline Avg helpdesk Avg support site Avg telephone number for
customer support Avg customer service contact number Avg customer care Avg toll
free number Avg security contact number contact Avg Avg headquarters Avg
customer service chat Avg customer service telephone number Avg helpdesk phone
number Avg customer support Avg customer service Avg login Avg locations Avg
customer service number Avg locations Avg customer service email address Avg
support site Avg technical support phone number Avg technical support live chat
Avg technical support email address Avg technical support number Avg technical
support number symantec technical support number Avg antivirus technical
support number Avg customer support phone number Avg customer support number
Avg customer support number Avg antivirus customer support number Avg locations
Avg helpdesk phone number Avg support phone number Avg customer service
helpdesk Avg technical support phone number Avg tech support phone number Avg
tech support number Avg tech support numberAvg 360 customer service phone
number usa Avg phone number canada Avg phone number customer services Avg
helpline number Avg antivirus contact number canada Avg phone number Avg
antivirus customer service phone number us what is the phone number for Avg
customer service Avg contact number Avg 360 customer service phone number Avg
360 support phone number usa Avg toll free number usa Avg contact phone number
Avg antivirus phone number Avg antivirus customer service phone number Avg
support phone number Avg support phone number canada Avg technical support
phone number canada Avg abrasives phone number Avg security phone contact
number Avg internet security customer 

[Bug rtl-optimization/71779] [5/6/7 regression] isl miscompiled with -mabi=ilp32

[bernd.edlinger at hotmail dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71779

--- Comment #15 from Bernd Edlinger  ---
patch posted here:
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01742.html

[Bug c/72685] New: Belkin Router support @1 844-330-2330@ Belkin router tech support number

[ckattyperry at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72685

Bug ID: 72685
   Summary: Belkin Router support @1 844-330-2330@ Belkin router
tech support number
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ckattyperry at gmail dot com
  Target Milestone: ---

Belkin Router support @1 844-330-2330@ Belkin router tech support number,
Belkin router customer service number,Belkin Router Technical Support number,
Belkin Router support phone number @@@rv 18443302330 Belkin Router Support
Phone number Belkin tech support number +++18443302330+++ Belkin Router
customer service phone number Belkin technical support number 18443302330++
Belkin Router customer Care phone number Belkin tech support number
18443302330 Belkin helpdesk support phone number Belkin Customer support
phone number 18443302330 Belkin tech support number , Belkin tech support phone
number , Belkin customer support phone number here $$$##@@ Belkin tech support
number 18443302330 Belkin Technical support number @@ Belkin support phone
number 18443302330 Belkin customer service phone number Belkin customer c.a.r.e
number Belkin helpdesk phone number Belkin helpline phone number 1844+330+2330
Belkin contact phone number 18443302330 Belkin tech support number , Belkin
tech support phone number , Belkin customer support phone number here $$$##@@
Belkin tech support number 18443302330 Belkin Technical support number @@
Belkin support phone number 18443302330 Belkin customer service phone number
Belkin customer c.a.r.e number Belkin helpdesk phone number Belkin helpline
phone number 1844+330+2330 Belkin contact phone number Belkin help number -
Belkin helpline number ; Belkin help phone number , Belkin helpline number ,
Belkin tech support tollfree number , Belkin support Tele phone number , Belkin
tech support Tele phone number , Belkin tech support contact number , Belkin
support contact number , Belkin Technical support contact number , Belkin
support phone number , Belkin Router support phone number . Belkin Router
customer support phone number Belkin customer service number 18443302330 Belkin
call center Belkin customer service Routeraddress Belkin customer c.a.r.e no
Belkin Router Technical support phone number 18443302330 Belkin Router tech
support phone number 18443302330 Belkin Router customer service phone number
18443302330 Belkin Technical support phone number 18443302330 symantec
Technical support phone number 18443302330 Belkin Technical support phone
number 18443302330 Belkin customer service tele phone number 18443302330 Belkin
Router phone number 18443302330 Belkin Router customer service phone number
18443302330 Belkin Router customer service helpdesk Belkin Router phone number
18443302330 Belkin phone number 18443302330cancel subscription Belkin Technical
support phone number 18443302330 Belkin 844 phone number 18443302330 snapdeal
tollfree customer c.a.r.e number 18443302330 sbi tollfree customer c.a.r.e
number 18443302330 airtel tollfree customer c.a.r.e number 18443302330 hdfc
tollfree customer c.a.r.e number 18443302330 bsnl tollfree customer c.a.r.e
number 18443302330 icici tollfree customer c.a.r.e number 18443302330 flipkart
tollfree customer c.a.r.e number 18443302330 vodafone tollfree customer c.a.r.e
number 18443302330 Belkin Technical support phone number 18443302330 Belkin
Technical support number 18443302330 Belkin Technical support number
18443302330 symantec Technical support number 18443302330 Belkin Router
Technical support number 18443302330 Belkin locations Belkin online support
Belkin helpdesk phone number 18443302330 Belkin customer c.a.r.e Belkin tech
support phone number 18443302330 Belkin tech support phone number 18443302330
Belkin Router tech support phone number 18443302330 Belkin locations Belkin
helpdesk phone number 18443302330 service Belkin com Belkin login Belkin
Technical support phone number 18443302330 Belkin customer service Belkin
helpdesk phone number 18443302330 Belkin support tele phone number 18443302330
Belkin support phone number 18443302330 Belkin Router support phone number
18443302330 Belkin support phone number 18443302330 Belkin locations Belkin
customer service Belkin customer c.a.r.e Belkin helpdesk phone number
18443302330 Belkin customer support phone number 18443302330 Belkin customer
support phone number 18443302330 Belkin Router customer support phone number
18443302330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72684

[Bug fortran/72051] gfortran bug - internal compiler error

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72051

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #7 from kargl at gcc dot gnu.org ---
After screwing around with the build system, I managed
to prove that both

gcc version 7.0.0 20160726 (experimental) (GCC)
gcc version 6.1.1 20160515 (GCC) 

compile the code without problems.

[Bug c/72684] New: Netgear Router support @1 844-330-2330@ Netgear router tech support number

[ckattyperry at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72684

Bug ID: 72684
   Summary: Netgear Router support @1 844-330-2330@ Netgear router
tech support number
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ckattyperry at gmail dot com
  Target Milestone: ---

Netgear Router support @1 844-330-2330@ Netgear router tech support number,
Netgear router customer service number,Netgear Router Technical Support number,
Netgear Router support phone number @@@rv 18443302330 Netgear Router
Support Phone number Netgear tech support number +++18443302330+++ Netgear
Router customer service phone number Netgear technical support number
18443302330++ Netgear Router customer Care phone number Netgear tech support
number 18443302330 Netgear helpdesk support phone number Netgear Customer
support phone number 18443302330 Netgear tech support number , Netgear tech
support phone number , Netgear customer support phone number here $$$##@@
Netgear tech support number 18443302330 Netgear Technical support number @@
Netgear support phone number 18443302330 Netgear customer service phone number
Netgear customer c.a.r.e number Netgear helpdesk phone number Netgear helpline
phone number 1844+330+2330 Netgear contact phone number 18443302330 Netgear
tech support number , Netgear tech support phone number , Netgear customer
support phone number here $$$##@@ Netgear tech support number 18443302330
Netgear Technical support number @@ Netgear support phone number 18443302330
Netgear customer service phone number Netgear customer c.a.r.e number Netgear
helpdesk phone number Netgear helpline phone number 1844+330+2330 Netgear
contact phone number Netgear help number - Netgear helpline number ; Netgear
help phone number , Netgear helpline number , Netgear tech support tollfree
number , Netgear support Tele phone number , Netgear tech support Tele phone
number , Netgear tech support contact number , Netgear support contact number ,
Netgear Technical support contact number , Netgear support phone number ,
Netgear Router support phone number . Netgear Router customer support phone
number Netgear customer service number 18443302330 Netgear call center Netgear
customer service Routeraddress Netgear customer c.a.r.e no Netgear Router
Technical support phone number 18443302330 Netgear Router tech support phone
number 18443302330 Netgear Router customer service phone number 18443302330
Netgear Technical support phone number 18443302330 symantec Technical support
phone number 18443302330 Netgear Technical support phone number 18443302330
Netgear customer service tele phone number 18443302330 Netgear Router phone
number 18443302330 Netgear Router customer service phone number 18443302330
Netgear Router customer service helpdesk Netgear Router phone number
18443302330 Netgear phone number 18443302330cancel subscription Netgear
Technical support phone number 18443302330 Netgear 844 phone number 18443302330
snapdeal tollfree customer c.a.r.e number 18443302330 sbi tollfree customer
c.a.r.e number 18443302330 airtel tollfree customer c.a.r.e number 18443302330
hdfc tollfree customer c.a.r.e number 18443302330 bsnl tollfree customer
c.a.r.e number 18443302330 icici tollfree customer c.a.r.e number 18443302330
flipkart tollfree customer c.a.r.e number 18443302330 vodafone tollfree
customer c.a.r.e number 18443302330 Netgear Technical support phone number
18443302330 Netgear Technical support number 18443302330 Netgear Technical
support number 18443302330 symantec Technical support number 18443302330
Netgear Router Technical support number 18443302330 Netgear locations Netgear
online support Netgear helpdesk phone number 18443302330 Netgear customer
c.a.r.e Netgear tech support phone number 18443302330 Netgear tech support
phone number 18443302330 Netgear Router tech support phone number 18443302330
Netgear locations Netgear helpdesk phone number 18443302330 service Netgear com
Netgear login Netgear Technical support phone number 18443302330 Netgear
customer service Netgear helpdesk phone number 18443302330 Netgear support tele
phone number 18443302330 Netgear support phone number 18443302330 Netgear
Router support phone number 18443302330 Netgear support phone number
18443302330 Netgear locations Netgear customer service Netgear customer c.a.r.e
Netgear helpdesk phone number 18443302330 Netgear customer support phone number
18443302330 Netgear customer support phone number 18443302330 Netgear Router
customer support phone number 18443302330

[Bug ipa/72657] [7 regression][CHKP] internal compiler error: in ix86_expand_builtin

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72657

--- Comment #2 from H.J. Lu  ---
(In reply to Ilya Enkovich from comment #1)
> Looks like it is caused by remained direct fndecl comparisons in checker
> code.
> Usage of chkp_gimple_call_builtin_p everywhere should fix it.

Will it also fix PR 72683?

[PATCH] Fix wrong code on aarch64 due to paradoxical subreg

[Bernd Edlinger]

Hi!

As described in PR 71779 and PR 70903 we have a wrong code issue on aarch64
which is triggered by a paradoxical subreg that can be created in
store_bit_field_using_insv when the target has an EP_insv bitfield instruction.

The attached patch changes this insn...

(insn 1047 1046 1048 (set (reg:DI 481)
(subreg:DI (reg/f:SI 479) 0)) y.c:12702 -1
 (nil))

... into a more simple insn:

(insn 1047 1046 1048 (set (reg:DI 479)
(zero_extend:DI (reg:SI 480))) isl_input.c:2496 -1
 (nil))

which manages to fix two bugs at the same time.

The patch does not include a test case, as I was looking at the PR 71779
just by curiosity, and I have only a theoretical interest in aarch64. However,
it should be easy to extract one from PR 70903 at least, but I can't do that by
myself.

Therefore I would like to leave the test case(s) to Cristina Tamar from ARM,
and/or Andreas Schwab, who have also helped out with bootstrapping and
reg-testing on aarch64 and aarch64-ilp32.

Bootstrap and reg-test on x86_64-linux-gnu with no regressions.
Successfully bootstrapped on aarch64_ilp32 and the ISL testsuite passes.
Also successfully bootstrapped on an aarch64 juno board and no regressions.


Is it OK for trunk?


Thanks
Bernd.2016-07-25  Bernd Edlinger  

	PR rtl-optimization/71779
	PR rtl-optimization/70903
	* expmed.c (store_bit_field_using_insv): Don't generate a paradoxical
	subreg.

Index: gcc/calls.c
Index: expmed.c
===
--- expmed.c	(revision 238694)
+++ expmed.c	(working copy)
@@ -664,14 +664,7 @@ store_bit_field_using_insv (const extraction_insn
 	 if we must narrow it, be sure we do it correctly.  */
 
 	  if (GET_MODE_SIZE (GET_MODE (value)) < GET_MODE_SIZE (op_mode))
-	{
-	  tmp = simplify_subreg (op_mode, value1, GET_MODE (value), 0);
-	  if (! tmp)
-		tmp = simplify_gen_subreg (op_mode,
-	   force_reg (GET_MODE (value),
-		  value1),
-	   GET_MODE (value), 0);
-	}
+	tmp = convert_to_mode (op_mode, value1, 1);
 	  else
 	{
 	  tmp = gen_lowpart_if_possible (op_mode, value1);

Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch

[Prathamesh Kulkarni]

On 26 July 2016 at 19:21, ayush goel  wrote:
> On 26 July 2016 at 3:38:59 AM, Manuel López-Ibáñez
> (lopeziba...@gmail.com) wrote:
>> On 25 July 2016 at 18:18, ayush goel wrote:
>> > On top of the previously filed patch for importing gnulib (the link
>> > isn’t available on the archive yet, however this contains some of the
>> > information: 
>> > http://gcc.1065356.n5.nabble.com/Importing-gnulib-into-the-gcc-tree-td1275807.html#a1279573)
>> > now I have replaced another function from libiberty with the
>> > corresponding version from gnulib.
>> > Even though in both OSX and GNU/Linux, fnmatch is provided by the GNU
>> > libc already, so the copy in libiberty is not used in your systems.
>> > However since the objective is to replace whatever functions can be
>> > leveraged by gnulib, these changes have been made.
>>
>> Why the change from "fnmatch.h" to ?
>
> Gnulib doesn’t contain a header for fnmatch. It itself relies on
> glib’c fnmatch.h
>
>>
>> Also, are the files in gnulib and libiberty semantically identical?
>> The wiki page does not say anything about this. How did you check
>> this?
>
> Well the online docs for libiberty and gnulib claim the same
> definition for fnmatch. Apart from this I’ve manually gone through the
> source code and they seem to be semantically similar.
> Also the fact that the system builds fine and the tests also execute
> fine could serve as a manifestation for the fact that they are
> semantically same.
>>
>> GCC can run on other systems besides OSX and GNU/Linux, how can you
>> test that your change does not break anything on those systems?
>>
> Well I have access to these two systems only. How would you suggest I
> test my patches on all possible systems?
Maybe building contrib/config-list.mk could help ? AFAIK, it will cross build
the gcc tree for different targets, but not run the testsuite, however
I could be wrong.

Thanks,
Prathamesh
>
>> Cheers,
>>
>> Manuel.
>>
>
> -Ayush

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

[josh at joshtriplett dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856

--- Comment #21 from Josh Triplett  ---
(In reply to PaX Team from comment #20)
> (In reply to Josh Triplett from comment #13)
> > Note that in addition to complaining if *any* exit to the function doesn't
> > have the correct "out" value, you also need to complain if calls to
> > functions with the context attribute don't have the necessary "in" value. 
> 
> i implemented this now but it generates a warning on good_lock3,
> good_unlock2 and good_if3 (since there're paths where the same lock is taken
> twice before we reach the end of the function where we'd know that the lock
> count imbalance is fine). how should these cases be handled?

Sorry for the delayed response; I didn't see an email update for your previous
comment.

To answer your question: "in" is a minimum, not an exact value.  If a function
(or the __context__ statement) requires context (1,0), meaning that the
function call should occur with the lock held and the function drops the lock
before returning, then you should evaluate the body of the function itself as
though with those exact contexts, but allow calls to that function with any
context >= 1, and have the function return with the context decreased by one. 
So, you could also call the function with context 2, in which case that context
would become 1 after the call.

Sparse experimented with separate attributes/statements for an *exact* context
match (as in, the context must equal 1, not 1 or more, for use with
non-recursive locking), but those got reverted.

Re: [PATCH] Remove special streaming of builtins

[H.J. Lu]

On Mon, Jul 25, 2016 at 4:35 AM, Richard Biener  wrote:
>
> So I needed to fix that builtins appearing in BLOCK_VARs and the solution
> I came up with accidentially disabled streaming via the special path.
> Thus the following patch removes the special-casing completely and makes
> the BLOCK_VARs handling work the same way as for regular externs (by
> streaming a local copy).  We stream each builtin decl once and then
> refer to it via the decl index (which is cheaper than the special
> casing).
>
> I'm not 100% this solves for example the -fno-math-errno inlining
> across TUs (it certainly doesn't if you use attribute optimize with
> -fno-math-errno), but it eventually should by means of having two
> different BUILT_IN_XXX if they have different behavior.  At least
> if all relevant bits are set on the function _type_ rather than
> the decl which I think we still lto-symtab replace with one
> entity during WPA(?)
>
> Well.
>
> LTO bootstrapped and tested on x86_64-unknown-linux-gnu (c,c++,fortran),
> bootstrapped on x86_64-unknown-linux-gnu (all), testing in progress.
>
> I might have not catched all fndecl compares.
>
> Will apply to trunk if testing completes.  As said, maybe followup
> cleanups possible, at least to lto-opts.c / lto-wrapper.
>
> Richard.
>
> 2016-07-25  Richard Biener  
>
> * cgraph.c (cgraph_node::verify_node): Compare against builtin
> by using DECL_BUILT_IN_CLASS and DECL_FUNCTION_CODE.
> * tree-chkp.c (chkp_gimple_call_builtin_p): Likewise.
> * tree-streamer.h (streamer_handle_as_builtin_p): Remove.
> (streamer_get_builtin_tree): Likewise.
> (streamer_write_builtin): Likewise.
> * lto-streamer.h (LTO_builtin_decl): Remove.
> * lto-streamer-in.c (lto_read_tree_1): Remove assert.
> (lto_input_scc): Remove LTO_builtin_decl handling.
> (lto_input_tree_1): Liekwise.
> * lto-streamer-out.c (lto_output_tree_1): Remove special
> handling of builtins.
> (DFS::DFS): Likewise.
> * tree-streamer-in.c (streamer_get_builtin_tree): Remove.
> * tree-streamer-out.c (pack_ts_function_decl_value_fields): Remove
> assert.
> (streamer_write_builtin): Remove.
>
> lto/
> * lto.c (compare_tree_sccs_1): Remove streamer_handle_as_builtin_p 
> uses.
> (unify_scc): Likewise.
> (lto_read_decls): Likewise.
>

This caused:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72683


-- 
H.J.

[Bug lto/72683] New: [7 Regression] MPX test failures with LTO

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72683

Bug ID: 72683
   Summary: [7 Regression] MPX test failures with LTO
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: rguenther at suse dot de
  Target Milestone: ---

On x86, r238709 caused:

FAIL: gcc.target/i386/mpx/va-arg-pack-2-lbv.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: gcc.target/i386/mpx/va-arg-pack-2-lbv.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.target/i386/mpx/va-arg-pack-2-ubv.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: gcc.target/i386/mpx/va-arg-pack-2-ubv.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.target/i386/mpx/vararg-1-lbv.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.target/i386/mpx/vararg-1-lbv.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.target/i386/mpx/vararg-1-ubv.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.target/i386/mpx/vararg-1-ubv.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.target/i386/mpx/vararg-2-lbv.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.target/i386/mpx/vararg-2-lbv.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.target/i386/mpx/vararg-2-ubv.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.target/i386/mpx/vararg-2-ubv.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.target/i386/mpx/vararg-3-lbv.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.target/i386/mpx/vararg-3-lbv.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.target/i386/mpx/vararg-3-ubv.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.target/i386/mpx/vararg-3-ubv.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.target/i386/mpx/vararg-4-lbv.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.target/i386/mpx/vararg-4-lbv.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.target/i386/mpx/vararg-4-ubv.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.target/i386/mpx/vararg-4-ubv.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.target/i386/mpx/vararg-5-lbv.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.target/i386/mpx/vararg-5-lbv.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.target/i386/mpx/vararg-5-ubv.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.target/i386/mpx/vararg-5-ubv.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.target/i386/mpx/vararg-6-lbv.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.target/i386/mpx/vararg-6-lbv.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.target/i386/mpx/vararg-6-ubv.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.target/i386/mpx/vararg-6-ubv.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.target/i386/mpx/vararg-7-lbv.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.target/i386/mpx/vararg-7-lbv.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.target/i386/mpx/vararg-7-ubv.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.target/i386/mpx/vararg-7-ubv.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.target/i386/mpx/vararg-8-lbv.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.target/i386/mpx/vararg-8-lbv.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.target/i386/mpx/vararg-8-ubv.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.target/i386/mpx/vararg-8-ubv.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test

on machines with MPX support.

[Bug c++/72682] New: Redundant concept diagnostics when the same concept is checked multiple times

[adrian.wielgosik at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72682

Bug ID: 72682
   Summary: Redundant concept diagnostics when the same concept is
checked multiple times
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adrian.wielgosik at gmail dot com
  Target Milestone: ---

A simple code example:

template using id=T;
template
concept bool A = requires(T a) { a==a; };
template
concept bool B =
  A && // (1) basic usage
  A && // (2) duplicate concept check
  A && // (3) different concept check that happens to check the same type
  A; // (4) same as above

template requires B void f(T){}

struct S{} s;
int main(){ f(s); }

Produces the following diagnostic (first couple of lines that were not relevant
were omitted):

main.cpp:4:14: note: within ‘template concept const bool A [with T
= S]’
 concept bool A = requires(T a) { a==a; };
  ^
main.cpp:4:14: note: with ‘S a’
main.cpp:4:14: note: the required expression ‘(a == a)’ would be ill-formed
main.cpp:4:14: note: within ‘template concept const bool A [with T
= S]’
main.cpp:4:14: note: with ‘S a’
main.cpp:4:14: note: the required expression ‘(a == a)’ would be ill-formed
main.cpp:4:14: note: within ‘template concept const bool A [with T
= S]’
main.cpp:4:14: note: with ‘S a’
main.cpp:4:14: note: the required expression ‘(a == a)’ would be ill-formed
main.cpp:4:14: note: within ‘template concept const bool A [with T
= S]’
main.cpp:4:14: note: with ‘S a’
main.cpp:4:14: note: the required expression ‘(a == a)’ would be ill-formed

Notice that all four checks in the end checked the concept A on the type S and
produced the exact same diagnostic.

For a real world example: if you use Ranges TS StrictTotallyOrdered on
unorderable type, it's going to check StrictTotallyOrdered three times on
the same type (and then also check all operators like "{t < u}->Boolean" extra
two times, and then a duplicate check of EqualityComparable), which can easily
produce over a dozen redundant messages, while ideally the whole diagnostic
should contain only six messages, one for each comparison operator.

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[Paul_Koning]

> On Jul 26, 2016, at 12:50 PM, Warren D Smith  wrote:
> 
> ...
> Sigh.  It's really hard to get compiler and language guys to do anything.

I find it puzzling that you appear to think that insulting your audience is the 
best way to influence them.

> ...
> There is absolutely no good reason why things have to be *legislated*
> to be an integer number of bytes.  They could be single bits.  It
> would be fine.  PASCAL already provided
> it 40 years ago.  

So what?  Pascal is a different language with different goals.  The reason 
there are hundreds of programming languages in the world -- and dozens in 
current use -- is that each design is a tradeoff of conflicting goals, and each 
is a different set of choices made for a particular set of reasons.  Pascal, 
Cobol, Lisp, C, and Python all make very different choices.  They are all good 
choices in some situations, and bad choices in another; this is why you 
sometimes write in C and sometimes in Python.

Support for data in sizes different from those native to most modern machine 
architectures comes at a very substantial cost, in compiler complexity, code 
size, and execution time.  It's clearly doable, and a few languages have done 
so.  But omitting it is a more common tradeoff, and clearly a good choice given 
the way those languages are received in the marketplace.

> If you wanted to make a packed array of 63 bools,
> you could pad it up to 64 to fit it in an integer number of bytes.
> I'd be ok with that.  I'm not ok with gratuitously wasting a factor of
> 8 in memory and/or forcing programmers to do lots more work and use
> cruddy syntax, merely because the compiler writers were too lazy to
> just change a few numbers in their code.  

Since you clearly don't know much about how compilers work, it would be better 
to study the subject before expressing an opinion.  You might also study the 
art of communicating persuasively.

> And it is an absolute outrage that every processor in the universe
> provides "add with carry" but the C language insists on preventing you
> from accessing that, while providing a way
> to access combined divide & remainder instead.  It is simply not a
> justifiable decision.

You might also study processor architecture some more.  If by "every processor" 
you mean every x86 processor, you might be correct.   But of the 15 or so 
processor architectures I've looked at, I think that only a modest minority 
have add-carry or add-with-carry instructions.  For example, MIPS, which is a 
very popular architecture in current wide use, does not have such operations.

Quite apart from that, it is not the goal of most (if any) high level languages 
to provide direct access to all CPU facilities.  Instead, the more common goal 
is to provide a clean set of abstractions complete enough to let people write 
reliable programs for the problem area in question, with minimal effort.  So it 
is with C (and Pascal, for that matter, which doesn't have an add-with-carry 
primitive either).  For those who want to see all the bells and whistles, 
there's a simple answer: assembly language.

paul

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[David Brown]

On 26/07/16 16:37, Warren D Smith wrote:

You would get on far better here if you tried a little politeness and
respect, rather than anger, accusations and confrontation.

The C standards were written by a group of very smart and experienced
people, refined over a long time based on real-world issues and
feedback.  The language has been successful for decades.  And the gcc
implementation of the language is developed by another group of very
smart and experienced people, and has also been refined over decades.

So if you say one thing, and the C standards and/or the gcc developers
say something else, the chances are extremely high that you are wrong
and they are right.  If the gcc compiler is missing a feature that you
would like, it is not because someone is lazy, incompetent, or trying to
be difficult - more often, it is simply that the feature you want is not
actually a good idea, or it is not worth the effort to implement for the
few cases where it would be used, or it is already possible using a
different method.

> On 7/26/16, Jonathan Wakely  wrote:
>> On 26 July 2016 at 14:31, Warren D Smith wrote:
>>> 1. Gcc with stdint.h already
>>> provides such nice predefined types as uint8_t.
>>> Sizes provided are 8,16,32, and 64.
>>> In some sense uint1_t is available too (stdbool.h)
>>> but at least on my machine stdbool uses 8-bits to store a bool,
>>
>> Because that's the smallest addressable unit.
> 
> --look, I know there is a pascal front end for gcc, so I know gcc could 
> provide
> packed bool arrays, because whoever wrote pascal-gcc already did provide it.

You have made it clear that you don't actually understand C in detail.
Apparently you also don't understand Pascal, or the underlying hardware
of typical processors.

Yes, Pascal may provide packed bool arrays.  But you cannot take the
address of the individual elements in a packed bool array.  And Pascal
arrays are not the same as C arrays - they contain more information, and
are more akin to C++ container types.  A single "bool" object in Pascal
takes one byte (a single smallest addressable unit, typically 8 bits).

Pascal implementations can provide packed bool arrays as a convenience
to the programmer - it is a higher level language than C, and provides a
number of such conveniences.  But the underlying mechanism for accessing
elements of the array involves masks and shifts - it is very different
from the simple access for an unpacked array.

In C, you write your own functions for this sort of thing (or use a
library).  In C++, standard containers such as std::bitset and
std::vector have optimisations to hide the details.  So if you want a
programming language that lets you have something that is a bit like an
array, but with packed boolean elements, and is used transparently like
a normal array - then pick a different language than C.

> 
> Also, I know on some machines to access a byte you have to get a word
> (larger than 8 bits)
> from memory, do shifts and masks.  So clearly you already do that inside gcc.

No, on systems that have a basic unit of memory that is bigger than 8
bits, your "byte" is bigger than 8 bits and it is the smallest unit you
can access.  So a DSP devices with 16-bit minimum addressable units has
16-bit "bytes", 16-bit char, CHAR_BIT == 16, sizeof(uint32_t) == 2, and
no way to directly access 8-bit units.  You have to use bitfields that
are 8-bit wide in a struct, or do the masking and shifting yourself.

(As far as I know, gcc does not support any targets that have CHAR_BIT
other than 8, but the principle is the same as this is basic standard C
stuff.)

> It therefore is trivial for you to do uint4_t also, because it would
> be that exact same code you already have, just change some numbers.

No.

> 
> The reason C language originally went with 8,16,32 only,
> was an embarrassing historical accident because the first C compiler
> was developed on some obsolete DEC PDP machine from hell.

8-bit basic units were already becoming mainstream when C was developed,
and were a popular choice.  The DEC machine in question was the PDP-11,
and it was not obsolete when C was developed, and it was certainly not a
"machine from hell".  It was one of the most successful and popular
minicomputers ever made.  (The rumour is that some of the terseness in
the C syntax is due to the DEC keyboards being terrible - whatever truth
there may be in that, the cpu itself was lovely.)

> DEC no longer exists, and PDP machines also no longer exist.
> To make things worse, they originally defined C *WITHOUT*
> actual unambiguous meanings, for example "int" might be who knows how
> many bits wide, language would not define that.  

This was an active decision to allow greater flexibility of the
language, and to make it easier to have implementations of C on systems
that could not support sizes such as 8 bit.  It means there are C
implementations for almost all cpus.  It does mean that portable code
does not know the exact 

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[David Brown]

On 26/07/16 16:55, Warren D Smith wrote:
> On 7/26/16, Joseph Myers  wrote:
>> On Tue, 26 Jul 2016, Warren D Smith wrote:
>>
>>> (And in the case of uint4_t, it actually would not even BE an
>>> "extension" since as I said,
>>> the standard already allows providing other sizes.)
>>
>> Only sizes which are an integer number of bytes with no padding bits.
> 
> wikipedia:
> "The C99 standard includes definitions of several new integer types to
> enhance the portability of programs.[2] The already available basic
> integer types were deemed insufficient, because their actual sizes are
> implementation defined and may vary across different systems... All
> new types are defined in  header (cinttypes header in C++)
> and also are available at  header (cstdint header in C++).
> The types can be grouped into the following categories:
> * Exact-width integer types which are guaranteed to have the same
> number N of bits across all implementations. Included only if it is
> available in the implementation..."
> 
> This wikipedia page nowhere says it must be an integer number of bytes
> with no padding.

Wikipedia does not define C - the C standards define C.  And yes, all
types (including extended integer types) in C must be an integer number
of bytes.  Padding bits are allowed, however.

So there is nothing (except sanity) to stop an implementation with 8-bit
chars having a 12-bit integer type that is stored in a 16-bit lump.  But
the only support C allows for an object of size 12 bits on such a
platform would be as a bitfield.


> And you will notice they *intentionally* chose to name them int8_t
> meaning 8 BITs wide, and *not* meaning 8 BYTEs wide, intentionally
> choosing those names presumably because they wanted to permit
> sizes not a multiple of 8.

No, the names were chosen to use bit sizes because a "bit" is clearly
defined as a single binary digit.  A "byte" in C terms is not
necessarily 8 bits - the unambiguous term for a lump of 8 bits is
"octet".  C defines a "byte" to be the smallest addressable unit of
memory, with the constraint of it being at least 8 bits.  On a great
many systems, a "byte" is precisely 8 bits (i.e., CHAR_BIT == 8).  But
on other systems it is different.  I have worked on devices with 16-bit
"bytes" (not with gcc).  On these systems, "uint16_t" is exactly the
same size as "uint16_t" on an x86 system, because the number of bits is
specified.  But "uint8_t" simply does not exist on such systems, because
the hardware does not support direct access to such units.

> 
> And they said "only if available in implementation" which gcc chose to
> interpret as
> "we're not going to make other sizes available, hahahaha."  But gcc could 
> choose
> to get ahead of the other compilers, leading not following, by
> making them available.  If you were really ambitious you could provide int7_t
> etc (w.g. all integer sizes up to 64) but I am not asking for that
> level of ambition.  I am asking merely for the easy sizes 1, 2 and 4
> which you plainly have already written
> the code to do, just change some numbers.

If this were as easy as you seem to think, and as useful as you seem to
think, then gcc would support different int sizes.  In fact making any
kind of dedicated int1_t, int2_t or int4_t support would be difficult in
the compiler, and would still not do what you want - the rules of C
insist that you be able to take the address of objects of these types,
and addresses of different objects are different.  Thus the only legal
implementation of "int4_t" would have four bits for the data content and
padding bits to make up the rest of the byte (typically 8 bits).

> 
> You are free to attack the standards bodies as being idiots.  But they weren't
> being idiots in this decision.
> 

I don't believe anyone other than you is attacking anyone, or calling
anyone "idiots".  The gcc developers are very well aware of the
standards, including both the flexibility and freedoms they give.  They
are also very well aware of the desires of programmers, and the
practical limitations of compilers and tools.  So while they know the
standards allow the possibility of an "int4_t" extended integer type,
they know it would not be useful (it would not do what you think it
would do), as well as being a significant effort to implement.

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[Joseph Myers]

On Tue, 26 Jul 2016, Warren D Smith wrote:

> --mind-boggling.
> So they actually intentionally made the language worse
> in the C11 TC3 revision versus the C99 standard.

There is no such thing as C11 TC3.  All the relevant requirements about 
being integer numbers of bytes are present in the original C99 (which I 
expect is available to purchase from organisations specialising in the 
sale of obsolete standards), as are the relevant requirements on intN_t 
and uintN_t; it's just that referring to the original C99 for  
requirements is a bad idea because of several other issues raised in 
various C99 DRs and addressed through TC1, TC2 and TC3 (all three of which 
made changes to the  specification).

Furthermore, while the subclause with wording about representations of 
types is new in C99, exactly the same requirement about being integer 
numbers of bytes can be found in C90; see the definition of "object" 
(subclause 3.14 in C90).  No doubt the principle of objects being 
addressable and made up of bytes, except for the special case of 
bit-fields, dates back long before C90.

-- 
Joseph S. Myers
jos...@codesourcery.com

[PATCH GCC]Vectorize possible infinite loop by loop versioning.

[Bin Cheng]

Hi,
This patch vectorizes possible infinite loops by versioning.  It analyzes loops 
considered for vectorization using loop constraint facility which was 
introduced by previous patch; then vectorizes the loop with respect to 
assumptions of loop niters information; at last, it sets constraint flags for 
versioned loop so that niter analyzer in following optimizers can take 
advantage of it.  The patch also adds two tests.

Bootstrap and test on x86_64.  Any comments?

Thanks,
bin

2016-07-25  Bin Cheng  

PR tree-optimization/57558
* tree-vect-loop-manip.c (vect_create_cond_for_niters_checks): New
function.
(vect_loop_versioning): Support versioning with niter assumptions.
* tree-vect-loop.c (tree-ssa-loop.h): Include header file.
(vect_get_loop_niters): New parameter.  Reimplement to support
assumptions in loop niter info.
(vect_analyze_loop_form_1, vect_analyze_loop_form): Ditto.
(new_loop_vec_info): Init LOOP_VINFO_NITERS_ASSUMPTIONS.
(vect_estimate_min_profitable_iters): Use LOOP_REQUIRES_VERSIONING.
Support loop versioning for niters.
* tree-vectorizer.c (tree-ssa-loop-niter.h): Include header file.
(vect_free_loop_info_assumptions): New function.
(vectorize_loops): Free loop niter info for loops with flag
LOOP_F_ASSUMPTIONS set if vectorization failed.
* tree-vectorizer.h (struct _loop_vec_info): New field
num_iters_assumptions.
(LOOP_VINFO_NITERS_ASSUMPTIONS): New macro.
(LOOP_REQUIRES_VERSIONING_FOR_NITERS): New macro.
(LOOP_REQUIRES_VERSIONING): New macro.
(vect_free_loop_info_assumptions): New decl.

gcc/testsuite/ChangeLog
2016-07-25  Bin Cheng  

PR tree-optimization/57558
* gcc.dg/vect/pr57558-1.c: New test.
* gcc.dg/vect/pr57558-2.c: New test.diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
index 819abcd..c1381b3 100644
--- a/gcc/tree-vect-loop-manip.c
+++ b/gcc/tree-vect-loop-manip.c
@@ -2082,6 +2082,37 @@ vect_do_peeling_for_alignment (loop_vec_info loop_vinfo, 
tree ni_name,
   free_original_copy_tables ();
 }
 
+/* Function vect_create_cond_for_niters_checks.
+
+   Create a conditional expression that represents the run-time checks for
+   loop's niter.  The loop is guaranteed to to terminate if the run-time
+   checks hold.
+
+   Input:
+   COND_EXPR  - input conditional expression.  New conditions will be chained
+   with logical AND operation.  If it is NULL, then the function
+   is used to return the number of alias checks.
+   LOOP_VINFO - field LOOP_VINFO_MAY_ALIAS_STMTS contains the list of ddrs
+   to be checked.
+
+   Output:
+   COND_EXPR - conditional expression.
+
+   The returned COND_EXPR is the conditional expression to be used in the
+   if statement that controls which version of the loop gets executed at
+   runtime.  */
+
+static void
+vect_create_cond_for_niters_checks (loop_vec_info loop_vinfo, tree *cond_expr)
+{
+  tree part_cond_expr = LOOP_VINFO_NITERS_ASSUMPTIONS (loop_vinfo);
+
+  if (*cond_expr)
+*cond_expr = fold_build2 (TRUTH_AND_EXPR, boolean_type_node,
+ *cond_expr, part_cond_expr);
+  else
+*cond_expr = part_cond_expr;
+}
 
 /* Function vect_create_cond_for_align_checks.
 
@@ -2330,7 +2361,7 @@ void
 vect_loop_versioning (loop_vec_info loop_vinfo,
  unsigned int th, bool check_profitability)
 {
-  struct loop *loop = LOOP_VINFO_LOOP (loop_vinfo);
+  struct loop *loop = LOOP_VINFO_LOOP (loop_vinfo), *nloop;
   struct loop *scalar_loop = LOOP_VINFO_SCALAR_LOOP (loop_vinfo);
   basic_block condition_bb;
   gphi_iterator gsi;
@@ -2347,14 +2378,19 @@ vect_loop_versioning (loop_vec_info loop_vinfo,
   tree scalar_loop_iters = LOOP_VINFO_NITERS (loop_vinfo);
   bool version_align = LOOP_REQUIRES_VERSIONING_FOR_ALIGNMENT (loop_vinfo);
   bool version_alias = LOOP_REQUIRES_VERSIONING_FOR_ALIAS (loop_vinfo);
+  bool version_niter = LOOP_REQUIRES_VERSIONING_FOR_NITERS (loop_vinfo);
 
   if (check_profitability)
-{
-  cond_expr = fold_build2 (GT_EXPR, boolean_type_node, scalar_loop_iters,
-  build_int_cst (TREE_TYPE (scalar_loop_iters), 
th));
-  cond_expr = force_gimple_operand_1 (cond_expr, _expr_stmt_list,
- is_gimple_condexpr, NULL_TREE);
-}
+cond_expr = fold_build2 (GT_EXPR, boolean_type_node, scalar_loop_iters,
+build_int_cst (TREE_TYPE (scalar_loop_iters),
+  th));
+
+  if (version_niter)
+vect_create_cond_for_niters_checks (loop_vinfo, _expr);
+
+  if (cond_expr)
+cond_expr = force_gimple_operand_1 (cond_expr, _expr_stmt_list,
+   is_gimple_condexpr, NULL_TREE);
 
   if (version_align)
 

[Patch GCC]Support constraint flags in loop structure.

[Bin Cheng]

Hi,
This patch adds support for constraint flags in loop structure.  Different to 
existing boolean flags which are set by niter analyzer, constraint flag is 
mainly set by consumers and affects certain semantics of niter analyzer APIs.  
Currently niter APIs affected are number_of_iterations_exit* and their callers. 
 Constraint flags are added to support handling of possible infinite loops in 
GCC.  One typical usecase of constraint is in vectorizer, as described in 
patch's comment:

  /* ...
   1) Compute niter->assumptions by calling niter analyzer API and
  record it as possible condition for loop versioning.
   2) Clear buffered result of niter/scev analyzer.
   3) Set constraint LOOP_C_FINITE assuming the loop is finite.
   4) Analyze data references.  Since data reference analysis depends
  on niter/scev analyzer, the point is that niter/scev analysis
  is done under circumstance of LOOP_C_FINITE constraint.
   5) Version the loop with assumptions computed in step 1).
   6) Vectorize the versioned loop in which assumptions is guarded to
  be true.
   7) Update constraints in versioned loops so that niter analyzer
  in following passes can use it.

 Note consumers are usually the loop optimizers and it is consumers'
 responsibility to set/clear constraints correctly.  Failing to do
 that might result in hard to track bugs in niter/scev analyzer.  */

Next patch will use constraint to vectorize possible infinite loop by 
versioning, I would also expect possible infinite loops (loops with 
assumptions) can be handled by more optimizers.  This patch itself doesn't 
change GCC behavior, bootstrap and test on x86_64.  Any comments?

Thanks,
bin

2016-07-25  Bin Cheng  

* cfgloop.h (struct loop): New field constraints.
(LOOP_C_INFINITE, LOOP_C_FINITE): New macros.
(loop_constraint_set, loop_constraint_clr, loop_constraint_set_p): New
functions.
* cfgloop.c (alloc_loop): Initialize new field.
* tree-ssa-loop-niter.c (number_of_iterations_exit_assumptions):
Adjust niter analysis wrto loop constraints.diff --git a/gcc/cfgloop.c b/gcc/cfgloop.c
index 2087b90..b5c920c 100644
--- a/gcc/cfgloop.c
+++ b/gcc/cfgloop.c
@@ -339,6 +339,7 @@ alloc_loop (void)
   loop->exits = ggc_cleared_alloc ();
   loop->exits->next = loop->exits->prev = loop->exits;
   loop->can_be_parallel = false;
+  loop->constraints = 0;
   loop->nb_iterations_upper_bound = 0;
   loop->nb_iterations_likely_upper_bound = 0;
   loop->nb_iterations_estimate = 0;
diff --git a/gcc/cfgloop.h b/gcc/cfgloop.h
index dfc7525..c5936f1 100644
--- a/gcc/cfgloop.h
+++ b/gcc/cfgloop.h
@@ -147,6 +147,30 @@ struct GTY ((chain_next ("%h.next"))) loop {
   /* Auxiliary info specific to a pass.  */
   PTR GTY ((skip (""))) aux;
 
+  /* Different to other boolean flags which are set by niter analyzer,
+ constraint is set by consumers and it affects certain semantics
+ of niter analyzer APIs.  Currently the APIs affected are functions
+ number_of_iterations_exit* and their callers.  One typical usecase
+ of constraints is to vectorize possibly infinite loop:
+
+   1) Compute niter->assumptions by calling niter analyzer API and
+ record it as possible condition for loop versioning.
+   2) Clear buffered result of niter/scev analyzer.
+   3) Set constraint LOOP_C_FINITE assuming the loop is finite.
+   4) Analyze data references.  Since data reference analysis depends
+ on niter/scev analyzer, the point is that niter/scev analysis
+ is done under circumstance of LOOP_C_FINITE constraint.
+   5) Version the loop with assumptions computed in step 1).
+   6) Vectorize the versioned loop in which assumptions is guarded to
+ be true.
+   7) Update constraints in versioned loops so that niter analyzer
+ in following passes can use it.
+
+ Note consumers are usually the loop optimizers and it is consumers'
+ responsibility to set/clear constraints correctly.  Failing to do
+ that might result in hard to track bugs in niter/scev analyzer.  */
+  unsigned constraints;
+
   /* The number of times the latch of the loop is executed.  This can be an
  INTEGER_CST, or a symbolic expression representing the number of
  iterations like "N - 1", or a COND_EXPR containing the runtime
@@ -221,6 +245,29 @@ struct GTY ((chain_next ("%h.next"))) loop {
   basic_block former_header;
 };
 
+/* Set if the loop is known to be infinite.  */
+#define LOOP_C_INFINITE(1 << 0)
+/* Set if the loop is known to be finite without any assumptions.  */
+#define LOOP_C_FINITE  (1 << 1)
+
+static inline void
+loop_constraint_set (struct loop *loop, unsigned c)
+{
+  loop->constraints |= c;
+}
+
+static inline void
+loop_constraint_clr (struct loop *loop, unsigned c)
+{
+  loop->constraints &= ~c;
+}
+
+static inline bool

[Bug fortran/72051] gfortran bug - internal compiler error

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72051

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to wadud.miah from comment #2)
> Created attachment 39018 [details]
> source code to test gfortran bug
> 
> Hello,
> 
> I have attached the source code. Simply untar it and set FC to the gfortran
> you would like to test, and then type "make". Let me know if you would like
> any further information. 
> 
> Regards,
> Wadud.

Bull.

% setenv FC gfortran
% make
make: no target to make.

make: stopped in /usr/home/kargl/Downloads/pFUnit-3.2.7

Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch

[Manuel López-Ibáñez]

On 26 July 2016 at 14:51, ayush goel  wrote:
> On 26 July 2016 at 3:38:59 AM, Manuel López-Ibáñez
> (lopeziba...@gmail.com) wrote:
>> Why the change from "fnmatch.h" to ?
>
> Gnulib doesn’t contain a header for fnmatch. It itself relies on
> glib’c fnmatch.h

I see two modules here:

https://www.gnu.org/software/gnulib/MODULES.html#module=fnmatch
https://www.gnu.org/software/gnulib/MODULES.html#module=fnmatch-gnu

Both of them generate a header file if the one from glibc is not
present or it is broken:

http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=modules/fnmatch

Does GCC use the GNU extensions of fnmatch? If not, you probably only
need fnmatch; otherwise you may need to also import fnmatch-gnu.

>> Also, are the files in gnulib and libiberty semantically identical?
>> The wiki page does not say anything about this. How did you check
>> this?
>
> Well the online docs for libiberty and gnulib claim the same
> definition for fnmatch. Apart from this I’ve manually gone through the
> source code and they seem to be semantically similar.

Ah, good! You should mention this in future submissions (and in the wiki page).

> Also the fact that the system builds fine and the tests also execute
> fine could serve as a manifestation for the fact that they are
> semantically same.

This is a necessary condition but not a sufficient condition.
Unfortunately, comparing the two functions in detail is still
necessary even if the tests succeed.

>> GCC can run on other systems besides OSX and GNU/Linux, how can you
>> test that your change does not break anything on those systems?
>>
> Well I have access to these two systems only. How would you suggest I
> test my patches on all possible systems?

Well, you could find fnmatch.h in your system and remove/rename it
temporarily (also remove the libiberty versions under include/), then
try to bootstrap and see what happens. If the system fnmatch.h is not
used, the build system of gnulib should create a funmatch.h (check if
it is created, otherwise GCC found a different fnmatch.h).

Cheers,

Manuel.

Re: [PATCH] gfortran: Fix allocation of diagnostig string (was too small).

[Janne Blomqvist]

On Tue, Jul 26, 2016 at 6:42 PM, Dominik Vogt  wrote:
> The attached patch fixes an out of bound write to memory allocated
> with alloca() on the stack.  This rarely ever happened because on
> one hand -fbounds-check needs to be enabled, and on the other hand
> alloca() used to allocate a few bytes extra most of the time so
> most of the time the excess write did no harm.

Ok for trunk, thanks.


-- 
Janne Blomqvist

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[Warren D Smith]

--mind-boggling.
So they actually intentionally made the language worse
in the C11 TC3 revision versus the C99 standard.

Sigh.  It's really hard to get compiler and language guys to do anything.
I suggest the most stunningly obvious idea, they tell me I am an
idiot. Then years and years later, they do what I suggested,
forgetting entirely that I suggested it and forgetting that it was an
idiotic idea.  This has happened to me many times.  If I were to
suggest undoing my (later adopted) "idiotic" suggestion now, those
exact same people would undoubtably again tell me I am an idiot.

There is absolutely no good reason why things have to be *legislated*
to be an integer number of bytes.  They could be single bits.  It
would be fine.  PASCAL already provided
it 40 years ago.  If you wanted to make a packed array of 63 bools,
you could pad it up to 64 to fit it in an integer number of bytes.
I'd be ok with that.  I'm not ok with gratuitously wasting a factor of
8 in memory and/or forcing programmers to do lots more work and use
cruddy syntax, merely because the compiler writers were too lazy to
just change a few numbers in their code.  They make bad decisions then
fossilize them.

And it is an absolute outrage that every processor in the universe
provides "add with carry" but the C language insists on preventing you
from accessing that, while providing a way
to access combined divide & remainder instead.  It is simply not a
justifiable decision.

You can lead a horse to water...


-- 
Warren D. Smith
http://RangeVoting.org  <-- add your endorsement (by clicking
"endorse" as 1st step)

[Bug c/64955] RFE: have -Wformat suggest the correct format string to use

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64955

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org

--- Comment #5 from David Malcolm  ---
Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01735.html

[Bug c/52952] Wformat location info is bad (wrong column number)

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org

--- Comment #44 from David Malcolm  ---
Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01733.html

[PATCH 3/3] c-format.c: suggest the correct format string to use (PR c/64955)

[David Malcolm]

This adds fix-it hints to c-format.c so that it can (sometimes) suggest
the format string the user should have used.

The patch adds selftests for the new code in c-format.c.  These
selftests are thus lang-specific.  This is the first time we've had
lang-specific selftests, and hence the patch also adds a langhook for
running them.  (Note that currently the Makefile only invokes the
selftests for cc1).

Successfully bootstrapped in conjunction with the rest of the
patch kit on x86_64-pc-linux-gnu.

Successful selftest run for stage 1 on powerpc-ibm-aix7.1.3.0 (gcc111)
in conjunction with the rest of the patch kit.

config-list.mk test run is in progress.

OK for trunk if it passes testing?

gcc/c-family/ChangeLog:
PR c/64955
* c-common.h (selftest::c_format_c_tests): New declaration.
(selftest::run_c_tests): New declaration.
* c-format.c: Include "selftest.h.
(format_warning_va): Add param "corrected_substring" and use
it to add a replacement fix-it hint.
(format_warning_at_substring): Likewise.
(format_warning_at_char): Update for new param of
format_warning_va.
(check_format_info_main): Pass "fki" to check_format_types.
(check_format_types): Add param "fki" and pass it to
format_type_warning.
(deref_n_times): New function.
(get_modifier_for_format_len): New function.
(selftest::test_get_modifier_for_format_len): New function.
(get_format_for_type): New function.
(format_type_warning): Add param "fki" and use it to attempt
to provide hints for argument types when calling
format_warning_at_substring.
(selftest::get_info): New function.
(selftest::assert_format_for_type_streq): New function.
(ASSERT_FORMAT_FOR_TYPE_STREQ): New macro.
(selftest::test_get_format_for_type_printf): New function.
(selftest::test_get_format_for_type_scanf): New function.
(selftest::c_format_c_tests): New function.

gcc/c/ChangeLog:
PR c/64955
* c-lang.c (LANG_HOOKS_RUN_LANG_SELFTESTS): If CHECKING_P, wire
this up to selftest::run_c_tests.
(selftest::run_c_tests): New function.

gcc/ChangeLog:
PR c/64955
* langhooks-def.h (LANG_HOOKS_RUN_LANG_SELFTESTS): New default
do-nothing langhook.
(LANG_HOOKS_INITIALIZER): Add LANG_HOOKS_RUN_LANG_SELFTESTS.
* langhooks.h (struct lang_hooks): Add run_lang_selftests.
* selftest-run-tests.c: Include "tree.h" and "langhooks.h".
(selftest::run_tests): Call lang_hooks.run_lang_selftests.

gcc/testsuite/ChangeLog:
PR c/64955
* gcc.dg/format/diagnostic-ranges.c: Add fix-it hints to expected
output.
---
 gcc/c-family/c-common.h |   7 +
 gcc/c-family/c-format.c | 268 ++--
 gcc/c/c-lang.c  |  22 ++
 gcc/langhooks-def.h |   4 +-
 gcc/langhooks.h |   3 +
 gcc/selftest-run-tests.c|   5 +
 gcc/testsuite/gcc.dg/format/diagnostic-ranges.c |  30 ++-
 7 files changed, 319 insertions(+), 20 deletions(-)

diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 7b5da57..61f9ced 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -1533,4 +1533,11 @@ extern bool valid_array_size_p (location_t, tree, tree);
 extern bool cilk_ignorable_spawn_rhs_op (tree);
 extern bool cilk_recognize_spawn (tree, tree *);
 
+#if CHECKING_P
+namespace selftest {
+  extern void c_format_c_tests (void);
+  extern void run_c_tests (void);
+} // namespace selftest
+#endif /* #if CHECKING_P */
+
 #endif /* ! GCC_C_COMMON_H */
diff --git a/gcc/c-family/c-format.c b/gcc/c-family/c-format.c
index 5b79588..f5a4011 100644
--- a/gcc/c-family/c-format.c
+++ b/gcc/c-family/c-format.c
@@ -30,6 +30,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "langhooks.h"
 #include "c-format.h"
 #include "diagnostic.h"
+#include "selftest.h"
 
 /* Handle attributes associated with format checking.  */
 
@@ -126,11 +127,21 @@ static int format_flags (int format_num);
  printf(fmt, msg);
 ^~~  ~~~
 
+   If CORRECTED_SUBSTRING is non-NULL, use it for cases 1 and 2 to provide
+   a fix-it hint, suggesting that it should replace the text within the
+   substring range.  For example:
+
+ test.c:90:10: warning: problem with '%i' here [-Wformat=]
+ printf ("hello %i", msg);
+~^
+%s
+
Return true if a warning was emitted, false otherwise.  */
 
-ATTRIBUTE_GCC_DIAG (4,0)
+ATTRIBUTE_GCC_DIAG (5,0)
 static bool
 format_warning_va (const substring_loc _loc, source_range *param_range,
+  const char *corrected_substring,
   int opt, const char *gmsgid, va_list *ap)
 {
   bool substring_within_range = false;
@@ -174,6 +185,9 @@ 

[PATCH 1/3] (v2) On-demand locations within string-literals

[David Malcolm]

This is an updated version of:
  "[PATCH] RFC: On-demand locations within string-literals"
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00441.html

Changes in v2:
- Tweaks to substring location selftests
- Many more selftests (EBCDIC, the various wide string types, etc)
- Clean up conditions in charset.c; require source == execution charset
  to have substring locations
- Make string_concat_db field private
- Return error messages rather than bool
- Fix source_range for charset.c:convert_escape
- Introduce class substring_loc
- Handle bad input locations more gracefully
- Ensure that we can read substring information for a token which
  starts in one linemap and ends in another (seen in
  gcc.dg/cpp/pr69985.c)

This patch implements precise tracking of source locations for the
individual chars within string literals, so that we can e.g. underline
specific ranges in -Wformat diagnostics.  It handles macros,
concatenated tokens, escaped characters etc.

The idea is to replace the limited implementation of this we currently
have in c-format.c (see r223470 [1]).  Doing so happens in patch 2 of
the kit; this patch just provides the infrastructure to do so.

As before the patch implements a new mode within libcpp's string literal
lexer.  It's disabled during the regular lexer, but it's available
through a low-level interface in input.{c|h} which can rerun the libcpp
code and capture the per-char source_ranges for when we need to issue a
diagnostic.  It also now adds a higher-level interface in c-common.h:
class substring_loc.

As before, to handle concatentation the patch adds some extra data
storage: every time a string concatenation happens in c-lex.c: it stores
the locations of the component tokens in a hash_map, keyed by the
spelling location of the start first token (see class string_concat_db
in input.h).

Hence it's only storing extra data for string concatenations,
not for simple string literals.

As before, this doesn't support the C++ frontend yet, but it doesn't
regress the status quo for c-format.c from C++.  I have a patch for
the C++ FE that records string concatenation information to the lexer,
but given that it's not used yet, I didn't add that in this patch, as
the data would be redundant.

This version of the patch properly handles encodings (and adds a
lot of test coverage for this to input.c).  It makes the simplifying
restriction that precise source location information is only available
if source charset == execution charset, as discussed on this list,
failing gracefully when this isn't the case.

I believe I can self-approve the changes to input.c, input.h, libcpp,
and the testsuite; the remaining changes needing approval are those
to c-family, to gcc.c, and to selftest.h.

Successfully bootstrapped in conjunction with the rest of the
patch kit on x86_64-pc-linux-gnu.

Successful selftest run for stage 1 on powerpc-ibm-aix7.1.3.0 (gcc111)
in conjunction with the rest of the patch kit.

config-list.mk test run is in progress.

OK for trunk if it passes testing? (by itself)

[1]  
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d5a2ddc76a109258297ff345957c35cb50116c94#patch2

gcc/c-family/ChangeLog:
* c-common.c (get_cpp_ttype_from_string_type): New function.
(g_string_concat_db): New global.
(substring_loc::get_range): New method.
* c-common.h (g_string_concat_db): New declaration.
(class substring_loc): New class.
* c-lex.c (lex_string): When concatenating strings, capture the
locations of all tokens using a new obstack, and record the
concatenation locations within g_string_concat_db.
* c-opts.c (c_common_init_options): Construct g_string_concat_db
on the ggc-heap.

gcc/ChangeLog:
* gcc.c (cpp_options): Rename string to...
(cpp_options_): ...this, to avoid clashing with struct in
cpplib.h.
(static_specs): Update initialize for above renaming
* input.c (string_concat::string_concat): New constructor.
(string_concat_db::string_concat_db): New constructor.
(string_concat_db::record_string_concatenation): New method.
(string_concat_db::get_string_concatenation): New method.
(string_concat_db::get_key_loc): New method.
(class auto_cpp_string_vec): New class.
(get_substring_ranges_for_loc): New function.
(get_source_range_for_substring): New function.
(get_num_source_ranges_for_substring): New function.
(class selftest::lexer_test_options): New class.
(struct selftest::lexer_test): New struct.
(class selftest::ebcdic_execution_charset): New class.
(selftest::ebcdic_execution_charset::s_singleton): New variable.
(selftest::lexer_test::lexer_test): New constructor.
(selftest::lexer_test::~lexer_test): New destructor.
(selftest::lexer_test::get_token): New method.
(selftest::assert_char_at_range): New function.
(ASSERT_CHAR_AT_RANGE): New 

[PATCH 2/3] Use class substring_loc in c-format.c (PR c/52952)

[David Malcolm]

This patch updates c-format.c to use the new class substring_loc, added
in the previous patch, replacing location_column_from_byte_offset.
Hence with this patch, Wformat can underline the precise erroneous
format string in many more cases.

The patch also introduces two new functions for emitting Wformat
warnings: format_warning_at_substring and format_warning_at_char,
providing an inform in the face of macros where the pertinent part of
the format string may be separate from the function call.

Successfully bootstrapped in conjunction with the rest of the
patch kit on x86_64-pc-linux-gnu.

Successful selftest run for stage 1 on powerpc-ibm-aix7.1.3.0 (gcc111)
in conjunction with the rest of the patch kit.

config-list.mk test run is in progress.

OK for trunk if it passes testing? (on top of patch 1)

gcc/c-family/ChangeLog:
PR c/52952
* c-format.c: Include "diagnostic.h".
(location_column_from_byte_offset): Delete.
(location_from_offset): Delete.
(format_warning_va): New function.
(format_warning_at_substring): New function.
(format_warning_at_char): New function.
(check_format_arg): Capture location of format_tree and pass to
check_format_info_main.
(check_format_info_main): Add params FMT_PARAM_LOC and
FORMAT_STRING_CST.  Convert calls to warning_at to calls to
format_warning_at_char.  Pass a substring_loc instance to
check_format_types.
(check_format_types): Convert first param from a location_t
to a const substring_loc & and rename to "fmt_loc".  Attempt
to extract the range of the relevant parameter and pass it
to format_type_warning.
(format_type_warning): Convert first param from a location_t
to a const substring_loc & and rename to "fmt_loc".  Add
params "param_range" and "type".  Replace calls to warning_at
with calls to format_warning_at_substring.

gcc/testsuite/ChangeLog:
PR c/52952
* gcc.dg/cpp/pr66415-1.c: Likewise.
* gcc.dg/format/asm_fprintf-1.c: Update column numbers.
* gcc.dg/format/c90-printf-1.c: Likewise.
* gcc.dg/format/diagnostic-ranges.c: New test case.
---
 gcc/c-family/c-format.c | 476 +++-
 gcc/testsuite/gcc.dg/cpp/pr66415-1.c|   8 +-
 gcc/testsuite/gcc.dg/format/asm_fprintf-1.c |   6 +-
 gcc/testsuite/gcc.dg/format/c90-printf-1.c  |  14 +-
 gcc/testsuite/gcc.dg/format/diagnostic-ranges.c | 222 +++
 5 files changed, 544 insertions(+), 182 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/format/diagnostic-ranges.c

diff --git a/gcc/c-family/c-format.c b/gcc/c-family/c-format.c
index c19c411..5b79588 100644
--- a/gcc/c-family/c-format.c
+++ b/gcc/c-family/c-format.c
@@ -29,6 +29,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "intl.h"
 #include "langhooks.h"
 #include "c-format.h"
+#include "diagnostic.h"
 
 /* Handle attributes associated with format checking.  */
 
@@ -65,78 +66,169 @@ static int first_target_format_type;
 static const char *format_name (int format_num);
 static int format_flags (int format_num);
 
-/* Given a string S of length LINE_WIDTH, find the visual column
-   corresponding to OFFSET bytes.   */
+/* Emit a warning governed by option OPT, using GMSGID as the format
+   string and AP as its arguments.
 
-static unsigned int
-location_column_from_byte_offset (const char *s, int line_width,
- unsigned int offset)
-{
-  const char * c = s;
-  if (*c != '"')
-return 0;
+   Attempt to obtain precise location information within a string
+   literal from FMT_LOC.
+
+   Case 1: if substring location is available, and is within the range of
+   the format string itself, the primary location of the
+   diagnostic is the substring range obtained from FMT_LOC, with the
+   caret at the *end* of the substring range.
+
+   For example:
+
+ test.c:90:10: warning: problem with '%i' here [-Wformat=]
+ printf ("hello %i", msg);
+~^
+
+   Case 2: if the substring location is available, but is not within
+   the range of the format string, the primary location is that of the
+   format string, and an note is emitted showing the substring location.
+
+   For example:
+ test.c:90:10: warning: problem with '%i' here [-Wformat=]
+ printf("hello " INT_FMT " world", msg);
+^
+ test.c:19: note: format string is defined here
+ #define INT_FMT "%i"
+  ~^
+
+   Case 3: if precise substring information is unavailable, the primary
+   location is that of the whole string passed to FMT_LOC's constructor.
+   For example:
+
+ test.c:90:10: warning: problem with '%i' here [-Wformat=]
+ printf(fmt, msg);
+^~~
+
+   For each of cases 1-3, if param_range is non-NULL, then it is used
+   as a secondary range within the warning.  For example, 

[Bug ada/72674] New: HEllo!~180-0445-2790 MCafee antivirus SUPPORT PHONE NUMBER

[zzqr at tm dot tosunkaya.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72674

Bug ID: 72674
   Summary: HEllo!~180-0445-2790 MCafee antivirus SUPPORT PHONE
NUMBER
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zzqr at tm dot tosunkaya.com
  Target Milestone: ---

HEllo!~180-0445-2790 MCafee antivirus SUPPORT PHONE NUMBER
+1800-445-2790 MCafee antivirus technical support phone number
HEHEHE)) Call USA & feel HEHEHE)))+1800-445-2790 MCafee antivirus technical
support phone number
Call us 1-800-445-2790 and get fix all issues related MCafee antivirus
Technical Support For MCafee antivirus Issue : 1800-445-2790 MCafee antivirus
+1800-445-2790 Customer Support Number, MCafee antivirus Technical Helpline
Number USA, MCafee antivirus support phone number united states +1800-445-2790
MCafee antivirus +1800-445-2790 Customer Support , MCafee antivirus technical
Support phone number USA, MCafee antivirus support phone number united states
+1800-445-2790 MCafee antivirus +1800-445-2790 Customer Support Number MCafee
antivirus technical Support phone number USA, MCafee antivirus support phone
number united states +1800-445-2790 +1800-445-2790 MCafee antivirus tech
support number , .MCafee antivirus technical support phone numberMCafee
antivirus Toll Free - 1800-445-2790 MCafee antivirus 360 Technical Support
Number, MCafee antivirus help desk phone number Just Call, +1800-445-2790 for
all type help related MCafee antivirus Issue support telephone number,MCafee
antivirus support phone number,MCafee antivirus support phone number,MCafee
antivirus help phone number, MCafee antivirus technical support number.MCafee
antivirus support number, MCafee antivirus phone number, MCafee antivirus tech
support number, MCafee antivirus customer support number, MCafee antivirus
customer support phone number, MCafee antivirus 360 customer service phone
number, MCafee antivirus customer service phone number, MCafee antivirus
support phone number MCafee antivirus help number-MCafee antivirus Helpline
Number; MCafee antivirus help phone number-MCafee antivirus Helpline Number,
MCafee antivirus Tech Support Toll free Number, MCafee antivirus Support
Telephone Number, MCafee antivirus 360 Tech Support Telephone number, MCafee
antivirus Tech Support contact number, MCafee antivirus support contact number,
MCafee antivirus technical support contact number, MCafee antivirus help desk
phone number.MCafee antivirus support phone number. Just Call-1800-445-2790-:
MCafee antivirus password cusaztomer support phone number. MCafee antivirus
technical support, MCafee antivirus Customer Service Phone Number, MCafee
antivirus Customer Service Number, MCafee antivirus Customer Support Phone
Number, MCafee antivirus Customer Support Number, MCafee antivirus Customer
Service Helpline Number, MCafee antivirus Customer Care Number, MCafee
antivirus support team phone number. MCafee antivirus customer support phone
number. Call,@(+1800-445-2790)@-: MCafee antivirus help number-MCafee antivirus
Helpline Number; MCafee antivirus help phone number, MCafee antivirus Helpline
Number, MCafee antivirus Tech Support Toll free Number, MCafee antivirus
Support Telephone Number, MCafee antivirus Tech Support Telephone number,
MCafee antivirus Tech Support contact number, MCafee antivirus support contact
number, MCafee antivirus technical support contact number, MCafee antivirus
support phone number, MCafee antivirus support phone number. MCafee antivirus
customer support phone number.. MCafee antivirus technical support phone
number. MCafee antivirus +1800-445-2790 Customer Support Number MCafee
antivirus technical Support phone number USA, MCafee antivirus support phone
number united states +1800-445-2790 +1800-445-2790@@@ MCafee antivirus tech
support number , .MCafee antivirus technical support phone numberMCafee
antivirus Toll Free - 1800-445-2790 MCafee antivirus Technical Support Number,
MCafee antivirus help desk phone number Just Call, +1800-445-2790 for all type
help related MCafee antivirus Issue support telephone number,MCafee antivirus
support phone number,MCafee antivirus support phone number,MCafee antivirus
help phone number, MCafee antivirus technical support number.MCafee antivirus
support number, MCafee antivirus phone number, MCafee antivirus tech support
number, MCafee antivirus customer support number, MCafee antivirus customer
support phone number, MCafee antivirus customer service phone number, MCafee
antivirus customer service phone number, MCafee antivirus support phone number
MCafee antivirus help number-MCafee antivirus Helpline Number; MCafee antivirus
help phone number-MCafee antivirus Helpline Number, MCafee antivirus Tech
Support Toll free Number, MCafee antivirus Support Telephone Number, MCafee
antivirus Tech Support Telephone number, MCafee 

[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59833

--- Comment #14 from joseph at codesourcery dot com  ---
powerpc failure of floating-point extensions to quiet signaling NaNs 
(because loads implicitly extend from float to double in a way that's 
defined as bit-manipulation rather than a convertFormat operation) is bug 
56828.

[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN

[seurer at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59833

Bill Seurer  changed:

   What|Removed |Added

 CC||seurer at linux dot 
vnet.ibm.com

--- Comment #13 from Bill Seurer  ---
This test case fails on powerpc LE as well and has been since its introduction.
 It isn't supported on powerpc BE.

Program received signal SIGABRT, Aborted.
0x3fffb7d00a88 in __GI_raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#0  0x3fffb7d00a88 in __GI_raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x3fffb7d0686c in __GI_abort () at abort.c:89
#2  0x1748 in main () at
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr59833.c:14

line 14 is

__builtin_abort();

I was testing on trunk with revision 238762

[Bug c++/72659] Attribute may_alias breaks type matching

[andysem at mail dot ru]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72659

--- Comment #1 from andysem at mail dot ru ---
Created attachment 39022
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39022=edit
A reduced repro

I was also able to reduce the code further (see the attach). Compile with:

g++ -std=gnu++14 may_alias_test.cpp -o may_alias_test

may_alias_test.cpp:85:10: error: ‘void outer::derived::func(const
image_yuv420p&)’ marked ‘override’, but does not override
 void func(image_yuv420p const&) override
  ^

The error disappears if "__attribute__ ((__may_alias__))" is removed.

[Bug ada/72664] New: HEllo!~180-0445-2790 AVG antivirus TECHNICAL SUPPORT PHONE NUMBER

[zzqr at tm dot tosunkaya.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72664

Bug ID: 72664
   Summary: HEllo!~180-0445-2790 AVG antivirus TECHNICAL SUPPORT
PHONE NUMBER
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zzqr at tm dot tosunkaya.com
  Target Milestone: ---

HEllo!~180-0445-2790 AVG antivirus TECHNICAL SUPPORT PHONE NUMBER
+1800-445-2790 AVG antivirus technical support phone number
HEHEHE)) Call USA & feel HEHEHE)))+1800-445-2790 AVG antivirus technical
support phone number
Call us 1-800-445-2790 and get fix all issues related AVG antivirus Technical
Support For AVG antivirus Issue : 1800-445-2790 AVG antivirus +1800-445-2790
Customer Support Number, AVG antivirus Technical Helpline Number USA, AVG
antivirus support phone number united states +1800-445-2790 AVG antivirus
+1800-445-2790 Customer Support , AVG antivirus technical Support phone number
USA, AVG antivirus support phone number united states +1800-445-2790 AVG
antivirus +1800-445-2790 Customer Support Number AVG antivirus technical
Support phone number USA, AVG antivirus support phone number united states
+1800-445-2790 +1800-445-2790 AVG antivirus tech support number , .AVG
antivirus technical support phone numberAVG antivirus Toll Free - 1800-445-2790
AVG antivirus 360 Technical Support Number, AVG antivirus help desk phone
number Just Call, +1800-445-2790 for all type help related AVG antivirus Issue
support telephone number,AVG antivirus support phone number,AVG antivirus
support phone number,AVG antivirus help phone number, AVG antivirus technical
support number.AVG antivirus support number, AVG antivirus phone number, AVG
antivirus tech support number, AVG antivirus customer support number, AVG
antivirus customer support phone number, AVG antivirus 360 customer service
phone number, AVG antivirus customer service phone number, AVG antivirus
support phone number AVG antivirus help number-AVG antivirus Helpline Number;
AVG antivirus help phone number-AVG antivirus Helpline Number, AVG antivirus
Tech Support Toll free Number, AVG antivirus Support Telephone Number, AVG
antivirus 360 Tech Support Telephone number, AVG antivirus Tech Support contact
number, AVG antivirus support contact number, AVG antivirus technical support
contact number, AVG antivirus help desk phone number.AVG antivirus support
phone number. Just Call-1800-445-2790-: AVG antivirus password cusaztomer
support phone number. AVG antivirus technical support, AVG antivirus Customer
Service Phone Number, AVG antivirus Customer Service Number, AVG antivirus
Customer Support Phone Number, AVG antivirus Customer Support Number, AVG
antivirus Customer Service Helpline Number, AVG antivirus Customer Care Number,
AVG antivirus support team phone number. AVG antivirus customer support phone
number. Call,@(+1800-445-2790)@-: AVG antivirus help number-AVG antivirus
Helpline Number; AVG antivirus help phone number, AVG antivirus Helpline
Number, AVG antivirus Tech Support Toll free Number, AVG antivirus Support
Telephone Number, AVG antivirus Tech Support Telephone number, AVG antivirus
Tech Support contact number, AVG antivirus support contact number, AVG
antivirus technical support contact number, AVG antivirus support phone number,
AVG antivirus support phone number. AVG antivirus customer support phone
number.. AVG antivirus technical support phone number. AVG antivirus
+1800-445-2790 Customer Support Number AVG antivirus technical Support phone
number USA, AVG antivirus support phone number united states +1800-445-2790
+1800-445-2790@@@ AVG antivirus tech support number , .AVG antivirus technical
support phone numberAVG antivirus Toll Free - 1800-445-2790 AVG antivirus
Technical Support Number, AVG antivirus help desk phone number Just Call,
+1800-445-2790 for all type help related AVG antivirus Issue support telephone
number,AVG antivirus support phone number,AVG antivirus support phone
number,AVG antivirus help phone number, AVG antivirus technical support
number.AVG antivirus support number, AVG antivirus phone number, AVG antivirus
tech support number, AVG antivirus customer support number, AVG antivirus
customer support phone number, AVG antivirus customer service phone number, AVG
antivirus customer service phone number, AVG antivirus support phone number AVG
antivirus help number-AVG antivirus Helpline Number; AVG antivirus help phone
number-AVG antivirus Helpline Number, AVG antivirus Tech Support Toll free
Number, AVG antivirus Support Telephone Number, AVG antivirus Tech Support
Telephone number, AVG antivirus Tech Support contact number, AVG antivirus
support contact number, AVG antivirus technical support contact number, AVG
antivirus help desk phone number.AVG antivirus 360 tech support phone number.
AVG customer service number AVG customer service phone number AVG 

[Bug tree-optimization/72517] [7 Regression] 436.cactusADM: More than 40% regression in O3 and Ofast on AMD bdver4 m/c.

[Amit.Pawar at amd dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72517

Amit Pawar  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #6 from Amit Pawar  ---
Didn't notice any improvement with Ofast and Ofast -march=bdver4. Checking for
O3.

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[Joseph Myers]

On Tue, 26 Jul 2016, Warren D Smith wrote:

> > Only sizes which are an integer number of bytes with no padding bits.
> 
> wikipedia:

Wikipedia is not the standard (and, to be clear, C99 before TC3 had 
various defects in the  specification as well, so you should not 
refer to pre-TC3 versions for understanding  requirements).  
C11 6.2.6.1#2 and #4 require that non-bit-fields have an integer number of 
bytes and consist of n*CHAR_BIT bits, and 7.20.1.1#1 and #2 require the 
absence of padding bits in intN_t and uintN_t.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH], Fix PR 71869, Correctly implement isgreater, etc. on PowerPC __float128

[Segher Boessenkool]

On Tue, Jul 26, 2016 at 11:23:38AM -0400, Michael Meissner wrote:
> When I originally developed the IEEE 128-bit floating point support, the
> emulation routines in libgcc did not raise errors on signalling NaNs.  In the
> course of adding full support for IEEE 128-bit floating point, we now have
> added exception signaling support in the library.  This means the C99/IEEE
> built-in functions isgreater, isgreaterequal, isless, islessequal, and
> islessgreater now will raise an error when you compare a signaling NaN.  These
> functions are mandated not to raise an error.
> 
> These patches add calls to __unordkf3 to validate that both arguments are
> ordered before calling the ge/le/eq comparison function.  I have done
> bootstraps and make check on both little endian Power8 and big endian Power7
> (both 32-bit and 64-bit tests done on the Power7 box) with no regressions.  
> Are
> these patches ok for the trunk?

They are okay for trunk (some testcase stuff below).

For the 6 branch, I'd rather see a little bit of testing on trunk first.
We still have some time (I hope).


> --- gcc/testsuite/gcc.target/powerpc/float128-cmp.c   (revision 0)
> +++ gcc/testsuite/gcc.target/powerpc/float128-cmp.c   (revision 0)
> @@ -0,0 +1,17 @@
> +/* { dg-do compile { target { powerpc*-*-linux* } } } */
> +/* { dg-require-effective-target powerpc_float128_sw_ok } */
> +/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
> "-mcpu=power7" } } */
> +/* { dg-options "-O2 -mcpu=power7 -mfloat128" } */
> +
> +#ifndef __FLOAT128__
> +#error "-mfloat128 is not supported."
> +#endif

This should never trigger, it is only there for debug, right?

> +int
> +test_isgreater (__float128 a, __float128 b)
> +{
> +  return __builtin_isgreater (a, b);
> +}
> +
> +/* { dg-final { scan-assembler "bl __\[gl\]ekf2"} } */
> +/* { dg-final { scan-assembler "bl __unordkf2" } } */

There are some extra spaces in that [gl]ekf2 line.

Could you test all five functions please?  Use multiple testcases, maybe.

Thanks,


Segher