[Bug target/88070] [8/9 Regression] ICE in create_pre_exit, at mode-switching.c:438

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Just for the record: started with r255395.

[Bug tree-optimization/88071] [8/9 Regression] ICE: verify_gimple failed (error: dead STMT in EH table)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-19
 CC||alan.hayward at arm dot com,
   ||david.sherwood at arm dot com,
   ||marxin at gcc dot gnu.org,
   ||rdsandiford at googlemail dot 
com
  Known to work||7.3.0
   Target Milestone|--- |8.3
Summary|[9 Regression] ICE: |[8/9 Regression] ICE:
   |verify_gimple failed|verify_gimple failed
   |(error: dead STMT in EH |(error: dead STMT in EH
   |table)  |table)
 Ever confirmed|0   |1
  Known to fail||8.2.0, 9.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r256639.

[Bug tree-optimization/88069] [9 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.c:709

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-19
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Known to work||8.2.0
   Target Milestone|--- |9.0
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r265959.

[Bug driver/81519] Enhancement: Add --help=target-distcc or similar to dump clean, optimal CFLAGS without using -march=native

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #10 from Martin Liška  ---
Note that I'm not planning to come up with a script. It's quite a concrete
usage, so I would recommend you to put a script into your project.

Idea of the script can be:
$ gcc --help=target -Q &>/tmp/1 && gcc --help=target -Q -march=haswell &>/tmp/2
&& diff -u /tmp/1 /tmp/2 | grep '^+'
+++ /tmp/2  2018-11-19 08:21:08.180761742 +0100
+  -maes[enabled]
+  -march=  haswell
+  -mavx[enabled]
+  -mavx2   [enabled]
+  -mavx256-split-unaligned-load[disabled]
+  -mavx256-split-unaligned-store   [disabled]
+  -mbmi[enabled]
+  -mbmi2   [enabled]
+  -mcx16   [enabled]
+  -mf16c   [enabled]
+  -mfma[enabled]
+  -mfsgsbase   [enabled]
+  -mhle[enabled]
+  -mlzcnt  [enabled]
+  -mmovbe  [enabled]
+  -mno-sse4[disabled]
+  -mpclmul [enabled]
+  -mpopcnt [enabled]
+  -mrdrnd  [enabled]
+  -msahf   [enabled]
+  -msse3   [enabled]
+  -msse4   [enabled]
+  -msse4.1 [enabled]
+  -msse4.2 [enabled]
+  -mssse3  [enabled]
+  -mtune=  haswell
+  -mxsave  [enabled]
+  -mxsaveopt   [enabled]

[Bug target/88083] ICE in find_constant_pool_ref_1, at config/s390/s390.c:8231

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug target/88082] ICE in change_address_1, at emit-rtl.c:2286

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug target/88083] New: ICE in find_constant_pool_ref_1, at config/s390/s390.c:8231

[marxin at gcc dot gnu.org]

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

Bug ID: 88083
   Summary: ICE in find_constant_pool_ref_1, at
config/s390/s390.c:8231
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: krebbel at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: s390x-linux-gnu

Following is causing ICE:

$ cat ice.i
void *a, *b;
void c(void) { __builtin_memcpy(a, b, -1); }

$ s390x-linux-gnu-gcc ice.i -fno-sched-last-insn-heuristic -fno-dce -march=z196
-O2
ice.i: In function ‘c’:
ice.i:2:16: warning: ‘__builtin_memcpy’ specified size 18446744073709551615
exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
2 | void c(void) { __builtin_memcpy(a, b, -1); }
  |^~
during RTL pass: mach
ice.i:2:1: internal compiler error: in find_constant_pool_ref_1, at
config/s390/s390.c:8231
2 | void c(void) { __builtin_memcpy(a, b, -1); }
  | ^~~~
0x56cc9b find_constant_pool_ref_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/config/s390/s390.c:8230
0xca7ca4 find_constant_pool_ref_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/config/s390/s390.c:8252
0xca7ca4 find_constant_pool_ref_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/config/s390/s390.c:8252
0xca7ca4 find_constant_pool_ref_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/config/s390/s390.c:8252
0xca7d35 find_constant_pool_ref_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/config/s390/s390.c:8257
0xcc55aa s390_mainpool_start
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/config/s390/s390.c:8736
0xcc55aa s390_reorg
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/config/s390/s390.c:14018
0x9b18d9 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/reorg.c:3979

[Bug target/88082] New: ICE in change_address_1, at emit-rtl.c:2286

[marxin at gcc dot gnu.org]

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

Bug ID: 88082
   Summary: ICE in change_address_1, at emit-rtl.c:2286
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: krebbel at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: s390x-linux-gnu

Following is causing ICE:

$ s390x-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/pr59037.c -Os
-march=z14
during RTL pass: early_mach
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/pr59037.c: In function
‘main’:
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/pr59037.c:12:1:
internal compiler error: in change_address_1, at emit-rtl.c:2286
   12 | }
  | ^
0x55222b change_address_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/emit-rtl.c:2286
0xca8811 annotate_constant_pool_refs_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/config/s390/s390.c:8153
0xca8675 annotate_constant_pool_refs_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/config/s390/s390.c:8196
0xca8675 annotate_constant_pool_refs_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/config/s390/s390.c:8196
0xcbfd64 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/config/s390/s390.c:10626
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug lto/88081] [7/8/9 Regression] ICE in lto_varpool_replace_node, at lto/lto-symtab.c:109

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2018-11-19
  Known to work||5.4.0
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
   Target Milestone|--- |9.0
  Known to fail||6.4.0, 7.3.0, 8.2.0, 9.0

