[Bug target/68214] New: gcc.dg/cwsc1.c fails on arm-none-eabi

[sandra at gcc dot gnu.org]

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

Bug ID: 68214
   Summary: gcc.dg/cwsc1.c fails on arm-none-eabi
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

Created attachment 36651
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36651=edit
cwsc1.s

The testcase gcc.dg/cwsc1.c seems to assume that register "ip" is always
reserved for the static chain pointer on ARM, but it's being re-used as a
temporary to hold the value of the variable "ptr" prior to calling it:

arm-none-eabi-gcc src/gcc-mainline/gcc/testsuite/gcc.dg/cwsc1.c -S -O

produces:

main:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
stmfd   sp!, {r4, lr}
sub sp, sp, #8
add r4, sp, #7
mov ip, r4
ldr r3, .L6
ldr ip, [r3]
mov lr, pc
bx  ip
cmp r4, r0
bne .L5

Invalid testcase or bug in the ARM backend?

[Bug fortran/63331] Fortran -fcompare-debug issues

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #4 from Dominique d'Humieres  ---
> Untested patch to fix (or work around) all but the last 2 FAILs.

Is this patch committed as revision r215516? Setting GCC_COMPARE_DEBUG=1, I see

FAIL: gfortran.dg/iso_c_binding_compiler_1.f90   -O  (test for excess errors)
FAIL: gfortran.dg/iso_c_binding_compiler_3.f90   -O  (test for excess errors)

at r229727. Is this OK. Any reason to keep this PR opened?

[Bug c++/68195] gcc//ld produces invalid ABI results (cxx11 problem?)

[dushistov at mail dot ru]

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

--- Comment #3 from Evgeniy Dushistov  ---
I build gcc with last commit:
commit 06d6724083a2cb1f35e36f4a0db3025bfde20667
Author: nathan <nathan@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Wed Nov 4 17:01:23 2015 +

* libgomp.oacc-c-c++-common/loop-red-g-1.c: New.
* libgomp.oacc-c-c++-common/loop-red-gwv-1.c: New.
* libgomp.oacc-c-c++-common/loop-red-v-1.c: New.
* libgomp.oacc-c-c++-common/loop-red-v-2.c: New.
* libgomp.oacc-c-c++-common/loop-red-w-1.c: New.
* libgomp.oacc-c-c++-common/loop-red-w-2.c: New.
* libgomp.oacc-c-c++-common/loop-red-wv-1.c: New.
* libgomp.oacc-fortran/reduction-5.f90: Avoid reference var.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@229770
138bc75d-0d04-0410-961f-82ee72b054a4

$/home/evgeniy/local/bin/g++ --version | head -n 1
g++ (GCC) 6.0.0 20151104 (experimental)

$ LANG=C make
/home/evgeniy/local/bin/g++ -std=c++03 -g3 -shared -fPIC -o libmyLib.so Lib.cpp
-O2
/home/evgeniy/local/bin/g++ -std=c++11 -g3 main.cpp -o main -L. -l myLib
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/evgeniy/local/lib64:./ ./main
Makefile:7: recipe for target 'test1' failed
make: *** [test1] Segmentation fault

So the bug should be in trunk also, linux/amd64

[Bug c++/68209] C++11 code compiled without -std=c++11 but doesn't work as expected

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #4 from Marc Glisse  ---
(Oups, pressed return by mistake)
Yes it is QoI, but we could still do better.

(the -Wall warning is a better sign that something is going wrong:
x.cc:8:22: warning: 'aa' may be used uninitialized in this function
[-Wmaybe-uninitialized]
  cout << aa << endl;
  ^
)

[Bug c++/68213] New: Exception handling corrupts a VLA in MinGW

[hedayat.fwd at gmail dot com]

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

Bug ID: 68213
   Summary: Exception handling corrupts a VLA in MinGW
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hedayat.fwd at gmail dot com
  Target Milestone: ---

Code:
-
#include 
#include 
#include 
#include 

using namespace std;

int main(int argc, char **argv)
{
int n;
stringstream ss(argv[1]);
ss >> n;
cout << "N: " << n << endl;
char tbuff[n];
try
{
memset(tbuff, 0, n);
throw runtime_error("ERR");
}
catch (exception )
{
cout << "Writing to VLA" << endl;
memset(tbuff, 0, n);
cout << "Wrote" << endl;
}
}
-

Compiled with: 
/usr/bin/i686-w64-mingw32-g++ -O2  test.cpp -o t

Run with wine (similar results under Windows) results in crash:
[]% ./t 100 
fixme:winediag:start_process Wine Staging is a testing version containing
experimental patches.
fixme:winediag:start_process Please report bugs at http://bugs.wine-staging.com
(instead of winehq.org).
N: 100
Writing to VLA
wine: Unhandled page fault on read access to 0x at address (nil)
(thread 0009), starting debugger...
Unhandled exception: page fault on read access to 0x in 32-bit code
(0x).

[Bug c++/68209] C++11 code compiled without -std=c++11 but doesn't work as expected

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||diagnostic, wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-04
 Ever confirmed|0   |1

[Bug fortran/63327] Poor caret location in error mesage

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
See also pr54224 comment 22 for other examples: Manuel López-Ibáñez wrote

> You will get a more precise column info (and better location for '^')
> if Fortran gives a more precise DECL_SOURCE_LOCATION() when generating
> this tree.

May be related to 29819.

[Bug c++/68209] C++11 code compiled without -std=c++11 but doesn't work as expected

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #3 from Daniel Krügler  ---
> What is the reason why it compiled on C++98?
> I expect that it is incorrect
> syntax for C++98 and code doesn't match language grammatics. So expected
> behavior is "compilation error".

