[Bug tree-optimization/85757] tree optimizers fail to fully clean up fixed-size memcpy

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Fixed on trunk.

[Bug tree-optimization/85757] tree optimizers fail to fully clean up fixed-size memcpy

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Thu May 17 06:57:45 2018
New Revision: 260306

URL: https://gcc.gnu.org/viewcvs?rev=260306&root=gcc&view=rev
Log:
2018-05-17  Richard Biener  

PR tree-optimization/85757
* tree-ssa-dse.c (dse_classify_store): Record a PHI def and
remove defs that only feed that PHI from further processing.

* gcc.dg/tree-ssa/ssa-dse-34.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-34.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dse.c

[Bug middle-end/85599] Prevent short-circuiting of logical expressions for non-pure functions

[janus at gcc dot gnu.org]

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

--- Comment #23 from janus at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #21)
> If we make guarantees that the standard does not, we will be
> creating our own language

I certainly don't want to create my own language. I'm trying to use the freedom
that the Fortran standard (unfortunately) gives in this area in a reasonable
way.


> (and people will get problems moving
> code to another compiler).

We do have problems with compiler-dependent behavior already. The behavior I'm
proposing is consistent with what ifort, PGI and flang do.


> Warn, yes.  This is the kind of thing that -Wsurprising is for,
> so people will get something with -Wall. (I volunteer for that).

What do you want to warn about? And how?


> Optimize, yes.  This could also be integrated with the warning.

Optimize, yes, but not at the price of changing results.


> Change the language, no.

Agreed.

[Bug middle-end/85599] Prevent short-circuiting of logical expressions for non-pure functions

[pinskia at gcc dot gnu.org]

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

--- Comment #22 from Andrew Pinski  ---
I don't think the middle end can even change. the semantics of TRUTH_ANDIF_EXPR
is always to short circuit. If you want a non short circuit you need to use
TRUTH_AND_EXPR

[Bug middle-end/85599] Prevent short-circuiting of logical expressions for non-pure functions

[tkoenig at gcc dot gnu.org]

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

--- Comment #21 from Thomas Koenig  ---

> Well, that was absolutely not my intention when I opened this PR, and it
> still isn't. Quite the opposite: I don't think gfortran should apply more
> optimizations, but less. I'm changing the title and keyword again to reflect
> that.

I am strictly opposed to that.

If we make guarantees that the standard does not, we will be
creating our own language (and people will get problems moving
code to another compiler). F has tried that, and failed.

Warn, yes.  This is the kind of thing that -Wsurprising is for,
so people will get something with -Wall. (I volunteer for that).

Optimize, yes.  This could also be integrated with the warning.

Change the language, no.

[Bug ada/85760] Using generic function to initialize a type created by a generic package crashes GNAT

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
> I only filed the report here once (at least purposely).

Didn't you file exactly the same bug report with AdaCore?

[Bug middle-end/85599] Prevent short-circuiting of logical expressions for non-pure functions

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords|diagnostic, |wrong-code
   |missed-optimization |
Summary|Function need not be|Prevent short-circuiting of
   |evaluated in logical|logical expressions for
   |expression  |non-pure functions

--- Comment #20 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #18)
> This PR is now about a missed optimization in the middle-end.

Well, that was absolutely not my intention when I opened this PR, and it still
isn't. Quite the opposite: I don't think gfortran should apply more
optimizations, but less. I'm changing the title and keyword again to reflect
that.

If anyone is interested in fixing some possible missed-optimization problem,
please open a new PR for that.

[Bug middle-end/85599] Function need not be evaluated in logical expression

[janus at gcc dot gnu.org]

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

--- Comment #19 from janus at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #17)
> Then you are only interest in the special case of .and.
> 
> binop above is the entire collection of all binary
> operators (e.g., +,-,*,/ etc as well as .and.).

The original problem of ill-posed short-circuiting does not apply to all binary
operators, but only to things like:

* X = .false. .and. Y()
* X = .true. .or. Y()

and possibly:

* X = 0 * Y()
* X = 0 / Y()

(in case gfortran applies 'short-circuiting' for such cases, which I haven't
checked).

There might be other cases as well, but it certainly does not apply to + and -.


> The order of the evaluation of ping() and pong() is 
> not specified by the Fortran standard.

This PR is not about reordering, but about short-circuiting.

[Bug libstdc++/71181] Reserving in unordered_map doesn't reserve enough

[fdumont at gcc dot gnu.org]

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

François Dumont  changed:

   What|Removed |Added

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

--- Comment #7 from François Dumont  ---
Indeed, it has been fixed.

[Bug c/85814] New: ICE Segmentation fault during GIMPLE pass: strlen -O3 and above

[zeccav at gmail dot com]

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

Bug ID: 85814
   Summary: ICE Segmentation fault during GIMPLE pass: strlen -O3
and above
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 44141
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44141&action=edit
Preprocessed C source to be compiled with -O3 or above

// gcc 9.0.0 trunk 260152 ICE Segmentation fault during GIMPLE pass: strlen
// must be compiled with option -O3 or above
//gcc -S ~/f95/cc/gccerr68.c -O3
//during GIMPLE pass: strlen
///home/vitti/f95/cc/gccerr68.c: In function
‘cp_units_MP_cp_basic_unit_desc.constprop’:
///home/vitti/f95/cc/gccerr68.c:6388:6: internal compiler error: Segmentation
fault
// void
cp_units_MP_cp_basic_unit_desc(res_,res_Len,basic_kind_,basic_unit_,power_,accept_undefined_)
//  ^~
//0xc74eaf crash_signal
//  ../../gcc-260152/gcc/toplev.c:325
//0x15440fa5ffcf ???
// 
/usr/src/debug/glibc-2.27-37-g39071a5539/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
//0xe2b8ee unshare_strinfo
//  ../../gcc-260152/gcc/tree-ssa-strlen.c:721
//0xe2dd5c get_stridx_plus_constant
//  ../../gcc-260152/gcc/tree-ssa-strlen.c:800
//0xe2e2c4 get_stridx
//  ../../gcc-260152/gcc/tree-ssa-strlen.c:325
//0xe3343b handle_pointer_plus
//  ../../gcc-260152/gcc/tree-ssa-strlen.c:2777
//0xe3343b strlen_check_and_optimize_stmt
//  ../../gcc-260152/gcc/tree-ssa-strlen.c:3237
//0xe3343b strlen_dom_walker::before_dom_children(basic_block_def*)
//  ../../gcc-260152/gcc/tree-ssa-strlen.c:3521
//0x13d1c02 dom_walker::walk(basic_block_def*)
//  ../../gcc-260152/gcc/domwalk.c:353
//0xe34822 execute
//  ../../gcc-260152/gcc/tree-ssa-strlen.c:3601
//Please submit a full bug report,
//with preprocessed source if appropriate.
//Please include the complete backtrace with any bug report.
//See  for instructions.

[Bug libstdc++/85813] New: make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions

[redbeard0531 at gmail dot com]

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

Bug ID: 85813
   Summary: make_exception_ptr should support
__cxa_init_primary_exception path even with
-fno-exceptions
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

It looks like nothing in that path actually needs exception support. This would
allow make_exception_ptr to produce a valid exception_ptr even in TUs that
don't support exceptions. While that may not sound valuable, the exception_ptr
could be handed to TUs that do support exceptions where it can be rethrown (a
misnomer in this case...) and caught.

Also, if my paper http://wg21.link/p1066 is accepted, that would provide full
support for handling the exception without ever throwing it. And if this ticket
is impossible to implement for some reason, I'd love to know that before
Rapperswil ;)

The nullptr return was added in response to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64241, but it looks like that was
done before the __cxa_init_primary_exception path existed. When that was added
in
https://github.com/gcc-mirror/gcc/commit/cce8e59224e18858749a2324bce583bcfd160d6c#diff-e1b5856b8cc940de58c12ef252d63c34R188,
I can't tell if it was put in the #if __cpp_exceptions block for a good reason
or just by default.

[Bug libstdc++/85812] New: make_exception_ptr can leak the allocated exception if construction throws

[redbeard0531 at gmail dot com]

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

Bug ID: 85812
   Summary: make_exception_ptr can leak the allocated exception if
construction throws
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

I think if this line throws the exception allocated on line 185 will leak:
https://github.com/gcc-mirror/gcc/blob/3474beffb1fd23da44a752763e648d5d1ffa4d0f/libstdc%2B%2B-v3/libsupc%2B%2B/exception_ptr.h#L189.