[Bug lto/88081] New: [7/8/9 Regression] ICE in lto_varpool_replace_node, at lto/lto-symtab.c:109

[marxin at gcc dot gnu.org]

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

Bug ID: 88081
   Summary: [7/8/9 Regression] ICE in lto_varpool_replace_node, at
lto/lto-symtab.c:109
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Following is causing ICE:

$ cat 1.ii
class a {
public:
  virtual ~a();
};
class b {
  virtual int c() const noexcept;
};
int b::c() const noexcept { return 0; }
namespace __cxxabiv1 {
class __class_type_info : a {};
} // namespace __cxxabiv1

$ cat 2.ii
class a {
  virtual char b();
};
class c {
  virtual bool m_fn2() const noexcept;
};
bool c::m_fn2() const noexcept { return true; }
namespace __cxxabiv1 {
class __class_type_info : a {};
} // namespace __cxxabiv1

$ g++ -c -flto 1.ii && g++ -c -flto 2.ii -O3 && g++ [12].o
during IPA pass: pure-const
lto1: internal compiler error: in lto_varpool_replace_node, at
lto/lto-symtab.c:109
0x5b6992 lto_varpool_replace_node
/home/marxin/Programming/gcc/gcc/lto/lto-symtab.c:109
0x79b794 lto_symtab_merge_symbols_1
/home/marxin/Programming/gcc/gcc/lto/lto-symtab.c:916
0x79b794 lto_symtab_merge_symbols()
/home/marxin/Programming/gcc/gcc/lto/lto-symtab.c:973
0x78c82f read_cgraph_and_symbols
/home/marxin/Programming/gcc/gcc/lto/lto.c:3013
0x78c82f lto_main()
/home/marxin/Programming/gcc/gcc/lto/lto.c:3401

[Bug lto/41528] LTO needs better internal and user documentation

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #4 from sandra at gcc dot gnu.org ---
Looking at the mailing list discussion of the patch committed in 2010

https://gcc.gnu.org/ml/gcc-patches/2010-11/msg01508.html

it seems like there were requests for corrections which Diego said he'd address
in follow-up patches, but I see no evidence that the requested changes were
ever committed.

I think it would be good if someone actually familiar with LTO internals
reviewed the existing internals documentation and corrected it to agree with
the current implementation.  Likewise I don't really know if the existing user
documentation completely reflects current reality, although I think the
concerns about lack of a usage overview and poor integration into the manual
that were mentioned in the issue description have been addressed.

[Bug target/87928] [7/8/9 Regression] ICE in ix86_compute_frame_layout, at config/i386/i386.c:11161 since r228607

[daniel.santos at pobox dot com]

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

