[Bug libstdc++/70722] include_next in cmath skips user-defined wrapper

[martin.thomson at gmail dot com]

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

--- Comment #1 from Martin Thomson  ---
My ViewCVS-fu isn't that good, it took me long enough to find this:

https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/c_global/cmath?r1=232585=232586;

[Bug libstdc++/70722] New: include_next in cmath skips user-defined wrapper

[martin.thomson at gmail dot com]

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

Bug ID: 70722
   Summary: include_next in cmath skips user-defined wrapper
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: martin.thomson at gmail dot com
  Target Milestone: ---

Firefox has a bunch of wrappers for system headers.  I'm not 100% on the
reasoning, but most just play with visibility.  For instance, the math.h
wrapper looks like:

   #pragma GCC system_header
   #pragma GCC visibility push(default)
   #include_next 
   #pragma GCC visibility pop

Firefox fails to link when built with libstdc++ 6.0.0 because it includes
 before it includes .  This leads to inclusion of  with
different visibility than is desired.

The version of cmath I have includes this:

   #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
   #include_next 
   #undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS

Removing the "_next" causes the build to succeed.

You can see my flailings regarding this issue here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1264534

[Bug middle-end/70689] [6/7 Regression] ICE on valid code at -O1 in 32-bit mode on x86_64-linux-gnu in curr_insn_transform, at lra-constraints.c:3564

[vmakarov at gcc dot gnu.org]

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

--- Comment #4 from Vladimir Makarov  ---
Author: vmakarov
Date: Tue Apr 19 02:49:54 2016
New Revision: 235184

URL: https://gcc.gnu.org/viewcvs?rev=235184=gcc=rev
Log:
2016-04-18  Vladimir Makarov  

PR middle-end/70689
* lra-constraints.c (equiv_substition_p): New.
(process_alt_operands): Use it.
(swap_operands): Swap it.
(curr_insn_transform): Update it.

2016-04-18  Vladimir Makarov  

PR middle-end/70689
* testsuite/gcc.target/i386/pr70689.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr70689.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

[Bug target/70721] Suboptimal code generated when using _mm_min_sd

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-19
 CC||ubizjak at gmail dot com
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
This is NOT the fix.  But you should get the idea:

[hjl@gnu-6 pr70708]$ cat y.c
#include 

double
__attribute ((noinline, noclone))
foo (double a, double b)
{
   __m128d x = _mm_set_sd(a);
   __m128d y = _mm_set_sd(b);
   return _mm_cvtsd_f64(_mm_min_sd(x, y));
}
[hjl@gnu-6 pr70708]$ make y.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -S -o y.s y.c
[hjl@gnu-6 pr70708]$ cat y.s
.file   "y.c"
.text
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB525:
.cfi_startproc
minsd   %xmm1, %xmm0
ret
.cfi_endproc
.LFE525:
.size   foo, .-foo
.ident  "GCC: (GNU) 7.0.0 20160418 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 pr70708]$ cat /tmp/x
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a66cfc4..167a564 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -32934,7 +32934,7 @@ static const struct builtin_description bdesc_args[] =

   { OPTION_MASK_ISA_SSE2, CODE_FOR_sminv2df3, "__builtin_ia32_minpd",
IX86_BUILTIN_MINPD, UNKNOWN, (int) V2DF_FTYPE_V2DF_V2DF },
   { OPTION_MASK_ISA_SSE2, CODE_FOR_smaxv2df3, "__builtin_ia32_maxpd",
IX86_BUILTIN_MAXPD, UNKNOWN, (int) V2DF_FTYPE_V2DF_V2DF },
-  { OPTION_MASK_ISA_SSE2, CODE_FOR_sse2_vmsminv2df3, "__builtin_ia32_minsd",
IX86_BUILTIN_MINSD, UNKNOWN, (int) V2DF_FTYPE_V2DF_V2DF },
+  { OPTION_MASK_ISA_SSE2, CODE_FOR_xx_vmsminv2df3, "__builtin_ia32_minsd",
IX86_BUILTIN_MINSD, UNKNOWN, (int) V2DF_FTYPE_V2DF_V2DF },
   { OPTION_MASK_ISA_SSE2, CODE_FOR_sse2_vmsmaxv2df3, "__builtin_ia32_maxsd",
IX86_BUILTIN_MAXSD, UNKNOWN, (int) V2DF_FTYPE_V2DF_V2DF },

   { OPTION_MASK_ISA_SSE2, CODE_FOR_andv2df3, "__builtin_ia32_andpd",
IX86_BUILTIN_ANDPD, UNKNOWN, (int) V2DF_FTYPE_V2DF_V2DF },
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 78c28c5..c8ce275 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -1656,6 +1656,28 @@
(set_attr "prefix" "")
(set_attr "mode" "")])

