[Bug bootstrap/58289] New: gcc/gengtype.c includes gcc/double-int.h, which uses C++ constructs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58289
Bug ID: 58289
Summary: gcc/gengtype.c includes gcc/double-int.h, which uses
C++ constructs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: jklowden at schemamania dot org
I pulled from svn://gcc.gnu.org/svn/gcc/trunk today to build gcc on OS X using
Clang. Some header files use C++ syntax, but are included in C files. The
error I'm seeing is:
/Developer/usr/bin/clang [...options omitted...]
-o build/gengtype.o ../../gcc/gengtype.c
[...warnings ommitted...]
In file included from ../../gcc/gengtype.c:28:
../../gcc/double-int.h:58:10: error: must use 'struct' tag to refer to type
'double_int'
static double_int from_uhwi (unsigned HOST_WIDE_INT cst);
The error stems from this construct in double-int.h:
==snip==
struct double_int
{
/* Normally, we would define constructors to create instances.
Two things prevent us from doing so.
First, defining a constructor makes the class non-POD in C++03,
and we certainly want double_int to be a POD.
Second, the GCC conding conventions prefer explicit conversion,
and explicit conversion operators are not available until C++11. */
static double_int from_uhwi (unsigned HOST_WIDE_INT cst);
==pins==
Comment not withstanding, the file could easily be converted to C; there are no
classes declared, for instance. All that's needed is say,
static struct double-int from_uhwi = cst;
perhaps with a cast.
I found similar problems in two other files that were small enough to repair or
work around. This file seems to be a pupa determined to become C++, and I'm
not quite sure what should be done.
[Bug c/58288] Incorrect error message on malformed section attribute syntax.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58288
--- Comment #2 from Ralph Loader ---
Created attachment 30735
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30735&action=edit
Patch
Patch to change the error message attached. I also noticed another problem: we
were setting the global variable user_defined_section_attribute for the
following:
int * foo(void) {
static int a __attribute__((section("mysection")));
return &a;
}
But looking at how user_defined_section_attribute is used (in bb-reorder.c), it
appears to apply to just the function, not the local variables.
[Bug c/58288] Incorrect error message on malformed section attribute syntax.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58288 --- Comment #1 from Ralph Loader --- Whoops I meant "not specified *correctly*" rather than just "not specified".
[Bug c/58288] New: Incorrect error message on malformed section attribute syntax.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58288 Bug ID: 58288 Summary: Incorrect error message on malformed section attribute syntax. Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: suckfish at ihug dot co.nz If a section attribute is malformed, then the gcc error message incorrectly claims that the "section attribute [is] not allowed". For the example below, a section attribute is allowed, the actual cause of the error is that the section name is not specified. $ cat temp.c int a __attribute__((section(x))); $ gcc -m32 -c temp.c temp.c:1:5: error: section attribute not allowed for ‘a’ int a __attribute__((section(x))); ^ Happens both with gcc (GCC) 4.8.1 20130603 (Red Hat 4.8.1-1) and with current gcc trunk (rev 202134).
[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #13 from Eric Botcazou --- Created attachment 30734 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30734&action=edit Tentative fix
[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269 --- Comment #3 from Iain Sandoe --- bt #0 0x000100d7805a in internal_error (gmsgid=0x404 ) at /src/gcc-live-trunk/gcc/diagnostic.c:1120 #1 0x000100d78266 in fancy_abort (file=Could not find the frame base for "_Z11fancy_abortPKciS0_". ) at /src/gcc-live-trunk/gcc/diagnostic.c:1180 #2 0x0001007e3f70 in check_rtl (final_p=true) at /src/gcc-live-trunk/gcc/lra.c:2034 #3 0x0001007e49dd in lra (f=0x0) at /src/gcc-live-trunk/gcc/lra.c:2426 #4 0x00010078da96 in do_reload () at /src/gcc-live-trunk/gcc/ira.c:4689 #5 0x00010078dd4f in rest_of_handle_reload () at /src/gcc-live-trunk/gcc/ira.c:4818 #6 0x00010078dd9f in execute (this=0x141e17400) at /src/gcc-live-trunk/gcc/ira.c:4847 #7 0x00010089bbce in execute_one_pass (pass=0x141e17400) at /src/gcc-live-trunk/gcc/passes.c:2201 #8 0x00010089be07 in execute_pass_list (pass=0x141e17400) at /src/gcc-live-trunk/gcc/passes.c:2253 #9 0x00010089be38 in execute_pass_list (pass=0x141e16320) at /src/gcc-live-trunk/gcc/passes.c:2254 #10 0x0001004944d1 in expand_function (node=0x142c0bd10) at /src/gcc-live-trunk/gcc/cgraphunit.c:1690 #11 0x000100494d41 in output_in_order () at /src/gcc-live-trunk/gcc/cgraphunit.c:1884 #12 0x000100495562 in compile () at /src/gcc-live-trunk/gcc/cgraphunit.c:2127 #13 0x00010049570f in finalize_compilation_unit () at /src/gcc-live-trunk/gcc/cgraphunit.c:2209 #14 0x0001000268d5 in c_write_global_declarations () at /src/gcc-live-trunk/gcc/c/c-decl.c:10125 #15 0x0001009ab4ee in compile_file () at /src/gcc-live-trunk/gcc/toplev.c:560 #16 0x0001009adcfb in do_compile () at /src/gcc-live-trunk/gcc/toplev.c:1878 #17 0x0001009adead in toplev_main (argc=14, argv=0x7fff5fbffa00) at /src/gcc-live-trunk/gcc/toplev.c:1954 #18 0x000100d6106b in main (argc=14, argv=0x7fff5fbffa00) at /src/gcc-live-trunk/gcc/main.c:36
[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269
--- Comment #2 from Iain Sandoe ---
note this *breaks bootstrap* for the normal language set.
reduced testcase:
int foo (int a, ...)
{
void *args;
args = __builtin_apply_args ();
return 0;
}
/src/test/pr58269.c:7:1: internal compiler error: in check_rtl, at lra.c:2034
[Bug fortran/35339] Improve translation of implied do loop in transfer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35339 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #5 from Thomas Koenig --- Depending how much ground we want to cover, this can be tricky. Off my head, I can think of the following examples: (a(i), i=1,10) --> a(1:10) (a(i), i=1,10,2) --> a(1:10:2) (a(2*i), i=1,10) --> a(2:20:2) ((a(i,j), i=1,10), j=1,2) --> a(1:10,1:20) ((a(i,j), j=1,2), i=1,10) --> no equivalent ((a(i,j), j=1,2) --> a(i,1:2) (a(i,2*i), i=1,10) --> no equivalent (a(i**2), i=1,10) --> no equivalent
[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #23 from Bernd Edlinger ---
Martin, one of the errors with strict volatile bitfields
was with a structure like this.
struct S0 {
signed a : 7;
unsigned b : 28;
} __attribute__((packed));
here the member b is using SImode but the data are spread over 5 bytes.
This stucture access does not go thru the misalign code path.
But it it did, then I think we could get into trouble.
The code in the misalign code path assumes, that bitpos == 0.
Otherwise the condition if (bitsize != GET_MODE_BITSIZE (mode))
will not do the right thing.
And the misalign code path will break the
-fstrict-volatile-bitfields if the access is volatile.
What I mean is if we could find an example where this code path
is executed for a bit field it will break the strict volatile bitfileds
once again, even with Sandra Loosemore's patch.
Probably there is a reason why this can not happen but I do not see
it. At least there should be some assertions here.
[Bug c++/14932] [3.4/4.0 Regression] cannot use offsetof to get offsets of array elements in g++ 3.4.0 prerelease
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14932
--- Comment #15 from zhangjingwang at gmail dot com ---
(In reply to zhangjingwang from comment #14)
> #include
> #include
>
> struct TestStruct {
> int array[13];
> };
>
> struct TempStruct {
> int index;
> };
>
> int array_offset(struct TempStruct *index)
> {
> return offsetof(struct TestStruct, array[index->index]);
> }
>
> int main(int argc, char **argv)
> {
> struct TempStruct tmp = {3};
> printf("Offset of array[3] is %d.\n", array_offset(&tmp));
> }
>
> test.c: In function 'int array_offset(TempStruct*)':
> test.c:14: error: 'index' cannot appear in a constant-expression
> test.c:14: error: '->' cannot appear in a constant-expression
>
> This can't be compiled by the following versions of g++ (while it is
> accepted by gcc of the same version and clang++ 3.4):
> g++ (Debian 4.4.5-8) 4.4.5
> Copyright (C) 2010 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.
> :AND:
> g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3)
> Copyright (C) 2010 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.
>
> So I don't think this bug is fixed for those versions.
OK, I've tested the latest gcc 4.8.1 and the problem is fixed in the latest
version. g++ there will accept the code above without any problem.
[Bug c/58287] [4.9 regression] internal compiler error: in c_builtin_function_ext_scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58287 Jacek Caban changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jacek Caban --- Sorry, I didn't find that one. *** This bug has been marked as a duplicate of bug 57848 ***
[Bug target/57848] internal compiler error on builtin and '#pragma GCC target()' option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 Jacek Caban changed: What|Removed |Added CC||jacek at codeweavers dot com --- Comment #8 from Jacek Caban --- *** Bug 58287 has been marked as a duplicate of this bug. ***
[Bug c/58287] [4.9 regression] internal compiler error: in c_builtin_function_ext_scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58287 --- Comment #1 from Mikael Pettersson --- This is a duplicate of PR57848.
[Bug c++/58272] unnecessary vtables emission for pure abstract classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58272 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Jan Hubicka --- Current mainline seems to optimize Interace out completely. If this is correct, we probably ought to add it to testsuite?
[Bug c/58287] New: internal compiler error: in c_builtin_function_ext_scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58287
Bug ID: 58287
Summary: internal compiler error: in
c_builtin_function_ext_scope
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jacek at codeweavers dot com
This is with trunk version. I found it during mingw-w64-crt compilation, but my
simplified test case crashes x86_64-unknown-linux-gnu as well. The test case is
as trivial as:
extern unsigned int __builtin_ia32_crc32si (unsigned int, unsigned int);
#pragma GCC target("sse4.2")
and the backtrace is:
#pragma GCC target("sse4.2")
^
0x518de2 c_builtin_function_ext_scope(tree_node*)
../../gcc-git/gcc/c/c-decl.c:3633
0x81d720 add_builtin_function_common
../../gcc-git/gcc/langhooks.c:561
0x81e373 add_builtin_function_ext_scope(char const*, tree_node*, int,
built_in_class, char const*, tree_node*)
../../gcc-git/gcc/langhooks.c:597
0xb92b38 ix86_add_new_builtins
../../gcc-git/gcc/config/i386/i386.c:27368
0xb92b38 ix86_valid_target_attribute_tree(tree_node*)
../../gcc-git/gcc/config/i386/i386.c:4631
0x5d137c ix86_pragma_target_parse
../../gcc-git/gcc/config/i386/i386-c.c:393
0x5b73cd handle_pragma_target
../../gcc-git/gcc/c-family/c-pragma.c:805
0x55596f c_parser_pragma
../../gcc-git/gcc/c/c-parser.c:8972
0x5675ab c_parser_external_declaration
../../gcc-git/gcc/c/c-parser.c:1345
0x568066 c_parser_translation_unit
../../gcc-git/gcc/c/c-parser.c:1251
0x568066 c_parse_file()
../../gcc-git/gcc/c/c-parser.c:11223
0x5b4f14 c_common_parse_file()
../../gcc-git/gcc/c-family/c-opts.c:1046
[Bug target/58278] visibility bug from #26905 still happens with the sparc64 backend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58278 --- Comment #6 from Martin Husemann --- Ooops, my lack of x86 ABI knowledge strikes again. Indeed, visibility is properly expressed in the prologue, all is fine.
[Bug libstdc++/58265] [lwg/2063] std::string move assignment should be noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58265 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|SUSPENDED Summary|std::string move assignment |[lwg/2063] std::string move |should be noexcept |assignment should be ||noexcept --- Comment #4 from Paolo Carlini --- Thanks Daniel. I knew that we would have to revisit this anyway when the C++11 allocator model is implemented for the C++11 conforming basic_string. All in all, I guess better suspending this for the time being. Since, as-is, the move assignment of ext/vstring is in fact noexcept, we may want to declare it as such however. By the way, I seem to remember that Jon has work almost ready for the C++11 conformance of it.
[Bug libstdc++/58265] std::string move assignment should be noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58265 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #3 from Daniel Krügler --- Similar to containers the move-assignment operator of basic_string should not be noexcept, because they have a narrow contract. The fact that the specification currently requires this, is a defect. This is http://cplusplus.github.io/LWG/lwg-active.html#2063
[Bug target/58278] visibility bug from #26905 still happens with the sparc64 backend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58278 Eric Botcazou changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Eric Botcazou --- > Same thing happens, so this is not bug 26905 but a more generic issue and we > could simplify the test case? > > Or are you trying to argue whether we should see a PLT call at all? The latter, @PLT is a x86 specific quirk.
[Bug target/58278] visibility bug from #26905 still happens with the sparc64 backend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58278 --- Comment #4 from Martin Husemann --- (In reply to Eric Botcazou from comment #3) > So what? What happens if conftest.cc doesn't fiddle with visibility at all? Sorry, I am not quite sure I understand what you are up to. Same thing happens, so this is not bug 26905 but a more generic issue and we could simplify the test case? Or are you trying to argue whether we should see a PLT call at all? Martin
[Bug java/58284] Compiling jvgenmain failes with lots of "undefined reference" errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58284 --- Comment #1 from Winston Smith --- The same happens if the build dir is not a symlink.