--- Comment #10 from Daniel Santos  ---
(In reply to Uroš Bizjak from comment #9)
> Fixed everywhere.

Thank you Uros, great work!

It's an easy mistake to assume that you're "on one system/ABI or another" and
forget about function-level attributes.  But I've never been too crazy about
the way some globals and macros are sort-of hidden in .md or .opt files and
generated in the build (like ix86_abi).

[Bug tree-optimization/88074] g++ hangs on math expression

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||alias
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-19
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Looks like the alias analysis phase during (before) PRE is causing an infinite
loop:
Alias information for void getValue(std::vector >&)

Aliased symbols

D.48932, UID D.48932, struct ValType, is addressable

Call clobber information

ESCAPED, points-to non-local, points-to vars: { D.48932 } (escaped)

Flow-insensitive points-to information

V_11(D), points-to non-local, points-to NULL, points-to vars: { }
_20, points-to non-local, points-to escaped, points-to NULL, points-to vars: {
}
_21, points-to non-local, points-to escaped, points-to NULL, points-to vars: {
}
_22, points-to non-local, points-to escaped, points-to NULL, points-to vars: {
}
_23

[Bug other/40498] no_instrument_function attribute not documented to prevent -pg instrumentation

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from sandra at gcc dot gnu.org ---
Fixed on trunk.

[Bug other/40498] no_instrument_function attribute not documented to prevent -pg instrumentation

[sandra at gcc dot gnu.org]

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

--- Comment #4 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Mon Nov 19 01:04:04 2018
New Revision: 266260

URL: https://gcc.gnu.org/viewcvs?rev=266260=gcc=rev
Log:
2018-11-18  Sandra Loosemore  

PR other/40498

gcc/
* doc/extend.texi (Common Function Attributes): Document that
no_instrument_function applies to -p and -pg, too.
* doc/invoke.texi (Instrumentation Options): Add cross-references
to docs for -p, -pg, and -finstrument-functions.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/extend.texi
trunk/gcc/doc/invoke.texi

[Bug fortran/88052] Format contravening f2008 constraint C1002 permitted

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
(In reply to harper from comment #5)
> The error I found is not just violating a constraint in f2008 or above. 
> The same constraint with different wording is in f2003, f95 and f90.
> If you want to allow any constraint violations I think that should be an 
> option, not the default.
> 

The syntax of 

if (compile_options.warn_std == 0)
+   goto format_item_1;

Is a little obscure, but basicallly the goto is performed only if a user
specifies -std=legacy. For anything else including not specifying any -std= or
the default, the error is given.

(as noted by Steve)

[Bug fortran/88080] New: Add warning if IMPLICIT NONE is missing

[vivekrao4 at yahoo dot com]

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

Bug ID: 88080
   Summary: Add warning if IMPLICIT NONE is missing
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vivekrao4 at yahoo dot com
  Target Milestone: ---

I think new Fortran code should have IMPLICIT NONE in every procedure or
preferably at the beginning of a program or MODULE. I request that gfortran add
an option that warns when this is not the case. Users who want IMPLICIT NONE in
all code can convert such a warning to an error.

This is, of course, an enhancement request and not a bug report.

[Bug fortran/88079] New: warn about procedure arguments without INTENT

[vivekrao4 at yahoo dot com]

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

Bug ID: 88079
   Summary: warn about procedure arguments without INTENT
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vivekrao4 at yahoo dot com
  Target Milestone: ---

I think all new Fortran code should have the INTENT specified for the arguments
of all procedures. I request that gfortran add a warning for code not doing
this. If a warning is added, users who agree with my style recommendation can
use a -Werror flag to force them to fix code without INTENTs for all arguments.

This is, of course, an enhancement request, not a bug report.

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #13 from Eric Botcazou  ---
> I'm wondering if the cause could be faulty code that only misbehaves with a
> trivial source file.  How do I investigate further?

You need to debug the compiler, preferably compiled at -O0.  There is something
fishy going on your machine and I'm afraid you're the only one able to find it.

You could for example execute in parallel the minimal program on the x86 and
SPARC machines and find out where things start to diverge between them.

[Bug fortran/88052] Format contravening f2008 constraint C1002 permitted

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to harper from comment #5)
> The error I found is not just violating a constraint in f2008 or above. 
> The same constraint with different wording is in f2003, f95 and f90.
> If you want to allow any constraint violations I think that should be an 
> option, not the default.
> 


There are a lot of things that one can think, but the reality
is that too many users throw garbage at gfortran and she does
her best to compile that garbage.  By default, gfortran enforces
-std=GNU, which accepts a very long list of garbage.  Sure, it
would be nice if -std=f2018 were the default, but it isn't and
I doubt that it ever will be, because none of the people who
contribute patches to gfortran would want to see the whining.
Oh, if you look at Jerry's patch, he is hiding the extension
behind -std=legacy.

[Bug target/87928] [7/8/9 Regression] ICE in ix86_compute_frame_layout, at config/i386/i386.c:11161 since r228607

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #9 from Uroš Bizjak  ---
Fixed everywhere.

[Bug target/87928] [7/8/9 Regression] ICE in ix86_compute_frame_layout, at config/i386/i386.c:11161 since r228607

[uros at gcc dot gnu.org]

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

--- Comment #8 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Nov 18 21:36:30 2018
New Revision: 266254

URL: https://gcc.gnu.org/viewcvs?rev=266254=gcc=rev
Log:
Backport from mainline
2018-11-11  Uros Bizjak  

PR target/87928
* config/i386/i386.h (STACK_BOUNDARY): Use TARGET_64BIT_MS_ABI
instead of (TARGET_64BIT && ix86_abi == MS_ABI).
* config/i386/darwin.h (STACK_BOUNDARY): Ditto.
* config/i386/cygming.h (STACK_BOUNDARY): Remove.

testsuite/ChangeLog:

Backport from mainline
2018-11-11  Uros Bizjak  

PR target/87928
* gcc.target/i386/pr87928.c: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr87928.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/cygming.h
branches/gcc-7-branch/gcc/config/i386/darwin.h
branches/gcc-7-branch/gcc/config/i386/i386.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/88052] Format contravening f2008 constraint C1002 permitted

[harper at msor dot vuw.ac.nz]

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

--- Comment #5 from harper at msor dot vuw.ac.nz ---
The error I found is not just violating a constraint in f2008 or above. 
The same constraint with different wording is in f2003, f95 and f90.
If you want to allow any constraint violations I think that should be an 
option, not the default.

On Fri, 16 Nov 2018, jvdelisle at gcc dot gnu.org wrote:

> Date: Fri, 16 Nov 2018 19:08:12 +
> From: jvdelisle at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug fortran/88052] Format contravening f2008 constraint C1002
> permitted
> Resent-Date: Sat, 17 Nov 2018 08:08:38 +1300 (NZDT)
> Resent-From: 
> 
> https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D88052data=02%7C01%7Cjohn.harper%40vuw.ac.nz%7C9dafaf4a7f4a4275460b08d64bf6dd15%7Ccfe63e236951427e8683bb84dcf1d20c%7C0%7C0%7C636779921039210363sdata=Nuf9UwUTOPDw6Xip1CG%2FTe7DUR37%2Bdq8Pd6hWYWMLG8%3Dreserved=0
>
> --- Comment #2 from Jerry DeLisle  ---
> Well until now we were permitting this as an extension. We could choose to
> allow it only under -std=legacy or throw a runtime error. Usually we don't 
> like
> to throw runtime errors for things if not absolutely necessary. As this is a
> constraint, we can give the error with F2008 or above.
>
> In format.c we have:
>
> default:
>  /* Assume a missing comma, this is a GNU extension */
>  goto format_item_1;
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz phone (+64)(4)463 5276 fax (+64)(4)463 5045

[Bug other/38801] libgcc exception handling routines need documentation

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-18
 CC||sandra at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from sandra at gcc dot gnu.org ---
Confirmed that this is still a problem.  As this is part of the internals
documentation, I'm treating it as lower priority than user-facing
documentation.  

Of course there's nothing stopping someone who's familiar with these interfaces
from drafting some documentation.

[Bug target/87928] [7/8/9 Regression] ICE in ix86_compute_frame_layout, at config/i386/i386.c:11161 since r228607

[uros at gcc dot gnu.org]

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

--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Nov 18 20:41:32 2018
New Revision: 266253