[Bug lto/85801] LTO linking fails to reconcile symbol from common an data sections (-fPIE -Wl,--as-needed -flto): unresolvable R_ARM_REL32 relocation against symbol `progname'

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
For LDPR_PREVAILING_DEF_IRONLY_EXP, if the IR definition is common,
compiler can't assume that the IR definition will prevail during the
final link.  This is another COMMON symbol issue like

https://sourceware.org/bugzilla/show_bug.cgi?id=23079

[Bug ada/85760] Using generic function to initialize a type created by a generic package crashes GNAT

[jhb.chat at gmail dot com]

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

--- Comment #5 from Jere  ---
Created attachment 44140
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44140&action=edit
combined ada files in (hopefully) gnatchop friendly format

[Bug ada/85760] Using generic function to initialize a type created by a generic package crashes GNAT

[jhb.chat at gmail dot com]

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

--- Comment #4 from Jere  ---
I only filed the report here once (at least purposely).  The website was laggy
when I submitted so perhaps it got submitted twice accidentally?  My side of
the interface only shows 2 bugs from me that are completely different from each
other (one from Jan and this one).  I am unfamiliar with gnatchop, so I'll look
into it and update this one when I figure out how to do it.

[Bug c/85810] gcc incorrectly handles declarations inside parameter lists of function declarators.

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
On Wed, 16 May 2018, cookevillain at yahoo dot com wrote:

> The Standard is supposed to be a formal specification of the language, so if

No, it isn't.  It's for humans, who need to interpret things in an 
appropriate context.  As I said, editorial issues should go direct to the 
project editors.

[Bug c++/69905] Digit separators break literal operators

[andreas.molzer at gmx dot de]

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

andreas.molzer at gmx dot de changed:

   What|Removed |Added

 CC||andreas.molzer at gmx dot de

--- Comment #7 from andreas.molzer at gmx dot de ---
Leaving out the overload for operator""s(long double) will silently break valid
code. Consider:

#include 
int main() {
using std::chrono_literals;
auto time = operator""s(0x8000'''''ULL);
}

According to standard, this should select the overload with unsigned long long
argument, which does not exist.  It will instead silently perform a numeric
conversion to long double, resulting in loss of accuracy on targets where gcc
does not use extended 80-bit double.  Any other integer arguments, which should
lead to overload resolution failure, will also be double durations albeit with
less immediately catastrophic results. 

However, that doesn't mean the long term effects are no issue.  Consider that
the type of time.count() also unexpectedly resolves as long double.  Or even
worse that assigning decltype(time)::max() to unsigned long long is undefined
behaviour.

It might be more fitting to open the missing declarations as a separately
tracked bug, improving visibility of the standard issue as well.

[Bug rtl-optimization/85811] Invalid optimization with fmax, fabs and nan

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
What does tree_expr_nonnegative_p call non-negative? A natural definition would
exclude NaN, but for REAL_CST we just return ! REAL_VALUE_NEGATIVE.

[Bug c/85810] gcc incorrectly handles declarations inside parameter lists of function declarators.

[cookevillain at yahoo dot com]

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

--- Comment #2 from cookevillain at yahoo dot com ---
There is nothing obvious about the intent of the Standard here (see the
definition of type name scope introduced into the standard to handle a similar
formal issue). Grammatically, parameter declarations are not identical to
ordinary declarations so  6.7.6.3(18) is only tangentially relevant here (where
tag declarations are considered). 

The Standard is supposed to be a formal specification of the language, so if
the implementors feel they implement what is intended and not what is written
this creates a problem for compiler users (especially those of us who write
formal verification tools). I have no problem accepting that gcc implements a
version of C11 that is better than the standard one, however 'perverse' is bit
too strong a term, maybe 'literal' is more appropriate.

[Bug middle-end/85599] Function need not be evaluated in logical expression

[dominiq at lps dot ens.fr]

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

--- Comment #18 from Dominique d'Humieres  ---
This PR is now about a missed optimization in the middle-end.

Would it possible to move further discussions to pr57160? TIA.

[Bug rtl-optimization/85811] Invalid optimization with fmax, fabs and nan

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> case MAX_EXPR:
>   return RECURSE (op0) || RECURSE (op1);
> 
> This is not true if one is a NAN.

And the reason why it is not true for NAN is simple:
If one of the two arguments is NaN, the value of the other argument is returned

[Bug rtl-optimization/85811] Invalid optimization with fmax, fabs and nan

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
case MAX_EXPR:
  return RECURSE (op0) || RECURSE (op1);

This is not true if one is a NAN.

[Bug rtl-optimization/85811] Invalid optimization with fmax, fabs and nan

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Applying pattern match.pd:832, gimple-match.c:11245
> Match-and-simplified ABS_EXPR  to val_5

Which is:
(simplify
 (abs tree_expr_nonnegative_p@0)
 @0)

[Bug rtl-optimization/85811] Invalid optimization with fmax, fabs and nan

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Applying pattern match.pd:832, gimple-match.c:11245
Match-and-simplified ABS_EXPR  to val_5

[Bug rtl-optimization/85811] Invalid optimization with fmax, fabs and nan

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
tree_binary_nonnegative_warnv_p for RDIV_EXPR does RECURSE (op0) && RECURSE
(op1), but that doesn't work so well when the denominator can be 0. I guess it
is still ok when finite-math-only (or no-nans and no-signed-zeros maybe?), or
when we can prove that the denominator is non-zero.

[Bug middle-end/85599] Function need not be evaluated in logical expression

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #17 from Steve Kargl  ---
On Wed, May 16, 2018 at 08:41:42AM +, janus at gcc dot gnu.org wrote:
> 
> > and implement it to transform
> > result = op1 binop op2
> > 
> > into
> > 
> > tmp1 = op1
> > tmp2 = op2
> > result = tmp1 BINOP tmp2
> 
> That's not what I had in mind. I'd rather make a change from
> 
> result = op1 && op2
> 
> to
> 
> result = op1 & op1
> 

Then you are only interest in the special case of .and.

binop above is the entire collection of all binary
operators (e.g., +,-,*,/ etc as well as .and.).

What about

real x, ping, pong
external ping, pong
x = ping() + pong() 

where both ping() and pong() have competing side effects.
The order of the evaluation of ping() and pong() is 
not specified by the Fortran standard.

[Bug rtl-optimization/85811] New: Invalid optimization with fmax, fabs and nan

[mpeddie at gmail dot com]

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

Bug ID: 85811
   Summary: Invalid optimization with fmax, fabs and nan
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpeddie at gmail dot com
  Target Milestone: ---

Created attachment 44139
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44139&action=edit
Preprocessed source file

I apologize in advance if I've chosen the wrong category for this bug; I have
to choose a category and don't know what's correct.

The output from my small test program varies depending on whether I enable
optimizations with -O.  The un-preprocessed program is the following
(preprocessed output attached):

#include 
#include 
#include 

int main(int argc __attribute__((unused)), char **argv
__attribute__((unused))) {
  const double negval = -1.0;
  const double nanval = 0.0 / 0.0;
  const double val = fmax(negval, nanval);
  const double absval = fabs(val);
  printf("fabs(%.16e) = %.16e\n", val, absval);
  return absval >= 0 ? 0 : 1;
}

With optimizations enabled, this prints

fabs(-1.e+00) = -1.e+00

and returns 1.  This result is wrong (the absolute value must be positive). 
Without optimizations, it prints

fabs(1.e+00) = 1.e+00

and returns 0 as expected.  If I make the arguments to fmax() depend on inputs,
for example the value of argc, the program behaves correctly.  If I call fmin()
instead of fmax(), the program behaves correctly.  If neither of the arguments
to fmax() is NaN, the program behaves correctly; the correct behavior happens
if one argument is -NaN, INFINITY or -INFINITY.  The order of arguments to
fmax() does not affect the result of the program.

If I look at the generated assembly, substituting fmin() for fmax() in the test
program results in an andpd instruction immediately after fmin() that isn't
emitted when fmax() is called.

The attached file test.i is the preprocessed source file.  The test program
compiles without errors or warnings and never triggers the undefined-behavior
sanitizer.  I've observed the same problem with gcc version 7.3.0 and 6.4.0 for
x86_64 as well as gcc version 6.3.0 for arm32.  I don't see the problem with
gcc version 5.5.0 for x86_64.  Below is the command-line invocation of gcc
along with its complete output.




gcc-8 -v -save-temps -O -Wall -Wextra -Werror -fsanitize=undefined
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -lm test.c -o
test

Using built-in specs.
COLLECT_GCC=gcc-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.1.0-3'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.1.0 (Debian 8.1.0-3)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O' '-Wall' '-Wextra' '-Werror'
'-fsanitize=undefined' '-fno-strict-aliasing' '-fwrapv'
'-fno-aggressive-loop-optimizations' '-o' 'test' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu
test.c -mtune=generic -march=x86-64 -Wall -Wextra -Werror -fsanitize=undefined
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -O
-fpch-preprocess -o test.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/8/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O' '-Wall' '-Wextra' '-Werror'
'-fsanitize=undefined' '-fno-strict-aliasing' '-fwrapv'
'-fno-agg

[Bug c++/85363] Throwing exception from member constructor (brace initializer vs initializer list)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
Fixed for GCC 9.

[Bug c++/85363] Throwing exception from member constructor (brace initializer vs initializer list)

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Author: mpolacek
Date: Wed May 16 20:37:45 2018
New Revision: 260300

URL: https://gcc.gnu.org/viewcvs?rev=260300&root=gcc&view=rev
Log:
PR c++/85363
* call.c (set_flags_from_callee): Handle AGGR_INIT_EXPRs too.
* tree.c (bot_manip): Call set_flags_from_callee for
AGGR_INIT_EXPRs too.

* g++.dg/cpp0x/initlist-throw1.C: New test.
* g++.dg/cpp0x/initlist-throw2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist-throw1.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist-throw2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug c/85810] gcc incorrectly handles declarations inside parameter lists of function declarators.

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
This is an obviously perverse interpretation of the standard that is 
inconsistent with the intent expressed explicitly if non-normatively in 
6.7.6.3#18 ("The identifiers x and y are declared for descriptive purposes 
only and go out of scope at the end of the declaration of apfi.", in the 
context of an example declaring an array of pointers to function).

When you have editorial issues where the wording of the standard could 
more clearly express the intent you should take them direct to the editors 
of the standard, not to implementors.

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=82063

--- Comment #11 from Eric Gallager  ---
(In reply to Alexander Monakov from comment #10)
> Reopening: the request to be able to disable the warning (via
> -Wno-alloc-size-larger-than) is valid and should be addressed.

I think that part is bug 82063

[Bug c++/85714] -Wimplicit-fallthrough and nested exhaustive switch statements with enum classes and return

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
The enumeration type can take any value from (Foo)INT_MIN to (Foo)INT_MAX, and
likewise for Bar. Your switches are not exhaustive.

I think we need a FAQ about this, we have so many invalid bug reports like
this.

[Bug middle-end/85682] Regression: gcc.dg/tree-ssa/prefetch-5.c at r259995

[luis.machado at linaro dot org]

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

--- Comment #4 from Luis Machado  ---
(In reply to James Greenhalgh from comment #3)
> The bisect robot doesn't bootstrap, only build a stage 1 compiler.
> 
> I've checked your most recent patch against these testcases, and they
> execute and complete fine.
> 

Thanks for checking it.

> (In reply to Luis Machado from comment #2)
> > I did a fresh x86-64 bootstrap with the changes in and those prefetch tests
> > are not executed as part of dg.exp. Running by hand they look sane to me.
> 
> I'm sure this is just a typo, but you probably didn't mean "dg.exp" in this
> case - the prefetch tests are in tree-ssa.exp and the opt-1 and opt-2 tests
> are in i386.exp .

Correct. I had the prefetch-* tests in mind when i mentioned dg.exp, but then
noticed they were grouped within tree-ssa.exp.

[Bug c++/85714] -Wimplicit-fallthrough and nested exhaustive switch statements with enum classes and return

[rs2740 at gmail dot com]

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

--- Comment #4 from TC  ---
[dcl.enum]p4:

The underlying type can be explicitly specified using an enum-base. For a
scoped enumeration type, the underlying type is int if it is not explicitly
specified. In both of these cases, the underlying type is said to be fixed.

p8:

For an enumeration whose underlying type is fixed, the values of the
enumeration are the values of the underlying type.

[Bug c++/85714] -Wimplicit-fallthrough and nested exhaustive switch statements with enum classes and return

[thomas.o...@pdv-fs.de]

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

--- Comment #3 from Thomas Otto  ---
I thought forcing out-of-range enum values is no longer unspecified but now
undefined behavior in C++17:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1766
http://obiwahn.org/c++draft/expr.static.cast/#10

> The value is unchanged if the original value is within the range of the 
> enumeration values ([dcl.enum]). Otherwise, the behavior is undefined.

And this warning also shows up with -std=c++17

[Bug c/85810] New: gcc incorrectly handles declarations inside parameter lists of function declarators.

[cookevillain at yahoo dot com]

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

Bug ID: 85810
   Summary: gcc incorrectly handles declarations inside parameter
lists of function declarators.
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cookevillain at yahoo dot com
  Target Milestone: ---

Clause 6.2.1(2) of the C11 ISO Standard (draft) defines a function prototype as
follows:

A function prototype is a declaration of a function that declares the types of
its parameters.

In the following translation unit

int (*func)( struct tag { int mem; } ); 
struct tag array[42];

the declaration for f is a declaration of a pointer, not a function, hence
there is no function prototype involved. Therefore, 'tag' should have file
scope and the translation unit should be conforming. Instead gcc diagnoses an
`array of incomplete types' error for 'a'.

