[Bug c++/83592] New: [8 Regression] Annoying -Wparentheses warnings

[trippels at gcc dot gnu.org]

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

Bug ID: 83592
   Summary: [8 Regression] Annoying -Wparentheses warnings
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
  Target Milestone: ---

Building anything QT related gives many annoying -Wparentheses warnings, e.g.:

 % cat test.ii
int* foo(long &a) { return reinterpret_cast(&a); }

 % g++ -Wall -c test.ii
test.ii: In function ‘int* foo(long int&)’:
test.ii:1:48: warning: unnecessary parentheses in declaration of ‘type name’
[-Wparentheses]
 int* foo(long &a) { return reinterpret_cast(&a); }
^
I don't see what harm these parentheses could cause in this context.

[Bug libgomp/82391] [openacc] acc_on_device not folded at -O0

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01529.html

[Bug rtl-optimization/83513] [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 3) in fill_vec_av_set in selective scheduler

[amonakov at gcc dot gnu.org]

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

--- Comment #5 from Alexander Monakov  ---
Author: amonakov
Date: Tue Dec 26 14:34:33 2017
New Revision: 256001

URL: https://gcc.gnu.org/viewcvs?rev=256001&root=gcc&view=rev
Log:
sel-sched: fix zero-usefulness case in sel_rank_for_schedule (PR 83513)

PR rtl-optimization/83513
* sel-sched.c (sel_rank_for_schedule): Order by non-zero usefulness
before priority comparison.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/sel-sched.c

[Bug middle-end/82407] [meta-bug] qsort_chk fallout tracking

[amonakov at gcc dot gnu.org]

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

Bug 83513 Summary: [8 Regression] ICE: qsort checking failed (error: qsort 
comparator non-negative on sorted output: 3) in fill_vec_av_set in selective 
scheduler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83513

   What|Removed |Added

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

[Bug rtl-optimization/83513] [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 3) in fill_vec_av_set in selective scheduler

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

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

--- Comment #6 from Alexander Monakov  ---
Fixed.