URL: https://gcc.gnu.org/viewcvs?rev=266253=gcc=rev
Log:
Backport from mainline
2018-11-11  Uros Bizjak  

PR target/87928
* config/i386/i386.h (STACK_BOUNDARY): Use TARGET_64BIT_MS_ABI
instead of (TARGET_64BIT && ix86_abi == MS_ABI).
* config/i386/darwin.h (STACK_BOUNDARY): Ditto.
* config/i386/cygming.h (STACK_BOUNDARY): Remove.

testsuite/ChangeLog:

Backport from mainline
2018-11-11  Uros Bizjak  

PR target/87928
* gcc.target/i386/pr87928.c: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr87928.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/i386/cygming.h
branches/gcc-8-branch/gcc/config/i386/darwin.h
branches/gcc-8-branch/gcc/config/i386/i386.h
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug c++/88078] New: error: '__float128' was not declared in this scope on PowerPC

[noloader at gmail dot com]

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

Bug ID: 88078
   Summary: error: '__float128' was not declared in this scope on
PowerPC
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: noloader at gmail dot com
  Target Milestone: ---

I'm working on GCC112 from the compile farm. I'm having trouble compiling a
program with the C++ compiler.

$ cat test.cxx
#include 
#undef vector
#undef pixel
#undef bool

#include 
#include 

typedef __vector unsigned char uint8x16_p;

uint8x16_p Foo(const unsigned char* ptr)
{
  return vec_ld(0, ptr);
}

=

Compiling results in:

$ /opt/cfarm/gcc-latest/bin/g++ -mcpu=power4 -maltivec -c test.cxx
In file included from
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/bits/move.h:55,
 from
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/bits/stl_pair.h:59,
 from
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/bits/stl_algobase.h:64,
 from
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/bits/char_traits.h:39,
 from
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/string:40,
 from test.cxx:6:
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/type_traits:335:39:
error: '__float128' was not declared in this scope
 struct __is_floating_point_helper<__float128>
   ^~
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/type_traits:335:39:
note: suggested alternative: 'vec_float2'
 struct __is_floating_point_helper<__float128>
   ^~
   vec_float2
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/type_traits:335:49:
error: template argument 1 is invalid
 struct __is_floating_point_helper<__float128>
 ^
In file included from
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/cstdlib:77,
 from
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/ext/string_conversions.h:41,
 from
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/bits/basic_string.h:6391,
 from
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/string:52,
 from test.cxx:6:
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/bits/std_abs.h:101:3:
error: '__float128' does not name a type; did you mean 'vec_float2'?
   __float128
   ^~
   vec_float2


=

And finally:

$ /opt/cfarm/gcc-latest/bin/g++ --version
g++ (GCC) 8.2.0
Copyright (C) 2018 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.

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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

--- Comment #12 from Gary Mills  ---
Just in case it was the C++ compiler that was mis-compiling the intermediate
gcc
compiler, I did a build with both CFLAGS and CXXFLAGS set to '-g -O0'.  Again,
I
got the same ICE.  With that, I suppose we can rule out a mis-compilation of
the
intermediate compiler.  The ICE seems to be real!

The curious thing is that gcc/xgcc seems to work correctly for building all of
the gcc-7 source.  It's only during the configuration tests that the ICE
appears.
At that time, it's compiling trivial source files.

I'm wondering if the cause could be faulty code that only misbehaves with a
trivial source file.  How do I investigate further?

The other curious thing is that gcc-7 builds correctly on x86 hardware.  The
ICE
only appears on SPARC hardware.  How do I investigate further?

[Bug fortran/87881] gfortran.dg/inquiry_type_ref_(1.f08|3.f90) fail on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
Hi Paul,

> I am getting nowhere with this. ...

Did you try to run gfortran under valgrind?

I think there is a latent bug in gfortran that triggers the

==82437==ERROR: AddressSanitizer: heap-use-after-free on address 0x617053d8
at pc 0x0001001565a9 bp 0x7ffeefbfcb60 sp 0x7ffeefbfcb58
READ of size 8 at 0x617053d8 thread T0
...

pr52622 gcc fortran unassig...@gcc.gnu.org  NEW ---
heap-use-after-free with instrumented compiler  2018-07-24
pr78746 gcc fortran unassig...@gcc.gnu.org  NEW --- charlen_03,
charlen_10 ICE  2018-07-24
pr81531 gcc fortran unassig...@gcc.gnu.org  NEW --- Multiple
Invalid reads seen by valgrind on an invalid test-case 2018-07-24
pr87881 gcc fortran unassig...@gcc.gnu.org  NEW ---
gfortran.dg/inquiry_type_ref_(1.f08|3.f90) fail on darwin   Sat 18:32
pr87908 gcc fortran unassig...@gcc.gnu.org  NEW --- ICE in
check_interface0, at fortran/interface.c:18412018-11-06
pr79524 gcc fortran unassig...@gcc.gnu.org  NEW --- [7/8/9
Regression] valgrind error for gcc/testsuite/gfortran.dg/fimplicit_none_2.f90  
 2018-10-26
pr82721 gcc fortran unassig...@gcc.gnu.org  NEW --- [7/8/9
Regression] Error message with corrupted text, sometimes ICE 2018-07-24
pr84245 gcc fortran unassig...@gcc.gnu.org  NEW --- [7/8/9
Regression] ICE in delete_root, at fortran/bbt.c:150 2018-02-07
pr86657 gcc fortran unassig...@gcc.gnu.org  NEW --- ASAN error:
heap-use-after-free gcc/fortran/symbol.c:1762 in gfc_add_flavor 2018-07-24
pr87994 gcc fortran unassig...@gcc.gnu.org  NEW --- ICE in
match_data_constant, at fortran/decl.c:399   19:01:42