The discussion in 

https://stackoverflow.com/questions/50371169/do-parameter-declarations-in-function-declarators-have-function-prototype-scope

is relevant here, as well.

[Bug c++/85662] [8/9 Regression] "error: non-constant condition for static assertion" from __builtin_offsetof in C++

[roland at gnu dot org]

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

--- Comment #6 from roland at gnu dot org ---
Thanks for the fix.  What's the status on backporting this to 8 and/or 7?

[Bug middle-end/85682] Regression: gcc.dg/tree-ssa/prefetch-5.c at r259995

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #3 from James Greenhalgh  ---
The bisect robot doesn't bootstrap, only build a stage 1 compiler.

I've checked your most recent patch against these testcases, and they execute
and complete fine.

(In reply to Luis Machado from comment #2)
> I did a fresh x86-64 bootstrap with the changes in and those prefetch tests
> are not executed as part of dg.exp. Running by hand they look sane to me.

I'm sure this is just a typo, but you probably didn't mean "dg.exp" in this
case - the prefetch tests are in tree-ssa.exp and the opt-1 and opt-2 tests are
in i386.exp .

[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))

[jason at gcc dot gnu.org]

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

--- Comment #36 from Jason Merrill  ---
(In reply to Jason Merrill from comment #35)
> Is there a reason you can't use [[nodiscard]]?

...ah, because this is a bug report against the C compiler.

[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))

[jason at gcc dot gnu.org]

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

--- Comment #35 from Jason Merrill  ---
Is there a reason you can't use [[nodiscard]]?

[Bug lto/85801] LTO linking fails to reconcile symbol from common an data sections (-fPIE -Wl,--as-needed -flto): unresolvable R_ARM_REL32 relocation against symbol `progname'

[rearnsha at gcc dot gnu.org]

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

--- Comment #9 from Richard Earnshaw  ---
(In reply to rguent...@suse.de from comment #8)

> 
> Sure. So I'd say common symbols that are exported may not be in an anchor
> group? 

In the shared library this isn't a common symbol: it has an initializer.

> 
> What do we do with weak globals? Or generally with interposable symbols in
> non-PIC code?

weak symbols (definitions, or references) can't go in anchor groups.  But
they're quite rare and we just have to live with the overhead.

[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))

[ed at catmur dot uk]

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

Ed Catmur  changed:

   What|Removed |Added

 CC||ed at catmur dot uk

--- Comment #34 from Ed Catmur  ---
Note that a logical negation prior to cast to void is sufficient to suppress
the warning:

  int void_cast_should_not_warn() {
 (void) !foo();
 // ^-- here
 return 0;
  }

[Bug lto/85801] LTO linking fails to reconcile symbol from common an data sections (-fPIE -Wl,--as-needed -flto): unresolvable R_ARM_REL32 relocation against symbol `progname'

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On May 16, 2018 6:27:37 PM GMT+02:00, "rearnsha at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801
>
>--- Comment #7 from Richard Earnshaw  ---
>(In reply to rguent...@suse.de from comment #6)
>
>> Can't we decide that per symbol?  Or somehow force the dynamic linker
>to use
>> the program symbol?
>
>At what point?  We've no idea during compilation which code would go in
>a
>shared library if its not built with -fPIC, and we've no idea which
>symbols
>might then need to be ripped out of an anchor group.  Once in an anchor
>group
>it isn't possible to undo that during linking (since the reference is
>to the
>entire group and individual symbols are no longer referenced).
>
>So this is a decision the compiler makes which the linker can never
>undo.

Sure. So I'd say common symbols that are exported may not be in an anchor
group? 

What do we do with weak globals? Or generally with interposable symbols in
non-PIC code?

[Bug lto/85801] LTO linking fails to reconcile symbol from common an data sections (-fPIE -Wl,--as-needed -flto): unresolvable R_ARM_REL32 relocation against symbol `progname'

[rearnsha at gcc dot gnu.org]

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

--- Comment #7 from Richard Earnshaw  ---
(In reply to rguent...@suse.de from comment #6)

> Can't we decide that per symbol?  Or somehow force the dynamic linker to use
> the program symbol?

At what point?  We've no idea during compilation which code would go in a
shared library if its not built with -fPIC, and we've no idea which symbols
might then need to be ripped out of an anchor group.  Once in an anchor group
it isn't possible to undo that during linking (since the reference is to the
entire group and individual symbols are no longer referenced).

So this is a decision the compiler makes which the linker can never undo.

[Bug lto/85801] LTO linking fails to reconcile symbol from common an data sections (-fPIE -Wl,--as-needed -flto): unresolvable R_ARM_REL32 relocation against symbol `progname'

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On May 16, 2018 5:07:57 PM GMT+02:00, "rearnsha at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801
>
>--- Comment #5 from Richard Earnshaw  ---
>> ld: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `progname'
>which may bind externally can not be used when making a shared object;
>recompile with -fPIC
>
>So this is the start of the problem.  Changing the behaviour to remove
>this
>would involve disabling section anchors for all code (rather than just
>PIC): we
>wouldn't know when a symbol might be pre-empted during linking.
>
>I don't think we want to fix this, even if we could...  there would be
>a large
>performance penalty for lazy build systems.
>
>That this works on X86 is not enough, IMO.  x86 doesn't use section
>anchors.

Can't we decide that per symbol?  Or somehow force the dynamic linker to use
the program symbol?

[Bug libstdc++/85670] `std::filesystem` does not compile on mingw-w64

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Oh I see, that line isn't compiled except on Windows, and does need a
declaration of operator!=.

I've fixed it locally now anyway.

[Bug lto/85801] LTO linking fails to reconcile symbol from common an data sections (-fPIE -Wl,--as-needed -flto): unresolvable R_ARM_REL32 relocation against symbol `progname'

[rearnsha at gcc dot gnu.org]

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