+(define_insn "xx_vmv2df3"
+  [(set (match_operand:V2DF 0 "register_operand" "=x,v")
+(vec_concat:V2DF
+ (smaxmin:DF
+   (vec_select:DF
+ (match_operand:V2DF 1 "register_operand" "0,v")
+ (parallel [(const_int 0)]))
+   (vec_select:DF
+ (match_operand:V2DF 2 "vector_operand" "xm,vm")
+ (parallel [(const_int 0)])))
+ (vec_select:DF (match_dup 0)
+(parallel [(const_int 1)]]
+  "TARGET_SSE2"
+  "@
+   sd\t{%2, %0|%0, %2}
+   vsd\t{%2, %1, %0|%0, %1, %2}"
+  [(set_attr "isa" "noavx,avx")
+   (set_attr "type" "sse")
+   (set_attr "prefix" "orig,vex")
+   (set_attr "btver2_sse_attr" "maxmin")
+   (set_attr "mode" "DF")])
+
 ;; These versions of the min/max patterns implement exactly the operations
 ;;   min = (op1 < op2 ? op1 : op2)
 ;;   max = (!(op1 < op2) ? op1 : op2)
[hjl@gnu-6 pr70708]$

[Bug target/68211] Free __m128d subreg of double

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2016-04-19
 CC||kirill.yukhin at intel dot com
 Resolution|DUPLICATE   |---
 Ever confirmed|0   |1

--- Comment #5 from H.J. Lu  ---
There is

(insn 10 9 11 2 (parallel [
(set (reg:V2DF 92) 
(vec_merge:V2DF (sqrt:V2DF (reg:V2DF 93))
(reg:V2DF 94) 
(const_int 1 [0x1])))
(unspec [
(const_int 10 [0xa])
] UNSPEC_EMBEDDED_ROUNDING)
])
/export/build/gnu/gcc/build-x86_64-linux/gcc/include/avx512fintrin.h:1736 1448
{sse2_vmsqrtv2df2_round}
 (nil))

Is that possible to change it to make sqrt to apply only to the
first 64-bit of input operand?

[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure

[dje at gcc dot gnu.org]

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

--- Comment #10 from David Edelsohn  ---
This is starting to look like PR60984 all over again.  Testing trunk with
--enable-checking=release succeeds.

[Bug target/70708] Suboptimal code generated when using _mm_set_sd (X64)

[hjl.tools at gmail dot com]

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

--- Comment #16 from H.J. Lu  ---
(In reply to Marc Glisse from comment #15)
> MyMinV2 returns a double, not a __m128d. I tried to read what the ABI says
> about the unused upper part of SSE registers when passing/returning a double
> and couldn't find any information. Could you explain in more details what
> makes MyMinV2 so different from MyMinV1? I appear to be missing some crucial
> piece of information here :-(

I opened PR 70721 for the _mm_min_sd issue.

[Bug target/70721] New: Suboptimal code generated when using _mm_min_sd

[hjl.tools at gmail dot com]

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

Bug ID: 70721
   Summary: Suboptimal code generated when using _mm_min_sd
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: kirill.yukhin at intel dot com
  Target Milestone: ---

_mm_min_sd is implemented as

(define_insn "_vm3"
  [(set (match_operand:VF_128 0 "register_operand" "=x,v")
(vec_merge:VF_128
  (smaxmin:VF_128
(match_operand:VF_128 1 "register_operand" "0,v")
(match_operand:VF_128 2 "vector_operand"
"xBm,"))
 (match_dup 1)
 (const_int 1)))] 

The problem is smaxmin is applied to the full 128-bit operand.
Can we change it to apply only to the first 64-bit of operand
so that we can remove 2 xmm moves in

---
#include 

double
__attribute ((noinline, noclone))
foo (double a, double b)
{
   __m128d x = _mm_set_sd(a);
   __m128d y = _mm_set_sd(b);
   return _mm_cvtsd_f64(_mm_min_sd(x, y));
}
---

[Bug c/29280] misleading warning for assignment used as truth construct

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Martin Sebor from comment #5)
> It seems like it should be trivial to enhance the warning by adding a note
> with the suggestion(s) mentioned in the request.

Given all the cases mentioned in PR25733, we should find a better way for users
to silence the warning. For example, by using an explicit cast.

Example:

int foo(int a, int b)
{
return ((a = b) ? 1 : 0);  // <= missed warning.
}

warning: using the result of an assignment as a boolean expression
[-Wparentheses]
 return ((a = b) ? 1 : 0);
  ~~^~~
note: add an explicit cast to bool to silence this warning
 return ((a = b) ? 1 : 0);
  ^
  (bool)

note: use '==' to turn this assignment into an equality comparison
 return ((a = b) ? 1 : 0);
^
==

[Bug middle-end/70689] [6/7 Regression] ICE on valid code at -O1 in 32-bit mode on x86_64-linux-gnu in curr_insn_transform, at lra-constraints.c:3564

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #2)
> 
> Vlad, could you please have a look at this?

I've started work on it.

[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure

[dje at gcc dot gnu.org]

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

--- Comment #9 from David Edelsohn  ---
r224187 works

[Bug target/69148] [5 Regression] ICE (floating point exception) on s390x-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #8 from Matthias Klose  ---
I prepared a patch for the distro builds. Any reason that this can't go to the
gcc-5-branch?

[Bug c++/70667] SFINAE error disambiguating using alignas

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
I'm not sure if that changes the validity of the test case (the invalid
alignment on the member makes the whole class invalid) but the error is the
same with A defined with the alignment specifier rather than its member.
template  struct alignas (N) A { int a; };

[Bug libgcc/70720] New: moxie-rtems stanza does not include crti/crtn extra_parts

[joel at gcc dot gnu.org]

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

Bug ID: 70720
   Summary: moxie-rtems stanza does not include crti/crtn
extra_parts
   Product: gcc
   Version: 4.9.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org
  Target Milestone: ---

Created attachment 38305
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38305=edit
Merge moxie-rtems stanza with other moxie stanzas.

moxie-rtems C++ applications fail to link because, the moxie-rtems stanza in
libgcc/config.host does not include extra_parts.

The solution is to add moxie-rtems to the list of other moxie targets above and
delete the special moxie-rtems stanza.

Filing this as a bug since it impacts at least from gcc 4.9 to the master.

[Bug testsuite/70719] New: the libjava testsuite does not work with dejagnu 1.6

[dominiq at lps dot ens.fr]

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

Bug ID: 70719
   Summary: the libjava testsuite does not work with dejagnu 1.6
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
  Target Milestone: ---

The libjava testsuite does not work with dejagnu 1.6:

=== libjava tests ===

Schedule of variations:
unix/-m32
unix/-m64

Running target unix/-m32
Using /sw64/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw64/share/dejagnu/config/unix.exp as generic interface file for target.
Using ../../../../_clean/libjava/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running ../../../../_clean/libjava/testsuite/libjava.cni/cni.exp ...
ERROR: (DejaGnu) proc "absolute
/opt/gcc/build_c/x86_64-apple-darwin15.4.0/libjava/testsuite" does not exist.
The error code is TCL LOOKUP COMMAND absolute
The info on the error is:
invalid command name "absolute"
while executing
"::tcl_unknown absolute
/opt/gcc/build_c/x86_64-apple-darwin15.4.0/libjava/testsuite"
("uplevel" body line 1)
invoked from within
"uplevel 1 ::tcl_unknown $args"

=== libjava Summary ===

# of expected passes1
Makefile:409: recipe for target 'check-DEJAGNU' failed
make[1]: *** [check-DEJAGNU] Error 1
make[1]: Leaving directory
'/opt/gcc/build_c/x86_64-apple-darwin15.4.0/libjava/testsuite'
Makefile:427: recipe for target 'check-am' failed
make: *** [check-am] Error 2
make: Target 'check' not remade because of errors.

Probably related to

1.2 New in this release

...

6. The user-visible utility procedures absolute, psource and slay have been
removed. If a testsuite uses any of these procedures, a copy of the procedure
should be made and placed in the lib directory of the testsuite.

[Bug c++/70667] SFINAE error disambiguating using alignas

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
The error here (in the definition of `A`) certainly looks like it's outside the
immediate context...?

[Bug c++/60799] access checking within injected friend functions does not happen in the context of the enclosing class

[Casey at Carter dot net]

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

--- Comment #5 from Casey Carter  ---
(In reply to TC from comment #4)
> 
> I don't think that reading makes much sense. Among member-declarations that
> do not declare a member are static_assert-declarations and unnamed bit-field
> declarations, so that reading disallows
> 
> class A {
> constexpr static bool value = true;
> friend class B;
> };
> 
> class B {
> static_assert(B::value, "");
> };
> 
> And disallows D in the below example but not E:
> 
> class C {
> constexpr static int value = 4;
> friend class D;
> friend class E;
> };
> 
> class D {
> int : C::value;
> };
> 
> class E {
> int i : C::value;
> };

I agree that my interpretation breaks things that should work, but given how
[class.mem]/1 goes out of its way to distinguish between member-declarations
and "declarations of members", it does seem to be what is specified. I think
the intent has been lost in the wording.

I've just discovered this problem is the topic of open CWG issue 1699
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1699; upstream is
already on-the-job.

[Bug target/70718] New: multilib_defaults on nios2 refers to -EL

[stilor at att dot net]

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

Bug ID: 70718
   Summary: multilib_defaults on nios2 refers to -EL
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stilor at att dot net
  Target Milestone: ---

Created attachment 38304
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38304=edit
Proposed fix

On nios2, multilib_defaults spec refers to the -EL/-EB options, but the driver
does not recognize them on nios2. Instead, the driver uses -mel/-meb (see the
asm/link specs, right next to the modified multilib spec, in the attached
patch).

[Bug preprocessor/70707] INT_MAX used before it is defined

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |preprocessor

--- Comment #4 from Andrew Pinski  ---
There is no bug here.  The prepocessor works this way.
That is the INT_MIN is replaced with (-INT_MAX - 1) and then INT_MAX is
replaced with 2147483647 when the usage of INT_MIN happens.

[Bug sanitizer/70717] -fsanitize=object-size as warning

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
-D_FORTIFY_SOURCE=1 or -D_FORTIFY_SOURCE=2 handle this well:
warning: call to __builtin___memcpy_chk will always overflow destination buffer

[Bug c++/60799] access checking within injected friend functions does not happen in the context of the enclosing class

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #4 from TC  ---
(In reply to Casey Carter from comment #3)
> >  I'm inclined to the second interpretation, which would imply the behavior 
> > described in this bug report is what the standard intends.
> 
> This is me stumbling over my words attempting to say "I think this is NOT a
> bug."

I don't think that reading makes much sense. Among member-declarations that do
not declare a member are static_assert-declarations and unnamed bit-field
declarations, so that reading disallows

class A {
constexpr static bool value = true;
friend class B;
};

class B {
static_assert(B::value, "");
};

And disallows D in the below example but not E:

class C {
constexpr static int value = 4;
friend class D;
friend class E;
};

class D {
int : C::value;
};

class E {
int i : C::value;
};

[Bug sanitizer/70717] -fsanitize=object-size as warning

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
You might get the warning with -D_FORTIFY_SOURCE=1 but I have not tried it
myself.

[Bug libstdc++/70472] is_copy_constructible<vector<unique_ptr>>::value is true

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #5 from TC  ---
In any event, it would be wrong to SFINAE on
std::is_copy_constructible. The requirement is CopyInsertable, not
CopyConstructible. The allocator's construct() can mutilate the constructor
arguments to its heart's content before passing them on, and I don't see a way
to check this.

[Bug c/70707] INT_MAX used before it is defined

[aleks at physik dot tu-berlin.de]

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

--- Comment #3 from Alexander Kleinsorge  ---
Problem confirmed with: gcc (GCC) 5.3.0
Usage before definition is no header problem (as suggested by Lewis).

// TestCode, no includes
#  define INT_MIN   (-INT_MAX - 1)
#  define INT_MAX   2147483647
int test1(int b) {
return (b + INT_MIN);
}
int main(int argc, char** argv) {
return test1( argc );
}
// EndOfFile

[Bug c/70707] INT_MAX used before it is defined

[aleks at physik dot tu-berlin.de]

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

Alexander Kleinsorge  changed:

   What|Removed |Added

 CC||aleks at physik dot 
tu-berlin.de

--- Comment #2 from Alexander Kleinsorge  ---
Problem confirmed with: gcc (GCC) 5.3.0
Usage before definition is no header problem (as suggested by Lewis).

// TestCode, no includes
#  define INT_MIN   (-INT_MAX - 1)
#  define INT_MAX   2147483647
int test1(int b) {
return (b + INT_MIN);
}
int main(int argc, char** argv) {
return test1( argc );
}
// EndOfFile

[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure

[dje at gcc dot gnu.org]

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

--- Comment #8 from David Edelsohn  ---
Development branch prior to debug-early merge works.

[Bug target/70708] Suboptimal code generated when using _mm_set_sd (X64)

[glisse at gcc dot gnu.org]

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

--- Comment #15 from Marc Glisse  ---
(In reply to H.J. Lu from comment #13)
> (In reply to Marc Glisse from comment #11)
> > Since for MyMinV1 we generate no move at all, then that code should also be
> > valid for MyMinV2 (no issue with sNaN in the upper part or whatever).
> 
> Since _mm_set_sd clears upper bits, return from MyMinV2 should have upper
> bits cleared. If not, it is a bug.

MyMinV2 returns a double, not a __m128d. I tried to read what the ABI says
about the unused upper part of SSE registers when passing/returning a double
and couldn't find any information. Could you explain in more details what makes
MyMinV2 so different from MyMinV1? I appear to be missing some crucial piece of
information here :-(

[Bug target/70708] Suboptimal code generated when using _mm_set_sd (X64)

[glisse at gcc dot gnu.org]

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

--- Comment #14 from Marc Glisse  ---
(In reply to H.J. Lu from comment #12)
> (In reply to Marc Glisse from comment #11)
> > As I told you in the other PR, movq is *NOT* what the PRs are asking for, it
> 
> See the subject of this PR.

1) I know for certain this is not what PR68211 (a bug you closed as a
duplicate) was asking for, since I filed that one.

2) If you read the summary, the optimal code Petr is asking for here is no move
at all, i.e. the same clang is generating. movq is still suboptimal here.

While I really appreciate the quick improvement on using movq, I don't
understand why you are so set on closing these PRs... Intel's intrinsics and
their gcc implementation make it hard to write scalar code without overhead,
that seems a relevant concern to me.

[Bug target/70708] Suboptimal code generated when using _mm_set_sd (X64)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from H.J. Lu  ---
(In reply to Marc Glisse from comment #11)
> Since for MyMinV1 we generate no move at all, then that code should also be
> valid for MyMinV2 (no issue with sNaN in the upper part or whatever).

Since _mm_set_sd clears upper bits, return from MyMinV2 should have upper
bits cleared. If not, it is a bug.

[Bug sanitizer/70717] New: -fsanitize=object-size as warning

[aleks at physik dot tu-berlin.de]

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

Bug ID: 70717
   Summary: -fsanitize=object-size as warning
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aleks at physik dot tu-berlin.de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

a new warning could detect problems earlier than "-fsanitize=object-size".
The following code is wrong, should be detected by "-fsanitize=object-size",
but it could be detected already at compile-time, especially for
memset/memcpy/memcmp .

char a[8], b[16]; memcpy(a,b,sizeof(b)); // write out of bounds, a[8..15] does
not exist

Thanks for reading

[Bug target/70708] Suboptimal code generated when using _mm_set_sd (X64)

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
(In reply to Marc Glisse from comment #11)
> As I told you in the other PR, movq is *NOT* what the PRs are asking for, it

See the subject of this PR.

[Bug c++/60799] access checking within injected friend functions does not happen in the context of the enclosing class

[Casey at Carter dot net]

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

--- Comment #3 from Casey Carter  ---
>  I'm inclined to the second interpretation, which would imply the behavior 
> described in this bug report is what the standard intends.

This is me stumbling over my words attempting to say "I think this is NOT a
bug."

[Bug target/70708] Suboptimal code generated when using _mm_set_sd (X64)

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|FIXED   |---

--- Comment #11 from Marc Glisse  ---
As I told you in the other PR, movq is *NOT* what the PRs are asking for, it
was just a side remark. If you consider clang's code completely broken and
gcc's code optimal, then the PR is invalid. Otherwise, it needs to stay open.

Since for MyMinV1 we generate no move at all, then that code should also be
valid for MyMinV2 (no issue with sNaN in the upper part or whatever).

[Bug c++/70505] [4.9/5/6/7 Regression] Constexpr failure when template type specified

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Mon Apr 18 19:43:19 2016
New Revision: 235170

URL: https://gcc.gnu.org/viewcvs?rev=235170=gcc=rev
Log:
PR c++/70505

* pt.c (tsubst_baselink): Give the new TEMPLATE_ID_EXPR
unknown_type_node, too.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-template10.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/pt.c

[Bug c++/70690] [6/7 Regression] r235002 miscompiles tcmalloc

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Mon Apr 18 19:43:26 2016
New Revision: 235171

URL: https://gcc.gnu.org/viewcvs?rev=235171=gcc=rev
Log:
PR c++/70690

PR c++/70528
* class.c (type_maybe_constexpr_default_constructor): New.
(type_has_constexpr_default_constructor): Revert.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/init/array41.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/class.c

[Bug c++/70528] [5 Regression] bogus error: constructor required before non-static data member

[jason at gcc dot gnu.org]

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

--- Comment #14 from Jason Merrill  ---
Author: jason
Date: Mon Apr 18 19:43:26 2016
New Revision: 235171

URL: https://gcc.gnu.org/viewcvs?rev=235171=gcc=rev
Log:
PR c++/70690

PR c++/70528
* class.c (type_maybe_constexpr_default_constructor): New.
(type_has_constexpr_default_constructor): Revert.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/init/array41.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/class.c

[Bug target/70708] Suboptimal code generated when using _mm_set_sd (X64)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #10 from H.J. Lu  ---
_mm_set_sd is fixed for GCC 7.

[Bug target/70708] Suboptimal code generated when using _mm_set_sd (X64)

[hjl at gcc dot gnu.org]

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

--- Comment #9 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Apr 18 19:40:30 2016
New Revision: 235169

URL: https://gcc.gnu.org/viewcvs?rev=235169=gcc=rev
Log:
Optimize load double into xmm with zero_extend

"movq" should used to load double into xmm register with zero_extend:

(set (reg:V2DF 90)
 (vec_concat:V2DF (reg/v:DF 88 [ d ])
  (const_double:DF 0.0 [0x0.0p+0])))

Unlike "movsd", which only works with load from memory, "movq" works
with both memory and xmm register.

gcc/

PR target/70708
* config/i386/sse.md (sse2_loadlpd): Accept load from "xm" and
replace %vmovsd with "%vmovq".
(vec_concatv2df): Likewise.

gcc/testsuite/

PR target/70708
* gcc.target/i386/pr70708.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr70708.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/60799] access checking within injected friend functions does not happen in the context of the enclosing class

[Casey at Carter dot net]

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

--- Comment #2 from Casey Carter  ---
[basic.lookup.unqual]/9 says that name *lookup* inside friend functions defined
inline works as it does in member functions, but that doesn’t necessarily imply
that the friend function should have the same *access* as member functions
would to the names so found (excepting, of course, names of the class being
defined). 

Given [class.friend]/2:

Declaring a class to be a friend implies that the names of private and
protected members from the class granting friendship can be accessed in the
base-specifiers and member declarations of the befriended class.

and [class.mem]/1:

… Except when used to declare friends (11.3), to declare an unnamed bit-field
(9.6), or to introduce the name of a member of a base class into a derived
class (7.3.3), or when the declaration is an empty-declaration,
member-declarations declare members of the class, and each such
member-declaration shall declare at least one member name of the class. …

It's "clear" that a friend declaration is a member-declaration which – oddly
enough – does not declare a member. So the critical question is whether the
wording “and member declarations” in [class.friend]/2 means “declarations that
are syntactically member-declarations” or “declarations of members.” I'm
inclined to the second interpretation, which would imply the behavior described
in this bug report is what the standard intends.

[Bug c++/70528] [5 Regression] bogus error: constructor required before non-static data member

[jason at gcc dot gnu.org]

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

--- Comment #13 from Jason Merrill  ---
Author: jason
Date: Mon Apr 18 19:00:00 2016
New Revision: 235165

URL: https://gcc.gnu.org/viewcvs?rev=235165=gcc=rev
Log:
PR c++/70690

PR c++/70528
* class.c (type_maybe_constexpr_default_constructor): New.
(type_has_constexpr_default_constructor): Revert.

Added:
trunk/gcc/testsuite/g++.dg/init/array41.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c

[Bug c++/70690] [6/7 Regression] r235002 miscompiles tcmalloc

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Mon Apr 18 19:00:00 2016
New Revision: 235165

URL: https://gcc.gnu.org/viewcvs?rev=235165=gcc=rev
Log:
PR c++/70690

PR c++/70528
* class.c (type_maybe_constexpr_default_constructor): New.
(type_has_constexpr_default_constructor): Revert.

Added:
trunk/gcc/testsuite/g++.dg/init/array41.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c

[Bug c++/70690] [6/7 Regression] r235002 miscompiles tcmalloc

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
GCC bug: we're clearing 'cache' during its dynamic initialization even though
default-initialization should have no effect.

struct A {
  A() {}
};

struct APadded : public A {
  char pad[63];
};

int f();
int i = f();
APadded cache[50];
APadded *p = cache;

int f()
{
  cache[0].pad[0] = 42;
  return 1;
}

int main()
{
  if (cache[0].pad[0] != 42)
__builtin_abort();
}

[Bug libstdc++/41759] [C++0x] static_assert phrasing should be positive

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Mon Apr 18 18:03:50 2016
New Revision: 235160

URL: https://gcc.gnu.org/viewcvs?rev=235160=gcc=rev
Log:
PR libstdc++/41759 reword static assertions in 

PR libstdc++/41759
* include/bits/random.h: Reword static assertion messages to state
positive conditions.
* include/bits/random.tcc: Likewise.
* include/bits/uniform_int_dist.h: Likewise.
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error
patterns.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/random.h
trunk/libstdc++-v3/include/bits/random.tcc
trunk/libstdc++-v3/include/bits/uniform_int_dist.h
trunk/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc

[Bug libstdc++/41759] [C++0x] static_assert phrasing should be positive

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Fixed for gcc7

[Bug c++/70690] [6/7 Regression] r235002 miscompiles tcmalloc

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-18
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug libstdc++/70294] operator< and operator== for std::thread::id only findable by ADL

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Fixed by r235155

[Bug target/68211] Free __m128d subreg of double

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
If the upper bits of the register can contain arbitrary garbage, then keeping
it there might result in e.g. floating point exceptions being raised (it could
be even a sNAN).  Of course a different thing is if we can prove what is in
those upper bits and be sure it doesn't do any harm, or if the operations on it
later on are masked.

[Bug c/70477] -Wtautological-compare too aggressive?

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-18
 Ever confirmed|0   |1

--- Comment #4 from Marek Polacek  ---
Yep, so I'm going to confirm this, though I can't readily see any nice
solution.

[Bug target/68211] Free __m128d subreg of double

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
(In reply to Marc Glisse from comment #2)
> (In reply to H.J. Lu from comment #1)
> > When the patch for PR 70708, I got
> > 
> > vmovq   %xmm0, %xmm0
> > vsqrtsd {ru-sae}, %xmm0, %xmm0, %xmm0
> > ret
> 
> Note that the goal of both PRs is to get rid of that movq (I agree that movq
> looks like an improvement compared to what we have currently, thanks).

It depends on how the upper bits should be treated.

[Bug target/68211] Free __m128d subreg of double

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(In reply to H.J. Lu from comment #1)
> When the patch for PR 70708, I got
> 
>   vmovq   %xmm0, %xmm0
>   vsqrtsd {ru-sae}, %xmm0, %xmm0, %xmm0
>   ret

Note that the goal of both PRs is to get rid of that movq (I agree that movq
looks like an improvement compared to what we have currently, thanks).

[Bug c/70477] -Wtautological-compare too aggressive?

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
(In reply to Marek Polacek from comment #2)
> ...because neither LHS nor RHS have any location here.

Hi Marek,
does that mean you can reproduce?

[Bug c/70477] -Wtautological-compare too aggressive?

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
...because neither LHS nor RHS have any location here.

[Bug c/70371] Number added worng

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
When testing on x86_64 with 4.9 I see the output is 2468.

[Bug target/68211] Free __m128d subreg of double

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||hjl.tools at gmail dot com
 Resolution|--- |DUPLICATE

--- Comment #1 from H.J. Lu  ---
When the patch for PR 70708, I got

vmovq   %xmm0, %xmm0
vsqrtsd {ru-sae}, %xmm0, %xmm0, %xmm0
ret

*** This bug has been marked as a duplicate of bug 70708 ***

[Bug target/70708] Suboptimal code generated when using _mm_set_sd (X64)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||glisse at gcc dot gnu.org

--- Comment #8 from H.J. Lu  ---
*** Bug 68211 has been marked as a duplicate of this bug. ***

[Bug target/70708] Suboptimal code generated when using _mm_set_sd (X64)

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
Created attachment 38303
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38303=edit
A patch for _mm_set_sd

We should use "movq" instead of "movsd" for _mm_set_sd.

[Bug middle-end/70689] [6/7 Regression] ICE on valid code at -O1 in 32-bit mode on x86_64-linux-gnu in curr_insn_transform, at lra-constraints.c:3564

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Most likely that just uncovered a latent RA or machine description RA related
bug.
The 
(define_insn "*float2_i387"
  [(set (match_operand:MODEF 0 "register_operand" "=f")
(float:MODEF (match_operand:SWI48x 1 "nonimmediate_operand" "m")))]
insn allows nonimmediate_operand - thus both MEM and REG before reload, and has
just "m" constraint, so we should force that into memory.
In *.ira that is using REG, which has REG_EQUIV of (plus (frame) (const_int
-4)).
Vlad, could you please have a look at this?

[Bug c/70400] GCC compiles a return statement with an expression in a void function (illegal under C90 6.6.6.4) with -std=c90 -pedantic

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Closing as there's nothing more to do.

[Bug c/70297] [5 Regression] GCC Segfaults when using -g3

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #17 from Marek Polacek  ---
Fixed.

[Bug c/70297] [5 Regression] GCC Segfaults when using -g3

[mpolacek at gcc dot gnu.org]

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

--- Comment #16 from Marek Polacek  ---
Author: mpolacek
Date: Mon Apr 18 15:21:52 2016
New Revision: 235150

URL: https://gcc.gnu.org/viewcvs?rev=235150=gcc=rev
Log:
PR c/70297
* c-decl.c (merge_decls): Also set TYPE_ALIGN and TYPE_USER_ALIGN.

* decl.c (duplicate_decls): Also set TYPE_ALIGN and TYPE_USER_ALIGN.

* c-c++-common/pr70297.c: New test.
* g++.dg/cpp0x/typedef-redecl.C: New test.
* gcc.dg/typedef-redecl2.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/c-c++-common/pr70297.c
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/typedef-redecl.C
branches/gcc-5-branch/gcc/testsuite/gcc.dg/typedef-redecl2.c
Modified:
branches/gcc-5-branch/gcc/c/ChangeLog
branches/gcc-5-branch/gcc/c/c-decl.c
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/decl.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/70712] False positive from AddressSanitizer with use of 'alignas'

[kcc at gcc dot gnu.org]

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

--- Comment #1 from Kostya Serebryany  ---
Does not happen with clang: 
clang++ -fsanitize=address alignas.cc -std=c++11 && ./a.out 
So this is gcc-specific.

[Bug tree-optimization/58483] missing optimization opportunity for const std::vector compared to std::array

[glisse at gcc dot gnu.org]

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

--- Comment #9 from Marc Glisse  ---
  __builtin_memcpy (_30, &._82, 12);
  _31 = MEM[(const int &)_30];

looks like something we should be able to optimize, and there is indeed code in
vn_reference_lookup_3 to that effect, but the code doesn't look that nice until
very late in the optimization pipeline. At fre1, we haven't inlined the
constructor of vector yet. And we only unroll the loop after all the pre/fre
passes are done. The most relevant remaining pass is dom3, but it doesn't look
like it handles this. If I add another FRE pass next to dom3, we are left with

  _30 = operator new (12);
  __builtin_memcpy (_30, &._41, 12);
  operator delete (_30);
  D.15905 ={v} {CLOBBER};
  return 160;

Removing memcpy before operator delete seems to be a work in progress
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00780.html
And then we would finally get to the part about removing new/delete pairs.

Adding that late FRE pass seems unlikely to happen (?), so we probably need to
find some other way.

We could notice that iterating on the copy _30 is the same as iterating on the
original ._82, but that seems much harder than adding another pass after loop
unrolling...

I was a bit surprised to notice that when we see

__builtin_memcpy(b,a,42);
c=b[0];

and we do notice that this is equivalent to "c=a[0]", we only do the rewriting
if we can get to a constant value for c. I was expecting an unconditional
rewrite. But maybe that would somehow end up pessimizing the code in other
cases.

[Bug c++/70690] [6/7 Regression] r235002 miscompiles tcmalloc

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
markus@x4 Release % cat static_vars.ii
class CentralFreeList {
 public:
  CentralFreeList() {}
};

template 
class CentralFreeListPaddedTo : public CentralFreeList {
 private:
  char pad_[64 - size];
};

class CentralFreeListPadded
: public CentralFreeListPaddedTo {};

class Static {
 public:
  static CentralFreeListPadded central_cache_[50];
};

CentralFreeListPadded Static::central_cache_[50];

[Bug c++/70616] [4.9/5/6/7 Regression] ICE on valid code on x86_64-linux-gnu in build_base_path, at cp/class.c:303

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/70616] [4.9/5/6/7 Regression] ICE on valid code on x86_64-linux-gnu in build_base_path, at cp/class.c:303

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #4 from Nathan Sidwell  ---
12.4 seems to cover this case, and indicate that with an unqualified name, we
call the complete object destructor -- not the base destructor.Thus
Patrick's test case is behaving as expected.

The qualified name will call that specific base's (in-charge, complete)
destructor.   And I think will not work with the current ABI in the case of
virtual bases.  The virtual bases could be placed  differently in the complete
object to how a particlar base would place them if it were the complete object 
(that's what  the VTT param is all about).

The std does not seem to indicate such calls are undefined though.

[Bug c++/70709] [4.9/5/6/7 Regression] gcc hangs on valid C++ code on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I bet this started with r187042, at least r187035 compiles this instantly, and
r187042 hangs somewhere during finish_struct in the FE.

[Bug target/70708] Suboptimal code generated when using _mm_set_sd (X64)

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
(In reply to Petr from comment #3)
> Is there any workaround guys?
> 
> I was looking for some built-in that would allow me just cast `double` to
> `__m128d` without going through `_mm_set_sd()`, but leaving the high part
> undefined.

See PR68211.

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

[nathan at gcc dot gnu.org]

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

--- Comment #7 from Nathan Sidwell  ---
I'm such a doofus :(

[Bug target/70708] Suboptimal code generated when using _mm_set_sd (X64)

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
double MyMinV2(double a, double b) {
double undef = undef;
__m128d x;
__m128d y;
asm ("" : "=x" (x) : "0" (a));
asm ("" : "=x" (y) : "0" (b));
return _mm_cvtsd_f64(_mm_min_sd(x, y));
}

works though.

[Bug libstdc++/70472] is_copy_constructible<vector<unique_ptr>>::value is true

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Yes, I know how to do it, that doesn't mean we can do so easily in existing
types.

[Bug target/70708] Suboptimal code generated when using _mm_set_sd (X64)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-18
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
If there were not PR61810 then

double MyMinV2(double a, double b) {
double undef = undef;
__m128d x = (__m128d) { a, undef };
__m128d y = (__m128d) { b, undef };
return _mm_cvtsd_f64(_mm_min_sd(x, y));
}

would work.  Currently it does

MyMinV2:
.LFB525:
.cfi_startproc
movhpd  .LC0(%rip), %xmm0
movhpd  .LC0(%rip), %xmm1
minsd   %xmm1, %xmm0

so as if you'd use 0.0 for undef.  Might be still "better" than going
through the stack.

[Bug target/70708] Suboptimal code generated when using _mm_set_sd (X64)

[kobalicek.petr at gmail dot com]

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

--- Comment #3 from Petr  ---
Is there any workaround guys?

I was looking for some built-in that would allow me just cast `double` to
`__m128d` without going through `_mm_set_sd()`, but leaving the high part
undefined.

[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37021
Bug 37021 depends on bug 43434, which changed state.

Bug 43434 Summary: Missed vectorization: "not vectorized: data ref analysis": 
pointer incremented by a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43434

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 43434, which changed state.

Bug 43434 Summary: Missed vectorization: "not vectorized: data ref analysis": 
pointer incremented by a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43434

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/43434] Missed vectorization: "not vectorized: data ref analysis": pointer incremented by a parameter

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Richard Biener  ---
.

[Bug libstdc++/70472] is_copy_constructible<vector<unique_ptr>>::value is true

[safinaskar at mail dot ru]

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

--- Comment #3 from Askar Safin  ---
(In reply to Jonathan Wakely from comment #2)
> It's not required, and it would be impossible to require it in general. The
> problem is that std::vector does have a copy constructor, so the trait value
> is true, but instantiating that constructor produces an error when the
> value_type is not copyable.
std::is_copy_constructible> is correct. Look
at the implementation. There are _Enable_special_members and _Enable_copy_move
in . Then there is _Optional_base in
. And then there is

template
class optional
: private _Optional_base<_Tp>,
  private _Enable_copy_move<
// Copy constructor.
is_copy_constructible<_Tp>::value,
...
  >

in . Also, link I post ( http://paste.debian.net/422907/
) give simplified example how to do this.

> Types used with std::vector must be nothrow-move-constructible or
> copy-constructible. If your type has a throwing move-ctor then vector will
> try to copy it, which causes an instantiation error.
If I remove copy-ctor and copy-assignment using "= delete" in that
paste.debian.org link and leave noexcept commented, then all will build
successfully. So, it seems for me vector uses the following algorithm:

if (has_noexcept_move_ctor)
  {
use_noexcept_move_ctor ();
  }
else if (has_copy_ctor) // determined using trait. So if copy ctor is defined,
it will be used, even if it doesn't compile. If copy ctor is deleted using "=
delete", it will not be used
  {
use_copy_ctor ();
  }
else
  {
use_move_ctor ();
  }

[Bug tree-optimization/43434] Missed vectorization: "not vectorized: data ref analysis": pointer incremented by a parameter

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0

--- Comment #10 from Richard Biener  ---
Fixed on trunk.

[Bug tree-optimization/43434] Missed vectorization: "not vectorized: data ref analysis": pointer incremented by a parameter

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Mon Apr 18 13:09:53 2016
New Revision: 235147

URL: https://gcc.gnu.org/viewcvs?rev=235147=gcc=rev
Log:
2016-04-18  Richard Biener  

PR tree-optimization/43434
* tree-ssa-structalias.c (struct vls_data): New.
(visit_loadstore): Handle all pointer-based accesses.
(compute_dependence_clique): Compute a bitmap of restrict tags
assigned bases and pass it to visit_loadstore.

* gcc.dg/vect/pr43434.c: New testcase.
* c-c++-common/goacc/kernels-alias-3.c: Adjust.
* c-c++-common/goacc/kernels-alias-4.c: Likewise.
* c-c++-common/goacc/kernels-alias-5.c: Likewise.
* c-c++-common/goacc/kernels-alias-6.c: Likewise.
* c-c++-common/goacc/kernels-alias-7.c: Likewise.
* c-c++-common/goacc/kernels-alias-8.c: Likewise.
* gcc.dg/gomp/pr68640.c: Likewise.
* gfortran.dg/goacc/kernels-alias-3.f95: Likewise.
* gfortran.dg/goacc/kernels-alias-4.f95: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr43434.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/kernels-alias-3.c
trunk/gcc/testsuite/c-c++-common/goacc/kernels-alias-4.c
trunk/gcc/testsuite/c-c++-common/goacc/kernels-alias-5.c
trunk/gcc/testsuite/c-c++-common/goacc/kernels-alias-6.c
trunk/gcc/testsuite/c-c++-common/goacc/kernels-alias-7.c
trunk/gcc/testsuite/c-c++-common/goacc/kernels-alias-8.c
trunk/gcc/testsuite/gcc.dg/gomp/pr68640.c
trunk/gcc/testsuite/gfortran.dg/goacc/kernels-alias-3.f95
trunk/gcc/testsuite/gfortran.dg/goacc/kernels-alias-4.f95
trunk/gcc/tree-ssa-structalias.c

[Bug target/69148] [5 Regression] ICE (floating point exception) on s390x-linux-gnu

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

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

--- Comment #7 from Dominik Vogt  ---
(Need to backport this to 5.3 for Ubuntu.)

[Bug target/70711] GCC ARM big-endian ARMv8.1 code fails.

[mwahab at gcc dot gnu.org]

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

mwahab at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from mwahab at gcc dot gnu.org ---
Fix committed to trunk and to gcc-6.

[Bug bootstrap/70704] [6 Regressions] AIX bootstrap comparison failure

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #7 from David Edelsohn  ---
I don't know that a sort is unstable or a particular sort.  It is a hunch based
on similar failures in the past -- some output in a different order.

Why would stage2 and stage3 be built with different options, especially if
their object files are compared?

I added -frandom-seed=0 to the options, but I still see differences in
addresses, which makes comparison a little difficult.

sbitmap.c.001.tu differ, with the @ addresses.  The first difference where
one dump file contains information not present in another dump file is
sbitmap.c.003t.original.  Stage2 contains three lines of

;; Function constexpr bool std::_ImplicitlyConvertiblePair() [with _T1 =
mem_usage*; _T2 = mem_usage*; _U1 = mem_usage*; _U2 = mem_usage*] (null)
;; enabled by -tree-original


return  = 1;

while Stage3 contains only one line.  The rest of the file contains identical
statements but different labels.

sbitmap.c.006.omplower begin to show differences in funcdef_no, cgraph_uid and
symbol_order.

[Bug c++/70617] internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
(gdb) p p
$2 = (const void *) 0x1f0

is the TREE_TYPE of a CEIL_MOD_EXPR.  That looks like a bogus pointer to me.
That CEIL_MOD_EXPR is at 0x75bd0b48.  It's first allocated as TYPE_DECL
for me, then as lang-specific via cxx_make_type for a UNION_TYPE
(0x75bd2150).

We end up coming here via walking CP binding levels

 TYPE_NAME (TREE_TYPE (TREE_VALUE (TYPE_ARG_TYPES (TYPE_CANONICAL (TREE_TYPE
(FUNCTION_DECL))

and then that TYPE_NAME is CEIL_MOD_EXPR.

bool  (struct tVfpPacketDesc *, unsigned char, const struct
VFP_INGRESS_PORT_RECORD *, unsigned int, struct t_ing_zeroed *, unsigned int *,
unsigned int *, unsigned int *, const struct INTERFACE_DEST_INFO * *, union
IP_ADDRESS_AND_L2TP *, struct t_ing_p1_flags *, union IPV6_ADDRESS *, struct
t_ing_tunnel_info *, struct INGRESS_VRF_RECORD *, unsigned int, const struct
INGRESS_ILM_RECORD *, unsigned char, struct INTERFACE_DEST_INFO *, unsigned
int, short unsigned int, short unsigned int, struct DPISUB_VFP_INFO *, const
struct VFP_INGRESS_SAP_INFO *, struct t_ing_qos *, const struct DEST_INDICES *,
struct t_ing_special_ucast_l3_info *)

#5  0x0090923b in gt_ggc_mx_lang_tree_node (x_p=0x74137d20)
at ./gt-cp-tree.h:543
543   gt_ggc_m_9tree_node
((*x).generic.type_non_common.with_lang_specific.common.common.typed.type);
(gdb) p debug_generic_expr ((tree)x)
struct tVfpPacketDesc *
$43 = void
(gdb) down
#4  0x009093c9 in gt_ggc_mx_lang_tree_node (x_p=0x740f9348)
at ./gt-cp-tree.h:567
567   gt_ggc_m_9tree_node
((*x).generic.type_non_common.with_lang_specific.common.name);
(gdb) p debug_generic_expr ((tree)x)
struct  %[cl] 
$44 = void

looking at how TYPE_NAME of that record evolves.  I suspect it should have
remained the TYPE_DECL and not released to be re-allocated as lang-specific
data.

Ok, so I think this is a dup of PR70297.

[Bug c/70297] [5 Regression] GCC Segfaults when using -g3

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
(In reply to Richard Biener from comment #13)
> r207169 that is.

r230202 I mean.

[Bug c/70297] [5 Regression] GCC Segfaults when using -g3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jan.sm...@alcatel-lucent.co
   ||m

--- Comment #15 from Richard Biener  ---
*** Bug 70617 has been marked as a duplicate of this bug. ***

[Bug c++/70617] internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #12 from Richard Biener  ---
Verified by backporting the fix.

*** This bug has been marked as a duplicate of bug 70297 ***

[Bug target/70711] GCC ARM big-endian ARMv8.1 code fails.

[mwahab at gcc dot gnu.org]

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

--- Comment #4 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Mon Apr 18 12:18:10 2016
New Revision: 235133

URL: https://gcc.gnu.org/viewcvs?rev=235133=gcc=rev
Log:
PR target/70711
* config/arm/bpabi.h (BE8_LINK_SPEC): Add entries for armv8+crc,
armv8.1-a and armv8.1-a+crc.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/arm/bpabi.h

[Bug c/70297] [5 Regression] GCC Segfaults when using -g3

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
r207169 that is.

[Bug bootstrap/70706] [7 Regression] r235082 caused bootstrap failure

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||hubicka at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Jan Hubicka  ---
Fixed.

[Bug c/70297] [5 Regression] GCC Segfaults when using -g3

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
On the branch also needs

2015-11-11  Jason Merrill  

* decl.c (duplicate_decls): When combining typedefs, remove the
new type from the variants list.

[Bug target/70711] GCC ARM big-endian ARMv8.1 code fails.

[mwahab at gcc dot gnu.org]

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

--- Comment #3 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Mon Apr 18 12:11:03 2016
New Revision: 235132

URL: https://gcc.gnu.org/viewcvs?rev=235132=gcc=rev
Log:
PR target/70711
* config/arm/bpabi.h (BE8_LINK_SPEC): Add entries for armv8+crc,
armv8.1-a and armv8.1-a+crc.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/bpabi.h

[Bug c/69504] XMM register variable ICE with vector extensions

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Better testcase:

typedef int U __attribute__ ((vector_size (16)));

int
foo (int i)
{
  register U u asm ("xmm0");
  return u[i];
}

[Bug c++/70617] internal compiler error: Segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #9)
> Ok, so
> 
>   page_table table = G.lookup;
>   uintptr_t high_bits = (uintptr_t) p & ~ (uintptr_t) 0x;
>   while (table->high_bits != high_bits)
> table = table->next;
>   base = >table[0];
> 
> here we assume we never get a non-GC pointer passed to
> lookup_page_table_entry
> (which is a valid assumption).  What's p's value here?

I think that is valid assumption, so if we refer to non-GC memory from GC
memory without skip, that is where the bug is.

[Bug libstdc++/70716] Doxygen comments on std containers need updating for C++11 allocators

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> Also, assignment operators and functions often say "Old data may be lost." I
> think that's a confusing way to say that old elements are replaced, do we
> really want to talk about data loss?

Especially "may be lost" ... that doesn't tell the user anything useful. The
elements are definitely destroyed. Whether that results in data loss or not
depends on the elements, but saying "data may be lost" is too vague to be
useful. Under what conditions is it lost? I think we should just remove those
sentences.

[Bug libstdc++/70716] New: Doxygen comments on std containers need updating for C++11 allocators

[redi at gcc dot gnu.org]

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

Bug ID: 70716
   Summary: Doxygen comments on std containers need updating for
C++11 allocators
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: minor
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

We have comments on copy constructors like:

   *  The newly-created %deque uses a copy of the allocation object used
   *  by @a __x.

and copy assignment:

   *  All the elements of @a x are copied, but unlike the copy constructor,
   *  the allocator object is not copied.

These need updating, as the behaviour depends on the allocator traits now.

Also, assignment operators and functions often say "Old data may be lost." I
think that's a confusing way to say that old elements are replaced, do we
really want to talk about data loss?

[Bug tree-optimization/70715] New: SCEV failed to prove no-overflow-ness information unsigned loop IV

[amker at gcc dot gnu.org]

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

Bug ID: 70715
   Summary: SCEV failed to prove no-overflow-ness information
unsigned loop IV
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker at gcc dot gnu.org
  Target Milestone: ---

Hi, below is a case in which SCEV failed to prove no-overflow-ness of converted
unsigned type loop IV.  As a result, the address of pointer dereference isn't
recognized as SCEV.

/* { dg-do compile } */
/* { dg-options "-O3 -fdump-tree-ldist" } */

int
foo (char *p, unsigned n)
{
  while(n--)
{
  p[n]='A';
}
  return 0;
}

/* Loop can be transformed into builtin memset since [n] is SCEV.  */
/* { dg-final { scan-tree-dump "builtin_memset" "ldist" } } */

Actually, I added code supporting NE_EXPR as comparison code in loop exit
condition for PR68529.  The only problem is: in function
number_of_iterations_exit, control_iv.base is expanded by
expand_simple_operations.
Given we have already encountered problems caused by this kind of expanding, we
may want to remove it in the future.  For the moment, this can be easily fixed
by checking expanded expression in loop_exits_before_overflow.

I am testing a patch for this.

[Bug tree-optimization/70701] incomplete value numbering when memcpy-ing from array

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Apr 18 11:39:04 2016
New Revision: 235131

URL: https://gcc.gnu.org/viewcvs?rev=235131=gcc=rev
Log:
2016-04-18  Richard Biener  

PR tree-optimization/70701
* tree-ssa-sccvn.c (vn_reference_lookup_3): Resolve fully constant
references after translating through a memcpy.

* gcc.dg/tree-ssa/ssa-fre-53.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-53.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/70701] incomplete value numbering when memcpy-ing from array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.0
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Fixed on trunk.

[Bug c++/70714] New: ICE: Segmentation fault

[jan.sm...@alcatel-lucent.com]

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

Bug ID: 70714
   Summary: ICE: Segmentation fault
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com
  Target Milestone: ---

struct UINT;
typedef struct { UINT TYPES } eType;
fn1(eType) {

gcc version 5.3.1 20160411 (GCC) 
 = gcc-5-branch @ 0efe1cc72d37ff1173b52cf6bc3f17bd0ccb59f3
target = x86_64-unknown-linux-gnu

compile with : -xc++ -c testcase.best  -o /dev/null  -m32 -w

[Bug c++/70617] internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Ok, so

  page_table table = G.lookup;
  uintptr_t high_bits = (uintptr_t) p & ~ (uintptr_t) 0x;
  while (table->high_bits != high_bits)
table = table->next;
  base = >table[0];

here we assume we never get a non-GC pointer passed to lookup_page_table_entry
(which is a valid assumption).  What's p's value here?

[Bug c++/70617] internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
(In reply to Jan Smets from comment #7)
> Should I open a different issue for that?

Yes.