> Have you joined the 'gilets jaunes' today ;-)

I hate the people behind it!-(

[Bug lto/88077] [8/9 Regression] ICE: tree check: expected class ‘type’, have ‘declaration’ (var_decl) in lto_symtab_merge, at lto/lto-symtab.c:378 since r256989

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-18
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |8.3
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Mine.

[Bug lto/88077] New: [8/9 Regression] ICE: tree check: expected class ‘type’, have ‘declaration’ (var_decl) in lto_symtab_merge, at lto/lto-symtab.c:378 since r256989

[marxin at gcc dot gnu.org]

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

Bug ID: 88077
   Summary: [8/9 Regression] ICE: tree check: expected class
‘type’, have ‘declaration’ (var_decl) in
lto_symtab_merge, at lto/lto-symtab.c:378 since
r256989
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Starting from my commit we ICE on:

$ cat 1.i
int HeaderStr;

$ cat 2.i
char HeaderStr[];

$ gcc [12].i -flto -O2 -shared
2.i:1:6: warning: array ‘HeaderStr’ assumed to have one element
1 | char HeaderStr[];
  |  ^
lto1: internal compiler error: tree check: expected class ‘type’, have
‘declaration’ (var_decl) in lto_symtab_merge, at lto/lto-symtab.c:378
0x6b6361 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.c:9707
0x5b710b tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/home/marxin/Programming/gcc/gcc/tree.h:3277
0x5b710b lto_symtab_merge
/home/marxin/Programming/gcc/gcc/lto/lto-symtab.c:378
0x5b710b lto_symtab_merge_decls_2
/home/marxin/Programming/gcc/gcc/lto/lto-symtab.c:636
0x5b710b lto_symtab_merge_decls_1
/home/marxin/Programming/gcc/gcc/lto/lto-symtab.c:849
0x5b710b lto_symtab_merge_decls()
/home/marxin/Programming/gcc/gcc/lto/lto-symtab.c:875
0x78cfc4 read_cgraph_and_symbols
/home/marxin/Programming/gcc/gcc/lto/lto.c:2962
0x78cfc4 lto_main()
/home/marxin/Programming/gcc/gcc/lto/lto.c:3401

[Bug fortran/87994] ICE in match_data_constant, at fortran/decl.c:399

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
I have instrumented gfortran with the patch in comment 5 and all the tests fail
as with pr87881:

=
==67715==ERROR: AddressSanitizer: heap-use-after-free on address 0x617045d8
at pc 0x0001001565a9 bp 0x7ffeefbfdd30 sp 0x7ffeefbfdd28
READ of size 8 at 0x617045d8 thread T0
#0 0x1001565a8 in simplify_ref_chain(gfc_ref*, int, gfc_expr**) expr.c:1943
#1 0x10015438e in gfc_simplify_expr(gfc_expr*, int) expr.c:2164
#2 0x100369eaf in gfc_match_varspec(gfc_expr*, int, bool, bool)
primary.c:2287
#3 0x1003798ba in gfc_match_rvalue(gfc_expr**) primary.c:3670
#4 0x1000c2f63 in match_data_constant(gfc_expr**) decl.c:379
#5 0x1000c4291 in top_val_list(gfc_data*) decl.c:478
#6 0x1000c4905 in gfc_match_data() decl.c:624
#7 0x10032fbc7 in match_word(char const*, match (*)(), locus*) parse.c:65
#8 0x10033d154 in decode_statement() parse.c:468
#9 0x10033ee0d in next_free() parse.c:1234
#10 0x10033f7d2 in next_statement() parse.c:1466
#11 0x100345d67 in parse_spec(gfc_statement) parse.c:3858
#12 0x10034c892 in parse_progunit(gfc_statement) parse.c:5671
#13 0x10034ec10 in gfc_parse_file() parse.c:6211
#14 0x100525304 in gfc_be_parse_file() f95-lang.c:204
#15 0x1062941c8 in compile_file() toplev.c:455
#16 0x10629f87c in do_compile() toplev.c:2172
#17 0x109388807 in toplev::main(int, char**) toplev.c:2307
#18 0x1097eaf4c in main main.c:39
#19 0x7fff703f908c in start (libdyld.dylib:x86_64+0x1708c)

0x617045d8 is located 728 bytes inside of 736-byte region
[0x61704300,0x617045e0)
freed by thread T0 here:
#0 0x15948a8e0 in wrap_free.part.0 sanitizer_malloc_mac.inc:121
#1 0x10012e8e5 in gfc_free_ref_list(gfc_ref*) expr.c:599
#2 0x10012efdd in free_expr0(gfc_expr*) expr.c:505
#3 0x10012f3be in gfc_replace_expr(gfc_expr*, gfc_expr*) expr.c:616
#4 0x1001563b7 in simplify_ref_chain(gfc_ref*, int, gfc_expr**) expr.c:1970
#5 0x10015438e in gfc_simplify_expr(gfc_expr*, int) expr.c:2164
#6 0x100369eaf in gfc_match_varspec(gfc_expr*, int, bool, bool)
primary.c:2287
#7 0x1003798ba in gfc_match_rvalue(gfc_expr**) primary.c:3670
#8 0x1000c2f63 in match_data_constant(gfc_expr**) decl.c:379
#9 0x1000c4291 in top_val_list(gfc_data*) decl.c:478
#10 0x1000c4905 in gfc_match_data() decl.c:624
#11 0x10032fbc7 in match_word(char const*, match (*)(), locus*) parse.c:65
#12 0x10033d154 in decode_statement() parse.c:468
#13 0x10033ee0d in next_free() parse.c:1234
#14 0x10033f7d2 in next_statement() parse.c:1466
#15 0x100345d67 in parse_spec(gfc_statement) parse.c:3858
#16 0x10034c892 in parse_progunit(gfc_statement) parse.c:5671
#17 0x10034ec10 in gfc_parse_file() parse.c:6211
#18 0x100525304 in gfc_be_parse_file() f95-lang.c:204
#19 0x1062941c8 in compile_file() toplev.c:455
#20 0x10629f87c in do_compile() toplev.c:2172
#21 0x109388807 in toplev::main(int, char**) toplev.c:2307
#22 0x1097eaf4c in main main.c:39
#23 0x7fff703f908c in start (libdyld.dylib:x86_64+0x1708c)

previously allocated by thread T0 here:
#0 0x159489db3 in wrap_calloc sanitizer_malloc_mac.inc:132
#1 0x1088a10de in xcalloc xmalloc.c:162
#2 0x10035b5ae in is_inquiry_ref(char const*, gfc_ref**) primary.c:1964
#3 0x100368721 in gfc_match_varspec(gfc_expr*, int, bool, bool)
primary.c:2199
#4 0x1003798ba in gfc_match_rvalue(gfc_expr**) primary.c:3670
#5 0x1000c2f63 in match_data_constant(gfc_expr**) decl.c:379
#6 0x1000c4291 in top_val_list(gfc_data*) decl.c:478
#7 0x1000c4905 in gfc_match_data() decl.c:624
#8 0x10032fbc7 in match_word(char const*, match (*)(), locus*) parse.c:65
#9 0x10033d154 in decode_statement() parse.c:468
#10 0x10033ee0d in next_free() parse.c:1234
#11 0x10033f7d2 in next_statement() parse.c:1466
#12 0x100345d67 in parse_spec(gfc_statement) parse.c:3858
#13 0x10034c892 in parse_progunit(gfc_statement) parse.c:5671
#14 0x10034ec10 in gfc_parse_file() parse.c:6211
#15 0x100525304 in gfc_be_parse_file() f95-lang.c:204
#16 0x1062941c8 in compile_file() toplev.c:455
#17 0x10629f87c in do_compile() toplev.c:2172
#18 0x109388807 in toplev::main(int, char**) toplev.c:2307
#19 0x1097eaf4c in main main.c:39
#20 0x7fff703f908c in start (libdyld.dylib:x86_64+0x1708c)

SUMMARY: AddressSanitizer: heap-use-after-free expr.c:1943 in
simplify_ref_chain(gfc_ref*, int, gfc_expr**)
Shadow bytes around the buggy address:
  0x1c2e0860: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x1c2e0870: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x1c2e0880: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x1c2e0890: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x1c2e08a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd

[Bug c++/87229] [8/9 Regression] ICE: tree code 'call_expr' is not supported in LTO streams

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Richi are you planning to fix that, or is it a hard issue?

[Bug fortran/88076] Shared Memory implementation for Coarrays

[pault at gcc dot gnu.org]

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

--- Comment #1 from Paul Thomas  ---

> I have opened this bug to track the progress and provide a forum for
> discussion :)

