[Bug tree-optimization/67607] New: Failure to perform constant folding through type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67607
Bug ID: 67607
Summary: Failure to perform constant folding through type
conversion
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: miyuki at gcc dot gnu.org
Target Milestone: ---
This code is taken from PR67606:
$ cat pr67606.c
int f(int a[], int length)
{
int count=0;
for (int i = 0 ; i < length ; i++)
if (a[i] > 5)
count++;
return count;
}
$ g++ -S -O3 -fno-tree-vectorize pr67606.c -fverbose-asm -fdump-tree-optimized
We get:
:
ivtmp.6_1 = (unsigned long) a_7(D);
_19 = (unsigned int) length_4(D);
_18 = _19 + 4294967295;
_21 = (sizetype) _18;
_22 = _21 + 1;
_23 = _22 * 4;
_24 = a_7(D) + _23;
_25 = (unsigned long) _24;
And this leads to generating some redundant code:
leal-1(%rsi), %eax #, tmp114
leaq4(%rdi,%rax,4), %rcx#, tmp111
[Bug middle-end/67606] Missing optimization: load possible return value before early-out test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67606 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-17 CC||matz at gcc dot gnu.org Component|c |middle-end Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- So for the main part of this PR we actually expand from : # count_16 = PHI return count_16; so it is a matter of coalescing and where we put that copy from zero. We coalesce the following way: Coalesce list: (1)count_1 & (15)count_15 [map: 0, 7] : Success -> 0 Coalesce list: (3)ivtmp.6_3 & (13)ivtmp.6_13 [map: 2, 6] : Success -> 2 Coalesce list: (1)count_1 & (11)count_11 [map: 0, 5] : Success -> 0 Coalesce list: (1)count_1 & (16)count_16 [map: 0, 8] : Success -> 0 Coalesce list: (2)ivtmp.6_2 & (13)ivtmp.6_3 [map: 1, 2] : Success -> 2 so 'count' is fully coalesced but of course the constant is still there and we insert a copy on the 2->7 edge. Inserting a value copy on edge BB3->BB4 : PART.0 = 0 Inserting a value copy on edge BB2->BB7 : PART.0 = 0 which also looks good (we use the correct partition for this). Note that the zero init isn't partially redundant so GCSE isn't able to optimize here and RTL code hoisting isn't very advanced. I'm also sure the RA guys will say it's not the RAs job of doing the hoisting. So with my usual GIMPLE hat on I'd say it would have been nice to help things by placing the value copy more intelligently. We have a pass that is supposed to help here - uncprop. We're faced with : if (length_4(D) > 0) goto ; else goto ; : ... : # count_15 = PHI <0(3), count_1(6)> ... : # count_1 = PHI ivtmp.6_3 = ivtmp.6_13 + 4; if (ivtmp.6_3 != _25) goto ; else goto ; : # count_16 = PHI return count_16; which might be a good enough pattern to detect (slight complication with the forwarder BB3). Note that we'd increase register pressure throughout BB3 and that for the whole thing to work we'd still need to be able to make sure we can coalesce all of count and the register we init with zero. Given the interaction with coalescing I wonder whether it makes sense to do "uncprop" together with coalescing or to make emitting and placing value-copies work on GIMPLE, exposing the partitions explicitely somehow. Well, trying to improve uncprop for this particular testcase would work and shouldn't be too hard (you'd extend it from detecting edge equivalencies to existing vargs to do PHI value hoisting). There is also other code trying to improve coalescing - rewrite_out_of_ssa has insert_backedge_copies so we could also detect the pattern here and insert copies from the common constant in the common dominator.
[Bug tree-optimization/67607] Failure to perform constant folding through type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67607 --- Comment #1 from Marc Glisse --- In general, for unsigned x, 1+(unsigned long)(x-1) can be simplified to x only if we know that x!=0, so we would need VRP information. Maybe this could be handled as part of the type-promotion work. VRP could tell that _21+1 can be computed in type unsigned int, and swap the operation and the conversion. Or it could tell that _19-1 can be computed in type unsigned long, it doesn't matter much which one it picks. The simplification -1+1 would then be trivial. Last idea would be to try and avoid generating so many +1 and -1 in the first place.
[Bug tree-optimization/67607] Failure to perform constant folding through type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67607 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-17 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- so this is ((unsigned long)((unsigned int) length_4(D) - 1U) + 1) you can't optimize this to (unsigned long) length_4(D) as for length_4 == 0 the result is 0x1. So what's the missed constant folding? Ah, so the above is guarded with if (length_4(D) > 0) which means we fail to optimize this to (unsigned long)length_4(D) because we don't consider this transform might be valid when taking into account range-info. # RANGE [1, 2147483647] NONZERO 2147483647 _19 = (unsigned int) length_4(D); # RANGE [0, 2147483646] NONZERO 2147483647 _18 = _19 + 4294967295; # RANGE [0, 2147483646] NONZERO 2147483647 _21 = (sizetype) _18; # RANGE [1, 2147483647] NONZERO 2147483647 _22 = _21 + 1; so here VRP could for example have promoted _19 and _18 to sizetype. Or it could handle the arithmetic simplification itself. We'd like to handle (T)(X +- CST1) +- CST1 generally here (both widening/shortening casts).
[Bug rtl-optimization/50749] Auto-inc-dec does not find subsequent contiguous mem accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
Urja Rannikko changed:
What|Removed |Added
CC||urjaman at gmail dot com
--- Comment #20 from Urja Rannikko ---
I'll add a note here that this seems to also affect the AVR target when it is
under register pressure and cant use Z or Y registers which can do Z+n /Y+n
addressing, it ends up doing really stupid things with X register (aka r26:r27)
(which could post-inc):
adiwr26, 0x01
ld r24, X
sbiwr26, 0x01
(followed by adiw r26, 2...)
This was my test case for showing this behaviour on AVR:
unsigned char test_0 (unsigned char* p1, unsigned char *p2, unsigned char *p3)
{
unsigned char r = 0;
r += *p1++;
r += *p2++;
r += *p3++;
r += *p1++;
r += *p2++;
r += *p3++;
r += *p1++;
r += *p2++;
r += *p3++;
return r;
}
This note added for anyone later trying to google for this after seeing that X
reg stupidity on AVR, sorry for maybe-a-bit-noise ...
[Bug fortran/52846] [F2008] Support submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846 --- Comment #27 from Paul Thomas --- Author: pault Date: Thu Sep 17 09:09:34 2015 New Revision: 227855 URL: https://gcc.gnu.org/viewcvs?rev=227855&root=gcc&view=rev Log: 2015-09-17 Paul Thomas PR fortran/52846 PR fortran/67588 * module.c : Add static no_module_procedures. (gfc_match_submodule): Correct memory leakage caused during the freeing of use_lists. (mio_symbol_attribute): Reset above if module procedure is encountered. (gfc_dump_module): Set above and exit without writing smod file if it reset. * gfortran.texi : Add section on submodule support. 2015-09-17 Paul Thomas PR fortran/52846 * gfortran.dg/public_private_module_5.f90: Add module procedure trigger_smod to ensure that the smod file is written. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/submodule_5.f08
[Bug fortran/67588] module.c heap use after free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67588 --- Comment #3 from Paul Thomas --- Author: pault Date: Thu Sep 17 09:09:34 2015 New Revision: 227855 URL: https://gcc.gnu.org/viewcvs?rev=227855&root=gcc&view=rev Log: 2015-09-17 Paul Thomas PR fortran/52846 PR fortran/67588 * module.c : Add static no_module_procedures. (gfc_match_submodule): Correct memory leakage caused during the freeing of use_lists. (mio_symbol_attribute): Reset above if module procedure is encountered. (gfc_dump_module): Set above and exit without writing smod file if it reset. * gfortran.texi : Add section on submodule support. 2015-09-17 Paul Thomas PR fortran/52846 * gfortran.dg/public_private_module_5.f90: Add module procedure trigger_smod to ensure that the smod file is written. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/submodule_5.f08
[Bug fortran/67588] module.c heap use after free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67588 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Paul Thomas --- Fixed on trunk. Vittorio, Many thanks for both the report and the fix! Steve, Thanks for bringing the PR to my attention. Cheers Paul
[Bug bootstrap/67597] [6 Regression] profiledbootstrap failure on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67597 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #4 from Alexandre Oliva --- Mine. AFAICT this is fixed in the git branch aoliva/pr64164, that moves rtl allocation of parms and results back to assign_parms.
[Bug fortran/67588] module.c heap use after free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67588 --- Comment #5 from Vittorio Zecca --- I believe that use_list = module_list; at line module.c:805 is useless and can be expunged.
[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 Eric Botcazou changed: What|Removed |Added CC||bonzini at gnu dot org, ||zadeck at naturalbridge dot com --- Comment #17 from Eric Botcazou --- > So I think there's three things to solve > - which problem should df_live be using, the one it says it's using or the > one it actually does > - if it's the former, see if passes using the information need fixing > - if it's the latter and we need the new problem from this patch, ensure > that it actually works correctly (initializing the out bitmaps to all ones, > probably). That sounds like a good plan. On second thoughts, for the first point, maybe a native speaker understands "an available definition on any path" as "an available definition on one path, whatever it is", in which case the description would be correct, albeit very confusing for non-native speakers. It would be good to have some insight from the DF maintainers here (CCed). In any case, what's needed to fix the bug is "an available definition on every path" and that's what Pierre-Marie's patch implements. We're going to review it in light of your remarks.
[Bug c++/67608] New: ICE when capturing a local 2D array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67608
Bug ID: 67608
Summary: ICE when capturing a local 2D array
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: linesprower at gmail dot com
Target Milestone: ---
// command line: g++ -std=c++11 error.cpp
//
// compiler version: 4.9.2 (Ubuntu 14.04)
//
// compiler output:
// error.cpp: In lambda function:
// error.cpp:10:21: internal compiler error: in expand_expr_real_1, at
expr.c:9454
//seen[r][c] = true;
// ^
class Test
{
const int k = 50;
public:
void test()
{
bool seen[k][k];
auto trace = [&](int r, int c)
{
seen[r][c] = true;
};
trace(5, 5);
}
};
int main()
{
Test t;
t.test();
return 0;
}
[Bug c++/67608] ICE when capturing a local 2D array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67608 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-17 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.4 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- ICEs since 4.7.
[Bug fortran/67588] module.c heap use after free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67588 --- Comment #6 from Paul Thomas --- (In reply to Vittorio Zecca from comment #5) > I believe that > > use_list = module_list; > > at line module.c:805 is useless and can be expunged. I don't think so Up to that point, use_list is set to point to the end of the module_list by line 760. It then has to be initialized for the loop at 806. Cheers Paul
[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #18 from Bernd Schmidt --- FWIW I did some googling to refresh my memory, and this may be helpful: www.seas.harvard.edu/courses/cs252/2011sp/slides/Lec02-Dataflow.pdf It looks like you want exactly the available expressions problem from page 26. Maybe that's better terminology than must-initialized? (I'm not sure, but I'd never heard the latter term before.) I think I'm coming to the conclusion that df_live really does want what it currently uses, which is the guarantee that there is _any_ def that reaches a use. The commentary could use updating though, I think it clearly isn't computing a "must" problem. When updating the patch please ensure that all new parameters are documented before the function.
[Bug bootstrap/67597] [6 Regression] profiledbootstrap failure on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67597 --- Comment #5 from Markus Trippelsdorf --- (In reply to Alexandre Oliva from comment #4) > Mine. AFAICT this is fixed in the git branch aoliva/pr64164, that moves rtl > allocation of parms and results back to assign_parms. Thanks. I can confirm that aoliva/pr64164 branch fixes the issue.
[Bug middle-end/67490] [6 regression] FAIL: gcc.target/powerpc/pr16458-1.c scan-assembler-not cmpw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67490 Alexandre Oliva changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-09-17 Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Alexandre Oliva --- Mine. Thanks, I've just fixed this in the aoliva/pr64164 branch. The problem was that we no longer generated declarations for anonymous SSA names, and this in turn broke reg_unsigned_p that rs6000's cbranch relied on to decide whether to emit signed or unsigned compares. I'm trying to add types to MEM attrs and the SSA names to REG attrs, so that we can recover the type information. Let's see how that goes...
[Bug middle-end/65958] -fstack-check breaks alloca on architectures using generic stack checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65958 --- Comment #5 from Eric Botcazou --- Author: ebotcazou Date: Thu Sep 17 11:06:57 2015 New Revision: 227860 URL: https://gcc.gnu.org/viewcvs?rev=227860&root=gcc&view=rev Log: PR middle-end/65958 * config/arm/linux-elf.h (STACK_CHECK_STATIC_BUILTIN): Define. * config/arm/arm-protos.h (output_probe_stack_range): Declare. * config/arm/arm.c: Include common/common-target.h. (use_return_insn): Return 0 if the static chain register was saved above a non-APCS frame. (arm_compute_static_chain_stack_bytes): Adjust for stack checking. (struct scratch_reg): New. (get_scratch_register_on_entry): New function. (release_scratch_register_on_entry): Likewise. (arm_emit_probe_stack_range): Likewise. (output_probe_stack_range): Likewise. (arm_expand_prologue): Factor out code dealing with the IP register for nested function and adjust it for stack checking. Invoke arm_emit_probe_stack_range if static builtin stack checking is enabled. (thumb1_expand_prologue): Sorry out if static builtin stack checking is enabled. (arm_expand_epilogue): Add the saved static chain register, if any, to the amount of pre-pushed registers to pop. (arm_frame_pointer_required): Return true if static stack checking is enabled and we want to catch the exception with the EABI unwinder. * config/arm/unspecs.md (UNSPEC_PROBE_STACK): New constant. (UNSPEC_PROBE_STACK_RANGE): Likewise. * config/arm/arm.md (probe_stack): New insn. (probe_stack_range): Likewise. Added: trunk/gcc/testsuite/gcc.target/arm/stack-checking.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-protos.h trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.md trunk/gcc/config/arm/linux-elf.h trunk/gcc/config/arm/unspecs.md trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/67351] Missed optimisation on 64-bit field compared to 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67351 Allan Jensen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Allan Jensen --- With a recent gcc 6 this example appears perfectly optimized: Disassembly of section .text: <_Z4testv>: 0: 48 83 ec 08 sub$0x8,%rsp 4: e8 00 00 00 00 callq 9 <_Z4testv+0x9> 9: 25 ff ff 00 ff and$0xff00,%eax e: 48 83 c4 08 add$0x8,%rsp 12: 0d 00 00 f0 00 or $0xf0,%eax 17: c3 retq 18: 0f 1f 84 00 00 00 00nopl 0x0(%rax,%rax,1) 1f: 00 0020 <_Z6test64v>: 20: 48 83 ec 08 sub$0x8,%rsp 24: e8 00 00 00 00 callq 29 <_Z6test64v+0x9> 29: 48 ba ff ff ff ff 00movabs $0x,%rdx 30: 00 ff ff 33: 48 83 c4 08 add$0x8,%rsp 37: 48 21 d0and%rdx,%rax 3a: 48 ba 00 00 00 00 f0movabs $0xf0f0,%rdx 41: f0 00 00 44: 48 09 d0or %rdx,%rax 47: c3 retq
[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #19 from Paolo Bonzini --- LIVE provides live registers that MAY be initialized (are initialized on at least one path). The comments are all wrong! There's no code in GCC for must-initialized. Pierre's patch gets it right (except that I'm not sure about the comment at line 2033). The MIR name can indeed add to the confusion about may/must. Perhaps valid registers (VR)? Note that this is not the available expressions problem. The confluence function is the same, but it operates on registers and not on expressions. The gen and kill sets are different, too. I wouldn't be surprised if you don't find it in the literature, since it's a relatively obvious extension of the usual dataflow problems. I think this issue can also be fixed easily with an approximated solution, which is already used for example by combine's set_nonzero_bits_and_sign_copies. If a register is undefined at the start of the function, you punt because the register has uninitialized uses. This is suboptimal if you have cases like: int y, x; x = y; /* uninitialized */ ... y = 5; ... x = y; /* initialized */ but they should be pretty rare.
[Bug regression/67609] New: [Regression] Generates wrong code for SSE2 _mm_load_pd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609
Bug ID: 67609
Summary: [Regression] Generates wrong code for SSE2 _mm_load_pd
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
For this program (needs -msse2 to compile).
#include
__m128d reg;
void set_lower(double b)
{
double v[2];
_mm_store_pd(v, reg);
v[0] = b;
reg = _mm_load_pd(v);
}
On optimization levels -O1 and up, GCC 5.2 incorrectly generates code that
destroys the upper half of reg.
movapd %xmm0, %xmm1
movaps %xmm1, reg(%rip)
On -O0, the bug does not occur.
If the index expression is changed into an expression whose value is not known
at compile-time, the code will work properly.
GCC 4.9 does this correctly (if with bit too much labor):
movdqa reg(%rip), %xmm1
movaps %xmm1, -24(%rsp)
movsd %xmm0, -24(%rsp)
movapd -24(%rsp), %xmm2
movaps %xmm2, reg(%rip)
For comparison, Clang 3.4 and 3.5:
movlpd %xmm0, reg(%rip)
For comparison, Clang 3.6:
movaps reg(%rip), %xmm1
movsd %xmm0, %xmm1
movaps %xmm1, reg(%rip)
[Bug tree-optimization/67351] Missed optimisation on 64-bit field compared to 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67351 Uroš Bizjak changed: What|Removed |Added Target Milestone|--- |6.0
[Bug regression/67609] [Regression] Generates wrong code for SSE2 _mm_load_pd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609 --- Comment #1 from Joel Yliluoma --- For the record, changing _mm_load_pd(v) into _mm_set_pd(v[1],v[0]) will coax GCC into generating correct code. The bug is related to _mm_load_pd().
[Bug testsuite/66530] libstdc++ testsuite links to incorrect shared libstdc++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66530 --- Comment #8 from Jennifer Yao --- I know this is horribly belated, but I *just* got around to testing the patch proper, and I'm afraid to say that it does not appear to work. (My last comment verified that setting PATH instead of LD_LIBRARY_PATH worked on Cygwin using a separate test program. I did not test the patch then.)
[Bug tree-optimization/66142] Loop is not vectorized because not sufficient support for GOMP_SIMD_LANE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66142
--- Comment #21 from Richard Biener ---
Ok, so if we fix SCCVN further we hit its (designed) limitation with stmt
walking not following backedges (but the use is in a loop and the def outside).
We avoid doing the work to determine if sth is loop invariant here.
This was trying to improve things with SRA disabled - I'm going to still push
those changes if testing works out fine.
Now with SRA enabled we have a better situation in this regard but face
_9 = &D.4309[_12].org;
MEM[(struct vec_ *)_9] = 1.0e+0;
MEM[(struct vec_ *)_9 + 4B] = _8;
D.4309[_12].dir.x = x_13;
D.4309[_12].dir.y = y_14;
D.4308[_12].t = 1.0e+10;
D.4308[_12].h = 0;
_20 = &D.4308[_12];
_26 = MEM[(const struct Ray *)&D.4309][_12].org.x;
which as said isn't friendly enough for the simplistic address forward
propagation we have. The issue here is that we can't disambiguate
against
MEM[(struct vec_ *)_9 + 4B] = _8;
when looking up MEM[(const struct Ray *)&D.4309][_12].org.x; because
vn_reference_maybe_forwprop_address doesn't forward into MEM[(struct vec_ *)_9
+ 4B] as its offset is not zero:
/* If that didn't work because the address isn't invariant propagate
the reference tree from the address operation in case the current
dereference isn't offsetted. */
if (!addr_base
&& *i_p == ops->length () - 1
&& off == 0
/* This makes us disable this transform for PRE where the
reference ops might be also used for code insertion which
is invalid. */
&& default_vn_walk_kind == VN_WALKREWRITE)
{
auto_vec tem;
copy_reference_ops_from_ref (TREE_OPERAND (addr, 0), &tem);
ops->pop ();
ops->pop ();
ops->safe_splice (tem);
--*i_p;
return true;
it also likely wouldn't help vn_reference_lookup_3 to do the disambiguation
as that performs just
lhs_ops = valueize_refs_1 (lhs_ops, &valueized_anything);
if (valueized_anything)
{
lhs_ref_ok = ao_ref_init_from_vn_reference (&lhs_ref,
get_alias_set (lhs),
TREE_TYPE (lhs),
lhs_ops);
if (lhs_ref_ok
&& !refs_may_alias_p_1 (ref, &lhs_ref, true))
return NULL;
but there is still the variable offset to cope with. We'd need to perform
some disambiguation on lhs_ref vs. vr.
But it's not clear how to represent &D.4309[_12].org forwarded into
MEM[(struct vec_ *)_9 + 4B]. It's kind-of a COMPONENT_REF with just
a offset added.
Let's collect the improvements I have sofar in my local tree and see if they
otherwise work.
[Bug c/67570] comparison rules fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67570
--- Comment #4 from BENAÏSSA ---
Thank you very much for your reply.
Please do not take care of the first set of values for
MIN_NORMALIZED and in place you can test those new values.
MIN_NORMALIZED
1.755494 E-038 for float
2.225074 E-308 for double
3.362103 E-4932 for __float128
All remainded values stays unchanged.
Addendum to precedent note:
the proposal is valid for any floating point operation between two
float or more with final result lower than (float)MIN_DENORMALIZED,
and I will consult the C99/C11 standards and bug 323.
I apologize by advance.
A.Benaïssa
Le Mercredi 16 septembre 2015 16h45, joseph at codesourcery dot com
a écrit :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67570
--- Comment #3 from joseph at codesourcery dot com ---
I advise looking at __FLT_MAX__, __FLT_MIN__, __FLT_DENORM_MIN__ etc. as
predefined by the compiler to see the appropriate values of various
constants.
> Multiplying (float)MIN_NORMALIZED * (float)MIN_NORMALIZED and
> viewing this value with printf("%E..) we obtains
> result = 3.109021E-076 wuich is a valid double normalized value.
That's a matter of excess range and precision. See the C99/C11 standards
and bug 323.
[Bug middle-end/67222] [4.9/5 Regression] ICE in gimple_call_arg with bogus posix_memalign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67222 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Thu Sep 17 12:50:54 2015 New Revision: 227862 URL: https://gcc.gnu.org/viewcvs?rev=227862&root=gcc&view=rev Log: PR middle-end/67222 * gimple-low.c (lower_stmt): Don't lower BUILT_IN_POSIX_MEMALIGN if the call isn't valid. * tree-ssa-alias.c (ref_maybe_used_by_call_p_1): Check builtins using gimple_call_builtin_p. (call_may_clobber_ref_p_1): Likewise. (stmt_kills_ref_p): Likewise. * gcc.dg/torture/pr67222.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr67222.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/gimple-low.c branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/tree-ssa-alias.c
[Bug target/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Status|UNCONFIRMED |NEW
Known to work||4.9.3
Keywords||ra, wrong-code
Last reconfirmed||2015-09-17
Component|regression |target
CC||uros at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
Ever confirmed|0 |1
Summary|[Regression] Generates |[5/6 Regression] Generates
|wrong code for SSE2 |wrong code for SSE2
|_mm_load_pd |_mm_load_pd
Target Milestone|--- |5.3
--- Comment #2 from Richard Biener ---
;; MEM[(__m128d * {ref-all})&v] = reg.0_2;
(insn 6 5 0 (set (reg/v:TI 90 [ v ])
(mem/c:TI (symbol_ref:DI ("reg") [flags 0x2] ) [0 reg+0 S16 A128]))
/abuild/rguenther/trunk-g/gcc/include/emmintrin.h:161 -1
(nil))
;; v[0] = b_4(D);
(insn 7 6 0 (set (subreg:DF (reg/v:TI 90 [ v ]) 0)
(reg/v:DF 88 [ b ])) t.c:7 -1
(nil))
;; reg = _6;
(insn 8 7 0 (set (mem/c:V2DF (symbol_ref:DI ("reg") [flags 0x2] ) [0 reg+0 S16 A128])
(subreg:V2DF (reg/v:TI 90 [ v ]) 0)) t.c:8 -1
(nil))
the subreg set is expected to preserve the upper part. It later gets
later assigned *movdf_internal - so eventually we'd have expected
a lowpart instead. Not sure about bigger-than wordmode regs and subregs...
GCC 4.9 and before go through the stack extensively (otherwise identical
GIMPLE IL and RTL expansion though). So it looks like a backend
(pattern constraints?) or RA related bug (the issue appears after IRA/reload).
[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #20 from Kenneth Zadeck --- >> On second thoughts, for the first point, maybe a native speaker understands >> "an available definition on any path" as "an available definition on one >> path, >> whatever it is", in which case the description would be correct, albeit very >> confusing for non-native speakers. It would be good to have some insight >> from >> the DF maintainers here (CCed). A native English speaker would say that this could be written better. I would suggest the term "on at least one path" and this is what a MAY problem is generally defined as. I do have to say that I am still uncomfortable with changing RRE to use a MUST problem rather than a MAY problem. I see this as dumbing down the compiler to provide the semantics of uninitialized variables and it is a path that we have generally avoided in GCC. I do not have a better solution, but there is a feeling that something is being missed here.
[Bug middle-end/67222] [4.9/5 Regression] ICE in gimple_call_arg with bogus posix_memalign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67222 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed.
[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #21 from Eric Botcazou --- > LIVE provides live registers that MAY be initialized (are initialized on at > least one path). The comments are all wrong! > > There's no code in GCC for must-initialized. Pierre's patch gets it right > (except that I'm not sure about the comment at line 2033). The MIR name can > indeed add to the confusion about may/must. Perhaps valid registers (VR)? Thanks for the comment. Yes, I agree that the MIR name ought to be improved. > I think this issue can also be fixed easily with an approximated solution, > which is already used for example by combine's > set_nonzero_bits_and_sign_copies. If a register is undefined at the start > of the function, you punt because the register has uninitialized uses. This > is suboptimal if you have cases like: > > int y, x; > x = y; /* uninitialized */ > ... > y = 5; > ... > x = y; /* initialized */ > > but they should be pretty rare. Right, we pondered about it. The difference is that combine operates on pseudo while REE operates on hard registers, so the suboptimality could be large.
[Bug target/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609 --- Comment #3 from Uroš Bizjak --- The doc says: When used as an lvalue, 'subreg' is a word-based accessor. Storing to a 'subreg' modifies all the words of REG that overlap the 'subreg', but it leaves the other words of REG alone. When storing to a normal 'subreg' that is smaller than a word, the other bits of the referenced word are usually left in an undefined state. This laxity makes it easier to generate efficient code for such instructions. To represent an instruction that preserves all the bits outside of those in the 'subreg', use 'strict_low_part' or 'zero_extract' around the 'subreg'. However, we expand assignment to v[0] with: ;; v[0] = b_4(D); (insn 7 6 0 (set (subreg:DF (reg/v:TI 90 [ v ]) 0) (reg/v:DF 88 [ b ])) pr67609.c:8 -1 (nil)) According to the above explanation, a strict_low_part should be used here. I think this is middle-end, not a target problem.
[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #22 from Eric Botcazou --- > A native English speaker would say that this could be written better. I > would suggest the term "on at least one path" and this is what a MAY problem > is generally defined as. Thanks. Here's a proposed amended wording: Index: df-problems.c === --- df-problems.c (revision 227819) +++ df-problems.c (working copy) @@ -1309,22 +1309,23 @@ df_lr_verify_transfer_functions (void) /* - LIVE AND MUST-INITIALIZED REGISTERS. + LIVE AND MAY-INITIALIZED REGISTERS. This problem first computes the IN and OUT bitvectors for the - must-initialized registers problems, which is a forward problem. - It gives the set of registers for which we MUST have an available - definition on any path from the entry block to the entry/exit of - a basic block. Sets generate a definition, while clobbers kill + may-initialized registers problems, which is a forward problem. + It gives the set of registers for which we MAY have an available + definition, i.e. for which there is an available definition on + at least one path from the entry block to the entry/exit of a + basic block. Sets generate a definition, while clobbers kill a definition. In and out bitvectors are built for each basic block and are indexed by regnum (see df.h for details). In and out bitvectors in struct - df_live_bb_info actually refers to the must-initialized problem; + df_live_bb_info actually refers to the may-initialized problem; Then, the in and out sets for the LIVE problem itself are computed. These are the logical AND of the IN and OUT sets from the LR problem - and the must-initialized problem. + and the may-initialized problem. */ /* Private data used to verify the solution for this problem. */ @@ -1531,7 +1532,7 @@ df_live_confluence_n (edge e) } -/* Transfer function for the forwards must-initialized problem. */ +/* Transfer function for the forwards may-initialized problem. */ static bool df_live_transfer_function (int bb_index) @@ -1555,7 +1556,7 @@ df_live_transfer_function (int bb_index) } -/* And the LR info with the must-initialized registers, to produce the LIVE info. */ +/* And the LR info with the may-initialized registers, to produce the LIVE info. */ static void df_live_finalize (bitmap all_blocks)
[Bug target/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609 --- Comment #4 from Richard Biener --- (In reply to Uroš Bizjak from comment #3) > The doc says: > > When used as an lvalue, 'subreg' is a word-based accessor. > Storing to a 'subreg' modifies all the words of REG that > overlap the 'subreg', but it leaves the other words of REG > alone. But UNITS_PER_WORD is 8 so (subreg:DF (TI)) should leave the upper half of the TImode register unchanged. > When storing to a normal 'subreg' that is smaller than a word, > the other bits of the referenced word are usually left in an > undefined state. This laxity makes it easier to generate > efficient code for such instructions. To represent an > instruction that preserves all the bits outside of those in > the 'subreg', use 'strict_low_part' or 'zero_extract' around > the 'subreg'. > > However, we expand assignment to v[0] with: > > ;; v[0] = b_4(D); > > (insn 7 6 0 (set (subreg:DF (reg/v:TI 90 [ v ]) 0) > (reg/v:DF 88 [ b ])) pr67609.c:8 -1 > (nil)) > > According to the above explanation, a strict_low_part should be used here. > > I think this is middle-end, not a target problem.
[Bug target/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609
--- Comment #5 from Richard Biener ---
It does the "correct" thing for
#include
__m128d reg;
void set_lower(float b)
{
float v[4];
_mm_store_pd((double *)v, reg);
v[0] = b;
reg = _mm_load_pd((double *)v);
}
[Bug c/67611] New: strcpy BUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67611
Bug ID: 67611
Summary: strcpy BUG
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: soekchl at 163 dot com
Target Milestone: ---
So easy programing , but the luck boy found a bug.Here is the gcc version of
the source code and the process and procedures for recording results.
And g++ have a same bug.
ubuntu@ubuntu-virtual-machine:~/temp_source/201509/16$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --enable-targets=all --disable-werror
--with-arch-32=i686 --with-tune=generic --enable-checking=release
--build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
ubuntu@ubuntu-virtual-machine:~/temp_source/201509/16$
ubuntu@ubuntu-virtual-machine:~/temp_source/201509/16$ ls
a.out bigNum.c strcpy.c
ubuntu@ubuntu-virtual-machine:~/temp_source/201509/16$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --enable-targets=all --disable-werror
--with-arch-32=i686 --with-tune=generic --enable-checking=release
--build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
ubuntu@ubuntu-virtual-machine:~/temp_source/201509/16$ cat strcpy.c
#include
#include
#include
int main(int argc, char *argv[])
{
char str[] = "098.01";
puts(str);
strcpy(str, str+1);
puts(str);
return 0;
}
ubuntu@ubuntu-virtual-machine:~/temp_source/201509/16$ gcc strcpy.c -Wall
ubuntu@ubuntu-virtual-machine:~/temp_source/201509/16$ ./a.out
098.01
98001
ubuntu@ubuntu-virtual-machine:~/temp_source/201509/16$
[Bug c/67611] strcpy BUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67611 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- Read the frabjous manual: http://man7.org/linux/man-pages/man3/strcpy.3.html The strings may not overlap, and the destination string dest must be large enough to receive the copy. Beware of buffer overruns! (See BUGS.)
[Bug rtl-optimization/50749] Auto-inc-dec does not find subsequent contiguous mem accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749 --- Comment #21 from Oleg Endo --- (In reply to Urja Rannikko from comment #20) > I'll add a note here that this seems to also affect the AVR target when it > is under register pressure and cant use Z or Y registers which can do Z+n > /Y+n addressing, it ends up doing really stupid things with X register > ... I don't know AVR, but if it has only two addr regs which can do post-inc loads, in your example a loop distribution is required. In other words, you need to use two loops, first with p1,p2 and second loop with p3. Because the calculation in the loop is simple, it would make sense. If the calculations in the loop are more complex, maybe not. It's similar to the problems in PR 53949.
[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67573 --- Comment #8 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #7) > Fixed on trunk. > Oleg, now we can propose to make -mlra default on trunk. Nice, thank you!
[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #23 from Kenneth Zadeck --- This change to the doc looks fine to me.
[Bug tree-optimization/67612] New: Unable to vectorize DOT_PROD_EXPR (PMADDWD)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67612 Bug ID: 67612 Summary: Unable to vectorize DOT_PROD_EXPR (PMADDWD) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- Created attachment 36346 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36346&action=edit Test case The attached code is a reduced form of a loop that the user hoped would be auto-vectorized to using PMADDWD, but no vectorization occurs (this was whilst investigating possible use of libgccjit for autovectorization). With a recent gcc trunk (r227686), I get this for the reproducer at -O3: : 0: 31 c0 xor%eax,%eax 2: 85 c9 test %ecx,%ecx 4: 7e 37 jle3d 6: 66 2e 0f 1f 84 00 00nopw %cs:0x0(%rax,%rax,1) d: 00 00 00 10: 44 0f bf 04 82 movswl (%rdx,%rax,4),%r8d 15: 44 0f bf 14 86 movswl (%rsi,%rax,4),%r10d 1a: 44 0f bf 4c 82 02 movswl 0x2(%rdx,%rax,4),%r9d 20: 45 0f af d0 imul %r8d,%r10d 24: 44 0f bf 44 86 02 movswl 0x2(%rsi,%rax,4),%r8d 2a: 45 0f af c1 imul %r9d,%r8d 2e: 45 01 d0add%r10d,%r8d 31: 44 89 04 87 mov%r8d,(%rdi,%rax,4) 35: 48 83 c0 01 add$0x1,%rax 39: 39 c1 cmp%eax,%ecx 3b: 7f d3 jg 10 3d: f3 c3 repz retq Building with -fdump-tree-vect-details to see why gcc -O3 fails to vectorize, I see this in FILENAME.c.130t.vect: (snip) ../../src/vector_dot_prod.c:11:3: note: ==> examining pattern statement: patt_91 = DOT_PROD_EXPR <_14, _18, _29>; ../../src/vector_dot_prod.c:11:3: note: vect_is_simple_use: operand _14 ../../src/vector_dot_prod.c:11:3: note: def_stmt: _14 = *_13; ../../src/vector_dot_prod.c:11:3: note: type of def: internal ../../src/vector_dot_prod.c:11:3: note: not vectorized: relevant stmt not supported: patt_91 = DOT_PROD_EXPR <_14, _18, _29>; ../../src/vector_dot_prod.c:11:3: note: bad operation or unsupported loop bound. ../../src/vector_dot_prod.c:5:1: note: vectorized 0 loops in function. Stepping through: gcc/tree-vect-stmts.c:vect_analyze_stmt for stmt: patt_91 = DOT_PROD_EXPR <_14, _18, _29>; I see that vectorizable_operation returns false here: 4821if (nunits_out != nunits_in) 4910return false; (gdb) p nunits_out $16 = 4 (gdb) p nunits_in $17 = 8 Should this be a vectorizable_operation?
[Bug libstdc++/65142] std::random_device Ignores Read Return Code (CVE-2015-5276)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65142 --- Comment #11 from Jonathan Wakely --- Author: redi Date: Thu Sep 17 15:06:42 2015 New Revision: 227872 URL: https://gcc.gnu.org/viewcvs?rev=227872&root=gcc&view=rev Log: Make std::random_device retry after short reads PR libstdc++/65142 * src/c++11/random.cc (random_device::_M_getval()): Retry after short reads. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++11/random.cc
[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #24 from Eric Botcazou --- Author: ebotcazou Date: Thu Sep 17 15:35:24 2015 New Revision: 227874 URL: https://gcc.gnu.org/viewcvs?rev=227874&root=gcc&view=rev Log: PR rtl-optimization/66790 * df-problems.c (LIVE): Amend documentation. Modified: trunk/gcc/ChangeLog trunk/gcc/df-problems.c
[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #25 from Eric Botcazou --- Author: ebotcazou Date: Thu Sep 17 15:35:43 2015 New Revision: 227875 URL: https://gcc.gnu.org/viewcvs?rev=227875&root=gcc&view=rev Log: PR rtl-optimization/66790 * df-problems.c (LIVE): Amend documentation. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/df-problems.c
[Bug fortran/67588] module.c heap use after free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67588 --- Comment #7 from Vittorio Zecca --- use_list is local to the function gfc_match_submodule and it is already reinitialized in the for statement at line 806. So there is a duplication. On return at line 812 it is then lost. Maybe optimization would expunge it anyway.
[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #26 from Eric Botcazou --- Author: ebotcazou Date: Thu Sep 17 15:35:58 2015 New Revision: 227876 URL: https://gcc.gnu.org/viewcvs?rev=227876&root=gcc&view=rev Log: PR rtl-optimization/66790 * df-problems.c (LIVE): Amend documentation. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/df-problems.c
[Bug c/67610] strcpy BUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67610 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|cp-tools|c Version|unspecified |4.2.1 Resolution|--- |INVALID Product|classpath |gcc --- Comment #2 from Andrew Pinski --- Strcpy has undefined behavior if the input and output arrays overlap. Use memmove instead. Also this would not be a gcc bug as gcc does provide strcpy.
[Bug c/67610] strcpy BUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67610 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #3 from Andrew Pinski --- *** This bug has been marked as a duplicate of bug 67611 ***
[Bug c/67611] strcpy BUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67611 --- Comment #2 from Andrew Pinski --- *** Bug 67610 has been marked as a duplicate of this bug. ***
[Bug libstdc++/65913] [5/6 Regression] Linking failure without -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65913 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Thu Sep 17 15:46:04 2015 New Revision: 227878 URL: https://gcc.gnu.org/viewcvs?rev=227878&root=gcc&view=rev Log: Handle alignment in __atomic_is_lock_free gcc: 2015-09-17 Richard Henderson PR libstdc++/65913 * builtins.c (fold_builtin_atomic_always_lock_free): Handle fake pointers that encode the alignment of the object. libstdc++-v3: 2015-09-17 Jonathan Wakely PR libstdc++/65913 * include/bits/atomic_base.h (__atomic_base<_TTp>::is_lock_free(), __atomic_base<_PTp*>::is_lock_free()): Call the built-in with the immediate pointer value, not a variable. * include/std/atomic (atomic::is_lock_free()): Likewise. * testsuite/29_atomics/atomic/65913.cc: New. Added: trunk/libstdc++-v3/testsuite/29_atomics/atomic/65913.cc Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/atomic_base.h trunk/libstdc++-v3/include/std/atomic
[Bug libstdc++/65913] [5 Regression] Linking failure without -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65913 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |5.3 Summary|[5/6 Regression] Linking|[5 Regression] Linking |failure without -latomic|failure without -latomic Known to fail|6.0 | --- Comment #8 from Jonathan Wakely --- Fixed on trunk now.
[Bug sanitizer/67513] ASAN: Not optimal shadow value check (unlikely condition checked in fast path)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67513 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-09-17 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #6 from Marek Polacek --- I'll have a look.
[Bug c++/67613] New: spell suggestions for misspelled command line options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67613 Bug ID: 67613 Summary: spell suggestions for misspelled command line options Product: gcc Version: unknown Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: manu at gcc dot gnu.org CC: dmalcolm at gcc dot gnu.org Depends on: 52277 Target Milestone: --- $ gcc -Wcoercion test.c cc1: error: unrecognized command line option "-Wcoercion" $ clang -Wcoercion test.c warning: unknown warning option '-Wcoercion'; did you mean '-Wconversion'? [-Wunknown-warning-option] Once PR52277 is fixed, gcc could do better here. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52277 [Bug 52277] spell corrector for misspelled identifiers
[Bug fortran/67614] New: ICE on using arithmetic if with null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67614 Bug ID: 67614 Summary: ICE on using arithmetic if with null Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Some cases with oldstyle arithmetic if in combination with null instead of a scalar-numeric-expr : $ cat z1.f90 program p integer, allocatable :: z if ( null(z) ) 1, 2, 3 1 stop 1 2 stop 2 3 stop 3 end $ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize z1.f90 internal compiler error: in gfc_build_const, at fortran/trans-const.c:76 $ cat z2.f90 program p integer, pointer :: z if ( null(z) ) 1, 2, 3 1 stop 1 2 stop 2 3 stop 3 end $ gfortran z2.f90 internal compiler error: in gfc_build_const, at fortran/trans-const.c:76
[Bug fortran/67614] ICE on using arithmetic if with null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67614 --- Comment #1 from Gerhard Steinmetz --- $ cat z4.f90 program p integer, pointer :: z => null() if ( z ) 1, 2, 3 1 stop 1 2 stop 2 3 stop 3 end $ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize z4.f90 $ a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
[Bug fortran/67615] New: ICE on using arithmetic if with array instead of scalar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67615 Bug ID: 67615 Summary: ICE on using arithmetic if with array instead of scalar Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- An arithmetic if with an array instead of a numeric scalar : program p integer :: z(1) = [1] if ( z ) 1, 2, 3 1 stop 1 2 stop 2 3 stop 3 end or this variation : program p integer :: z(2) = [1, 2] if ( z ) 1, 2, 3 1 stop 1 2 stop 2 3 stop 3 end yields : internal compiler error: Segmentation fault
[Bug fortran/67615] ICE on using arithmetic if with array instead of scalar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67615 --- Comment #1 from Gerhard Steinmetz --- With an array constructor : $ cat z6.f90 program p if ( [1] ) 1, 2, 3 if ( [1, -1] ) 1, 2, 3 if ( [real :: 1, -1] ) 1, 2, 3 1 stop 1 2 stop 2 3 stop 3 end $ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize z6.f90 z6.f90:2:0: if ( [1] ) 1, 2, 3 1 internal compiler error: in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:6326
[Bug regression/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609 Joel Yliluoma changed: What|Removed |Added Component|target |regression --- Comment #6 from Joel Yliluoma --- And also for _mm_load_ps in a similar situation. I did manage to get some error to occur with floats too, but I'm yet to isolate the problem.
[Bug fortran/67616] New: ICE on data initialization of type variable in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67616 Bug ID: 67616 Summary: ICE on data initialization of type variable in block Product: gcc Version: 5.2.1 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 an embedding block construct : $ cat z1.f90 program p type t end type block type(t) :: x data x /t()/ end block end $ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize z1.f90 f951: internal compiler error: in gfc_match_structure_constructor, at fortran/primary.c:2655
[Bug fortran/67616] ICE on data initialization of type variable in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67616 --- Comment #1 from Gerhard Steinmetz --- Compiles without block : program p type t end type type(t) :: x data x /t()/ end Compiles with block and intrinsic type : program p block integer :: x data x /1/ end block end
[Bug middle-end/64920] bootstrap-ubsan [build/gengtype -r gtype.state]: libiberty/regex.c:6970:11: runtime error: left shift of negative value -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64920 --- Comment #2 from Vittorio Zecca --- I propose the following fix at line 688 of regex.c in trunk change (destination) += SIGN_EXTEND_CHAR (*((source) + 1)) << 8 ; \ into (*((source) + 1)) >= 0 ? (destination) += SIGN_EXTEND_CHAR (*((source) + 1)) << 8 : (destination) ; \ I admit I did not tested it (yet) but the idea is to shift only if the shiftee is not negative
[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 --- Comment #23 from baoshan --- (In reply to Manuel López-Ibáñez from comment #22) > (In reply to baoshan from comment #21) > > Don't you think the range value is strange? how it is possible the range > > value is so big according the code? > > j = i - 1 is actually j = i + 4294967295 because of unsigned. > > Thus the problematic ranges: > >[test.c:9:13] # RANGE [4294967291, 4294967295] >_51 = i_2 + 4294967290; > > are actually: > >[test.c:9:13] # RANGE [-5, -1] >_51 = i_2 - 6; > > but this code should have not been generated. Those ranges do seem > suspicious. Finding out how that block ends up with those ranges would be > helpful. You probably need to debug vrp or (using -fopt-info) the point > where gcc gives: > > test.c:7:3: note: loop turned into non-loop; it never loops. > test.c:7:3: note: loop with 5 iterations completely unrolled I have seen two places that would convert "A-1" to "A+(-1)", and due the type is unsigned int, it would be converted to "A+4294967295". This looks not right to me. The two places are: 1. fold-const.c:10626 /* A - B -> A + (-B) if B is easily negatable. */ if (negate_expr_p (arg1) && !TYPE_OVERFLOW_SANITIZED (type) && ((FLOAT_TYPE_P (type) /* Avoid this transformation if B is a positive REAL_CST. */ && (TREE_CODE (arg1) != REAL_CST || REAL_VALUE_NEGATIVE (TREE_REAL_CST (arg1 || INTEGRAL_TYPE_P (type))) => return fold_build2_loc (loc, PLUS_EXPR, type, fold_convert_loc (loc, type, arg0), fold_convert_loc (loc, type, negate_expr (arg1))); 2. c-common.c:4574 if (resultcode == MINUS_EXPR) intop = fold_build1_loc (loc, NEGATE_EXPR, sizetype, intop);
[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 --- Comment #24 from Andrew Pinski --- (In reply to baoshan from comment #23) > I have seen two places that would convert "A-1" to "A+(-1)", and due the > type is unsigned int, it would be converted to "A+4294967295". This looks > not right to me. Why wrapping is well defined for unsigned types so adding 4294967295 is the same as subtracting by 1.
[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 --- Comment #25 from baoshan --- (In reply to Andrew Pinski from comment #24) > (In reply to baoshan from comment #23) > > I have seen two places that would convert "A-1" to "A+(-1)", and due the > > type is unsigned int, it would be converted to "A+4294967295". This looks > > not right to me. > > Why wrapping is well defined for unsigned types so adding 4294967295 is the > same as subtracting by 1. What is wrapping? and where it is defined? I don't know this part and I like to learn it. Thanks.
[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609 Uroš Bizjak changed: What|Removed |Added Component|target |rtl-optimization --- Comment #7 from Uroš Bizjak --- (In reply to Richard Biener from comment #4) > (In reply to Uroš Bizjak from comment #3) > > The doc says: > > > > When used as an lvalue, 'subreg' is a word-based accessor. > > Storing to a 'subreg' modifies all the words of REG that > > overlap the 'subreg', but it leaves the other words of REG > > alone. > > But UNITS_PER_WORD is 8 so (subreg:DF (TI)) should leave the upper half > of the TImode register unchanged. Indeed, and -m32 creates correct code. So, it is register allocator that fails. Reconfirmed as rtl-optimization problem.
[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 --- Comment #26 from Jakub Jelinek --- (In reply to baoshan from comment #25) > > Why wrapping is well defined for unsigned types so adding 4294967295 is the > > same as subtracting by 1. > > What is wrapping? and where it is defined? I don't know this part and I like > to learn it. > Thanks. Just read the C or C++ standards? E.g. C99, 6.2.5/9: ... "A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type." ...
[Bug libstdc++/67617] New: Non-standard const requirements imposed on associate container comparison objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67617
Bug ID: 67617
Summary: Non-standard const requirements imposed on associate
container comparison objects
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mdempsky at google dot com
Target Milestone: ---
This code appears to me to be conforming to the C++ standard, but it's rejected
by G++/libstdc++:
#include
struct compare {
bool operator()(int a, int b);
};
void func() {
const std::set s;
s.find(0);
}
because compare::operator() is not const qualified.
N3690 [associative.reqmts]p2 says "The object of type Compare is called the
comparison object of the container", and p3 talks about the requirements on
behavior of a comparison object comp. However, none of the requirements seem
to impose requirements on objects of type const Compare.
[Bug other/66827] [6 Regression] left shifts of negative value warnings due to C++14 switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66827 --- Comment #3 from Vittorio Zecca --- (In reply to Mikhail Maltsev from comment #1) > gcc/haifa-sched.c:1164:24 > gcc/haifa-sched.c:1442:26 > gcc/sched-deps.c:112:20 > > are caused by the following macro definition in gcc/sched-int.h:243: > #define UNKNOWN_DEP_COST (-1<<19) I fixed this one with #define UNKNOWN_DEP_COST (-1u<<19)
[Bug tree-optimization/57742] memset(malloc(n),0,n) -> calloc(n,1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742 Daniel Gutson changed: What|Removed |Added CC||daniel.gutson@tallertechnol ||ogies.com --- Comment #24 from Daniel Gutson --- This optimization breaks code, please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
[Bug c/67618] New: malloc+memset optimization breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
Bug ID: 67618
Summary: malloc+memset optimization breaks code
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.gutson at tallertechnologies dot com
Target Milestone: ---
compiling the following code with -O2
#include
#include
char* function(size_t x)
{
void* ret = malloc(x);
if (x > 12)
memset(ret, 0, x);
return (char*)ret;
}
int main(void)
{
return 0;
}
causes gcc to wrongly replace function's content by a call to calloc.
This comes from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
Additionally, in the case for RTEMS for example, if the function itself
(caller) is calloc, causes a recursive call. (Maybe this could be addressed in
two separate issues).
[Bug c/67618] malloc+memset optimization breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618 --- Comment #1 from Marc Glisse --- Why do you call it wrong? It is always legal to replace malloc with calloc, and if we do it, the memset becomes useless. It may not be optimal from a performance POV, but I don't see where it breaks anything. As for the infinite loop, that's a know problem not specific to this function and there are already several PRs/emails about it. When you compile the C library itself, you are supposed to pass some options to gcc so it knows not to do that.
[Bug sanitizer/64078] FAIL: c-c++-common/ubsan/object-size-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64078 --- Comment #14 from Bernd Edlinger --- Author: edlinger Date: Thu Sep 17 19:43:00 2015 New Revision: 227886 URL: https://gcc.gnu.org/viewcvs?rev=227886&root=gcc&view=rev Log: 2015-09-17 Bernd Edlinger PR sanitizer/64078 * c-c++-common/ubsan/object-size-9.c (s): Add alignment attribute. (f2, f3): Make the function static. * c-c++-common/ubsan/object-size-10.c (a, b): Add alignment attribute. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/ubsan/object-size-10.c trunk/gcc/testsuite/c-c++-common/ubsan/object-size-9.c
[Bug rtl-optimization/50749] Auto-inc-dec does not find subsequent contiguous mem accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #22 from Urja Rannikko ---
All of the 3 pointer regs (X,Y,Z) can do post-inc operations, but only Y and Z
can do displacement (which is what gcc tries to use, even when the increment
operation would be better all around since we usually want the +4 pointer).
The given code wasnt meant to be anywhere near the real code, just a code that
shows the behaviour exists. The real code is just a function with lots going on
involving loading 32-bit values from pointers.
This code is WIP and i was just looking how it'll end up compiled, but for your
curiosity, here's a fragment (not enough to compile), with a comment added on
the part where i found the ld, adiw, ld, sbiw, adiw, ld, sbiw, adiw, ..
sequence, but AFAIK it could be triggered at any usage of inlined buf2u32:
static uint32_t buf2u32(uint8_t *buf) {
return *(uint32_t*)buf;
}
static uint8_t do_exec_opbuf_extwrite(uint8_t *ewsq, uint32_t addr, uint8_t
*buf, uint16_t dlen) {
uint8_t* end = ewsq + ewsq[0] + 1;
for (uint16_t i=0;iend) return 1;
}
return 0;
}
If i end up liking this code enough it'll end up in a branch at
https://github.com/urjaman/libfrser
[Bug sanitizer/64078] FAIL: c-c++-common/ubsan/object-size-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64078 Bernd Edlinger changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Bernd Edlinger --- fixed on trunk.
[Bug c/67618] malloc+memset optimization breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618 --- Comment #2 from Daniel Gutson --- (In reply to Marc Glisse from comment #1) > Why do you call it wrong? It is always legal to replace malloc with calloc, Have you seen the 'if' condition? The optimization ignores it completely. > and if we do it, the memset becomes useless. It may not be optimal from a > performance POV, but I don't see where it breaks anything. > > As for the infinite loop, that's a know problem not specific to this > function and there are already several PRs/emails about it. When you compile > the C library itself, you are supposed to pass some options to gcc so it > knows not to do that.
[Bug c/67618] malloc+memset optimization breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618 --- Comment #3 from Andreas Schwab --- Trying to read the (uninitialized) contents of the allocated memory for x <= 12 would be undefined behaviour, so calling calloc instead does not change the defined behaviour.
[Bug c/67618] malloc+memset optimization breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618 --- Comment #4 from Daniel Gutson --- (In reply to Andreas Schwab from comment #3) > Trying to read the (uninitialized) contents of the allocated memory for x <= > 12 would be undefined behaviour, so calling calloc instead does not change > the defined behaviour. Why do you assert that the program will read the memory? The optimization ignores the 'if' statement (just comment that line and see), so if malloc() returns NULL, memset is called unconditionally and will try to write to address NULL. The "x > 12" was just an example that this is arbitrary. Replace it with something else. The 'if' shall not be ignored.
[Bug middle-end/67618] malloc+memset optimization breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618 Andrew Pinski changed: What|Removed |Added Component|c |middle-end --- Comment #5 from Andrew Pinski --- (In reply to Daniel Gutson from comment #4) > (In reply to Andreas Schwab from comment #3) > > Trying to read the (uninitialized) contents of the allocated memory for x <= > > 12 would be undefined behaviour, so calling calloc instead does not change > > the defined behaviour. > > Why do you assert that the program will read the memory? It does not. It just optimizes the code. > The optimization ignores the 'if' statement (just comment that line and > see), so if malloc() returns NULL, memset is called unconditionally and will > try to write to address NULL. The "x > 12" was just an example that this is > arbitrary. Replace it with something else. The 'if' shall not be ignored. yes that just undefined behavior when invoking memset with a NULL value, so replacing it is still fine. Also calloc is sometimes faster than a malloc/memset due to knowing if the kernel will zero out the memory, etc.
[Bug middle-end/67618] malloc+memset optimization breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618 --- Comment #6 from Daniel Gutson --- (In reply to Andrew Pinski from comment #5) > (In reply to Daniel Gutson from comment #4) > > (In reply to Andreas Schwab from comment #3) > > > Trying to read the (uninitialized) contents of the allocated memory for x > > > <= > > > 12 would be undefined behaviour, so calling calloc instead does not change > > > the defined behaviour. > > > > Why do you assert that the program will read the memory? > > It does not. It just optimizes the code. I meant: how do you know what the program will do next? Maybe it will write memory. See below please. > > > The optimization ignores the 'if' statement (just comment that line and > > see), so if malloc() returns NULL, memset is called unconditionally and will > > try to write to address NULL. The "x > 12" was just an example that this is > > arbitrary. Replace it with something else. The 'if' shall not be ignored. > > yes that just undefined behavior when invoking memset with a NULL value, so > replacing it is still fine. That's why the 'if (ptr != NULL)' should not be ignored, which currently is. The 'if' prevents the UB. > > Also calloc is sometimes faster than a malloc/memset due to knowing if the > kernel will zero out the memory, etc. This is not under discussion.
[Bug c/67618] malloc+memset optimization breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618 Marc Glisse changed: What|Removed |Added Component|middle-end |c --- Comment #7 from Marc Glisse --- (In reply to Daniel Gutson from comment #4) > The optimization ignores the 'if' statement (just comment that line and > see), so if malloc() returns NULL, memset is called unconditionally and will > try to write to address NULL. Ah, you are saying that calling memset on a null pointer is not undefined behavior, that it generates an observable trap, and that the transformation should be protected by -fdelete-null-pointer-checks?
[Bug tree-optimization/67618] malloc+memset optimization breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618 Marc Glisse changed: What|Removed |Added Component|c |tree-optimization --- Comment #8 from Marc Glisse --- (bugzilla bug that reset the component...) (In reply to Daniel Gutson from comment #6) > That's why the 'if (ptr != NULL)' should not be ignored, which currently is. > The 'if' prevents the UB. Uh, if you consider it UB, I don't understand the problem. At runtime, either malloc succeeded and the transformation is fine, or x<=12 and the transformation is fine, or the call to memset is undefined behavior so anything is fine (including the transformation). Unless you explicitly want to catch the trap, I don't understand what you are saying. Could you detail step by step where a well-defined behavior in the original program is turned into a different behavior in the optimization?
[Bug tree-optimization/67618] malloc+memset optimization breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
--- Comment #9 from Daniel Gutson
---
(In reply to Marc Glisse from comment #8)
> (bugzilla bug that reset the component...)
>
> (In reply to Daniel Gutson from comment #6)
> > That's why the 'if (ptr != NULL)' should not be ignored, which currently is.
> > The 'if' prevents the UB.
>
> Uh, if you consider it UB, I don't understand the problem. At runtime,
> either malloc succeeded and the transformation is fine, or x<=12 and the
> transformation is fine, or the call to memset is undefined behavior so
> anything is fine (including the transformation). Unless you explicitly want
> to catch the trap, I don't understand what you are saying. Could you detail
> step by step where a well-defined behavior in the original program is turned
> into a different behavior in the optimization?
See this example: ('function' is same as above)
void caller(void)
{
void* ptr = function(1);
*(char*)ptr = 1;
}
In this case, calloc was called instead of (only) malloc because the 'if' was
ignored, resulting in a suboptimized code (since calloc is usually slower than
malloc alone).
The resulting steps are:
calloc(1)
*ptr = 1;
whereas I just wanted
malloc(1)
*ptr = 1;
IMHO, the optimization should take the 'if' into account and only apply if it
is the usual 'if (ptr != NULL)' pattern.
(Additionally, it should check that the context caller function is not 'calloc'
itself).
[Bug tree-optimization/67618] malloc+memset optimization breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #10 from Andrew Pinski ---
(In reply to Daniel Gutson from comment #9)
> (In reply to Marc Glisse from comment #8)
> > (bugzilla bug that reset the component...)
> >
> > (In reply to Daniel Gutson from comment #6)
> > > That's why the 'if (ptr != NULL)' should not be ignored, which currently
> > > is.
> > > The 'if' prevents the UB.
> >
> > Uh, if you consider it UB, I don't understand the problem. At runtime,
> > either malloc succeeded and the transformation is fine, or x<=12 and the
> > transformation is fine, or the call to memset is undefined behavior so
> > anything is fine (including the transformation). Unless you explicitly want
> > to catch the trap, I don't understand what you are saying. Could you detail
> > step by step where a well-defined behavior in the original program is turned
> > into a different behavior in the optimization?
>
> See this example: ('function' is same as above)
>
> void caller(void)
> {
> void* ptr = function(1);
> *(char*)ptr = 1;
> }
Maybe file another bug which does the opposite transformation for the cases
where memcpy happens after the calloc. There is not enough information to know
if the value is going to be <=15 most of the time or not so we just guess.
Anyways there is no breaking of code. If you don't want this transformation
inside a function which is called calloc, then you need to use
-fno-builtin-malloc to disable finding of the malloc call.
[Bug c++/67364] "accessing uninitialized member" error in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67364 --- Comment #1 from Louis Dionne --- Ping. This is one of the last bugs preventing Boost.Hana [1] to work with GCC. I would be eternally grateful if someone could fix this! [1]: https://github.com/ldionne/hana
[Bug tree-optimization/67618] malloc+memset optimization breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
--- Comment #11 from Daniel Gutson ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Daniel Gutson from comment #9)
> > (In reply to Marc Glisse from comment #8)
> > > (bugzilla bug that reset the component...)
> > >
> > > (In reply to Daniel Gutson from comment #6)
> > > > That's why the 'if (ptr != NULL)' should not be ignored, which
> > > > currently is.
> > > > The 'if' prevents the UB.
> > >
> > > Uh, if you consider it UB, I don't understand the problem. At runtime,
> > > either malloc succeeded and the transformation is fine, or x<=12 and the
> > > transformation is fine, or the call to memset is undefined behavior so
> > > anything is fine (including the transformation). Unless you explicitly
> > > want
> > > to catch the trap, I don't understand what you are saying. Could you
> > > detail
> > > step by step where a well-defined behavior in the original program is
> > > turned
> > > into a different behavior in the optimization?
> >
> > See this example: ('function' is same as above)
> >
> > void caller(void)
> > {
> > void* ptr = function(1);
> > *(char*)ptr = 1;
> > }
>
> Maybe file another bug which does the opposite transformation for the cases
> where memcpy happens after the calloc. There is not enough information to
> know if the value is going to be <=15 most of the time or not so we just
> guess.
Can't we use this one?
>
> Anyways there is no breaking of code.
OK, my bad.
> If you don't want this transformation
> inside a function which is called calloc, then you need to use
> -fno-builtin-malloc to disable finding of the malloc call.
Shouldn't be -fno-builtin-calloc the flag to prevent this optimization? I don't
want to disable malloc's builtin flavor everywhere else.
[Bug fortran/67616] ICE on data initialization of type variable in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67616 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-17 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (6.0).
[Bug fortran/67615] ICE on using arithmetic if with array instead of scalar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67615 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-17 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (6.0). Backtrace * thread #1: tid = 0x97e3343, 0x0001000dc6ee f951`::gfc_conv_scalarized_array_ref(se=0x7fff5fbfef40, ar=0x000144b01728) + 30 at trans-array.c:3129, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) frame #0: 0x0001000dc6ee f951`::gfc_conv_scalarized_array_ref(se=0x7fff5fbfef40, ar=0x000144b01728) + 30 at trans-array.c:3129 3126 int n; 3127 3128 ss = se->ss; -> 3129 expr = ss->info->expr; 3130 info = &ss->info->data.array; 3131 if (ar) 3132 n = se->loop->order[0]; (lldb) bt * thread #1: tid = 0x97e3343, 0x0001000dc6ee f951`::gfc_conv_scalarized_array_ref(se=0x7fff5fbfef40, ar=0x000144b01728) + 30 at trans-array.c:3129, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) * frame #0: 0x0001000dc6ee f951`::gfc_conv_scalarized_array_ref(se=0x7fff5fbfef40, ar=0x000144b01728) + 30 at trans-array.c:3129 frame #1: 0x0001000dd26a f951`gfc_conv_array_ref(se=0x7fff5fbfef40, ar=0x000144b01728, expr=, where=0x000144b016b0) + 154 at trans-array.c:3281 frame #2: 0x000100109f5e f951`::gfc_conv_variable(se=0x7fff5fbfef40, expr=0x000144b01660) + 414 at trans-expr.c:2567 frame #3: 0x000100108594 f951`gfc_conv_expr_val(se=0x7fff5fbfef40, expr=) + 20 at trans-expr.c:7535 frame #4: 0x00010013b6a4 f951`gfc_trans_arithmetic_if(code=0x000144b019a0) + 52 at trans-stmt.c:1183 frame #5: 0x0001000d4c48 f951`::trans_code(code=0x000144b019a0, cond=0x) + 1176 at trans.c:1744 frame #6: 0x0001000fa015 f951`gfc_generate_function_code(ns=) + 1061 at trans-decl.c:5900 frame #7: 0x00010008bedc f951`gfc_parse_file() + 1628 at parse.c:5526 frame #8: 0x0001000d1ad6 f951`::gfc_be_parse_file() + 54 at f95-lang.c:209 frame #9: 0x00010091d67a f951`::compile_file() + 58 at toplev.c:545 frame #10: 0x000100cf817c f951`toplev::main(int, char**) + 1151 at toplev.c:2035 frame #11: 0x000100cf7cfd f951`toplev::main(this=, argc=2, argv=0x7fff5fbff350) + 717 frame #12: 0x000100cf9be9 f951`main(argc=2, argv=0x7fff5fbff350) + 41 at main.c:39
[Bug fortran/67614] ICE on using arithmetic if with null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67614 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-17 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (6.0).
[Bug c/67580] Improve error message on missing "struct" tag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67580 Manuel López-Ibáñez changed: What|Removed |Added CC||rui.maciel at gmail dot com --- Comment #5 from Manuel López-Ibáñez --- *** Bug 55613 has been marked as a duplicate of this bug. ***
[Bug libstdc++/67617] Non-standard const requirements imposed on associative container comparison objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67617 --- Comment #1 from Jonathan Wakely --- If that code is conforming then it's a defect in the standard.
[Bug c/55613] Add suggestion of adding struct if the name exists in the struct tag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55613 Manuel López-Ibáñez changed: What|Removed |Added Status|NEW |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Manuel López-Ibáñez --- Fixed in GCC 6 *** This bug has been marked as a duplicate of bug 67580 ***
[Bug libstdc++/67617] Non-standard const requirements imposed on associative container comparison objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67617 --- Comment #2 from Jonathan Wakely --- Both Clang/libc++ and MSVC/Dinkumware reject it for the same reason.
[Bug middle-end/38358] Could not compile gcc using large include files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38358 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |INVALID --- Comment #6 from Manuel López-Ibáñez --- No testcase, old report. Please reopen if this is still a problem.
[Bug c++/51270] missed warning about returning reference to temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51270
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
Depends on||60517
--- Comment #9 from Manuel López-Ibáñez ---
(In reply to Jonathan Wakely from comment #7)
> Here's a simpler testcase for the missed warning:
>
> const int& f(long l)
> {
> const int& i = l;
> return i;
> }
>
We now warn for this testcase because of the fixes in R60517.
test.cc:5:10: warning: function returns address of local variable
[-Wreturn-local-addr]
return i;
^
test.cc:4:18: note: declared here
const int& i = l;
^
I haven't tested the other testcases here, but it seems a duplicate.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
[Bug 60517] warning/error for taking address of member of a temporary object
[Bug c/50476] Warn of pointer set to object whose lifetime is limited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50476 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-17 Depends on||60517 Ever confirmed|0 |1 --- Comment #4 from Manuel López-Ibáñez --- Possibly a duplicate of PR60517, but this testcase is slightly different (it involves assigning to global pointer and not a return statement). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517 [Bug 60517] warning/error for taking address of member of a temporary object
[Bug c/45821] no warning when returning a local variable address within a statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45821
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-09-18
CC||manu at gcc dot gnu.org
Depends on||60517
Ever confirmed|0 |1
--- Comment #4 from Manuel López-Ibáñez ---
(In reply to Andrew Gaul from comment #3)
> int *function_return_local(void)
> {
> int x = 0;
> return &x;
> }
>
> int *statement_expression_return_local(void)
> {
> int *y = ({
> int x = 0;
> &x;
> });
> return y;
> }
We now warn at -O2:
test.c:14:10: warning: function returns address of local variable
[-Wreturn-local-addr]
return y;
^
test.c:11:11: note: declared here
int x = 0;
^
but only because we return y. For this testcase,
int statement_expression_return_local(void)
{
int *y = ({
int x = 0;
&x;
});
return *y;
}
we get:
test.c:14:10: warning: ‘x’ is used uninitialized in this function
[-Wuninitialized]
return *y;
^
which is a bit confusing (and not the same warning).
Possibly related to 60517.
it would be good to add the testcase
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
[Bug 60517] warning/error for taking address of member of a temporary object
[Bug middle-end/24786] Missing warning on questionable use of parameter to initialize static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24786
Manuel López-Ibáñez changed:
What|Removed |Added
Last reconfirmed|2005-11-11 17:59:15 |2015-9-18
CC||manu at gcc dot gnu.org
Component|c++ |middle-end
Version|4.1.0 |6.0
--- Comment #3 from Manuel López-Ibáñez ---
GCC generates code like this:
const char *names[1];
const char *blah2() {
char x = 7;
if (first_time)
names[0] = { &x };
return names[0];
}
and we end up returning:
# .MEM_1 = PHI <.MEM_4(2), .MEM_9(4), .MEM_6(3)>
[test.c:5:17] # VUSE <.MEM_1>
# PT = nonlocal escaped { D.2254 } (escaped)
_10 = [test.c:5:17] _ZZ5blah2vE5namesD.2255[0];
# .MEM_11 = VDEF <.MEM_1>
xD.2254 ={v} {CLOBBER};
[test.c:5:17] # VUSE <.MEM_11>
return _10;
;;succ: EXIT [100.0%]
While in the non-static case we propagate &x:
;; basic block 2, loop depth 0, count 0, freq 1, maybe hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE)
;;pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE)
;; starting at line 5
# .MEM_2 = VDEF <.MEM_1(D)>
xD.2254 ={v} {CLOBBER};
[test.c:5:17] # VUSE <.MEM_2>
return &xD.2254;
;;succ: EXIT [100.0%]
This seems like a missed optimization.
Somehow related to PR60517.
[Bug c++/17729] [4.9/5/6 Regression] Duplicate __attribute__((deprecated)) warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729 Manuel López-Ibáñez changed: What|Removed |Added Last reconfirmed|2006-02-01 04:38:45 |2015-9-18 --- Comment #36 from Manuel López-Ibáñez --- Still valid. Patch doesn't apply anymore. test.cc:6:3: warning: ‘void func()’ is deprecated [-Wdeprecated-declarations] func(); ^ test.cc:3:6: note: declared here void func(void) __attribute__((deprecated)); ^ test.cc:6:8: warning: ‘void func()’ is deprecated [-Wdeprecated-declarations] func(); ^ test.cc:3:6: note: declared here void func(void) __attribute__((deprecated)); ^ We give one warning for "func" and another for "func()". Breakpoint 6, warn_deprecated_use (node=node@entry=0x7658bd20, attr=, attr@entry=0x0) at /home/manuel/test1/pristine/gcc/tree.c:12338 (gdb) bt #0 warn_deprecated_use (node=node@entry=0x7658bd20, attr=, attr@entry=0x0) at /home/manuel/test1/pristine/gcc/tree.c:12338 #1 0x006c8a69 in mark_used (decl=decl@entry=0x7658bd20, complain=complain@entry=3) at /home/manuel/test1/pristine/gcc/cp/decl2.c:5085 #2 0x006c973a in mark_used (decl=decl@entry=0x7658bd20) at /home/manuel/test1/pristine/gcc/cp/decl2.c:5255 #3 0x0077ed79 in finish_id_expression (id_expression=0x765998f0, decl=0x7658bd20, scope=0x0, idk=0x7fffdc34, integral_constant_expression_p=, allow_non_integral_constant_expression_p=, non_integral_constant_expression_p=0x76433a4d, template_p=false, done=false, address_p=false, template_arg_p=false, error_msg=0x7fffdbc8, location=648) at /home/manuel/test1/pristine/gcc/cp/semantics.c:3607 #4 0x006e9e66 in cp_parser_primary_expression (parser=parser@entry=0x76433a20, address_p=address_p@entry=false, cast_p=cast_p@entry=false, template_arg_p=template_arg_p@entry=false, decltype_p=decltype_p@entry=false, idk=idk@entry=0x7fffdc34) at /home/manuel/test1/pristine/gcc/cp/parser.c:4817 #5 0x006f646c in cp_parser_postfix_expression (parser=parser@entry=0x76433a20, address_p=address_p@entry=false, cast_p=cast_p@entry=false, member_access_only_p=member_access_only_p@entry=false, decltype_p=false, pidk_return=pidk_return@entry=0x0) at /home/manuel/test1/pristine/gcc/cp/parser.c:6201 (gdb) c Continuing. /home/manuel/test.cc:6:3: warning: ‘void func()’ is deprecated [-Wdeprecated-declarations] func(); ^ /home/manuel/test.cc:3:6: note: declared here void func(void) __attribute__((deprecated)); ^ Breakpoint 6, warn_deprecated_use (node=node@entry=0x7658bd20, attr=, attr@entry=0x0) at /home/manuel/test1/pristine/gcc/tree.c:12338 (gdb) bt #0 warn_deprecated_use (node=node@entry=0x7658bd20, attr=, attr@entry=0x0) at /home/manuel/test1/pristine/gcc/tree.c:12338 #1 0x006c8a69 in mark_used (decl=decl@entry=0x7658bd20, complain=complain@entry=3) at /home/manuel/test1/pristine/gcc/cp/decl2.c:5085 #2 0x005de657 in build_over_call (cand=, flags=1, complain=complain@entry=3) at /home/manuel/test1/pristine/gcc/cp/call.c:7578 #3 0x005ed620 in build_new_function_call (fn=fn@entry=0x7658bd20, args=args@entry=0x7fffdc38, koenig_p=koenig_p@entry=false, complain=complain@entry=3) at /home/manuel/test1/pristine/gcc/cp/call.c:4136 #4 0x007776bf in finish_call_expr (fn=fn@entry=0x7658bd20, args=args@entry=0x7fffdc38, disallow_virtual=disallow_virtual@entry=false, koenig_p=, complain=3) at /home/manuel/test1/pristine/gcc/cp/semantics.c:2391 #5 0x006f651a in cp_parser_postfix_expression (parser=parser@entry=0x76433a20, address_p=address_p@entry=false, cast_p=cast_p@entry=false, member_access_only_p=member_access_only_p@entry=false, decltype_p=false, pidk_return=pidk_return@entry=0x0) at /home/manuel/test1/pristine/gcc/cp/parser.c:6419
[Bug libgcc/66883] config/epiphany/udivsi3-float.c:52: bad if test ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66883 Manuel López-Ibáñez changed: What|Removed |Added Target||epiphany CC||amylaar at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez --- David, you may need to CC the target maintainer for bugs in minor targets. They do not follow gcc-bugs or peruse bugzilla.
[Bug target/53712] Does not combine unaligned load with _mm_cmpistri, redundant instruction at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53712 Marco Leise changed: What|Removed |Added CC||Marco.Leise at gmx dot de --- Comment #9 from Marco Leise --- If this was fixed three years ago, then how does the same test program produce this assembly with gcc 5.2.0 (and earlier)? Dump of assembler code for function test: 0x00400596 <+0>: push rbp 0x00400597 <+1>: movrbp,rsp 0x0040059a <+4>: movQWORD PTR [rbp-0x28],rdi 0x0040059e <+8>: movQWORD PTR [rbp-0x30],rsi 0x004005a2 <+12>:movrax,QWORD PTR [rbp-0x30] 0x004005a6 <+16>:movQWORD PTR [rbp-0x18],rax 0x004005aa <+20>:movrax,QWORD PTR [rbp-0x18] 0x004005ae <+24>:movdqu xmm0,XMMWORD PTR [rax] 0x004005b2 <+28>:movaps XMMWORD PTR [rbp-0x10],xmm0 0x004005b6 <+32>:movrax,QWORD PTR [rbp-0x28] => 0x004005ba <+36>:movdqa xmm0,XMMWORD PTR [rax] 0x004005be <+40>:movdqa xmm1,xmm0 0x004005c2 <+44>:movdqa xmm0,XMMWORD PTR [rbp-0x10] 0x004005c7 <+49>:pcmpistri xmm0,xmm1,0x0 0x004005cd <+55>:moveax,ecx 0x004005cf <+57>:pcmpistrm xmm0,xmm1,0x0 0x004005d5 <+63>:poprbp 0x004005d6 <+64>:ret gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/5.2.0/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/5.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-5.2.0/work/gcc-5.2.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/5.2.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.2.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.2.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.2.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.2.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.2.0/include/g++-v5 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/5.2.0/python --enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 5.2.0 p1.1, pie-0.6.4' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libquadmath --enable-lto --without-isl --enable-libsanitizer Thread model: posix gcc version 5.2.0 (Gentoo 5.2.0 p1.1, pie-0.6.4)
