[Bug tree-optimization/67659] [5 regression] ICE: segfault: Linux kernel/rcu/tree.c:3261:6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67659
--- Comment #3 from Markus Trippelsdorf ---
tree.i:13:6: internal compiler error: Segmentation fault
void fn1(unsigned long p1) {
^
0x99d1ef crash_signal
../../gcc/gcc/toplev.c:383
0xa5cc22 fold_builtin_alloca_with_align
../../gcc/gcc/tree-ssa-ccp.c:2067
0xa5cc22 ccp_fold_stmt
../../gcc/gcc/tree-ssa-ccp.c:2172
0xac6866 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
../../gcc/gcc/tree-ssa-propagate.c:1177
0xea6077 dom_walker::walk(basic_block_def*)
../../gcc/gcc/domwalk.c:188
0xac62a9 substitute_and_fold(tree_node* (*)(tree_node*), bool
(*)(gimple_stmt_iterator*), bool)
../../gcc/gcc/tree-ssa-propagate.c:1272
0xa54108 ccp_finalize
../../gcc/gcc/tree-ssa-ccp.c:941
0xa54108 do_ssa_ccp
../../gcc/gcc/tree-ssa-ccp.c:2382
0xa54108 execute
../../gcc/gcc/tree-ssa-ccp.c:2414
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
I think there is a dup somewhere, but I cannot find it at the moment.
[Bug middle-end/67714] [6 Regression] signed char is zero-extended instead of sign-extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67714 --- Comment #3 from ktkachov at gcc dot gnu.org --- (In reply to kugan from comment #2) > It is the same issue and the patch posted in > https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00403.html fixes this > test-case too. Thanks for checking! I suppose you can reference this PR in that patches ChangeLog when it goes in
[Bug target/67701] Unnecessary/bad instructions for u32-casted access to external symbol (assumes misaligned, superfluous load)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67701
--- Comment #8 from rguenther at suse dot de ---
On Thu, 24 Sep 2015, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67701
>
> --- Comment #7 from Eric Botcazou ---
> > Yes, AFAIK this was some obscure situation with SSE on x86. IIRC
> > code doing unaligned scalar accesses (which is ok on x86) but then
> > vectorized using peeling for alignment (which cannot succeed if the
> > element is not naturally aligned) and segfaulting for the emitted
> > aligned move instructions.
>
> I see, thanks for the insight.
>
> > Maybe these days the legacy has been cleaned up enough so we can
> > remove that conservative handling again... I think it also causes
> > us to handle
> >
> > char c[4];
> >
> > int main()
> > {
> > if (!((unsigned long)c & 3))
> > return *(int *)c;
> > return c[0];
> > }
> >
> > too conservatively as we expand
> >
> > _5 = MEM[(int *)&c];
> >
> > and thus lost the flow-sensitive info.
>
> The problem is that, in order to fix a legitimate issue on x86, the change
> pessimizes the code for strict-alignment platforms, where the said issue
> doesn't exist since there are unaligned accesses in the source code. And of
> course only for them, since x86 has unaligned load/stores. So, in the end,
> this is a net loss for strict-alignment platforms.
Agreed. Looking at how to fix this in get_object_alignment_2 I wonder
if it makes sense to unify this function with get_inner_reference. The
other choice would be to add a flag to get_inner_reference to stop
at MEM_REF/TARGET_MEM_REFs.
[Bug c/48885] missed optimization with restrict qualifier?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48885
vries at gcc dot gnu.org changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #18 from vries at gcc dot gnu.org ---
Let's rewrite the example from comment 14 to plain C (as we did in PR67705):
void
f (int *__restrict__ *__restrict__ fpp, int *fp2)
{
int *fp = *fpp;
*fp = 1;
*fp2 = 2;
}
void
g (int *__restrict__ gp)
{
f (&gp, gp);
}
void
h (void)
{
int ha;
g (&ha);
}
My interpretation of the restricts in the example (given what I've learned in
PR67705):
Restrict declaration D: "int *__restrict__ gp"
Type T: int
Object P: gp
Block B: g function block
Lvalues: *fp and *fp2
Objects designated by lvalues: ha in both cases.
Object ha modified during execution of B: yes
Object gp considered modified during execution of B: yes
&Lvalues: pointer expressions fp and fp2
&Lvalues based on object P: yes
Conclusion: Valid example. Since both lvalues have their address based on
the same restrict pointer, there are no disambiguation
consequences.
Restrict declaration D: "int *__restrict__ *__restrict__ fpp"
Type T: int *__restrict__
Object P: fpp
Block B: f function block
Lvalues: *fpp
Objects designated by lvalues: gp
Object gp modified during execution of B: considered modified, yes
Object fpp considered modified during execution of B: yes
&Lvalues: pointer expression fpp
&Lvalues based on object P: yes
Conclusion: Valid example. Since there's only one lvalue accessing gp there
are no disambiguation consequences.
Joseph, can you confirm that:
- this is a valid example, and
- there are no disambiguation consequences.
If that is indeed the case, then the committed patch is invalid.
[Bug c/48885] missed optimization with restrict qualifier?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48885
--- Comment #19 from rguenther at suse dot de ---
On Fri, 25 Sep 2015, vries at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48885
>
> vries at gcc dot gnu.org changed:
>
>What|Removed |Added
>
> CC||jsm28 at gcc dot gnu.org
>
> --- Comment #18 from vries at gcc dot gnu.org ---
> Let's rewrite the example from comment 14 to plain C (as we did in PR67705):
>
> void
> f (int *__restrict__ *__restrict__ fpp, int *fp2)
> {
> int *fp = *fpp;
> *fp = 1;
> *fp2 = 2;
> }
>
> void
> g (int *__restrict__ gp)
> {
> f (&gp, gp);
> }
>
> void
> h (void)
> {
> int ha;
> g (&ha);
> }
>
> My interpretation of the restricts in the example (given what I've learned in
> PR67705):
>
> Restrict declaration D: "int *__restrict__ gp"
> Type T: int
> Object P: gp
> Block B: g function block
> Lvalues: *fp and *fp2
> Objects designated by lvalues: ha in both cases.
> Object ha modified during execution of B: yes
> Object gp considered modified during execution of B: yes
> &Lvalues: pointer expressions fp and fp2
> &Lvalues based on object P: yes
> Conclusion: Valid example. Since both lvalues have their address based on
> the same restrict pointer, there are no disambiguation
> consequences.
>
> Restrict declaration D: "int *__restrict__ *__restrict__ fpp"
> Type T: int *__restrict__
> Object P: fpp
> Block B: f function block
> Lvalues: *fpp
> Objects designated by lvalues: gp
> Object gp modified during execution of B: considered modified, yes
> Object fpp considered modified during execution of B: yes
> &Lvalues: pointer expression fpp
> &Lvalues based on object P: yes
> Conclusion: Valid example. Since there's only one lvalue accessing gp there
> are no disambiguation consequences.
>
> Joseph, can you confirm that:
> - this is a valid example, and
> - there are no disambiguation consequences.
>
> If that is indeed the case, then the committed patch is invalid.
I don't see how one needs to consider fp2 based on fp (*fpp). If
we need to consider that then what's the difference to
int foo (int * __restrict__ p, int *q)
{
*p = 1;
*q = 2;
return *p;
}
int main ()
{
int i;
if (foo (&i, &i) != 2)
abort ();
}
here q is based on p if you take into account the caller.
But IIRC what matters here is that the BLOCK with the restrict
declaration of 'p' starts at the beginning of foo and does not
include the initialization at the call site. Thus any
"based-on" properties that are formed before the execution of
BLOCK begins are irrelevant to the standards wording.
Thus it's like
int main()
{
int i;
int *pcaller = &i;
int *qcaller = &i;
int ret;
{
int * __restrict__ p = pcaller;
int * q = qcaller;
*p = 1;
*q = 2;
ret = *p;
}
if (ret != 2)
abort ();
}
(where GCC doesn't handle restrict as it can only guarantee to
follow the scoping rule on a whole function basis).
[Bug rtl-optimization/67715] [6 Regression][ARM] ICE in cselib.c during reload_cse_regs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67715 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug middle-end/67714] [6 Regression] signed char is zero-extended instead of sign-extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67714 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c/48885] missed optimization with restrict qualifier?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48885 --- Comment #20 from Marc Glisse --- (In reply to vries from comment #18) Aren't you supposed to also look at: D: declaration of fpp B: block of f P: *fpp accesses: *fp and *fp2 etc ?
[Bug tree-optimization/67659] [5 regression] ICE: segfault: Linux kernel/rcu/tree.c:3261:6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67659 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Markus Trippelsdorf --- dup. *** This bug has been marked as a duplicate of bug 67055 ***
[Bug tree-optimization/67055] [5 Regression] Segmentation fault in fold_builtin_alloca_with_align in tree-ssa-ccp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67055 Markus Trippelsdorf changed: What|Removed |Added CC||nwmcsween at gmail dot com --- Comment #17 from Markus Trippelsdorf --- *** Bug 67659 has been marked as a duplicate of this bug. ***
[Bug target/67716] New: [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716 Bug ID: 67716 Summary: [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de CC: kkojima at gcc dot gnu.org, olegendo at gcc dot gnu.org Target Milestone: --- Target: sh*-*-* Hi! I have recently triggered rebuilds of all packages with reverse-dependencies on the new standard C++ library which means all of them were recompiled with gcc-5 after (mostly) being previously built with gcc-4.9. This resulted in a few FTBFS which previously did not occur, mostly because the packages need to be ported to the new standard C++ library. However, this particular package, libraw, seems to fail to build due to a regression, as gcc-5 generates incorrect assembler code for SH: libtool: compile: g++ -DPACKAGE_NAME=\"LibRaw\" -DPACKAGE_TARNAME=\"libraw\" -DPACKAGE_VERSION=\"0.16.2\" "-DPACKAGE_STRING=\"LibRaw 0.16.2\"" -DPACKAGE_BUGREPORT=\"i...@libraw.org\" -DPACKAGE_URL=\"http://www.libraw.org\"; -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_JPEGLIB_H=1 -DHAVE_JPEGLIB_H=1 -DHAVE_JASPER_JASPER_H=1 -I. -D_FORTIFY_SOURCE=2 -I/usr/local/include -DUSE_JPEG -DUSE_JPEG8 -DUSE_JASPER -DUSE_LCMS2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -fopenmp -c internal/dcraw_common.cpp -fPIC -DPIC -o internal/.libs/dcraw_common.o /tmp/ccTfltZR.s: Assembler messages: /tmp/ccTfltZR.s: Error: unaligned opcodes detected in executable segment make[1]: *** [internal/dcraw_common.lo] Error 1 I have taken the build directory as is and created a compressed tar ball from it which can be downloaded here: https://people.debian.org/~glaubitz/libraw-qDq4D3.tgz It's just 2.3 MiB in size. Full build log in [1]. Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=libraw&arch=sh4&ver=0.16.2-1%2Bb1&stamp=1443116335
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #48 from Markus Trippelsdorf --- (In reply to Markus Trippelsdorf from comment #47) > Another cosmetic issue that I've noticed is that an extra newline is added > after every quoted comment. > > For example: > > > test > reply The extra line is fine if there is no extra line already. > test1 reply (extra line introduced by bugzilla) > test2 reply2 (two extra lines, one introduced by bugzilla, one by the author.) Another issue. Searching all issues for "-fno-ipa-icf" returns "Zarro Boogs found.". But of course there are plenty of PRs that include this string, e.g.: PR67659. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__all__&content=%22-fno-ipa-icf%22&list_id=126886&order=Importance&query_format=specific
[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578 --- Comment #32 from Dominik Vogt --- Update: We've stepped through the code with gdb and noticed that the change in lra-lives.c has nothing to do with our observations. The new condition there is never executed, so it must be just the change in match_reload().
[Bug sanitizer/64906] -fsanitize=integer-divide-by-zero creates false -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64906 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Fri Sep 25 09:50:29 2015 New Revision: 228112 URL: https://gcc.gnu.org/viewcvs?rev=228112&root=gcc&view=rev Log: PR sanitizer/64906 * c-ubsan.c (ubsan_instrument_division): Also pre-evaluate OP1. * c-c++-common/ubsan/pr64906.c: New test. Added: trunk/gcc/testsuite/c-c++-common/ubsan/pr64906.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-ubsan.c trunk/gcc/testsuite/ChangeLog
[Bug target/67717] New: [6.0 regression] ICE when compiling WRF benchmark from cpu2006 with -Ofast -march=bdver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67717
Bug ID: 67717
Summary: [6.0 regression] ICE when compiling WRF benchmark from
cpu2006 with -Ofast -march=bdver4
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vekumar at gcc dot gnu.org
Target Milestone: ---
gfortran -c -o module_cu_gd.fppized.o -I. -I./netcdf/include -march=bdver4
-Ofast -fno-second-underscore module_cu_gd.fppized.f90
module_cu_gd.fppized.f90:1302:0:
(Snip)
END SUBROUTINE CUP_enss
^
Error: insn does not satisfy its constraints:
(insn 8179 8178 14983 589 (parallel [
(set (reg:V4SF 23 xmm2 [orig:2240 vect__1137.6099 ] [2240])
(unspec:V4SF [
(reg:V4SF 23 xmm2 [orig:2240 vect__1137.6099 ] [2240])
(mem:SF (unspec:DI [
(reg/f:DI 4 si [4841])
(reg:V2DI 21 xmm0 [orig:6879
vect__1136.6096 ] [6879])
(const_int 4 [0x4])
] UNSPEC_VSIBADDR) [0 S4 A8])
(mem:BLK (scratch) [0 A8])
(reg:V4SF 23 xmm2 [orig:2240 vect__1137.6099 ] [2240])
] UNSPEC_GATHER))
(clobber (reg:V4SF 23 xmm2 [orig:2240 vect__1137.6099 ] [2240]))
]) module_cu_gd.fppized.f90:1102 4603 {*avx2_gatherdiv4sf}
(nil))
module_cu_gd.fppized.f90:1302:0: internal compiler error: in
extract_constrain_insn, at recog.c:2200
0xaf0548 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-fsf-trunk/gcc/rtl-error.c:109
0xaf056f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-fsf-trunk/gcc/rtl-error.c:120
0xabe03d extract_constrain_insn(rtx_insn*)
../../gcc-fsf-trunk/gcc/recog.c:2200
0xa9e185 reload_cse_simplify_operands
../../gcc-fsf-trunk/gcc/postreload.c:408
0xa9f245 reload_cse_simplify
../../gcc-fsf-trunk/gcc/postreload.c:194
0xa9f245 reload_cse_regs_1
../../gcc-fsf-trunk/gcc/postreload.c:233
0xaa0b13 reload_cse_regs
../../gcc-fsf-trunk/gcc/postreload.c:81
0xaa0b13 execute
../../gcc-fsf-trunk/gcc/postreload.c:2350
Please submit a full bug report,
with preprocessed source if appropriate.
(Snip)
I am trying to get a reduced test case.
But the Bug seems to starts from r227382
commit 0af99ebfea26293fc900fe9050c5dd514005e4e5
2015-09-01 Vladimir Makarov
PR target/61578
* lra-lives.c (process_bb_lives): Process move pseudos with the
same value for copies and preferences
* lra-constraints.c (match_reload): Create match reload pseudo
with the same value from single dying input pseudo.
[Bug c/48885] missed optimization with restrict qualifier?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48885 --- Comment #21 from vries at gcc dot gnu.org --- (In reply to Marc Glisse from comment #20) > (In reply to vries from comment #18) > > Aren't you supposed to also look at: > D: declaration of fpp > B: block of f > P: *fpp > accesses: *fp and *fp2 > etc ? Hmm, I think this may indeed be the difference in interpretation. Standard: "Let D be a declaration of an ordinary identifier that provides a means of designating an object P as a restrict-qualified pointer to type T." Say D is "int *__restrict__ *__restrict__ fpp" Does this designate as a restrict-qualified pointer": 1. both objects fpp and *fpp, or 2. only object fpp (and the first restrict is just an obligate copy of the type qualifier of the restrict pointer declaration fpp points to) ? I'd say the standard is not clear on this point.
[Bug sanitizer/64906] -fsanitize=integer-divide-by-zero creates false -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64906 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Fri Sep 25 10:46:03 2015 New Revision: 228113 URL: https://gcc.gnu.org/viewcvs?rev=228113&root=gcc&view=rev Log: PR sanitizer/64906 * c-ubsan.c (ubsan_instrument_division): Also pre-evaluate OP1. * c-c++-common/ubsan/pr64906.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/c-c++-common/ubsan/pr64906.c Modified: branches/gcc-5-branch/gcc/c-family/ChangeLog branches/gcc-5-branch/gcc/c-family/c-ubsan.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug sanitizer/64906] -fsanitize=integer-divide-by-zero creates false -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64906 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed.
[Bug target/67717] [6.0 regression] ICE when compiling WRF benchmark from cpu2006 with -Ofast -march=bdver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67717 Uroš Bizjak changed: What|Removed |Added Target||x86 Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-25 Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak --- Does additional patch [1] from PR 61578 also fix this failure? [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578#c31
[Bug target/67717] [6.0 regression] ICE when compiling WRF benchmark from cpu2006 with -Ofast -march=bdver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67717 --- Comment #2 from vekumar at gcc dot gnu.org --- yes reproducible with today's trunk. gcc version 6.0.0 20150925 (experimental) (GCC)
[Bug target/67717] [6.0 regression] ICE when compiling WRF benchmark from cpu2006 with -Ofast -march=bdver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67717 --- Comment #3 from vekumar at gcc dot gnu.org --- (In reply to vekumar from comment #2) > yes reproducible with today's trunk. > gcc version 6.0.0 20150925 (experimental) (GCC) I meant ICE still shows up in the trunk.
[Bug fortran/67170] PRE can't hoist out a readonly argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67170
--- Comment #8 from Richard Biener ---
I wonder why IPA SRA doesn't turn the scalar parameter from by-reference to
by-value passing btw. I do see that IPA SRA doesn't handle recursion though,
thus
static int __attribute__((noinline)) foo (int *p)
{
if (*p)
return foo (p);
return *p;
}
int main()
{
int i = 0;
return foo (&i);
}
is not transformed. But in the testcase there isn't a recursive call using
the incoming parameter.
As for the idea to use the alias machinery I'm now leaning towards either
having PTA compute a "points-to-readonly" or SCCVN/LIM pre-compute the
parm-decl
property and have its own disambiguator handle the disambiguation.
[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716 --- Comment #1 from Kazumoto Kojima --- (In reply to John Paul Adrian Glaubitz from comment #0) > I have taken the build directory as is and created a compressed tar ball > from it which can be downloaded here: Could you send .i and .s files with adding -save-temps to the problematic compilation as usual? The build directory is useful only for the same debian environment.
[Bug target/67675] [SH] Improve __builtin_strcmp alignment test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67675 --- Comment #3 from Oleg Endo --- Author: olegendo Date: Fri Sep 25 13:09:04 2015 New Revision: 228118 URL: https://gcc.gnu.org/viewcvs?rev=228118&root=gcc&view=rev Log: gcc/ PR target/67675 * config/sh/sh-mem.cc (sh_expand_cmpstr): Check alignment of addr1 and addr2 individually. Don't emit logical or insn if one is known to be aligned approriately. (sh_expand_cmpnstr): Likewise. gcc/testsuite/ PR target/67675 * gcc.target/sh/pr67675.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr67675.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh-mem.cc trunk/gcc/testsuite/ChangeLog
[Bug target/67717] [6.0 regression] ICE when compiling WRF benchmark from cpu2006 with -Ofast -march=bdver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67717 Mikhail Maltsev changed: What|Removed |Added CC||miyuki at gcc dot gnu.org --- Comment #4 from Mikhail Maltsev --- Looks like a dup of PR67447.
[Bug tree-optimization/57558] Loop not vectorized if iteration count could be infinite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57558
--- Comment #4 from alalaw01 at gcc dot gnu.org ---
Here's another example, extracted from another benchmark - it vectorizes if
INDEX is defined to 'long' but not if INDEX is 'short':
#include
unsigned char *t_run_test(unsigned char *in, int N)
{
unsigned char *out = malloc (N);
for (unsigned INDEX i = 1; i < (N - 1); i++)
out[i] = ((3 * in[i]) - in[i - 1] - in[i + 1]);
return out;
}
However, the -Wunsafe-loop-optimizations doesn't give us anything useful here:
(successful case, warning printed)
$ aarch64-none-elf-gcc -O3 bmark2.c -DINDEX=long -S -Wunsafe-loop-optimizations
-fdump-tree-vect-details=stdout | grep vectorized
bmark2.c:7:3: note: === vect_mark_stmts_to_be_vectorized ===
bmark2.c:7:3: note: loop vectorized
bmark2.c:3:16: note: vectorized 1 loops in function.
bmark2.c: In function 't_run_test':
bmark2.c:3:16: warning: cannot optimize loop, the loop counter may overflow
[-Wunsafe-loop-optimizations]
unsigned char *t_run_test(unsigned char *in, int N)
(unsuccessful case, no warning)
$ aarch64-none-elf-gcc -O3 bmark2.c -DINDEX=short -S
-Wunsafe-loop-optimizations -fdump-tree-vect-details=stdout | grep vectorized
bmark2.c:7:3: note: not vectorized: number of iterations cannot be computed.
bmark2.c:3:16: note: vectorized 0 loops in function.
[Bug c/67680] Seg Fault in gcc 4.9.3 compiling libiberty/floatformat.c when building gcc 5.2.1 on Cygwin 64 on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67680 Marek Polacek changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #8 from Marek Polacek --- Sounds like invalid then.
[Bug fortran/67567] resolve.c: gfc_error called with iface->module == NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67567 --- Comment #4 from Manuel López-Ibáñez --- Author: manu Date: Fri Sep 25 14:24:11 2015 New Revision: 228131 URL: https://gcc.gnu.org/viewcvs?rev=228131&root=gcc&view=rev Log: PR pretty-print/67567 do not pass NULL as a string Fortran passes NULL where a non-null string is expected by the pretty-printer, which causes a sanitizer warning. This could have been found earlier by using gcc_checking_assert. Even if the assertion is false, the result is just an incomplete diagnostic, thus it seems more user-friendly to assert only when checking. I do not have any idea how to properly fix the Fortran bug, thus this patch simply works-around it. gcc/fortran/ChangeLog: 2015-09-25 Manuel López-Ibáñez PR pretty-print/67567 * resolve.c (resolve_fl_procedure): Work-around when iface->module == NULL. gcc/ChangeLog: 2015-09-25 Manuel López-Ibáñez PR pretty-print/67567 * pretty-print.c (pp_string): Add gcc_checking_assert. * pretty-print.h (output_buffer_append_r): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/pretty-print.c trunk/gcc/pretty-print.h
[Bug fortran/67567] resolve.c: gfc_error called with iface->module == NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67567 Manuel López-Ibáñez changed: What|Removed |Added Keywords||diagnostic CC|manu at gcc dot gnu.org|fxcoudert at gcc dot gnu.org, ||paul.richard.thomas at gmail dot c ||om --- Comment #5 from Manuel López-Ibáñez --- This is a Fortran only issue now. Related to the submodules work apparently: https://gcc.gnu.org/ml/fortran/2015-09/msg00094.html
[Bug fortran/67567] resolve.c: gfc_error called with iface->module == NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67567 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #6 from Paul Thomas --- (In reply to Manuel López-Ibáñez from comment #5) > This is a Fortran only issue now. Related to the submodules work apparently: > > https://gcc.gnu.org/ml/fortran/2015-09/msg00094.html Thanks Manuel, I'll get onto it. Paul
[Bug target/67675] [SH] Improve __builtin_strcmp alignment test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67675 Oleg Endo changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Oleg Endo --- Fixed on trunk.
[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716 --- Comment #2 from John Paul Adrian Glaubitz --- (In reply to Kazumoto Kojima from comment #1) > Could you send .i and .s files with adding -save-temps to the problematic > compilation as usual? The build directory is useful only for the same > debian environment. Oops, I somehow assumed they were in the tarball but I didn't really check. Attaching the .i and .s files that were generated with: glaubitz@tirpitz:~/debian/libraw-test/libraw-qDq4D3/libraw-0.16.2/internal$ gcc -save-temps -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -fopenmp -c dcraw_common.cpp -fPIC -DPIC -o dcraw_common.o -I .. dcraw_common.s: Assembler messages: dcraw_common.s: Error: unaligned opcodes detected in executable segment glaubitz@tirpitz:~/debian/libraw-test/libraw-qDq4D3/libraw-0.16.2/internal$ Interestingly, this problem doesn't occur when omitting all the extra options: glaubitz@tirpitz:~/debian/libraw-test/libraw-qDq4D3/libraw-0.16.2/internal$ gcc -c dcraw_common.cpp -o dcraw_common.o -I .. glaubitz@tirpitz:~/debian/libraw-test/libraw-qDq4D3/libraw-0.16.2/internal$ vs. glaubitz@tirpitz:~/debian/libraw-test/libraw-qDq4D3/libraw-0.16.2/internal$ gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -fopenmp -c dcraw_common.cpp -fPIC -DPIC -o dcraw_common.o -I .. /tmp/ccJsoST5.s: Assembler messages: /tmp/ccJsoST5.s: Error: unaligned opcodes detected in executable segment glaubitz@tirpitz:~/debian/libraw-test/libraw-qDq4D3/libraw-0.16.2/internal$ I assume, it's one of -f options, but I didn't check yet. Adrian
[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716 --- Comment #3 from John Paul Adrian Glaubitz --- Created attachment 36388 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36388&action=edit Compressed C++ source for dcraw_common.cpp
[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716 --- Comment #4 from John Paul Adrian Glaubitz --- Created attachment 36389 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36389&action=edit Compressed, preprocessed C++ source for dcraw_common.cpp
[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716 --- Comment #5 from John Paul Adrian Glaubitz --- Created attachment 36390 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36390&action=edit Compressed, assembled C++ source for dcraw_common.cpp
[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716 --- Comment #6 from John Paul Adrian Glaubitz --- Attachment 36390 is not assembled, of course. But the actual assembler output from gcc :).
[Bug c/48885] missed optimization with restrict qualifier?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48885 --- Comment #22 from joseph at codesourcery dot com --- On Fri, 25 Sep 2015, vries at gcc dot gnu.org wrote: > Standard: "Let D be a declaration of an ordinary identifier that provides a > means of designating an object P as a restrict-qualified pointer to type T." > > Say D is "int *__restrict__ *__restrict__ fpp" > > Does this designate as a restrict-qualified pointer": > 1. both objects fpp and *fpp, or Both objects. And also objects fpp[1], fpp[-1], etc., if they exist.
[Bug bootstrap/60946] Current 4.9 branch does not boot strap on FC20 with systemtap-devel installed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60946 --- Comment #9 from Andi Kleen --- Created attachment 36391 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36391&action=edit workaround This workaround fixes it. Disable -gc-section for libstdc++. It seems like a linker bug. I opened a binutils bug report https://sourceware.org/bugzilla/show_bug.cgi?id=19008
ivybridge processor is not supported by -march ivybridge
I asked at linux questions about if my mobile processor really was an ivybridge and if -march ivybridge was really what it could use. https://www.linuxquestions.org/questions/showthread.php?s=b99823329486c2467986c8809a00263c&p=5425639#post5425639 My processor is described here: http://ark.intel.com/products/71469/Intel-Pentium-Processor-2117U-2M-Cache-1_80-GHz The ivy bridge arch is described here: https://en.wikipedia.org/wiki/Ivy_Bridge_28microarchitecture%29 My problem is that my cpu does not support all the standard ivybridge instructions. I want to know if this is a bug in gcc or my processor or what. -- View this message in context: http://gcc.1065356.n5.nabble.com/ivybridge-processor-is-not-supported-by-march-ivybridge-tp1188778.html Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug middle-end/67718] New: [aarch64] long double incorrect code for copysign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67718
Bug ID: 67718
Summary: [aarch64] long double incorrect code for copysign
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: thanm at google dot com
Target Milestone: ---
Created attachment 36392
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36392&action=edit
reduced test case (C++)
Compiling the attached example with g++ at -O2 or -O1 results in incorrect code
(-O0 looks ok). This is with gcc trunk aarch64-linux-android target; problem is
also present in 4.9. Source being compiled looks like:
/// begin
union IEEEl2bits {
long double e;
struct {
unsigned long manl :64;
unsigned long manh :48;
unsigned int exp :15;
unsigned int sign :1;
} bits;
};
long double
copysignl(long double x, long double y)
{
union IEEEl2bits ux, uy;
ux.e = x;
uy.e = y;
ux.bits.sign = uy.bits.sign;
return (ux.e);
}
/// end
Here is -O2 assembly:
ushrd1, d1, 63
fmovx0, d0
fmovx1, v0.d[1]
fmovd0, x0
fmovx2, d1
bfi x1, x2, 63, 1
fmovv0.d[1], x1
ret
Note that the first instruction is sourcing d1 (incorrect) -- this needs to
read q0 in order for correct semantics.
I am not a gcc expert, but I'm guessing that the problem is happening in the
reload phase. Prior to reload the RTL looks ok:
(insn 10 9 7 2 (set (reg:DI 81 [ D.3189 ])
(lshiftrt:DI (subreg:DI (reg:TI 33 v1 [ y ]) 8)
(const_int 63 [0x3f])))
bionic/libm/upstream-freebsd/lib/msun/src/s_copysignl.c:40 512
{*aarch64_lshr_sisd_or_int_di3}
(expr_list:REG_DEAD (reg:TI 33 v1 [ y ])
(nil)))
and then after reload this gets turned into
(insn 10 9 7 2 (set (reg:DI 33 v1 [orig:81 D.3189 ] [81])
(lshiftrt:DI (reg:DI 33 v1 [ y+8 ])
(const_int 63 [0x3f])))
bionic/libm/upstream-freebsd/lib/msun/src/s_copysignl.c:40 512
{*aarch64_lshr_sisd_or_int_di3}
(nil))
which doesn't look right -- we seem to have lost the "TI", which I take to be
the bug.
[Bug c/63346] xserver_xorg-server-1.15.1 crash on RaspberryPi when compiled with gcc-4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63346 Peter Seiderer changed: What|Removed |Added Target||arm1176jzf-s ||arm-buildroot-linux-uclibcg ||nueabi-gcc Component|target |c Known to work||4.8.3, 4.8.4 Host||x86_64 Version|4.9.0 |4.9.3 Known to fail||4.9.1, 4.9.3, 5.2.0 --- Comment #1 from Peter Seiderer --- Crash still reproducible with buildroot 2015.11-git-00271-g81c4788 (xserver-1.17.2) gcc-4.9.3 and gcc-5.2.0 with optimization for space (-Os). No crash with gcc-5.2.0 and optimization '-O3'...
[Bug c++/51333] cxxabi.h incompatible with -fkeep-inline-functions at link time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51333 Josh Baudhuin changed: What|Removed |Added CC||joshb at cadence dot com --- Comment #4 from Josh Baudhuin --- Noticed this somewhat intermittently in 4.8.3. The option was not universally applied to the build, just to the code in one .so (and the same code rebuilt/linked as .a).
[Bug fortran/55603] [F03] Memory leak with scalar allocatable function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603 --- Comment #10 from Mikael Morin --- Author: mikael Date: Fri Sep 25 20:28:33 2015 New Revision: 228151 URL: https://gcc.gnu.org/viewcvs?rev=228151&root=gcc&view=rev Log: Add PR fortran/55603 working test gcc/testsuite/ PR fortran/55603 * gfortran.dg/allocatable_function_9.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/allocatable_function_9.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/37336] [F03] Finish derived-type finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 Bug 37336 depends on bug 55603, which changed state. Bug 55603 Summary: [F03] Memory leak with scalar allocatable function result https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/55603] [F03] Memory leak with scalar allocatable function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603 Mikael Morin changed: What|Removed |Added Status|NEW |RESOLVED Known to work||6.0 Resolution|--- |FIXED --- Comment #11 from Mikael Morin --- (In reply to Mikael Morin from comment #9) > It seems to work with current trunk. FIXED? I have just committed the test. I'm closing this PR.
[Bug c++/58566] [c++11] ICE with invalid expression in lambda body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58566
Vittorio Zecca changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Comment #2 from Vittorio Zecca ---
Still fails on 6.0.0 trunk
~/gcc-trunk/bin/g++ -S p1.C -std=c++11
p1.C: In lambda function:
p1.C:5:25: error: invalid use of member function (did you forget the ‘()’ ?)
[this]{ return foo; };
^
p1.C:5:25: internal compiler error: in check_return_expr, at cp/typeck.c:8609
0x729126 check_return_expr(tree_node*, bool*)
../../gcc/gcc/cp/typeck.c:8609
0x7663fe finish_return_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:873
0x70d5c4 cp_parser_lambda_body
../../gcc/gcc/cp/parser.c:9636
0x70d5c4 cp_parser_lambda_expression
../../gcc/gcc/cp/parser.c:9141
0x6df257 cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:4510
0x6eb64b cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6201
0x6f00a9 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7486
0x6f0ce7 cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:8223
0x6f13ef cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8481
0x6f9b61 cp_parser_expression
../../gcc/gcc/cp/parser.c:8635
0x6fb6c6 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:10049
0x706ae5 cp_parser_statement
../../gcc/gcc/cp/parser.c:9900
0x7076a2 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:10172
0x70780b cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:10126
0x707a1b cp_parser_function_body
../../gcc/gcc/cp/parser.c:19785
0x707a1b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:19821
0x708899 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:24428
0x70c45c cp_parser_late_parsing_for_member
../../gcc/gcc/cp/parser.c:25232
0x6e7cc1 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:20645
0x6e7cc1 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:20671
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578 --- Comment #33 from Vladimir Makarov --- Author: vmakarov Date: Fri Sep 25 21:06:08 2015 New Revision: 228153 URL: https://gcc.gnu.org/viewcvs?rev=228153&root=gcc&view=rev Log: 2015-09-25 Vladimir Makarov PR target/61578 * lra-constarints.c (match_reload): Check presence of the input pseudo in the output pseudo. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c
[Bug fortran/67525] ICE on select type with improper selector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67525 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Sep 25 22:28:04 2015 New Revision: 228155 URL: https://gcc.gnu.org/viewcvs?rev=228155&root=gcc&view=rev Log: 2015-09-25 Steven G. Kargl PR fortran/67525 * parse.c (match_deferred_characteristics): Remove an assert, which allows an invalid SELECT TYPE selector to be detected. 2015-09-25 Steven G. Kargl PR fortran/67525 * gfortran.dg/pr67525.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr67525.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/67614] ICE on using arithmetic if with null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67614 --- Comment #6 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Sep 25 22:30:26 2015 New Revision: 228156 URL: https://gcc.gnu.org/viewcvs?rev=228156&root=gcc&view=rev Log: 2015-09-25 Steven G. Kargl PR fortran/67614 * resolve.c (gfc_resolve_code): Prevent ICE for invalid EXPR_NULL. 2015-09-25 Steven G. Kargl PR fortran/67614 * gfortran.dg/pr67614.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr67614.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/67525] ICE on select type with improper selector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67525 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Sep 25 22:45:27 2015 New Revision: 228157 URL: https://gcc.gnu.org/viewcvs?rev=228157&root=gcc&view=rev Log: 2015-09-25 Steven G. Kargl PR fortran/67525 * parse.c (match_deferred_characteristics): Remove an assert, which allows an invalid SELECT TYPE selector to be detected. 2015-09-25 Steven G. Kargl PR fortran/67525 * gfortran.dg/pr67525.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67525.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/parse.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/67614] ICE on using arithmetic if with null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67614 --- Comment #7 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Sep 25 22:59:15 2015 New Revision: 228158 URL: https://gcc.gnu.org/viewcvs?rev=228158&root=gcc&view=rev Log: 2015-09-25 Steven G. Kargl PR fortran/67614 * resolve.c (gfc_resolve_code): Prevent ICE for invalid EXPR_NULL. 2015-09-25 Steven G. Kargl PR fortran/67614 * gfortran.dg/pr67614.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67614.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/resolve.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/67614] ICE on using arithmetic if with null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67614 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |5.3 --- Comment #8 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for bug report and convincing me to look at it again.
[Bug fortran/67525] ICE on select type with improper selector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67525 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |5.3 --- Comment #5 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug target/67718] [aarch64] long double incorrect code for copysign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67718 Andrew Pinski changed: What|Removed |Added Component|middle-end |target --- Comment #1 from Andrew Pinski --- What is happening is the subreg is being assumed it is lower part of the register rather than the upper part. Really this subreg should have declared as invalid for v1 as there is no way to do scalar for the upper part of the register. This makes this a target issue rather than a middle-end one. Also by the way using __builtin_copysignl should generate better code generation anyways.
[Bug c++/67719] New: [concepts] bug with concepts using logical or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67719
Bug ID: 67719
Summary: [concepts] bug with concepts using logical or
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ryan.burn at gmail dot com
Target Milestone: ---
This code fails to compile but should.
It gives the following error:
main.cpp: In function ‘int main()’:
main.cpp:11:15: error: template constraint failure
Ax a;
^
main.cpp:11:15: note: constraints not satisfied
main.cpp:11:15: note: in the expansion of ‘(C)()...’
/
#include
template concept bool C() {
return std::is_same::value || std::is_same::value;
}
template
struct Ax {};
int main() {
Ax a;
return 0;
}
/
[Bug c++/67720] New: [concepts] bug with recursive constrained function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67720
Bug ID: 67720
Summary: [concepts] bug with recursive constrained function
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ryan.burn at gmail dot com
Target Milestone: ---
The below code is valid but gives this error with gcc:
main.cpp: In instantiation of ‘auto f(const std::tuple<_El0, _El ...>&)
requires predicate((cpt_BooleanFalseConstant)(f::t)))>)())
[with TFirst = std::integral_constant; TRest =
{std::integral_constant, std::integral_constant}]’:
main.cpp:34:11: required from ‘auto f(const std::tuple<_El0, _El ...>&)
requires predicate((cpt_BooleanFalseConstant)(f::t)))>)())
[with TFirst = std::integral_constant; TRest =
{std::integral_constant, std::integral_constant,
std::integral_constant}]’
main.cpp:44:6: required from here
main.cpp:34:11: error: call of overloaded
‘f(std::tuple, std::integral_constant
>)’ is ambiguous
return f(std::tuple());
^
main.cpp:24:6: note: candidate: auto f(const std::tuple<_El0, _El ...>&)
requires predicate((cpt_BooleanTrueConstant)(f::t)))>)())
[with TFirst = std::integral_constant; TRest =
{std::integral_constant}]
auto f(const std::tuple& t)
^
main.cpp:31:6: note: candidate: auto f(const std::tuple<_El0, _El ...>&)
requires predicate((cpt_BooleanFalseConstant)(f::t)))>)())
[with TFirst = std::integral_constant; TRest =
{std::integral_constant}]
auto f(const std::tuple& t)
#include
#include
template
requires requires {
X::value;
}
constexpr bool lift_boolean_constant_value = X::value;
template concept bool cpt_BooleanTrueConstant() {
return requires { requires lift_boolean_constant_value; };
}
template concept bool cpt_BooleanFalseConstant() {
return requires { requires !lift_boolean_constant_value; };
}
template
auto p(std::integral_constant) {
return std::integral_constant();
}
template
auto f(const std::tuple& t)
requires cpt_BooleanTrueConstant(t)))>()
{
return 1;
}
template
auto f(const std::tuple& t)
requires cpt_BooleanFalseConstant(t)))>()
{
return f(std::tuple());
}
int main() {
std::tuple<
std::integral_constant,
std::integral_constant,
std::integral_constant,
std::integral_constant
> t;
f(t);
return 0;
}
[Bug target/67391] [SH] Convert clrt addc to normal add insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391 --- Comment #15 from Oleg Endo --- Created attachment 36393 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36393&action=edit Another trail, doesn't work with LRA (In reply to Kazumoto Kojima from comment #14) > Created attachment 36387 [details] > a trial > > Although a bit ugly, how about adding pattern using scratch reg? > Does it get the original clrt+addc issue back again? The clrt+addc sequence does not appear with this patch it seems. There are only a few +4/-4 code size changes in the CSiBE set. So basically the patch seems to work, but I think we should try to avoid it. For example, with the attached patch (without LRA) I'm getting for CSiBE: sum: 3345527 -> 3334307-11220 / -0.335373 % It seems the addsi3 pattern has a big influence on address calculations. I haven't done full testing of the patch though. Compiling CSiBE with this patch and LRA triggers various problems. One is a segfault in LRA and another is something in postreload. I'm now trying to come up with something that is between your patch and my patch to make it work with LRA. However, somehow I think we are just desperately wallpapering LRA deficits here. It looks a bit fragile. We should try to avoid that if possible.
[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716 --- Comment #7 from Oleg Endo --- Created attachment 36394 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36394&action=edit preprocessed C++ source for dcraw_common.cpp The code in attachment 36389 doesn't compile with the trunk compiler because of some integer literal / type mismatches. Adding some casts in the tables fixes the issue.
[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716 --- Comment #8 from Oleg Endo --- On sh-elf/newlib there are no threads, so -fopenmp doesn't work. I can't reproduce it Without -fopenmp.