Nicolas,

Once you are done on this, you might consider implementing a -parallel as in
ifort.

This could conveniently be triggered in frontend-passes.c, I suspect. ie. this
would be a good place to check for dependencies within a do loop and signal, if
there are none, that the loop can be parallelised. Then, with everything that
you have learned about trans-*.c in dealing with coarrays, you should be able
to do what is needed for do loops (and scalarization loops).

Just a thought.

Paul

PS I am just going to look at your last email to have a stab at answering your
question.

[Bug libstdc++/83566] cyl_bessel_j returns wrong result for x>1000 for high orders.

[emsr at gcc dot gnu.org]

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

--- Comment #3 from emsr at gcc dot gnu.org ---
Author: emsr
Date: Sun Nov 18 18:32:26 2018
New Revision: 266252

URL: https://gcc.gnu.org/viewcvs?rev=266252=gcc=rev
Log:
2018-11-16  Michele Pezzutti 
Edward Smith-Rowland  <3dw...@verizon.net>

PR libstdc++/83566 - cyl_bessel_j returns wrong result for x>1000
for high orders.
* include/tr1/bessel_function.tcc: Perform no fewer than nu/2
iterations
of the asymptotic series (nu is the Bessel order).
* testsuite/tr1/5_numerical_facilities/special_functions/
09_cyl_bessel_j/check_value.cc: Add tests at nu=100, 1000<=x<=2000.
* testsuite/tr1/5_numerical_facilities/special_functions/   
11_cyl_neumann/check_value.cc: Ditto.
* testsuite/special_functions/08_cyl_bessel_j/check_value.cc: Ditto.
* testsuite/special_functions/10_cyl_neumann/check_value.cc: Ditto.


Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/tr1/bessel_function.tcc
   
trunk/libstdc++-v3/testsuite/special_functions/08_cyl_bessel_j/check_value.cc
   
trunk/libstdc++-v3/testsuite/special_functions/10_cyl_neumann/check_value.cc
   
trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/09_cyl_bessel_j/check_value.cc
   
trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/11_cyl_neumann/check_value.cc

[Bug fortran/88073] [7/8 Regression] Internal compiler error compiling WHERE construct with -O or -O2

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Target Milestone|--- |7.4
Summary|Internal compiler error |[7/8 Regression] Internal
   |compiling WHERE construct   |compiler error  compiling
   |with -O or -O2  |WHERE construct with -O or
   ||-O2

