[Bug c++/91217] Returning std::array from lambda results in an extra copy step on return

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #2 from Marc Glisse  ---
I didn't notice an extra copy. What I did notice is that in one case we don't
inline, and ldist turns the copying loop into memcpy, while in the other case
we do inline, and ldist (and vectorization) fail to handle a read from a
constant string as a memory read (they don't create a DR for it).

[Bug target/53633] __attribute__((naked)) should disable -Wreturn-type

[rsandifo at gcc dot gnu.org]

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

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Sun Jul 21 09:42:41 2019
New Revision: 273642

URL: https://gcc.gnu.org/viewcvs?rev=273642&root=gcc&view=rev
Log:
Fix -Wreturn-type for static naked functions in C

This patch extends the fix for PR53633 to include static functions,
which were giving a bogus -Wreturn-type warning for C but not for C++.

2019-07-21  Richard Sandiford  

gcc/c/
Backport from mainline
2019-07-18  Richard Sandiford  

PR c/53633
* c-decl.c (finish_function): Check targetm.warn_func_return
before issuing a -Wreturn-type warning.

gcc/testsuite/
Backport from mainline
2019-07-18  Richard Sandiford  

* c-c++-common/pr53633-2.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/c-c++-common/pr53633-2.c
Modified:
branches/gcc-8-branch/gcc/c/ChangeLog
branches/gcc-8-branch/gcc/c/c-decl.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug preprocessor/48839] #error should terminate compilation - similar to missing #include

[paolo.carlini at oracle dot com]

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

--- Comment #10 from Paolo Carlini  ---
Hi Eric