There is no requirement for your expected behaviour. The standard only requires
a diagnostics in such a case, see [intro.compliance] p2:

If a program contains a violation of any diagnosable rule or an occurrence of a
construct described in this Standard as “conditionally-supported” when the
implementation does not support that construct, a conforming implementation
shall issue at least one diagnostic message.

This diagnostics is produced. I'd like to point out that clang behaves
similarly (albeit this is not really relevant when we talk about the
correctness).

[Bug c++/68195] gcc//ld produces invalid ABI results (cxx11 problem?)

[dushistov at mail dot ru]

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

--- Comment #4 from Evgeniy Dushistov  ---
Created attachment 36650
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36650=edit
preprocessed sources

I attached files created with gcc -E from main.cpp and Lib.cpp, hope this helps
reproduce bug (used xz compressor to work around 1000KB restriction from
bugzilla).

[Bug rtl-optimization/68212] Loop unroller breaks basic block frequencies

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-04
 CC||dje at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug fortran/54224] Warn for unused internal procedures

[dominiq at lps dot ens.fr]

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

--- Comment #30 from Dominique d'Humieres  ---
> so I give up. I am planning to submit the following patch, open a new PR
> for the bad locus, then close this PR as fixed.

The new PR won't be necessary: it is already pr63327.

[Bug fortran/53694] [OOP] GENERIC type-bound procs should be available without part-ref syntax

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #9 from Dominique d'Humieres  ---
More than three years ago Tobias Burnus wrote

> Actually, I am no longer sure that this PR is valid - nor is Richard Maine
> in c.l.f. Janus seems to have the same doubts, if I read comment 5 correctly.
>
> The standard seems to make a distinction between 'generic type-bound 
> procedure'
> and 'generic procedure name'.

Any reason to keep this PR opened?

Note that the tests now fail with

Error: INTENT(OUT) argument 'a' of pure procedure 'scalar_equals_field' at (1)
may not be polymorphic

[Bug rtl-optimization/67753] [6 Regression] FAIL: cxg1005, cxg2002, cxg2006, cxg2007, cxg2008, cxg2018, cxg2019 and cxg2020

[dave.anglin at bell dot net]

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

--- Comment #5 from dave.anglin at bell dot net ---
On 2015-11-04, at 1:57 AM, aoliva at gcc dot gnu.org wrote:

> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36645=edit
> Here's a patch I'm testing to fix this problem

Testing...

--
John David Anglin   dave.ang...@bell.net

[Bug middle-end/68215] New: [6 regression] FAIL: c-c++-common/opaque-vector.c -std=c++11 (internal compiler error)

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

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

Bug ID: 68215
   Summary: [6 regression] FAIL: c-c++-common/opaque-vector.c
-std=c++11 (internal compiler error)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: ienkovich at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-*-*