[Bug target/88070] [8/9 Regression] ICE in create_pre_exit, at mode-switching.c:438

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-18
   Target Milestone|--- |7.4
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
This is the case of scheduler splitting return copy pair:

(insn 19 18 16 2 (set (reg:V2SF 21 xmm0)
(mem/c:V2SF (plus:DI (reg/f:DI 7 sp)
(const_int -72 [0xffb8])) [0  S8 A64]))
"pr88070.c":8 1157 {*movv2sf_internal}
 (nil))
(insn 16 19 20 2 (set (reg:V2SF 0 ax [orig:91  ] [91])
(reg:V2SF 0 ax [89])) "pr88070.c":8 1157 {*movv2sf_internal}
 (nil))
(insn 20 16 21 2 (unspec_volatile [
(const_int 0 [0])
] UNSPECV_BLOCKAGE) "pr88070.c":8 710 {blockage}
 (nil))
(insn 21 20 23 2 (use (reg:V2SF 21 xmm0)) "pr88070.c":8 -1
 (nil))

Please note how (insn 16) interferes with (insn 19)-(insn 21) pair.

I think that the assert is too restrictive for post-reload vzeroupper
insertion. There will be no end of problems, similar to the one above (mainly
due to pre-reload scheduler, or the RA itself), so I guess the following patch,
that relaxes the assert is justified:

--cut here--
Index: mode-switching.c
===
--- mode-switching.c(revision 266250)
+++ mode-switching.c(working copy)
@@ -431,11 +431,12 @@
  }
while (nregs);

