[Bug c/69404] atomic builtins accept incompatible pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69404
--- Comment #5 from Martin Sebor ---
The GCC manual says the __atomic builtins are meant to be compatible with those
described in the Intel Itanium Processor-specific Application Binary Interface,
section 7.4. Both the ABI and the GCC manual describe the builtins to operate
on objects of some /type/. For example, __atomic_load is described like so:
__atomic_load (type *ptr, type *ret, int memorder)
implying that ptr and ret should be compatible. (The ABI doesn't describe
__atomic_load but it does describe many of the __atomic builtins.)
GCC rejects the test cases when the __atomic builtins are replaced with the
corresponding C11 atomic generic functions defined in , but only
because these are implemented as macros involving conversions that detect the
incompatibility. The C11 generics that don't do such conversions are just as
impotent at detecting incompatibilities as the corresponding builtins. For
example, GCC doesn't diagnose the program below (both Clang and Intel CC do
issue the expected diagnostic -- ICC when the _Atomic keyword is removed as it
doesn't seem to understand it yet).
$ cat z.c && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -S -Wall -Wextra -Wpedantic -o/dev/null
z.c
#include
int* foo (void (*p)(void))
{
int* _Atomic q;
atomic_init (&q, 0);
atomic_fetch_add (&q, p);
return q;
}
I certainly agree that GCC can define its own extensions any way it sees fit.
But I can think of no use for this "extension" except to make it easier to
accidentally write incorrect code.
Incidentally, I came across this problem while testing a patch for bug 64843
(and improving the documentation of the builtins in the GCC manual op resolve
bug 52291).
[Bug tree-optimization/69400] [5/6 Regression] wrong code with -O and int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69400 H.J. Lu changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #2 from H.J. Lu --- It is caused by r210113.
[Bug c/52291] __sync_fetch_and_add and friends poorly specified for pointer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52291 --- Comment #6 from Martin Sebor --- Author: msebor Date: Thu Jan 21 03:38:32 2016 New Revision: 232662 URL: https://gcc.gnu.org/viewcvs?rev=232662&root=gcc&view=rev Log: PR c/52291 - __sync_fetch_and_add and friends poorly specified for pointer types 2016-01-20 Martin Sebor * extend.texi (__sync Builtins): Clarify the semantics of __sync_fetch_and_OP built-ins on pointers. (__atomic Builtins): Same. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi
[Bug c/52291] __sync_fetch_and_add and friends poorly specified for pointer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52291 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Sebor --- Fixed in r232662.
[Bug c/69405] New: [6 Regression] ICE in c_tree_printer on an invalid __atomic_fetch_add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69405
Bug ID: 69405
Summary: [6 Regression] ICE in c_tree_printer on an invalid
__atomic_fetch_add
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Today's trunk fails with the ICE below on the following invalid test case (p is
not declared). 5.1.0 issues the expected errors and exits.
$ cat z.c && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -S -Wall -Wextra -Wpedantic -o/dev/null
z.c
void foo (void)
{
int *q = 0;
__atomic_fetch_add (&p, &q, 0);
}
z.c: In function ‘foo’:
z.c:4:26: error: ‘p’ undeclared (first use in this function)
__atomic_fetch_add (&p, &q, 0);
^
z.c:4:26: note: each undeclared identifier is reported only once for each
function it appears in
‘
in c_tree_printer, at c/c-objc-common.c:128
__atomic_fetch_add (&p, &q, 0);
^~
0x7c05b4 c_tree_printer
/home/msebor/scm/fsf/gcc-git/gcc/c/c-objc-common.c:128
0x184814a pp_format(pretty_printer*, text_info*)
/home/msebor/scm/fsf/gcc-git/gcc/pretty-print.c:634
0x1841e2d diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/msebor/scm/fsf/gcc-git/gcc/diagnostic.c:797
0x18430ff error(char const*, ...)
/home/msebor/scm/fsf/gcc-git/gcc/diagnostic.c:1157
0x83fa29 sync_resolve_size
/home/msebor/scm/fsf/gcc-git/gcc/c-family/c-common.c:10708
0x840e78 resolve_overloaded_builtin(unsigned int, tree_node*, vec*)
/home/msebor/scm/fsf/gcc-git/gcc/c-family/c-common.c:11393
0x790edf c_build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*)
/home/msebor/scm/fsf/gcc-git/gcc/c/c-typeck.c:3098
0x7d3988 c_parser_postfix_expression_after_primary
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:8222
0x7d311e c_parser_postfix_expression
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:8034
0x7cf35e c_parser_unary_expression
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:6852
0x7ce7d7 c_parser_cast_expression
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:6681
0x7cd4d9 c_parser_binary_expression
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:6490
0x7ccd6f c_parser_conditional_expression
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:6261
0x7cca7f c_parser_expr_no_commas
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:6178
0x7d4140 c_parser_expression
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:8363
0x7d4395 c_parser_expression_conv
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:8396
0x7ca83d c_parser_statement_after_labels
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:5251
0x7c9c27 c_parser_compound_statement_nostart
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:4835
0x7c962f c_parser_compound_statement
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:4671
0x7c42ee c_parser_declaration_or_fndef
/home/msebor/scm/fsf/gcc-git/gcc/c/c-parser.c:2088
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug fortran/68442] ICE on kind specification, depending on ordering of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68442 --- Comment #5 from Jerry DeLisle --- (In reply to Dominique d'Humieres from comment #4) > Related to pr69397. With the patch in pr69397 comment 2, the ICE is replaced > with the error: > > pr68442.f90:7:21: > >character(kind=gkind()) :: x > 1 > > Error: There is no specific function for the generic 'gkind' at (1) > > When I applied the patch, I was not happy with this message: it points to > the problem, but IMO with a wrong diagnostic. I am currently getting: $ gfc pr68442.f90 pr68442.f90:10:21: character(kind=gkind()) :: x 1 Error: Function ‘gkind’ in initialization expression at (1) must be an intrinsic function
[Bug c/69405] [6 Regression] ICE in c_tree_printer on an invalid __atomic_fetch_add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69405 Martin Sebor changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-01-21 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Looks like my own r232147 is the responsible commit.
[Bug fortran/69397] ICE on missing subprogram in generic interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69397 --- Comment #3 from Jerry DeLisle --- (In reply to Dominique d'Humieres from comment #2) > Related to/duplicate of pr68442. Sort of related, but I find 68442 fixed already. > - gcc_assert (sym->attr.flavor == FL_PROCEDURE); > + /* gcc_assert (sym->attr.flavor == FL_PROCEDURE); */ > + if (sym->attr.flavor != FL_PROCEDURE) > +return false; > How is this for error messages (I tweaked the second one): $ gfc pr69397.f90 pr69397.f90:3:18: procedure f1 1 Error: Procedure ‘f1’ in generic interface 'f' at (1) is neither function nor subroutine pr69397.f90:7:11: print *, f(z) 1 Error: Generic procedure ‘f’ at (1) must have a specific procedure defined
[Bug testsuite/69371] UNRESOLVED: special_functions/18_riemann_zeta/check_value.cc compilation failed to produce executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69371 --- Comment #4 from Thomas Preud'homme --- Doh, I should have caught that earlier. The bug can be seen in: % grep -c dg-option special_functions/18_riemann_zeta/check_value.cc 3 Using dg-additional-option for the timeout solves the issue. Maybe the patch could also remove the redundant timeout adjustment in the testcase?
[Bug c/69405] [6 Regression] ICE in c_tree_printer on an invalid __atomic_fetch_add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69405 Martin Sebor changed: What|Removed |Added Known to fail||6.0 --- Comment #2 from Martin Sebor --- Fix posted for review: https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01592.html
[Bug testsuite/69406] New: FAIL: 17_intro/headers/c++2011/linkage.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69406 Bug ID: 69406 Summary: FAIL: 17_intro/headers/c++2011/linkage.cc (test for excess errors) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: thopre01 at gcc dot gnu.org CC: redi at gcc dot gnu.org Target Milestone: --- Target: arm-none-eabi 17_intro/headers/c++2011/linkage.cc fails on arm-none-eabi targets with the error: 17_intro/headers/c++2011/linkage.cc:47:19: fatal error: uchar.h: No such file or directory (...) FAIL: 17_intro/headers/c++2011/linkage.cc (test for excess errors) This is because arm-none-eabi uses newlib which does not provide uchar.h. I am not sure about the correct course of action. Should a xfail be added for newlib targets? Since uchar.h seems to come from C11, maybe it would be more appropriate to xfail all tests involving C11 for newlib target? Best regards.
[Bug c/69407] New: -Wunused-value on __atomic_fetch_OP and __atomic_OP_fetch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69407
Bug ID: 69407
Summary: -Wunused-value on __atomic_fetch_OP and
__atomic_OP_fetch
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Invoking the __atomic_fetch_OP and __atomic_OP_fetch intrinsics without using
their return value elicits a -Wunused-value warning. The warning doesn't seem
useful, especially in the __atomic_OP_fetch(ptr, val) case, since a) whether
the computed value is used impossible to determine at the call site, and b) the
corresponding (*ptr OP= val) expressions don't cause any warnings. (As
expected, the warnings can be suppressed by casting the result ti void).
No other CCC-compatible compiler emits warnings for these intrinsics.
$ cat z.c && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -S -Wall -Wextra -Wpedantic -o/dev/null
z.c
void foo (int*i, int);
void foo (int *p, int a)
{
__atomic_fetch_add (&p, a, 0);
__atomic_add_fetch (&p, a, 0);
}
z.c: In function ‘foo’:
z.c:5:5: warning: value computed is not used [-Wunused-value]
__atomic_fetch_add (&p, a, 0);
^
z.c:6:5: warning: value computed is not used [-Wunused-value]
__atomic_add_fetch (&p, a, 0);
^
[Bug tree-optimization/69400] [5/6 Regression] wrong code with -O and int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69400 --- Comment #3 from H.J. Lu --- Fix this may also fix PR 69399.
[Bug tree-optimization/69400] [5/6 Regression] wrong code with -O and int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69400 --- Comment #4 from H.J. Lu --- Before wide-int: Lattice value changed to CONSTANT 18446744073709551614. Adding SSA edges to worklist. After wide-int: Lattice value changed to CONSTANT 0xfffe. Adding SSA edges to worklist. It is wrong to sign-extend (__int128) 0xfffe.
[Bug ipa/68273] [5/6 Regression] Wrong code on mips/mipsel with -fipa-sra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #4 from Jeffrey A. Law ---
It's starting to look like a problem in tree-ssa-pre.c
Essentially we have these these key statements in various blocks:
_10 = yyvsp_1->sym;
_15 = yyvsp_1->sym;
_17 = enter (_14, _15);
_22 = MEM[(union YYSTYPE *)yyvsp_1];
Respectively _10 and _22 have the types:
(gdb) p debug_tree (cfun->gimple_df->ssa_names.m_vecdata[10]->typed.type)
unit size
align 32 symtab 0 alias set -1 canonical type 0x703842a0
fields
unsigned SI file j.c line 4 col 9 size unit size
align 32 offset_align 64
offset
bit offset context
> context
pointer_to_this chain >
sizes-gimplified public unsigned SI size
unit size
align 32 symtab 0 alias set -1 canonical type 0x703c6540>
(gdb) p debug_tree (cfun->gimple_df->ssa_names.m_vecdata[22]->typed.type)
unit size
align 8 symtab 0 alias set -1 canonical type 0x703843f0 context
pointer_to_this chain >
sizes-gimplified unsigned SI
size constant 32>
unit size constant 4>
align 64 symtab 0 alias set -1 canonical type 0x70384d20>
The type of _15 is the same as the type of _10.
For reference, we're referring to instances of this structure:
union YYSTYPE
{
Symbol *sym;
Node rec;
};
The key thing to note from the types is they have different alignments.
Anyway, PRE detects the redundant memory reference and creates:
# prephitmp_23 = PHI
Where _23 and _26 will have the type with the 64 bit alignment.
That node feeds this statement:
_17 = enter (_14, prephitmp_23);
Yow! Remember that statement previously looked like:
_17 = enter (_14, _15);
So the alignment associated with the second argument to "enter" has changed
from 32 to 64. That in turn may change how the argument gets passed on some
ports (mips, epiphany, maybe others). In this specific instance is causes the
MIPS backend to align the parameter, passing it in $6 rather than where the
callee expects it ($5), which in turn results in gsoap being mis-compiled on
MIPS.
Richi -- you know the PRE code better than anyone that's currently active.
Thoughts?
[Bug preprocessor/55115] [4.9/5/6 Regression] missing headers as fatal breaks cproto logic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55115 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |WONTFIX --- Comment #17 from Jeffrey A. Law --- Fundamentally, trying to include a non-existent header should trigger a fatal error. The fact that cproto has depended on GCC not doing that is unfortunate, but I don't think catering to this broken cproto design is something we ought to do.
