[Bug c/66084] New: ICE:internal compiler error: in fold_convert_loc, at fold-const.c:1974

[zhongyunde at huawei dot com]

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

Bug ID: 66084
   Summary: ICE:internal compiler error: in fold_convert_loc, at
fold-const.c:1974
   Product: gcc
   Version: 4.7.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhongyunde at huawei dot com
  Target Milestone: ---

Created attachment 35509
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35509&action=edit
a small case compile with -O2 can reproduce the issue

bug issue:
crash1.c: In function 'func_32':
crash1.c:1128:1: internal compiler error: in fold_convert_loc, at
fold-const.c:1974
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


1972: TREE_TYPE (orig), arg));
1973:  gcc_assert (TREE_CODE (orig) == VECTOR_TYPE
1974: && "tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE
(orig))");
1975:  return fold_build1_loc (loc, NOP_EXPR, type, arg);

testcase:
__attribute__ ((vector_size (16))) g_73 = {0x15FE687EL, 0x5827DF98L,
0xF8411272L, 0x235E695dL};
__attribute__ ((vector_size (16))) g_1124;

int func_1(void)
{  
__attribute__ ((vector_size (16))) l_1117 = {0x15FE688EL, 0x5827DF98L,
0xF8411272L, 0x235E695EL};
__attribute__ ((vector_size (16))) zhong = ( g_73  <= g_73);
g_1124 = (((g_73 < l_1117) == zhong) << 9);

return 0;
}

[Bug c/66084] ICE:internal compiler error: in fold_convert_loc, at fold-const.c:1974

[zhongyunde at huawei dot com]

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

--- Comment #1 from vfdff  ---
the following try can fix the issue, but need consider the reason why the
gcc_assert is added original ?

[zhongyunde@linux-root ~/6183_hcc/gcc/gcc-4.7.0/gcc]$svn diff  fold-const.c
Index: fold-const.c
===
--- fold-const.c(revision 128101)
+++ fold-const.c(working copy)
@@ -1970,8 +1970,7 @@
return fold_convert_loc (loc, type,
 fold_build1_loc (loc, REALPART_EXPR,
  TREE_TYPE (orig), arg));
-  gcc_assert (TREE_CODE (orig) == VECTOR_TYPE
- && tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE (orig)));
+  gcc_assert (TREE_CODE (orig) == VECTOR_TYPE);
   return fold_build1_loc (loc, NOP_EXPR, type, arg);

 case REAL_TYPE:

[Bug c/66084] ICE:internal compiler error: in fold_convert_loc, at fold-const.c:1974

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
The assert is correct in that it is checking that the size of what is being
converted to a vector type is the same size as the vector.

The problem is more likely before that point.

[Bug sanitizer/64839] libsanitizer shouldn't require

[harald at gigawatt dot nl]

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