-   /* If we didn't see a full return value copy, verify that there
-  is a plausible reason for this.  If some, but not all of the
-  return register is likely spilled, we can expect that there
-  is a copy for the likely spilled part.  */
-   gcc_assert (!nregs
+   /* Before reload, if we didn't see a full return value copy,
+  verify that there is a plausible reason for this.  If some,
+  but not all of the return register is likely spilled, we can
+  expect that there is a copy for the likely spilled part.  */
+   gcc_assert (reload_completed
+   || !nregs
|| forced_late_switch
|| short_block
|| !(targetm.class_likely_spilled_p
--cut here--

[Bug fortran/88073] Internal compiler error compiling WHERE construct with -O or -O2

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Nov 18 17:40:23 2018
New Revision: 266251

URL: https://gcc.gnu.org/viewcvs?rev=266251=gcc=rev
Log:
2018-11-18  Thomas Koenig  

PR fortran/88073
* frontend-passes.c (combine_array_constructor): Do not do
anything if in a WHERE statement.

2018-11-18  Thomas Koenig  

PR fortran/88073
* gfortran.dg/where_7.f90: New test.


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

[Bug fortran/88076] Shared Memory implementation for Coarrays

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-18
 Ever confirmed|0   |1

[Bug fortran/88076] New: Shared Memory implementation for Coarrays

[koenigni at gcc dot gnu.org]

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

Bug ID: 88076
   Summary: Shared Memory implementation for Coarrays
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: koenigni at gcc dot gnu.org
  Target Milestone: ---

At the moment, we only support coarrays using mpi (or if they only have single
image). Thomas & I are currently working on adding an implementation based upon
shared memory between processes that is maintained inside libgfortran. It will
be enabled by '-fcoarray=native'. This library will have to have a different
interface than '-fcoarray=lib'. 

At the moment, we have written a basic library with the necessary interprocess
allocator, simple synchronization routines and the functions for creating and
handling the image processes.

I am currently working on trans-* to emit the new initialization code and to
emit the direct memory accesses. Once this is done I will upload the first
prove-of-concept patch.

I have opened this bug to track the progress and provide a forum for discussion
:)

[Bug target/86806] SPARC port needs updating for CVE-2017-5753

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

   Target Milestone|--- |9.0
Summary|sparc port needs updating   |SPARC port needs updating
   |for CVE-2017-5753   |for CVE-2017-5753

[Bug target/86806] sparc port needs updating for CVE-2017-5753

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
Investigating.

[Bug target/87807] passing float/double vectors as variadic args fails on-64bit SPARC

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  ---
Investigating.

[Bug target/87807] passing float/double vectors as variadic args fails on-64bit SPARC

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Target|sparc-sun-solaris2.*|sparc64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-18
Summary|Passing float, double   |passing float/double
   |vectors as variadic args|vectors as variadic args
   |fails on sparcv9|fails on-64bit SPARC
 Ever confirmed|0   |1

--- Comment #2 from Eric Botcazou  ---
This very likely has never worked indeed.

[Bug c++/88075] New: [feature-request] allow "concept" instead of "concept bool" with -fconcepts

[h2+bugs at fsfe dot org]

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

Bug ID: 88075
   Summary: [feature-request] allow "concept" instead of "concept
bool" with -fconcepts
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: h2+bugs at fsfe dot org
  Target Milestone: ---

Concepts in C++20 are happening and the overlap with the concepts TS is very
significant which opens the possibility to write code in a dialect that is
accepted by both `-std=c++17 -fconcepts` and `-std=c++2a`. This is a huge bonus
for GCC over other implementations, because many long-term supported operating
systems ship GCC7 and won't pick up new compilers with full c++20 support for a
long time.

The only thing that prevents using the common subset is that concepts are
introduced by "concept bool" in the TS, but only by "concept" in the draft
standard. Instead of burdening the c++20 implementation with being compatible
to the TS, it would be really great if you could change the implementation of
the TS on GCC7 and GCC8 to also accept just "concept".

Note that I do not suggest backporting any features or other changes, this is
just about a small syntactical change that would allow cleanly writing code
that targets older and newer GCC versions at the same time. I assume this would
be greatly appreciated by quite a few libraries that currently employ different
concept-compatibility layers like range-v3, nanorange, cmstl2 and others. I
also expect more people will be interested in targeting the common concepts
dialect as Clang is picking up Concepts soon (the c++2a-feature branch works
quite well already).

[Bug driver/83243] -fuse-ld=lld

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #5 from H.J. Lu  ---
Fixed by

commit 4eea76dbfc871614e116961b048d9aa38eee66ea
Author: law 
Date:   Thu Nov 8 22:05:27 2018 +

* collect2.c (linker_select):  Add USE_LLD_LD.
(ld_suffixes): Add ld.lld.
(main): Handle -fuse-ld=lld.
* common.opt (-fuse-ld=lld): New option.
* doc/invoke.texi (-fuse-ld=lld): Document.
* opts.c (common_handle_option): Handle OPT_fuse_ld_lld.

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

[Bug fortran/88073] Internal compiler error compiling WHERE construct with -O or -O2

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Koenig  ---
I'll commit the following as obvious, probably today.

===
--- frontend-passes.c   (Revision 266250)
+++ frontend-passes.c   (Arbeitskopie)
@@ -1773,6 +1773,10 @@ combine_array_constructor (gfc_expr *e)
   if (iterator_level > 0)
 return false;

+  /* WHERE also doesn't work.  */
+  if (in_where > 0)
+return false;
+
   op1 = e->value.op.op1;
   op2 = e->value.op.op2;

[Bug target/87807] Passing float, double vectors as variadic args fails on sparcv9

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
Also happens on sparc64-linux-gnu with
gcc-9/8.2/7.3/6.4/5.5/4.9.4/4.8.5/4.7.4/4.6.4; 4.5.4 couldn't compile the test
case.

[Bug preprocessor/37549] gcc -E -dD prints predefined macros, contrary to docs

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #5 from sandra at gcc dot gnu.org ---
This preprocessor bug is still present on trunk.

[Bug target/36062] -mpc32,-mpc64, and -mpc80 are not documented properly

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org
  Component|other   |target

--- Comment #3 from sandra at gcc dot gnu.org ---
I'm not really familiar with all the x86 operating system variants.  Can one of
the target maintainers can make a list of which of them currently support these
options?

E.g. I see a reference in config/i386/sol2.h, but isn't Solaris 2 long
obsolete?

[Bug target/87771] My first 3d printer, and I messed up trying to update the .ini file. So, I'm trying to put the original software back in it, and I get this internal compiler error

[dory at satx dot rr.com]

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

--- Comment #10 from Donna Ory  ---
(In reply to Richard Biener from comment #3)
> Please provide a testcase - usually preprocessed source, commandline-options
> with -v appended.  See https://gcc.gnu.org/bugs.html
> 
> Note that GCC 5 and 6 are no longer supported so you need to update to GCC 7
> or newer.

Where do I go to get the update for GCC 7? I don't know how I have GCC 5 or 6.
I don't even know what it is. lol
Thanks!

[Bug other/87695] Fehler beim Kompilieren für das Board Arduino/Genuino Mega or Mega 2560.

[dory at satx dot rr.com]

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

--- Comment #3 from Donna Ory  ---
Sooo...what does that mean?
Do I still have a 3D printer that won't print because the problem lies with the
so called original program that I'm just trying to put back in it?

[Bug fortran/87969] -fcheck does not raise signal

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-11-18
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Dominique d'Humieres  ---
Whet happens with the other runtime errors? What is the behavior of the other
languages in GCC? What does other compilers?

[Bug fortran/87233] Constraint C1279 still followed after f2008 standard revision (?)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-18
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
(In reply to Jerry DeLisle from comment #1)
> The check is easy enough to delete:

More important: does gfortran generate the right code if the error is deleted?

[Bug fortran/70260] ICE: gimplification failed

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #8 from Thomas Koenig  ---
Fixed on trunk, no need to backport IMHO.

Closing. Thanks for the bug report!

[Bug fortran/70260] ICE: gimplification failed

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Nov 18 09:16:19 2018
New Revision: 266248

URL: https://gcc.gnu.org/viewcvs?rev=266248=gcc=rev
Log:
2018-11-18  Thomas Koenig  

PR fortran/70260
* expr.c (gfc_check_assign): Reject assigning to an external
symbol.
(gfc_check_pointer_assign): Add suppress_type_test
argument. Insert line after if. A non-proc pointer can not point
to a constant.  Only check types if suppress_type_test is false.
* gfortran.h (gfc_check_pointer_assign): Add optional
suppress_type_test argument.
* resolve.c (gfc_resolve_code):  Move up gfc_check_pointer_assign
and give it the extra argument.
(resolve_fl_procedure): Set error on value for a function with
an inizializer.

2018-11-18  Thomas Koenig  

PR fortran/70260
* gfortran.dg/proc_ptr_result_5.f90:  Add dg-error directive.
* gfortran.dg/protected_4.f90: Split line to allow for extra error.
* gfortran.dg/protected_6.f90: Likewise.
* gfortran.dg/assign_11.f90: New test.
* gfortran.dg/pointer_assign_12.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/assign_11.f90
trunk/gcc/testsuite/gfortran.dg/pointer_assign_12.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/proc_ptr_result_5.f90
trunk/gcc/testsuite/gfortran.dg/protected_4.f90
trunk/gcc/testsuite/gfortran.dg/protected_6.f90