[Bug middle-end/69715] g++ crash dump on building SoftFloatWrapper.cpp

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-08
 CC||trippels at gcc dot gnu.org
  Component|c++ |middle-end
 Ever confirmed|0   |1
   Severity|blocker |normal

--- Comment #3 from Markus Trippelsdorf  ---
All supported gcc versions ICE.

markus@x4 tmp % cat cra.ii
namespace streflop {
template  struct A { operator long double() const; };
namespace SoftFloat {
typedef struct {
  long long low;
  int high;
} floatx80;
floatx80 fn1(int);
}
using namespace SoftFloat;
template <> A<32>::operator long double() const {
  long double a;
  *reinterpret_cast() = fn1(0);
  return a;
}
}

markus@x4 tmp % /var/tmp/gcc_test/usr/local/bin/g++ -c -m32 -O3 cra.ii

cra.ii: In member function ‘streflop::A< >::operator long double()
const [with int  = 32]’:
cra.ii:13:45: internal compiler error: in store_bit_field_1, at expmed.c:839
   *reinterpret_cast() = fn1(0);
 ^
0x9d7d8e store_bit_field_1
../../gcc/gcc/expmed.c:839
0x9d7e8c store_bit_field(rtx_def*, unsigned long, unsigned long, unsigned long,
unsigned long, machine_mode, rtx_def*, bool)
../../gcc/gcc/expmed.c:
0x9f906c store_field
../../gcc/gcc/expr.c:6769
0x9f4b41 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/gcc/expr.c:5021
0x8e7a2a expand_call_stmt
../../gcc/gcc/cfgexpand.c:2646
0x8e7a2a expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3536
0x8e7a2a expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3702
0x8eaa96 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5708
0x8ef8d6 execute
../../gcc/gcc/cfgexpand.c:6323

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-07
 Ever confirmed|0   |1

--- Comment #9 from Oleg Endo  ---
(In reply to Alexander Monakov from comment #8)
> Hm, if GCC won't accept clobbering a hardreg that overlaps the output
> hardregs holding the return value (operands[0]), then it's less obvious.

Yes, I was afraid of that.  (See below).
I've also tried using LRA without the patch, but the problem persists.

> r0
> is always suitable then and does not require mentioning in the RTL template,

That might be true, but that could be a source of future silent wrong-code
bugs.


> but constrains scheduling as Rich said.

I'm not sure whether this will have any effects on scheduling.  Maybe just some
few cases where r0 could be used to calculate something else, or access memory
via index-register address mode.

Anyway, I've tried the following 2-liner:

Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 233200)
+++ gcc/config/sh/sh.md (working copy)
@@ -10481,7 +10481,7 @@
(call (mem:SI (match_operand:SI 1 "symbol_ref_operand" ""))
  (match_operand 2 "" "")))
(use (reg:SI FPSCR_MODES_REG))
-   (clobber (match_scratch:SI 3 "="))
+   (clobber (reg:SI R1_REG))
(return)]
   "TARGET_SH2 && !TARGET_FDPIC"
   "#"
@@ -10491,6 +10491,8 @@
   rtx lab = PATTERN (gen_call_site ());
   rtx call_insn;