(In reply to Eric Gallager from comment #9)
> (In reply to Paolo Carlini from comment #8)
> > Hi. As you can see, the patch itself seems simple, but a while ago I noticed
> > that quite a few testcases would need adjusting and that made me a little
> > nervous. In particular those testcases (both C and C++) which are doing more
> > than one check and would have to be split, because the compilation ends
> > after the first #error. 
> 
> Which testcases are these?

Eric, It’s been a while, and I’m in the middle of a few other things, but you
can apply the patchlet (I’m pretty sure that it still applies as-is or with
minor variants) and see yourself! By the way, if you feel like immediately
pursuing the thing yourself, thus patch + testsuite tweaks + sending the whole
package to the mailing list for comments, by all means reassign the bug to
yourself and go ahead!

[Bug c++/78209] Decltype of rvalue reference

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-21
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/88227] ICE in gfc_convert_boz, at fortran/target-memory.c:788

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
The following test giveS ALSO an ICE with -m32

% cat boz_10.f90
print *, real(b'1010101001101',10)
end
% gfortran -m32 boz_10.f90
f951: internal compiler error: Segmentation fault: 11
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian

[tkoenig at gcc dot gnu.org]

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

--- Comment #40 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Jul 21 15:55:49 2019
New Revision: 273643

URL: https://gcc.gnu.org/viewcvs?rev=273643&root=gcc&view=rev
Log:
2019-07-21  Thomas König  

PR libfortran/91030
* gfortran.texi (GFORTRAN_FORMATTED_BUFFER_SIZE): Document
(GFORTRAN_UNFORMATTED_BUFFER_SIZE): Likewise.

2019-07-21  Thomas König  

PR libfortran/91030
* io/unix.c (BUFFER_SIZE): Delete.
(BUFFER_FORMATTED_SIZE_DEFAULT): New variable.
(BUFFER_UNFORMATTED_SIZE_DEFAULT): New variable.
(unix_stream): Add buffer_size.
(buf_read): Use s->buffer_size instead of BUFFER_SIZE.
(buf_write): Likewise.
(buf_init): Add argument unformatted.  Handle block sizes
for unformatted vs. formatted, using defaults if provided.
(fd_to_stream): Add argument unformatted in call to buf_init.
* libgfortran.h (options_t): Add buffer_size_formatted and
buffer_size_unformatted.
* runtime/environ.c (variable_table): Add
GFORTRAN_UNFORMATTED_BUFFER_SIZE and
GFORTRAN_FORMATTED_BUFFER_SIZE.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.texi
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/unix.c
trunk/libgfortran/libgfortran.h
trunk/libgfortran/runtime/environ.c

[Bug middle-end/61577] [4.9.0] can't compile on hp-ux v3 ia64

[cameron.heide at betasystems dot com]

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

--- Comment #71 from C. Heide  ---
Created attachment 46616
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46616&action=edit
Different output for revs r214744 and r214747

I did a bit of bisecting and the EOF conftest crash started occurring at
revision r214747
(https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=214747).

The previous revision (r214744) isn't quite a working compiler as it hits an
ICE in stage 2, but that seems to be a frequently recurring one (ICE in
plus_constant while building charset.c) and it does at least make it past the
EOF test and on to stage 2.

Attached are the output RTL and assembly files for the conftest for both revs,
in case that helps.

[Bug middle-end/61577] [4.9.0] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #72 from dave.anglin at bell dot net ---
On 2019-07-21 2:56 p.m., cameron.heide at betasystems dot com wrote:
> I did a bit of bisecting and the EOF conftest crash started occurring at
> revision r214747
> (https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=214747).

Excellent!  Does this help?

Index: expr.c
===
--- expr.c  (revision 273643)
+++ expr.c  (working copy)
@@ -344,6 +344,11 @@

 if (GET_MODE_PRECISION (from_mode) > GET_MODE_PRECISION (to_mode))
   ctab = trunc_optab;
+else if (unsignedp < 0 && targetm.have_ptr_extend ())
+  {
+   emit_unop_insn (targetm.code_for_ptr_extend, to, from, UNKNOWN);
+   return;
+  }
 else if (unsignedp)
   ctab = zext_optab;
 else

[Bug target/90363] or1k: Extra mask insn after load from memory

[shorne at gcc dot gnu.org]

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

--- Comment #3 from Stafford Horne  ---
Author: shorne
Date: Sun Jul 21 20:58:54 2019
New Revision: 273647

URL: https://gcc.gnu.org/viewcvs?rev=273647&root=gcc&view=rev
Log:
or1k: Fix code quality for volatile memory loads

Volatile memory does not match the memory_operand predicate.  This
causes extra extend/mask instructions instructions when reading
from volatile memory.  On OpenRISC loading volatile memory can be
treated the same as regular memory loads which supports combined
sign/zero extends.  Fixing this eliminates the need for extra
extend/mask instructions.

This also adds a test provided by Richard Selvaggi which uncovered the
issue while we were looking into another issue.

gcc/ChangeLog:

PR target/90363
* config/or1k/or1k.md (zero_extendsi2): Update predicate.
(extendsi2): Update predicate.
* gcc/config/or1k/predicates.md (volatile_mem_operand): New.
(reg_or_mem_operand): New.

gcc/testsuite/ChangeLog:

PR target/90363
* gcc.target/or1k/swap-1.c: New test.
* gcc.target/or1k/swap-2.c: New test.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/or1k/or1k.md
trunk/gcc/config/or1k/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug target/90362] or1k: Soft divide does not work correctly

[shorne at gcc dot gnu.org]

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

--- Comment #3 from Stafford Horne  ---
Author: shorne
Date: Sun Jul 21 20:59:50 2019
New Revision: 273648

URL: https://gcc.gnu.org/viewcvs?rev=273648&root=gcc&view=rev
Log:
or1k: Fix issues with msoft-div

Fixes bad assembly logic with software divide as reported by Richard Selvaggi.
Also, add a basic test to verify the soft math works when enabled.

gcc/testsuite/ChangeLog:

PR target/90362
* gcc.target/or1k/div-mul-3.c: New test.

libgcc/ChangeLog:

PR target/90362
* config/or1k/lib1funcs.S (__udivsi3): Change l.sfeqi
to l.sfeq and l.sfltsi to l.sflts equivalents as the immediate
instructions are not available on every processor.  Change a
l.bnf to l.bf to fix logic issue.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgcc/ChangeLog
trunk/libgcc/config/or1k/lib1funcs.S

[Bug target/90363] or1k: Extra mask insn after load from memory

[shorne at gcc dot gnu.org]

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

Stafford Horne  changed:

   What|Removed |Added

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

--- Comment #4 from Stafford Horne  ---
The fix for this has been committed to SVN.

[Bug target/90362] or1k: Soft divide does not work correctly

[shorne at gcc dot gnu.org]

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

Stafford Horne  changed:

   What|Removed |Added

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

--- Comment #4 from Stafford Horne  ---
The fix for this has been committed to SVN.

[Bug c++/67853] decltype of parenthesized xvalue does not correctly yield rvalue-reference

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-07-21
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Fixed by r260621.

[Bug c++/67853] decltype of parenthesized xvalue does not correctly yield rvalue-reference

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Sun Jul 21 21:20:27 2019
New Revision: 273652

URL: https://gcc.gnu.org/viewcvs?rev=273652&root=gcc&view=rev
Log:
PR c++/67853
* g++.dg/cpp0x/decltype72.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/decltype72.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/54366] [meta-bug] decltype issues

[mpolacek at gcc dot gnu.org]

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

Bug 67853 Summary: decltype of parenthesized xvalue does not correctly yield 
rvalue-reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67853

   What|Removed |Added

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

[Bug c++/67853] decltype of parenthesized xvalue does not correctly yield rvalue-reference

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Test added.

[Bug middle-end/87256] hppa spends huge amount of time in synth_mult()

[danglin at gcc dot gnu.org]

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

--- Comment #11 from John David Anglin  ---
I tend to think there may be an issue with costs.  There is no pattern
for muldi3 on 32-bit hppa, so we use the generic code from libgcc.  How
do we know the cost for this routine?

If synth_mult is disabled, the testcase takes a fraction of a second to
compile.  The only difference in the generated code is for "case 6" where
the multiplication by 13 is done using shift add.

[Bug driver/91220] New: -Q --help=common displays options limited to subsets of languages

[msebor at gcc dot gnu.org]

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

Bug ID: 91220
   Summary: -Q --help=common displays options limited to subsets
of languages
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While testing a fix for bug 80545 I noticed that the --help=common option has
GCC list options that are only available in a subset of languages even though
it is documented to "Display the options that are common to all languages."

Here's the output for a subset of language-specific options:

$ gcc -Q --help=common -xc - | grep -E
"(-Wcpp|-Wdeprecated|-Wmisleading-indentation|-Wstrict-aliasing|-Wstrict-overflow|-Wsystem-headers|-Wunused)"
  -Wcpp [enabled]
  -Wdeprecated  [enabled]
  -Wdeprecated-declarations [enabled]
  -Wmisleading-indentation  [disabled]
  -Wstrict-aliasing 
  -Wstrict-aliasing=<0,3>   0
  -Wstrict-overflow 
  -Wstrict-overflow=<0,5>   0
  -Wsystem-headers  [disabled]
  -Wunused  [disabled]
  -Wunused-but-set-parameter[disabled]
  -Wunused-but-set-variable [disabled]
  -Wunused-function [disabled]
  -Wunused-label[disabled]
  -Wunused-parameter[disabled]
  -Wunused-value[disabled]
  -Wunused-variable [disabled]

