[Bug target/69187] ICE: Aborted when native compiling neon code with __builtin_neon_vmlals_lanev4hi

[stefan.sorensen at spectralink dot com]

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

Stefan Sørensen  changed:

   What|Removed |Added

 CC||stefan.sorensen@spectralink
   ||.com

--- Comment #6 from Stefan Sørensen  ---
Created attachment 37300
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37300=edit
Proposed fix

It seems to be a simple array overflow in arm_expand_neon_builtin, causing neon
builtins with the maximum number of arguments to thrash the stack.

[Bug go/68980] [6 regression] ps -o cmd in gotest isn't portable

[axwalk at gmail dot com]

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

Andrew Wilkins  changed:

   What|Removed |Added

 CC||axwalk at gmail dot com

--- Comment #3 from Andrew Wilkins  ---
Use of comm should be suitable. I am verifying this now.

[Bug c++/69222] New: C++14 template code working in GCC 5.1 stops working in 5.2 and 5.3

[wuyongwei at gmail dot com]

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

Bug ID: 69222
   Summary: C++14 template code working in GCC 5.1 stops working
in 5.2 and 5.3
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wuyongwei at gmail dot com
  Target Milestone: ---

Created attachment 37299
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37299=edit
Test C++ file

I have an implementation of Y Combinator in C++, which works in GCC 4.9 to 5.1
as well as Clang 3.5 (in C++14 mode). It stops working in GCC 5.2 and 5.3, so I
think it is regression. I think GCC is being too eager in template
instantiation. As I also tried using the GCC 5.1 C++ header files with GCC 5.2
and got the same errors, I guess it is a C++ front end problem.

The test program is supposed to apply the Y combinator to a non-recursive
function almost_fac to get a factorial function. It should compile well and
output two lines of "120", but now it fails the compilation at the
"fix_curry(almost_fac)" line.

I tested on Windows and OS X. The Windows error output is:

In file included from test_gcc.cpp:1:0:
C:/mingw64/x86_64-w64-mingw32/include/c++/functional: In substitution of
'template std::function<_Res(_ArgTypes
...)>::function(_Functor) [with _Functor =
std::function(self_ref_func
>)>;  = ]':
C:/mingw64/x86_64-w64-mingw32/include/c++/functional:1981:45:   recursively
required by substitution of 'template
std::function<_Res(_ArgTypes ...)>::function(_Functor) [with _Functor =
std::function(self_ref_func
>)>;  = ]'
C:/mingw64/x86_64-w64-mingw32/include/c++/functional:1981:45:   required by
substitution of 'template std::function<_Res(_ArgTypes
...)>::function(_Functor) [with _Functor =
std::function(self_ref_func
>)>;  = ]'
test_gcc.cpp:47:51:   required from
'fix_curry(std::function(std::function<_Rs(_Tp)>)>)::::
[with _Rs = int; _Tp = int]'
test_gcc.cpp:45:34:   required from 'struct
fix_curry(std::function(std::function<_Rs(_Tp)>)>)::
[with _Rs = int; _Tp = int; fn_self_ref = self_ref_func
>]::'
test_gcc.cpp:45:21:   required from
'fix_curry(std::function(std::function<_Rs(_Tp)>)>)::
[with _Rs = int; _Tp = int; fn_self_ref = self_ref_func
>]'
test_gcc.cpp:43:10:   required from 'struct
fix_curry(std::function(std::function<_Rs(_Tp)>)>)
[with _Rs = int; _Tp = int]::'
test_gcc.cpp:50:5:   required from 'std::function<_Rs(_Tp)>
fix_curry(std::function(std::function<_Rs(_Tp)>)>)
[with _Rs = int; _Tp = int]'
test_gcc.cpp:69:43:   required from here
C:/mingw64/x86_64-w64-mingw32/include/c++/functional:1981:69: fatal error:
template instantiation depth exceeds maximum of 900 (use -ftemplate-depth= to
increase the maximum)
  using _Invoke = decltype(__callable_functor(std::declval<_Functor&>())
 ^
compilation terminated.

[Bug c++/69218] File input streams states inconsistency

[dmitigr at gmail dot com]

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

--- Comment #3 from Dmitry Igrishin  ---
(In reply to Jonathan Wakely from comment #2)
> This is the correct behaviour required by the C++ standard, your assertion
> is incorrect, that is not guaranteed to always be true.
> 
> When reading the last word of the file (which in your test is "character")
> the compiler keeps reading while there are non-whitespace characters.
> Because there are no non-whitespace characters after the word "character" it
> stops reading and sets eofbit, but doesn't set failbit because reading
> succeeded.
> 
> If you have a newline at the end then reading the word "character" does not
> reach EOF, but on the next time round the loop it fails to read any
> non-whitespace characters, so sets failbit.
> 
> This is why you should write "while (in >> w)" instead of checking for EOF.

I just didn't find this requirement in the standard. (Got lost here.) Sorry for
noise.

[Bug c++/69218] File input streams states inconsistency

[dmitigr at gmail dot com]

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

--- Comment #4 from Dmitry Igrishin  ---
(In reply to Jonathan Wakely from comment #2)
> This is the correct behaviour required by the C++ standard, your assertion
> is incorrect, that is not guaranteed to always be true.
> 
> When reading the last word of the file (which in your test is "character")
> the compiler keeps reading while there are non-whitespace characters.
> Because there are no non-whitespace characters after the word "character" it
> stops reading and sets eofbit, but doesn't set failbit because reading
> succeeded.
> 
> If you have a newline at the end then reading the word "character" does not
> reach EOF, but on the next time round the loop it fails to read any
> non-whitespace characters, so sets failbit.
> 
> This is why you should write "while (in >> w)" instead of checking for EOF.

And thank you for explanation, Jonathan!

[Bug c++/69223] New: ICE with polymorphic lambda

[nightstrike at gmail dot com]

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

Bug ID: 69223
   Summary: ICE with polymorphic lambda
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

The following code causes an ICE on gcc 4.9.3, 5.1, 5.2, and 5.3:
[If a fix is found, could it be backported to 4.9?]

#include 
#include 
#include 

int main(int argc, char * argv[]) {
  std::vector> out;
  std::vector data;

  auto saveChan = [&](std::size_t size, auto const & src, auto & dest, auto &&
f) {
for (std::size_t chan = 0; chan < size; ++chan)
  for (auto const & i: src)
dest.emplace_back(f(i)[chan]);
  };
  saveChan(20, out, data, [](decltype(out)::value_type const & i){ return i;});

  return 0;
}


$ g++ -std=gnu++14 aa.cpp -c
aa.cpp: In lambda function:
aa.cpp:14:81: internal compiler error: Segmentation fault
  saveChan(20, out, dataInt32, [](decltype(out)::value_type const & i){ return
i;});
   
 ^
0x9def6f crash_signal
../../gcc/toplev.c:337
0x86c90e gimplify_return_expr
../../gcc/gimplify.c:1229
0x86c90e gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7874
0x86e4b6 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5373
0x86c34d gimplify_cleanup_point_expr
../../gcc/gimplify.c:5149
0x86c34d gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7990
0x86e4b6 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5373
0x86ed4b gimplify_bind_expr
../../gcc/gimplify.c:1099
0x86c2be gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7824
0x86e4b6 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5373
0x86f36a gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:8734
0x86f657 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:8887
0x769d27 cgraph_analyze_function(cgraph_node*)
../../gcc/cgraphunit.c:648
0x76aa57 analyze_functions
../../gcc/cgraphunit.c:1016
0x76b895 finalize_compilation_unit()
../../gcc/cgraphunit.c:2328
0x61e4d3 cp_write_global_declarations()
../../gcc/cp/decl2.c:4647
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/69062] invalid PHI argument error with ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from vries at gcc dot gnu.org ---
patch with test-case committed, marking resolved-fixed

[Bug c/69224] New: -Warray-bounds false positive with -O3 and struct pointer parameter

[nightstrike at gmail dot com]

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

Bug ID: 69224
   Summary: -Warray-bounds false positive with -O3 and struct
pointer parameter
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

There are a lot of -Warray-bounds false positives at -O3, but this one is
interesting:

struct S {
int a;
int b;
int c;
int d;
int e;
float x[5];
float y[5];  // Comment these two lines out to
float z[5 - 1];  // remove the warning
};
void f(struct S *s, float a[], float **b, float c[]) {
if ((s->b == 1) && (s->d > 0)) {
for (int i = 0; i < s->a; i++) {
if (a[i] != 0.0) {
for (int j = 0; j < s->d - 1; j++) {
if ((c[i] >= s->x[j]) && (c[i] <=
s->x[j + 1])) {
b[2*j][i] = s->x[j];
break;
}
}
}
}
}
}



If you comment out those two variables in the struct, both of which are unused,
then the warning goes away.

Note that in this particular case, since the loop boundary is passed in at run
time, there's no way for the compiler to ever know if we are exceeding the
array bounds.

I've included a few of the other -Warray-bounds bugs in the See Also lists in
the hopes that maybe some of these would be related.

[Bug libstdc++/69191] Wrong equality comparison between error_code and error_condition + segfault

[eyenseo at gmail dot com]

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

--- Comment #12 from eyenseo at gmail dot com ---
(In reply to Jonathan Wakely from comment #10)
> Use ldd to see which library is used at runtime. See what file that symlink
> points to. Compare with the version numbers of the releases.
> 
> GCC 4.9.0: libstdc++.so.6.0.20
> 
> GCC 5.1.0: libstdc++.so.6.0.21

It does use /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 ... why would they do
that?

[Bug c++/67650] undef reference with -fdevirtualize

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||jason at redhat dot com

--- Comment #8 from Jan Hubicka  ---
I think this is a bug in testcase and/or C++ FE.  I get:
main.cpp:33:8: warning: �void AN::rp() [with OC = LR::LLC; RC = BLKC]� used but never defined

/tmp/ccT1Jzgh.o:main.cpp:function main: error: undefined reference to 'operator
new(unsigned long)'
/tmp/ccT1Jzgh.o:main.cpp:function LK::LL>::rb(): error:
undefined reference to 'AN::LLC, BLKC>::rp()'

_ZN2ANIN2LRI1I2IEXadL_ZL2ETEEE3LLCE4BLKCE2rpEv is virtual function that is not
defined:

_ZN2ANIN2LRI1I2IEXadL_ZL2ETEEE3LLCE4BLKCE2rpEv/504 (void AN::rp() [with
OC = LR::LLC; RC = BLKC]) @0x75aa2000
  Type: function
  Visibility: external public virtual
  References: 
  Referring: 
  First run: 0
  Function flags:
  Called by: _ZN2REI2ELIN2LRI1I2IEXadL_ZL2ETEEE3LLCEEE2axEv/485 (1.00 per call)
(can throw external) 
  Calls: 

and is used as:
_ZN2LKIN2LRI1I2IEXadL_ZL2ETEEE2LLEE2rbEv/484 (void LK::rb() [with T = LR::LL]) @0x75a4fa10
  Type: function definition analyzed
  Visibility: prevailing_def_ironly virtual 
  Address is taken. 
  References:   
  Referring: _ZTV2LKIN2LRI1I2IEXadL_ZL2ETEEE2LLEE/441 (addr)
  Availability: available   
  First run: 0  
  Function flags: body  
  Called by:
  Calls: _ZN2ANIN2LRI1I2IEXadL_ZL2ETEEE3LLCE4BLKCE2rpEv/504 (1.00 per call)
(can throw external)


Now with -fno-devirtualize we get:
/484 (void LK::rb() [with T = LR::LL])
@0x75a4fa10
  Type: function definition analyzed
  Visibility: prevailing_def_ironly virtual 
  Address is taken. 
  References:   
  Referring: _ZTV2LKIN2LRI1I2IEXadL_ZL2ETEEE2LLEE/441 (addr)
  Availability: available   
  First run: 0  
  Function flags: body  
  Called by:
  Calls:
   Polymorphic indirect call of type struct RE token:0(1.00 per call) (can
throw external)
nothing known   

So it is simply devirtualization of:
;; Function void LK::rb() [with T = LR::LL]
(_ZN2LKIN2LRI1I2IEXadL_ZL2ETEEE2LLEE2rbEv, funcdef_no=1102, decl_uid=24008,
cgraph_uid=438, symbol_order=484)

void LK::rb() [with T = LR::LL] (struct LK *
const this)
{   
  struct RE * _1;   
  int (*__vtbl_ptr_type) () * _3;   
  int (*__vtbl_ptr_type) () _4; 

  :   
  _1 = [(struct LL *)0B].D.25771.D.25733;   
  _3 = MEM[(struct RE *)0B]._vptr.RE;   
  _4 = *_3; 
  OBJ_TYPE_REF(_4;(struct RE)_1->0) (_1);   
  return;   

}   
to
;; Function void LK::rb() [with T = LR::LL]
(_ZN2LKIN2LRI1I2IEXadL_ZL2ETEEE2LLEE2rbEv, funcdef_no=1102, decl_uid=24008,
cgraph_uid=438, symbol_order=484)

void LK::rb() [with T = LR::LL] (struct LK *
const this)
{   
  struct RE * _1;   

  :   
  _1 = [(struct 

[Bug ipa/68148] Devirtualization only applies to last of multiple successive calls

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-01-10
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jan Hubicka  ---
This is the result of analysis:
Procesing function void test(Interface&)/12
Introduced new external node (void __cxa_pure_virtual()/26).
  Targets of polymorphic call of type 0:struct Interface token 3
Outer type (dynamic):struct Interface (or a derived type) offset 0
This is partial list; extra targets may be defined in other units. (derived
types included)
   virtual void Concrete::virtualFunc2()/11

code.C:16:19: note: speculatively devirtualizing call in void
test(Interface&)/12 to virtual void Concrete::virtualFunc2()/11
Indirect call -> speculative call void test(Interface&)/12 => virtual void
Concrete::virtualFunc2()/11
  Targets of polymorphic call of type 0:struct Interface token 2
Outer type (dynamic):struct Interface (or a derived type) offset 0
This is partial list; extra targets may be defined in other units. (derived
types included)
   virtual void Concrete::virtualFunc()/10 (no definition inline)
  Speculative targets:

the problem is that list of Speculative targets is empty which makes us to
ignore the fact that even non-speculatively there is only one possible target.

The reason is that the second function does not pass
can_refer_decl_in_current_unit_p:

149   snode = symtab_node::get (decl);
150   if (!snode
151   || ((!snode->definition || DECL_EXTERNAL (decl))
152   && (!snode->in_other_partition
153   || (!snode->forced_by_abi && !snode->force_output
154 return false;

and node is:

(gdb) p snode->debug ()
_ZN8Concrete11virtualFuncEv/10 (virtual void Concrete::virtualFunc())
@0x76c4f170
  Type: function
  Body removed by symtab_remove_unreachable_nodes
  Visibility: externally_visible public weak comdat
comdat_group:_ZN8Concrete11virtualFuncEv one_only virtual
  References: 
  Referring: 
  Availability: not_available
  First run: 0
  Function flags: icf_merged
  Called by: 
  Calls: 

which is done by ipa-icf::merge:

Wrapper cannot be created because of COMDAT 
Unified; Function body was removed.

This is because ipa-icf thinks that since there are no calls or direct uses, it
may get rid of the function.

I am testing the following:

Index: ../../gcc/ipa-icf.c
===
--- ../../gcc/ipa-icf.c (revision 232179)
+++ ../../gcc/ipa-icf.c (working copy)
@@ -1305,6 +1305,7 @@ sem_function::merge (sem_item *alias_ite

   /* If all callers was redirected, do not produce wrapper.  */
   if (alias->can_remove_if_no_direct_calls_p ()
+ && !DECL_VIRTUAL_P (alias->decl)
  && !alias->has_aliases_p ())
{
  create_wrapper = false;

[Bug tree-optimization/69039] [6 regression] segfault with ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from vries at gcc dot gnu.org ---
patch with test-case committed, marking resolved-fixed.

[Bug tree-optimization/69155] [6 Regression] ICE (segfault in gimple_stmt_nonnegative_warnv_p)

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

  Component|fortran |tree-optimization

--- Comment #5 from Thomas Koenig  ---
Just for completeness' sake, here is a C testcase. Needs -fcx-fortran-rules
to fail.

#include 

double complex pr69155(double complex a, double complex b)
{
  if (cimag(a) < 10)
{
  while (creal(a) < 10)
{
  b = b - 1/a;
  a = a + 1;
}
}
  return a+b;
}

ig25@linux-fd1f:/tmp> gcc -fcx-fortran-rules -O c.c
c.c: In Funktion »pr69155«:
c.c:3:16: interner Compiler-Fehler: Speicherzugriffsfehler
 double complex pr69155(double complex a, double complex b)
^~~

0xb473bf crash_signal
../../trunk/gcc/toplev.c:334
0x8e8b15 gimple_stmt_nonnegative_warnv_p(gimple*, bool*, int)
../../trunk/gcc/gimple-fold.c:6260
...

[Bug target/69179] undocumented darwin attributes "apple_kext_compatibility" and "weak_import"

[iains at gcc dot gnu.org]

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

--- Comment #3 from Iain Sandoe  ---
(In reply to sandra from comment #0)
> config/darwin.c defines attributes "apple_kext_compatibility" and
> "weak_import" which have no documentation in the GCC manual.
> 
> "apple_kext_compatibility" seems related to the also-undocumented
> -fapple-kext command-line option (see PR 62273).  Reading the code, I'm
> wondering if a feature intended to provide backwards compatibility with GCC
> 2.95 is even relevant to modern versions of Darwin, or whether this might be
> a candidate for deletion as obsolete.

The purpose of the attribute is to allow the VTABLE for c++ (in kernel modules)
to be altered to be compatible with GCC2.95 layouts for use with Darwin <= 8.
There is an outside possibility it might be relevant to m32 Darwin9 (this needs
checking).

This option is recognised but not implemented - it looks like the APPLE_LOCAL
changes in 4.2.1 were never upstreamed (or never accepted, or subsequently
removed).

I think, documentation-wise, we could (now) note the facts (i.e. that it's
recognised in sources but unimplemented).

For the future;
1. I doubt that there's any serious appetite for introducing intrusive changes
to c++ to support an EOL platform (if we do it at all I'd say save it for a
"Vendor Branch").  ISTM that folks who need to support such kernel modules are
not looking for up-to-date c++11 features and could just use apple g++-4.2.

2. We should introduce at least a warning in the current source that the option
is not enacted.

3. Unless anyone disagrees with (1) and has the time/enthusiasm to implement
and push the implementation though, I think we should note that this attribute
is deprecated

4. It's likely that we should review whether the -fapple-kext stuff has any
function/meaning [to the ppc port] as things stand.

[Bug tree-optimization/69062] invalid PHI argument error with ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
Author: vries
Date: Sun Jan 10 12:44:57 2016
New Revision: 232199

URL: https://gcc.gnu.org/viewcvs?rev=232199=gcc=rev
Log:
Don't parallelize loops containing phis with addr_exprs

2016-01-10  Tom de Vries  

PR tree-optimization/69062
* tree-parloops.c (loop_has_phi_with_address_arg): New function.
(parallelize_loops): Don't paralelize loop that has phi with address
arg.

* gcc.dg/autopar/pr69062.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/autopar/pr69062.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-parloops.c

[Bug middle-end/69217] New: ICE at var-tracking.c:5038 Segmentation fault

[ibuclaw at gdcproject dot org]

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

Bug ID: 69217
   Summary: ICE at var-tracking.c:5038 Segmentation fault
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Starting from this commit, I have been seeing segfaults in the D frontend.

https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/var-tracking.c?r1=231897=231896=231897

The equivalent C++ code is:

---
struct S1 { };

void __dtor (S1& pthis)
{
  return;
}


S1& opAssign (S1& pthis, S1 p)
{
  S1 __tmp1 = pthis;
  pthis = p;
  __dtor (__tmp1);
  return pthis;
}
---

However g++ does something that I don't, remove empty aggregate assignments.

While I should get round to fixing the gimplify stage to conform, I think the
middle-end should do something other than SEGV when this happens.

e.g:

  if (TYPE_FIELDS (type) == NULL_TREE
  || DECL_CHAIN (TYPE_FIELDS (type)) == NULL_TREE)
return false;

[Bug fortran/68829] [4.9/5/6 Regression] Segfaults with -Ofast due to large array on stack

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #3 from Thomas Koenig  ---

> > But it's also that you are asking for it with -Ofast.  Maybe the frontend
> > should have a switch to specifiy a size limit?
> 
> Good idea, any volunteer?

It seems that -fmax-stack-var-size=N does not override -Ofast.  Maybe
it should.

ig25@linux-fd1f:/tmp> cat a.f90
real, dimension(10**6) :: a
call random_number(a)
write (*,*) a
end
ig25@linux-fd1f:/tmp> gfortran -fdump-tree-original -Ofast
-fmax-stack-var-size=1 a.f90 
ig25@linux-fd1f:/tmp> head a.f90.003t.original 
MAIN__ ()
{
  static real(kind=4) a[100];

  {
struct array1_real(kind=4) parm.0;

parm.0.dtype = 281;
parm.0.dim[0].lbound = 1;
parm.0.dim[0].ubound = 100;
ig25@linux-fd1f:/tmp>

[Bug tree-optimization/68976] [6 Regression] ICE w/ -O2 (and above) -fgraphite-identity (or -floop-nest-optimize)

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org

--- Comment #1 from Arseny Solokha  ---
Probably a duplicate of PR68692.

[Bug fortran/67779] Strange ordering with strings in extended object

[pault at gcc dot gnu.org]

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

--- Comment #24 from Paul Thomas  ---
Author: pault
Date: Sun Jan 10 12:56:28 2016
New Revision: 232200

URL: https://gcc.gnu.org/viewcvs?rev=232200=gcc=rev
Log:
2016-01-10  Paul Thomas  

PR fortran/67779
* trans_array.c (gfc_conv_scalarized_array_ref): Add missing
se->use_offset from condition for calculation of 'base'.

2016-01-10  Paul Thomas  

PR fortran/67779
* gfortran.dg/actual_array_offset_1: New test.

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

[Bug fortran/67779] Strange ordering with strings in extended object

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #25 from Paul Thomas  ---
I found a completely trivial fix :-)

Fixed on trunk - thanks for the report.

Paul

[Bug sanitizer/69204] ThreadSanitizer: False positive on std::promise usage

[dvyukov at google dot com]

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

--- Comment #6 from Dmitry Vyukov  ---
The problem is that gcc does not instrument atomic operations for some reason.

Here is disasm of future::set_result:

Dump of assembler code for function
std::__future_base::_State_baseV2::_M_set_result(std::function ()>, bool):
...
   0x0048bebd <+301>:   mov-0x40(%rbp),%rax
   0x0048bec1 <+305>:   mov-0x44(%rbp),%edx
   0x0048bec4 <+308>:   xchg   %edx,(%rax)
   0x0048bec6 <+310>:   mov%edx,%eax
   0x0048bec8 <+312>:   shr$0x1f,%eax
   0x0048becb <+315>:   test   %al,%al
   0x0048becd <+317>:   je 0x48bef5
 ()>, bool)+357>
   0x0048becf <+319>:   mov-0x38(%rbp),%rax
   0x0048bed3 <+323>:   mov%rax,%rdi
   0x0048bed6 <+326>:   callq  0x407550
<_ZNSt28__atomic_futex_unsigned_base19_M_futex_notify_allEPj@plt>
...
   0x0048bf1c <+396>:   retq   

That xchg is supposed to be std::atomic::store(memory_order_release)
that marks the future as ready.

I have no idea what has regressed.

[Bug tree-optimization/69039] [6 regression] segfault with ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

--- Comment #10 from vries at gcc dot gnu.org ---
Author: vries
Date: Sun Jan 10 09:12:03 2016
New Revision: 232196

URL: https://gcc.gnu.org/viewcvs?rev=232196=gcc=rev
Log:
Only allow single exit phi for reduction in try_create_reduction_list

2016-01-10  Tom de Vries  

PR tree-optimization/69039
* tree-parloops.c (try_create_reduction_list): Only allow single exit
phi for reduction.

* gcc.dg/autopar/pr69039.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/autopar/pr69039.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-parloops.c

[Bug ipa/68175] g++ 5.2.1 produces broken executables with devirtualization enabled

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-01-10
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jan Hubicka  ---
This testcase works for me on Debian both on mainline and g++ (GCC) 5.2.1
20151127

I fixed a similar bug so this may have been fixed by Richards backport:
2015-11-18  Richard Biener   

Backport from mainline  
2015-11-07  Jan Hubicka     

PR ipa/68057
PR ipa/68220
* ipa-polymorphic-call.c
(ipa_polymorphic_call_context::restrict_to_inner_type): Fix ordering
issue when offset is out of range.  
(contains_type_p): Fix out of range check, clear dynamic flag.  

2015-10-23  Jan Hubicka     

PR ipa/pr67600  
* ipa-polymorphic-call.c
(ipa_polymorphic_call_context::get_dynamic_type): Do not confuse
instance offset with offset of outer type.  

2015-10-12  Richard Biener   

PR ipa/67783
* ipa-inline-analysis.c (estimate_function_body_sizes): Re-add  
code that analyzes IVs on each stmt but in a cheaper way avoiding   
quadratic behavior. 

2015-10-11  Jan Hubicka     

PR ipa/67056
* ipa-polymorphic-call.c (possible_placement_new): If cur_offset
is negative we don't know the type. 
(check_stmt_for_type_change): Skip constructors of non-polymorphic  
types as those won't help devirutalization. 

2015-08-11  Manuel López-Ibáñez   

PR c/66098  
PR c/66711  
* diagnostic.c (diagnostic_classify_diagnostic): Take -Werror into  
account when deciding what was the command-line status. 

 Can you please re-test if it works with recent mainline and MingW?

[Bug c++/69216] New: posix_memalign

[snino64 at yahoo dot es]

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

Bug ID: 69216
   Summary: posix_memalign
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: snino64 at yahoo dot es
  Target Milestone: ---

SugarR: https://github.com/Zerbinati/SugarR

The file opt.cpp

/*
  SugaR, a UCI chess playing engine derived from Stockfish
  Copyright (C) 2008-2015 Marco Costalba, Joona Kiiski, Tord Romstad

  SugaR is free software: you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation, either version 3 of the License, or
  (at your option) any later version.

  SugaR is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  GNU General Public License for more details.

  You should have received a copy of the GNU General Public License
  along with this program.  If not, see .
*/

#include 
// Benigno
#include 
//

#include "thread.h"
#include "tt.h"

using namespace std;

#define TRUE 1
#define FALSE 0

int large_use;
int MemError;

#ifndef _WIN32 // Linux 
#include 
#include 
// Benigno
#define MEMALIGN(a, b, c) posix_memalign ((void**) &(a), b, c)
#define ALIGNED_FREE(x) free (x);

static int num;

void SETUP_PRIVILEGES(){}

void CREATE_MEM(void** A,int align,uint64_t size)
{
large_use=FALSE;

num=shmget(IPC_PRIVATE,size,IPC_CREAT|SHM_R|SHM_W|SHM_HUGETLB);
if(num==-1)
{
printf("info string LargePages FAILED %llu Mb\n",(unsigned long
long int) size>>20);
MemError = MEMALIGN((*A),align,size);
}
else
{
(*A)=shmat(num,NULL,0x0);
large_use=TRUE;
printf("info string LargePages OK %llu Mb\n",(unsigned long
long int) size>>20);
std::cout<<"info string HUGELTB "<<(size>>20)<>20);
}
}

void FREE_MEM(void* A)
{
if(!A)
return;
if(!large_use)
{
ALIGNED_FREE(A);
return;
}
shmdt(A);
shmctl(num,IPC_RMID,NULL);
large_use=FALSE;
}

#else

#define MEMALIGN(a, b, c) a = _aligned_malloc (c, b) 
#define ALIGNED_FREE(x) _aligned_free (x)
//
void CREATE_MEM(void** A,int align,uint64_t size)
{
large_use=FALSE;
   
(*A)=VirtualAlloc(NULL,size,MEM_LARGE_PAGES|MEM_COMMIT|MEM_RESERVE,PAGE_READWRITE);
if((*A))
{
large_use=TRUE;
printf("info string %llu Mb LargePages\n",(unsigned long long
int) size>>20);
}
else
{
printf("info string %llu Mb(no LargePages)\n",(unsigned long
long int) size>>20);
MEMALIGN((*A),align,size);
}
}

void CREATE_MEM2(void** A,uint64_t size)
{
large_use=FALSE;
   
(*A)=VirtualAlloc(NULL,size,MEM_LARGE_PAGES|MEM_COMMIT|MEM_RESERVE,PAGE_READWRITE);
if((*A))
{
large_use=TRUE;
printf("info string LargePages %llu Mb\n",(unsigned long long
int) size>>20);
}
}

void FREE_MEM(void* A)
{
if(!A)
return;
if(!large_use)
ALIGNED_FREE(A);
else
{
VirtualFree(A,0,MEM_RELEASE);
large_use=FALSE;
}
}

void SETUP_PRIVILEGES()
{
HANDLE TH,PROC;
TOKEN_PRIVILEGES tp;

PROC=GetCurrentProcess();
OpenProcessToken(PROC,TOKEN_ADJUST_PRIVILEGES|TOKEN_QUERY,);
   
LookupPrivilegeValue(NULL,TEXT("SeLockMemoryPrivilege"),[0].Luid);
tp.PrivilegeCount=1;
tp.Privileges[0].Attributes=SE_PRIVILEGE_ENABLED;
AdjustTokenPrivileges(TH,FALSE,,0,NULL,0);
CloseHandle(TH);
}
#endif

I do: make profile-build ARCH=x86-64-modern

g++ -o SugaR benchmark.o bitbase.o bitboard.o book.o endgame.o evaluate.o
main.o material.o misc.o movegen.o movepick.o opt.o pawns.o position.o psqt.o
search.o thread.o timeman.o tt.o uci.o ucioption.o syzygy/tbprobe.o -lgcov
-Wl,--no-as-needed -lpthread -Wall -Wcast-qual -fno-exceptions -fno-rtti
-std=c++11 -fprofile-use -fno-peel-loops -fno-tracer -pedantic -Wextra -Wshadow
-DNDEBUG -O3 -DIS_64BIT -msse -DUSE_BSFQ -msse3 -mpopcnt -DUSE_POPCNT -flto
lto1: internal compiler error: Violación de segmento
0x940bef crash_signal

[Bug tree-optimization/60899] undef reference generated with -fdevirtualize-speculatively

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #13 from Jan Hubicka  ---
I believe this can be closed.

[Bug fortran/69154] [6 Regression] ICE in gfc_trans_where_2, at fortran/trans-stmt.c:5005 on *-linux

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #7 from Thomas Koenig  ---
Fixed on trunk (only affected branch), closing.

[Bug fortran/69154] [6 Regression] ICE in gfc_trans_where_2, at fortran/trans-stmt.c:5005 on *-linux

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Jan 10 13:18:54 2016
New Revision: 232201

URL: https://gcc.gnu.org/viewcvs?rev=232201=gcc=rev
Log:
2016-01-10  Thomas Koenig  

PR fortran/69154
* frontend-passes.c (in_where):  New variable.
(inline_matmul_assign):  Don't try this if we are within
a WHERE statement.
(gfc_code_walker):  Keep track of in_where.

2016-01-10  Thomas Koenig  

PR fortran/69154
* gfortran.dg/inline_matmul_12.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/inline_matmul_12.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/37131] inline matmul for small matrix sizes

[tkoenig at gcc dot gnu.org]

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

Bug 69154 Summary: [6 Regression] ICE in gfc_trans_where_2, at 
fortran/trans-stmt.c:5005 on *-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69154

   What|Removed |Added

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

[Bug target/69179] undocumented darwin attributes "apple_kext_compatibility" and "weak_import"

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-10
 Ever confirmed|0   |1

--- Comment #2 from Iain Sandoe  ---
(In reply to Jack Howarth from comment #1)
> Note that weak_import was added by Geoffrey Keating in...
> 
> https://gcc.gnu.org/ml/gcc-patches/2004-10/msg02441.html
> 
> and tweaked in...
> 
> https://gcc.gnu.org/ml/gcc-patches/2005-01/msg00146.html
> 
> The last time Geoff referenced it in a patch, he claimed it was 'effectively
> deprecated' in gcc...
> 
> https://gcc.gnu.org/ml/gcc-patches/2005-12/msg00378.html
> 
> It might be worth checking with the Apple clang developers to see what their
> current position is on the feature. I would note that
> http://clang.llvm.org/docs/AttributeReference.html has...
> 
> A declaration can be used even when deploying back to a platform version
> prior to when the declaration was introduced. When this happens, the
> declaration is weakly linked, as if the weak_import attribute were added to
> the declaration. A weakly-linked declaration may or may not be present a
> run-time, and a program can determine whether the declaration is present by
> checking whether the address of that declaration is non-NULL.
> 
> in the section describing the availability attribute so I guess they still
> intend to support into the future.

GCC currently treats "weak_import" as a different spelling for "weak" (barring
one additional check for inlined functions made in the "weak" case - which we
should probably add for weak_import).  AFAIU, there is no practical difference
in the meaning of weak_import, c.f. weak.

[Bug c++/67918] -fdevirtualize causes binary to crash with Segmentation Fault (CryptoPP involved)

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  ---
At the moment this seems to be the only open devirt related wrong code bug. 
Does it still reproduce?

[Bug c++/69218] New: File input streams states inconsistency

[dmitigr at gmail dot com]

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

Bug ID: 69218
   Summary: File input streams states inconsistency
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmitigr at gmail dot com
  Target Milestone: ---

Created attachment 37296
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37296=edit
The test case and example text file which doesn't ends with the newline
character.

When EOF reached while reading a text file *which doesn't ends with newline
character* the stream's state becomes "not good" and "eof" but remains "not
fail".

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #10 from Vincent  ---
Additionally, in the snippet:

template 
struct EN: public RE
{
  EN(::std::string){}
  void rp(){}
};

If you replace ::std::string by const char*, the problem disappears.
More generally, essentially any simplification of the code, unrelated to
virtuals, makes the problem disappear.

[Bug c++/69029] [6 Regression] bogus -Wmisleading-indentation warning on one-line loops

[ppalka at gcc dot gnu.org]

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

--- Comment #3 from Patrick Palka  ---
Author: ppalka
Date: Sun Jan 10 16:39:39 2016
New Revision: 232202

URL: https://gcc.gnu.org/viewcvs?rev=232202=gcc=rev
Log:
Fix -Wmisleading indentation false-positive for do-while statement

gcc/c-family/ChangeLog:

PR c++/69029
* c-indentation.c (should_warn_for_misleading_indentation):
Don't warn about do-while statements.

gcc/testsuite/ChangeLog:

PR c++/69029
* c-c++-common/Wisleading-indentation.c: Augment test.


Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-indentation.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Wmisleading-indentation.c

[Bug c++/69218] File input streams states inconsistency

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
This is the correct behaviour required by the C++ standard, your assertion is
incorrect, that is not guaranteed to always be true.

When reading the last word of the file (which in your test is "character") the
compiler keeps reading while there are non-whitespace characters. Because there
are no non-whitespace characters after the word "character" it stops reading
and sets eofbit, but doesn't set failbit because reading succeeded.

If you have a newline at the end then reading the word "character" does not
reach EOF, but on the next time round the loop it fails to read any
non-whitespace characters, so sets failbit.

This is why you should write "while (in >> w)" instead of checking for EOF.

[Bug c++/67918] -fdevirtualize causes binary to crash with Segmentation Fault (CryptoPP involved)

[11throwaway11 at outlook dot com]

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

Nameless <11throwaway11 at outlook dot com> changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Nameless <11throwaway11 at outlook dot com> ---
(In reply to Jan Hubicka from comment #7)
> At the moment this seems to be the only open devirt related wrong code bug. 
> Does it still reproduce?

If by "still" you mean GCC 5.3, then no, it does not. Thanks for the fix!

[Bug ada/69219] New: [5/6 regression] failed to compile nested subprograms with Inline_Always and Intrinsic

[demoonlit at panathenaia dot halfmoon.jp]

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

Bug ID: 69219
   Summary: [5/6 regression] failed to compile nested subprograms
with Inline_Always and Intrinsic
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: demoonlit at panathenaia dot halfmoon.jp
  Target Milestone: ---

Created attachment 37297
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37297=edit
minimal bug triggering source code

gcc-5 and later have generated no machine-code for subprograms having the
combination of Inline_Always and Intrinsic.
However, this pattern causes  error for nested subprograms.

procedure nestedinlinealways is -- outer subprogram

   procedure NI;
   pragma No_Inline (NI);

   procedure IA;
   pragma Convention (Intrinsic, IA);
   pragma Inline_Always (IA);
-- pragma Inline (IA); -- it works fine.

   procedure IA is
   begin
  NI; -- calling other subprogram here is one of the triggers.
   end IA;

   procedure NI is null;

begin
   IA;
end nestedinlinealways;

Please try to compile above code (the attached file):

% gcc -c nestedinlinealways.adb
: In function 'nestedinlinealways.ia':
nestedinlinealways.adb:3:14: error: subprogram 'nestedinlinealways.ni' not
marked Inline_Always
nestedinlinealways.adb:11:4: error: parent subprogram cannot be inlined

It will become to be compiled if I replace pragma Inline_Always to normal
Inline or remove pragma Convention.

[Bug fortran/68241] [meta-bug] Deferred-length character

[pault at gcc dot gnu.org]

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

Bug 67674 Summary: Incorrect result or ICE for deferred-length character 
component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67674

   What|Removed |Added

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

[Bug fortran/68216] [F2003] IO problem with allocatable, deferred character length arrays

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Paul Thomas  ---
Closed on trunk and 5-branch.

Thanks for the report.

Paul

[Bug fortran/68241] [meta-bug] Deferred-length character

[pault at gcc dot gnu.org]

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

Bug 68216 Summary: [F2003] IO problem with allocatable, deferred character 
length arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68216

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/68241] [meta-bug] Deferred-length character

[pault at gcc dot gnu.org]

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

Bug 63932 Summary: posible problem with allocatable character(:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63932

   What|Removed |Added

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

[Bug fortran/63932] posible problem with allocatable character(:)

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #5 from Paul Thomas  ---
Closed on trunk and 5-branch.

Thanks for the report.

Paul

[Bug fortran/66408] deferred-length character & overloaded assignment

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #5 from Paul Thomas  ---
Closed on trunk and 5-branch.

Thanks for the report.

Paul

[Bug fortran/68241] [meta-bug] Deferred-length character

[pault at gcc dot gnu.org]

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

Bug 66408 Summary: deferred-length character & overloaded assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66408

   What|Removed |Added

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

[Bug fortran/45170] [F2003] allocatable character lengths

[pault at gcc dot gnu.org]

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

Bug 50221 Summary: Allocatable string length fails with array assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50221

   What|Removed |Added

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

[Bug fortran/50221] Allocatable string length fails with array assignment

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #9 from Paul Thomas  ---
Closed on trunk and 5-branch.

Thanks for the report.

Paul

[Bug fortran/68241] [meta-bug] Deferred-length character

[pault at gcc dot gnu.org]

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

Bug 50221 Summary: Allocatable string length fails with array assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50221

   What|Removed |Added

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

[Bug fortran/67779] Strange ordering with strings in extended object

[pault at gcc dot gnu.org]

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

--- Comment #26 from Paul Thomas  ---
Author: pault
Date: Sun Jan 10 18:06:43 2016
New Revision: 232203

URL: https://gcc.gnu.org/viewcvs?rev=232203=gcc=rev
Log:
2016-01-10  Paul Thomas  

Backport from mainline.
PR fortran/50221
PR fortran/68216
PR fortran/63932
PR fortran/66408
* trans_array.c (gfc_conv_scalarized_array_ref): Pass the
symbol decl for deferred character length array references.
* trans-stmt.c (gfc_trans_allocate): Keep the string lengths
to update deferred length character string lengths.
* trans-types.c (gfc_get_dtype_rank_type); Use the string
length of deferred character types for the dtype size.
* trans.c (gfc_build_array_ref): For references to deferred
character arrays, use the domain max value, if it is a variable
to set the 'span' and use pointer arithmetic for acces to the
element.
(trans_code): Set gfc_current_locus for diagnostic purposes.

Backport from mainline.
PR fortran/67674
* trans-expr.c (gfc_conv_procedure_call): Do not fix deferred
string lengths of components.

Backport from mainline.
PR fortran/49954
* resolve.c (deferred_op_assign): New function.
(gfc_resolve_code): Call it.
* trans-array.c (concat_str_length): New function.
(gfc_alloc_allocatable_for_assignment): Jump directly to alloc/
realloc blocks for deferred character length arrays because the
string length might change, even if the shape is the same. Call
concat_str_length to obtain the string length for concatenation
since it is needed to compute the lhs string length.
Set the descriptor dtype appropriately for the new string
length.
* trans-expr.c (gfc_trans_assignment_1): Fix the rse string
length for all characters, other than deferred types. For
concatenation operators, push the rse.pre block to the inner
most loop so that the temporary pointer and the assignments
are properly placed.

Backport from mainline.
PR fortran/67779
* trans_array.c (gfc_conv_scalarized_array_ref): Add missing
se->use_offset from condition for calculation of 'base'.

2015-01-10  Paul Thomas  

Backport from mainline.
PR fortran/50221
* gfortran.dg/deferred_character_1.f90: New test.
* gfortran.dg/deferred_character_4.f90: New test for comment
#4 of the PR.

Backport from mainline.
PR fortran/68216
* gfortran.dg/deferred_character_2.f90: New test.

Backport from mainline.
PR fortran/67674
* gfortran.dg/deferred_character_3.f90: New test.

Backport from mainline.
PR fortran/63932
* gfortran.dg/deferred_character_5.f90: New test.

Backport from mainline.
PR fortran/66408
* gfortran.dg/deferred_character_6.f90: New test.

Backport from mainline.
PR fortran/49954
* gfortran.dg/deferred_character_7.f90: New test.

Backport from mainline.
PR fortran/67779
* gfortran.dg/actual_array_offset_1: New test.

Added:
branches/gcc-5-branch/gcc/fortran/ChangeLog-2015
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_1.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_2.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_3.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_4.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_5.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_6.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_7.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/resolve.c
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/fortran/trans-stmt.c
branches/gcc-5-branch/gcc/fortran/trans-types.c
branches/gcc-5-branch/gcc/fortran/trans.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/66408] deferred-length character & overloaded assignment

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
Author: pault
Date: Sun Jan 10 18:06:43 2016
New Revision: 232203

URL: https://gcc.gnu.org/viewcvs?rev=232203=gcc=rev
Log:
2016-01-10  Paul Thomas  

Backport from mainline.
PR fortran/50221
PR fortran/68216
PR fortran/63932
PR fortran/66408
* trans_array.c (gfc_conv_scalarized_array_ref): Pass the
symbol decl for deferred character length array references.
* trans-stmt.c (gfc_trans_allocate): Keep the string lengths
to update deferred length character string lengths.
* trans-types.c (gfc_get_dtype_rank_type); Use the string
length of deferred character types for the dtype size.
* trans.c (gfc_build_array_ref): For references to deferred
character arrays, use the domain max value, if it is a variable
to set the 'span' and use pointer arithmetic for acces to the
element.
(trans_code): Set gfc_current_locus for diagnostic purposes.

Backport from mainline.
PR fortran/67674
* trans-expr.c (gfc_conv_procedure_call): Do not fix deferred
string lengths of components.

Backport from mainline.
PR fortran/49954
* resolve.c (deferred_op_assign): New function.
(gfc_resolve_code): Call it.
* trans-array.c (concat_str_length): New function.
(gfc_alloc_allocatable_for_assignment): Jump directly to alloc/
realloc blocks for deferred character length arrays because the
string length might change, even if the shape is the same. Call
concat_str_length to obtain the string length for concatenation
since it is needed to compute the lhs string length.
Set the descriptor dtype appropriately for the new string
length.
* trans-expr.c (gfc_trans_assignment_1): Fix the rse string
length for all characters, other than deferred types. For
concatenation operators, push the rse.pre block to the inner
most loop so that the temporary pointer and the assignments
are properly placed.

Backport from mainline.
PR fortran/67779
* trans_array.c (gfc_conv_scalarized_array_ref): Add missing
se->use_offset from condition for calculation of 'base'.

2015-01-10  Paul Thomas  

Backport from mainline.
PR fortran/50221
* gfortran.dg/deferred_character_1.f90: New test.
* gfortran.dg/deferred_character_4.f90: New test for comment
#4 of the PR.

Backport from mainline.
PR fortran/68216
* gfortran.dg/deferred_character_2.f90: New test.

Backport from mainline.
PR fortran/67674
* gfortran.dg/deferred_character_3.f90: New test.

Backport from mainline.
PR fortran/63932
* gfortran.dg/deferred_character_5.f90: New test.

Backport from mainline.
PR fortran/66408
* gfortran.dg/deferred_character_6.f90: New test.

Backport from mainline.
PR fortran/49954
* gfortran.dg/deferred_character_7.f90: New test.

Backport from mainline.
PR fortran/67779
* gfortran.dg/actual_array_offset_1: New test.

Added:
branches/gcc-5-branch/gcc/fortran/ChangeLog-2015
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_1.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_2.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_3.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_4.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_5.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_6.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_7.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/resolve.c
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/fortran/trans-stmt.c
branches/gcc-5-branch/gcc/fortran/trans-types.c
branches/gcc-5-branch/gcc/fortran/trans.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/63932] posible problem with allocatable character(:)

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
Author: pault
Date: Sun Jan 10 18:06:43 2016
New Revision: 232203

URL: https://gcc.gnu.org/viewcvs?rev=232203=gcc=rev
Log:
2016-01-10  Paul Thomas  

Backport from mainline.
PR fortran/50221
PR fortran/68216
PR fortran/63932
PR fortran/66408
* trans_array.c (gfc_conv_scalarized_array_ref): Pass the
symbol decl for deferred character length array references.
* trans-stmt.c (gfc_trans_allocate): Keep the string lengths
to update deferred length character string lengths.
* trans-types.c (gfc_get_dtype_rank_type); Use the string
length of deferred character types for the dtype size.
* trans.c (gfc_build_array_ref): For references to deferred
character arrays, use the domain max value, if it is a variable
to set the 'span' and use pointer arithmetic for acces to the
element.
(trans_code): Set gfc_current_locus for diagnostic purposes.

Backport from mainline.
PR fortran/67674
* trans-expr.c (gfc_conv_procedure_call): Do not fix deferred
string lengths of components.

Backport from mainline.
PR fortran/49954
* resolve.c (deferred_op_assign): New function.
(gfc_resolve_code): Call it.
* trans-array.c (concat_str_length): New function.
(gfc_alloc_allocatable_for_assignment): Jump directly to alloc/
realloc blocks for deferred character length arrays because the
string length might change, even if the shape is the same. Call
concat_str_length to obtain the string length for concatenation
since it is needed to compute the lhs string length.
Set the descriptor dtype appropriately for the new string
length.
* trans-expr.c (gfc_trans_assignment_1): Fix the rse string
length for all characters, other than deferred types. For
concatenation operators, push the rse.pre block to the inner
most loop so that the temporary pointer and the assignments
are properly placed.

Backport from mainline.
PR fortran/67779
* trans_array.c (gfc_conv_scalarized_array_ref): Add missing
se->use_offset from condition for calculation of 'base'.

2015-01-10  Paul Thomas  

Backport from mainline.
PR fortran/50221
* gfortran.dg/deferred_character_1.f90: New test.
* gfortran.dg/deferred_character_4.f90: New test for comment
#4 of the PR.

Backport from mainline.
PR fortran/68216
* gfortran.dg/deferred_character_2.f90: New test.

Backport from mainline.
PR fortran/67674
* gfortran.dg/deferred_character_3.f90: New test.

Backport from mainline.
PR fortran/63932
* gfortran.dg/deferred_character_5.f90: New test.

Backport from mainline.
PR fortran/66408
* gfortran.dg/deferred_character_6.f90: New test.

Backport from mainline.
PR fortran/49954
* gfortran.dg/deferred_character_7.f90: New test.

Backport from mainline.
PR fortran/67779
* gfortran.dg/actual_array_offset_1: New test.

Added:
branches/gcc-5-branch/gcc/fortran/ChangeLog-2015
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_1.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_2.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_3.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_4.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_5.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_6.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_7.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/resolve.c
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/fortran/trans-stmt.c
branches/gcc-5-branch/gcc/fortran/trans-types.c
branches/gcc-5-branch/gcc/fortran/trans.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/49954] ICE assigning concat expression to an array deferred-length string (realloc on assignment)

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  ---
Author: pault
Date: Sun Jan 10 18:06:43 2016
New Revision: 232203

URL: https://gcc.gnu.org/viewcvs?rev=232203=gcc=rev
Log:
2016-01-10  Paul Thomas  

Backport from mainline.
PR fortran/50221
PR fortran/68216
PR fortran/63932
PR fortran/66408
* trans_array.c (gfc_conv_scalarized_array_ref): Pass the
symbol decl for deferred character length array references.
* trans-stmt.c (gfc_trans_allocate): Keep the string lengths
to update deferred length character string lengths.
* trans-types.c (gfc_get_dtype_rank_type); Use the string
length of deferred character types for the dtype size.
* trans.c (gfc_build_array_ref): For references to deferred
character arrays, use the domain max value, if it is a variable
to set the 'span' and use pointer arithmetic for acces to the
element.
(trans_code): Set gfc_current_locus for diagnostic purposes.

Backport from mainline.
PR fortran/67674
* trans-expr.c (gfc_conv_procedure_call): Do not fix deferred
string lengths of components.

Backport from mainline.
PR fortran/49954
* resolve.c (deferred_op_assign): New function.
(gfc_resolve_code): Call it.
* trans-array.c (concat_str_length): New function.
(gfc_alloc_allocatable_for_assignment): Jump directly to alloc/
realloc blocks for deferred character length arrays because the
string length might change, even if the shape is the same. Call
concat_str_length to obtain the string length for concatenation
since it is needed to compute the lhs string length.
Set the descriptor dtype appropriately for the new string
length.
* trans-expr.c (gfc_trans_assignment_1): Fix the rse string
length for all characters, other than deferred types. For
concatenation operators, push the rse.pre block to the inner
most loop so that the temporary pointer and the assignments
are properly placed.

Backport from mainline.
PR fortran/67779
* trans_array.c (gfc_conv_scalarized_array_ref): Add missing
se->use_offset from condition for calculation of 'base'.

2015-01-10  Paul Thomas  

Backport from mainline.
PR fortran/50221
* gfortran.dg/deferred_character_1.f90: New test.
* gfortran.dg/deferred_character_4.f90: New test for comment
#4 of the PR.

Backport from mainline.
PR fortran/68216
* gfortran.dg/deferred_character_2.f90: New test.

Backport from mainline.
PR fortran/67674
* gfortran.dg/deferred_character_3.f90: New test.

Backport from mainline.
PR fortran/63932
* gfortran.dg/deferred_character_5.f90: New test.

Backport from mainline.
PR fortran/66408
* gfortran.dg/deferred_character_6.f90: New test.

Backport from mainline.
PR fortran/49954
* gfortran.dg/deferred_character_7.f90: New test.

Backport from mainline.
PR fortran/67779
* gfortran.dg/actual_array_offset_1: New test.

Added:
branches/gcc-5-branch/gcc/fortran/ChangeLog-2015
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_1.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_2.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_3.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_4.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_5.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_6.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_7.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/resolve.c
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/fortran/trans-stmt.c
branches/gcc-5-branch/gcc/fortran/trans-types.c
branches/gcc-5-branch/gcc/fortran/trans.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/67674] Incorrect result or ICE for deferred-length character component

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
Author: pault
Date: Sun Jan 10 18:06:43 2016
New Revision: 232203

URL: https://gcc.gnu.org/viewcvs?rev=232203=gcc=rev
Log:
2016-01-10  Paul Thomas  

Backport from mainline.
PR fortran/50221
PR fortran/68216
PR fortran/63932
PR fortran/66408
* trans_array.c (gfc_conv_scalarized_array_ref): Pass the
symbol decl for deferred character length array references.
* trans-stmt.c (gfc_trans_allocate): Keep the string lengths
to update deferred length character string lengths.
* trans-types.c (gfc_get_dtype_rank_type); Use the string
length of deferred character types for the dtype size.
* trans.c (gfc_build_array_ref): For references to deferred
character arrays, use the domain max value, if it is a variable
to set the 'span' and use pointer arithmetic for acces to the
element.
(trans_code): Set gfc_current_locus for diagnostic purposes.

Backport from mainline.
PR fortran/67674
* trans-expr.c (gfc_conv_procedure_call): Do not fix deferred
string lengths of components.

Backport from mainline.
PR fortran/49954
* resolve.c (deferred_op_assign): New function.
(gfc_resolve_code): Call it.
* trans-array.c (concat_str_length): New function.
(gfc_alloc_allocatable_for_assignment): Jump directly to alloc/
realloc blocks for deferred character length arrays because the
string length might change, even if the shape is the same. Call
concat_str_length to obtain the string length for concatenation
since it is needed to compute the lhs string length.
Set the descriptor dtype appropriately for the new string
length.
* trans-expr.c (gfc_trans_assignment_1): Fix the rse string
length for all characters, other than deferred types. For
concatenation operators, push the rse.pre block to the inner
most loop so that the temporary pointer and the assignments
are properly placed.

Backport from mainline.
PR fortran/67779
* trans_array.c (gfc_conv_scalarized_array_ref): Add missing
se->use_offset from condition for calculation of 'base'.

2015-01-10  Paul Thomas  

Backport from mainline.
PR fortran/50221
* gfortran.dg/deferred_character_1.f90: New test.
* gfortran.dg/deferred_character_4.f90: New test for comment
#4 of the PR.

Backport from mainline.
PR fortran/68216
* gfortran.dg/deferred_character_2.f90: New test.

Backport from mainline.
PR fortran/67674
* gfortran.dg/deferred_character_3.f90: New test.

Backport from mainline.
PR fortran/63932
* gfortran.dg/deferred_character_5.f90: New test.

Backport from mainline.
PR fortran/66408
* gfortran.dg/deferred_character_6.f90: New test.

Backport from mainline.
PR fortran/49954
* gfortran.dg/deferred_character_7.f90: New test.

Backport from mainline.
PR fortran/67779
* gfortran.dg/actual_array_offset_1: New test.

Added:
branches/gcc-5-branch/gcc/fortran/ChangeLog-2015
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_1.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_2.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_3.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_4.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_5.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_6.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_7.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/resolve.c
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/fortran/trans-stmt.c
branches/gcc-5-branch/gcc/fortran/trans-types.c
branches/gcc-5-branch/gcc/fortran/trans.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/50221] Allocatable string length fails with array assignment

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas  ---
Author: pault
Date: Sun Jan 10 18:06:43 2016
New Revision: 232203

URL: https://gcc.gnu.org/viewcvs?rev=232203=gcc=rev
Log:
2016-01-10  Paul Thomas  

Backport from mainline.
PR fortran/50221
PR fortran/68216
PR fortran/63932
PR fortran/66408
* trans_array.c (gfc_conv_scalarized_array_ref): Pass the
symbol decl for deferred character length array references.
* trans-stmt.c (gfc_trans_allocate): Keep the string lengths
to update deferred length character string lengths.
* trans-types.c (gfc_get_dtype_rank_type); Use the string
length of deferred character types for the dtype size.
* trans.c (gfc_build_array_ref): For references to deferred
character arrays, use the domain max value, if it is a variable
to set the 'span' and use pointer arithmetic for acces to the
element.
(trans_code): Set gfc_current_locus for diagnostic purposes.

Backport from mainline.
PR fortran/67674
* trans-expr.c (gfc_conv_procedure_call): Do not fix deferred
string lengths of components.

Backport from mainline.
PR fortran/49954
* resolve.c (deferred_op_assign): New function.
(gfc_resolve_code): Call it.
* trans-array.c (concat_str_length): New function.
(gfc_alloc_allocatable_for_assignment): Jump directly to alloc/
realloc blocks for deferred character length arrays because the
string length might change, even if the shape is the same. Call
concat_str_length to obtain the string length for concatenation
since it is needed to compute the lhs string length.
Set the descriptor dtype appropriately for the new string
length.
* trans-expr.c (gfc_trans_assignment_1): Fix the rse string
length for all characters, other than deferred types. For
concatenation operators, push the rse.pre block to the inner
most loop so that the temporary pointer and the assignments
are properly placed.

Backport from mainline.
PR fortran/67779
* trans_array.c (gfc_conv_scalarized_array_ref): Add missing
se->use_offset from condition for calculation of 'base'.

2015-01-10  Paul Thomas  

Backport from mainline.
PR fortran/50221
* gfortran.dg/deferred_character_1.f90: New test.
* gfortran.dg/deferred_character_4.f90: New test for comment
#4 of the PR.

Backport from mainline.
PR fortran/68216
* gfortran.dg/deferred_character_2.f90: New test.

Backport from mainline.
PR fortran/67674
* gfortran.dg/deferred_character_3.f90: New test.

Backport from mainline.
PR fortran/63932
* gfortran.dg/deferred_character_5.f90: New test.

Backport from mainline.
PR fortran/66408
* gfortran.dg/deferred_character_6.f90: New test.

Backport from mainline.
PR fortran/49954
* gfortran.dg/deferred_character_7.f90: New test.

Backport from mainline.
PR fortran/67779
* gfortran.dg/actual_array_offset_1: New test.

Added:
branches/gcc-5-branch/gcc/fortran/ChangeLog-2015
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_1.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_2.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_3.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_4.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_5.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_6.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_7.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/resolve.c
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/fortran/trans-stmt.c
branches/gcc-5-branch/gcc/fortran/trans-types.c
branches/gcc-5-branch/gcc/fortran/trans.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #9 from Vincent  ---
To my knowledge that virtual function is duly defined:

template 
struct AN: public RE
{
  void rp(){}
};

[Bug c++/69029] [6 Regression] bogus -Wmisleading-indentation warning on one-line loops

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #4 from Markus Trippelsdorf  ---
Fixed. Thanks.

[Bug fortran/45170] [F2003] allocatable character lengths

[pault at gcc dot gnu.org]

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

Bug 49954 Summary: ICE assigning concat expression to an array deferred-length 
string (realloc on assignment)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49954

   What|Removed |Added

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

[Bug fortran/68241] [meta-bug] Deferred-length character

[pault at gcc dot gnu.org]

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

Bug 49954 Summary: ICE assigning concat expression to an array deferred-length 
string (realloc on assignment)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49954

   What|Removed |Added

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

[Bug fortran/49954] ICE assigning concat expression to an array deferred-length string (realloc on assignment)

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #7 from Paul Thomas  ---
Fixed on trunk and 5-branch.

Thanks for the report.

Paul

[Bug fortran/67674] Incorrect result or ICE for deferred-length character component

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||pault at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Paul Thomas  ---
Closed on trunk and 5-branch.

Thanks for the report.

Paul

[Bug c++/69218] File input streams states inconsistency

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Comment on attachment 37296
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37296
The test case and example text file which doesn't ends with the newline
character.

N.B. it's not useful to upload a tar file containing two tiny files, just
attach the files directly, or paste them straight in.

// When EOF reached while reading a text file _which doesn't ends
// with newline character_ the stream's state becomes
// "not good" and "eof" but remains "not fail".

#include 
#include 
#include 
#include 

int main(int argc, char *argv[])
{
  // The file must not terminates with the newline character.
  const char* file = "test.txt";
  std::ifstream in(file);
  if (!in) {
std::cerr << "Could not work with file " << file << std::endl;
return 1;
  }

  while (in) {
std::string w;
in >> w;
std::cerr << "Fail: " << in.fail()
  << "   Good: " << in.good()
  << "   EOF: " << in.eof()
  << std::endl;
// Assertion failed if the file doesn't ends with newline character.
assert(!in.fail() == in.good());
  }

  return 0;
}

[Bug ipa/68175] g++ 5.2.1 produces broken executables with devirtualization enabled

[bnagaev at gmail dot com]

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

Boris Nagaev  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Boris Nagaev  ---
It is fixed in Debian Stretch, gcc 5.3.1 20160101 (Debian 5.3.1-5).
It is fixed in MinGW 5.3.0.

[Bug c++/69205] Place a variadic template in front of function parameter when it is known

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|major   |normal

[Bug middle-end/69217] ICE at var-tracking.c:5038 Segmentation fault

[ibuclaw at gdcproject dot org]

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

--- Comment #1 from Iain Buclaw  ---
I should also note that this only ever triggers using both: -O2 -g

[Bug fortran/68216] [F2003] IO problem with allocatable, deferred character length arrays

[pault at gcc dot gnu.org]

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

--- Comment #10 from Paul Thomas  ---
Author: pault
Date: Sun Jan 10 18:06:43 2016
New Revision: 232203

URL: https://gcc.gnu.org/viewcvs?rev=232203=gcc=rev
Log:
2016-01-10  Paul Thomas  

Backport from mainline.
PR fortran/50221
PR fortran/68216
PR fortran/63932
PR fortran/66408
* trans_array.c (gfc_conv_scalarized_array_ref): Pass the
symbol decl for deferred character length array references.
* trans-stmt.c (gfc_trans_allocate): Keep the string lengths
to update deferred length character string lengths.
* trans-types.c (gfc_get_dtype_rank_type); Use the string
length of deferred character types for the dtype size.
* trans.c (gfc_build_array_ref): For references to deferred
character arrays, use the domain max value, if it is a variable
to set the 'span' and use pointer arithmetic for acces to the
element.
(trans_code): Set gfc_current_locus for diagnostic purposes.

Backport from mainline.
PR fortran/67674
* trans-expr.c (gfc_conv_procedure_call): Do not fix deferred
string lengths of components.

Backport from mainline.
PR fortran/49954
* resolve.c (deferred_op_assign): New function.
(gfc_resolve_code): Call it.
* trans-array.c (concat_str_length): New function.
(gfc_alloc_allocatable_for_assignment): Jump directly to alloc/
realloc blocks for deferred character length arrays because the
string length might change, even if the shape is the same. Call
concat_str_length to obtain the string length for concatenation
since it is needed to compute the lhs string length.
Set the descriptor dtype appropriately for the new string
length.
* trans-expr.c (gfc_trans_assignment_1): Fix the rse string
length for all characters, other than deferred types. For
concatenation operators, push the rse.pre block to the inner
most loop so that the temporary pointer and the assignments
are properly placed.

Backport from mainline.
PR fortran/67779
* trans_array.c (gfc_conv_scalarized_array_ref): Add missing
se->use_offset from condition for calculation of 'base'.

2015-01-10  Paul Thomas  

Backport from mainline.
PR fortran/50221
* gfortran.dg/deferred_character_1.f90: New test.
* gfortran.dg/deferred_character_4.f90: New test for comment
#4 of the PR.

Backport from mainline.
PR fortran/68216
* gfortran.dg/deferred_character_2.f90: New test.

Backport from mainline.
PR fortran/67674
* gfortran.dg/deferred_character_3.f90: New test.

Backport from mainline.
PR fortran/63932
* gfortran.dg/deferred_character_5.f90: New test.

Backport from mainline.
PR fortran/66408
* gfortran.dg/deferred_character_6.f90: New test.

Backport from mainline.
PR fortran/49954
* gfortran.dg/deferred_character_7.f90: New test.

Backport from mainline.
PR fortran/67779
* gfortran.dg/actual_array_offset_1: New test.

Added:
branches/gcc-5-branch/gcc/fortran/ChangeLog-2015
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_1.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_2.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_3.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_4.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_5.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_6.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_7.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/resolve.c
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/fortran/trans-stmt.c
branches/gcc-5-branch/gcc/fortran/trans-types.c
branches/gcc-5-branch/gcc/fortran/trans.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/66461] [4.9/5/6 Regression] ICE on missing end program in fixed source

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  ---
Hiesenbug. Steves fix, probably on BSD, does not work on linux. Some of my
attempts work when running within the debugger, but do not work outside the
debugger. I have traced through the scanner with and without the END statement
and see nothing yet.

We might try a regression hunt to see where it broke to get a hint. One thing I
have not checked yet is in fixed form we skip past the first characters of each
line.  We may need to trap an EOF when we are doing that skipping.

[Bug fortran/66461] [4.9/5/6 Regression] ICE on missing end program in fixed source

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #7 from Joost VandeVondele  
---
(In reply to Jerry DeLisle from comment #6)
> Hiesenbug. Steves fix, probably on BSD, does not work on linux. Some of my
> attempts work when running within the debugger, but do not work outside the
> debugger. I have traced through the scanner with and without the END
> statement and see nothing yet.
> 
> We might try a regression hunt to see where it broke to get a hint. One
> thing I have not checked yet is in fixed form we skip past the first
> characters of each line.  We may need to trap an EOF when we are doing that
> skipping.

This might be obvious, but valgrind might give a hint ? :

-linux-gnu/6.0.0/finclude -o /tmp/ccyEi6l3.s
==20860== 
==20860== Invalid read of size 4
==20860==at 0x5DF7C1: free_expr0(gfc_expr*) (expr.c:431)
==20860==by 0x5DF9BD: gfc_free_expr(gfc_expr*) (expr.c:513)
==20860==by 0x60FE57: gfc_match_if(gfc_statement*) (match.c:1441)
==20860==by 0x62BF91: decode_statement (parse.c:398)
==20860==by 0x62BF91: decode_statement() (parse.c:293)
==20860==by 0x62D434: next_free (parse.c:1076)
==20860==by 0x62D434: next_statement() (parse.c:1310)
==20860==by 0x62F4D4: parse_executable(gfc_statement) (parse.c:4792)
==20860==by 0x630311: parse_progunit(gfc_statement) (parse.c:5215)
==20860==by 0x6316C0: gfc_parse_file() (parse.c:5698)
==20860==by 0x6745A2: gfc_be_parse_file() (f95-lang.c:201)
==20860==by 0xB64FD2: compile_file() (toplev.c:464)
==20860==by 0xB6706B: do_compile (toplev.c:1985)
==20860==by 0xB6706B: toplev::main(int, char**) (toplev.c:2092)
==20860==by 0x1354346: main (main.c:39)
==20860==  Address 0x4dc1b50 is 0 bytes inside a block of size 192 free'd
==20860==at 0x4A06D9B: free (vg_replace_malloc.c:530)
==20860==by 0x60FE12: gfc_match_if(gfc_statement*) (match.c:1425)
==20860==by 0x62BF91: decode_statement (parse.c:398)
==20860==by 0x62BF91: decode_statement() (parse.c:293)
==20860==by 0x62D434: next_free (parse.c:1076)
==20860==by 0x62D434: next_statement() (parse.c:1310)
==20860==by 0x62F4D4: parse_executable(gfc_statement) (parse.c:4792)
==20860==by 0x630311: parse_progunit(gfc_statement) (parse.c:5215)
==20860==by 0x6316C0: gfc_parse_file() (parse.c:5698)
==20860==by 0x6745A2: gfc_be_parse_file() (f95-lang.c:201)
==20860==by 0xB64FD2: compile_file() (toplev.c:464)
==20860==by 0xB6706B: do_compile (toplev.c:1985)
==20860==by 0xB6706B: toplev::main(int, char**) (toplev.c:2092)
==20860==by 0x1354346: main (main.c:39)
==20860==  Block was alloc'd at
==20860==at 0x4A07B05: calloc (vg_replace_malloc.c:711)
==20860==by 0x13C2368: xcalloc (xmalloc.c:163)
==20860==by 0x5DF29F: gfc_get_expr() (expr.c:48)
==20860==by 0x5DF397: gfc_get_operator_expr(locus*, gfc_intrinsic_op,
gfc_expr*, gfc_expr*) (expr.c:106)
==20860==by 0x5B1090: eval_intrinsic(gfc_intrinsic_op, eval_f, gfc_expr*,
gfc_expr*) (arith.c:1611)
==20860==by 0x5B1440: eval_intrinsic_f3 (arith.c:1725)
==20860==by 0x5B1440: eval_intrinsic_f3(gfc_intrinsic_op, arith
(*)(gfc_expr*, gfc_expr*, gfc_expr**), gfc_expr*, gfc_expr*) (arith.c:1713)
==20860==by 0x6131B2: match_equiv_operand(gfc_expr**) (matchexp.c:784)
==20860==by 0x613276: match_level_5(gfc_expr**) (matchexp.c:811)
==20860==by 0x612572: gfc_match_expr(gfc_expr**) (matchexp.c:870)
==20860==by 0x60B870: gfc_match(char const*, ...) (match.c:1015)
==20860==by 0x60FCC7: gfc_match_if(gfc_statement*) (match.c:1347)
==20860==by 0x62BF91: decode_statement (parse.c:398)
==20860==by 0x62BF91: decode_statement() (parse.c:293)

[Bug fortran/66461] [4.9/5/6 Regression] ICE on missing end program in fixed source

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
(In reply to Joost VandeVondele from comment #7)
> (In reply to Jerry DeLisle from comment #6)
> > Hiesenbug. Steves fix, probably on BSD, does not work on linux. Some of my
> > attempts work when running within the debugger, but do not work outside the
> > debugger. I have traced through the scanner with and without the END
> > statement and see nothing yet.
> > 
> > We might try a regression hunt to see where it broke to get a hint. One
> > thing I have not checked yet is in fixed form we skip past the first
> > characters of each line.  We may need to trap an EOF when we are doing that
> > skipping.
> 
> This might be obvious, but valgrind might give a hint ? :
> 
> -linux-gnu/6.0.0/finclude -o /tmp/ccyEi6l3.s
> ==20860== 
> ==20860== Invalid read of size 4
> ==20860==at 0x5DF7C1: free_expr0(gfc_expr*) (expr.c:431)
> ==20860==by 0x5DF9BD: gfc_free_expr(gfc_expr*) (expr.c:513)
> ==20860==by 0x60FE57: gfc_match_if(gfc_statement*) (match.c:1441)
 Yes we know it is near here. I am suspecting that we have actually matched the
good if statement and have gone down again in the next_statement with premature
file end.  The gfc_match_if calls gfc_match which calls many matchers and expr
is coming back junk.  The bugger is why it depends on fixed form, thus my
comment above.

[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1

[iains at gcc dot gnu.org]

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

--- Comment #22 from Iain Sandoe  ---
OK, So this has been biting me some more.

It might be another case where Darwin has thrown up a more general problem.

What's happening is that, where functions are ending up zero-sized, an FDE is
still being emitted.

we get for DWARF FDE,
  .globl foo
foo:
LFBxxx
LFExxx

and for .cfi_

  .globl foo
foo:
LFBxxx
   .cfi_startproc
   .cfi_endproc
LFExxx

... both produce FDEs with 0 PC ranges.

This upsets ld64.

1. GCC - it seems a waste of binary file space to emit FDEs with 0 PC range,
since they can neither be the site of an exception, nor can they participate in
unwinding; however, it might be rather intrusive for the current phase to fix
that - if it's not causing any other port problems.
 * I haven't thought about it much harder than that - any reason anyone can see
for wanting to emit an FDE with 0 PC range?

2. ld64 - should, perhaps, be more defensive, and discard 0-length FDEs when
pulling in object files.  I've patched my version to do this and testing - will
post a revised version when it's done.

Meanwhile, are there any other thoughts from folks on the best way forward?

[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1

[mrs at gcc dot gnu.org]

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

--- Comment #23 from mrs at gcc dot gnu.org  ---
On the platform, external symbols are defined to be 1 or more bytes.  0 is not
one or more.  Once that is fixed, then the problem goes away.  If you want to
have Apple update their abi for future systems to include zero byte objects,
you will have to ask them to change their abi.

[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1

[iains at gcc dot gnu.org]

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

--- Comment #24 from Iain Sandoe  ---
(In reply to m...@gcc.gnu.org from comment #23)
> On the platform, external symbols are defined to be 1 or more bytes.  0 is
> not one or more.  Once that is fixed, then the problem goes away.  If you
> want to have Apple update their abi for future systems to include zero byte
> objects, you will have to ask them to change their abi.

Well, I'm very aware of the constraint that has been applied our output to date
(having implemented some of the "fixes" for it).  However, it was my
understanding that the constraint was one of the tools; I.E. ld64's ability to
determine an unambiguous 'atom'.  I can't find anything in the written ABI or
assembler documentation that makes such a statement (although we accept that
"what the other tools do" is the effective ABI).

It appears that (recently) ld64 [and the assembler] have been modified to
support symbol aliases.  Thus the constraint you mention has been
amended/modified; newer versions of ld64 are not complaining about the 0-sized
functions (or co-incident symbols), only the 0-sized FDE.

It would be quite a useful step forward to support symbol aliases - since the
absence has been a source of difficulty for us - but let's not get side-tracked
from the actual problem.



1. FWIW There is code in i386.c [12410 - 12438] that is supposed to ensure that
functions on Darwin contain at least a NOP.  However, it clearly isn't working
in these cases.



2. The issue of whether Darwin can have 0-sized functions is actually a
separate one from whether GCC should emit FDEs for 0-sized functions (since
other platforms can clearly support them).

[Bug c/69221] New: gcc on m68k miscompiles function type casts

[slyfox at inbox dot ru]

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

Bug ID: 69221
   Summary: gcc on m68k miscompiles function type casts
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
  Target Milestone: ---

Created attachment 37298
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37298=edit
sample with broken ABI

This came up as a miscompilation of GHC:
https://ghc.haskell.org/trac/ghc/ticket/11395

Consider the following small snippet:

/* needed to introduce a symbol */
extern void* f(); /* real prototype is 'int f(void);' */

int g(void)
{
/* cast a symbol to known function type, returns 'int' */
return 1 + ((int (*)(void))f)();
}

/* somewhere in other translation unit */
int __f (void)
{
return 42;
}

/* just for comparison */
void * __vf (void)
{
return (void*)42;
}

$ m68k-unknown-linux-gnu-gcc -O2 -S demo1.c -fomit-frame-pointer
[ Also issues a warning:
  warning: function called through a non-compatible type
 return 1 + ((int (*)(void))f)();
^
]

generates the following assembly:

g:
jsr f
move.l %a0,%d0 ; 'g' kills register 'd0', resould of called would-be
'f'
addq.l #1,%d0
rts

__f:
moveq #42,%d0
rts

__vf:
move.w #42,%a0
moveq #42,%d0
rts

The idea here is 
extern void* f();
line brings a .text symbol of yet unknown propotype.

Later *at .c file generation time) we get information about
symbol 'f' and cast it to known type:
((int (*)(void))f)();

But caller does not expect result to present in 'd0' data register, expects
'a0' address register.

[a note: GHC used to introduce unknown symbols in scope as
extern void* f(void);
but that broke on PPC64 ELFv2 and we changed to less precise
extern void* f();
]

Looks like GCC bug to ignore actual 'int (*)(void)' ABI of a symbol at call
site.

[Bug fortran/68829] [4.9/5/6 Regression] Segfaults with -Ofast due to large array on stack

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #4 from Joost VandeVondele  
---
(In reply to Thomas Koenig from comment #3)
> 
> It seems that -fmax-stack-var-size=N does not override -Ofast.  Maybe
> it should.
> 

Ah interesting, I wasn't aware that '-fmax-stack-var-size' existed, but indeed,
if -fstack-arrays would honour that flag, this problem would be fixed. That
would be a good solution from my point of view.

[Bug middle-end/69217] ICE at var-tracking.c:5038 Segmentation fault

[ibuclaw at gdcproject dot org]

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

--- Comment #3 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #2)
> Fixed the first case, and now there is a second.
> 

Triggers using -O2 -g -fno-inline

[Bug middle-end/69217] ICE at var-tracking.c:5038 Segmentation fault

[ibuclaw at gdcproject dot org]

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

--- Comment #2 from Iain Buclaw  ---
Fixed the first case, and now there is a second.

Again, can't reproduce using equivalent C++ with g++. This time however I have
no idea why, as both look like they produce identical codegen on the surface. 
One key difference in data types is that SArray is a built-in type S[] in D. 
But otherwise ABI should be identical.

---
struct S
{
};

struct SArray
{
  size_t length;
  void* ptr;
};

void formattedWrite (SArray, S)
{
  void (*funs)(S) = 0;
  funs (S ());
}

int format (SArray fmt, S args)
{
  formattedWrite (fmt, args);
  return 1;
}
---

bug.d: In function ‘format’:
bug.d:15:1: internal compiler error: Segmentation fault
0xbc7186 crash_signal
../../dev/gcc/toplev.c:334
0xe954c8 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../dev/gcc/tree.h:3111
0xe954c8 tracked_record_parameter_p
../../dev/gcc/var-tracking.c:5038
0xe9a4ac add_stores
../../dev/gcc/var-tracking.c:5954
0xe961e7 add_with_sets
../../dev/gcc/var-tracking.c:6495
0x80e957 cselib_record_sets
../../dev/gcc/cselib.c:2562
0x810161 cselib_process_insn(rtx_insn*)
../../dev/gcc/cselib.c:2674
0xea5d63 vt_initialize
../../dev/gcc/var-tracking.c:10037
0xeab2e6 variable_tracking_main_1
../../dev/gcc/var-tracking.c:10234
0xeab2e6 variable_tracking_main()
../../dev/gcc/var-tracking.c:10287
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/69220] New: Internal error with array of negative size and initializers for it

[j2108665 at trbvm dot com]

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

Bug ID: 69220
   Summary: Internal error with array of negative size and
initializers for it
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: j2108665 at trbvm dot com
  Target Milestone: ---

GCC seems to loop infinitely when this code is given:

int main() 
{
   int* p = new int[-1]{1}; 
}

Limiting its CPU time produces an internal compiler error. Notice that with an
empty braced-init-list (so without the '1'), compilation succeeds. 

Compiled with:
$ g++ -std=c++11 test.cpp

[Bug c/69221] gcc on m68k miscompiles function type casts

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

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
The declaration of f isn't compatible with its defintion.  A cast doesn't
change that fact.

[Bug c/69221] gcc on m68k miscompiles function type casts

[slyfox at inbox dot ru]

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

--- Comment #2 from Sergei Trofimovich  ---
(In reply to Andreas Schwab from comment #1)
> The declaration of f isn't compatible with its defintion.  A cast doesn't
> change that fact.

Correct. But is it relevant here? Cast is the only real thing gcc sees.
'void * f();' is an incomplete declaration.

Is there a way to introduce a symbol without any declaration so cast would be
only source of ABI information?

If I change 'int' to 'float' in original sample it will be compiled correctly.
// was return 1 + ((int (*)(void))f)();
return 1 + (int)((float (*)(void))f)();
GCC won't try to cast from %a0 but will pick %fp0:

g:
jsr f
fintrz.x %fp0,%fp0
fmove.l %fp0,%d0
addq.l #1,%d0
rts


I suspect gcc actually knows it can use 'int' / 'void*' interchangeaby. But on
m68k it's not true.

[Bug c++/68245] FAIL: c-c++-common/gomp/clauses-2.c -std=c++98 (internal compiler error)

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
ICE doesn't occur if arguments p, q and t are copied.