[Bug c/64423] Incorrect column number of -Wchar-subscripts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64423 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-28 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- That is because warn_array_subscript_with_type_char does not take a location and does not use warningat but rather just warning. Confirmed.
[Bug c/64423] New: Incorrect column number of -Wchar-subscripts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64423
Bug ID: 64423
Summary: Incorrect column number of -Wchar-subscripts
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
The column number of -Wchar-subscripts is not precise. It always starts at the
beginning of the statement.
$: cat t.c
int a[100];
int f(char c) {
return a[c] + a[c] + a[c];
}
$:
$: gcc-trunk -Wchar-subscripts -c t.c
t.c: In function ‘f’:
t.c:4:3: warning: array subscript has type ‘char’ [-Wchar-subscripts]
return a[c] + a[c] + a[c];
^
t.c:4:3: warning: array subscript has type ‘char’ [-Wchar-subscripts]
t.c:4:3: warning: array subscript has type ‘char’ [-Wchar-subscripts]
$:
$: clang-trunk -Wchar-subscripts -c t.c
t.c:4:11: warning: array subscript is of type 'char' [-Wchar-subscripts]
return a[c] + a[c] + a[c];
^~
t.c:4:18: warning: array subscript is of type 'char' [-Wchar-subscripts]
return a[c] + a[c] + a[c];
^~
t.c:4:25: warning: array subscript is of type 'char' [-Wchar-subscripts]
return a[c] + a[c] + a[c];
^~
3 warnings generated.
[Bug c++/64422] basic_string::erase is unresloved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64422 --- Comment #1 from Bernd Edlinger --- with -std=gnu++03 we get call _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE5eraseEN9__gnu_cxx17__normal_iteratorIPKcS4_EES9_ aka std::__cxx11::basic_string, std::allocator >::erase(__gnu_cxx::__normal_iterator, std::allocator > >, __gnu_cxx::__normal_iterator, std::allocator > >) which is not in -lstdc++ but with -std=gnu++11 we get call _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE5eraseEN9__gnu_cxx17__normal_iteratorIPcS4_EES8_ aka std::__cxx11::basic_string, std::allocator >::erase(__gnu_cxx::__normal_iterator, std::allocator > >, __gnu_cxx::__normal_iterator, std::allocator > >) which is found in -lstdc++ so the difference is in the constness of the iterator parameters.
[Bug c++/64422] New: basic_string::erase is unresloved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64422
Bug ID: 64422
Summary: basic_string::erase is unresloved
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
starting with around r218964, "New std::string implementation."
the following program does no longer link correctly:
cat test1.cc
#include
int
main()
{
std::string x;
x.erase(x.begin(), x.end());
}
g++ test1.cc
/tmp/ccgup1FU.o: In function `main':
test1.cc:(.text+0x41): undefined reference to `std::__cxx11::basic_string,
std::allocator>::erase(__gnu_cxx::__normal_iterator,
std::allocator>>, __gnu_cxx::__normal_iterator,
std::allocator>>)'
collect2: error: ld returned 1 exit status
This does however not happen at -O1 and above.
Or if -std=gnu++11 is used.
[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-28 Ever confirmed|0 |1 --- Comment #4 from David Edelsohn --- Confirmed.
[Bug c++/64418] User-defined conversion not properly suppressed in certain cases of list-initialisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64418 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Jason Merrill --- G++ implements the resolution of issue 1467: http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#1467 So initialization of a does not use 13.3.1.7.
[Bug fortran/60414] internal compiler error: tree check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60414 --- Comment #5 from janus at gcc dot gnu.org --- It seems the ICE is fixed on trunk. Can we close this PR?
[Bug fortran/59103] [OOP] Reject deallocate/intent(out) for polymorphic var in PURE procedures (IR F08/0033)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59103 --- Comment #5 from janus at gcc dot gnu.org --- (In reply to janus from comment #4) > (In reply to Dominique d'Humieres from comment #2) > > Isn't this PR related to the patch at > > https://gcc.gnu.org/ml/fortran/2014-12/msg00098.html? > > Yes, but the patch does not cover all cases mentioned in comment 0. This patch has been committed as r219085.
[Bug fortran/54756] [OOP] [F08] Should reject CLASS, intent(out) in PURE procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54756 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from janus at gcc dot gnu.org --- Fixed with r219085. Closing.
[Bug fortran/54756] [OOP] [F08] Should reject CLASS, intent(out) in PURE procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54756 --- Comment #8 from janus at gcc dot gnu.org --- Author: janus Date: Sat Dec 27 22:40:21 2014 New Revision: 219085 URL: https://gcc.gnu.org/viewcvs?rev=219085&root=gcc&view=rev Log: 2014-12-27 Janus Weil PR fortran/54756 * resolve.c (resolve_formal_arglist): Reject polymorphic INTENT(OUT) arguments of pure procedures. 2014-12-27 Janus Weil PR fortran/54756 * gfortran.dg/class_array_3.f03: Fixed invalid test case. * gfortran.dg/class_array_7.f03: Ditto. * gfortran.dg/class_dummy_4.f03: Ditto. * gfortran.dg/defined_assignment_3.f90: Ditto. * gfortran.dg/defined_assignment_5.f90: Ditto. * gfortran.dg/elemental_subroutine_10.f90: Ditto. * gfortran.dg/typebound_operator_4.f03: Ditto. * gfortran.dg/typebound_proc_16.f03: Ditto. * gfortran.dg/unlimited_polymorphic_19.f90: Ditto. * gfortran.dg/class_dummy_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/class_dummy_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/class_array_3.f03 trunk/gcc/testsuite/gfortran.dg/class_array_7.f03 trunk/gcc/testsuite/gfortran.dg/class_dummy_4.f03 trunk/gcc/testsuite/gfortran.dg/defined_assignment_3.f90 trunk/gcc/testsuite/gfortran.dg/defined_assignment_5.f90 trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_10.f90 trunk/gcc/testsuite/gfortran.dg/typebound_operator_4.f03 trunk/gcc/testsuite/gfortran.dg/typebound_proc_16.f03 trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_19.f90
[Bug tree-optimization/64421] New: Incorrect vector function name generated for log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64421
Bug ID: 64421
Summary: Incorrect vector function name generated for log
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: andrew.n.senkevich at gmail dot com
Created attachment 34340
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34340&action=edit
reduced test
Hi,
compilation failed with the following code in log.c:
#include
#pragma omp declare simd notinbranch simdlen(2)
extern double log (double);
int N = 3200;
double b[3200];
double a[3200];
int main (void)
{
int i;
#pragma omp simd
for (i = 0; i < N; i += 1)
{
b[i] = log (a[i]);
}
return (0);
}
gcc log.c -fopenmp -ffast-math -O1
/tmp/ccjc6yPN.s: Assembler messages:
/tmp/ccjc6yPN.s:37: Error: invalid operands (*UND* and *UND* sections) for `*'
gcc log.c -fopenmp -ffast-math -O1 -S
cat log.s
. . . . .
call_ZGVbN2v_*__log_finite
. . . . .
It seems because of wrong asm keyword handling, reduced test is:
#pragma omp declare simd notinbranch simdlen(2)
extern double log (double) __asm__ ("" "__log_finite") __attribute__
((__nothrow__ , __leaf__));
int N = 3200;
double b[3200];
double a[3200];
int main (void)
{
int i;
#pragma omp simd
for (i = 0; i < N; i += 1)
{
b[i] = log (a[i]);
}
return (0);
}
gcc -v
. . . . .
Target: x86_64-unknown-linux-gnu
. . . . .
gcc version 5.0.0 20141226 (experimental) (GCC)
[Bug bootstrap/64419] ./configure --prefix /root/bin/gcc-4.9.2 --with-mpc=/root/mpc/ --disable-multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64419 --- Comment #3 from Jason Pyeron --- Sorry, I just assumed that I did not need to mention that I had set LD_LIBRARY_PATH (at least so says history). Thanks. Off to other problems now.
[Bug c++/64385] odd behaviour of std::is_move_constructible< std::ostringstream >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64385
--- Comment #2 from Jonathan Wakely ---
As a workaround you can simply instantiate the trait before it is used in the
function template.
Here's a reduced version of the test, which breaks when A is defined, but is
fixed by defining B:
#include
#include
using trait = std::is_constructible;
#if B
const bool dummy = trait::value;
#endif
#if A
template struct X { };
struct moveable_class
{
template
moveable_class(Source&& src, X* = 0)
{ }
};
#endif
static_assert( !trait::value, "");
[Bug c++/64385] odd behaviour of std::is_move_constructible< std::ostringstream >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64385 --- Comment #1 from Jonathan Wakely --- The problem is due to one of the bugs that PR 59002 depends on. Prior to GCC 5 the stream classes have private copy constructors to make them non-copyable. Normally (as you see when A is not defined) this means is_move_constructible reports false, but when A is defined the first instantiation of is_move_constructible happens in a function template, and G++ has a number of bugs in templates that mean access checking doesn't work. This means the first instantiation occurs in a context where the private copy constructor is (incorrectly) accessible, so it reports true. When you use is_move_constructible again in main() it uses the existing instantiation which gives the wrong result again. The correct fix is to fix all the bugs linked to from PR 59002, but that's not going to happen for GCC 4.9. An alternative would be to replace the private constructors with deleted ones, so that the stream classes are not copyable even in contexts where access checking doesn't work. I'm not sure that is worth fixing now, given that the streams really are movable in GCC 5 anyway.
[Bug ipa/64420] New: LTO can miscompile IFUNCs designated via top-level asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64420 Bug ID: 64420 Summary: LTO can miscompile IFUNCs designated via top-level asm Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: amonakov at gcc dot gnu.org Minimal testcase: $ cat >test.c <
[Bug c++/64418] User-defined conversion not properly suppressed in certain cases of list-initialisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64418 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-27 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Confirmed. As noted in PR 51553 the current behaviour is wrong. Clang and EDG reject the testcase in this PR.
[Bug bootstrap/64419] ./configure --prefix /root/bin/gcc-4.9.2 --with-mpc=/root/mpc/ --disable-multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64419 --- Comment #2 from Jonathan Wakely --- This is a FAQ: https://gcc.gnu.org/wiki/FAQ#configure_suffix Most search engines should be able to direct you straight to that page if you search for the error. Also, don't use ./configure as explained at https://gcc.gnu.org/wiki/FAQ#configure See https://gcc.gnu.org/wiki/InstallingGCC Basically, read the docs.
[Bug bootstrap/64419] ./configure --prefix /root/bin/gcc-4.9.2 --with-mpc=/root/mpc/ --disable-multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64419 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- You need to set LD_LIBRARY_PATH.
[Bug bootstrap/64419] New: ./configure --prefix /root/bin/gcc-4.9.2 --with-mpc=/root/mpc/ --disable-multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64419
Bug ID: 64419
Summary: ./configure --prefix /root/bin/gcc-4.9.2
--with-mpc=/root/mpc/ --disable-multilib
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: jpyeron at pdinc dot us
--with-mpc does not compile, installing mpc in standard location does.
RHEL 6 64 bit, latest patches. build as root.
sorry for the bug and run, but I purged all the files from the system already.
## --- ##
## Core tests. ##
## --- ##
...skipping...
configure:3392: $? = 1
configure:3580: checking for suffix of object files
configure:3602: /root/gcc-4.9.2/host-x86_64-unknown-linux-gnu/gcc/xgcc
-B/root/gcc-4.9.2/host-x86_64-unknown-linux-gnu/gcc/
-B/root/bin/gcc-4.9.2/x86_64-unknown-linux-gnu/bin/
-B/root/bin/gcc-4.9.2/x86_64-unknown-linux-gnu/lib/ -isystem
/root/bin/gcc-4.9.2/x86_64-unknown-linux-gnu/include -isystem
/root/bin/gcc-4.9.2/x86_64-unknown-linux-gnu/sys-in
clude-c -g -O2 conftest.c >&5
/root/gcc-4.9.2/host-x86_64-unknown-linux-gnu/gcc/cc1: error while loading
shared libraries: libmpc.so.2: cannot open shared object file: No such file or
directory
configure:3606: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3620: error: in `/root/gcc-4.9.2/x86_64-unknown-linux-gnu/libgcc':
configure:3623: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
[Bug c++/64414] cc1plus: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64414 --- Comment #3 from Jason Pyeron --- I am building gcc 4.9.2 presently, I will test afterwards. Distro bug: https://bugzilla.redhat.com/show_bug.cgi?id=1177458 in case of patch.
[Bug target/64409] ICE building Mesa 10.4.0 for x32 ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64409 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.8.5, 4.9.3, 5.0 Resolution|--- |FIXED --- Comment #9 from H.J. Lu --- Fixed for 4.8.5.
[Bug target/64409] ICE building Mesa 10.4.0 for x32 ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64409 --- Comment #8 from hjl at gcc dot gnu.org --- Author: hjl Date: Sat Dec 27 16:35:41 2014 New Revision: 219083 URL: https://gcc.gnu.org/viewcvs?rev=219083&root=gcc&view=rev Log: Issue an error for ms_abi attribute with x32 There is no counter part of x32 in MS ABI. Issue an error when ms_abi attribute is used with x32. gcc/ PR target/64409 * config/i386/i386.c (ix86_function_type_abi): Issue an error when ms_abi attribute is used with x32. gcc/testsuite/ PR target/64409 * gcc.target/i386/pr64409.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr64409.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/i386.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug target/64409] ICE building Mesa 10.4.0 for x32 ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64409 --- Comment #7 from hjl at gcc dot gnu.org --- Author: hjl Date: Sat Dec 27 16:26:55 2014 New Revision: 219082 URL: https://gcc.gnu.org/viewcvs?rev=219082&root=gcc&view=rev Log: Issue an error for ms_abi attribute with x32 There is no counter part of x32 in MS ABI. Issue an error when ms_abi attribute is used with x32. gcc/ PR target/64409 * config/i386/i386.c (ix86_function_type_abi): Issue an error when ms_abi attribute is used with x32. gcc/testsuite/ PR target/64409 * gcc.target/i386/pr64409.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr64409.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/i386/i386.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug target/64409] ICE building Mesa 10.4.0 for x32 ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64409 --- Comment #6 from hjl at gcc dot gnu.org --- Author: hjl Date: Sat Dec 27 16:14:59 2014 New Revision: 219081 URL: https://gcc.gnu.org/viewcvs?rev=219081&root=gcc&view=rev Log: Issue an error for ms_abi attribute with x32 There is no counter part of x32 in MS ABI. Issue an error when ms_abi attribute is used with x32. gcc/ PR target/64409 * config/i386/i386.c (ix86_function_type_abi): Issue an error when ms_abi attribute is used with x32. gcc/testsuite/ PR target/64409 * gcc.target/i386/pr64409.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr64409.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug c++/64418] New: User-defined conversion not properly suppressed in certain cases of list-initialisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64418
Bug ID: 64418
Summary: User-defined conversion not properly suppressed in
certain cases of list-initialisation
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: momchil.velikov at gmail dot com
Consider the example:
--- 8< --
struct C {
C(const C &);
};
struct X {
operator C() const;
};
C a{X()};
--- 8< --
This program is successfully compiled. However, I believe this is an
erroneous behavior.
The variable "a" is initialised by direct list-initialization
according to 8.5.4. [dcl.init.list] #3 and 13.3.1.7 [over.match.list].
As the class C does not have an initializer-list ctor, all the
constructors of C are tried with the elements of the initializer list
as arguments.
GCC tries and in fact finds a user-defined conversion sequence from X
to the first parameter of the C's copy-ctor.
However, according to 13.3.3.1 [over.best.ics] #4,
"[...] when considering the argument of a constructor [...] that is a
candidate by [...] by 13.3.1.7 [...] or when the initializer list has
exactly one element and a conversion to some class X or reference to
(possibly cv-qualified) X is considered for the first parameter of a
constructor of X [...] only standard conversion sequences and ellipsis
conversion sequences are considered.
Bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51553 is related to this one.
[Bug c++/64414] cc1plus: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64414 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-12-27 Ever confirmed|0 |1 --- Comment #2 from H.J. Lu --- GCC 4.4 is no longer supported. Please try GCC 4.9.
[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412 --- Comment #3 from H.J. Lu --- (In reply to iverbin from comment #2) > (In reply to H.J. Lu from comment #1) > > (In reply to iverbin from comment #0) > > > To reproduce using Intel Xeon Phi emulation: > > > 1. Build offload and host compilers as described in > > > https://gcc.gnu.org/wiki/Offloading#How_to_try_offloading_enabled_GCC > > > 2. Run make check-target-libgomp RUNTESTFLAGS="c.exp=e.53.5.c" > > > > Can you create a stanalone testcase for the Intel Xeon Phi offload > > cross compiler? It will be easier to debug. > > The offload model in GCC implies 2 compilers: one produces IR for OpenMP > target regions, and another compiles this IR for Intel Xeon Phi. > There is no single compiler, which could stream offload IR out, then stream > it in, and then compile. > I can reduce e.53.5.c testcase, not sure whether this is helpful. Can you use "gcc -v -save-temps" to see what is passed to the offload compiler and feed them to the offload compiler directly?
[Bug target/54429] [SH] SImode values get ferried through FPUL and FP regs for -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54429 --- Comment #8 from Oleg Endo --- BTW, the problem is also there when using LRA.
[Bug c/64417] [SH] FAIL: gcc.c-torture/compile/pr28865.c -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64417 Andreas Schwab changed: What|Removed |Added Component|target |c --- Comment #1 from Andreas Schwab --- That should be rejected, since array element types may not be incomplete.
[Bug target/54429] [SH] SImode values get ferried through FPUL and FP regs for -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54429
--- Comment #7 from Oleg Endo ---
Another minimal test case:
int var;
int test (void)
{
return var;
}
mov.l r14,@-r15
mov r15,r14
mov.l .L3,r1
mov.l @r1,r1
lds r1,fpul
fstsfpul,fr1
fldsfr1,fpul
sts fpul,r0
mov r14,r15
mov.l @r15+,r14
rts
nop
.L4:
.align 2
.L3:
.long _var
[Bug target/64417] New: [SH] FAIL: gcc.c-torture/compile/pr28865.c -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64417
Bug ID: 64417
Summary: [SH] FAIL: gcc.c-torture/compile/pr28865.c -O0
(test for excess errors)
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
On SH, the test case
struct var_len
{
int field1;
const char field2[];
};
static const struct var_len var_array[] =
{
{ 1, "Long exposure noise reduction" },
{ 2, "Shutter/AE lock buttons" },
{ 3, "Mirror lockup" }
};
without optimization compiles to:
.little
.section.rodata
.align 2
.type_var_array, @object
.size_var_array, 12
_var_array:
.long1
.string"Long exposure noise reduction"
.long2
.string"Shutter/AE lock buttons"
.long3
.string"Mirror lockup"
.ident"GCC: (GNU) 5.0.0 20141226 (experimental)"
The structs in the array are misaligned. Either the struct size has to be
aligned to 4 bytes (adding '\0' chars to the strings or inserting .align 2) or
the 32 bit values have to be output as byte arrays.