The following is the output of GCC patched to list the strict subset of
languages in which each of the options is available in, and configured with
-enable-languages=all:

  -Wcpp [available in C, C++, ObjC, ObjC++]
  -Wdeprecated  [available in C, C++, D, ObjC, ObjC++]
  -Wdeprecated-declarations [enabled]
  -Wmisleading-indentation  [available in C, C++]
  -Wstrict-aliasing [enabled]
  -Wstrict-aliasing=<0,3>   [available in C, C++, ObjC, ObjC++]
  -Wstrict-overflow [enabled]
  -Wstrict-overflow=<0,5>   [available in C, C++, ObjC, ObjC++]
  -Wsystem-headers  [available in C, C++, ObjC, ObjC++]
  -Wunused  [available in C, C++, ObjC, ObjC++]
  -Wunused-but-set-parameter[disabled]
  -Wunused-but-set-variable [disabled]
  -Wunused-function [disabled]
  -Wunused-label[disabled]
  -Wunused-parameter[disabled]
  -Wunused-value[disabled]
  -Wunused-variable [available in C, C++, ObjC, ObjC++]

[Bug driver/80545] option -Wstringop-overflow not recognized by Fortran

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
As best I can tell the problem is that the option_enabled() function doesn't
consider the front-end's lang_mask and returns true even for options that are
not supported in the current language.  I'm working on a fix.

[Bug ipa/91194] A suspicious condition in recursive_inlining

[fxue at os dot amperecomputing.com]

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

Feng Xue  changed:

   What|Removed |Added

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

--- Comment #4 from Feng Xue  ---
Fixed

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[cameron.heide at betasystems dot com]

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

C. Heide  changed:

   What|Removed |Added

 CC||cameron.heide at betasystems 
dot c
   ||om

--- Comment #73 from C. Heide  ---
With that change, and some other cajoling (the previously mentioned duplicate
symbols and operand64 problem, and -O1 to work around the ICE), I can now get
gcc-8.3 to do a full bootstrap on HP-UX 11.23 ia64.

I haven't run the GCC testsuite yet, but it was able to build an internal C++
app and pass its unit tests, though it did still need the duplicate symbol
workaround when linking (added -Wl,+allowdups).

[Bug middle-end/91195] [10 regression] incorrect may be used uninitialized smw (272711, 273474]

[jiangning.liu at amperecomputing dot com]

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

--- Comment #3 from Jiangning Liu  ---
The gcc compilation difference between FOR_UP_LIMIT is 3 and 4 is that,
cunrolli can do loop unrolling when FOR_UP_LIMIT is 3, for which the control
flow can be significantly simplified, so the conditional store optimization in
phiopt will not be triggered.

The following code is generated with conditional store optimization, and
"cstore_8 = MEM  [(void *)&Msg][0];" is inserted in the else branch
"if (m1_9(D) != 0B)" statement.

   [local count: 214748364]:
  if (m1_9(D) != 0B)
goto ; [70.00%]
  else
goto ; [30.00%]

   [local count: 64424509]:
  cstore_8 = MEM  [(void *)&Msg][0];

   [local count: 214748364]:
  # num_2 = PHI <1(2), 0(3)>
  # cstore_4 = PHI 
  MEM  [(void *)&Msg][0] = cstore_4;

The possible solution is to disable this optimization when
"-Werror=maybe-uninitialized" is enabled.

[Bug fortran/34528] Document internal structure of arrays

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
(In reply to Tobias Burnus from comment #0)
> http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/
> 80093a381db184c6/
> 
> This interface is needed if one wants pass an array descriptor to C; other
> vendors have such a documentation as well. It should come with a note that
> the interface may change between versions.
> 
> Other compilers have this as well, e.g,
> http://www.intel.com/software/products/compilers/docs/flin/main_for/
> mergedProjects/bldaps_for/common/bldaps_hndl_arrdesc.htm

Link is dead; here is an archive dot org saved copy of it: 
http://web.archive.org/web/20100129054945/http://www.intel.com/software/products/compilers/docs/flin/main_for/mergedProjects/bldaps_for/common/bldaps_hndl_arrdesc.htm

> 
> If not for the gfortran documentation, one could add it to gfortran-internal.