+  operands[3] = gen_rtx_REG (SImode, R1_REG);
+
   sh_expand_sym_label2reg (operands[3], operands[1], lab, true);
   call_insn = emit_call_insn (gen_sibcall_valuei_pcrel (operands[0],
operands[3],

... and it gets the job done for the test case in comment #1.

The patch could be a quick fix for the problem (with some comments added),
although clearly it's just wallpapering.  It will also break if hard-regs are
reserved via compiler options, but luckily that's not a common use case.

When compiling the test case without -fPIC the "sibcall_valuei" pattern is used
and doesn't show any problems.  So I guess the pcrel patterns like
"sibcall_value_pcrel" should be changed to get register allocation working as
for non-pcrel calls and do the pcrel stuff in a different way.  But I guess
this will be some bigger rework patch.

[Bug target/69713] Invalid code of optimization in SH

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Target|sh-unknown-linux|sh*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-07
 CC||kkojima at gcc dot gnu.org,
   ||olegendo at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Oleg Endo  ---
Thanks for reporting.

The upper bound check for the table lookup is missing.  I will try to check if
this is a SH specific issue.

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

[amonakov at gcc dot gnu.org]

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

--- Comment #10 from Alexander Monakov  ---
If always using r0 is not an issue, I think it's possible to just use
operands[0] (casting it to the right size with subreg:SI, if needed) to avoid
using a potentially-reserved hardreg.  This would allow to remove the clobber
from the pattern altogether.

(I also imagine that sh.md could benefit from a rework of call patterns, I
don't understand why it's done this way with postreload splits)

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

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #15 from Thomas Koenig  ---
(In reply to Mikael Morin from comment #14)

> I'm not sure this is actually correct; should we consider c(1) optional if c
> is optional?

We don't currently do this for the PRESENT intrinsic:

ig25@linux-fd1f:/tmp> cat opt.f90
module foo
contains
  subroutine opt(a)
integer, intent(in), dimension(3) :: a
if (present(a(1))) print *,a
  end subroutine opt
end module foo

program main
  use foo
  call opt
end program main
ig25@linux-fd1f:/tmp> gfortran opt.f90
opt.f90:5:16:

 if (present(a(1))) print *,a
1
Error: »a« argument of »present« intrinsic at (1) must be of an OPTIONAL dummy
variable
opt.f90:10:6:

   use foo
  1
Fatal Error: Can't open module file »foo.mod« for reading at (1): Datei oder
Verzeichnis nicht gefunden
Kompilierung beendet.

[Bug inline-asm/68095] "cc" clobber with Flag Output Operands

[gccbugzilla at limegreensocks dot com]

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

--- Comment #6 from David  ---
Created attachment 37621
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37621=edit
Patch for missing clobber validations

I have created a patch (attached) that does the check I am describing.  And
while I was at it, I added a few other validations for clobber conditions.  The
patch includes testcases, but in short, these lines (which currently produce no
messages) would all give errors:

  __asm__ volatile("":::"eax","eax");
  __asm__ volatile("":::"memory", "memory");
  __asm__ volatile("":::"cc", "cc");
  __asm__ volatile("":"=@ccc"(c)::"cc");

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

[amonakov at gcc dot gnu.org]

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

--- Comment #12 from Alexander Monakov  ---
> Do you have anything in particular in mind?

I mostly wonder why does sh.md change RTL representation of a sibcall that way,
instead of simply generating the required relative address load upfront, during
RTL expand. This way, RTL better matches final instruction stream, register
allocation should be more natural, and the load of the relative address is
subject to all RTL optimizations (so if you call a function in a loop, you can
load the relative address once, out of the loop).

[Bug target/69713] Invalid code of optimization in SH

[olegendo at gcc dot gnu.org]

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

--- Comment #2 from Oleg Endo  ---
Looks like an SH specific issue.  The bounds check is there, but it's in the
wrong place:

_lookup_user_key:
mov.l   r8,@-r15
mov #0,r3
mov.l   r9,@-r15
mov #15,r1
mov.l   r10,@-r15
mov.l   r11,@-r15
mov r5,r11
mov.l   r12,@-r15
mov r4,r12
mov.l   r13,@-r15
mov.l   r14,@-r15
sts.l   pr,@-r15
add #-76,r15
mov r15,r2
mov.l   r6,@(4,r15)
add #16,r2
.L18:
add #-1,r1
mov.l   r3,@r2
tst r1,r1
add #4,r2
bf  .L18

mov.l   .L106,r1
mov r12,r10
add #8,r10  <<< offset table index
mova.L23,r0 <<< table base addr
mov.l   r1,@(32,r15)
mov r10,r2  <<<
mov #1,r1
mov.l   r1,@(48,r15)
add r2,r2   <<< table offset * 2
mov.w   @(r0,r2),r1 <<< table access without bounds check
add r0,r1
mov r11,r0
and #1,r0
mov.l   .L107,r9
mov.l   .L108,r8
mov.l   r1,@(8,r15)
mov.l   r0,@(12,r15)
.L20:
.L60:
! 421 "sh_tmp.cpp" 1
stc r7_bank, r1
! 0 "" 2
mov.l   @r1,r1
jsr @r9
mov.l   @r1,r14
mov.w   .L110,r4
jsr @r8
mov r0,r13
mov.l   @r14,r2
mov r13,r4
add #1,r2
jsr @r8
mov.l   r2,@r14
mov #7,r2   <<< switch case upper bound
mov.l   r14,@(28,r15)
cmp/hi  r2,r10  <<< bounds check
bf  .L101   <<< 

As far as I can see it, the problem is in the expansion of 

  emit_insn (gen_casesi_0 (operands[0], operands[1], operands[2], operands[4],
   reg));
  emit_insn (gen_casesi_worker_0 (reg2, reg, operands[3]));

The casesi_0 pattern is supposed to emit the bounds checking code, followed by
the table memory access expanded by casesi_worker_0 which is then split into
casesi_worker_1.  However, something seems off and the code emitted by
casesi_worker_1 is hoisted above the code emitted by casesi_0.

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

[olegendo at gcc dot gnu.org]

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

--- Comment #11 from Oleg Endo  ---
(In reply to Alexander Monakov from comment #10)
> If always using r0 is not an issue, I think it's possible to just use
> operands[0] (casting it to the right size with subreg:SI, if needed) to
> avoid using a potentially-reserved hardreg.  This would allow to remove the
> clobber from the pattern altogether.

I'm not sure it's a good idea.  All the call patterns are written with "=rf"
for operand[0], i.e. it could be a floating point register.  Under the current
ABI all function calls always clobber GP regs r0..r3 though.  To avoid more
potential r0-spill-failure cases, I'd rather put the explicit r1 clobber.

> (I also imagine that sh.md could benefit from a rework of call patterns, I
> don't understand why it's done this way with postreload splits)

Do you have anything in particular in mind?  I guess some of the things are
tied to the way constant/literal pools work on SH.

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

[bastian.beisc...@rwth-aachen.de]

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

--- Comment #3 from bastian.beisc...@rwth-aachen.de ---
Jonathan, maybe so but it should be mentioned on the page nevertheless, right?

My issue is that we are using (as an example):

#if (defined(__GLIBCXX__) && __GLIBCXX__ > 20150626) ||
(defined(_LIBCPP_VERSION) && _LIBCPP_VERSION >= 1101)
static_assert(std::is_trivially_constructible::value, "MyClass should
be trivially constructible.");
#endif

since "std_is_trivially_constructible" exists only in libstdc++ shipped with
GCC 5.1.0+, but not in libstdc++ shipped with GCC 4.9.3, for example.

If i understand your comment correctly you are saying that, if GCC 4.9.4 were
released, it would include a version of libstdc++ with __GLIBCXX__ > today, so
it would pass the above check, but still there would't be any
"std_is_trivially_constructible".

But how else can I do the check then?! Using __GNUC__ / __GNUC_MINOR__ is not
going to work because we have people using other compilers (clang, Intel
compiler) which use libstdc++ shipped with GCC but do not define __GNUC__ /
__GNUC_MINOR__.

[Bug target/69713] Invalid code of optimization in SH

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo  ---
It seems that one of the loop optimizations pulls the casesi_0 and
casesi_worker_0 insns apart and then things go wrong from there on.  Compiling
the test case with -fno-move-loop-invariants results in the correct code.

I guess the actual problem is that what the SH backend expands results in some
unexpected/unhandled CFG for the case insn.

One option could be to merge the casesi_0 and casesi_worker_0 / casesi_worker_1
patterns somehow into one pattern, so that the block remains in one place.

Another option I can think of would be feeding the bounds check comparison
result from the casesi_0 insns into casesi_worker_0/casesi_worker_1 and add a
conditional branch around the table access.

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

[olegendo at gcc dot gnu.org]

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

--- Comment #13 from Oleg Endo  ---
(In reply to Alexander Monakov from comment #12)
> 
> I mostly wonder why does sh.md change RTL representation of a sibcall that
> way, instead of simply generating the required relative address load
> upfront, during RTL expand. This way, RTL better matches final instruction
> stream, register allocation should be more natural, and the load of the
> relative address is subject to all RTL optimizations (so if you call a
> function in a loop, you can load the relative address once, out of the loop).

Good question indeed.  Kaz, maybe you remember anything?

[Bug c++/66786] [5/6 Regression] ICE: Segmentation fault

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Slightly more simplified test case:

  template  auto list = [](T... xs) { [=](auto f) { f(xs...); };
};
  int main() { list; }


The problem ultimately seems to lie in template_class_depth, which returns the
number of enclosing templates in which the given type or decl is embedded.


In particular, given the RECORD_TYPE that corresponds to the outermost lambda
in the above test case, template_class_depth returns 0 instead of 1 since the
TYPE_CONTEXT of this RECORD_TYPE is the file's TRANSLATION_UNIT_DECL and not
the VAR_DECL so template_class_depth never sees it.

That the TYPE_CONTEXT doesn't point to the enclosing VAR_DECL doesn't seem like
a bug because according to the documentation, the TYPE_CONTEXT (and
DECL_CONTEXT) of a tree is never expected to be a VAR_DECL.  It can be a
FUNCTION_DECL however, which explains why the following test case, which just
replaces the enclosing variable template with a function template, compiles
successfully (the TYPE_CONTEXT points to the enclosing FUNCTION_DECL and so
template_class_depth appropriately returns 1):

  template 
  auto
  list ()
  {
return [](T... xs) { [=](auto f) { f(xs...); }; }; 
  }

  int main() { list (); }

So I wonder how to make template_class_depth be aware of the given type's
enclosing variable template...

[Bug fortran/50555] synonymous namelist/statement function dummy argument not allowed (r178939)

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Feb  7 20:15:55 2016
New Revision: 233203

URL: https://gcc.gnu.org/viewcvs?rev=233203=gcc=rev
Log:
2016-02-07  Jerry DeLisle  

PR fortran/50555
* primary.c (match_actual_arg): If symbol has attribute flavor of
namelist, generate an error. (gfc_match_rvalue): Likewise return
MATCH_ERROR.
* resolve.c (resolve_symbol): Scan arument list of procedures and
generate an error if a namelist is found.

PR fortran/50555
* gfortran.dg/namelist_args.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/namelist_args.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

[bastian.beisc...@rwth-aachen.de]

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

--- Comment #5 from bastian.beisc...@rwth-aachen.de ---
Thanks for your comments. Does this mean that such a macro does not exist at
the present time?

[Bug fortran/50555] synonymous namelist/statement function dummy argument not allowed (r178939)

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #9 from Jerry DeLisle  ---
...

[Bug fortran/56007] Remarkably bad error message with DO array=1,2

[anlauf at gmx dot de]

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

--- Comment #6 from Harald Anlauf  ---
(In reply to Harald Anlauf from comment #5)
> The patch of comment #4 appears to be easily extendible to reject
> arrays as loop variables (I hope I got this right):
> 
> Index: gcc/fortran/match.c
> ===
> --- gcc/fortran/match.c (revision 232904)
> +++ gcc/fortran/match.c (working copy)
> @@ -877,6 +877,18 @@
>if (m != MATCH_YES)
>  return MATCH_NO;
>  
> +  if (var->ts.type == BT_CHARACTER)
> +{
> +  gfc_error ("Loop variable at %C cannot be of type CHARACTER");
> +  goto cleanup;
> +}
> +
> +  if (var->symtree->n.sym->attr.dimension)
> +{
> +  gfc_error ("Loop variable at %C cannot be an array");
> +  goto cleanup;
> +}
> +
>/* F2008, C617 & C565.  */
>if (var->symtree->n.sym->attr.codimension)
>  {

The first part of the patch is actually not needed, thus the essential
part is:

Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 232904)
+++ gcc/fortran/match.c (working copy)
@@ -877,6 +877,12 @@
   if (m != MATCH_YES)
 return MATCH_NO;

+  if (var->symtree->n.sym->attr.dimension)
+{
+  gfc_error ("Loop variable at %C cannot be an array");
+  goto cleanup;
+}
+
   /* F2008, C617 & C565.  */
   if (var->symtree->n.sym->attr.codimension)
 {


This removed the most confusing error messages, but leaves those
cases untouched where the parsing of the do statement should give
a syntax error.

Testsuite suggestions based on Tobias' examples:

% cat pr56007.f
! { dg-do compile }
! PR fortran/56007
! Based on testcase by Tobias Schlüter

  integer iw1(90), doiw1(90)
  do iw1(1)=1
  do iw1=1
  do iw1=1,2! { dg-error "cannot be an array" }
  end do! { dg-error "Expecting END PROGRAM statement" }
  END

% cat pr56007.f90
! { dg-do compile }
! PR fortran/56007
! Based on testcase by Tobias Schlüter

  integer iw1(90), doiw1(90)
  do iw1=1,2 ! { dg-error "cannot be an array" }
  end do ! { dg-error "Expecting END PROGRAM statement" }
  do iw1(1)=1! { dg-error "Unclassifiable statement" }
  do iw1=1   ! { dg-error "cannot be an array" }
  end do ! { dg-error "Expecting END PROGRAM statement" }
END program

[Bug fortran/50555] synonymous namelist/statement function dummy argument not allowed (r178939)

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
Closing, fixed on trunk.

[Bug c/69602] [6 Regression] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Depends on||43486, 61534

--- Comment #9 from Manuel López-Ibáñez  ---
If not a duplicate, then they are co-dependent.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486
[Bug 43486] Preserve variable-use locations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61534
[Bug 61534] Wlogical-op should not warn when either operand comes from macro
expansion

[Bug lto/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez  ---
Note that it is ok to completely ignore such an invalid line directive and:

line-map.c: file "" left but not entered

should actually be an error or an ICE. As the code says:

  /* Depending upon whether we are handling preprocessed input or
 not, this can be a user error or an ICE.  */
  if (error)
fprintf (stderr, "line-map.c: file \"%s\" left but not entered\n",
 to_file);

The problem is that nobody so far has done the work of adding diagnostics/ICE
reporting support to line-maps.c, so that the above can be a proper ICE or
diagnostic (perhaps the error should be reported by the caller, who presumably
knows whether this comes from preprocessed input?).

There is also:

  /* Depending upon whether we are handling preprocessed input or
 not, this can be a user error or an ICE.  */
  for (map = LINEMAPS_LAST_ORDINARY_MAP (set);
   ! MAIN_FILE_P (map);
   map = INCLUDED_FROM (set, map))
fprintf (stderr, "line-map.c: file \"%s\" entered but not left\n",
 ORDINARY_MAP_FILE_NAME (map));

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to bastian.beischer from comment #3)
> Jonathan, maybe so but it should be mentioned on the page nevertheless,
> right?

Yes, although I plan to deprecate that macro.

> My issue is that we are using (as an example):
> 
> #if (defined(__GLIBCXX__) && __GLIBCXX__ > 20150626) ||
> (defined(_LIBCPP_VERSION) && _LIBCPP_VERSION >= 1101)
> static_assert(std::is_trivially_constructible::value, "MyClass
> should be trivially constructible.");
> #endif
> 
> since "std_is_trivially_constructible" exists only in libstdc++ shipped with
> GCC 5.1.0+, but not in libstdc++ shipped with GCC 4.9.3, for example.
>
> If i understand your comment correctly you are saying that, if GCC 4.9.4
> were released, it would include a version of libstdc++ with __GLIBCXX__ >
> today, so it would pass the above check, but still there would't be any
> "std_is_trivially_constructible".

Exactly. GCC 4.9.4 definitely will be released, and when it is your check will
not work. Someone could even use a version of GCC 4.9.3 built from the
gcc-4_9-branch in subversion, and your check would fail today.

> But how else can I do the check then?! Using __GNUC__ / __GNUC_MINOR__ is
> not going to work because we have people using other compilers (clang, Intel
> compiler) which use libstdc++ shipped with GCC but do not define __GNUC__ /
> __GNUC_MINOR__.

We need a macro that actually reflects the version of the library, not one that
refers to the almost meaningless release date.

[Bug c/69602] [6 Regression] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

[manu at gcc dot gnu.org]

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

--- Comment #11 from Manuel López-Ibáñez  ---
(In reply to Gerald Pfeifer from comment #10)
> (In reply to Jakub Jelinek from comment #8)
> >   if (errno == EAGAIN || (EWOULDBLOCK != EAGAIN && errno == EWOULDBLOCK))
> > could be better workaround.
> 
> This is WAY more complicated to read and understand than the original
> approach.  I understand you only called it a workaround, but I am pretty
> sure both GCC and Wine maintainers (and presumably others) would shoot
> such obfuscation down if it's for the sake of avoiding a warning.

Unfortunately, we are very far away from implementing anything better [*],
short of completely disabling the warning, which can be done by users with
#pragma GCC diagnostic for specific cases or simply by not using -Wlogical-op.
As Marek said, many warnings suffer from this inability to see macros before
expansion, and this is why they are not enabled by -Wall (or even by -Wextra).

[*] Fixing this will not only require making the folding procedures recognize
macros and handle them specially for the sake of some warnings which want to
look at code as written by the user, not as represented internally by gcc; it
will also require adding virtual locations to a lot of source level entities
that don't have them (PR43486). I would not expect to see the latter in the
near future; it has proven to be a very hard problem to crack.

[Bug c/69602] [6 Regression] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

[gerald at pfeifer dot com]

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

Gerald Pfeifer  changed:

   What|Removed |Added

 CC||gerald at pfeifer dot com

--- Comment #10 from Gerald Pfeifer  ---
(In reply to Manuel López-Ibáñez from comment #6)
> I think we should NOT look through macros. The purpose of the warning is to
> catch mistakes like xxx && !!xxx or 0 < A || A > 0, but if the user writes
> f() && g() and both functions return the same value, it is clearly not a
> bug, even if GCC knows that they are the same function.

I agree with Manuel (and had similar cases in Wine).  Sometimes APIs
may richer than an actual implementation thereof, as is the case in
this example.  Still we would want developers to write general code
that matches the API instead of manually optimizing things (and in
consequence breaking them on other platforms/in other scenarios).

(In reply to Jakub Jelinek from comment #8)
>   if (errno == EAGAIN || (EWOULDBLOCK != EAGAIN && errno == EWOULDBLOCK))
> could be better workaround.

This is WAY more complicated to read and understand than the original
approach.  I understand you only called it a workaround, but I am pretty
sure both GCC and Wine maintainers (and presumably others) would shoot
such obfuscation down if it's for the sake of avoiding a warning.

[Bug fortran/69695] slice of an array retains pointer attribute

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

   Keywords|accepts-invalid |wrong-code
 CC||mikael at gcc dot gnu.org

--- Comment #2 from Mikael Morin  ---
(In reply to Joost VandeVondele from comment #0)
> However, the underlying problem is that gfortran doesn't generate a compile
> time error, as the array slice is passed to a subroutine that expects a
> pointer argument. 

This seems to be allowed, see 12.5.2.7:

If the dummy argument does not have INTENT (IN), the actual argument shall be a
pointer. Otherwise, the
actual argument shall be a pointer or a valid target for the dummy pointer in a
pointer assignment statement. 


Only the target attribute is required, and a(:,2) has the target attribute.
The program is properly rejected with -std=f2003.
So this is probably a plain wrong-code bug.

[Bug other/69554] [6 Regression] Multi-location diagnostics writes too many lines

[manu at gcc dot gnu.org]

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

--- Comment #16 from Manuel López-Ibáñez  ---
You can also just match the locations and the columns with dg-error. Placing
dg-error at the expected lines will match the expected output as explained in
comment 12. Fixing dg-begin-multiline-output for fortran might be too much
work/disruptive for gcc 6 stage 4.

[Bug c++/69139] [4.9/5/6 Regression] deduction failure with trailing return type in function template argument

[rs2740 at gmail dot com]

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

--- Comment #3 from TC  ---
Another test case, slightly modified from the original in the linked SO
question:

struct X {
  auto get(int) const & -> int { return {}; }
  auto get(int) && -> long { return {}; }
};

template  auto f(auto (X::*)(int) const & -> R) -> R {}

using I = decltype(f(::get));
using I = int;

The fix needs to also handle the cv-qualifier-seq and ref-qualifier in the
function type, if any.

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

[kkojima at gcc dot gnu.org]

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

--- Comment #14 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #13)
> Good question indeed.  Kaz, maybe you remember anything?

With my vague recollection, they were already there when I had looked
into them for the first time.

I guess that SH jump stuff was built with stacking many things so to
avoid strong restrictions of ISA.  Rewriting them from a current view
of gcc is a good thing, though perhaps it'll be a big hummer.

[Bug fortran/56007] Remarkably bad error message with DO array=1,2

[anlauf at gmx dot de]

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

--- Comment #7 from Harald Anlauf  ---
The patch in comment #6 requires adapting the testsuite accordingly:

gfortran.dg/coarray_8.f90:149:7:

   do i = 1, 5 ! { dg-error "cannot be a sub-component" }

needs to be changed to:

   do i = 1, 5 ! { dg-error "cannot be an array" }

[Bug c++/66786] [5/6 Regression] ICE: Segmentation fault

[ppalka at gcc dot gnu.org]

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

--- Comment #5 from Patrick Palka  ---
Looks like the field LAMBDA_TYPE_EXTRA_SCOPE has what we need.  I am testing
this patch:

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 4d405cf..5c344c1 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -369,16 +369,20 @@ template_class_depth (tree type)
 {
   int depth;

-  for (depth = 0;
-   type && TREE_CODE (type) != NAMESPACE_DECL;
-   type = (TREE_CODE (type) == FUNCTION_DECL)
-? CP_DECL_CONTEXT (type) : CP_TYPE_CONTEXT (type))
+  for (depth = 0; type && TREE_CODE (type) != NAMESPACE_DECL; )
 {
   tree tinfo = get_template_info (type);

   if (tinfo && PRIMARY_TEMPLATE_P (TI_TEMPLATE (tinfo))
  && uses_template_parms (INNERMOST_TEMPLATE_ARGS (TI_ARGS (tinfo
++depth;
+
+  if (VAR_OR_FUNCTION_DECL_P (type))
+   type = CP_DECL_CONTEXT (type);
+  else if (LAMBDA_TYPE_P (type))
+   type = LAMBDA_TYPE_EXTRA_SCOPE (type);
+  else
+   type = CP_TYPE_CONTEXT (type);
 }

   return depth;

[Bug c++/69715] g++ crash dump on building SoftFloatWrapper.cpp

[kip at thevertigo dot com]

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

Kip Warner  changed:

   What|Removed |Added

 CC||kip at thevertigo dot com

--- Comment #2 from Kip Warner  ---
Created attachment 37624
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37624=edit
Summary build log.

[Bug target/69716] New: asm generates invalid register name

[gccbugzilla at limegreensocks dot com]

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

Bug ID: 69716
   Summary: asm generates invalid register name
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugzilla at limegreensocks dot com
  Target Milestone: ---

While this is a problem with inline asm, it seems like it would be
target-specific which is why I set component: target.

I can produce the problem several ways.  This is probably the simplest:

unsigned char a = 0;
asm volatile("mov $0, %0" : "=r"(a) : : "ax", "bx", "cx", "dx");

Compile this with gcc -m32 -S, and you see:

mov $0, %sil

However, sil is not a valid register name on x86 (although it is on x64).

You can get similar behavior with:

   unsigned char a, b, c, d, e;
   asm volatile("# %0 %1 %2 %3 %4" : "=r"(a),"=r"(b),"=r"(c),"=r"(d),"=r"(e));

This generates:

# %dil %sil %bl %cl %dl

Neither dil nor sil are valid register names for 32bit.

[Bug middle-end/69714] New: [5 Regression] ffmpeg crc.c test miscompiled

[danglin at gcc dot gnu.org]

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

Bug ID: 69714
   Summary: [5 Regression] ffmpeg crc.c test miscompiled
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

Created attachment 37622
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37622=edit
Preprocessed source

The attached preprocessed source file is miscompiled without
'-fno-expensive-optimizations'.  Compile command is:

gcc -S -fpreprocessed crc.i -dumpbase crc.c -g -g -O2 -O3 -Wdate-time
-Wformat=1 -Werror=format-security -Wdeclaration-after-statement -Wall
-Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings
-Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast
-Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-switch
-Wno-format-zero-length -Wno-pointer-sign -Werror=format-security
-Werror=implicit-function-declaration -Werror=missing-prototypes
-Werror=return-type -Werror=vla -Wformat=1 -Wno-maybe-uninitialized -std=c99
-fno-strict-overflow -fstack-protector-all -fomit-frame-pointer -fPIC
-fno-optimize-sibling-calls -fno-math-errno -fno-signed-zeros
-fno-tree-vectorize -fdiagnostics-color=auto -o crc.s

Main assembly difference is:

dave@mx3210:~/crc$ diff -u crc.s-expensive-opt crc.s-no-expensive-opt|less
--- crc.s-expensive-opt 2016-02-07 19:25:52.859388388 -0500
+++ crc.s-no-expensive-opt  2016-02-07 19:03:10.848495110 -0500
@@ -340,16 +340,15 @@
 .LVL54:
 .L42:
.loc 1 367 0
-   ldw 0(%r31),%r21
-   zdep %r21,23,8,%r28
-   extru %r21,16+8-1,8,%r21
-   ldh 2(%r31),%r20
-   or %r28,%r21,%r28
+   ldw 0(%r31),%r20
extru %r20,16+8-1,8,%r21
+   zdep %r20,23,8,%r28
+   or %r28,%r21,%r28
+   extru %r20,7,8,%r21
zdep %r28,15,16,%r28
-   zdep %r20,23,24,%r22
+   extru %r20,15,16,%r22
+   zdep %r22,23,8,%r22
or %r22,%r21,%r20
-   extru %r20,31,16,%r20
or %r28,%r20,%r20
xor %r20,%r25,%r28

This bug is also believed to affect mips:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813858

[Bug target/69713] Invalid code of optimization in SH

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  ---
(In reply to Oleg Endo from comment #3)
> 
> One option could be to merge the casesi_0 and casesi_worker_0 /
> casesi_worker_1 patterns somehow into one pattern, so that the block remains
> in one place.
> 
> Another option I can think of would be feeding the bounds check comparison
> result from the casesi_0 insns into casesi_worker_0/casesi_worker_1 and add
> a conditional branch around the table access.

Option 3)
Try adding a T_REG use in casesi_worker_0/casesi_worker_1 patterns to create a
link between the bounds checking insn and the table access insns.

Option 4)
Try implementing the "tablejump" pattern instead of "casesi" and let the
middle-end handle the bounds checking.

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

[bugdal at aerifal dot cx]

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

--- Comment #15 from Rich Felker  ---
Is it related to the fact that the relative address load is tied to a specific
call site and that the call can't be cloned without producing a new relative
address load to go with the clone?

[Bug testsuite/69573] FAIL: gcc.dg/pr61053.c (test for excess errors)

[gang.chen.5i5j at gmail dot com]

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

--- Comment #3 from Chen Gang  ---
Created attachment 37625
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37625=edit
Under my Darwin mac book OS X Yosemite 10.10.4, it looks short wide alignas for
long wide type will cause issue.

Under my Darwin mac book OS X Yosemite 10.10.4, it looks short wide alignas for
long wide type will cause issue.

Please check, thanks.

And I shall continue, too.

[Bug c++/69715] New: g++ crash dump on building SoftFloatWrapper.cpp

[kip at thevertigo dot com]

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

Bug ID: 69715
   Summary: g++ crash dump on building SoftFloatWrapper.cpp
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kip at thevertigo dot com
  Target Milestone: ---

While building streflop via my PPA (personal package archive) I managed to
actually make GCC crash. I've attached two logs. One is the full build log
which is very large (11 MB), and the other is an excerpt of just the dump
itself.

Note that this only seems to happen when my package is built for i386 and not
amd64.

Here is the PPA in case it is of use:
https://launchpad.net/~kip/+archive/ubuntu/streflop

[Bug c++/69715] g++ crash dump on building SoftFloatWrapper.cpp

[kip at thevertigo dot com]

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

--- Comment #1 from Kip Warner  ---
Created attachment 37623
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37623=edit
Complete build log (very big, 11 MB decompressed).

[Bug libstdc++/69717] New: std::pair is incompatible with std::is_constructible

[david at doublewise dot net]

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

Bug ID: 69717
   Summary: std::pair is incompatible with std::is_constructible
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david at doublewise dot net
  Target Milestone: ---

#include 
#include 

struct S {
S(int) {}
};

int main() {
using pair_t = std::pair;
static_assert(std::is_default_constructible::value, "");
pair_t p;
}





The static_assert does not fire, even though it should. If I comment out line
11, everything compiles. With line 11 in, I get a compile error that
essentially tells me that pair_t is not default constructible. This is with
-std=c++1z, which has pair's constructors only participating in overload
resolution if they are valid.

Compiling with clang and libstdc++ gives different behavior. The static_assert
fails to compile, but not with a regular static_assert message. It gives a hard
error, similar to what gcc gives when you actually try to compile line 11.
However, it is a hard error not in the immediate context, so attempting to use
it for SFINAE with enable_if causes a compile time error. In other words, I get
a compiler error with clang if I just mention
std::is_default_constructible, which seems like 'correct' behavior
based on the implementation of std::pair (but not correct in c++1z mode).

So this actually seems like a bug in both gcc and libstdc++. libstdc++ has a
std::pair implementation that causes a hard error even in c++1z mode if you
check if it is default constructible and it is not, and gcc has a bug that
causes it to ignore that error and just return true for
std::is_default_constructible.

This looks related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68430

[Bug testsuite/68886] FAIL: gcc.c-torture/execute/stkalign.c execution test

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #4 from Alan Modra  ---
Created attachment 37626
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37626=edit
fix the testcase

From the git commit log
Function (or more narrow) scope static variables (as well as others not
placed on the stack) should also not have any effect on the stack
alignment.
but that is not exactly what the testcase is testing..  So, make it test just
that, by using two functions, identical except for the non-stack var alignment.

[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber

[gccbugzilla at limegreensocks dot com]

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

--- Comment #14 from David  ---
I understand that stage 3 is now closed too.  I don't have svn write access, so
I can't check this in myself.

[Bug c++/69718] New: [concepts] cc1plus segfault on invalid

[lucdanton at free dot fr]

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

Bug ID: 69718
   Summary: [concepts] cc1plus segfault on invalid
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr
  Target Milestone: ---

The testcase was mechanically reduced.

$ g++-trunk --version
g++-trunk (GCC) 6.0.0 20160208 (experimental)
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat main.cpp
template concept bool Concept = requires { Type { 0 }; };
struct foo {
typename foo(Init) requires Concept {
foo {
$ g++-trunk -std=c++1z main.cpp
main.cpp:3:14: error: expected nested-name-specifier before 'foo'
 typename foo(Init) requires Concept {
  ^~~
main.cpp:3:18: error: 'Init' has not been declared
 typename foo(Init) requires Concept {
  ^~~~
main.cpp:4:13: error: expected '}' at end of input
 foo {
 ^
g++-trunk: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug libfortran/69651] Usage of unitialized pointer io/list_read.c

[kyukhin at gcc dot gnu.org]

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

--- Comment #3 from Kirill Yukhin  ---
Created attachment 37627
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37627=edit
Reproducer src

Reproducer

[Bug libfortran/69651] Usage of unitialized pointer io/list_read.c

[kyukhin at gcc dot gnu.org]

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

--- Comment #4 from Kirill Yukhin  ---
Created attachment 37628
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37628=edit
Reproducer input

[Bug c++/64697] C++11 thread_local: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for N::ptd'

[raidl at ac dot tuwien.ac.at]

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

--- Comment #4 from raidl at ac dot tuwien.ac.at ---
Problem is still present in gcc 5.3.0.
Furthermore, it also appears when the thread_local variable is a static class
member.

[Bug tree-optimization/69719] New: wrong code at -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 69719
   Summary: wrong code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk and 5.3.x miscompile the following code on
x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes. 

This is a regression from 5.2.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160207 (experimental) [trunk revision 233200] (GCC) 
$ 
$ gcc-trunk -O2 small.c; ./a.out
$ gcc-5.2 -O3 small.c; ./a.out
$ 
$ gcc-trunk -O3 small.c
$ ./a.out
Aborted (core dumped)
$ gcc-5.3 -O3 small.c
$ ./a.out
Aborted (core dumped)
$ 


--


int b, c = 1, e, f; 
int a[6][5] = { {0, 0, 0, 0, 0}, 
{0, 0, 0, 0, 0}, 
{0, 1, 0, 0, 0} };

void 
fn1 ()
{
  int d;
  for (b = 0; b < 5; b++)
for (d = 4; d; d--)
  a[c + 1][b] = a[d + 1][d];
}

int
main ()
{
  fn1 ();

  if (a[2][1] != 0) 
__builtin_abort (); 

  return 0; 
}

[Bug tree-optimization/69720] New: wrong code at -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 69720
   Summary: wrong code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -O3
in both 32-bit and 64-bit modes. 

This is a regression from 5.3.x.


$ gcc-trunk -v  
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160207 (experimental) [trunk revision 233200] (GCC) 
$ 
$ gcc-trunk -O2 small.c; ./a.out
$ gcc-5.3 -O3 small.c; ./a.out
$ 
$ gcc-trunk -O3 small.c
$ ./a.out
Aborted (core dumped)
$ 


-


int a, b, c, e, f; 
long long d[32] = { 4, 0, 4, 4, 0, 4, 4, 0, 4, 4, 0, 4, 4 };

int
main ()
{
  for (; a < 6; a++)
{
  b ^= e;
  for (c = 0; c < 2; c++)
d[a * 6] |= 9;
}

  if (d[12] != 13) 
__builtin_abort (); 

  return 0;
}

[Bug fortran/69695] slice of an array retains pointer attribute

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #3 from Joost VandeVondele  
---
(In reply to Mikael Morin from comment #2)

> This seems to be allowed, see 12.5.2.7:

Interesting, so that's a F2008 feature. The Cray compiler indeed gets this
right.

> So this is probably a plain wrong-code bug.

thanks for looking carefully!

[Bug libfortran/69651] Usage of unitialized pointer io/list_read.c

[kyukhin at gcc dot gnu.org]

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

--- Comment #5 from Kirill Yukhin  ---
A bug in fortran's IO RT has emerged during 21 Apr 2016,
between r54 and r92; 
looks like it's caused by the same revision –r71
(libgfortran/io/list_read.c ), which probably just triggers
another hidden bug.

Trying two  builds (as of  21 and 22 Apr ):
$  gfortran-20160421 -O0 T.f90 -static  
$ ./a.out 
 res, (1) ==1 !
### Ok 

$  gfortran-20160422 -O0 T.f90 -static  
$ ./a.out  
 res, (1) ==   80  @p¼B
### FAIL – garbage is read in 

[Bug web/69601] current/ redirect is off by at least a day

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||gerald at pfeifer dot com,
   ||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #1 from Joost VandeVondele  
---
mentioned on the mailing list:

https://gcc.gnu.org/ml/gcc/2016-02/msg00066.html

Is this now fixed ? It took a couple of days for the switch to happen.