[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really

[Keith.S.Thompson at gmail dot com]

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

--- Comment #7 from Keith Thompson  ---
I don't agree that this bug report is invalid.  I see that the
Bugzilla interface lets me change the status.  Would it be appropriate
to do so?

[Bug middle-end/48968] incorrect warning about longjmp/vfork clobbering a local (-W -O2, x86-64)

[eggert at gnu dot org]

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

--- Comment #13 from Paul Eggert  ---
(In reply to Eric Gallager from comment #12)
> (In reply to Paul Eggert from comment #11)
> > Also please see related bugs Bug 21161, Bug 54561, Bug 61118, Bug 65041, Bug
> > 83162. Perhaps they should be merged?
> 
> Sure, but into which one?

I expect that merges typically go into the lowest-numbered bug, which in this
case is 21161.

[Bug tree-optimization/83593] New: [8 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[asolokha at gmx dot com]

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

Bug ID: 83593
   Summary: [8 Regression] ICE: verify_gimple failed (error:
statement marked for throw, but doesn't)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20171224 snapshot (r255993) ICEs when compiling the following
snippet w/ -O2 (-O3, -Ofast) -fno-tree-dominator-opts -fnon-call-exceptions
-fno-tree-pre -fexceptions -fno-code-hoisting -fno-tree-fre:

void
hr (int *ed, signed char *ju)
{
  int kc;
{
  int xj;
  int *q2 = (*ed == 0) ? &xj : &kc;

  *ju = 0;
  kc = *ju;
}
}

% gcc-8.0.0-alpha20171224 -O2 -fno-tree-dominator-opts -fnon-call-exceptions
-fno-tree-pre -fexceptions -fno-code-hoisting -fno-tree-fre -c czocw0lq.c
czocw0lq.c: In function 'hr':
czocw0lq.c:2:1: error: statement marked for throw, but doesn't
 hr (int *ed, signed char *ju)
 ^~
_7 = 0;
during GIMPLE pass: strlen
czocw0lq.c:2:1: internal compiler error: verify_gimple failed
0xd8250f verify_gimple_in_cfg(function*, bool)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171224/work/gcc-8-20171224/gcc/tree-cfg.c:5569
0xc7490f execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171224/work/gcc-8-20171224/gcc/passes.c:1994
0xc7536e execute_todo
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171224/work/gcc-8-20171224/gcc/passes.c:2048

[Bug ipa/83594] New: ICE: in function_and_variable_visibility, at ipa-visibility.c:640 with __attribute__((noipa))

[zsojka at seznam dot cz]

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

Bug ID: 83594
   Summary: ICE: in function_and_variable_visibility, at
ipa-visibility.c:640 with __attribute__((noipa))
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: jakub at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42966
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42966&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc testcase.c 
during IPA pass: visibility
testcase.c:5:1: internal compiler error: in function_and_variable_visibility,
at ipa-visibility.c:640
 }
 ^
0x8e91e6 function_and_variable_visibility
/repo/gcc-trunk/gcc/ipa-visibility.c:640
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


This attribute is new in gcc-8.

[Bug c/83595] New: [8 Regression] ICE: in linemap_macro_map_lookup, at libcpp/line-map.c:1008 on invalid code

[zsojka at seznam dot cz]

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

Bug ID: 83595
   Summary: [8 Regression] ICE: in linemap_macro_map_lookup, at
libcpp/line-map.c:1008 on invalid code
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Created attachment 42967
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42967&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc testcase.c   
testcase.c: In function 'foo':
testcase.c:4:5: error: expected expression before ')' token
   (())((int){0);
 ^
testcase.c:4:5: internal compiler error: in linemap_macro_map_lookup, at
libcpp/line-map.c:1008
0x17b7a07 linemap_macro_map_lookup
/repo/gcc-trunk/libcpp/line-map.c:1008
0x17b7a07 linemap_lookup(line_maps*, unsigned int)
/repo/gcc-trunk/libcpp/line-map.c:942
0x17b8619 get_pure_location(line_maps*, unsigned int)
/repo/gcc-trunk/libcpp/line-map.c:335
0x17978e6 get_pure_location
/repo/gcc-trunk/gcc/input.h:91
0x17978e6 make_location(unsigned int, unsigned int, unsigned int)
/repo/gcc-trunk/gcc/input.c:890
0x97b9fd c_expr::get_location() const
/repo/gcc-trunk/gcc/c/c-tree.h:155
0x97b9fd c_parser_expr_list
/repo/gcc-trunk/gcc/c/c-parser.c:9390
0x97c3fc c_parser_postfix_expression_after_primary
/repo/gcc-trunk/gcc/c/c-parser.c:9128
0x96cc3b c_parser_postfix_expression
/repo/gcc-trunk/gcc/c/c-parser.c:8978
0x976362 c_parser_unary_expression
/repo/gcc-trunk/gcc/c/c-parser.c:7258
0x97720a c_parser_cast_expression
/repo/gcc-trunk/gcc/c/c-parser.c:7102
0x977462 c_parser_binary_expression
/repo/gcc-trunk/gcc/c/c-parser.c:6905
0x978275 c_parser_conditional_expression
/repo/gcc-trunk/gcc/c/c-parser.c:6643
0x9788c0 c_parser_expr_no_commas
/repo/gcc-trunk/gcc/c/c-parser.c:6560
0x978b12 c_parser_expression
/repo/gcc-trunk/gcc/c/c-parser.c:9290
0x97ab96 c_parser_expression_conv
/repo/gcc-trunk/gcc/c/c-parser.c:9323
0x985fe0 c_parser_statement_after_labels
/repo/gcc-trunk/gcc/c/c-parser.c:5538
0x988079 c_parser_compound_statement_nostart
/repo/gcc-trunk/gcc/c/c-parser.c:5076
0x988586 c_parser_compound_statement
/repo/gcc-trunk/gcc/c/c-parser.c:4911
0x989c9c c_parser_declaration_or_fndef
/repo/gcc-trunk/gcc/c/c-parser.c:2340
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-255981-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-255981-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 8.0.0 20171222 (experimental) (GCC)

[Bug fortran/83218] gforttran command fails to compile if fortran file is present inside folder "%+@"

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
WORKSFORME as well with 8.0.  I tried sh, bash, and tcsh.
I suspect that one of %+@ is being interpreted as a special
character with whatever shell Sanket uses.

[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
The code in comment #0 compiles with gfortran 8.0.0 20171224.

The code in comment #2 still causes an ICE.  The code in this
comment is probably invalid as ncells is never set.  It may
also be invalid in that ncells may not be allowed to be 
used in an initialization expression, but I would need to go 
read up on the conditions on initialization expression and
host association.

[Bug c++/83596] New: ['17] can't use member pointer result of a constexpr function as template argument

[oremanj at mit dot edu]

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

Bug ID: 83596
   Summary: ['17] can't use member pointer result of a constexpr
function as template argument
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oremanj at mit dot edu
  Target Milestone: ---

The below C++ program defines a constexpr function that returns a
pointer-to-member, then attempts to use that pointer-to-member as a template
argument. I believe this is fine by the standard, and clang (5.0.0) accepts it,
but gcc complains, in a fashion that suggests there's some internal confusion
about types going on.

$ cat t.cc
struct X { int x; int y; };
template  int get(X& x) { return x.*mp; }
constexpr int X::* getMP() { return &X::y; }
constexpr int X::* mptr = getMP();
int test() {
X x{1, 2};
return get(x);
}

$ g++ -std=c++17 -c t.cc
t.cc: In function 'int test()':
t.cc:7:23: error: no matching function for call to 'get(X&)'
return get(x);
   ^
t.cc:2:28: note: candidate: template int get(X&)
template  int get(X& x) { return x.*mp; }
   ^~~
t.cc:2:28: note:   template argument deduction/substitution failed:
t.cc:7:23: error: '4' is not a valid template argument for type 'int X::*'
return get(x);
  ^
t.cc:7:23: note: it must be a pointer-to-member of the form '&X::Y'

$ g++ --version
g++ (GCC-Explorer-Build) 8.0.0 20171226 (experimental)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The error is unchanged under any of the following perturbations:
- every 'int X::*' is replaced by 'auto'
- the result of getMP() is passed as the template argument directly
- mptr is defined as &X::y directly, getMP() is defined to return mptr, and
get() is instantiated with  as its argument
- optimizations are used or not used
- either getMP() or mptr is assigned to a local-scope constexpr in test() which
is then used as the template argument

Compilation succeeds if there is no constexpr function involved, e.g. if the
source file says 'constexpr int X::* mptr = &X::y;' directly.

gcc 7.2.1 returns a slightly different error message; the final "note:" above
is replaced with

t.cc:7:23: error: it must be a pointer-to-member of the form '&X::Y'
t.cc:7:23: error: could not convert template argument 'mptr' from 'int X::*
const' to 'int X::*'

[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||jsm28 at gcc dot gnu.org,
   ||manu at gcc dot gnu.org

--- Comment #8 from Manuel López-Ibáñez  ---
(In reply to Keith Thompson from comment #7)
> I don't agree that this bug report is invalid.  I see that the
> Bugzilla interface lets me change the status.  Would it be appropriate
> to do so?

Please change it to UNCONFIRMED if you wish to reopen it.

Given the current definition of -pedantic-errors, it is sometimes very subtle
whether something should be an error or not with -pedantic-errors. There are
definitely some warnings that should not be there.

I'll defer to Joseph or any other C FE maintainers to make the final call.

Suggestions for a more precise text are welcome, specially if they come in the
form of a patch that also updates the testsuite to match the new text.

[Bug fortran/83093] ICE in fold_convert_loc, at fold-const.c:2266

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> With invalid code, down to at least 4.8 :
> 
> 
> $ cat z1.f90
> program p
>character(:), allocatable :: z
>allocate (character(a) :: z)
> end
> 
> 

This appears to be a case where the individual who 
wrote match.c(gfc_match_type_spec) overlooked that
one needs to check for a valid length_selector.

[Bug c++/83592] [8 Regression] Annoying -Wparentheses warnings

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  ---
This seems be a false positive, since int(*) can never be confused with a
function call.

Also, the text perhaps could explain the rational behind the warning:

warning: unnecessary parentheses in declaration of ‘type name’ may be confused
with a function call

With the text above, it becomes clear that the warning is a bug.

[Bug c++/83591] -Wduplicated-branches fires in system headers in template instantiation

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-26
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Manuel López-Ibáñez  ---
> cc1plus: error: this condition has identical branches

This suggests that GCC has somehow lost the source location info for this
warning (even the file location), so GCC does not know that it happens inside a
system header nor it can be silenced with #pragmas, since those rely on the
location.

> I suspect this is related to
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82541 but it has differences:

I think PR82541 is asking that cond ? A : B is not warned about if A and B are
textually different, even if they are template parameters that expand to the
same expression.

In your case, the warning is correct, but the location is broken, so the
location-based tricks to silence it do not work.

[Bug c++/82541] Wduplicated-branches triggers in template context

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-26
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
This is also a problem with macros:

https://www.redhat.com/archives/libvir-list/2017-June/msg00608.html

[Bug c++/82541] Wduplicated-branches triggers in template context

[manu at gcc dot gnu.org]

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

--- Comment #2 from Manuel López-Ibáñez  ---
As mentioned here: https://patchwork.ozlabs.org/patch/684040/

This may need to wait until we have more precise location info for constants
and variable uses.

[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really

[Keith.S.Thompson at gmail dot com]

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

Keith Thompson  changed:

   What|Removed |Added

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

--- Comment #9 from Keith Thompson  ---
In my opinion, this is a genuine bug. The conversion warrants a warning,
but not a fatal error. (For it to be an error, it should violate a specific
constraint or syntax rule.)

[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

[neil.n.carlson at gmail dot com]

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

--- Comment #5 from Neil Carlson  ---
I disagree (in part) with comment 4.  Ncells is a valid specification statement
(see 7.1.11, par 2 (4), Fortran 2008).  Its value need not be known at compile
time; only when the get() function is executed.  If the code successfully
compiled then, yes, at run time it is not conforming because ncells was never
assigned a value.

Interestingly if the main program is modified to use mod1 (but still not define
ncells) then the ICE goes away.

use mod1
use mod2
s = sum(get())
end

So perhaps there is something here about mod1 going out of scope.  I forget how
that works, and seem to recall that some new standard was going to drop that
feature of the language.

However that aspect can be side stepped by just turning the main program into a
subprogram

subroutine sub
use mod2
s = sum(get())
end

This still gives an ICE and I believe is valid.  Both NAG and Intel compile
without error, fwtw.

[Bug c/11234] -pedantic accepts function pointer <-> void*

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||Keith.S.Thompson at gmail dot 
com

--- Comment #6 from Andrew Pinski  ---
*** Bug 83584 has been marked as a duplicate of this bug. ***

[Bug c/11234] -pedantic accepts function pointer <-> void*

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|3.4.0   |---

[Bug c/11234] -pedantic accepts function pointer <-> void*

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #7 from Andrew Pinski  ---
Reopening based on the duplicated bug says our reading of the standard is
incorrect.  But I will let someone else decide if that is really true or not.

[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
Marking as a dup of bug 11234.

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

[Bug c/11234] -pedantic accepts function pointer <-> void*

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=75595

[Bug c/11234] -pedantic accepts function pointer <-> void*

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |3.4.0

--- Comment #9 from Andrew Pinski  ---
https://gcc.gnu.org/ml/gcc-patches/2004-01/msg00599.html

This patch fixes PR c/11234 (nondiagnosis of certain invalid
conversions between function and object pointers). 

So fixed.

[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really

[pinskia at gcc dot gnu.org]

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Manuel López-Ibáñez from comment #8)
> I'll defer to Joseph or any other C FE maintainers to make the final call.

https://gcc.gnu.org/ml/gcc-patches/2004-01/msg00599.html

See that email about how this is invalid conversions from JSM already.

"This patch fixes PR c/11234 (nondiagnosis of certain invalid
conversions between function and object pointers). "

So again this is not a bug.

[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really

[Keith.S.Thompson at gmail dot com]

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

--- Comment #12 from Keith Thompson  ---
Andrew:

In my opinion, such conversions have undefined behavior (simply because
the standard does not define their behavior), but they are not forbidden.

The "-pedantic" and "-pedantic-errors" options, as I understand their
description, cause gcc to produce all diagnostic required by the C
standard. The only required diagnostics are for (a) #error directives,
(b) violations of syntax rules, and (c) violations of constraints.

Is my understanding correct?

If so, what syntax rule or constraint is violated by the program in
the description?

For example, (void*)1.0 violates the constraint in N1570 6.5.4 p4.

(I'll note in passing, without claiming that it's directly relevant,
that "clang -c -std=c11 -pedantic-errors" does not produce a diagnostic.)

This is not a duplicate of #11234, it's the opposite. #11234 complains
that a diagnostic is not produced; this bug report complains that it does.

I don't want to get into an editing war, so I'll leave the status as it
is for now.

[Bug lto/82027] [7/8 Regression] wrong code with -O3 -flto

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||aoliva at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org

--- Comment #15 from Alexandre Oliva  ---
AFAICT this is fixed; thanks, Martin!

[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Tue, Dec 26, 2017 at 08:00:29PM +, neil.n.carlson at gmail dot com
wrote:
> 
> I disagree (in part) with comment 4.
>

As you failed to quote the part that is disagreeable, it is
somewhat difficult to pursue.  The code is clearly invalid
in that ncells is reference but is never set.

[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

[neil.n.carlson at gmail dot com]

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

--- Comment #7 from Neil Carlson  ---
Perhaps this modification of comment 2 code is clearer.

Put this in one file:

module mod1
  integer :: ncells
end module

module mod2
contains
  function get() result(array)
use mod1
real array(ncells)
array = 1.0
  end function
end module

And this in another (this is different):

subroutine sub
use mod2
s = sum(get())
end

This gives an ICE when compiled with 8.0.0 (20171222).

NCELLS is a valid specification expression.

A valid full program that calls SUB would have to define NCELLS before doing
so. However it is not required that the compiler know the value of NCELLS at
compile time.

[Bug rtl-optimization/81611] [8 Regression] gcc un-learned loop / post-increment optimization

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #3 from Alexandre Oliva  ---
I see the same problem on x86_64.  Compiling with -fno-tree-forwprop stops
str_6 from being propagated out of the loop, so it dies at the str_11 def and
everything optimizes nicely.

[Bug fortran/83540] [8 Regression] Invalid code with MATMUL, -fno-realloc-lhs -ffrontend-optimize

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Dec 26 23:29:20 2017
New Revision: 256003

URL: https://gcc.gnu.org/viewcvs?rev=256003&root=gcc&view=rev
Log:
2017-12-26  Thomas Koenig  

PR fortran/83540
* frontend-passes.c (create_var): If an array to be created
has unknown size and -fno-realloc-lhs is in effect,
return NULL.

2017-12-26  Thomas Koenig  

PR fortran/83540
* gfortran.dg/inline_matmul_20.f90: New test.


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

[Bug tree-optimization/81611] [8 Regression] gcc un-learned loop / post-increment optimization

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|rtl-optimization|tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org

--- Comment #4 from Alexandre Oliva  ---
Mine; patch will be attached momentarily.

[Bug fortran/83540] [8 Regression] Invalid code with MATMUL, -fno-realloc-lhs -ffrontend-optimize

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #7 from Thomas Koenig  ---
Fixed, closing.

[Bug fortran/20520] allocatable arrays used uninitialized without a warning

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #17 from Thomas Koenig  ---
There is a warning now:

$ gfortran -O -Wall a.f90
a.f90:3:0:

 a(1)=2*b(1)

Warning: ‘b.offset’ is used uninitialized in this function [-Wuninitialized]
a.f90:3:0: Warning: ‘a.offset’ is used uninitialized in this function
[-Wuninitialized]
a.f90:3:0:

 a(1)=2*b(1)

Warning: ‘b.offset’ is used uninitialized in this function [-Wuninitialized]
a.f90:1:0:

 real,allocatable:: a(:),b(:)

note: ‘b.offset’ was declared here
a.f90:3:0:

 a(1)=2*b(1)

Warning: ‘a.offset’ is used uninitialized in this function [-Wuninitialized]
a.f90:1:0:

 real,allocatable:: a(:),b(:)

note: ‘a.offset’ was declared here

Although the text is a bit unclear it does show that something
is wrong.

So, commit a test case and close as fixed?

[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl  ---
On Tue, Dec 26, 2017 at 09:42:54PM +, neil.n.carlson at gmail dot com
wrote:
>
> Perhaps this modification of comment 2 code is clearer.

ncell is never set.

> Put this in one file:
> 
> module mod1
>   integer :: ncells
> end module
> 
> module mod2
> contains
>   function get() result(array)
> use mod1
> real array(ncells)

The reference to ncells is to an undefined entity. 

> array = 1.0
>   end function
> end module
> 
> And this in another (this is different):
> 
> subroutine sub
> use mod2

You need to have 

  ncells = 1  ! or some other value here.

> s = sum(get())
> end
> 
> This gives an ICE when compiled with 8.0.0 (20171222).

The code with ncells properly defined defined still
hits an ICE.  This probably a result of not walking
mod2's namespace, but I haven't tried to debug the
problem beyond this.

[Bug tree-optimization/81611] [8 Regression] gcc un-learned loop / post-increment optimization

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  ---
Created attachment 42968
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42968&action=edit
partial candidate patch

Alas, although it restores good code for x86_64 and arm, it doesn't go as far
as enabling avr to use auto_inc (though auto_inc use is restored on arm). 
Still looking...

[Bug c/11234] -pedantic accepts function pointer <-> void*

[h.b.furuseth at usit dot uio.no]

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

--- Comment #10 from Hallvard B Furuseth  ---
On 26/12/17 21:13, pinskia at gcc dot gnu.org wrote:
> Reopening based on the duplicated bug says our reading of the standard is
> incorrect.  But I will let someone else decide if that is really true or not.

Er, yes.  I wrote the bug report that caused that warning, and I think I
was wrong.  The warning should go away, or move to -Wextra or something.

Hallvard

[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really

[txr at alumni dot caltech.edu]

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

Tim Rentsch  changed:

   What|Removed |Added

 CC||txr at alumni dot caltech.edu

--- Comment #13 from Tim Rentsch  ---
(In reply to Andrew Pinski from comment #11)
> So again this is not a bug.

I mostly agree, but I think some clarification is needed.  For reference
here is the diagnostic gcc gives (under -pedantic-errors)

   error: ISO C forbids conversion of object pointer to function pointer

This text is wrong because it is factually incorrect.  There is nothing
in the ISO C standard that forbids or prohibits converting an object
pointer type to a function pointer type, or vice versa.

The catch is that these conversions aren't required to be supported
either.  Section 6.3 discusses conversions, with section 6.3.2.3
specifically concerned with pointer types.  Each case involving converting
a type to or from a pointer type is listed with a specific permission, eg,
"Any pointer type may be converted to an integer type."  There is no such
statement that says object pointer types may be converted to function
pointer types, or vice versa.  We may reasonably infer from these
statements that the "may be converted" cases must be accepted by all
conforming compilers, but not the others.  To say this the other way, any
case not explicitly covered (involving a pointer type) /may/ be accepted
but is not required to be.  Of course if such a conversion is evaluated
its behavior is undefined, but I mean something else, namely, whether a
program is accepted if it contains any such conversion, whether it is
evaluated or not.  To me it seems clear that the ISO C standard means that
such a program doesn't have to be accepted:  it /can/ be accepted, but it
doesn't /have/ to be.

Note section 4 paragraph 5:  "A /strictly conforming program/ shall use
only those features of the language and library specified in this
International Standard."  Converting between object pointer types and
function pointer types is not covered in the Standard.  I don't mean the
behavior isn't defined;  I mean the case is not addressed, ie, it is not a
feature of the language.  Hence any program containing such a conversion
is not a strictly conforming program, and as such it can be rejected.  So
I believe gcc is within its rights to make this an error.  It would be
nice if the diagnostic text were better, and consistent with what the
Standard says, but as far as being an error goes I think gcc is in the
clear here.

[Bug tree-optimization/81611] [8 Regression] gcc un-learned loop / post-increment optimization

[aoliva at gcc dot gnu.org]

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

--- Comment #6 from Alexandre Oliva  ---
Created attachment 42969
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42969&action=edit
complementary candidate patch

This patch complements the earlier one.  

On AVR, unlike other ports, we had the increment computed into a separate
pseudo, then the memory store using the original pseudo, then the copy of the
separate pseudo to the original one.  auto_inc_dec can't deal with such a
sequence.  It could deal with it if the increment was after the memory access,
which would have already eliminated the temporary and the copy.

So, instead of extending auto_inc_dec to deal with a more complex scenario
involving 3 insns, I decided to try and move the increment down, past the
memory access, so as to benefit even ports without auto_inc addressing modes by
avoiding SSA conflicts and reducing the use of temporaries.

It moves IV increment stmts that are not used within their own blocks closer to
the end of the block, so as to reduce the likelihood of a SSA conflict with the
PHI node.  This also makes it more likely that the increment will appear after
memory uses with which it can be combined into a post_inc addressing mode.

[Bug tree-optimization/81611] [8 Regression] gcc un-learned loop / post-increment optimization

[aoliva at gcc dot gnu.org]

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

--- Comment #7 from Alexandre Oliva  ---
Hmm, what the complementary patch won't do is improve the odds of auto_inc or
even saving a temp in spaghetti code, rather than in loops.  Maybe that's
important too?  I wonder if we should add the post-increment to the gimple stmt
seq after the use of the old value, like IIRC we used to.

[Bug tree-optimization/81611] [8 Regression] gcc un-learned loop / post-increment optimization

[aoliva at gcc dot gnu.org]

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

--- Comment #8 from Alexandre Oliva  ---
Created attachment 42970
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42970&action=edit
alternative (?) complementary candidate patch

This addresses the concern of post-increment in non-loops.  It solves the
problem along with the initial partial patch, but I'm still undecided as to the
second.  I already know it is broken (there's a thinko in the case that handles
all uses in a single stmt), and once the postinc auto_inc addressing modes are
handled by this third patch, I'm not sure yet whether the SSA conflict
reduction the second one affords are worth the trouble any more.  I'll try to
actually measure the effects, once I verify that it (or rather a fixed version
thereof) works.

[Bug tree-optimization/81611] [8 Regression] gcc un-learned loop / post-increment optimization

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

  Attachment #42969|0   |1
is obsolete||

--- Comment #9 from Alexandre Oliva  ---
Created attachment 42971
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42971&action=edit
updated complementary candidate patch

This updated patch fixes a bug in the sinking patch, in the path that handled
all uses in a single stmt.

[Bug c++/83046] ICE in nvptx offloading, C++ compilation of libgomp.oacc-c-c++-common/gang-static-2.c

[vries at gcc dot gnu.org]

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

--- Comment #9 from Tom de Vries  ---
Author: vries
Date: Wed Dec 27 07:50:04 2017
New Revision: 256008

URL: https://gcc.gnu.org/viewcvs?rev=256008&root=gcc&view=rev
Log:
Workaround PR83046 in gang-static-2.c

2017-12-27  Tom de Vries  

PR c++/83046
* testsuite/libgomp.oacc-c-c++-common/gang-static-2.c (test_static)
(test_nonstatic): Fix return type to workaround PR83046.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/gang-static-2.c

[Bug tree-optimization/81611] [8 Regression] gcc un-learned loop / post-increment optimization

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

  Attachment #42971|0   |1
is obsolete||

--- Comment #10 from Alexandre Oliva  ---
Created attachment 42972
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42972&action=edit
2xupdated complementary candidate patch

It looked like the build was going so well, but...  No such luck.  Watch out
for CPU-eating zombies with the previous patch; it may loop endlessly moving a
stmt just before its successor over and over and over.  I suppose the old code
really didn't mean to move stuff within a single BB, otherwise it would have
checked this case.  Anyhow...  One more bug fixed, bootstrap well into
stage3...