--- Comment #11 from Harald van Dijk  ---
(In reply to Yury Gribov from comment #10)
> Did libsanitizer build for you both with and without xdr.h? If yes, I'll
> just go ahead and submit this.

I'm using your patch applied to 5.1.0 without issues on my system without
xdr.h. If you need someone to confirm that it doesn't break systems that do
have it, and don't get feedback from someone else soon enough, I can probably
check that in the weekend.

[Bug sanitizer/64839] libsanitizer shouldn't require

[y.gribov at samsung dot com]

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

--- Comment #12 from Yury Gribov  ---
> I'm using your patch applied to 5.1.0 without issues on my system without 
> xdr.h.

That's probably ok, thanks. I'll submit on Monday then (to be online if
problems arise).

[Bug fortran/66035] [5/6 Regression] gfortran ICE segfault

[evangelos at foutrelis dot com]

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

Evangelos Foutras  changed:

   What|Removed |Added

 CC||evangelos at foutrelis dot com

--- Comment #5 from Evangelos Foutras  ---
(In reply to vehre from comment #4)
> Created attachment 35482 [details]
> Candidate patch for latest regressions.

This patch applied on top of the 5-20150505 snapshot fixes the ICE on x86_64.

[Bug bootstrap/66085] New: [6 Regression] Revision r222934 breaks bootstrap on darwin.

[dominiq at lps dot ens.fr]

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

Bug ID: 66085
   Summary: [6 Regression] Revision r222934 breaks bootstrap on
darwin.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: aldyh at gcc dot gnu.org, howarth.at.gcc at gmail dot com,
iains at gcc dot gnu.org
  Target Milestone: ---
  Host: *-*-darwin*
Target: *-*-darwin*
 Build: *-*-darwin*

Revision r222934 breaks bootstrap on darwin (and all target for which
ASM_OUTPUT_DEF is not defined)

/opt/gcc/build_w/./prev-gcc/xg++ -B/opt/gcc/build_w/./prev-gcc/
-B/opt/gcc/gcc6w/x86_64-apple-darwin14.3.0/bin/ -nostdinc++
-B/opt/gcc/build_w/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/src/.libs
-B/opt/gcc/build_w/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/libsupc++/.libs 
-I/opt/gcc/build_w/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/include/x86_64-apple-darwin14.3.0
 -I/opt/gcc/build_w/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/include 
-I/opt/gcc/work/libstdc++-v3/libsupc++
-L/opt/gcc/build_w/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/src/.libs
-L/opt/gcc/build_w/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/libsupc++/.libs
-c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2   -gtoggle -DIN_GCC   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-fno-common  -DHAVE_CONFIG_H -I. -Icp -I../../work/gcc -I../../work/gcc/cp
-I../../work/gcc/../include -I./../intl -I../../work/gcc/../libcpp/include
-I/opt/mp-new/include  -I../../work/gcc/../libdecnumber
-I../../work/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../work/gcc/../libbacktrace -I/opt/mp-new/include  -o cp/decl2.o -MT
cp/decl2.o -MMD -MP -MF cp/.deps/decl2.TPo ../../work/gcc/cp/decl2.c
../../work/gcc/cp/decl2.c:4330:27: error: unused parameter 'decl'
[-Werror=unused-parameter]
 note_mangling_alias (tree decl, tree id2)
   ^
../../work/gcc/cp/decl2.c:4330:38: error: unused parameter 'id2'
[-Werror=unused-parameter]
 note_mangling_alias (tree decl, tree id2)
  ^
cc1plus: all warnings being treated as errors

I am testing 

--- ../_clean/gcc/cp/decl2.c2015-05-09 10:07:54.0 +0200
+++ gcc/cp/decl2.c  2015-05-09 11:29:23.0 +0200
@@ -4327,7 +4327,7 @@ generate_mangling_alias (tree decl, tree
implementation.  */

 void
-note_mangling_alias (tree decl, tree id2)
+note_mangling_alias (tree decl __attribute__((unused)), tree id2
__attribute__((unused)))
 {
 #ifdef ASM_OUTPUT_DEF
   if (at_eof)

[Bug c/66086] New: Casting a pointer to a double confuses the optimizer

[agriff at tin dot it]

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

Bug ID: 66086
   Summary: Casting a pointer to a double confuses the optimizer
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: agriff at tin dot it
  Target Milestone: ---

Created attachment 35510
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35510&action=edit
Small program showing the problem

When compiling

double doit() {
double *ptr = (double *)malloc(sizeof(double));
ptr[0] = 3.14;
return (double)((uintptr_t) ptr);
}

the generated code doesn't initialize the memory returned by `malloc` when the
optimization level is -O2.

This happens both in 64-bit mode and in 32-bit mode (where the size of
uintptr_t is 4 bytes and all theoretic values can be represented exactly in a
double); note that on x86-64 the used values are 48-bit only and a double
provides enough accuracy to store them correctly.

Attached is a full program showing the issue (compiled with -O0 the result is
correct, compiled with -O2 the result is wrong).

[Bug middle-end/66084] ICE:internal compiler error: in fold_convert_loc, at fold-const.c:1974

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.8.4
 Resolution|--- |FIXED

--- Comment #3 from Marc Glisse  ---
Again, 4.7 is not supported anymore. Please test with a more recent version.

[Bug bootstrap/66085] [6 Regression] Revision r222934 breaks bootstrap on darwin.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-09
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Bootstrap completed with the patch in comment 0.

[Bug rtl-optimization/66087] New: Invalid narrowing of MEM with containing POST_INC

[sch...@linux-m68k.org]

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

Bug ID: 66087
   Summary: Invalid narrowing of MEM with containing POST_INC
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: law at redhat dot com
  Target Milestone: ---
Target: m68k-*-*

Created attachment 35511
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35511&action=edit
Testcase extracted from icu

With the attached test case compiled with -O2, reload is transforming

(insn 21 20 22 4 (set (reg:SI 47 [ D.1538 ])
(plus:SI (subreg:SI (mem:DI (post_inc:SI (reg:SI 41 [ ivtmp.13 ])) [1
MEM[base: _17, offset: 0B]+0 S8 A16]) 0)
(const_int -1 [0x]))) autoinc.c:4 133
{*addsi3_internal}
 (expr_list:REG_INC (reg:SI 41 [ ivtmp.13 ])
(nil)))

into

(insn 40 20 21 4 (set (reg:SI 1 %d1 [orig:47 D.1538 ] [47])
(mem:SI (post_inc:SI (reg:SI 8 %a0 [orig:41 ivtmp.13 ] [41])) [1
MEM[base: _17, offset: 0B]+0 S4 A16])) autoinc.c:4 37 {*movsi_m68k}
 (expr_list:REG_INC (reg:SI 8 %a0 [orig:41 ivtmp.13 ] [41])
(nil)))

without compensating for the fact that POST_INC depends on the mode of the
containing MEM wrt to the amount to increment.

The bug was introduced by the autoinc changes in r150588, but it probably just
exposed a latent bug in reload.

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #7 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #6)
> To be followed up.

Just built with gcc-4.9_4.9.2-7 which previously successfully built
gcc-4.9_4.9.2-10 [1] but fails to build gcc-4.9_4.9.2-16 [2].

Any suggestions? I am testing with "nostrap" now and will use this compiler to
build the package again. Otherwise I am currently out of ideas.

Adrian

> [1] 
> http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9&arch=sh4&ver=4.9.2-10&stamp=1421945369
> [2] 
> http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9&arch=sh4&ver=4.9.2-16&stamp=1431119505

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[kugan at gcc dot gnu.org]

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

kugan at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kugan at gcc dot gnu.org

--- Comment #5 from kugan at gcc dot gnu.org ---
I ran into this today when I created a cross compiler for aarch64-linux-gnu. It
also happens with arm. As Richard Biener suggested, -pedantic helps. How about
this:

diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 3fcb7c2..d5d82fd 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -10702,7 +10702,7 @@ build_binary_op (location_t location, enum tree_code
code,
{
  /* Don't reject a left shift of a negative value in a context
 where a constant expression is needed in C90.  */
- if (flag_isoc99)
+ if (flag_isoc99 && pedantic)
int_const = false;
  if (c_inhibit_evaluation_warnings == 0)
warning_at (location, OPT_Wshift_negative_value,

[Bug c/66088] New: -Wunused-but-set-variable does not regard static variable access in local scope

[vshebordaev at mail dot ru]

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

Bug ID: 66088
   Summary: -Wunused-but-set-variable does not regard static
variable access in local scope
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vshebordaev at mail dot ru
  Target Milestone: ---

As of gcc 4.9.2, I get faulty -Wunused-but-set-variable warning (and broken
build with -Wall) in this case

 1 struct test {
 2 int t;
 3 };
 4
 5 int main(int argc, const char *argv[])
 6 {
 7 static struct test t = { 0 };
 8 struct test v = { 1 };
 9
10 t = v;
11
12 return 0;
13 }

The warning disappears when t is referenced by its address, i.e. when line 10
changed to

10 *(&t) = v;

which is considered as a usage but looks ridiculously.

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[mikael at gcc dot gnu.org]

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

--- Comment #32 from Mikael Morin  ---
Author: mikael
Date: Sat May  9 13:36:14 2015
New Revision: 222968

URL: https://gcc.gnu.org/viewcvs?rev=222968&root=gcc&view=rev
Log:
Fix fortran/65894 elemental procedures wrong-code

gcc/fortran/
2015-05-09  Mikael Morin  

PR fortran/65894
* trans-array.h (gfc_scalar_elemental_arg_saved_as_reference):
New prototype.
* trans-array.c (gfc_scalar_elemental_arg_saved_as_reference):
New function.
(gfc_add_loop_ss_code): Use gfc_scalar_elemental_arg_saved_as_reference
as conditional.
(gfc_walk_elemental_function_args): Set the dummy_arg field.
* trans.h (gfc_ss_info): New subfield dummy_arg.
* trans-expr.c (gfc_conv_procedure_call): Revert the change
of revision 222361.
(gfc_conv_expr): Use gfc_scalar_elemental_arg_saved_as_reference
as conditional.

gcc/testsuite/
2015-05-09  Andre Vehreschild  

PR fortran/65894
* gfortran.dg/elemental_subroutine_11.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_11.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-array.h
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/66085] [6 Regression] Revision r222934 breaks bootstrap on darwin.

[aldyh at gcc dot gnu.org]

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

--- Comment #2 from Aldy Hernandez  ---
Author: aldyh
Date: Sat May  9 13:50:21 2015
New Revision: 222969

URL: https://gcc.gnu.org/viewcvs?rev=222969&root=gcc&view=rev
Log:
PR bootstrap/66085
* decl2.c (note_mangling_alias): Declare arguments as unused.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c

[Bug bootstrap/66085] [6 Regression] Revision r222934 breaks bootstrap on darwin.

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #3 from Aldy Hernandez  ---
Fixed on mainline.

[Bug rtl-optimization/66087] Invalid narrowing of MEM with containing POST_INC

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Good old allowing subreg of a mem as register operand before reload.

[Bug tree-optimization/64454] optimize (x%5)%5

[glisse at gcc dot gnu.org]

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

--- Comment #10 from Marc Glisse  ---
Author: glisse
Date: Sat May  9 15:40:05 2015
New Revision: 222970

URL: https://gcc.gnu.org/viewcvs?rev=222970&root=gcc&view=rev
Log:
2015-05-09  Marc Glisse  

PR tree-optimization/64454
gcc/
* tree-vrp.c (extract_range_from_binary_expr_1) :
Rewrite.
gcc/testsuite/
* gcc.dg/tree-ssa/vrp97.c: New file.
* gcc.dg/vect/slp-perm-7.c: Update.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp97.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/slp-perm-7.c
trunk/gcc/tree-vrp.c

[Bug fortran/66089] New: elemental dependency mishandling when derived types are involved

[mikael at gcc dot gnu.org]

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

Bug ID: 66089
   Summary: elemental dependency mishandling when derived types
are involved
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikael at gcc dot gnu.org
  Target Milestone: ---

This is a followup to pr65894.
We don't handle correctly the dependencies when elemental procedures and
derived types are involved.
Test:

  type :: t
integer :: c
  end type t

  type(t), dimension(5) :: a, b, c

  a = t(1)
  b = t(7)
  c = t(13)
  c = plus(c(1), b)
  print *, c
  if (any(c%c /= 20)) call abort

contains

  elemental function plus(lhs, rhs)
type(t), intent(in) :: lhs, rhs
type(t) :: plus
plus%c = lhs%c + rhs%c
  end function plus

end

[Bug fortran/66089] elemental dependency mishandling when derived types are involved

[mikael at gcc dot gnu.org]

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

--- Comment #1 from Mikael Morin  ---
Draft patch:

Index: trans-array.c
===
--- trans-array.c   (révision 222968)
+++ trans-array.c   (copie de travail)
@@ -2449,13 +2449,6 @@ gfc_scalar_elemental_arg_saved_as_reference (gfc_s
   && ss_info->expr->ts.type == BT_CLASS)
 return true;

-  /* If the expression is a data reference of aggregate type,
- avoid a copy by saving a reference to the content.  */
-  if (ss_info->expr->expr_type == EXPR_VARIABLE
-  && (ss_info->expr->ts.type == BT_DERIVED
- || ss_info->expr->ts.type == BT_CLASS))
-return true;
-
   /* Otherwise the expression is evaluated to a temporary variable before the
  scalarization loop.  */
   return false;

[Bug debug/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin

[iains at gcc dot gnu.org]

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

--- Comment #14 from Iain Sandoe  ---
(In reply to Joel Brobecker from comment #13)
> Sorry guys, but dsymutil is not working very well. I have a couple of
> examples where, either dsymutil is excluding some DIEs from the DWARF image,
> or where dsymutil actually segfaults. 

I think we all see this to some degree-or-other...

>There is also the fact that dsymutil
> doesn't know about recent DWARF enhancements, and doesn't work well when
> compiling code with -gno-strict-dwarf.

I think that's pretty much "not supported" with dsymutil; even the LLVM project
makes concessions to the need to support older DWARF output for OS X…  
I'd also wonder if it's 100% safe w.r.t ld64, and other items from the
DWARFutils package (although objdump & friends are pretty good for mach-o, they
are not a standard build for most folks).

however

>Since we do not control dsymutil and its quality level (or lack thereof), 

Yeah .. 'tis the one thing we can't fix at present...

… (let's cross fingers for llvm-dsymutil maturing quickly).

> GDB should be able to use the debug info from the object files without
> requiring the use of dsymutil. 

>I suggest the best course of action is
> trying to figure out why GDB doesn't pick the debugging info up from the .o
> files, and then fix that.

That's a good idea.
My experience is that it's quite variable, sometimes using GDB on the *.o works
better … sometimes the .dSYM works better.

> In the meantime, I suggest we revert this change, or else make it optional
> at the very least.

case 1. gcc  foo.o bar.o baz.o … <= should *not* invoke dsymutil - should work
"as expected" with the .o files.

case 2. gcc foo.o bar.o bad.c <= should invoke dsymutil.

In this case, you don't have baz.o, since it's a temporary file - so you can't
use it for debug (hence the secondary purpose of dsymutil).  You'd need
'save-temps' on the c/l to ensure this...

So we we could try amending the link spec to suppress the call of dsymutil if
"save-temps" is on the c/l?

I'm kinda in favour of this, since we *don't* have control over dsymutil and it
won't be fixed for darwin < bleeding edge even if a radar is filed - I assume
radar(s) have been filed for the issues?

> PS: Our experiments are on Darwin 13.4 and 14.3.

It's much the same across the board Darwin9+

[Bug libstdc++/58931] condition_variable::wait_until overflowed by large time_point

[aaron at aarongraham dot com]

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

Aaron Graham  changed:

   What|Removed |Added

 CC||aaron at aarongraham dot com

--- Comment #3 from Aaron Graham  ---
This is still a problem in current gcc trunk.

The bug is in the condition_variable::wait_until clock conversion. It doesn't
check for overflow in that math. Since the steady_clock and system_clock epochs
can be very different, it's likely to overflow with values much less than
max().

template
  cv_status
  wait_until(unique_lock& __lock,
 const chrono::time_point<_Clock, _Duration>& __atime)
  {
// DR 887 - Sync unknown clock to known clock.
const typename _Clock::time_point __c_entry = _Clock::now();
const __clock_t::time_point __s_entry = __clock_t::now();
const auto __delta = __atime - __c_entry;
const auto __s_atime = __s_entry + __delta;

return __wait_until_impl(__lock, __s_atime);
  }

I modified my version of gcc to use steady_clock as condition_variable's "known
clock" (__clock_t). This is more correct according to the C++ standard and most
importantly it makes condition_variable resilient to clock changes when used in
conjunction with steady_clock. Because of this, in my case, it works fine with
steady_clock::time_point::max(), but fails with
system_clock::time_point::max().

Because I made that change and since I don't do timed waits on system_clock
(which is unsafe), the overflow hasn't been a problem for me and I haven't
fixed it.

[Bug libstdc++/58931] condition_variable::wait_until overflowed by large time_point

[aaron at aarongraham dot com]

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

--- Comment #4 from Aaron Graham  ---
See bug 41861 for discussion of steady_clock wrt condition_variable.

[Bug debug/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin

[iains at gcc dot gnu.org]

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

--- Comment #15 from Iain Sandoe  ---
Created attachment 35512
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35512&action=edit
Disable dsymutil when -save-temps is on the command line.

… something like this…

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[juergen.reuter at desy dot de]

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

--- Comment #33 from Jürgen Reuter  ---
Great, with that comment everything in our code works again, thanks, Mikael.
So, what about Dominique's comment with the fix for PR 58586 and that this
breaks our code again. Shall I (try to) investigate this?

[Bug c/66088] -Wunused-but-set-variable does not regard static variable access in local scope

[vshebordaev at mail dot ru]

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

--- Comment #1 from Vladimir  ---
Well, the build is broken when -Werror option is specified just like it is
expected, I've overlooked a typo.

[Bug c/66088] -Wunused-but-set-variable does not regard static variable access in local scope

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Is gcc warning about t being set but unused? If so then the warning is correct
"t =" is just setting t and the variable is otherwise unused and can be removed
as it has no side effects. 

*(&t) disables the warning as &t is using t for its address.

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

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

--- Comment #8 from Kazumoto Kojima  ---
(In reply to John Paul Adrian Glaubitz from comment #7)
> Just built with gcc-4.9_4.9.2-7 which previously successfully built
> gcc-4.9_4.9.2-10 [1] but fails to build gcc-4.9_4.9.2-16 [2].

It seems that latest 4.9 and 5.0 have some wrong code problem on
this target.  We should pin point it.  My sh4 board has only 64MB
RAM and it takes a week to get stage2 compiler for gcc-5.  A reduced
testcase for the cross compiler is deadly needed.
It looks there are not so many target changes between
  http://http.debian.net/debian/pool/main/g/gcc-4.9/gcc-4.9_4.9.2-10.diff.gz
and
  http://http.debian.net/debian/pool/main/g/gcc-4.9/gcc-4.9_4.9.2-16.diff.gz

2015-03-26  Oleg Endo  

Backport from mainline
2015-03-26  Oleg Endo  

* config/sh/t-sh (MULTILIB_EXCEPTIONS): Handle default endian.

2015-03-10  Oleg Endo  

PR target/53988
* config/sh/sh.md (*tst_t_zero): Remove insns.

2015-03-03  Kaz Kojima  

PR target/65249
* config/sh/sh.md (symGOT_load): Use R0 reg for operands[2] when
called for __stack_chk_guard symbol.

2015-02-25  Kaz Kojima  

Backport from mainline
2015-02-23  Kaz Kojima  

PR target/65153
* config/sh/sh.md (movsicc_true+3): Remove peephole.
* config/sh/sh-protos.h (replace_n_hard_rtx): Don't declare.
* config/sh/sh.c (replace_n_hard_rtx): Remove.

2015-02-23  Oleg Endo  

Backport from mainline
2015-02-23  Oleg Endo  

PR target/65163
* config/sh/sh.md (swapbsi2, related peephole2): Use const_int -65536
instead of const_int 4294901760.

2015-01-08  Christian Bruel  

PR target/64507
* config/sh/sh-mem.cc (sh_expand_cmpnstr): Check 0 length.

of which revision number in FSF gcc svn are
r221686, r221305, r221166, r220957, r220917, r219258
respectively.
You can revert the above changes to see what happens.  Looks safe
changes to me, but some changes could reveal hidden problems.
If the issue remains even if all those changes are reverted,
there will be no easy way to narrow down.

[Bug c/66088] -Wunused-but-set-variable does not regard static variable access in local scope

[vshebordaev at mail dot ru]

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

--- Comment #3 from Vladimir  ---
Well, I doubt that modification of the static variable has no side effects.

[Bug c/66090] New: Wrong loop code generation with -O2 on ARM

[christian.procha...@genode-labs.com]

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

Bug ID: 66090
   Summary: Wrong loop code generation with -O2 on ARM
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christian.procha...@genode-labs.com
  Target Milestone: ---

test.c:

void func()
{
unsigned int i;

unsigned int *ptr = (unsigned int*)0xf000;

for (i = 0; i < 1024; i++)
*(ptr++) = 0;
}

Compiled with GCC 4.9.2 from the Xubuntu 15.04 repository:

arm-linux-gnueabihf-gcc-4.9 -marm -c -O2 test.c

Generated code:

 :
func():
   0:   e3a03a0fmov r3, #61440  ; 0xf000
   4:   e3a02000mov r2, #0
   8:   e34f3fffmovtr3, #65535  ; 0x
   c:   e4832004str r2, [r3], #4
  10:   eafdb   c 

There is no check of the loop exit condition.

When compiling with -O1, it is there:

 :
func():
   0:   e3a03a0fmov r3, #61440  ; 0xf000
   4:   e34f3fffmovtr3, #65535  ; 0x
   8:   e3a02000mov r2, #0
   c:   e4832004str r2, [r3], #4
  10:   e353cmp r3, #0
  14:   1afcbne c 
  18:   e12fff1ebx  lr

The problem does not occur with GCC 4.8.4.

[Bug c++/66091] New: [c++-concepts] Overloading of member operators based on constraints rejected; regression from r211591

[tom at honermann dot net]

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

Bug ID: 66091
   Summary: [c++-concepts] Overloading of member operators based
on constraints rejected; regression from r211591
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
  Target Milestone: ---

The following test case was accepted by r211591 of the c++-concepts branch, but
is rejected by r222769.  My interpretation of N4377 is that this test case
should be accepted.

$ cat t.cpp
template
concept bool C1() {
return requires() { typename T::type1; };
}
template
concept bool C2() {
return C1()
&& requires() { typename T::type2; };
}
template
struct S {
S& operator++()
{ return *this; }
S& operator++()
requires C2()
{ return *this; }
};

# Compiling with r222769:
$ g++ -c -std=c++1z t.cpp 
t.cpp:14:8: error: ‘S& S::operator++()’ cannot be overloaded
 S& operator++()
^
t.cpp:12:8: error: with ‘S& S::operator++()’
 S& operator++()
^

[Bug c++/66092] New: Concept can't check variadic template arguments

[yingpo.liao at gmail dot com]

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

Bug ID: 66092
   Summary: Concept can't check variadic template arguments
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yingpo.liao at gmail dot com
  Target Milestone: ---

Concept can't check variadic template arguments (r222891).

The example code shows an implementation of a concept to check if all types are
the same via variadic template arguments. It will be okay if we directly print
out the results, but will fail (internal compiler error) if we apply the
concept to real cases, i.e., a foo() function. 

$ svn info

Path: .
Working Copy Root Path:
/Users/liao/Downloads/gcc-branch-c++-concepts/c++-concepts
URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts
Relative URL: ^/branches/c++-concepts
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 222891
Node Kind: directory
Schedule: normal
Last Changed Author: asutton
Last Changed Rev: 222891
Last Changed Date: 2015-05-07 15:25:15 -0500 (Thu, 07 May 2015)

$ cat test.cpp

#include 
#include 

template 
requires (sizeof...(Args) == 0)
  constexpr decltype(auto) check()
  {
return std::integral_constant();
  }

template 
requires (sizeof...(Args) > 0)
  constexpr decltype(auto) check()
  {
return std::integral_constant())::value>();
  }

template 
  concept bool Same()
  {
return decltype(check())::value;
  }

template 
requires Same()
  void foo( Args... args ) {}

int main()
{
  // OK: print "true"
  std::cout << std::boolalpha << Same() << std::endl;
  // ERROR
  foo(1, 2, 3);
  return 0;
}

$ g++ -std=c++1z test.cpp  -o test

test.cpp:22:41: internal compiler error: tree check: accessed elt 2 of tree_vec
with 1 elts in tsubst, at cp/pt.c:12556
 return decltype(check())::value;
 ^

test.cpp:22:41: internal compiler error: Abort trap: 6
g++: internal compiler error: Abort trap: 6 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c/66086] Casting a pointer to an uintptr_t and later to a double confuses the optimizer

[agriff at tin dot it]

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

--- Comment #1 from Andrea Griffini  ---
Not sure if this helps but I found that when compiling -m32 -O -fno-tree-dce
the output of the program becomes correct but the generated code is not.

More specifically the non-inlined version of `doit` contains no initialization
of the allocated memory, but the inlined call in `main` does the allocation and
does NOT initialize the memory but loads the expected result 3.14 directly in
the stack before calling printf.

Without -fno-tree-dce the inilined version simply reads the memory instead
(that has not been initialized) and produces the wrong output.

[Bug c/66086] Casting a pointer to an uintptr_t and later to a double confuses the optimizer

[agriff at tin dot it]

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

--- Comment #2 from Andrea Griffini  ---
(In reply to Andrea Griffini from comment #1)
> Not sure if this helps but I found that when compiling -m32 -O -fno-tree-dce
> the output of the program becomes correct but the generated code is not.
> 
> More specifically the non-inlined version of `doit` contains no
> initialization of the allocated memory, but the inlined call in `main` does
> the allocation and does NOT initialize the memory but loads the expected
> result 3.14 directly in the stack before calling printf.
> 
> Without -fno-tree-dce the inilined version simply reads the memory instead
> (that has not been initialized) and produces the wrong output.

Sorry... this happens at -O2, not at -O