--- Comment #5 from Richard Earnshaw  ---
> ld: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `progname' which may 
> bind externally can not be used when making a shared object; recompile with 
> -fPIC

So this is the start of the problem.  Changing the behaviour to remove this
would involve disabling section anchors for all code (rather than just PIC): we
wouldn't know when a symbol might be pre-empted during linking.

I don't think we want to fix this, even if we could...  there would be a large
performance penalty for lazy build systems.

That this works on X86 is not enough, IMO.  x86 doesn't use section anchors.

[Bug libstdc++/83306] filesystem_error is not nothrow copyable

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |9.0

--- Comment #1 from Jonathan Wakely  ---
I think I should also avoid storing the extra std::string and just do the
concatenation before passing the string to the system_error base class.

[Bug c++/85809] SFINAE code compiles that shouldn't be able to compile.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-05-16
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
This is not a valid bug report, please read https://gcc.gnu.org/bugs/ (as
requested when creating a reprot) and provide the missing information.

Re: bug ? : -Wpedantic -Wconversion 'short a=1; a-=1;' complaint

[Jonathan Wakely]

On 16/05/18 13:58 +, Jason Vas Dias wrote:

Great thanks for your informative response, Jim! :
RE:
On 23/04/2018, Jim Wilson  wrote:

On 04/23/2018 07:11 AM, Jason Vas Dias wrote:


I really do not think a '-Wpedantic -Wconversion' warning should
be generated for the following code, but it is
(with GCC 6.4.1 and 7.3.1 on RHEL-7.5 Linux) :

  $ echo '
  typedef unsigned short U16_t;
  static void f(void)
  { U16_t a = 1;
a-=1;
  }' > t.C;


g...@gcc.gnu.org dropped as inappropriate.  Note that gcc-bugs is output
from our bugzilla.  Sending email here isn't very useful.  If you want a
bug fixed, you have to open a bug report in bugzilla.  You can ask gcc
questions on gcc help.


Please move this to a mailing list other than gcc-bugs, because as
explained that is for automated email from Bugzilla.

You've added "g...@gcc.org" which is nothing to do with GCC.
gcc-h...@gcc.gnu.org is the right mailing list.

[Bug c++/85809] New: SFINAE code compiles that shouldn't be able to compile.

[viktorzoutman at vzout dot com]

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

Bug ID: 85809
   Summary: SFINAE code compiles that shouldn't be able to
compile.
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: viktorzoutman at vzout dot com
  Target Milestone: ---

The following SFINAE code shouldn't be able to compile as far as I'm aware.
However it does compile on gcc: https://godbolt.org/g/D5BkWf

The interesting thing is if you comment out line 25 it gives an error as it
should. But line 25 doesn't have anything to do with the incorrect code. As you
can see in the following code example: https://godbolt.org/g/azEvKp

[Bug c++/84588] [8/9 Regression] internal compiler error: Segmentation fault (contains_struct_check())

[paolo.carlini at oracle dot com]

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

--- Comment #12 from Paolo Carlini  ---
What I'm finishing testing:

Index: cp/parser.c
===
--- cp/parser.c (revision 260280)
+++ cp/parser.c (working copy)
@@ -21308,7 +21308,7 @@ cp_parser_parameter_declaration_list (cp_parser* p
   while (true)
 {
   cp_parameter_declarator *parameter;
-  tree decl = error_mark_node;
+  tree decl;
   bool parenthesized_p = false;

   /* Parse the parameter.  */
@@ -21316,21 +21316,22 @@ cp_parser_parameter_declaration_list (cp_parser* p
= cp_parser_parameter_declaration (parser,
   /*template_parm_p=*/false,
   &parenthesized_p);
+  if (!parameter)
+   {
+ *is_error = true;
+ parameters = error_mark_node;
+ break;
+   }

   /* We don't know yet if the enclosing context is deprecated, so wait
 and warn in grokparms if appropriate.  */
   deprecated_state = DEPRECATED_SUPPRESS;

-  if (parameter)
-   {
- decl = grokdeclarator (parameter->declarator,
-¶meter->decl_specifiers,
-PARM,
-parameter->default_argument != NULL_TREE,
-¶meter->decl_specifiers.attributes);
- if (decl != error_mark_node && parameter->loc != UNKNOWN_LOCATION)
-   DECL_SOURCE_LOCATION (decl) = parameter->loc;
-   }
+  decl = grokdeclarator (parameter->declarator,
+¶meter->decl_specifiers,
+PARM,
+parameter->default_argument != NULL_TREE,
+¶meter->decl_specifiers.attributes);

   deprecated_state = DEPRECATED_NORMAL;

@@ -21340,9 +21341,14 @@ cp_parser_parameter_declaration_list (cp_parser* p
{
  *is_error = true;
  parameters = error_mark_node;
+ if (parser->fully_implicit_function_template_p)
+   abort_fully_implicit_template (parser);
  break;
}

+  if (parameter->loc != UNKNOWN_LOCATION)
+   DECL_SOURCE_LOCATION (decl) = parameter->loc;
+
   if (parameter->decl_specifiers.attributes)
cplus_decl_attributes (&decl,
   parameter->decl_specifiers.attributes,
Index: testsuite/g++.dg/cpp1y/pr84588.C
===
--- testsuite/g++.dg/cpp1y/pr84588.C(nonexistent)
+++ testsuite/g++.dg/cpp1y/pr84588.C(working copy)
@@ -0,0 +1,10 @@
+// { dg-do compile { target c++14 } }
+// { dg-options "-w" }
+
+struct a {
+  void b() {}
+  void c(auto = [] {
+if (a a(int auto){})  // { dg-error "two or more data types" }
+  ;
+  }) {}
+};

[Bug target/85805] Improper code generation for 64 bit comparisons on avr-gcc

[sandor.zsuga at jubatian dot com]

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

--- Comment #3 from Sandor Zsuga  ---
I don't have reasonably easy access to a newer version as it doesn't seem like
there were precompiled binaries available for Linux which I could try without
much hassle.

If someone had one laying around, I would appreciate if he gave a go to the
sample with an

avr-gcc -S -O1 sample.c

where sample.c contained the code above. The resulting assembly file would show
whether the particular GCC version was affected.

[Bug target/85805] Improper code generation for 64 bit comparisons on avr-gcc

[sandor.zsuga at jubatian dot com]

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

--- Comment #2 from Sandor Zsuga  ---
Tested on a different machine:

avr-gcc (GCC) 4.9.2

This is what comes with Debian Jessie. The behavior is present (function
compiles to a single "ret").

[Bug c++/85807] [8/9 Regression] ICEs related to noexcept

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Started with r253599.

[Bug c++/85807] [8/9 Regression] ICEs related to noexcept

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||7.3.1
  Known to fail||8.1.0

[Bug c++/85807] [8/9 Regression] ICEs related to noexcept

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-16
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |8.2
Summary|ICEs related to noexcept|[8/9 Regression] ICEs
   ||related to noexcept
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/85808] New: [concepts] unqualified name lookup breaks after qualified lookup in nested requirement

[Casey at Carter dot net]

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

Bug ID: 85808
   Summary: [concepts] unqualified name lookup breaks after
qualified lookup in nested requirement
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

Compiling this program fragment with "g++ -std=c++17 -fconcepts"
(https://godbolt.org/g/EXDoD3):

  namespace X {
  template constexpr bool x = true;
  }

  template using helper = void;

  template
  concept bool C = requires {
  requires X::x;
  #ifndef WORKAROUND
  typename helper;
  #else
  typename ::helper; // Workaround
  #endif
  };

  static_assert(C);

produces diagnostics:

  :11:14: error: 'X::helper' has not been declared
   typename helper;
^~
  :11:24: error: expected ';' before '>' token
   typename helper;
  ^
  ;
  :11:24: error: expected '}' before '>' token
  :8:27: note: to match this '{'
   concept bool C = requires {
 ^
  :11:25: error: expected primary-expression before ';' token
   typename helper;
   ^
  :15:1: error: expected declaration before '}' token
   };
   ^

rather than the expected successful and silent compile.

Re: bug ? : -Wpedantic -Wconversion 'short a=1; a-=1;' complaint

[Jason Vas Dias]

Great thanks for your informative response, Jim! :
RE:
On 23/04/2018, Jim Wilson  wrote:
> On 04/23/2018 07:11 AM, Jason Vas Dias wrote:
>>
>> I really do not think a '-Wpedantic -Wconversion' warning should
>> be generated for the following code, but it is
>> (with GCC 6.4.1 and 7.3.1 on RHEL-7.5 Linux) :
>>
>>   $ echo '
>>   typedef unsigned short U16_t;
>>   static void f(void)
>>   { U16_t a = 1;
>> a-=1;
>>   }' > t.C;
>
> g...@gcc.gnu.org dropped as inappropriate.  Note that gcc-bugs is output
> from our bugzilla.  Sending email here isn't very useful.  If you want a
> bug fixed, you have to open a bug report in bugzilla.  You can ask gcc
> questions on gcc help.
>
> In the C language, operations on short and always performed as int, and
> then converted back to short.  Subtracting one may generated a negative
> number, which converted to unsigned short will change its value.  So the
> warning seems appropriate.
>
> Note that -Wconversion means different things in different gcc versions.
>   It current meaning is to warn for any implicit cast that may change a
> value.  This is not very useful in general, and is not an option that I
> would recommend using by default.  In old gcc versions, -Wconversion
> warned for code that had different meaning in K&R C and ISO C.  That was
> useful, and some people used that option by default, but the option no
> longer does that.
>
> You can silence the warning by adding an explicit cast.
> a = (U16_t) (a - 1);
>
> Jim
>

But I still think, in modern GCC, the behaviour of this warning option is a bug.
When I look at the code generated for the above example, I can see
the compiler is actually generating 16-bit operations:

$ gcc -std=c11 -Wall -Wextra -pedantic -Wconversion -S -o u16.s u16.c
u16.c: In function ‘f’:
u16.c:9:6: warning: conversion to ‘U16_t {aka short unsigned int}’
from ‘int’ may alter its value [-Wconversion]
   v-=1;
  ^

But looking at the assembler generated :

movw$1, -2(%rbp)
subw$1, -2(%rbp)

we see that on x86_64 at least, the compiler is actually generating
16-bit operations on two-byte values.

I can understand that on architectures such as ARM , it might be
appropriate to generate the warning, because on that platform,
a 32-bit operation may actually be generated for the code.
But if no 32-bit operation is being generated, why issue the warning?

So it is not the case that
> In the C language, operations on short are always performed as int, and
> then converted back to short .

That may have been true with ANSI C90, but not with more recent versions
of the C language; surely GCC should know what standard & CPU it is generating
code for, and emit appropriate warnings for that standard and CPU ?

And your suggested fix illustrates my point about the warning encouraging
unnecessary casts:
> You can silence the warning by adding an explicit cast.
> a = (U16_t) (a - 1);
Actually, in this case, gcc is clever enough to realize that a cast is
not required,
and actually generates identical code with or without the cast:

movw$1, -2(%rbp)
subw$1, -2(%rbp)

But C++ programmers are encouraged to look at any C-style "(X)y" cast as
"Create an anonymous Temporary to hold y cast to type X " .
Even though that is not what is going on here, I think the warning does
not help programmers understand what code is being generated
(the 16-bit operations) and incorrectly makes them think a 32-bit
temporary is being generated.

So I think that '-Wconversion' should have no effect if '-pedantic'
is in effect,
because that combination produces erroneous and misleading warnings .

Thanks & Best Regards,
Jason

[Bug c++/85807] New: ICEs related to noexcept

[peter.azmanov at transas dot com]

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

Bug ID: 85807
   Summary: ICEs related to noexcept
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter.azmanov at transas dot com
  Target Milestone: ---

Created attachment 44138
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44138&action=edit
self-contained test

After upgrade to version 8.1.0, encountered ICE:
"internal compiler error: in check_noexcept_r, at cp/except.c:1027"

Slight modifications led to other ICEs.

Test script:
echo " Segfault internal compiler error"
/usr/bin/g++ -DSEGFAULT_ERROR test.cpp
echo " Noexcept internal compiler error"
/usr/bin/g++ -DNOEXCEPT_ERROR test.cpp
echo " Unexpected expression internal compiler error"
/usr/bin/g++ -DUNEXPECTED_EXPR_ERROR -Wall test.cpp
echo " cp_get_fndecl_from_callee internal compiler error (1)"
/usr/bin/g++ -DUNEXPECTED_EXPR_ERROR test.cpp
echo " cp_get_fndecl_from_callee internal compiler error (2)"
/usr/bin/g++ test.cpp

echo " Workaround"
/usr/bin/g++ -DWORKAROUND test.cpp

Output:
 Segfault internal compiler error
test.cpp: In function ‘value_statistics_t<> calc() [with T = double]’:
test.cpp:25:13: internal compiler error: Segmentation fault
 return {};
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
 Noexcept internal compiler error
test.cpp: In instantiation of ‘value_statistics_t<> calc() [with T = double]’:
test.cpp:39:46:   required from here
test.cpp:28:24: internal compiler error: in check_noexcept_r, at
cp/except.c:1027
   value_statistics_t<> result;
^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
 Unexpected expression internal compiler error
test.cpp: In instantiation of ‘value_statistics_t<> calc() [with T = double]’:
test.cpp:39:46:   required from here
test.cpp:31:31: internal compiler error: unexpected expression ‘(size_t)0’ of
kind implicit_conv_expr
   return value_statistics_t<>{};
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
 cp_get_fndecl_from_callee internal compiler error (1)
test.cpp: In instantiation of ‘value_statistics_t<> calc() [with T = double]’:
test.cpp:39:46:   required from here
test.cpp:35:1: internal compiler error: in cp_get_fndecl_from_callee, at
cp/cvt.c:957
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
 cp_get_fndecl_from_callee internal compiler error (2)
test.cpp: In instantiation of ‘value_statistics_t<> calc() [with T = double]’:
test.cpp:39:46:   required from here
test.cpp:35:1: internal compiler error: in cp_get_fndecl_from_callee, at
cp/cvt.c:957
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
 Workaround

[Bug c++/85363] Throwing exception from member constructor (brace initializer vs initializer list)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/85806] New: [concepts] Hard error for "invalid use of non-static data member" in a requires expression

[Casey at Carter dot net]

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

Bug ID: 85806
   Summary: [concepts] Hard error for "invalid use of non-static
data member" in a requires expression
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

Compiling this program fragment with g++ -std=c++17 -fconcepts
(https://godbolt.org/g/L1b6TS):

  template using helper = void;

  template
  concept bool HasCount = requires {
  typename ::helper;
  };

  struct S {
  int count = 42;
  };
  static_assert(!HasCount);

produces a diagnostic:

  :11:18: error: invalid use of non-static data member 'S::count'
 static_assert(!HasCount);
^~~
  :9:19: note: declared here
 int count = 42;
 ^~

rather than the expected successful and silent compile.

[Bug tree-optimization/85803] [6/7/8/9 Regression] DSE removes live global store

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||ebotcazou at gcc dot gnu.org
   Target Milestone|--- |6.5

--- Comment #1 from Richard Biener  ---
More simple cases involve externally thrown (non-call or from const function)
exceptions like

  *p = 42;
  a / 0;
  *p = 0;

or

  *p = 42;
  *(void *)0 = 0;
  *p = 0;

note that with externally thrown EH we do not have any CFG reflecting the EH
and thus other passes are usually also free in re-ordering stmts to make the
*p = 42 side-effect invisible.

I think the only in-tree language eventually specifying behavior for stuff
like above is Ada - so, any comments / attempts for testcases where we do
not follow language specified behavior?

One idea that crossed our minds is to add a return statement to the exit
block having the virtual operand and have externally throwing stmts have
an EH edge to that block (and a fallthru from the regular exit / return stmt).

Actions

[Luk]

Actions

















尊敬的企业家，



是否聴過：不宣傳等死，宣传這么貴找死！
低於一位销售員月薪費用的大數据新媒体是您的選擇！
不管是本港，国内或者外国市场，我们都有办法为你精凖找出客户！
我们使用的是今天現代人的电子媒体和最先进的IT技术。
衆多的成功範例来自零售、飱飲、地產、貿易、服装、厂家、律师事务所.
我们在香港已经上市十六年，错过這个信息是你最大的遗憾！




来电36102885/36102887


Best Regards


KK Luk 
陸家駒上


Netel Digital Marketing 




   





  

Should you wish not to receive any promotional 
email in the future, please click UNSUBSCRIBE.
如閣下不欲收到本公司的宣傳郵件，請按不訂閱。
  

[Bug c++/84588] [8/9 Regression] internal compiler error: Segmentation fault (contains_struct_check())

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini  ---
I think I figured out why my first try didn't really work. It's a latent
issue/weirdness in cp_parser_parameter_declaration_list: it is setting
*is_error = true, returning error_mark_node - and maybe calling
abort_fully_implicit_template (parser) with my patch - also when
cp_parser_parameter_declaration simply returns NULL_TREE, not error_mark_node.
A more complete patch additionally streamlining
cp_parser_parameter_declaration_list wrt to that appears to work just fine and
doesn't regress c++/85713, I'll send it for review later today if everything
goes well.

[Bug libstdc++/78870] Support std::filesystem on Windows

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||lh_mouse at 126 dot com

--- Comment #12 from Jonathan Wakely  ---
*** Bug 85670 has been marked as a duplicate of this bug. ***

[Bug libstdc++/85670] `std::filesystem` does not compile on mingw-w64

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
I've got no idea what this error is caused by because the relevant operator!=
is clearly present on line 550 of , but I'm surprised
 is even installed for MinGW. It should only be installed
conditionally, like , but I forgot to do that.

But this will get fixed soon, as part of PR 78870, so closing as a dup of that
one.

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

[Bug lto/85801] LTO linking fails to reconcile symbol from common an data sections (-fPIE -Wl,--as-needed -flto): unresolvable R_ARM_REL32 relocation against symbol `progname'

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
(In reply to rguent...@suse.de from comment #3)
> 
> I see.  But why's the resolution dependent on --as-needed?

Since with --as-needed, in the first pass, linker doesn't include
libxfs.so, pogram is set to COMMON.  Without --as-needed, program
is resolved to definition in libxfs.so immediately. But this is
internal to linker and shouldn't make a difference.

[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use

[marxin at gcc dot gnu.org]

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

--- Comment #15 from Martin Liška  ---
A simple solution how to prevent the pathological situation is for now not to
use directory in -fprofile-{generate,use}.

[Bug lto/85801] LTO linking fails to reconcile symbol from common an data sections (-fPIE -Wl,--as-needed -flto): unresolvable R_ARM_REL32 relocation against symbol `progname'

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Wed, 16 May 2018, hjl.tools at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801
> 
> --- Comment #2 from H.J. Lu  ---
> (In reply to Richard Biener from comment #1)
> > I think this is valid from an ELF perspective.  But ca you really expect
> > char *progname to resolve to the library copy?  In fact the linker 
> > resolution
> > here is
> > 
> > 1
> > t2.o 4
> > 207 b42c927210240321 PREVAILING_DEF main
> > 349 b42c927210240321 PREVAILING_DEF_IRONLY_EXP progname
> > 351 b42c927210240321 RESOLVED_DYN stderr
> > 347 b42c927210240321 UNDEF my_name
> > 
> > and thus it correctly(?) resolves to a non-exported local copy
> > (GNU ld 2.30 branch).  Note that without --as-needed I get
> 
> This looks normal to me and works on x86.  Linker plugin determined that
> program is defined in IR and visible externally:
> 
>  /* This is the prevailing definition of the symbol, with no
>  references from regular objects.  It is only referenced from IR
>  code, but the symbol is exported and may be referenced from
>  a dynamic object (not seen at link time).  */ 
>  LDPR_PREVAILING_DEF_IRONLY_EXP
> 
> The final resolution is performed by the non-LTO part of linker.  Since
> program is COMMOM, the definition in libxfs.so is used.  It sounds like
> a linker backend bug.

I see.  But why's the resolution dependent on --as-needed?

[Bug c++/85802] false-positive -Wmemset-elt-size when compiling C++ code

[mail at milianw dot de]

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

--- Comment #2 from Milian Wolff  ---
Oh, awesome - it actually detected a bug :) It should have been "char buf", not
"char* buf".

Thanks for opening my eyes here, I stared at this for a while and couldn't spot
the issue. The fact that it wasn't reproducible with C made me believe it was a
false-positive.

Thanks again

[Bug lto/85801] LTO linking fails to reconcile symbol from common an data sections (-fPIE -Wl,--as-needed -flto): unresolvable R_ARM_REL32 relocation against symbol `progname'

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to Richard Biener from comment #1)
> I think this is valid from an ELF perspective.  But ca you really expect
> char *progname to resolve to the library copy?  In fact the linker resolution
> here is
> 
> 1
> t2.o 4
> 207 b42c927210240321 PREVAILING_DEF main
> 349 b42c927210240321 PREVAILING_DEF_IRONLY_EXP progname
> 351 b42c927210240321 RESOLVED_DYN stderr
> 347 b42c927210240321 UNDEF my_name
> 
> and thus it correctly(?) resolves to a non-exported local copy
> (GNU ld 2.30 branch).  Note that without --as-needed I get

This looks normal to me and works on x86.  Linker plugin determined that
program is defined in IR and visible externally:

 /* This is the prevailing definition of the symbol, with no
 references from regular objects.  It is only referenced from IR
 code, but the symbol is exported and may be referenced from
 a dynamic object (not seen at link time).  */ 
 LDPR_PREVAILING_DEF_IRONLY_EXP

The final resolution is performed by the non-LTO part of linker.  Since
program is COMMOM, the definition in libxfs.so is used.  It sounds like
a linker backend bug.

[Bug c/85800] A miscompilation bug with unsigned char

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |NEW

[Bug tree-optimization/85757] tree optimizers fail to fully clean up fixed-size memcpy

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Ontop of recent patches:

diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
index 32a25b9eb1e..1b672ad204a 100644
--- a/gcc/tree-ssa-dse.c
+++ b/gcc/tree-ssa-dse.c
@@ -577,6 +577,7 @@ dse_classify_store (ao_ref *ref, gimple *stmt,
   else
defvar = gimple_vdef (temp);
   auto_vec defs;
+  gimple *phi_def = NULL;
   FOR_EACH_IMM_USE_STMT (use_stmt, ui, defvar)
{
  /* Limit stmt walking.  */
@@ -600,7 +601,10 @@ dse_classify_store (ao_ref *ref, gimple *stmt,
 processing.  */
  if (!bitmap_bit_p (visited,
 SSA_NAME_VERSION (PHI_RESULT (use_stmt
-   defs.safe_push (use_stmt);
+   {
+ defs.safe_push (use_stmt);
+ phi_def = use_stmt;
+   }
}
  /* If the statement is a use the store is not dead.  */
  else if (ref_maybe_used_by_stmt_p (use_stmt, ref))
@@ -660,12 +671,25 @@ dse_classify_store (ao_ref *ref, gimple *stmt,
   /* Process defs and remove paths starting with a kill from further
  processing.  */
   for (unsigned i = 0; i < defs.length (); ++i)
-   if (stmt_kills_ref_p (defs[i], ref))
- {
-   if (by_clobber_p && !gimple_clobber_p (defs[i]))
- *by_clobber_p = false;
+   {
+ gimple *def = defs[i];
+ gimple *use_stmt;
+ use_operand_p use_p;
+ if (stmt_kills_ref_p (def, ref))
+   {
+ if (by_clobber_p && !gimple_clobber_p (def))
+   *by_clobber_p = false;
+ defs.unordered_remove (i);
+   }
+ /* In addition to kills we can remove defs whose only use
+is another def in defs.  That can only ever be PHIs of which
+we track a single for simplicity reasons (we fail for multiple
+PHIs anyways).  */
+ else if (gimple_code (def) != GIMPLE_PHI
+  && single_imm_use (gimple_vdef (def), &use_p, &use_stmt)
+  && use_stmt == phi_def)
defs.unordered_remove (i);
- }
+   }

   /* If all defs kill the ref we are done.  */
   if (defs.is_empty ())

[Bug fortran/83149] [6- and 7-branches] Missing test for sym->ns->proc_name: crash_signal in toplev.c:325

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #16 from Paul Thomas  ---
Fixed on 6-branch through to trunk

Thanks for the report.

Paul

[Bug c++/35878] [LWG 2302] Useless NULL pointer check when constructing object

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

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

--- Comment #15 from Ville Voutilainen  ---
The check was removed in all modes by r254694. I don't plan to backport that,
so closing.

[Bug fortran/83149] [6- and 7-branches] Missing test for sym->ns->proc_name: crash_signal in toplev.c:325

[pault at gcc dot gnu.org]

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

--- Comment #15 from Paul Thomas  ---
Author: pault
Date: Wed May 16 11:42:47 2018
New Revision: 260286

URL: https://gcc.gnu.org/viewcvs?rev=260286&root=gcc&view=rev
Log:
2018-05-16  Paul Thomas  

PR fortran/83149
Backport from trunk
* trans-decl.c (gfc_finish_var_decl): Test sym->ns->proc_name
before accessing its components.
* trans-types.c (gfc_sym_type): If a character result has null
backend_decl, try the procedure symbol.

2018-05-16  Paul Thomas  

PR fortran/83149
Backport from trunk
* gfortran.dg/pr83149_1.f90: New test.
* gfortran.dg/pr83149.f90: Additional source for previous.
* gfortran.dg/pr83149_b.f90: New test.
* gfortran.dg/pr83149_a.f90: Additional source for previous.


Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr83149.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr83149_1.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr83149_a.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr83149_b.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/trans-decl.c
branches/gcc-6-branch/gcc/fortran/trans-types.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/85805] Improper code generation for 64 bit comparisons on avr-gcc

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||avr
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-05-16
  Component|c   |target
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Note GCC 4.8 is long out of maintainance and GCC 4.8.1 is a particularly old
version from the branch.  Please try a still supported compiler which would
be GCC 6.4, GCC 7.3 or GCC 8.1.  If you can't do that please try at least
the latest GCC 4.8 based compiler which is GCC 4.8.5.

[Bug fortran/83149] [6- and 7-branches] Missing test for sym->ns->proc_name: crash_signal in toplev.c:325

[pault at gcc dot gnu.org]

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

--- Comment #14 from Paul Thomas  ---
Author: pault
Date: Wed May 16 11:17:10 2018
New Revision: 260285

URL: https://gcc.gnu.org/viewcvs?rev=260285&root=gcc&view=rev
Log:
2018-05-16  Paul Thomas  

PR fortran/83149
Backport from trunk
* trans-decl.c (gfc_finish_var_decl): Test sym->ns->proc_name
before accessing its components.
* trans-types.c (gfc_sym_type): If a character result has null
backend_decl, try the procedure symbol..

2018-05-16  Paul Thomas  

PR fortran/83149
Backport from trunk
* gfortran.dg/pr83149_1.f90: New test.
* gfortran.dg/pr83149.f90: Additional source for previous.
* gfortran.dg/pr83149_b.f90: New test.
* gfortran.dg/pr83149_a.f90: Additional source for previous.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr83149.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr83149_1.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr83149_a.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr83149_b.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/trans-decl.c
branches/gcc-7-branch/gcc/fortran/trans-types.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c/85805] New: Improper code generation for 64 bit comparisons on avr-gcc

[sandor.zsuga at jubatian dot com]

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

Bug ID: 85805
   Summary: Improper code generation for 64 bit comparisons on
avr-gcc
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandor.zsuga at jubatian dot com
  Target Milestone: ---

GCC version:

avr-gcc (GCC) 4.8.1

Compiling with either -O1 or -O2 optimizations enabled, tested with some ATMega
and XMega targets. Test case:


#include 

uint8_t volatile tmp;

__attribute__((noinline)) void test_64(uint64_t d64)
{
 if ((d64 & 0xFF80UL) == 0xFF80UL){
  tmp ++;
 }
}

__attribute__((noinline)) void test_32(uint32_t d32)
{
 if ((d32 & 0xFF80UL) == 0xFF80UL){
  tmp ++;
 }
}

int main(void)
{
 test_64(0);
 test_32(0);

 while(1);
}


A cut from the output assembly, showing the critical part (the code generated
for test_64, test_32 and main):


0228 :
 228:   08 95   ret

022a :
 22a:   66 27   eor r22, r22
 22c:   77 27   eor r23, r23
 22e:   80 78   andir24, 0x80   ; 128
 230:   61 15   cp  r22, r1
 232:   71 05   cpc r23, r1
 234:   80 48   sbcir24, 0x80   ; 128
 236:   9f 4f   sbcir25, 0xFF   ; 255
 238:   09 f0   breq.+2 ; 0x23c 
 23a:   08 95   ret
 23c:   80 91 00 20 lds r24, 0x2000
 240:   8f 5f   subir24, 0xFF   ; 255
 242:   80 93 00 20 sts 0x2000, r24
 246:   08 95   ret

0248 :
 248:   20 e0   ldi r18, 0x00   ; 0
 24a:   30 e0   ldi r19, 0x00   ; 0
 24c:   40 e0   ldi r20, 0x00   ; 0
 24e:   50 e0   ldi r21, 0x00   ; 0
 250:   60 e0   ldi r22, 0x00   ; 0
 252:   70 e0   ldi r23, 0x00   ; 0
 254:   80 e0   ldi r24, 0x00   ; 0
 256:   90 e0   ldi r25, 0x00   ; 0
 258:   0e 94 14 01 call0x228   ; 0x228 
 25c:   60 e0   ldi r22, 0x00   ; 0
 25e:   70 e0   ldi r23, 0x00   ; 0
 260:   cb 01   movwr24, r22
 262:   0e 94 15 01 call0x22a   ; 0x22a 
 266:   ff cf   rjmp.-2 ; 0x266 


It seems like the compiler incorrectly determines that the "if" is always false
in the 64 bit case, and produces a corresponding result (a function doing
nothing). A native version of GCC produces the expected code (the comparison
being performed).

[Bug tree-optimization/85804] [8/9 Regression][AArch64] Mis-compilation of loop with strided array access and xor reduction

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P2

[Bug fortran/83898] [6/7 Regression] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:7181

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #8 from Paul Thomas  ---
Fixed on 6-branch through to trunk.

Thanks for the report.

Paul

[Bug fortran/83898] [6/7 Regression] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:7181

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Wed May 16 10:41:48 2018
New Revision: 260284

URL: https://gcc.gnu.org/viewcvs?rev=260284&root=gcc&view=rev
Log:
2018-16-05  Paul Thomas  

PR fortran/83898
Backport from trunk
* trans-stmt.c (trans_associate_var): Do not set cst_array_ctor
for characters.

2018-16-05  Paul Thomas  

PR fortran/83898
Backport from trunk
* gfortran.dg/associate_33.f03 : New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/associate_33.f03
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/trans-stmt.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/85802] false-positive -Wmemset-elt-size when compiling C++ code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Try adding sizeof  (char*) instead.  

Note the reason why it does not complain in c is because buf is a vla in c
while is a standard array in c++.  Const is treated differently in the
languages.

[Bug fortran/83898] [6/7 Regression] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:7181

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  ---
Author: pault
Date: Wed May 16 10:18:20 2018
New Revision: 260282

URL: https://gcc.gnu.org/viewcvs?rev=260282&root=gcc&view=rev
Log:
2018-16-05  Paul Thomas  

PR fortran/83898
Backport from trunk
* trans-stmt.c (trans_associate_var): Do not set cst_array_ctor
for characters.

2018-16-05  Paul Thomas  

PR fortran/83898
Backport from trunk
* gfortran.dg/associate_33.f03 : New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_33.f03
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/trans-stmt.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/85804] [8/9 Regression][AArch64] Mis-compilation of loop with strided array access and xor reduction

[sudi at gcc dot gnu.org]

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

sudi at gcc dot gnu.org changed:

   What|Removed |Added

 Target||aarch64-none-linux-gnu
   Target Milestone|--- |8.2

[Bug tree-optimization/85804] New: [8/9 Regression][AArch64] Mis-compilation of loop with strided array access and xor reduction

[sudi at gcc dot gnu.org]

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

Bug ID: 85804
   Summary: [8/9 Regression][AArch64] Mis-compilation of loop with
strided array access and xor reduction
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sudi at gcc dot gnu.org
  Target Milestone: ---

The following test case:

#include 

long d[32] = {0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};

int main() {
  int b = 0;
  for (int c = 0; c <= 5; c++)
b ^= d[c * 5 + 1];
  printf("checksum = %x\n", b);
}

when compiled with:
aarch64-none-linux-gnu-gcc -O3 f.c
prints "checksum = 1".

All the elements being xor'd (1,6,11,16,21,26) are 0s and thus the result
should also be 0.

The assembly for main looks like:
main:
.LFB11:
.cfi_startproc
adrpx1, .LANCHOR0
add x1, x1, :lo12:.LANCHOR0
stp x29, x30, [sp, -16]!
.cfi_def_cfa_offset 16
.cfi_offset 29, -16
.cfi_offset 30, -8
adrpx0, .LC0
add x0, x0, :lo12:.LC0
mov x29, sp
ldr q1, [x1, 8]
ldr q2, [x1, 24]
ldr q0, [x1, 40]
xtn v2.2s, v2.2d
xtn v1.2s, v1.2d
xtn v0.2s, v0.2d
eor v1.8b, v1.8b, v2.8b
eor v0.8b, v0.8b, v1.8b
ushr d1, d0, 32
eor v0.8b, v0.8b, v1.8b
umovw1, v0.s[0]
bl  printf
mov w0, 0
ldp x29, x30, [sp], 16
.cfi_restore 30
.cfi_restore 29
.cfi_def_cfa_offset 0
ret
.cfi_endproc


This goes away with -fno-tree-loop-vectorize.

[Bug tree-optimization/85803] New: [6/7/8/9 Regression] DSE removes live global store

[rguenth at gcc dot gnu.org]

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

Bug ID: 85803
   Summary: [6/7/8/9 Regression] DSE removes live global store
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Due to an algorithmic defect GIMPLE DSE removes the global store to *p in
the if (i == 42) condition.  This is because it relies on the presence of
virtual operands on _all_ use sites, including ones outside of the function.
One might think the

  if (ref_may_alias_global_p (ref))
return DSE_STORE_LIVE;

protects such cases but that only works if no alternate definition site is
found.  That is, for this bug to trigger we need to have sth like

  if (..)
exit-of-function-w/o-VUSE;
  # _2 = VDEF <_1>

GIMPLE_RESX is amongst the opcodes that (can?) exit the function but have
no associated virtual operands.

Testcase, fails at -O2 with GCC 5+ (didn't verify if with 4.9.4 the issue
is just latent for whatever reason):

#include 
#include 
#include 

extern void maybethrow(void*);
int cond, *globp;
static inline void __attribute__((always_inline)) inlinethrow(void *p)
{
  *globp = 43;
}
int __attribute__((noinline,noclone)) foo (int *p, int i)
{
  if (i) {
  if (i == 42) {
  *p = 42;
  int local __attribute__((cleanup(inlinethrow)));
  }
  *p = 0;
  }
  *p = 1;
  return i + 1;
}

jmp_buf buf;
static void segv_handler(int seg)
{
  longjmp (buf, 1);
}
int x;
int main()
{
  struct sigaction sa, origsa;
  sa.sa_handler = segv_handler;
  sa.sa_flags = 0;
  sigemptyset(&sa.sa_mask);
  sigaction(SIGSEGV, &sa, NULL);

  if (!setjmp (buf))
foo (&x, 42);
  if (x != 42)
abort ();
  return 0;
}

I beleive the proper course of action is to make all function exiting
GIMPLE ops have a VUSE (and adjust ref_maybe_used_by_stmt_p accordingly
as it was done for GIMPLE_RETURN).

If you remove the above check in DSE (which should be redundant) you'll
see some more cleanup and EH tests fail.

[Bug fortran/84219] Failure to generate error for IO of transfer intrinsic, when MOLD has derived type components.

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #7 from Paul Thomas  ---
Having perused the F2008 standard, I can find no indication that the testcase
in comment 5 is illegal and so I am closing this PR as resolved.

Paul

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2018-05-16
 CC||amonakov at gcc dot gnu.org
 Resolution|WONTFIX |---
 Ever confirmed|0   |1

--- Comment #10 from Alexander Monakov  ---
Reopening: the request to be able to disable the warning (via
-Wno-alloc-size-larger-than) is valid and should be addressed.

[Bug c++/85799] __builin_expect doesn't propagate through inlined functions

[hubicka at ucw dot cz]

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

--- Comment #4 from Jan Hubicka  ---
> I believe inlining is happening too late for it to have an effect - we are
> early inlining a body which has the __builtin_expect replaced by nothing.
> 
> Iff the expected outcome is "constant" a new function attribute would work.
> For outcome dependent on context that wouldn't work.
> 
> Not sure if we can simply introduce a return-value predictor that survives
> inlining?  Honza?

with martin we added strip_predict_hints to the end of early optimization queue
at https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01573.html
this removes the hint and it is not used by the branch prediction of the outer
function.  The statement predictors are somewhat problematic here becuase they
may associate with wrong conditional if the inner function body is optimized.

I guess we have two options
 1) do not re-do branch prediction on inlined code.
 2) strip just selected hints and not others (like builtin_expect) that is
safe even after inlning.
Not sure which one is better...

Honza
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug demangler/85373] Ice in demangler

[fiesh at zefix dot tv]

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

--- Comment #1 from fiesh at zefix dot tv ---
The problem is that d_count_templates_scopes calls itself infinitely.

[Bug fortran/84546] [7 Regression] Bad sourced allocation of CLASS(*) with source with CLASS(*) component

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #10 from Paul Thomas  ---
Fixed on 7-branch.

Thanks for the report.

Paul

[Bug fortran/84546] [7 Regression] Bad sourced allocation of CLASS(*) with source with CLASS(*) component

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas  ---
Author: pault
Date: Wed May 16 09:35:19 2018
New Revision: 260281

URL: https://gcc.gnu.org/viewcvs?rev=260281&root=gcc&view=rev
Log:
2018-05-16  Paul Thomas  

PR fortran/84546
Backport from trunk
* trans-array.c (structure_alloc_comps): Make sure that the
vptr is copied and that the unlimited polymorphic _len is used
to compute the size to be allocated.
(build_array_ref): Set the 'unlimited' argument false in the
call to gfc_get_class_array_ref.
* trans-expr.c (gfc_get_class_array_ref): If unlimited, use the
unlimited polymorphic _len for the offset to the element.
(gfc_copy_class_to_class): Set the new 'unlimited' argument.
* trans.h : Add the boolean 'unlimited' to the prototype.

2018-05-16  Paul Thomas  

PR fortran/84546
Backport from trunk
* gfortran.dg/unlimited_polymorphic_29.f90 : New test.


Added:
   
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/unlimited_polymorphic_29.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/trans-array.c
branches/gcc-7-branch/gcc/fortran/trans-expr.c
branches/gcc-7-branch/gcc/fortran/trans.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug lto/85801] LTO linking fails to reconcile symbol from common an data sections (-fPIE -Wl,--as-needed -flto): unresolvable R_ARM_REL32 relocation against symbol `progname'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
I think this is valid from an ELF perspective.  But ca you really expect
char *progname to resolve to the library copy?  In fact the linker resolution
here is

1
t2.o 4
207 b42c927210240321 PREVAILING_DEF main
349 b42c927210240321 PREVAILING_DEF_IRONLY_EXP progname
351 b42c927210240321 RESOLVED_DYN stderr
347 b42c927210240321 UNDEF my_name

and thus it correctly(?) resolves to a non-exported local copy
(GNU ld 2.30 branch).  Note that without --as-needed I get

1
t2.o 4
207 226c604d5f4407d9 PREVAILING_DEF main
349 226c604d5f4407d9 RESOLVED_DYN progname
351 226c604d5f4407d9 RESOLVED_DYN stderr
347 226c604d5f4407d9 RESOLVED_DYN my_name

so I think this points to a GNU ld bug (and gold behaves the same).

HJ?  I think for the purpose of generating the resolution we have to
ignore --as-needed?

[Bug fortran/84546] [7 Regression] Bad sourced allocation of CLASS(*) with source with CLASS(*) component

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas  ---
*** Bug 83118 has been marked as a duplicate of this bug. ***

[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||pault at gcc dot gnu.org
 Resolution|--- |DUPLICATE
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #5 from Paul Thomas  ---
This bug is fixed by the patch for PR84546, which has already been applied to
8-branch and trunk.

I am just now regtesting on 7-branch and intend to commit on success.

Paul

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

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||85800

--- Comment #30 from Richard Biener  ---
Another interesting example in PR85800 where the offending "bad" transformation
is
for char a, b

  if (a == b)
a[i] = a;
  else
a[i] = b;

if-convert that to

  a[i] = b;

because a and b have different pointer provenance -- runtime equal pointers
&x and &y+1 (one-after-end) again.  The if-converted result results in
a[i] having same provenance as b rather than "both" (GCC happily tracks
provenance union).

In isolation avoiding this kind of transforms is bad (consider this is isolated
into a separate function and later inlined).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85800
[Bug 85800] A miscompilation bug with unsigned char

[Bug c/85800] A miscompilation bug with unsigned char

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Wed, 16 May 2018, juneyoung.lee at sf dot snu.ac.kr wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85800
> 
> --- Comment #2 from Juneyoung Lee  ---
> If address is not adjacent - you can reorder the definition of A and B and try
> again.
> ```
>   int A[4], B[4];
> ```
> 
> If changing
> 
> if (c1 == c2)
>   // Always true if p and q have same integer representation.
>   arr3[i] = arr1[i];
> else
>   arr3[i] = arr2[i];
> 
> to
> 
> if (c1 == c2)
>   // Always true if p and q have same integer representation.
>   arr3[i] = arr2[i];
> else
>   arr3[i] = arr1[i];
> 
> removed miscompilation, I think this implies that the former one is folded 
> into
> `arr[3] = arr2[i]` (which is incorrect, because arr2 is equivalent to `q`) but
> the latter one is folded into `arr[3] = arr1[i]`.
> 
> This explains the generated assembly as well: Compiling store_10_to_p with -O3
> generates
> 
> ```
> store_10_to_p(int*, int*):
>   mov DWORD PTR [rdi], 1
>   mov DWORD PTR [rsi], 10
>   ret
> ```
> 
> meaning that it is actually trying to store 10 to *q, which is UB if the
> function is inlined. (B[4] is out-of-bounds)

Ok, so the sequence of optimization is as follows.  First the
comparison is narrowed so we compare arr1[i] and arr2[i] directly.
Then we sink the store and get

  _10 = arr1[i_9];
  _11 = arr2[i_9];
  if (_10 == _11)
goto ; [34.00%]
  else
goto ; [66.00%]

   [58.67%]:

   [88.89%]:
  # cstore_29 = PHI <_10(3), _11(4)>
  arr3[i_9] = cstore_29;

then this is pattern matched to just

  _1 = arr1[i_4];
  _2 = arr2[i_4];
  arr3[i_4] = _2;

which is correct since if _10 == _11 we can as well store _11
instead of _10 to arr3[i_9].  This is where things go "wrong"
and a "bug" similar to PR61502 arises.  We propagate conditional
equivalences.

Then alias analysis comes along and while it originally
correctly computed arr3 to "point" to both A and B it now
only sees the provenance on B and both stores can be
re-ordered by scheduling.  We expand to RTL from
(-fdump-tree-optimized-alias-uid):

   [11.11%]:
  # USE = nonlocal null { D.2675 D.2676 } (escaped)
  # CLB = nonlocal null { D.2675 D.2676 } (escaped)
  printf ("%p %p\n", &AD.2675, &BD.2676[4]);
  # RANGE [0, 18446744073709551615] NONZERO 18446744073709551600
  _8 = (long unsigned intD.10) &BD.2676[4];
  MEM[(charD.7 * {ref-all})&arr2D.2693] = _8;
  _27 = MEM[(charD.7 * {ref-all})&arr2D.2693];
  MEM[(charD.7 * {ref-all})&arr3D.2694] = _27;
  _14 = MEM[(charD.7 * {ref-all})&arr3D.2694];
  # PT = null { D.2676 } (escaped)
  r_15 = (intD.6 *) _14;
  MEM[(intD.6 *)&AD.2675] = 1;
  *r_15 = 10;
  arr2D.2693 ={v} {CLOBBER};
  arr3D.2694 ={v} {CLOBBER};
  # USE = nonlocal null { D.2675 D.2676 } (escaped)
  # CLB = nonlocal null { D.2675 D.2676 } (escaped)
  printf ("%d\n", 1);
  AD.2675 ={v} {CLOBBER};
  BD.2676 ={v} {CLOBBER};
  return 0;

as you can see r_15 is computed to point to BD.2676 only.  The
"bug" reproduces with -O2 as well if you declare store_10_to_p
static inline.

[Bug middle-end/85599] Function need not be evaluated in logical expression

[janus at gcc dot gnu.org]

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

--- Comment #16 from janus at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #15)
> To be clear.

First of all, I'd have preferred to have a Fortran standard which gives clear
and precise instructions on how a compiler should handle cases like the one
that I brought up. However this does not seem to be the case: A compiler is
apparently allowed (but not required) to do short-circuiting.


> 1) Are you proposing that .AND. should be special-cased to
>force evaluation of both operands?

I'm not quite sure what you mean by "special casing", but I don't think I want
to do that.


> 2) Are you proposing that the operands in rational expressions
>must be evaluated?

Basically yes.

I think gfortran should be more 'conservative' about this optimization: Either
not do short-circuiting at all, or only do it if one can prove that there are
no side effects that can change results (i.e. the case of PURE functions).


> 3) Are you proposing that the operands for all operators must
>be evaluated?

The argument above is not specific to logical operators: An operation should
only be optimized away if it can not change any measurable result.


> If the answer to any of the above is 'yes', then add a new
> option -fno-short-circuit

I'm not too keen on adding a new option. Short-circuiting is not guaranteed by
the standard, so people should not rely on it anyway (also other compilers
don't do it). Performance might slightly decrease in some cases, but I'd hope
it's not that bad (the PURE attribute can help).

I'd prioritize correctness over performance.


> and implement it to transform
> result = op1 binop op2
> 
> into
> 
> tmp1 = op1
> tmp2 = op2
> result = tmp1 BINOP tmp2

That's not what I had in mind. I'd rather make a change from

result = op1 && op2

to

result = op1 & op1

(cf. comment #6).