[Bug preprocessor/77699] suspicious code in get_next_line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77699 Bernd Edlinger changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Bernd Edlinger --- fixed on trunk.
[Bug bootstrap/77788] profiledbootstrap failures on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77788 --- Comment #4 from Martin Liška --- Author: marxin Date: Thu Oct 6 07:33:49 2016 New Revision: 240827 URL: https://gcc.gnu.org/viewcvs?rev=240827&root=gcc&view=rev Log: Fix warnings for make profiledbootstrap (PR bootstrap/77788) PR bootstrap/77788 * expmed.h (mul_highpart_cost_ptr): Add an gcc_assert. * gimple-ssa-strength-reduction.c (slsr_process_cast): Initialize a pointer to NULL. (slsr_process_copy): Likewise. * input.c (location_get_source_line): Likewise. * tree-ssa-ccp.c (optimize_atomic_bit_test_and): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/expmed.h trunk/gcc/gimple-ssa-strength-reduction.c trunk/gcc/input.c trunk/gcc/tree-ssa-ccp.c
[Bug bootstrap/77788] profiledbootstrap failures on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77788 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška --- Fixed.
[Bug tree-optimization/77880] New: [7 Regression] out of memory building recent LLVM on ppc64le with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77880 Bug ID: 77880 Summary: [7 Regression] out of memory building recent LLVM on ppc64le with -O3 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: bernds at gcc dot gnu.org Target Milestone: --- Host: ppc64le Target: ppc64le Build: ppc64le Since r237069: commit 3e346f54bf009e9c2dbccb3654ba1e81c8bb8e26 Author: bernds Date: Fri Jun 3 14:20:53 2016 + PR tree-optimization/52171 I cannot build recent LLVM on ppc64le anymore, because on the attached file gcc uses all memory with -O3. $ g++ -O3 -c ARMBuildAttrs.ii
[Bug tree-optimization/77880] [7 Regression] out of memory building recent LLVM on ppc64le with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77880 --- Comment #1 from Markus Trippelsdorf --- Created attachment 39762 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39762&action=edit unreduced testcase
[Bug sanitizer/66343] "Error: .Lubsan_type3 already defined" with UBSan and precompiled headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66343 --- Comment #11 from Jakub Jelinek --- The #c3 testcase works now, so if you have something different you can reproduce it on, please attach preprocessed source for the PCH header and preprocessed source of the c/c++ source with the PCH header unincluded plus command lines.
[Bug rtl-optimization/77855] [7 Regression] 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=77855
--- Comment #3 from Richard Biener ---
Testcase failing at -O2:
int a, b = 1, c, e, f, g, k, m, n, o;
char d, h, i, j, l;
char res[2];
void __attribute__ ((noinline,noclone)) fn2 ()
{
d = 2;
}
void fn3 ()
{
for (;;)
{
for (; b; b--)
{
fn2 ();
if (e)
j = 1;
if (f)
L1:
k = j | (a & l);
for (;;)
{
__builtin_snprintf (res, 2, "%d\n", d);
if (d)
break;
for (; o; o--)
for (; n;)
for (; m; m++)
;
goto L1;
}
}
g = h;
c = i;
break;
}
}
int main ()
{
fn3 ();
if (res[0] != '2')
__builtin_abort ();
return 0;
}
[Bug tree-optimization/77839] [6 Regression] Memory- and compile time hog at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77839 Richard Biener changed: What|Removed |Added Known to work||7.0 Summary|[6/7 Regression] Memory-|[6 Regression] Memory- and |and compile time hog at -O1 |compile time hog at -O1 and |and above |above Known to fail|7.0 | --- Comment #6 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/77839] [6/7 Regression] Memory- and compile time hog at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77839 --- Comment #5 from Richard Biener --- Author: rguenth Date: Thu Oct 6 08:54:37 2016 New Revision: 240829 URL: https://gcc.gnu.org/viewcvs?rev=240829&root=gcc&view=rev Log: 2016-10-06 Richard Biener PR tree-optimization/77839 * tree-ssa-sccvn.c (set_ssa_val_to): Forbid value -> constant value lattice transition. * gcc.dg/torture/pr77839.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr77839.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug rtl-optimization/77738] Invalid initialisation of ar.lc register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77738 Andreas Schwab changed: What|Removed |Added Component|target |rtl-optimization --- Comment #1 from Andreas Schwab --- The count expression is (const_int -2147483648 [0x8000]), but the iteration count is 2147483648.
[Bug rtl-optimization/77738] Invalid initialisation of ar.lc register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77738 Andreas Schwab changed: What|Removed |Added Target Milestone|--- |7.0
[Bug fortran/77872] [5/6/7 Regression] ICE in gfc_conv_descriptor_token, at fortran/trans-array.c:305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77872 --- Comment #2 from Dominique d'Humieres --- A first change occurred between revisions r209838 (2014-04-27, OK) and r210042 (2014-05-03, ICE): pr77872.f90:9:0: internal compiler error: in gfc_conv_procedure_call, at fortran/trans-expr.c:4824 call x%f() A second change occurred between revisions r212119 (2014-06-29, error above) and r212302 (2014-07-05, error reported in comment 0), likely r212299.
[Bug target/77738] Invalid initialisation of ar.lc register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77738 Andreas Schwab changed: What|Removed |Added Component|rtl-optimization|target --- Comment #2 from Andreas Schwab --- The doloop_end pattern should reject a mode != DImode.
[Bug target/77759] ICE in function_arg_record_value on nested empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77759 --- Comment #3 from Eric Botcazou --- Author: ebotcazou Date: Thu Oct 6 10:28:23 2016 New Revision: 240830 URL: https://gcc.gnu.org/viewcvs?rev=240830&root=gcc&view=rev Log: PR target/77759 * config/sparc/sparc.c (classify_data_t): Remove int_regs field. (classify_registers): Don't set it (function_arg_slotno): Don't initialize and test it. Tidy up. Added: trunk/gcc/testsuite/g++.dg/other/pr77759.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.c trunk/gcc/testsuite/ChangeLog
[Bug target/77759] ICE in function_arg_record_value on nested empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77759 --- Comment #4 from Eric Botcazou --- Author: ebotcazou Date: Thu Oct 6 10:30:55 2016 New Revision: 240831 URL: https://gcc.gnu.org/viewcvs?rev=240831&root=gcc&view=rev Log: PR target/77759 * config/sparc/sparc.c (classify_data_t): Remove int_regs field. (classify_registers): Don't set it (function_arg_slotno): Don't initialize and test it. Tidy up. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/other/pr77759.C - copied unchanged from r240830, trunk/gcc/testsuite/g++.dg/other/pr77759.C Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/sparc/sparc.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug target/77759] ICE in function_arg_record_value on nested empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77759 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.3 --- Comment #5 from Eric Botcazou --- Thanks for the report and the fix.
[Bug tree-optimization/77880] [7 Regression] out of memory building recent LLVM on ppc64le with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77880 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug tree-optimization/77879] [7 Regression] mpd gets miscompiled since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77879 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-10-06 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Mine.
[Bug fortran/77872] [5/6/7 Regression] ICE in gfc_conv_descriptor_token, at fortran/trans-array.c:305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77872 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.5
[Bug rtl-optimization/77877] missed optimization in switch of modulus value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77877 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-06 Component|tree-optimization |rtl-optimization Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- The point is that with the modulus visible VRP will remove the default case (or rather take a random one -- here the first one -- as new default): : n_9 = n_8(D) % 3; switch (n_9) , case 1: , case 2: > : zero.0_1 = zero; _2 = zero.0_1 + 1; zero = _2; goto ; : one.1_3 = one; _4 = one.1_3 + 1; one = _4; goto ; : two.2_5 = two; _6 = two.2_5 + 1; two = _6; : return; if we don't have the modulo then the default case will not be optimized away (not the one with the unreachable either) before RTL expansion. So it looks like the four-cases variant where one case later vanishes happens to be expanded better. Which means we should improve expansion for the IL case above (stmt.c:expand_case). Or work around by choosing another value as the "default" if that makes expand_case happy.
[Bug tree-optimization/77880] [7 Regression] out of memory building recent LLVM on ppc64le with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77880 --- Comment #2 from Bernd Schmidt --- Hmm, a memcmp with ULONG_MAX as the size. Try this? Index: expr.c === --- expr.c (revision 240429) +++ expr.c (working copy) @@ -785,7 +785,7 @@ by_pieces_ninsns (unsigned HOST_WIDE_INT case COMPARE_BY_PIECES: int batch = targetm.compare_by_pieces_branch_ratio (mode); int batch_ops = 4 * batch - 1; - int full = n_pieces / batch; + unsigned HOST_WIDE_INT full = n_pieces / batch; n_insns += full * batch_ops; if (n_pieces % batch != 0) n_insns++;
[Bug tree-optimization/77879] [7 Regression] mpd gets miscompiled since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77879 --- Comment #4 from Richard Biener --- Created attachment 39763 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39763&action=edit patch : _73 = MEM[(long unsigned int *)&home + 8B]; _74 = MEM[(char * *)&home]; D.32906 = PathTraitsFS::Build (_74, _73, ".config", 7); [return slot optimization] : MEM[(struct _Alloc_hider *)&fallback]._M_p = &MEM[(struct basic_string *)&fallback].D.17830._M_local_buf; _76 = MEM[(char * *)&D.32906]; if (&D.32906.D.17830._M_local_buf == _76) goto ; else goto ; this is the condition that is optimized. _76 points to nonlocal/escaped. Looks like a PTA bug, mishandled RSO in some way. Ah, RSO handling is missing from pure/const fn handling. Can you try if the attached fixes the issue?
[Bug tree-optimization/77880] [7 Regression] out of memory building recent LLVM on ppc64le with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77880 --- Comment #3 from Markus Trippelsdorf --- Works fine, thank you.
[Bug tree-optimization/77879] [7 Regression] mpd gets miscompiled since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77879 --- Comment #5 from Markus Trippelsdorf --- Yes, your patch fixes the issue. Thanks.
[Bug tree-optimization/77664] Missed optimization: signed int >= 0 && < unsigned short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77664 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 39764 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39764&action=edit gcc7-pr77664.patch Untested fix.
[Bug target/77881] New: [5/6/7 Regression] Non-optimal signed comparison on x86_64 since r146817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77881
Bug ID: 77881
Summary: [5/6/7 Regression] Non-optimal signed comparison on
x86_64 since r146817
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
int
foo (long long int a, int b)
{
if (a >= 0 || b)
baz ();
}
int
bar (long long int a, int b)
{
if (a < 0 || b)
baz ();
}
on x86_64-linux with -O2 is compiled into following starting with r146817:
testq %rdi, %rdi
jns .L4
testl %esi, %esi
jne .L4
for foo, which looks reasonable, and
shrq$63, %rdi
testb %dil, %dil
jne .L9
testl %esi, %esi
jne .L9
in bar, where I'd expect and we used to emit in the past
testq %rdi, %rdi
js .L9
testl %esi, %esi
jne .L9
or something similar. I wonder if we want a combine pattern that would
transform right shift by precision - 1 followed by comparison of the result
against 0 if the result of the right shift is dead into just signed comparison.
[Bug target/77881] [5/6/7 Regression] Non-optimal signed comparison on x86_64 since r146817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77881 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-06 CC||matz at gcc dot gnu.org, ||uros at gcc dot gnu.org Target Milestone|--- |5.5 Ever confirmed|0 |1
[Bug rtl-optimization/77855] [7 Regression] 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=77855 --- Comment #4 from Richard Biener --- Author: rguenth Date: Thu Oct 6 12:17:53 2016 New Revision: 240832 URL: https://gcc.gnu.org/viewcvs?rev=240832&root=gcc&view=rev Log: 2016-10-06 Richard Biener PR tree-optimization/77855 * tree-ssa-pre.c (prune_clobbered_mems): Queue exprs to remove instead of removing the current item while iterating over the set which is not safe. * gcc.dg/torture/pr77855.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr77855.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug target/77881] [5/6/7 Regression] Non-optimal signed comparison on x86_64 since r146817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77881 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from Richard Biener --- The question is why we expand a < 0 to shift and test in the first place.
[Bug target/77881] [5/6/7 Regression] Non-optimal signed comparison on x86_64 since r146817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77881 --- Comment #2 from Michael Matz --- Exactly. Whatever makes it currently work for >=0 should be made to work for <0 as well.
[Bug target/77881] [5/6/7 Regression] Non-optimal signed comparison on x86_64 since r146817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77881 --- Comment #3 from Jakub Jelinek --- Well, generally if we want to store a < 0 or a >= 0 into a bool/int variable etc., then the right shift is desirable, because we avoid branching or sets/setns, but not when the result is used in a conditional jump.
[Bug rtl-optimization/77855] [7 Regression] 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=77855 Richard Biener changed: What|Removed |Added Target Milestone|7.0 |5.5
[Bug rtl-optimization/77855] [7 Regression] 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=77855 Richard Biener changed: What|Removed |Added Known to work||7.0 --- Comment #5 from Richard Biener --- Fixed on trunk sofar. I do plan to backport as this is a latent issue.
[Bug c/77882] New: [Aarch64, ARM64] Add 'naked' function attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77882
Bug ID: 77882
Summary: [Aarch64, ARM64] Add 'naked' function attribute
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: christophe.monat at st dot com
Target Milestone: ---
With the following code fragment aarch64-attribute-naked.c :
void
__attribute__((naked))
dealwithit()
{
// Stuff removed above, below we assume that the 'naked' attribute
// does the job and does not generate the usual 'ret' instruction
asm("eret"::);
}
$ aarch64-linux-gnu-gcc -S aarch64-attribute-naked.c
aarch64-attribute-naked.c:4:1: warning: 'naked' attribute directive ignored
[-Wattributes]
I have tried with a gcc-6.1.1, but simply as an example, this feature has never
been ported to Aarch64, I think.
As this attribute is supported for the legacy ARM target, it would be nice it
the Aarch64 compiler could support it.
[Bug target/71607] [5/6/7 Regression] [ARM] ice due to forbidden enabled attribute dependency on instruction operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71607 avieira at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #7 from avieira at gcc dot gnu.org --- Got a patch up for review on gcc-patches that fixes this, see https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00377.html
[Bug c/77882] [Aarch64] Add 'naked' function attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77882 Ramana Radhakrishnan changed: What|Removed |Added Target||aarch64*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-06 CC||ramana at gcc dot gnu.org Summary|[Aarch64, ARM64] Add|[Aarch64] Add 'naked' |'naked' function attribute |function attribute Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Ramana Radhakrishnan --- Confirmed. > > As this attribute is supported for the legacy ARM target, it would be nice > it the Aarch64 compiler could support it. s/legacy// patches welcome for further discussion ;) regards Ramana
[Bug target/77882] [Aarch64] Add 'naked' function attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77882 Andrew Pinski changed: What|Removed |Added Component|c |target --- Comment #2 from Andrew Pinski --- I really think the naked attribute as not useful at all. I think it was a bad idea. Why not write a .s file which does what you want?
[Bug target/77882] [Aarch64] Add 'naked' function attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77882 --- Comment #3 from Christophe Monat --- Andrew, (In reply to Andrew Pinski from comment #2) > I really think the naked attribute as not useful at all. I think it was a > bad idea. Why not write a .s file which does what you want? Well, from the discussions I read (for instance in bug #25967) before posting this, I was more or less expecting this remark. I agree that some arguments there are not valid. In a nutshell, I wrote quite a lot of tricky testing code (dealing manually with functions prologues/epilogues, etc..) for the ARM target (Ramana : please pardon the misused 'legacy' adjective) using this feature, and I would like to have a similar installment for ARM64. I am also generally simply bothered at the idea of putting decoration at the beginning of an assembly file, and starting from .c enables me to have the appropriate tags automatically emitted when I switch from target to target. --C
[Bug target/77881] [5/6/7 Regression] Non-optimal signed comparison on x86_64 since r146817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77881
--- Comment #4 from Michael Matz ---
Actually, it's merely a deficiency in current combine not simplifying
intermediate expressions enough. One of the things that need to happen is
the following transformation:
(compare:CCZ (subreg:QI (lshiftrt:DI (reg:DI 95)
(const_int 63 [0x3f])) 0)
(const_int 0 [0]))
--> (remove subreg)
(compare:CCZ (lshiftrt:DI (reg:DI 95)
(const_int 63 [0x3f]))
(const_int 0 [0]))
--> (recognize that it's a sign bit extract)
(ge (reg:DI 95) (const_int 0))
(or 'lt', doesn't matter, depends on the outer code by which the compare:CCZ
result itself is compared).
In current combine.c this requires two steps, the removal of the irrelevant
subreg (irrelevant in this specific context), and then the recognition of
the sign bit extraction. With the first function combine has the chance
for two attempts of simplification because we have a sequence of three
isnstructions to start with:
t1 = ~a
t2 = 255 & (t1 >> 63)
flags = t2 != 0
The intermediate expression is combine_simplify_rtx'ed twice, so both steps
above happen, and we get good code. In the second function we only have
two instructions to start with (the not is missing):
t2 = 255 & (a >> 63)
flags = t2 == 0
Only the first step above happens, we're left with the (lshiftrt(subreg)) and
nothing simplifies this further before it tries to recognize the insn
(which ultimately fails).
The same can also be seen when artificially forcing the expression to
be a tad more complicated:
int bar2 (long long int a, long long int a2, int b) {
if ((a+a2) < 0 || b)
baz();
}
Here, we also get good code again, simply because combine can have two
attempts at the intermediate expression.
After some amount of tracing combine I've come up with the below patch.
The simplify_comparison function already contains loops that effectively
retry simplification after a change occured. But the code that actually
removes
a useless subreg is after that loop. Putting it into the loop as well
fixes the problem. It can't be removed from the old place because between the
loop and subreg removal it might actually change the expression further
due to make_compound_operation (though I don't know if that really creates
subregs often).
combines normal facilities of not doing combines when intermediate results
are really used outside will take care of not creating useless code.
Index: combine.c
===
--- combine.c (revision 235171)
+++ combine.c (working copy)
@@ -11891,6 +11891,27 @@ simplify_comparison (enum rtx_code code,
if (subreg_lowpart_p (op0)
&& GET_MODE_PRECISION (GET_MODE (SUBREG_REG (op0))) < mode_width)
/* Fall through */ ;
+ else if (subreg_lowpart_p (op0)
+ && GET_MODE_CLASS (GET_MODE (op0)) == MODE_INT
+ && GET_MODE_CLASS (GET_MODE (SUBREG_REG (op0))) == MODE_INT
+ && (code == NE || code == EQ)
+ && (GET_MODE_PRECISION (GET_MODE (SUBREG_REG (op0)))
+ <= HOST_BITS_PER_WIDE_INT)
+ && !paradoxical_subreg_p (op0)
+ && (nonzero_bits (SUBREG_REG (op0),
+GET_MODE (SUBREG_REG (op0)))
+ & ~GET_MODE_MASK (GET_MODE (op0))) == 0)
+ {
+ tem = gen_lowpart (GET_MODE (SUBREG_REG (op0)), op1);
+
+ if ((nonzero_bits (tem, GET_MODE (SUBREG_REG (op0)))
+ & ~GET_MODE_MASK (GET_MODE (op0))) == 0)
+ {
+ op0 = SUBREG_REG (op0), op1 = tem;
+ continue;
+ }
+ break;
+ }
else
break;
[Bug tree-optimization/77824] unreachable code in SLSR GIMPLE pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77824 --- Comment #6 from Bill Schmidt --- I've done some poking around, and I see copies showing up frequently in some of GCC's own libraries, as well as in SPEC CPU2006 code. With a patched compiler to key on SSA_NAME for copies, I've seen that many of these copies are for induction variables, though not all. I have yet to find a case where handling the copies in SLSR changes the code. I'll plan to commit the obvious fix here. It doesn't seem practical to try to create a test case guaranteed to have copies in the code by the time we hit SLSR, though.
[Bug tree-optimization/71661] [7 Regression] wrong code at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71661 --- Comment #8 from Jeffrey A. Law --- Author: law Date: Thu Oct 6 16:23:22 2016 New Revision: 240836 URL: https://gcc.gnu.org/viewcvs?rev=240836&root=gcc&view=rev Log: PR tree-optimization/71661 * tree-cfgcleanup.c (remove_forwarder_block_with_phi): Handle case when removal of a forwarder exposes a new natural loop. PR tree-optimization/71661 * gcc.dg/tree-ssa/pr71661.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71661.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfgcleanup.c
[Bug target/77881] [5/6/7 Regression] Non-optimal signed comparison on x86_64 since r146817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77881 --- Comment #5 from Segher Boessenkool --- That looks good, please submit to gcc-patches?
[Bug tree-optimization/71661] [7 Regression] wrong code at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71661 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jeffrey A. Law --- Fixed with commit on trunk.
[Bug c/77883] New: ice with -Wall flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77883 Bug ID: 77883 Summary: ice with -Wall flag Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 39765 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39765&action=edit gzipped C source code The attached code, when compiled by gcc trunk revision 240826, and the flag -Wall, does this: /home/dcb/rpmbuild/BUILD/rxtx-20100211/./src/SerialImp.c: In function ‘Java_gnu_ io_RXTXCommDriver_registerKnownPorts’: /home/dcb/rpmbuild/BUILD/rxtx-20100211/./src/SerialImp.c:4608:49: internal compi ler error: in get_substring_ranges_for_loc, at input.c:1375 JNIEXPORT jboolean JNICALL RXTXCommDriver(registerKnownPorts)(JNIEnv *env, ^~ 0x14c251a get_substring_ranges_for_loc ../../trunk/gcc/input.c:1375 0x14c2bc4 get_source_location_for_substring(cpp_reader*, string_concat_db*, unsi gned int, cpp_ttype, int, int, int, unsigned int*) ../../trunk/gcc/input.c:1445 0x6ce424 c_get_substring_location(substring_loc const&, unsigned int*) ../../trunk/gcc/c-family/c-common.c:1175 0xc5e3dd substring_loc::get_location(unsigned int*) const ../../trunk/gcc/substring-locations.c:194 0xc5e3dd format_warning_va(substring_loc const&, source_range const*, char const *, int, char const*, __va_list_tag (*) [1])
[Bug c/77883] ice with -Wall flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77883 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I can't reproduce with -Wall -O.
[Bug c/77883] ice with -Wall flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77883 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Me neither.
[Bug fortran/77884] New: ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:1963
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77884 Bug ID: 77884 Summary: ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:1963 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Invalid code, affects versions 5, 6 and 7. No ICE with 4.9.0. $ cat z1.f90 program p type t end type type(t) :: x(2) call s(x) contains subroutine s(x) class(t) :: x(2)[*] end end $ cat z4.f90 program p real :: x(2) call s(x) contains subroutine s(x) class(*) :: x(2)[*] end end $ gfortran-7-20161002 -fcoarray=lib -c z1.f90 z1.f90:5:0: call s(x) internal compiler error: in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:1963 0x7597b3 gfc_get_tree_for_caf_expr(gfc_expr*) ../../gcc/fortran/trans-expr.c:1963 0x75da15 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.c:5798 0x7a4dc4 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../gcc/fortran/trans-stmt.c:407 0x7243fa trans_code ../../gcc/fortran/trans.c:1787 0x7538f8 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6257 0x6de270 translate_all_program_units ../../gcc/fortran/parse.c:5940 0x6de270 gfc_parse_file() ../../gcc/fortran/parse.c:6146 0x720e82 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:198
[Bug fortran/77884] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:1963
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77884 --- Comment #1 from Gerhard Steinmetz --- With -fcoarray=single : $ gfortran-7-20161002 -fcoarray=single -c z1.f90 z1.f90:1:0: program p Error: non-trivial conversion at assignment struct array2_t struct array1_t class.0._data = parm.1; z1.f90:1:0: internal compiler error: verify_gimple failed 0xc63abd verify_gimple_in_seq(gimple*) ../../gcc/tree-cfg.c:4876 0x9dafa2 gimplify_body(tree_node*, bool) ../../gcc/gimplify.c:12238 0x9db336 gimplify_function_tree(tree_node*) ../../gcc/gimplify.c:12326 0x843447 cgraph_node::analyze() ../../gcc/cgraphunit.c:626 0x846813 analyze_functions ../../gcc/cgraphunit.c:1087 0x847518 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2554
[Bug fortran/77885] New: ICE in gfc_add_class_array_ref, at fortran/class.c:259
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77885 Bug ID: 77885 Summary: ICE in gfc_add_class_array_ref, at fortran/class.c:259 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With invalid code, down to at least 4.8 : $ cat z1.f90 program p type t end type class(t), pointer :: x => null() call s(x) contains subroutine s(x) class(t) :: x[*] end end $ /home/gst/gcc/gcc-7-20161002-oyd/bin/gfortran -fcoarray=single z1.f90 z1.f90:5:0: call s(x) internal compiler error: Segmentation fault 0xc29b8f crash_signal ../../gcc/toplev.c:337 0x670cfb gfc_add_class_array_ref(gfc_expr*) ../../gcc/fortran/class.c:259 0x761362 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.c:5087 0x7a4dc4 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../gcc/fortran/trans-stmt.c:407 0x7243fa trans_code ../../gcc/fortran/trans.c:1787 0x7538f8 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6257 0x6de270 translate_all_program_units ../../gcc/fortran/parse.c:5940 0x6de270 gfc_parse_file() ../../gcc/fortran/parse.c:6146 0x720e82 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:198
[Bug target/77874] two problems with gcc.target/i386/avx-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77874 --- Comment #3 from uros at gcc dot gnu.org --- Author: uros Date: Thu Oct 6 17:53:15 2016 New Revision: 240837 URL: https://gcc.gnu.org/viewcvs?rev=240837&root=gcc&view=rev Log: PR target/77874 * config/i386/sse.md (3): Remove wrong assert. (float2: Use as operand 1 constraint. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/i386/sse.md
[Bug c/77886] New: -Wimplicit-fallthrough: breaks duff's device
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77886
Bug ID: 77886
Summary: -Wimplicit-fallthrough: breaks duff's device
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: marc.mutz at kdab dot com
Target Milestone: ---
The recent addition (or activation) of -Wimplicit-fallthrough breaks Duff's
Device:
int n = (count + 7) / 8;
switch (count & 0x07)
{
case 0: do { *dest++ = value;
case 7: *dest++ = value;
case 6: *dest++ = value;
case 5: *dest++ = value;
case 4: *dest++ = value;
case 3: *dest++ = value;
case 2: *dest++ = value;
case 1: *dest++ = value;
} while (--n > 0);
}
adding all those pesky // fall through comments makes the code unreadable, the
more so as GCC doesn"t accept it as a trailing comment after each line but
insists on having it on a line of its own.
[Bug target/77874] two problems with gcc.target/i386/avx-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77874 --- Comment #4 from uros at gcc dot gnu.org --- Author: uros Date: Thu Oct 6 17:55:20 2016 New Revision: 240838 URL: https://gcc.gnu.org/viewcvs?rev=240838&root=gcc&view=rev Log: PR target/77874 * config/i386/sse.md (3): Remove wrong assert. (float2: Use as operand 1 constraint. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/i386/sse.md
[Bug target/77874] two problems with gcc.target/i386/avx-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77874 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.5 --- Comment #5 from Uroš Bizjak --- Fixed everywhere.
[Bug c/77886] -Wimplicit-fallthrough: breaks duff's device
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77886 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I think either a diagnostics pragma or a special new attribute appertaining to a switch statement could "fix" this.
[Bug c/77886] -Wimplicit-fallthrough: breaks duff's device
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77886
--- Comment #2 from Marc Mutz ---
It's worse than I thought:
int n = (count + 7) / 8;
switch (count & 0x07)
{
case 0: do { *dest++ = value;
// fall through
case 7: *dest++ = value;
// fall through
case 6: *dest++ = value;
// fall through
case 5: *dest++ = value;
// fall through
case 4: *dest++ = value;
// fall through
case 3: *dest++ = value;
// fall through
case 2: *dest++ = value;
// fall through
case 1: *dest++ = value;
} while (--n > 0);
}
still warns.
The only way to avoid the warning is to use [[fallthrough]] at the end of each
line.
[Bug c++/77887] New: -Wimplicit-fallthrough fails to trigger in an unused function template specialisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77887
Bug ID: 77887
Summary: -Wimplicit-fallthrough fails to trigger in an unused
function template specialisation
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marc.mutz at kdab dot com
Target Milestone: ---
I have a switch statement here that -Wimplicit-fallthrough fails to warn about:
template <>
inline void qt_memfill_template(quint16 *dest, quint16 value, int count)
{
if (count < 3) {
switch (count) {
case 2: *dest++ = value;
// fall through<-- absence is not detected
case 1: *dest = value;
}
return;
}
// ...
This specialisation ends up not being instantiated, but I'd expect a warning
from a full specialisation nonetheless.
Hmm. If I change from specialisation to overloading (ie. to a non-template),
the switch still doesn't trigger.
I thought the warning was generated by the front-end, but it seems it'd
generated by the backend instead, after dead code elimination...?
[Bug tree-optimization/77862] [7 Regression] ice in add_equivalence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77862 --- Comment #5 from kugan at gcc dot gnu.org --- Author: kugan Date: Thu Oct 6 19:58:46 2016 New Revision: 240842 URL: https://gcc.gnu.org/viewcvs?rev=240842&root=gcc&view=rev Log: Fix PR77862 gcc/testsuite/ChangeLog: 2016-10-06 Kugan Vivekanandarajah PR tree-optimization/77862 * gcc.dg/pr77862.c: New test. gcc/ChangeLog: 2016-10-06 Kugan Vivekanandarajah PR tree-optimization/77862 * tree-vrp.c (add_equivalence): Use get_value_range so that num_vr_values is checked before accessing vr_values. Added: trunk/gcc/testsuite/gcc.dg/pr77862.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug c/77886] -Wimplicit-fallthrough: breaks duff's device
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77886
--- Comment #3 from Marc Mutz ---
Here's another example of a switch where I can't silence the warning, except by
C++11 attribute:
switch (i & 7) {
case 7: blender.write(line, reinterpret_cast(reinterpret_cast(srcPixels) + (v >> 16) * sbpl)[u >> 16]); u
+= dudx; v += dvdx; ++line;
case 6: blender.write(line, reinterpret_cast(reinterpret_cast(srcPixels) + (v >> 16) * sbpl)[u >> 16]); u
+= dudx; v += dvdx; ++line;
case 5: blender.write(line, reinterpret_cast(reinterpret_cast(srcPixels) + (v >> 16) * sbpl)[u >> 16]); u
+= dudx; v += dvdx; ++line;
case 4: blender.write(line, reinterpret_cast(reinterpret_cast(srcPixels) + (v >> 16) * sbpl)[u >> 16]); u
+= dudx; v += dvdx; ++line;
case 3: blender.write(line, reinterpret_cast(reinterpret_cast(srcPixels) + (v >> 16) * sbpl)[u >> 16]); u
+= dudx; v += dvdx; ++line;
case 2: blender.write(line, reinterpret_cast(reinterpret_cast(srcPixels) + (v >> 16) * sbpl)[u >> 16]); u
+= dudx; v += dvdx; ++line;
case 1: blender.write(line, reinterpret_cast(reinterpret_cast(srcPixels) + (v >> 16) * sbpl)[u >> 16]); u
+= dudx; v += dvdx; ++line;
}
[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #29 from Eric Gallager --- I tried testing this patchset on i386-apple-darwin9.8.0, but I think something went wrong with the parallelism in the testsuite (I did `make -j2 check-gcc RUNTESTFLAGS="-v -v"`), and I ended up having to restart my computer... but anyways, the results are here: https://gcc.gnu.org/ml/gcc-testresults/2016-10/msg00537.html I think the failures are mostly unrelated...
[Bug c++/77887] -Wimplicit-fallthrough fails to trigger in an unused function template specialisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77887 --- Comment #1 from Jonathan Wakely --- Complete testcase please. (In reply to Marc Mutz from comment #0) > This specialisation ends up not being instantiated, but I'd expect a warning > from a full specialisation nonetheless. This is the case for *loads* of warnings. GCC doesn't do very much with uninstantiated templates. > Hmm. If I change from specialisation to overloading (ie. to a non-template), > the switch still doesn't trigger. Probably because it's inline.
[Bug c/77888] New: Missing -Wparentheses diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77888
Bug ID: 77888
Summary: Missing -Wparentheses diagnostic
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.sm...@alcatel-lucent.com
Target Milestone: ---
int main(void)
{
int zone = 5;
int MinChassisFanZoneNum = 4;
int MaxChassisFanZoneNum = 10;
# if 0
for (int i = (zone?zone:MinChassisFanZoneNum); i <=
(zone?zone:MaxChassisFanZoneNum); i++)
return i;
#else
for (int i = zone?zone:MinChassisFanZoneNum; i <=
zone?zone:MaxChassisFanZoneNum; i++)
return i;
#endif
}
The missing parentheses result in an infinite loop when compiled at O2.
[Bug c/77888] Missing -Wparentheses diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77888
--- Comment #1 from Andrew Pinski ---
Rather it is just this testcase:
bool f(int i, int zone, int MaxChassisFanZoneNum)
{
if (i <= zone?zone:MaxChassisFanZoneNum)
return 1;
return 0;
}
[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767 --- Comment #30 from Iain Sandoe --- (In reply to Eric Gallager from comment #29) > I tried testing this patchset on i386-apple-darwin9.8.0, thanks! - I got reasonable results on ppc-d9 with both ld64-85.2 and ld64-253.9 > but I think > something went wrong with the parallelism in the testsuite (I did `make -j2 > check-gcc RUNTESTFLAGS="-v -v"`), you probably need a"-k" in there too ... (and the -v -v is a bit excessive for running the whole suite, best used if you need to chase a test suite problem with a small set of tests). I'm going to rebase and post the patches
[Bug middle-end/77889] New: missing optimization on strlen(p + offset) with a bounded offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77889
Bug ID: 77889
Summary: missing optimization on strlen(p + offset) with a
bounded offset
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
While testing my patch for bug 77608 I noticed another case of the same
limitation, this one in the tree-ssa-strlen pass. The test case below shows
that while (with my patch) __builtin_object_size is able to compute the range
the smallest sizes of the string that p points to (i.e., either 2 or 3 bytes),
__builtin_strlen is not able to compute the range of lengths of the string that
p points to, even though the range of the offsets into the string is available
via the get_range_info function. (The test cases uses _Bool only to constrain
the range to small bounds; the problem is general and not specific to a
particular type of the offset variable.)
$ cat rng.c && /build/gcc-77608/gcc/xgcc -B /build/gcc-77608/gcc -O2 -S -Wall
-Wextra -Wpedantic -fdump-tree-vrp=/dev/stdout rng.c
void f (_Bool i)
{
const char *p = "abc";
p += i;
unsigned long n = __builtin_strlen (p);
if (n < 2 || 3 < n)
__builtin_abort ();
}
void g (_Bool i)
{
const char *p = "ab";
p += i;
unsigned long n = __builtin_object_size (p, 2);
if (n < 2 || 3 < n)
__builtin_abort ();
}
;; Function f (f, funcdef_no=0, decl_uid=1791, cgraph_uid=0, symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4
;; 2 succs { 3 4 }
;; 3 succs { }
;; 4 succs { 1 }
Value ranges after VRP:
_1: [0, 1]
_2: [0, +INF]
i_3(D): VARYING
p_4: VARYING
n_6: VARYING
f (_Bool i)
{
long unsigned int n;
const char * p;
sizetype _1;
long unsigned int _2;
:
_1 = (sizetype) i_3(D);
p_4 = "abc" + _1;
n_6 = __builtin_strlen (p_4);
_2 = n_6 + 18446744073709551614;
if (_2 > 1)
goto ;
else
goto ;
:
__builtin_abort ();
:
return;
}
;; Function f (f, funcdef_no=0, decl_uid=1791, cgraph_uid=0, symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4
;; 2 succs { 3 4 }
;; 3 succs { }
;; 4 succs { 1 }
Value ranges after VRP:
_1: [0, 1]
_2: [0, +INF]
i_3(D): VARYING
p_4: VARYING
n_6: VARYING
f (_Bool i)
{
long unsigned int n;
const char * p;
sizetype _1;
long unsigned int _2;
:
_1 = (sizetype) i_3(D);
p_4 = "abc" + _1;
n_6 = __builtin_strlen (p_4);
_2 = n_6 + 18446744073709551614;
if (_2 > 1)
goto ;
else
goto ;
:
__builtin_abort ();
:
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1796, cgraph_uid=1, symbol_order=1)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
Value ranges after VRP:
_1: [0, 1]
i_3(D): VARYING
p_4: VARYING
n_6: VARYING
g (_Bool i)
{
long unsigned int n;
const char * p;
sizetype _1;
:
_1 = (sizetype) i_3(D);
p_4 = "ab" + _1;
n_6 = __builtin_object_size (p_4, 2);
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1796, cgraph_uid=1, symbol_order=1)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
Value ranges after VRP:
g (_Bool i)
{
long unsigned int n;
const char * p;
:
return;
}
[Bug middle-end/77889] missing optimization on strlen(p + offset) with a bounded offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77889 Martin Sebor changed: What|Removed |Added Keywords||missed-optimization See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=63989 --- Comment #1 from Martin Sebor --- Bug 63989 is somewhat related but limited to constant offsets.
[Bug c++/77890] New: class template type deduction fails for lambda functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77890
Bug ID: 77890
Summary: class template type deduction fails for lambda
functions
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jeff.mirwaisi at gmail dot com
Target Milestone: ---
//error: 'S(F&&)-> S [with F = main(int, char**)::]', declared
using local
//type 'main(int, char**)::', is used but never defined
template struct S{S(F&&f){}};
int main()
{
S([]{});
}
//explicit deduction via a helper function works as expected
template struct S{S(F&&f){}};
template auto H(F&& f){return S(forward(f));}
int main()
{
H([]{});
}
[Bug fortran/57910] ICE (segfault) with deferred-length strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57910 --- Comment #2 from lkrupp at gcc dot gnu.org --- Author: lkrupp Date: Fri Oct 7 02:02:13 2016 New Revision: 240850 URL: https://gcc.gnu.org/viewcvs?rev=240850&root=gcc&view=rev Log: 2016_10-06 Louis Krupp PR fortran/57910 * gfortran.dg/pr57910.f90: New test. 2016-10-05 Louis Krupp PR fortran/57910 * trans-expr.c (gfc_add_interface_mapping): Don't try to dereference call-by-value scalar argument Added: trunk/gcc/testsuite/gfortran.dg/pr57910.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/45170] [F2003] allocatable character lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Bug 45170 depends on bug 57910, which changed state. Bug 57910 Summary: ICE (segfault) with deferred-length strings https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57910 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/68241] [meta-bug] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 57910, which changed state. Bug 57910 Summary: ICE (segfault) with deferred-length strings https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57910 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/57910] ICE (segfault) with deferred-length strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57910 lkrupp at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||lkrupp at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from lkrupp at gcc dot gnu.org --- Fixed in revision 240850.
[Bug fortran/69955] Memory leak with array constructor and derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69955 lkrupp at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||lkrupp at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from lkrupp at gcc dot gnu.org --- Fixed in revision 240851.
[Bug fortran/68800] Fortran FE produces many memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68800 Bug 68800 depends on bug 69955, which changed state. Bug 69955 Summary: Memory leak with array constructor and derived type https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69955 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/69955] Memory leak with array constructor and derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69955 --- Comment #5 from lkrupp at gcc dot gnu.org --- Author: lkrupp Date: Fri Oct 7 02:24:40 2016 New Revision: 240851 URL: https://gcc.gnu.org/viewcvs?rev=240851&root=gcc&view=rev Log: 2016-10-06 Louis Krupp * gfortran.dg/pr69955.f90: New test. 2016-10-06 Louis Krupp PR fortran/69955 * trans-array.c (gfc_conv_expr_descriptor): Don't allocate components if it's not necessary. Added: trunk/gcc/testsuite/gfortran.dg/pr69955.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/77891] New: Signed overflow sanitizer doesn't catch multiplication overflows due to promotion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77891
Bug ID: 77891
Summary: Signed overflow sanitizer doesn't catch multiplication
overflows due to promotion
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: myriachan at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
-fsanitize=signed-integer-overflow doesn't catch multiplication overflows that
occur in signed types due to promotion rules. This can happen when you use an
unsigned type that is exactly half the width of "signed int". That's usually
"unsigned short".
The following should generate two runtime errors when compiled with
-fsanitize=signed-integer-overflow, but instead only one error occurs:
#include
int main()
{
std::printf("unsigned short\n");
std::fflush(stdout);
unsigned short x = 65535;
x *= x;
std::printf("signed int\n");
std::fflush(stdout);
signed int y = 65535;
y *= y;
return 0;
}
myria@machine:~/tests$ g++ -m64 -std=gnu++11 -Wstrict-overflow -ftrapv
-fstrict-overflow -fsanitize=signed-integer-overflow overflow.cpp -lpthread
-ldl -o overflow64
myria@machine:~/tests$ ./overflow64
unsigned short
signed int
overflow.cpp:13:15: runtime error: signed integer overflow: 65535 * 65535
cannot be represented in type 'int'
Clang does pick up the overflow, though:
myria@machine:~/tests$ clang++-3.8 -m64 -std=gnu++11 -stdlib=libc++
-fsanitize=signed-integer-overflow overflow.cpp -o overflow64
myria@machine:~/tests$ ./overflow64
unsigned short
overflow.cpp:8:11: runtime error: signed integer overflow: 65535 * 65535 cannot
be represented in type 'int'
signed int
overflow.cpp:13:11: runtime error: signed integer overflow: 65535 * 65535
cannot be represented in type 'int'
[Bug c++/77892] New: local function declarations don't match namespace scope declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77892
Bug ID: 77892
Summary: local function declarations don't match namespace
scope declarations
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jeff.mirwaisi at gmail dot com
Target Milestone: ---
//error: undefined reference to 'f()'
struct S{friend void f(){}}; //lexical scope of S, only discoverable via ADL,
no
//argument, so not discoverable at all yet
void f(); //make f visible to ordinary qualified lookup
int main()
{
void f(); //declaration should match the declaration at namespace scope,
instead
//hides the previous declaration at namespace scope
f();
}
//open question whether a local scope declaration is enough to make a class
scope
//friend function visible to ordinary lookup
//works in clang not in gcc
struct S{friend void f(){}};
int main()
{
void f();
f();
}
[Bug sanitizer/77891] Signed overflow sanitizer doesn't catch multiplication overflows due to promotion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77891 --- Comment #1 from Andrew Pinski --- Convert.c comes into play again.
[Bug fortran/67073] short program produces ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67073 Gerhard Steinmetz changed: What|Removed |Added CC||gerhard.steinmetz.fortran@t ||-online.de --- Comment #2 from Gerhard Steinmetz --- Please let me add a (new) backtrace, analogous to pr70696 comment 3 : $ gfortran-7-20161002 -fcoarray=lib -c pr67073_c1.f90 pr67073_c1.f90:6:0: lock (lock2) internal compiler error: in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:1909 0x759923 gfc_get_tree_for_caf_expr(gfc_expr*) ../../gcc/fortran/trans-expr.c:1909 0x7a73f7 gfc_trans_lock_unlock(gfc_code*, gfc_exec_op) ../../gcc/fortran/trans-stmt.c:715 0x723fe7 trans_code ../../gcc/fortran/trans.c:1853 0x7538f8 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6257 0x753747 gfc_generate_contained_functions ../../gcc/fortran/trans-decl.c:5237 0x753747 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6186 0x6de270 translate_all_program_units ../../gcc/fortran/parse.c:5940 0x6de270 gfc_parse_file() ../../gcc/fortran/parse.c:6146 0x720e82 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:198
[Bug fortran/70696] [6.0] ICE on EVENT POST of host-associated EVENT_TYPE coarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70696 Gerhard Steinmetz changed: What|Removed |Added CC||gerhard.steinmetz.fortran@t ||-online.de --- Comment #3 from Gerhard Steinmetz --- Please let me add a (new) backtrace, analogous to pr67073 comment 2 : $ gfortran-7-20161002 -fcoarray=lib -c pr70696.f90 pr70696.f90:6:0: event post(x[1]) internal compiler error: in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:1909 0x759923 gfc_get_tree_for_caf_expr(gfc_expr*) ../../gcc/fortran/trans-expr.c:1909 0x7a7cf9 gfc_trans_event_post_wait(gfc_code*, gfc_exec_op) ../../gcc/fortran/trans-stmt.c:912 0x723f57 trans_code ../../gcc/fortran/trans.c:1858 0x7538f8 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6257 0x753747 gfc_generate_contained_functions ../../gcc/fortran/trans-decl.c:5237 0x753747 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6186 0x6de270 translate_all_program_units ../../gcc/fortran/parse.c:5940 0x6de270 gfc_parse_file() ../../gcc/fortran/parse.c:6146 0x720e82 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:198