$ gcc/xg++ -Bgcc/ ../gcc/testsuite/c-c++-common/opaque-vector.c -nostdinc++
-Ipowerpc64-suse-linux/32/libstdc++-v3/include/powerpc64-suse-linux
-Ipowerpc64-suse-linux/32/libstdc++-v3/include -I../libstdc++-v3/libsupc++
-I../libstdc++-v3/include/backward -I../libstdc++-v3/testsuite/util -std=c++11
-S -m32
../gcc/testsuite/c-c++-common/opaque-vector.c: In function ‘void f()’:
../gcc/testsuite/c-c++-common/opaque-vector.c:3:153: internal compiler error:
in expand_shift_1, at expmed.c:2334
 peof((v

[Bug c++/67625] some constexpr expressions rejected as enumerator value

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-05
 CC||olegendo at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||5.2.1

--- Comment #1 from Oleg Endo  ---
I just ran into the very same issue.

[Bug c++/67625] some constexpr expressions rejected as enumerator value

[olegendo at gcc dot gnu.org]

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

--- Comment #2 from Oleg Endo  ---
There is a funny work around for this though ...

#include 

struct bswapped16
{
  const uint16_t val;
  constexpr bswapped16 (uint16_t v) : val (__builtin_bswap16 (v)) { }
};

constexpr uint16_t bswap16 (uint16_t x)
{
  return bswapped16 (x).val;
}

enum { foo_4 = bswap16 (1) };  // OK

[Bug rtl-optimization/68217] Wrong constant folding

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-05
  Component|c   |rtl-optimization
 Ever confirmed|0   |1
  Known to fail||4.8.5, 4.9.3, 5.2.1

--- Comment #1 from Marc Glisse  ---
Might happen during the combine pass (or not).

[Bug fortran/68216] New: [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

Bug ID: 68216
   Summary: [F2003] IO problem with allocatable, deferred
character length arrays
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pault at gcc dot gnu.org
  Target Milestone: ---

The following segfaults in the READ statement:

PROGRAM hello
IMPLICIT NONE

CHARACTER(LEN=:),DIMENSION(:),ALLOCATABLE :: array_lineas
INTEGER :: largo , cant_lineas , i
WRITE(*,*) ' Escriba un numero para el largo de cada linea'
READ(*,*) largo

WRITE(*,*) ' Escriba la cantidad de lineas'
READ(*,*) cant_lineas

ALLOCATE(CHARACTER(LEN=largo) :: array_lineas(cant_lineas))

WRITE(*,*) 'Escriba el array', len(array_lineas), size(array_lineas)
READ(*,*) (array_lineas(i),i=1,cant_lineas)

WRITE(*,*) 'Array guardado: '
DO i=1,cant_lineas
WRITE(*,*) array_lineas(i)
ENDDO

READ(*,*)

END PROGRAM

Reported on clf
https://groups.google.com/forum/#!topic/comp.lang.fortran/eWQTKfqKLZc

Paul

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-05
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
I am not sure it has anything to do with IO, but I think it is rather a
duplicate of pr50221.

[Bug c/68217] New: Wrong constant folding

[ishiura-compiler at ml dot kwansei.ac.jp]

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

Bug ID: 68217
   Summary: Wrong constant folding
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ishiura-compiler at ml dot kwansei.ac.jp
  Target Milestone: ---

GCC-6.0.0 miscompiles the following code.

$ cat error.c

int main(void){
volatile int a = -1;
long long b = -9223372036854775807LL-1; // LLONG_MIN
long long x = (a & b); // x == 0x8000
if ( x < 1LL ) { ; } else { __builtin_abort(); }
return 0;
}

$ gcc-6.0 error.c -O3 && ./a.out
[1]26572 abort (core dumped)  ./a.out

$ gcc-6.0 -v
Using built-in specs.
COLLECT_GCC=gcc-6.0
COLLECT_LTO_WRAPPER=$HOME/opt/gcc-6.0.0/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=$HOME/opt/gcc-6.0.0
--enable-languages=c --program-suffix=-6.0
Thread model: posix
gcc version 6.0.0 20151105 (experimental) (GCC)

[Bug c/61588] Optimization defaults are not what documentation say they should be

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-05
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
Confirmed with the latest trunk.

The -Os documentation states:

  -Os disables the following optimization flags:

 -falign-functions  -falign-jumps  -falign-loops 
 -falign-labels  -freorder-blocks  -freorder-blocks-algorithm=stc 
 -freorder-blocks-and-partition  -fprefetch-loop-arrays

Invoking "gcc -Os -Q --help=optimizers" to "to find out the exact set of
optimizations that are enabled at [the given optimization] level" indicates
that all the options are enabled:

$ /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -Os -o/dev/null -Q
--help=optimizers | grep -E
"[-]f(align-functions|align-jumps|align-loops|align-labels|reorder-blocks|reorder-blocks-algorithm|reorder-blocks-and-partition|prefetch-loop-arrays)"
 
  -falign-functions [enabled]
  -falign-jumps [enabled]
  -falign-labels[enabled]
  -falign-loops [enabled]
  -fprefetch-loop-arrays[enabled]
  -freorder-blocks  [enabled]
  -freorder-blocks-algorithm=   simple
  -freorder-blocks-and-partition[enabled]

[Bug fortran/68218] New: ALLOCATE with size given by a module function

[ysheofue at imgof dot com]

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

Bug ID: 68218
   Summary: ALLOCATE with size given by a module function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysheofue at imgof dot com
  Target Milestone: ---

Calling ALLOCATE with an array size that is given by a function argument
results in multiple calls of this function.
This issue is present (at least) on gfortran versions 4.7 ... 5

The following program unintentionally calls "nquery()" four times:

MODULE mo_test

CONTAINS

  FUNCTION nquery()
INTEGER :: nquery
WRITE (0,*) "hello!"
nquery = 1
  END FUNCTION nquery

END MODULE mo_test


! --
! MAIN PROGRAM
! --
PROGRAM example
   USE mo_test
   INTEGER, ALLOCATABLE :: query_buf(:)
   ALLOCATE(query_buf(nquery()))
END PROGRAM example

[Bug fortran/63859] OpenACC DEVICE_RESIDENT clause

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed at revision r229787 (trunk 6.0)

 !$acc declare device_resident (a)
^
sorry, unimplemented: directive not yet implemented

[Bug fortran/68218] ALLOCATE with size given by a module function

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.3.1 up to trunk (6.0).

[Bug fortran/58769] RFC: Creating SIMD variant for Fortran's ELEMENTAL functions

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-05
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
WTF? No activity for over two years.

[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get

[pault at gcc dot gnu.org]

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

--- Comment #15 from Paul Thomas  ---
Author: pault
Date: Wed Nov  4 20:00:19 2015
New Revision: 229777

URL: https://gcc.gnu.org/viewcvs?rev=229777=gcc=rev
Log:
2015-01-25  Paul Thomas  

Backported from trunk.
PR fortran/67171
* trans-array.c (structure_alloc_comps): On deallocation of
class components, reset the vptr to the declared type vtable
and reset the _len field of unlimited polymorphic components.
*trans-expr.c (gfc_find_and_cut_at_last_class_ref): Bail out on
allocatable component references to the right of part reference
with non-zero rank and return NULL.
(gfc_reset_vptr): Simplify this function by using the function
gfc_get_vptr_from_expr. Return if the vptr is NULL_TREE.
(gfc_reset_len): If gfc_find_and_cut_at_last_class_ref returns
NULL return.

2015-01-25  Paul Thomas  

Backported from trunk.
PR fortran/67171
* gfortran.dg/allocate_with_source_12.f03: New test

Backported from trunk.
PR fortran/61819
* gfortran.dg/allocate_with_source_13.f03: New test

Backported from trunk.
PR fortran/61830
* gfortran.dg/allocate_with_source_14.f03: New test

Backported from trunk.
PR fortran/67933
* gfortran.dg/allocate_with_source_15.f03: New test

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_12.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_13.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_14.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_15.f03
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/67171] [6 regression] sourced allocation

[pault at gcc dot gnu.org]

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

--- Comment #11 from Paul Thomas  ---
Author: pault
Date: Wed Nov  4 20:00:19 2015
New Revision: 229777

URL: https://gcc.gnu.org/viewcvs?rev=229777=gcc=rev
Log:
2015-01-25  Paul Thomas  

Backported from trunk.
PR fortran/67171
* trans-array.c (structure_alloc_comps): On deallocation of
class components, reset the vptr to the declared type vtable
and reset the _len field of unlimited polymorphic components.
*trans-expr.c (gfc_find_and_cut_at_last_class_ref): Bail out on
allocatable component references to the right of part reference
with non-zero rank and return NULL.
(gfc_reset_vptr): Simplify this function by using the function
gfc_get_vptr_from_expr. Return if the vptr is NULL_TREE.
(gfc_reset_len): If gfc_find_and_cut_at_last_class_ref returns
NULL return.

2015-01-25  Paul Thomas  

Backported from trunk.
PR fortran/67171
* gfortran.dg/allocate_with_source_12.f03: New test

Backported from trunk.
PR fortran/61819
* gfortran.dg/allocate_with_source_13.f03: New test

Backported from trunk.
PR fortran/61830
* gfortran.dg/allocate_with_source_14.f03: New test

Backported from trunk.
PR fortran/67933
* gfortran.dg/allocate_with_source_15.f03: New test

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_12.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_13.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_14.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_15.f03
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/61830] [4.9/5/6 regression] Memory leak with assignment to array of derived types with allocatable components

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas  ---
Author: pault
Date: Wed Nov  4 20:00:19 2015
New Revision: 229777

URL: https://gcc.gnu.org/viewcvs?rev=229777=gcc=rev
Log:
2015-01-25  Paul Thomas  

Backported from trunk.
PR fortran/67171
* trans-array.c (structure_alloc_comps): On deallocation of
class components, reset the vptr to the declared type vtable
and reset the _len field of unlimited polymorphic components.
*trans-expr.c (gfc_find_and_cut_at_last_class_ref): Bail out on
allocatable component references to the right of part reference
with non-zero rank and return NULL.
(gfc_reset_vptr): Simplify this function by using the function
gfc_get_vptr_from_expr. Return if the vptr is NULL_TREE.
(gfc_reset_len): If gfc_find_and_cut_at_last_class_ref returns
NULL return.

2015-01-25  Paul Thomas  

Backported from trunk.
PR fortran/67171
* gfortran.dg/allocate_with_source_12.f03: New test

Backported from trunk.
PR fortran/61819
* gfortran.dg/allocate_with_source_13.f03: New test

Backported from trunk.
PR fortran/61830
* gfortran.dg/allocate_with_source_14.f03: New test

Backported from trunk.
PR fortran/67933
* gfortran.dg/allocate_with_source_15.f03: New test

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_12.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_13.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_14.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_15.f03
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/67933] [5 Regression] ICE for array of a derived type with allocatable class in derived type object

[pault at gcc dot gnu.org]

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

--- Comment #10 from Paul Thomas  ---
Author: pault
Date: Wed Nov  4 20:00:19 2015
New Revision: 229777

URL: https://gcc.gnu.org/viewcvs?rev=229777=gcc=rev
Log:
2015-01-25  Paul Thomas  

Backported from trunk.
PR fortran/67171
* trans-array.c (structure_alloc_comps): On deallocation of
class components, reset the vptr to the declared type vtable
and reset the _len field of unlimited polymorphic components.
*trans-expr.c (gfc_find_and_cut_at_last_class_ref): Bail out on
allocatable component references to the right of part reference
with non-zero rank and return NULL.
(gfc_reset_vptr): Simplify this function by using the function
gfc_get_vptr_from_expr. Return if the vptr is NULL_TREE.
(gfc_reset_len): If gfc_find_and_cut_at_last_class_ref returns
NULL return.

2015-01-25  Paul Thomas  

Backported from trunk.
PR fortran/67171
* gfortran.dg/allocate_with_source_12.f03: New test

Backported from trunk.
PR fortran/61819
* gfortran.dg/allocate_with_source_13.f03: New test

Backported from trunk.
PR fortran/61830
* gfortran.dg/allocate_with_source_14.f03: New test

Backported from trunk.
PR fortran/67933
* gfortran.dg/allocate_with_source_15.f03: New test

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_12.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_13.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_14.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_15.f03
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

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

Thanks for the report.

Paul

[Bug fortran/61830] [4.9/5/6 regression] Memory leak with assignment to array of derived types with allocatable components

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

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

I'll take a look at fixing it on 4.9 but, for now, I am closing this PR.

Thanks for the report.

Paul

[Bug fortran/67933] [5 Regression] ICE for array of a derived type with allocatable class in derived type object

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

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

Thanks for the report.

Paul

[Bug fortran/64973] Duplicate use-statements could be diagnosed

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
Correct link: https://gcc.gnu.org/ml/fortran/2015-02/msg00036.html.

[Bug middle-end/64247] malloc alignment and -mavx

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #11 from Joost VandeVondele  
---
(In reply to Dominique d'Humieres from comment #10)
> A few comments:
> 
> (1) Why do you want to use PURE in this context?

because this is a pure procedure ? 

Comment 7 is not too the point (indeed reassociation can happen) as explained
afterwards

The bug here is that the same (serial) binary gives different results from run
to run, as soon as the user enables avx, and there is no way around.

I agree that it would be fixed if there was an option as askin in pr68101. (and
yes, this could help with performance as well).

[Bug fortran/53699] Missing "restrict" qualifier for OPTIONAL dummy arguments

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-04
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Still missing at revision r229727 (trunk 6.0).

[Bug tree-optimization/67742] 3rd-level restrict ignored

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org ---
Author: vries
Date: Wed Nov  4 14:18:43 2015
New Revision: 229755

URL: https://gcc.gnu.org/viewcvs?rev=229755=gcc=rev
Log:
Handle recursive restrict in function parameter

2015-11-04  Tom de Vries  

PR tree-optimization/67742
* tree-ssa-structalias.c (struct fieldoff): Add restrict_pointed_type
field.
(push_fields_onto_fieldstack): Handle restrict_pointed_type field.
(create_variable_info_for_1): Add and handle handle_param parameter.
Add restrict handling.
(create_variable_info_for): Call create_variable_info_for_1 with extra
arg.
(make_param_constraints): Drop restrict_name parameter.  Ignore
vi->only_restrict_pointers.
(intra_create_variable_infos): Call create_variable_info_for_1 with
extra arg.  Remove restrict handling.  Call make_param_constraints with
one less arg.

* gcc.dg/tree-ssa/restrict-7.c: New test.
* gcc.dg/tree-ssa/restrict-8.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/restrict-7.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/restrict-8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-structalias.c

[Bug tree-optimization/67742] 3rd-level restrict ignored

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from vries at gcc dot gnu.org ---
patch and test-cases committed, marking resolved-fixed.

[Bug driver/67613] spell suggestions for misspelled command line options

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org

--- Comment #1 from David Malcolm  ---
Candidate patch posted here:
  https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00355.html

[Bug fortran/68196] [4.9/5/6 Regression] ICE on function result with procedure pointer component

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
The patch in comment 2 looks good (works as advertised without regression, no
duplicate in store)!

[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|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |---

--- Comment #2 from Boris Nagaev  ---
The patch from bug 67056 [1] was applied to MXE [2]. It doesn't work. The
executable produced from my test code (class BufferedIfstream) is crashing. The
patch was applied to Debian Stretch version of gcc (5.2.1-22) and the resulting
gcc compiler makes crashing executables as well.

The code provided in bug 67056 as a test code [3] is compiled to a working
executable by patched MXE, original MXE and Debian Stretch's gcc 5.2.1. Bugs
67056 and 68175 seems not to be the same bug.

Can you confirm that patched gcc (rev. 229148) compiles my test code correctly
(class BufferedIfstream), please?

[1]
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/ipa-polymorphic-call.c?r1=229148=229147=229148
[2]
https://github.com/LuaAndC/mxe/commit/5c47e8ef678ea785b1092272fd3adb51beebff4e
[3]
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/testsuite/g%2B%2B.dg/ipa/pr67056.C?view=markup=229148

[Bug c++/68089] c++ friend with template

[dushistov at mail dot ru]

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

Evgeniy Dushistov  changed:

   What|Removed |Added

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

--- Comment #2 from Evgeniy Dushistov  ---
>The error seems correct to me

Yes my mistake.

[Bug c++/68209] New: C++11 code compiled without -std=c++11 but doesn't work as expected

[mirzayanovmr at gmail dot com]

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

Bug ID: 68209
   Summary: C++11 code compiled without -std=c++11 but doesn't
work as expected
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mirzayanovmr at gmail dot com
  Target Milestone: ---

Tried on g++.EXE (tdm-1) 5.1.0 and g++ (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4).

This code compiled successfully with command line 'g++ a.cpp'

#include 
#include 
using namespace std;
int main()
{
vector a;
for (int aa: a)
cout << aa << endl;
}

It prints warrning 'warning: range-based ‘for’ loops only available with
-std=c++11 or -std=gnu++11' but it is not a error.

I expected behaviour like on 4.9.2: it gives error 'error: range-based 'for'
loops are not allowed in C++98 mode'

As a result code compiled but doesn't work correctly. It prints lines
containing "0" infinitely.

I expect that such code shouldn't be compiled or at least (if compiled) work as
expected.

[Bug c++/68209] C++11 code compiled without -std=c++11 but doesn't work as expected

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
So use -pedantic-errors or -Werror if you want an error?

[Bug c/68201] alloc_size attribute and memory pools

[bugzi...@poradnik-webmastera.com]

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

--- Comment #2 from Daniel Fruzynski  ---
What about code compiled with -D_FORTIFY_SOURCE=1, when functions like strcpy
are replaced with __builtin___strcpy_chk? This is a runtime check, so passing
pool->block_size should be reasonable there.

Inlining requirement for pool_alloc is OK for me. Make sure it will be
documented in gcc manual.

[Bug c++/68209] C++11 code compiled without -std=c++11 but doesn't work as expected

[mirzayanovmr at gmail dot com]

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

--- Comment #2 from MikeMirzayanov  ---
Right now code written as C++11 can be unintentionally compiled in C++98-mode
and it leads to incorrect behavior of the code.

What is the reason why it compiled on C++98? I expect that it is incorrect
syntax for C++98 and code doesn't match language grammatics. So expected
behavior is "compilation error".

[Bug fortran/68101] Provide a way to allocate arrays aligned to 32 bytes

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #4 from Dominique d'Humieres  ---
Also related to pr642447.

[Bug middle-end/64247] malloc alignment and -mavx

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-04
 Ever confirmed|0   |1

--- Comment #10 from Dominique d'Humieres  ---
A few comments:

(1) Why do you want to use PURE in this context?

(2) On x86_64-apple-darwin14 I have run the test in comment 9 with 4.8 up to
trunk (6.0), various options, and various values of N without getting the
message "pure routine gives different results at iter: ... ". IIRC the default
alignment on darwin is bigger than the one in linux.

(3) It may help to have pr68101 implemented.

(4) I agree with comment 7 that this PR is invalid: although I am not an expert
in vectorization, I understand that the vectorization may depend on the
alignment (peeling, versioning, ... ), thus I expect that the round-off error
may depend on the alignment. If I add a line

print *, maxval(abs(Cv1(1:N*N)-Cv2(1+2:N*N+2)))/epsilon(Cv1)

before 'IF (ANY(Cv1(1:N*N).NE.Cv2(1+2:N*N+2))) CALL ABORT()', I get 4 for N=10,
48 for N=100, and 768 for N=1000, roughly what I expect for round-off errors.

[Bug libstdc++/68210] New: nothrow operator fails to call default new

[msebor at gcc dot gnu.org]

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

Bug ID: 68210
   Summary: nothrow operator fails to call default new
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

A recent discussion about operator new
(https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00192.html) revealed that the
libstdc++ implementation of the nothrow overload of the operator doesn't
conform to the requirement to "return a pointer obtained as if acquired from
the (possibly replaced) ordinary version."  The test case below illustrates
some of the problems.

The requirement quoted above implies that a conforming implementation of the
nothrow overload must call the ordinary form like so:

void* operator new (size_t n, const nothrow_t&) {
try {
return operator new (n);
}
catch (...) {
return 0;
}
}


$ cat t.cpp && ~/bin/gcc-5.1.0/bin/g++ -Wall t.cpp && ./a.out 
#include 
#include 
#include 

struct MyBadAlloc: std::bad_alloc { };

static bool new_fail;
static bool bad_alloc_thrown;
static unsigned new_called;
static unsigned new_handler_called;

static void new_handler ()
{
if (new_handler_called++)
throw MyBadAlloc ();
}

void* operator new (size_t n)
{
static size_t cntr;

++new_called;

for ( ; ; ) {
if (void *p = new_fail ? 0 : malloc (n + sizeof n)) {
*static_cast(p) = ++cntr;
return static_cast(p) + 1;
}

if (std::new_handler h = std::set_new_handler (0)) {
std::set_new_handler (h);
h ();
}
else {
bad_alloc_thrown = true;
throw MyBadAlloc ();
}
}
}

void operator delete (void *p)
{
if (p)
free (static_cast(p) - 1);
}

int main ()
{
new_called = 0;
void *p = operator new (1, std::nothrow);

assert (p != 0);
assert (1 == new_called);

std::set_new_handler (new_handler);
new_fail = true;

try {
p = operator new (1, std::nothrow);
}
catch (...) {
assert (!"nothrow operator new threw");
}

assert (0 == p);
assert (2 == new_handler_called);
assert (bad_alloc_thrown);
}
a.out: t.cpp:53: int main(): Assertion `1 == new_called' failed.
Aborted (core dumped)

[Bug target/68211] New: Free __m128d subreg of double

[glisse at gcc dot gnu.org]

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

Bug ID: 68211
   Summary: Free __m128d subreg of double
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*

Hello,

we still seem to be missing some way of passing a double to intrinsics that
take a __m128d argument (see below for an example) without any overhead when we
do not care about the high part.

__m128d to __m256d has an intrinsic, although its implementation is not optimal
(see PR 50829). But Intel apparently "forgot" to add a similar one for double
to __m128d.

Say I want to use the new AVX512 _mm_sqrt_round_sd to compute the square root
of a double rounded towards +infinity. Using -mavx512f, I can try:

#include 

double sqrt_up(double x){
  __m128d y = { x, 0 };
  return _mm_cvtsd_f64(_mm_sqrt_round_sd(y, y,
_MM_FROUND_TO_POS_INF|_MM_FROUND_NO_EXC));
}

which generates

vmovsd  %xmm0, -16(%rsp)
vmovsd  -16(%rsp), %xmm0
vsqrtsd {ru-sae}, %xmm0, %xmm0, %xmm0

I get the exact same code with

  double d = d;
  __m128d y = { x, d };

or

  __m128d y = y;
  y[0] = x;

I can shorten it to

vmovddup%xmm0, %xmm0
vsqrtsd {ru-sae}, %xmm0, %xmm0, %xmm0

using

  __m128d y = { x, x };

I am forced to use inline asm

  __m128d y;
  asm("":"=x"(y):"0"(x));

to get what I wanted, i.e. only vsqrtsd without any extra instruction. But that
makes the code non-portable, and I might as well write the vsqrtsd instruction
myself in the asm. It probably also has similar drawbacks to the unspec in PR
50829.

[Bug c/68162] [5/6 Regression] Incompatible pointer type using a typedef

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Joseph S. Myers  ---
Fixing this runs into failures of gcc.dg/debug/dwarf2/pr47939-4.c with what
looks like a problem with the DWARF debug output.

The problem (arising from the fix for PR 47939) is that the array of the
typedef was incorrectly constructed without a TYPE_MAIN_VARIANT being an array
of unqualified elements as it should be (though it seems some more recent
change resulted in this producing incorrect diagnostics, likely the support for
C++-style handling of arrays of qualified type).

Fixing the incorrect logic for determining first_non_attr_kind results in
failures of that DWARF test because the type ends up no longer being based on
the typedef.  A more complicated fix, however, as suggested in that PR, results
in a type properly based on the typedef, but the test still fails.  The type I
get (which results in debug info not referencing Harry_t, but looks correct to
me) is:

 
unit size 
align 32 symtab -145814880 alias set -1 canonical type 0x774e39d8
fields 
SI file t.c line 1 col 35 size  unit
size 
align 32 offset_align 128
offset 
bit offset  context
>>
BLK
size  constant 320>
unit size  constant 40>
align 32 symtab 0 alias set -1 canonical type 0x774e3f18
domain 
unit size 
align 64 symtab -145814480 alias set -1 canonical type
0x773d21f8 precision 64 min  max >
DI size  unit size 
align 64 symtab 0 alias set -1 canonical type 0x774e3c78 precision
64 min  max >>

[Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number

[arnez at linux dot vnet.ibm.com]

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

--- Comment #22 from Andreas Arnez  ---
Here's another version of the fix:

  https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00368.html

It addresses an issue with the previous version that was brought up by Bernd
Schmidt:  A breakpoint on the "while (1)" didn't behave as expected, but on the
first hit one loop iteration may have executed already.

[Bug tree-optimization/67742] 3rd-level restrict ignored

[vries at gcc dot gnu.org]

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

--- Comment #9 from vries at gcc dot gnu.org ---
Author: vries
Date: Wed Nov  4 16:51:06 2015
New Revision: 229766

URL: https://gcc.gnu.org/viewcvs?rev=229766=gcc=rev
Log:
Backport "Handle recursive restrict in function parameter"

2015-11-04  Tom de Vries  

backport from trunk:
2015-11-04  Tom de Vries  

PR tree-optimization/67742
* tree-ssa-structalias.c (struct fieldoff): Add restrict_pointed_type
field.
(push_fields_onto_fieldstack): Handle restrict_pointed_type field.
(create_variable_info_for_1): Add and handle handle_param parameter.
Add restrict handling.
(create_variable_info_for): Call create_variable_info_for_1 with extra
arg.
(make_param_constraints): Drop restrict_name parameter.  Ignore
vi->only_restrict_pointers.
(intra_create_variable_infos): Call create_variable_info_for_1 with
extra arg.  Remove restrict handling.  Call make_param_constraints with
one less arg.

* gcc.dg/tree-ssa/restrict-7.c: New test.
* gcc.dg/tree-ssa/restrict-8.c: New test.

* tree-ssa-structalias.c (create_variable_info_for_1): Use decl_type
variable.

Added:
branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/tree-ssa/restrict-7.c
branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/tree-ssa/restrict-8.c
Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/tree-ssa-structalias.c

[Bug c/68212] New: Loop unroller breaks basic block frequencies

[kelvin.nilsen at gmail dot com]

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

Bug ID: 68212
   Summary: Loop unroller breaks basic block frequencies
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kelvin.nilsen at gmail dot com
  Target Milestone: ---

Here’s a very simple program to demonstrate the existing problems:

void foo(double *d, unsigned long int n) {
  unsigned long int i;

  for (i=0;i> 4;
   mod4_elements = extended_element_count & 0x03;
  goto B9;  /* fall through, probability 100%, frequency 819 */

 B9: /* frequency 819 */
   *((double *) ivtmp.6) = zero_preload;
   ivtmp.6 += 16;
   if (ivtmp.6 == _17) goto B10; /* probability 91%, frequency 745 */
  else goto B7; /* fall through, probability 9%, frequency 74 */

 B10: /* frequency 745 */
 /* no code */
 goto BB23;  /* fall through, probability 75%, frequency 559 */
 /* WRONG: probability should be 100%, frequency should be 745 */

 B23: /* frequency 497: WRONG: B10 is the only predecessor, frequency 
   * should be 559 based on existing B10 information 
   */
if (mod4_elements == 0) goto B22; /* 25% probability, frequency 124 */
else goto BB19; /* fall through, probability 100%, frequency 497. 
WRONG: should be probability 75%, frequency 373 */

 B19: /* frequency: 373.  INCONSISTENT with B23 data, but this is a correct
value by some standard. */
 if (mod4_elements == 1) goto BB18; /* 33% probability, frequency 123
*/
 else goto B15; /* fall-through, probability 100%, frequency 373. 
WRONG: should be probability 67%, frequency 250 */

 B15: /* frequency: 745.  WRONG: only predecessor is B19, should be 373 as B19
is currently described */
 if (mod4_elements == 2) goto B14; /* probability 50%, frequency = 373
*/
 else goto B11; /* fall through, probability 100%, frequency 745. 
WRONG: 

[Bug c/68162] [5/6 Regression] Incompatible pointer type using a typedef

[jsm28 at gcc dot gnu.org]

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

--- Comment #4 from Joseph S. Myers  ---
Created attachment 36649
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36649=edit
Patch that preserves the typedef but does not fix the debug test failure

[Bug fortran/66459] bogus warning 'w.offset' may be used uninitialized in this function [-Wmaybe-uninitialized]

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
> Possibly related bug: PR60500

Likely, but I get the warning for this PR for 4.5.4, but not 4.4.7, while the
warnings for PR60500 appear only for 4.7.3.

[Bug c/68162] [5/6 Regression] Incompatible pointer type using a typedef

[jsm28 at gcc dot gnu.org]

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

--- Comment #3 from Joseph S. Myers  ---
Created attachment 36648
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36648=edit
Minimal patch for grokdeclarator

[Bug c++/68195] gcc//ld produces invalid ABI results (cxx11 problem?)

[dushistov at mail dot ru]

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

Evgeniy Dushistov  changed:

   What|Removed |Added

 CC||dushistov at mail dot ru

--- Comment #1 from Evgeniy Dushistov  ---
The behavior of compiler generate code with segfault and generate valid code
was changed by this commit:

commit 7fbf53b8667745c0122e964e1b11dcb99959e377
Author: hubicka 
Date:   Mon Nov 24 16:15:46 2014 +

PR ipa/63671
* ipa-inline-transform.c (can_remove_node_now_p_1): Handle alises
and -fno-devirtualize more carefully.
(can_remove_node_now_p): Update.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@218024
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c/68201] alloc_size attribute and memory pools

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
As GCC uses the attribute for static analysis it can't go out and read the
actual
value from pool->block_size so I see no value in providing the size this way
(it would also only work if pool_alloc is inlined).

[Bug libstdc++/52604] mt allocator crashes on multi-threaded

[rguenth at gcc dot gnu.org]

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

--- Comment #23 from Richard Biener  ---
According to the dup the fix is bogus (the added stmt is optimized away).

[Bug libstdc++/52604] mt allocator crashes on multi-threaded

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||oremanj at mit dot edu

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

[Bug libstdc++/68200] g++ 5.2 optimizes out pointer assignment in libstdc++ mt_allocator freelist destructor, causing crash at global-dtor time

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Duplicate then (52604 is not marked fixed anyway).

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

[Bug c++/68203] Аbout infinite compilation time on struct with nested array of pairs with -std=c++11

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog,
   ||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-04
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
And we have a duplicate bugreport for this somewhere.

[Bug tree-optimization/66726] missed optimization, factor conversion out of COND_EXPR

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

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

--- Comment #13 from Andreas Schwab  ---
../../gcc/tree-ssa-reassoc.c: In function 'void
maybe_optimize_range_tests(gimple*)':
../../gcc/tree-ssa-reassoc.c:3193:8: error: 'operand_entry_t' was not declared
in this scope
operand_entry_t oe = operand_entry_pool.allocate ();
^
../../gcc/tree-ssa-reassoc.c:3193:24: error: expected ';' before 'oe'
operand_entry_t oe = operand_entry_pool.allocate ();
^
../../gcc/tree-ssa-reassoc.c:3194:8: error: 'oe' was not declared in this scope
oe->op = lhs;
^

[Bug fortran/66244] [4.9/5/6 Regression] ICE on assigning a value to a pointer variable

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|ICE on assigning a value to |[4.9/5/6 Regression] ICE on
   |a pointer variable  |assigning a value to a
   ||pointer variable

--- Comment #3 from Dominique d'Humieres  ---
Compiling the test in comment 0 with 4.7.3 does not ICE, but the error

pr66244.f90:3.35:

  integer, pointer :: z => a(3)
   1
Error: Pointer initialization target at (1) must have the SAVE attribute

Note that the ICE for 4.8.5 is

pr66244.f90:6:0: internal compiler error: in varpool_node_for_decl, at
varpool.c:45
end
 ^

The change occurred between revisions r194897 (2013-01-04, error) and r195140
(2013-01-14, ICE at varpool.c:45). Note that the code compiles with

  integer, save, target :: a(3)

[Bug c++/68195] gcc//ld produces invalid ABI results (cxx11 problem?)

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Jan Hubicka  ---
This works for me on mainline:

$ ls
Lib.cpp  Lib.hpp  main.cpp  Makefile  README.md
$ g++ --version
g++ (GCC) 6.0.0 20151010 (experimental)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ make test1
g++ -shared -fPIC -o libmyLib.so Lib.cpp  -O2
g++ -o main -std=c++11 main.cpp -L. -l myLib
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:. ./main


I am building GCC-5 branch to see if it fails.

[Bug target/68199] avr-gcc rise a warning when defining a custom interruption

[astralien3000 at yahoo dot fr]

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

astralien3000  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug fortran/68196] [4.9/5/6 Regression] ICE on function result with procedure pointer component

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
Created attachment 36646
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36646=edit
Patch for the PR

Dear Damian,

Thanks for this one! Dominique was quite right as to where the infinite
recursion occurs. Once fixed, however, the same thing happens again in
trans-types.c!

The attached patch fixes both and is just now regtesting.

The testcase is:
! { dg-do run }
! Tests the fix for PR68196
!
! Contributed by Damian Rouson  
!
  type AA
integer :: i
procedure(foo), pointer :: funct
  end type
  class(AA), allocatable :: my_AA
  type(AA) :: res

  allocate (my_AA, source = AA (1, foo))

  res = my_AA%funct ()

  if (res%i .ne. 3) call abort
  if (.not.associated (res%funct)) call abort
  if (my_AA%i .ne. 4) call abort
  if (associated (my_AA%funct)) call abort

contains
  function foo(A)
class(AA), allocatable :: A
type(AA) foo

if (.not.allocated (A)) then
  allocate (A, source = AA (2, foo))
endif

select type (A)
  type is (AA)
foo = AA (3, foo)
A = AA (4, NULL ())
end select
  end function
end

Cheers

Paul

[Bug fortran/48820] TR 29113: Implement parts needed for MPI 3

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #21 from Dominique d'Humieres  ---
No activity for over three years, broken links, ... . IMO this PR should be
closed as FIXED and new PR(s) should be opened for remaining issue(s) not
covered by existing PRs.

[Bug fortran/35031] ELEMENTAL procedure with BIND(C)

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
This is

C1252 An elemental procedure shall not have the BIND attribute.

in subclause 12.6.2.1 of my Fortran 2015 draft.

[Bug c++/68208] New: g++ doesn't warn against reference self-initialization

[ooprala at redhat dot com]

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

Bug ID: 68208
   Summary: g++ doesn't warn against reference self-initialization
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ooprala at redhat dot com
  Target Milestone: ---

Created attachment 36647
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36647=edit
reproducer

/usr/bin/gcc -v
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-default-libstdcxx-abi=c++98 --with-isl --enable-libmpx
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC) 



g++ remains silent with -Wall -Wextra.
However, even with no extra options,
clang++ -c repr.cc emits:
repr.cc:4:10: warning: reference 'm' is not yet bound to a value when used here
[-Wuninitialized]
  S0():m(m){}
 ^
1 warning generated.