[Bug rtl-optimization/71636] Missed optimization in variable alignment test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71636
Marc Glisse changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #2 from Marc Glisse ---
For -march=core2, we get for g
movl$-1, %edx
movl%esi, %ecx
movl%edx, %eax
sall%cl, %eax
notl%eax
andl%edi, %eax
The use of %edx seems strange, llvm puts -1 directly in %eax. RA issue?
For the original issue, I guess doing the transformation very early with
something like the following might do
(simplify
(minus (lshift:s integer_each_onep@1 @0) @1)
(bit_not (lshift { build_all_ones_cst (type); } @0)))
(maybe with some extra code to handle conversions in the middle)
Or we could restrict the transformation to the case with bit_and, but I have
the vague impression that it would complicate things, especially if (1U<
[Bug middle-end/71625] missing strlen optimization on different array initialization style
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71625
--- Comment #10 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #6)
> > > char array[] = "abc";
> > > return __builtin_strlen (array);
>
> Well, this actually is optimized.
Oops, I failed my copy-paste, I meant to copy:
char array[] = {'a', 'b', 'c', '\0'};
> > Or we could do like clang and improve alias analysis. We should know that
> > array doesn't escape and thus that hallo() cannot write to it.
>
> The strlen pass uses the alias oracle, so the question is why it thinks the
> call might affect the array.
The alias machinery thinks that array escapes (and we are flow-insensitive
there). It is thus normal that hallo can write to it. I think array doesn't
escape, but it isn't obvious to me where the aliasing code decides that it
does.
(In reply to Jakub Jelinek from comment #7)
> int baz ()
> {
> char a[4];
> a[0] = 'a';
> a[1] = 'b';
> a[2] = 'c';
> a[3] = '\0';
> return __builtin_strlen (a);
> }
> still won't be optimized.
And we don't "vectorize" it either (llvm doesn't optimize strlen in this case,
but at least the write to a is a single movl $6513249, 4(%rsp) instead of 4
movb).
[Bug fortran/71649] Internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71649 --- Comment #5 from Dominique d'Humieres --- > Not darwin specific. Is the sample code valid? Good question! The ICE disappears if I rename the subroutine Compiler_Options or the ISO_FORTRAN_ENV one, e.g., opts => Compiler_Options. Anyway an ICE is not user friendly.
[Bug target/71338] [RL78] mulu instruction not used on G10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71338 --- Comment #5 from Oleg Endo --- (In reply to DJ Delorie from comment #4) > Sure, the only dependencies might be on binutils/gdb releases, but they > support it and they're independent of gcc releases anyway. As far as I know, binutils GAS does not check for mulu usage when compiling for G10 and happily accepts it in e.g. inline asm blocks. So I think it should be OK from that side. I'll backport r237566.
[Bug target/71657] New: Wrong code on trunk gcc (std::out_of_range), westmere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71657 Bug ID: 71657 Summary: Wrong code on trunk gcc (std::out_of_range), westmere Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: anton.mitrokhin at phystech dot edu Target Milestone: --- Created attachment 38767 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38767&action=edit Reproducer It looks like there is some king of overflow while computing array index (which is actually should be correct) This happens only on westmere, O3/Ofast Compile: > g++ -std=c++11 -static-libgcc -static-libstdc++ -O3 -march=westmere -o out > crash_init.cpp crash_main.cpp Run: > ./out Output: terminate called after throwing an instance of 'std::out_of_range' what(): vector::_M_range_check: __n (which is 20751846) >= this->size() (which is 38) Aborted (core dumped) > gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/export/users/amitrokh/gcc_trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /export/users/gnutester/stability/svn/trunk/configure --with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld --enable-cloog-backend=isl --with-fpmath=sse --with-pkgversion=Revision=237716/svn-rev:237719/ --prefix=/export/users/gnutester/stability/work/trunk/64/install --enable-languages=c,c++,fortran,java,lto Thread model: posix gcc version 7.0.0 20160622 (experimental) (Revision=237716/svn-rev:237719/)
[Bug target/71657] Wrong code on trunk gcc (std::out_of_range), westmere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71657 --- Comment #1 from Anton Mitrokhin --- Created attachment 38768 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38768&action=edit Reproducer - two files (crash_main.cpp and crash_init.cpp)
[Bug target/71657] Wrong code on trunk gcc (std::out_of_range), westmere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71657 --- Comment #2 from Anton Mitrokhin --- Comment on attachment 38768 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38768 Reproducer - two files (crash_main.cpp and crash_init.cpp) This attachment is a 7-zip archive
[Bug fortran/71649] Internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71649
--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #4)
> (In reply to jack.s...@nasa.gov from comment #2)
>
> > >
> > > Could someone check that the problem is not darwin specific?
> > >
>
> Not darwin specific. Is the sample code valid?
Of course the code is invalid. Op has
subroutine foo()
implicit none
i = foo()
end subroutine foo
1) Subroutines are not invoked as a function.
2) For a subroutine to invoke itself, it needs
the recursive attribute.
3) Subroutines have no type.
Your patch is almost correct (IMO). It should move
the check to the next conditional.
if (tmp_symtree)
{
if (tmp_symtree->n.sym
&& tmp_symtree->n.sym->module
&& strcmp (modname, tmp_symtree->n.sym->module) == 0)
return;
The error message shuold then be generated.
[Bug fortran/71649] Internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71649 --- Comment #7 from Jerry DeLisle --- I will regtest and commit the patch sometime today.
[Bug tree-optimization/71631] [7 Regression] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71631 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Sat Jun 25 17:20:15 2016 New Revision: 237782 URL: https://gcc.gnu.org/viewcvs?rev=237782&root=gcc&view=rev Log: PR tree-optimization/71631 * tree-ssa-reassoc.c (reassociate_bb): Pass true as last argument to rewrite_expr_tree even if negate_result, move new_lhs var declaration and initialization earlier, for powi_result set afterwards new_lhs to lhs. For negate_result, use new_lhs instead of tmp if new_lhs != lhs, and don't shadow gsi var. * gcc.c-torture/execute/pr71631.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr71631.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug tree-optimization/71643] [7 Regression] internal compiler error: in redirect_eh_edge_1, at tree-eh.c:2318 after r237427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71643 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Sat Jun 25 17:23:02 2016 New Revision: 237783 URL: https://gcc.gnu.org/viewcvs?rev=237783&root=gcc&view=rev Log: PR tree-optimization/71643 * tree-ssa-tail-merge.c (find_clusters_1): Ignore basic blocks with EH preds. * tree-ssa-tail-merge.c (deps_ok_for_redirect_from_bb_to_bb): Don't leak a bitmap if dep_bb is NULL. * g++.dg/opt/pr71643.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr71643.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-tail-merge.c
[Bug tree-optimization/71647] aligned(x:32) in #pragma omp simd does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71647 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed for 6.2. Thanks for the report.
[Bug tree-optimization/71631] [7 Regression] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71631 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/71643] [7 Regression] internal compiler error: in redirect_eh_edge_1, at tree-eh.c:2318 after r237427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71643 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug c++/71658] New: User-defined conversion operator from a wrapper class to the wrapped type does not compile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71658 Bug ID: 71658 Summary: User-defined conversion operator from a wrapper class to the wrapped type does not compile. Product: gcc Version: 4.8.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ulrichmutze at gmx dot de Target Milestone: --- Created attachment 38769 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38769&action=edit This single self-contained source file should compile according to what the standard sys about user-defined conversion operators. It doesn't. Please see the heading comment section of the attached self-contained source file main.cpp. I hope that it contains all info you are looking for. John Maddock from the boost project to whom I reported the problem in a form closer to the my actual application, and assuming that it would be caused by boost/multiprecision classes, found the problem 'perplexing' and came to the conclusion that it has probably not to do with multiprecision. So, I simplified the the problem to the lowest level which is presented here.
[Bug target/71659] New: _xgetbv intrinsic missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71659 Bug ID: 71659 Summary: _xgetbv intrinsic missing Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: andi-gcc at firstfloor dot org Target Milestone: --- icc and microsoft have a _xgetbv intrinsic for the XGETBV instruction, which is needed to check if AVX or MPX are supported by the kernel. gcc is missing an intrinsic for that, so everyone has to write inline assembler. Should add one.
[Bug libstdc++/71660] New: [4.9 regression] alignment of std::atomic<8 byte primitive type> (long long, double) is wrong on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71660
Bug ID: 71660
Summary: [4.9 regression] alignment of std::atomic<8 byte
primitive type> (long long, double) is wrong on x86
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
The resolution of Bug 65147 made this change to __atomic_base:
- __int_type _M_i;
+ static constexpr int _S_alignment =
+ sizeof(_ITp) > alignof(_ITp) ? sizeof(_ITp) : alignof(_ITp);
+
+ alignas(_S_alignment) __int_type _M_i;
That breaks the alignment for 8-byte primitive types on 32-bit x86, which have
a historical under-alignment to keep ABI compatibility with existing code.
That is:
alignof(long long) == 8
but:
struct InStruct { long long x; }
alignof(InStruct) == 4
The above is done so that existing structures containing those types retain
their layout.
Prior to Commit 221945, this struct had alignment of 4 on x86:
struct AtomicStruct { int; std::atomic x; };
After it, it's now 8.
More importantly, the sizeof that struct changed from 12 to 16 and the layout
also changed.
Please update this change to exclude:
long long
unsigned long long
double
long double
[Bug target/71659] _xgetbv intrinsic missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71659 --- Comment #1 from H.J. Lu --- You need more than an intrinsic to know if AVX or MPX is available. So far, run-time implementation has no issue with inline asm statement.
[Bug target/67400] -fno-plt doesn't work with function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67400 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|6.2 |7.0 --- Comment #6 from H.J. Lu --- (In reply to H.J. Lu from comment #1) > Another pointer bug: > > [hjl@gnu-6 pr18900]$ cat y.c > extern void foo (void); > > typedef void (*func_p) (void); > > const func_p p1 = &foo; > [hjl@gnu-6 pr18900]$ make y.o Since info of how p1 is initialized isn't available, there is not much we can do.
[Bug fortran/71649] Internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71649
--- Comment #8 from Jerry DeLisle ---
With:
if (tmp_symtree)
{
if (tmp_symtree->n.sym && tmp_symtree->n.sym->module
&& strcmp (modname, tmp_symtree->n.sym->module) == 0)
return;
gfc_error ("Symbol %qs at %C already declared", name);
return;
}
We now get:
$ gfc -c pr71649.f90
pr71649.f90:3:7:
USE ISO_FORTRAN_ENV, ONLY : Compiler_Version, Compiler_Options
1
Error: Symbol ‘compiler_options’ at (1) already declared
pr71649.f90:12:29:
Options = Compiler_Options()
1
Error: Unexpected use of subroutine name ‘compiler_options’ at (1)
Which now makes sense.
[Bug fortran/71649] Internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71649 --- Comment #9 from Jerry DeLisle --- Author: jvdelisle Date: Sun Jun 26 01:03:19 2016 New Revision: 237789 URL: https://gcc.gnu.org/viewcvs?rev=237789&root=gcc&view=rev Log: 2016-06-25 Jerry DeLisle PR fortran/71649 * module.c (create_intrinsic_function): Check for NULL values and return after giving error. PR fortran/71649 * gfortran.dg/pr71649.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr71649.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/71649] Internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71649 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Jerry DeLisle --- Fixed on trunk. Closing
[Bug tree-optimization/71661] New: wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71661
Bug ID: 71661
Summary: wrong code at -O3 on x86_64-linux-gnu (in both 32-bit
and 64-bit modes)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -O3
in both 32-bit and 64-bit modes.
This is a regression from 6.1.x.
It should be different from PR 71550, which seems to have become latent for the
latest trunk.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160625 (experimental) [trunk revision 237780] (GCC)
$
$ gcc-trunk -O2 small.c; ./a.out
$ gcc-6.1 -O3 small.c; ./a.out
$
$ gcc-trunk -O3 small.c
$ ./a.out
Segmentation fault (core dumped)
$
$ gcc-trunk -O3 pr71550.c; ./a.out
$ gcc-trunk -O0 pr71550.c; ./a.out
$
int a, b;
void
fn1 ()
{
unsigned c = 0;
int d;
b = a;
if (a < 0)
goto L1;
for (; a < 1; a++)
d = 0;
for (; d < 2; d++)
{
for (c = 0; c < 3; c++)
L1:
a = 2;
}
}
int
main ()
{
fn1 ();
return 0;
}
[Bug web/71356] Unable to reach trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71356 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- .
[Bug tree-optimization/71307] [7 Regression] Code quality regression with lane extraction arm_neon.h intrinsics on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71307 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-26 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug c++/71350] internal compiler error on trailing return type declaration with initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71350 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-26 Ever confirmed|0 |1 Known to fail||4.8.4, 7.0 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/71386] Wrong code on c++14 (GCC trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71386
--- Comment #2 from Andrew Pinski ---
With -Wall -W I get the following warnings from gcc:
t9.cc: In function ‘int main()’:
t9.cc:37:44: warning: ‘xs1#0’ is used uninitialized in this function
[-Wuninitialized]
auto print_func = [](int x){printf("%d ",x);return x;};
^
t9.cc:9:30: note: ‘xs1#0’ was declared here
return [=](auto processList){return processList(xs...);};
^
t9.cc:37:44: warning: ‘xs1#1’ is used uninitialized in this function
[-Wuninitialized]
auto print_func = [](int x){printf("%d ",x);return x;};
^
t9.cc:9:30: note: ‘xs1#1’ was declared here
return [=](auto processList){return processList(xs...);};
^
t9.cc:37:44: warning: ‘xs1#2’ is used uninitialized in this function
[-Wuninitialized]
auto print_func = [](int x){printf("%d ",x);return x;};
^
t9.cc:9:30: note: ‘xs1#2’ was declared here
return [=](auto processList){return processList(xs...);};
^
[Bug bootstrap/70473] genautomata memory footprint for arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70473 BillyBarty changed: What|Removed |Added CC||bill_bartol at yahoo dot com --- Comment #7 from BillyBarty --- I was having this same issue building gcc 5.2.0 on my Raspberry Pi 3. I successfully built it and then decided to duplicate everything I did before and re-run the build. That's when this issue started showing up. So what changed? Well, I forgot that I had (subsequent to the successful build) gone into raspi-config and change the Boot Options to boot to the desktop GUI and rebooted. So what I did was go back into raspi-config and put the Boot Options back to boot to text console, rebooted again, and confirmed that the Pi stopped its boot at the text console (it did). Then I ran the make and the process made it past the gcc build/genautomata step that it had previously conked out on. So I guess not having the desktop GUI running freed up enough memory to get me past said genautomata step. The make is still running; hopefully it will continue and complete successfully like it did before when I was booting to the text console.
[Bug c++/71662] New: ICE on invalid C++11 code with unqualified name look up: in tsubst_copy, at cp/pt.c:14010
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71662
Bug ID: 71662
Summary: ICE on invalid C++11 code with unqualified name look
up: in tsubst_copy, at cp/pt.c:14010
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The following C++11 code causes an ICE when compiled with the current GCC trunk
on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It also affects older versions at least as early as 4.6.x.
$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160625 (experimental) [trunk revision 237780] (GCC)
$
$ g++-trunk -c -std=c++11 small.cpp
small.cpp: In instantiation of ‘A::E A::h() [with T = int]’:
small.cpp:8:23: required from here
small.cpp:14:10: internal compiler error: in tsubst_copy, at cp/pt.c:14010
return e;
^
0x6dfcdc tsubst_copy
../../gcc-source-trunk/gcc/cp/pt.c:14010
0x6e2906 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-source-trunk/gcc/cp/pt.c:17243
0x6d68ff tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15868
0x6d6f75 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15176
0x6d7e30 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15351
0x6d4835 instantiate_decl(tree_node*, int, bool)
../../gcc-source-trunk/gcc/cp/pt.c:22095
0x721512 instantiate_pending_templates(int)
../../gcc-source-trunk/gcc/cp/pt.c:22214
0x764645 c_parse_final_cleanups()
../../gcc-source-trunk/gcc/cp/decl2.c:4600
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
--
template < typename T > struct A
{
enum E : T;
E h ();
};
A < int > a;
A < int >::E b = a.h ();
template < typename T > enum A < T >::E : T { e };
template < typename T > typename A < T >::E A < T >::h ()
{
return e;
}
[Bug target/71663] New: aarch64 Vector initialization can be improved slightly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71663
Bug ID: 71663
Summary: aarch64 Vector initialization can be improved slightly
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
Take:
#define vector __attribute__((vector_size(16)))
vector float combine (float a, float b, float c, float d)
{
return (vector float) { a, b, c, d };
}
--- CUT ---
Currently we produce:
moviv4.4s, 0
ins v4.s[0], v0.s[0]
ins v4.s[1], v1.s[0]
ins v4.s[2], v2.s[0]
orr v0.16b, v4.16b, v4.16b
ins v0.s[3], v3.s[0]
ret
The movi is not needed and if we did it correctly, the move (orr) is not needed
either. Even the first ins is not needed either.
Right now we expand the first element as:
(insn 9 8 10 (set (reg:SF 80)
(reg/v:SF 74 [ a ])) t8.c:5 -1
(nil))
(insn 10 9 11 (set (reg:V4SF 79)
(vec_merge:V4SF (vec_duplicate:V4SF (reg:SF 80))
(reg:V4SF 79)
(const_int 1 [0x1]))) t8.c:5 -1
(nil))
But maybe if we do:
(set (reg:V4SF 79) (subreg:V4SF (reg:SF 74)))
We could remove the movi and ins. The last move would remove itself too
because v0 is dead after the instruction.
[Bug c++/71459] ICE writing to a string-initialized local array in a constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71459 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-26 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/71487] sorry, unimplemented: mangling offset_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71487 Andrew Pinski changed: What|Removed |Added Keywords||ABI Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-26 Ever confirmed|0 |1 Known to fail||7.0 --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug c++/71664] New: valid C++11 code with qualified enumerator lookup rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71664
Bug ID: 71664
Summary: valid C++11 code with qualified enumerator lookup
rejected
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The following C++11 code is rejected when compiled with the current GCC trunk
on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It also affects older versions at least as early as 4.6.x.
This is related to and derived from PR 71662.
$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160625 (experimental) [trunk revision 237780] (GCC)
$
$ clang++-3.8 -c -std=c++11 small.cpp
$
$ g++-trunk -c -std=c++11 small.cpp
small.cpp: In instantiation of ‘A::E A::h() [with T = int]’:
small.cpp:8:23: required from here
small.cpp:14:22: error: ‘e’ is not a member of ‘A::E’
return A < T >::E::e;
^
$
--
template < typename T > struct A
{
enum E : T;
E h ();
};
A < int > a;
A < int >::E b = a.h ();
template < typename T > enum A < T >::E : T { e };
template < typename T > typename A < T >::E A < T >::h ()
{
return A < T >::E::e;
}
[Bug c++/71553] [6 regression]ICE in assign_temp, at function.c:961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71553 --- Comment #2 from Andrew Pinski --- Works on the trunk on aarch64-linux-gnu.
[Bug rtl-optimization/71636] Missed optimization in variable alignment test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71636 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-26 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/71661] [7 Regression] wrong code at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71661 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-26 Target Milestone|--- |7.0 Summary|wrong code at -O3 on|[7 Regression] wrong code |x86_64-linux-gnu (in both |at -O3 |32-bit and 64-bit modes)| Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed, complete unrolling puts an __builtin_unreachable in the IR.
[Bug driver/69540] add a short info on .so priority in -l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69540 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-26 Component|c |driver Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #2 from Andrew Pinski --- Really this documentation should just point to ld's documentation on your system since -l is passed directly without any change. As it is also incorrect for windows systems. Confirmed.
[Bug middle-end/71587] missed inlining extern template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71587 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-26 Component|c++ |middle-end Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/69045] missing optimization: forward constant propagation of regular expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69045 Andrew Pinski changed: What|Removed |Added Component|middle-end |c++ Version|unknown |7.0 --- Comment #1 from Andrew Pinski --- Do you have an example code?
[Bug web/69601] current/ redirect is off by at least a day
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69601 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-26 Assignee|unassigned at gcc dot gnu.org |overseers at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug c++/69593] static thread_local in a structure within a function template causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69593 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #2 from Andrew Pinski --- Fixed so closing.
[Bug c++/71665] New: ICE on invalid C++ code with non-integral constant enumerator value:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71665 Bug ID: 71665 Summary: ICE on invalid C++ code with non-integral constant enumerator value: Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu Target Milestone: ---
[Bug c++/71665] ICE on invalid C++ code with non-integral constant enumerator value: in cxx_eval_constant_expression, at cp/constexpr.c:3918
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71665
Zhendong Su changed:
What|Removed |Added
Summary|ICE on invalid C++ code |ICE on invalid C++ code
|with non-integral constant |with non-integral constant
|enumerator value: |enumerator value: in
||cxx_eval_constant_expressio
||n, at cp/constexpr.c:3918
--- Comment #1 from Zhendong Su ---
The following C++ code causes an ICE when compiled with the current GCC trunk
on x86_64-linux-gnu in both 32-bit and 64-bit modes.
This is a regression from 6.1.x.
$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160625 (experimental) [trunk revision 237780] (GCC)
$
$ g++-6.1 -c small.cpp
small.cpp:4:14: error: enumerator value for ‘a’ is not an integer constant
enum { a = f };
^
$
$ g++-trunk -c small.cpp
small.cpp:4:14: internal compiler error: in cxx_eval_constant_expression, at
cp/constexpr.c:3918
enum { a = f };
^
0x8acaed cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3918
0x8b1929 cxx_eval_outermost_constant_expr
../../gcc-source-trunk/gcc/cp/constexpr.c:4211
0x6a22c7 build_enumerator(tree_node*, tree_node*, tree_node*, tree_node*,
unsigned int)
../../gcc-source-trunk/gcc/cp/decl.c:13588
0x7a98e2 cp_parser_enumerator_definition
../../gcc-source-trunk/gcc/cp/parser.c:17431
0x7a98e2 cp_parser_enumerator_list
../../gcc-source-trunk/gcc/cp/parser.c:17360
0x7a98e2 cp_parser_enum_specifier
../../gcc-source-trunk/gcc/cp/parser.c:17287
0x78aea9 cp_parser_type_specifier
../../gcc-source-trunk/gcc/cp/parser.c:15813
0x79fc23 cp_parser_decl_specifier_seq
../../gcc-source-trunk/gcc/cp/parser.c:12763
0x7af2ed cp_parser_member_declaration
../../gcc-source-trunk/gcc/cp/parser.c:22334
0x78b118 cp_parser_member_specification_opt
../../gcc-source-trunk/gcc/cp/parser.c:22186
0x78b118 cp_parser_class_specifier_1
../../gcc-source-trunk/gcc/cp/parser.c:21365
0x78b118 cp_parser_class_specifier
../../gcc-source-trunk/gcc/cp/parser.c:21601
0x78b118 cp_parser_type_specifier
../../gcc-source-trunk/gcc/cp/parser.c:15841
0x79fc23 cp_parser_decl_specifier_seq
../../gcc-source-trunk/gcc/cp/parser.c:12763
0x7ad111 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12304
0x7ad561 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12251
0x7b6940 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12148
0x7b5414 cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12027
0x7b5748 cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4329
0x7b5748 c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:37491
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
class A
{
int f ();
enum { a = f };
};
