[Bug c++/77430] warn about redundant assignments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77430 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Do we want to warn about this kind of stuff even if there are side-effects in the first rhs? Obviously we must not warn if the var is used in the second rhs, or if the var is volatile/atomic, or if assignment operator is overloaded. The question is where to warn, warning in the FE would have the advantage that the rhs's are still fairly non-optimized and thus possible uses of the var in them aren't optimized away yet.
[Bug target/77439] New: [6/7 regression] wrong code for sibcall with longcall, APCS frame and VFP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77439
Bug ID: 77439
Summary: [6/7 regression] wrong code for sibcall with
longcall, APCS frame and VFP
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ebotcazou at gcc dot gnu.org
Target Milestone: ---
Created attachment 39531
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39531&action=edit
Testcase
The following change:
2014-04-25 Jiong Wang
* config/arm/predicates.md (call_insn_operand): Add long_call check.
* config/arm/arm.md (sibcall, sibcall_value): Force the address to
reg for long_call.
* config/arm/arm.c (arm_function_ok_for_sibcall): Remove long_call
restriction.
has introduced a bug for sibcalls with longcall, APCS frame and VFP. For a
longcall, any sibcall becomes an indirect sibcall and therefore requires
a register to hold the target address. Now if all the argument registers are
taken, this register will be IP but, for APCS frames and VFP, IP can be used
in the sibcall epilogue to restore the VFP registers, so the target address is
overwritten and the call goes astray. Testcase attached, compile it with e.g.
-mapcs-frame -mfloat-abi=soft -O -foptimize-sibling-calls -ffunction-sections
and you'll see for arm-eabi:
sub ip, fp, #36
vldmip!, {d8}
sub sp, fp, #28
ldmfd sp, {r4, r5, r6, r7, fp, sp, lr}
bx ip
[Bug testsuite/77418] SELECT TYPE associating entity can be (de)allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77418 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|fortran |testsuite Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed on trunk.
[Bug fortran/77420] [5/6/7 Regression] gfortran and equivalence produces internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77420 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.5
[Bug other/77421] Bugs found in GCC with the help of PVS-Studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421 --- Comment #11 from Richard Biener --- (In reply to Jonathan Wakely from comment #5) > Remaining issues: > > find_structure in gengtype.c does: > > structures = s; > s->kind = kind; > s->u.s.tag = name; > structures = s; > > The first assignment is redundant. > > ix86_expand_args_builtin in gcc/config/i386/i386.c does: > > case V8DI_FTYPE_V8DI_V8DI_V8DI_INT_UQI: > case V16SI_FTYPE_V16SI_V16SI_V16SI_INT_UHI: > case V2DF_FTYPE_V2DF_V2DF_V2DI_INT_UQI: > case V4SF_FTYPE_V4SF_V4SF_V4SI_INT_UQI: > case V8SF_FTYPE_V8SF_V8SF_V8SI_INT_UQI: > case V8SI_FTYPE_V8SI_V8SI_V8SI_INT_UQI: > case V4DF_FTYPE_V4DF_V4DF_V4DI_INT_UQI: > case V4DI_FTYPE_V4DI_V4DI_V4DI_INT_UQI: > case V4SI_FTYPE_V4SI_V4SI_V4SI_INT_UQI: > case V2DI_FTYPE_V2DI_V2DI_V2DI_INT_UQI: >nargs = 5; > nargs = 5; > > The first one is redundant, and wrongly indented. > > cand_value_at in tree-ssa-loop-ivopts.c does: > > tree type = TREE_TYPE (iv->base); > tree steptype = type; > if (POINTER_TYPE_P (type)) > steptype = sizetype; > steptype = unsigned_type_for (type); > > It's unclear why the last four lines aren't just: > > tree steptype = unsigned_type_for (type); it should be if (POINTER_TYPE_P (type)) steptype = sizetype else steptype = unsigned_type_for (type);
[Bug middle-end/77422] -fdata-sections should put each constant in its own section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77422 --- Comment #6 from Richard Biener --- I agree with Jakub.
[Bug target/77439] [6/7 regression] wrong code for sibcall with longcall, APCS frame and VFP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77439 Jiong Wang changed: What|Removed |Added Assignee|jiwang at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #1 from Jiong Wang --- Reset Assignee as Eric has proposed the fix: https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02131.html
[Bug c/68687] C compiler options to ignore all const qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68687 --- Comment #1 from Andrew Pinski --- -Dconst= should work, right?
[Bug tree-optimization/77424] Identical statements in if-else branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77424
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-09-01
CC||law at gcc dot gnu.org
Version|7.0 |6.2.1
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
Of course conservatively correct (give up) ... the big comment before the block
doesn't match the code in any way, esp. I can't find
As a compromise for the latter case, if the thread path ends in
a block where the last statement is a multiway branch, then go
ahead and thread it, else ignore it. */
that obviously doesn't match the "thread into the loop" check. On the gcc 5
branch we had a
else if (bb_ends_with_multiway_branch (path->last ()->e->src))
{
...
}
inbetween and I suppose the refactoring of FSM vs. non-FSM theading simply
left this now dead code / comment around...
Jeff?
[Bug testsuite/77418] SELECT TYPE associating entity can be (de)allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77418 Paul Thomas changed: What|Removed |Added Keywords||accepts-invalid Status|RESOLVED|NEW Resolution|FIXED |--- --- Comment #4 from Paul Thomas --- (In reply to Richard Biener from comment #3) > Fixed on trunk. gfortran still accepts non-standard code, though. However, the testcase has been made to comply. Not quite fixed. I have a patch but I am checking with various folk to understand precisely what the standard is here. The draft F2008 that is posted on the GFortran wiki is not exaactly clear about this point. Evidently the WG posted some clarifications. Paul
[Bug target/77438] MMX intrinsic on x86_64 generates bloated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77438 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-01 Version|4.8.4 |6.2.1 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- For using the vector extension vector lowering is faced with the backend claiming that v8qi is not supported thus it uses generic integers to implement vector support (better than doing it component-wise). Note that the args are still passed in SSE registers (or MMX regs with SSE disabled but MMX enabled). I belive that's on purpose because the compiler cannot introduce MMX usage because of the overlap with the x87 register stack. Thus indeed - do not use MMX. I believe there is no attempt being made to improve code generation for the (obsolete) MMX CPU feature. For vector lowering instead of falling back to integer ops support we can also fall back to using a larger vector size (maybe controlled by a target hook). Vector lowering would need to fill the excess elements with proper values of course (not zero in case it is used in a division for example).
[Bug middle-end/77426] Duplicate condition in expmed.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77426 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org --- Comment #3 from ktkachov at gcc dot gnu.org --- I'll fix it up when I get a moment (the duplicate code in expmed.c I mean)
[Bug target/77438] MMX intrinsic on x86_64 generates bloated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77438 --- Comment #3 from Uroš Bizjak --- (In reply to Richard Biener from comment #2) > I belive that's on purpose because the compiler cannot introduce MMX > usage because of the overlap with the x87 register stack. True. It is even worse, x87 stack gets disbled (all values are NaNs) as soon as MMX reg is touched, and stays disabled until EMMS is executed. > Thus indeed - do not use MMX. I believe there is no attempt being made > to improve code generation for the (obsolete) MMX CPU feature. Register allocator is fine-tuned to avoid MMX registers unless there is really no other way to handle the value. The compiler is actually walking on the edge in order to provide correct functionality, not optimized code. I can assure you that nobody will touch these tunings, so this missed-optimization PR is WONTFIX as far as x86 backend is concerned. > For vector lowering instead of falling back to integer ops support we can > also fall back to using a larger vector size (maybe controlled by a target > hook). Vector lowering would need to fill the excess elements with proper > values of course (not zero in case it is used in a division for example). Maybe we should keep the PR open to track the above idea.
[Bug middle-end/77436] [5/6/7 Regression] Incorrect constant result for summing loop inserted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77436
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Component|c |middle-end
Known to work||4.9.4
Target Milestone|--- |5.5
Summary|Incorrect constant result |[5/6/7 Regression]
|for summing loop inserted |Incorrect constant result
||for summing loop inserted
--- Comment #4 from Richard Biener ---
Confirmed, caused by SCCP (or SCEV/niter analysis):
Analyzing # of iterations of loop 1
exit condition [-2147483645, + , 1] != 2147483647
bounds on difference of bases: 4294967292 ... 4294967292
result:
# of iterations 4294967292, bounded by 4294967292
Replacing uses of: sum_11 with: 2147483648
while it computes correctly the evolution of the sum IV:
{0, +, {2147483650, +, 1}_1}_1
somehow the exit PHI value is computed as 2147483648 by
compute_overall_effect_of_inner_loop on that IV + x
{2147483650, +, {2147483651, +, 1}_1}_1
number of latch executions is computed as 4294967292.
We run into chrec_evaluate with the above where binominal coeff evaluation
checks for overflow in the signed type but the computation in chrec_evaluate
doing
arg0 = fold_build2 (MULT_EXPR, type,
CHREC_LEFT (chrec), binomial_n_k);
has no such checks. On the GCC 4.9 branch we fail:
(chrec_apply
(varying_loop = 1
)
(chrec = {2147483650, +, {2147483651, +, 1}_1}_1)
(x = 4294967292)
(res = scev_not_known))
not replacing:
sum_2 = PHI
thus this is a regression with the wide-int conversion somehow.
[Bug libfortran/77393] [7 Regression] Revision r237735 changed the behavior of F0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77393 --- Comment #3 from Dominique d'Humieres --- At revision r239908 the second test in comment 0 still gives ** Program received signal SIGSEGV: Segmentation fault - invalid memory reference. at run time.
[Bug c++/77440] New: [[noreturn]] does not work at end of main().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77440
Bug ID: 77440
Summary: [[noreturn]] does not work at end of main().
Product: gcc
Version: 5.4.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kataoka-instructor at ka2 dot so-net.ne.jp
Target Milestone: ---
First, I know Bug ID 52003.
Why need warning about evident dead code?
[[noreturn]]
int main()
{
while(true)
{
//do something...
}
} //the attribute cannot remove implicit 'return 0;' from here.
sample.cpp: In function 'int main()':
sample.cpp:8:1: warning: function declared 'noreturn' has a 'return' statement
} //the attribute cannot remove implicit 'return 0;' from here.
^
[Bug target/77281] [ARM] Wrong code generated for move of constant vector with mix of signed and unsigned zeros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77281 --- Comment #3 from mwahab at gcc dot gnu.org --- Author: mwahab Date: Thu Sep 1 08:57:21 2016 New Revision: 239918 URL: https://gcc.gnu.org/viewcvs?rev=239918&root=gcc&view=rev Log: [ARM] Fix an invalid check for vectors of the same floating-point constants. 2016-09-01 Matthew Wahab PR target/77281 * config/arm/arm.c (neon_valid_immediate): Delete declaration. Use const_vec_duplicate to check for duplicated elements. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/arm/arm.c
[Bug target/77439] [6/7 regression] wrong code for sibcall with longcall, APCS frame and VFP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77439 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.3
[Bug target/77441] New: Cygwin64: g++ linker: infinite loop when linking a shared library from objects compiled with std=c++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77441 Bug ID: 77441 Summary: Cygwin64: g++ linker: infinite loop when linking a shared library from objects compiled with std=c++14 Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zosrothko at orange dot fr Target Milestone: --- Created attachment 39532 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39532&action=edit The g++ command produced by make upon linking the PocoDatad.dll Hello On a Cygwin64 system, the g++ linker is looping when linking a shared library from objects compiled with the std=c++14 option. Context: $ uname -a CYGWIN_NT-10.0 idefix 2.6.0(0.304/5/3) 2016-08-31 14:32 x86_64 Cygwin $ gcc -v Utilisation des specs internes. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/lto-wrapper.exe Cible : x86_64-pc-cygwin Configuré avec: /cygdrive/i/szsz/tmpp/gcc/gcc-5.4.0-1.x86_64/src/gcc-5.4.0/configure --srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-5.4.0-1.x86_64/src/gcc-5.4.0 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libcilkrts --enable-libgomp --enable-libitm --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-libada --enable-libgcj-sublibs --disable-java-awt --disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible Modèle de thread: posix gcc version 5.4.0 (GCC) This issue is always reproducible but I was not able to reduce the number of objects to reproduce it. Here the way to get the ussie 1/ git clone -b c++11 https://github.com/Kampbell/poco.git poco-c++11 2/ cd poco-c++11 3/ ./configure --minimal --no-tests --no-samples 4/ vim config.make 5/ Remove 'Data' from the OMIT value at line 7 6/ save and exit from vim 7/ make After compiling Foundation, Util, XML, Jason and Net modules, the make compiles the Data module and loops upon linking the PocoDatad.dll The building process takes some time, so be patient before arrinving to the problem
[Bug ada/71911] [Cygwin] "gnatclean program" will remove the standard package .ali file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71911 --- Comment #4 from 鍾 --- (In reply to Eric Botcazou from comment #3) > > I use the administrator user and administrator permissions in Windows host, > > so, normally I use the same permission map to root permissions in Cygwin > > host. > > Please double check the permissions of the ALI files, they should be > read-only. -rw-r--r-- 1 Administrator None 1.7K 六月 14 00:12 a-assert.ali -rw-r--r-- 1 Administrator None 16K 六月 14 00:12 a-btgbso.ali -rw-r--r-- 1 Administrator None 2.7K 六月 14 00:12 a-calari.ali -rw-r--r-- 1 Administrator None 4.2K 六月 14 00:12 a-calcon.ali -rw-r--r-- 1 Administrator None 3.3K 六月 14 00:12 a-caldel.ali -rw-r--r-- 1 Administrator None 20K 六月 14 00:12 a-calend.ali -rw-r--r-- 1 Administrator None 15K 六月 14 00:12 a-calfor.ali -rw-r--r-- 1 Administrator None 2.0K 六月 14 00:12 a-catizo.ali -rw-r--r-- 1 Administrator None 38K 六月 14 00:12 a-cbdlli.ali I am the Administrator.
[Bug middle-end/77436] [5/6/7 Regression] Incorrect constant result for summing loop inserted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77436 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener --- As usual this is sign-extension behavior of wide-ints that does not exactly match double-ints. tree_fold_binomial likes to do infinite precision math. The int_fits_type_p check below is not effective as wide_int_to_tree truncates the value to be in-range. /* Result = Numerator / Denominator. */ wide_int di_res = wi::udiv_trunc (num, denom); res = wide_int_to_tree (type, di_res); return int_fits_type_p (res, type) ? res : NULL_TREE; I have a patch restoring previous behavior. IMHO the whole chrec_evaluate should use GMP, there is no need to give up - the final truncation is still valid.
[Bug c++/77442] New: error: ‘free’ is not a member of ‘std’ std::free(ptr);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77442 Bug ID: 77442 Summary: error: ‘free’ is not a member of ‘std’ std::free(ptr); Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: manishthatte at hotmail dot com Target Milestone: --- Created attachment 39533 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39533&action=edit make.log
[Bug ada/71911] [Cygwin] "gnatclean program" will remove the standard package .ali file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71911 --- Comment #5 from Eric Botcazou --- > -rw-r--r-- 1 Administrator None 1.7K 六月 14 00:12 a-assert.ali > -rw-r--r-- 1 Administrator None 16K 六月 14 00:12 a-btgbso.ali > -rw-r--r-- 1 Administrator None 2.7K 六月 14 00:12 a-calari.ali > -rw-r--r-- 1 Administrator None 4.2K 六月 14 00:12 a-calcon.ali > -rw-r--r-- 1 Administrator None 3.3K 六月 14 00:12 a-caldel.ali > -rw-r--r-- 1 Administrator None 20K 六月 14 00:12 a-calend.ali > -rw-r--r-- 1 Administrator None 15K 六月 14 00:12 a-calfor.ali > -rw-r--r-- 1 Administrator None 2.0K 六月 14 00:12 a-catizo.ali > -rw-r--r-- 1 Administrator None 38K 六月 14 00:12 a-cbdlli.ali OK, that's the bug, there should be no 'w' at all. You need to find out what happens during 'make install', the Makefile issues: $(CHMOD) a-wx $(RTSDIR)/*.ali
[Bug c++/77427] [6/7 Regression] ice when canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77427 Richard Biener changed: What|Removed |Added Priority|P3 |P1 CC||vries at gcc dot gnu.org Known to work||6.2.0 Target Milestone|--- |6.3 Summary|[7 Regression] ice when |[6/7 Regression] ice when |canonical types differ for |canonical types differ for |identical types |identical types --- Comment #2 from Richard Biener --- Recent regression also present now on the GCC 6 branch.
[Bug tree-optimization/77438] Vector lowering should also consider larger vector sizes (MMX -> SSE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77438 Richard Biener changed: What|Removed |Added Component|target |tree-optimization Summary|MMX intrinsic on x86_64 |Vector lowering should also |generates bloated code |consider larger vector ||sizes (MMX -> SSE) --- Comment #4 from Richard Biener --- Good idea - summary changed to reflect this.
[Bug ada/71911] [Cygwin] "gnatclean program" will remove the standard package .ali file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71911 --- Comment #6 from 鍾 --- (In reply to Eric Botcazou from comment #5) > > -rw-r--r-- 1 Administrator None 1.7K 六月 14 00:12 a-assert.ali > > -rw-r--r-- 1 Administrator None 16K 六月 14 00:12 a-btgbso.ali > > -rw-r--r-- 1 Administrator None 2.7K 六月 14 00:12 a-calari.ali > > -rw-r--r-- 1 Administrator None 4.2K 六月 14 00:12 a-calcon.ali > > -rw-r--r-- 1 Administrator None 3.3K 六月 14 00:12 a-caldel.ali > > -rw-r--r-- 1 Administrator None 20K 六月 14 00:12 a-calend.ali > > -rw-r--r-- 1 Administrator None 15K 六月 14 00:12 a-calfor.ali > > -rw-r--r-- 1 Administrator None 2.0K 六月 14 00:12 a-catizo.ali > > -rw-r--r-- 1 Administrator None 38K 六月 14 00:12 a-cbdlli.ali > > OK, that's the bug, there should be no 'w' at all. > > You need to find out what happens during 'make install', the Makefile issues: > > $(CHMOD) a-wx $(RTSDIR)/*.ali Thanks.
[Bug tree-optimization/77438] Vector lowering should also consider larger vector sizes (MMX -> SSE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77438 --- Comment #5 from Richard Biener --- Profitability also depends on the ABI in this case as well as the ability to do the required extensions/extractions (and resource availability). For bit operations that directly map to the integer representation it will likely be a loss unless you consider ABI. As said in another PR vector lowering should be re-written to sth tree-complex.c like, with a lattice that allows to optimize insertion of extensions/extracts (and also could track cost of parameter / return value transform).
[Bug rtl-optimization/77425] Pointer test follows dereference in sched-int.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77425 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 39534 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39534&action=edit gcc7-pr77425.patch Untested fix. I believe if we are going to return false, then nothing is/should be looking at the iterator object anymore, at least all other uses of linkp field dereference it anyway and for NULL list &list->first gives an UB NULL pointer.
[Bug c++/77443] New: Empty initializer on huge object array member slow down the compilation dramatically with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77443
Bug ID: 77443
Summary: Empty initializer on huge object array member slow
down the compilation dramatically with -O1
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at gyoo dot com
Target Milestone: ---
Adding an empty initializer on a huge array is multiplying the compilation time
by about x100 when using -O1:
// time g++ -std=c++14 -O1 -Wall initialization.cc
class MyObject
{
public:
MyObject() {}
};
class MyClassFast
{
MyObject array[3]; // ok: fast to build with -O1
};
class MyClassSlow
{
MyObject array[3] {}; // problem: super slow to build with -O1
(x100 slower than the fast version)
};
int main()
{
//MyClassFast fast;
MyClassSlow slow;
}
Was working fine with gcc4.9.3. Having this slow behaviour for gcc5.2.0,
gcc5.3.0 and gcc5.4.0
Looks like gcc is trying to unroll the constructor for each item of the array.
For instance if the constructor of MyObject is marked private instead of
public, the compilation will generate 30k (number of elements in the array)
compilation error messages.
[Bug rtl-optimization/77425] Pointer test follows dereference in sched-int.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77425
--- Comment #3 from Jonathan Wakely ---
(In reply to Manuel López-Ibáñez from comment #1)
> There is also this example:
>
> odr_type
> get_odr_type (tree type, bool insert)
> {
>
> odr_types[val->id] = 0;
> gcc_assert (val->derived_types.length() == 0);
> if (odr_types_ptr)
> val->id = odr_types.length ();
>
> }
>
> which is even more insidious since it is hidden behind macros.
Yes that obfuscating macro seems like a horrible idea.
[Bug target/71910] ICE on valid OpenMP code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71910 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Thu Sep 1 11:29:55 2016 New Revision: 239922 URL: https://gcc.gnu.org/viewcvs?rev=239922&root=gcc&view=rev Log: Backported from mainline 2016-08-16 Jakub Jelinek PR target/71910 * tree-cfg.c (execute_fixup_cfg): Add node variable, use it. Before inlining, add cgraph edge for the added __builtin_unreachable call. * g++.dg/gomp/pr71910.C: New test. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/gomp/pr71910.C Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-cfg.c
[Bug middle-end/77259] [6/7 Regression] ICE in emit_move_insn since r232167
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77259 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Thu Sep 1 11:36:50 2016 New Revision: 239924 URL: https://gcc.gnu.org/viewcvs?rev=239924&root=gcc&view=rev Log: Backported from mainline 2016-08-17 Jakub Jelinek PR middle-end/77259 * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): If turning a call into __builtin_unreachable-like noreturn call, adjust gimple_call_set_fntype. * tree-cfgcleanup.c (fixup_noreturn_call): Remove lhs also if gimple_call_fntype has void return type. * g++.dg/ipa/devirt-52.C: New test. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/ipa/devirt-52.C Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-cfgcleanup.c branches/gcc-6-branch/gcc/tree-ssa-pre.c
[Bug fortran/69281] gfortran ICE on temporary array in function call with -fstack-arrays -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69281 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Thu Sep 1 11:38:16 2016 New Revision: 239926 URL: https://gcc.gnu.org/viewcvs?rev=239926&root=gcc&view=rev Log: Backported from mainline 2016-08-19 Jakub Jelinek PR fortran/69281 * trans-openmp.c (gfc_trans_omp_parallel, gfc_trans_omp_task, gfc_trans_omp_target): Wrap gfc_trans_omp_code result in an extra BIND_EXPR with its own forced BLOCK. * gfortran.dg/gomp/pr69281.f90: New test. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/gomp/pr69281.f90 Modified: branches/gcc-6-branch/gcc/fortran/ChangeLog branches/gcc-6-branch/gcc/fortran/trans-openmp.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug fortran/72744] ICE in verify_ssa, at tree-ssa.c:1039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72744 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Thu Sep 1 11:38:57 2016 New Revision: 239927 URL: https://gcc.gnu.org/viewcvs?rev=239927&root=gcc&view=rev Log: Backported from mainline 2016-08-19 Jakub Jelinek PR fortran/72744 * gfortran.dg/gomp/pr72744.f90: New test. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/gomp/pr72744.f90 Modified: branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71014 --- Comment #12 from Jakub Jelinek --- Author: jakub Date: Thu Sep 1 11:41:34 2016 New Revision: 239928 URL: https://gcc.gnu.org/viewcvs?rev=239928&root=gcc&view=rev Log: Backported from mainline 2016-08-19 Jakub Jelinek PR fortran/71014 * resolve.c (gfc_resolve): For ns->construct_entities don't save, clear and restore omp state around the resolving. * testsuite/libgomp.fortran/pr71014.f90: New test. Added: branches/gcc-6-branch/libgomp/testsuite/libgomp.fortran/pr71014.f90 Modified: branches/gcc-6-branch/gcc/fortran/ChangeLog branches/gcc-6-branch/gcc/fortran/resolve.c branches/gcc-6-branch/libgomp/ChangeLog
[Bug tree-optimization/77444] New: Bogus assignments in cand_value_at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77444 Bug ID: 77444 Summary: Bogus assignments in cand_value_at Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Blocks: 77421 Target Milestone: --- From PR 77421 (In reply to Richard Biener from comment #11) > (In reply to Jonathan Wakely from comment #5) > > cand_value_at in tree-ssa-loop-ivopts.c does: > > > > tree type = TREE_TYPE (iv->base); > > tree steptype = type; > > if (POINTER_TYPE_P (type)) > > steptype = sizetype; > > steptype = unsigned_type_for (type); > > > > It's unclear why the last four lines aren't just: > > > > tree steptype = unsigned_type_for (type); > > it should be > > if (POINTER_TYPE_P (type)) > steptype = sizetype > else > steptype = unsigned_type_for (type); Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421 [Bug 77421] Bugs found in GCC with the help of PVS-Studio
[Bug middle-end/77377] [7 Regression] c-c++-common/pr59037.c ICEs with -fpic -msse on i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77377 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Thu Sep 1 11:42:22 2016 New Revision: 239929 URL: https://gcc.gnu.org/viewcvs?rev=239929&root=gcc&view=rev Log: Backported from mainline 2016-08-30 Jakub Jelinek PR middle-end/77377 * simplify-rtx.c (avoid_constant_pool_reference): For out of bounds constant pool reference return x instead of c. * gcc.target/i386/pr77377.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr77377.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/simplify-rtx.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug c++/77363] [5/6 Regression] Missing debug information in DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77363 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Thu Sep 1 11:43:15 2016 New Revision: 239930 URL: https://gcc.gnu.org/viewcvs?rev=239930&root=gcc&view=rev Log: Backported from mainline 2016-08-30 Jakub Jelinek PR debug/77363 * dwarf2out.c (modified_type_die): Use lookup_type_die (type) instead of lookup_type_die (type_main_variant (type)) even for array types. * g++.dg/debug/dwarf2/pr77363.C: New test. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/debug/dwarf2/pr77363.C Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/dwarf2out.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug other/77421] Bugs found in GCC with the help of PVS-Studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421 --- Comment #12 from Jonathan Wakely --- (In reply to Richard Biener from comment #11) > (In reply to Jonathan Wakely from comment #5) > > cand_value_at in tree-ssa-loop-ivopts.c does: > > > > tree type = TREE_TYPE (iv->base); > > tree steptype = type; > > if (POINTER_TYPE_P (type)) > > steptype = sizetype; > > steptype = unsigned_type_for (type); > > > > It's unclear why the last four lines aren't just: > > > > tree steptype = unsigned_type_for (type); > > it should be > > if (POINTER_TYPE_P (type)) > steptype = sizetype > else > steptype = unsigned_type_for (type); This is now PR 77444
[Bug tree-optimization/72866] Compile time hog w/ -O3 (-Ofast)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72866 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Thu Sep 1 11:46:57 2016 New Revision: 239931 URL: https://gcc.gnu.org/viewcvs?rev=239931&root=gcc&view=rev Log: Backported from mainline 2016-08-30 Jakub Jelinek PR tree-optimization/72866 * tree-vect-patterns.c (search_type_for_mask): Turn into a small wrapper, move all code to ... (search_type_for_mask_1): ... this new function. Add caching and adjust recursive calls. * gcc.dg/vect/pr72866.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.dg/vect/pr72866.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-vect-patterns.c
[Bug fortran/77374] [6/7 Regression] ICE in resolve_omp_atomic, at fortran/openmp.c:3949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77374 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Thu Sep 1 11:48:02 2016 New Revision: 239932 URL: https://gcc.gnu.org/viewcvs?rev=239932&root=gcc&view=rev Log: Backported from mainline 2016-08-31 Jakub Jelinek PR fortran/77374 * parse.c (parse_omp_oacc_atomic): Copy over cp->ext.omp_atomic to cp->block->ext.omp_atomic. * resolve.c (gfc_resolve_blocks): Assert block with one or two EXEC_ASSIGNs for EXEC_*_ATOMIC. * openmp.c (resolve_omp_atomic): Don't assert one or two EXEC_ASSIGNs, instead return quietly for EXEC_NOPs and otherwise error unexpected statements. PR fortran/77374 * gfortran.dg/gomp/pr77374.f08: New test. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/gomp/pr77374.f08 Modified: branches/gcc-6-branch/gcc/fortran/ChangeLog branches/gcc-6-branch/gcc/fortran/openmp.c branches/gcc-6-branch/gcc/fortran/parse.c branches/gcc-6-branch/gcc/fortran/resolve.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/77352] ICE: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77352 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Thu Sep 1 11:48:54 2016 New Revision: 239933 URL: https://gcc.gnu.org/viewcvs?rev=239933&root=gcc&view=rev Log: Backported from mainline 2016-08-31 Jakub Jelinek PR fortran/77352 * trans-openmp.c (gfc_trans_omp_parallel_workshare): Always add a BIND_EXPR with BLOCK around what gfc_trans_omp_workshare returns. * gfortran.dg/gomp/pr77352.f90: New test. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/gomp/pr77352.f90 Modified: branches/gcc-6-branch/gcc/fortran/ChangeLog branches/gcc-6-branch/gcc/fortran/trans-openmp.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug c++/77427] [6/7 Regression] ice when canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77427
Tom de Vries changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org
--- Comment #3 from Tom de Vries ---
Eliminated typedef:
...
void bar (__builtin_va_list &);
struct c
{
operator const __builtin_va_list &();
operator __builtin_va_list &();
};
void
foo (void) {
struct c c1;
bar (c1);
}
...
[Bug tree-optimization/77445] New: [7 Regression] Performance drop after r239219 on coremark test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445 Bug ID: 77445 Summary: [7 Regression] Performance drop after r239219 on coremark test Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ysrumyan at gmail dot com Target Milestone: --- We noticed huge (32%) performance drop on coremark-pro/core (former coremark benchmark) after http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=239219 The problem part is if (optimize_edge_for_speed_p (taken_edge)) which does not look correct since we have a lot of missed opportunities for jump threading optimization like: test.c.111t.thread2:FSM jump-thread path not considered: duplication of 4 insns is needed and optimizing for size. test.c.111t.thread2:FSM jump-thread path not considered: duplication of 4 insns is needed and optimizing for size. test.c.111t.thread2:FSM jump-thread path not considered: duplication of 4 insns is needed and optimizing for size. test.c.111t.thread2:FSM jump-thread path not considered: duplication of 4 insns is needed and optimizing for size. test.c.111t.thread2:FSM jump-thread path not considered: duplication of 4 insns is needed and optimizing for size. test.c.111t.thread2:FSM jump-thread path not considered: duplication of 4 insns is needed and optimizing for size. test.c.111t.thread2:FSM jump-thread path not considered: duplication of 5 insns is needed and optimizing for size. test.c.111t.thread2:FSM jump-thread path not considered: duplication of 5 insns is needed and optimizing for size. test.c.111t.thread2:FSM jump-thread path not considered: duplication of 5 insns is needed and optimizing for size. test.c.167t.thread3:FSM jump-thread path not considered: duplication of 5 insns is needed and optimizing for size. test.c.167t.thread3:FSM jump-thread path not considered: duplication of 5 insns is needed and optimizing for size. test.c.167t.thread3:FSM jump-thread path not considered: duplication of 5 insns is needed and optimizing for size. test.c.167t.thread3:FSM jump-thread path not considered: duplication of 5 insns is needed and optimizing for size. test.c.167t.thread3:FSM jump-thread path not considered: duplication of 5 insns is needed and optimizing for size. test.c.167t.thread3:FSM jump-thread path not considered: duplication of 5 insns is needed and optimizing for size. test.c.167t.thread3:FSM jump-thread path not considered: duplication of 4 insns is needed and optimizing for size. test.c.167t.thread3:FSM jump-thread path not considered: duplication of 4 insns is needed and optimizing for size. test.c.167t.thread3:FSM jump-thread path not considered: duplication of 4 insns is needed and optimizing for size. test.c.170t.thread4:FSM jump-thread path not considered: duplication of 5 insns is needed and optimizing for size. test.c.170t.thread4:FSM jump-thread path not considered: duplication of 5 insns is needed and optimizing for size. test.c.170t.thread4:FSM jump-thread path not considered: duplication of 5 insns is needed and optimizing for size. test.c.170t.thread4:FSM jump-thread path not considered: duplication of 5 insns is needed and optimizing for size. test.c.170t.thread4:FSM jump-thread path not considered: duplication of 5 insns is needed and optimizing for size. test.c.170t.thread4:FSM jump-thread path not considered: duplication of 5 insns is needed and optimizing for size. test.c.170t.thread4:FSM jump-thread path not considered: duplication of 4 insns is needed and optimizing for size. test.c.170t.thread4:FSM jump-thread path not considered: duplication of 4 insns is needed and optimizing for size. test.c.170t.thread4:FSM jump-thread path not considered: duplication of 4 insns is needed and optimizing for size. If we change it to if (!optimize_function_for_size_p (cfun)) performance is back. I attach the test-case to reproduce issue.
[Bug tree-optimization/77445] [7 Regression] Performance drop after r239219 on coremark test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445 --- Comment #1 from Yuri Rumyantsev --- Created attachment 39535 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39535&action=edit test-case to reproduce It is sufficient to compile it with -Ofast option.
[Bug web/69601] current/ redirect is off by at least a day
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69601 --- Comment #6 from Eric Gallager --- Seems to be fixed for September.
[Bug c++/77427] [6/7 Regression] ice when canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77427
--- Comment #4 from Tom de Vries ---
This fixes the ICE:
...
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 4531647..f13790f 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -10551,6 +10551,8 @@ ix86_build_builtin_va_list_64 (void)
TYPE_ATTRIBUTES (record) = tree_cons (get_identifier ("sysv_abi va_list"),
NULL_TREE, TYPE_ATTRIBUTES (record));
+ SET_TYPE_STRUCTURAL_EQUALITY (record);
+
/* The correct type is an array type of one element. */
return build_array_type (record, build_index_type (size_zero_node));
}
...
[Bug c++/25814] Request for warning for parser ambiguity of function declarations and variable declarations with initializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25814 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #8 from Eric Gallager --- Turns out there's actually an entire Wikipedia article on this issue: https://en.wikipedia.org/wiki/Most_vexing_parse It mentions that Scott Meyers talks about it in his "Effective STL" book, so maybe if GCC adds a -Wvexing-parse option, it could have it be automatically enabled by the -Weffc++ option.
[Bug rtl-optimization/77416] [7 Regression] LRA rematerializing use of CA reg across function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77416 --- Comment #4 from Pat Haugen --- Didn't really think of this before, but the call isn't necessarily the problem, addze sets the CA bit too. So it's invalid to remataterialize the addze after an addze.
[Bug middle-end/77436] [5/6/7 Regression] Incorrect constant result for summing loop inserted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77436 --- Comment #6 from Richard Biener --- Author: rguenth Date: Thu Sep 1 13:38:25 2016 New Revision: 239937 URL: https://gcc.gnu.org/viewcvs?rev=239937&root=gcc&view=rev Log: 2016-09-01 Richard Biener PR middle-end/77436 * tree-chrec.c (tree_fold_binomial): Use widest_int, properly check whether the result fits the desired result type. * gcc.dg/torture/pr77436.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr77436.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chrec.c
[Bug c++/77434] warn about suspicious precedence of ternary operator (?:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77434 Bernd Edlinger changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #4 from Bernd Edlinger --- (In reply to jos...@codesourcery.com from comment #1) > I think the key thing that makes this suspicious is the boolean context > combined with both halves of the conditional expression being constant. > A conditional expression with both halves constant in a boolean context > either always evaluates to the same value, as here, or could be replaced > simply by "(COND)" or "(!(COND))". > > Alternatively, a conditional expression in a boolean context where either > half is a constant that's not 0 or 1 is suspicious. I agree: <= for boolean seems questionable.
[Bug middle-end/77436] [5/6 Regression] Incorrect constant result for summing loop inserted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77436 Richard Biener changed: What|Removed |Added Known to work||7.0 Summary|[5/6/7 Regression] |[5/6 Regression] Incorrect |Incorrect constant result |constant result for summing |for summing loop inserted |loop inserted Known to fail||5.4.0, 6.2.0 --- Comment #7 from Richard Biener --- Fixed on trunk sofar.
[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467 --- Comment #12 from Jakub Jelinek --- Actually, firstprivate on _Atomic vars in target construct could be implemented just by forcing it into a temporary with non-_Atomic qualified type on the host side (i.e. atomically loading it), firstprivatizing such temporary instead of the original _Atomic variable, privatizing the _Atomic variable instead and then assigning the privatized var the temporary's firstprivatized copy in the target code. Not going to implement it unless it gets standardized though.
[Bug tree-optimization/77445] [7 Regression] Performance drop after r239219 on coremark test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445 Richard Biener changed: What|Removed |Added Keywords||missed-optimization CC||hubicka at gcc dot gnu.org Target Milestone|--- |7.0 --- Comment #2 from Richard Biener --- I think r239219 looks bogus in that it considers the outgoing edge frequency but not the frequency of the path to it. That is, we usually have if () / \ B A \ / X if () \ taken_edge and we should duplicate 'X' if the path leading to taken_edge (either through A or B) is to be optimized for speed (or ! for size). The frequency of the edge out of the condition isn't the only relevant one (in fact whether we should consider it hot or cold needs to be adjusted by the incoming path frequency given the now static prediction). Given r239219 uses ninsns > 1 in the else path it IMHO should use !optimize_edge_for_size_p or retain a > 1 PARAM use.
[Bug c++/77443] Empty initializer on huge object array member slow down the compilation dramatically with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77443 Richard Biener changed: What|Removed |Added Keywords||compile-time-hog CC||jason at gcc dot gnu.org --- Comment #1 from Richard Biener --- It's the C++ frontend at work and we have (a few) duplicates of this bug. Like PR68203.
[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 --- Comment #4 from Christophe Monat --- (In reply to Thomas Preud'homme from comment #3) Thomas, I am seeing that the assignee name has been reset : does it mean that you definitely disengage from looking at this problem ? If this is the case, and if nobody officially takes over, would you share your current patch ? Best regards, --C
[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 --- Comment #5 from Thomas Preud'homme --- (In reply to Christophe Monat from comment #4) > (In reply to Thomas Preud'homme from comment #3) > > Thomas, Hi Christophe, > > I am seeing that the assignee name has been reset : does it mean that you > definitely disengage from looking at this problem ? Yes but only because a colleague took over. He is trying a new approach for -mslow-flash-data altogether which should prove cleaner. > > If this is the case, and if nobody officially takes over, would you share > your current patch ? I'd prefer not since my colleague Andre took over and is actively working on it. He'll keep this bug updated of any progress. Best regards, Thomas
[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 Thomas Preud'homme changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #6 from Thomas Preud'homme --- Ticket is currently unassigned
[Bug c++/77446] New: Suspicious "non-constant condition for static assertion" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77446
Bug ID: 77446
Summary: Suspicious "non-constant condition for static
assertion" error
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
I'm compiling the following under C++14 mode on HEAD 7.0.0 201608 of
http://melpon.org/wandbox/
struct inner {
int field_a = 0;
bool field_b = false;
explicit constexpr inner(const int &arg_field_a) noexcept : field_a{
arg_field_a } {}
};
struct outer {
inner the_inner = inner{ 0 };
constexpr outer() noexcept = default;
constexpr int set_inner(const inner &arg_inner) {
the_inner = arg_inner;
return 0;
}
};
constexpr inner another_inner{ 1 };
static_assert( outer{}.set_inner( another_inner ) == 0, "" );
int main() {}
...and seeing this error:
prog.cc:19:1: error: non-constant condition for static assertion
static_assert( outer{}.set_inner( another_inner ) == 0, "" );
^
I suspect this is a compiler error, particularly because;
* Commenting out the field_b line makes it work.
* Clang compiles this without complaint.
* The error message appears to be inconsistent, sometimes gaining the
following messages after the messages above...
prog.cc:19:33: in constexpr expansion of
'outer{inner(0)}.outer::set_inner(another_inner)'
prog.cc:19:1: error: accessing value of '.outer::the_inner' through
a 'char [5]' glvalue in a constant expression
Many apologies if this is a false positive.
Many thanks for all your hard work on this wonderful compiler.
[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827 --- Comment #25 from Bill Schmidt --- Author: wschmidt Date: Thu Sep 1 14:43:55 2016 New Revision: 239938 URL: https://gcc.gnu.org/viewcvs?rev=239938&root=gcc&view=rev Log: 2016-09-01 Bill Schmidt Michael Meissner PR target/72827 * config/rs6000/rs6000.c (rs6000_legitimize_address): Avoid reg+reg addressing for TImode. (rs6000_legitimate_address_p): Only allow register indirect addressing for TImode, even without TARGET_QUAD_MEMORY. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827 --- Comment #26 from Bill Schmidt --- The original patch direction was impossible to make work, as with a base register of r31 (frame pointer) and an offset register of r0 (not allowed as a base register), there is no legitimate way to update the address into one of the existing registers without spilling. I've committed a temporary workaround that prevents reg+reg addressing for TImode, so that the situation can't arise. When we have a little more time, our team will work on a solution with secondary reload, but this clears up the bootstrap issue for now.
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 --- Comment #60 from Marek Polacek --- Author: mpolacek Date: Thu Sep 1 14:59:50 2016 New Revision: 239939 URL: https://gcc.gnu.org/viewcvs?rev=239939&root=gcc&view=rev Log: PR c/7652 gcc/c-family/ * c-common.c (resolve_overloaded_builtin): Fix formatting. Add FALLTHRU comments. gcc/c/ * c-typeck.c (composite_type): Add FALLTHRU comment. gcc/gcc/cp/ * error.c (dump_type): Fix falls through comment. (dump_decl): Likewise. (dump_expr): Likewise. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c
[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #27 from Eric Botcazou --- .
[Bug c++/77427] [6/7 Regression] ice when canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77427 --- Comment #5 from Tom de Vries --- Hmm, PR52830 looks similar.
[Bug fortran/72832] [6/7 Regression] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72832 vehre at gcc dot gnu.org changed: What|Removed |Added Priority|P4 |P3 Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org
[Bug libgcc/77447] New: /usr/arm-linux-gnueabihf is not in xgcc include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77447 Bug ID: 77447 Summary: /usr/arm-linux-gnueabihf is not in xgcc include path Product: gcc Version: 4.9.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: malithyapa at gmail dot com Target Milestone: --- xgcc fails to compile libgcc because it can't find sys/cdefs.h which is in /usr/arm-linux-gnueabihf. may not be a bug. but couldn't find the configure option to add to the xgcc include path.
[Bug libgcc/77447] /usr/arm-linux-gnueabihf is not in xgcc include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77447 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-09-01 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- MULTIARCH_DIRNAME = $(call if_multiarch,arm$(ARM_EB)-linux-gnueabi$(if $(filter hard,$(with_float)),hf)) How did you configure gcc? From the sound of it, you don't have the right options that match up with the system you are compiling for.
[Bug libgcc/77447] /usr/arm-linux-gnueabihf is not in xgcc include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77447 --- Comment #2 from Andrew Pinski --- I suspect you did not use --with-float=hard
[Bug fortran/72832] [6/7 Regression] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72832 vehre at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug libgcc/77447] /usr/arm-linux-gnueabihf is not in xgcc include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77447 --- Comment #3 from malithyapa at gmail dot com --- Yes! sorry, didn't think it'd matter, i even saw that in the original configure line. Thanks!
[Bug libgcc/77447] /usr/arm-linux-gnueabihf is not in xgcc include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77447 malithyapa at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID
[Bug rtl-optimization/77416] [7 Regression] LRA rematerializing use of CA reg across function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77416
--- Comment #5 from Peter Bergner ---
So this is a latent bug in LRA's rematerialization code. For this test case,
we have insn:
Basic BlocK 6:
...
(insn 179 178 92 6 (parallel [
(set (reg/v:SI 175 [ pD.2425 ])
(plus:SI (reg/v:SI 271 [orig:179 p2D.2421 ] [179])
(reg:SI 76 ca)))
(clobber (reg:SI 76 ca))
]) t.i:23 96 {addsi3_carry_in_0}
(expr_list:REG_DEAD (reg:SI 76 ca)
(expr_list:REG_UNUSED (reg:SI 76 ca)
(nil
...
BB6 ends in a conditional branch.
Basic Block 7 (fall through from BB6)
(insn 99 98 100 7 (set (reg:SI 3 3)
(reg/v:SI 175 [ pD.2425 ])) t.i:26 464 {*movsi_internal1}
(expr_list:REG_DEAD (reg/v:SI 175 [ pD.2425 ])
(nil)))
...
Pseudo r175 is marked for spilling and LRA thinks it can remat r175 in insn 99
because it thinks its operands have not changed. The problem is that insn 179
not only uses the CA, it also clobbers it making remat illegal. The do_remat()
routine does check whether the candidate remat insn's operands are still ok.
The bug is that it isn't actually checking ALL of the insn's operands. The
code in lra_update_insn_regno_info() which computes which regs are used in the
insn uses the recog n_operands to determine the number of operands in the insn,
but in the pattern for this insn, we have a hard coded use of the CA reg so it
doesn't get counted in the n_operands:
(define_insn "add3_carry_in_0"
[(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
(plus:GPR (match_operand:GPR 1 "gpc_reg_operand" "r")
(reg:GPR CA_REGNO)))
(clobber (reg:GPR CA_REGNO))]
So this pattern only has 2 operands[] entries, but the CA really is an operand.
Looking at i386.md, they have lots of hardcoded registers in their machine
description files, so I'm not sure why they are not hitting this.
Vlad, I assume in lra_update_insn_regno_info(), we have to be more careful
about pulling out the used registers being used in the insn? Or do you know of
another way we can fix this?
[Bug libfortran/77393] [7 Regression] Revision r237735 changed the behavior of F0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77393 --- Comment #4 from Jerry DeLisle --- (In reply to Dominique d'Humieres from comment #3) > At revision r239908 the second test in comment 0 still gives > > > ** > > Program received signal SIGSEGV: Segmentation fault - invalid memory > reference. > > at run time. Works for me here!
[Bug c++/77434] warn about suspicious precedence of ternary operator (?:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77434
--- Comment #5 from Bernd Edlinger ---
This is an idea for a warning that does not focus on parentheses:
Here we had: a ? c1 : c2;
but in a context where a boolean is requested.
It is always suspicious, when c1, and c2 are integer constants
which a neither 0 or 1:
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 239944)
+++ gcc/c-family/c-common.c (working copy)
@@ -4618,6 +4618,14 @@
TREE_OPERAND (expr, 0));
case COND_EXPR:
+ if (TREE_CODE (TREE_OPERAND (expr, 1)) == INTEGER_CST
+ && TREE_CODE (TREE_OPERAND (expr, 2)) == INTEGER_CST
+ && !integer_zerop (TREE_OPERAND (expr, 1))
+ && !integer_onep (TREE_OPERAND (expr, 1))
+ && !integer_zerop (TREE_OPERAND (expr, 2))
+ && !integer_onep (TREE_OPERAND (expr, 2)))
+ warning_at (location, 0,
+ "?: expression using integer constants in boolean
context");
/* Distribute the conversion into the arms of a COND_EXPR. */
if (c_dialect_cxx ())
{
Bootstrap obviously fails here:
In file included from ../../gcc-trunk/gcc/dwarf2out.c:59:0:
../../gcc-trunk/gcc/dwarf2out.c: In function 'void
output_loc_operands(dw_loc_descr_ref, int)':
../../gcc-trunk/gcc/system.h:725:18: error: ?: expression using integer
constants in boolean context [-Werror]
((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0 : 0))
^
../../gcc-trunk/gcc/dwarf2out.c:2053:2: note: in expansion of macro
'gcc_assert'
gcc_assert (die_offset > 0
^~
../../gcc-trunk/gcc/system.h:725:18: error: ?: expression using integer
constants in boolean context [-Werror]
((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0 : 0))
^
../../gcc-trunk/gcc/dwarf2out.c:2053:2: note: in expansion of macro
'gcc_assert'
gcc_assert (die_offset > 0
^~
cc1plus: all warnings being treated as errors
[Bug c++/77427] [6/7 Regression] ice when canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77427 --- Comment #6 from Tom de Vries --- (In reply to Tom de Vries from comment #5) > Hmm, PR52830 looks similar. This more generic patch fixes PR52830 as well: ... diff --git a/gcc/tree.c b/gcc/tree.c index 33e6f97..f5c1f6a 100644 --- a/gcc/tree.c +++ b/gcc/tree.c @@ -1043,7 +1043,10 @@ make_node_stat (enum tree_code code MEM_STAT_DECL) SET_TYPE_ALIGN (t, BITS_PER_UNIT); TYPE_USER_ALIGN (t) = 0; TYPE_MAIN_VARIANT (t) = t; - TYPE_CANONICAL (t) = t; + if (code == RECORD_TYPE) + SET_TYPE_STRUCTURAL_EQUALITY (t); + else + TYPE_CANONICAL (t) = t; /* Default to no attributes for type, but let target change that. */ TYPE_ATTRIBUTES (t) = NULL_TREE; ...
[Bug c++/77434] warn about suspicious precedence of ternary operator (?:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77434 --- Comment #6 from joseph at codesourcery dot com --- On Thu, 1 Sep 2016, bernd.edlinger at hotmail dot de wrote: > + warning_at (location, 0, > + "?: expression using integer constants in boolean > context"); This should of course be enabled by some -W option (new or existing, and enabled by -Wall in any case); warnings without an option to control them should be avoided.
[Bug c++/77434] warn about suspicious precedence of ternary operator (?:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77434 --- Comment #7 from Bernd Edlinger --- (In reply to jos...@codesourcery.com from comment #6) > On Thu, 1 Sep 2016, bernd.edlinger at hotmail dot de wrote: > > > + warning_at (location, 0, > > + "?: expression using integer constants in boolean > > context"); > > This should of course be enabled by some -W option (new or existing, and > enabled by -Wall in any case); warnings without an option to control them > should be avoided. sure. It is only an experiment so far. But it feels quite right. The location info is not optimal: at the closing parenthesis. I am not sure how to name the warning, and if there is a better way to tell the user what's wrong with the code.
[Bug libfortran/77393] [7 Regression] Revision r237735 changed the behavior of F0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77393 --- Comment #5 from Jerry DeLisle --- Author: jvdelisle Date: Thu Sep 1 21:17:42 2016 New Revision: 239945 URL: https://gcc.gnu.org/viewcvs?rev=239945&root=gcc&view=rev Log: 2016-09-01 Jerry DeLisle PR libgfortran/77393 * gfortran.dg/fmt_f0_2.f90: Update tests for available kinds. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/fmt_f0_2.f90
[Bug rtl-optimization/77416] [7 Regression] LRA rematerializing use of CA reg across function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77416 --- Comment #6 from Peter Bergner --- Looking closer, it does seem remat is trying to handle these hard coded registers via its hard_regs field. One thing that strikes me as I look at that code, it checks for reg->type being == OP_IN or != OP_IN and for this particular pattern, the CA reg->type is OP_INOUT which I could see causing issues since we don't seem to handle inout regs.
[Bug libfortran/77393] [7 Regression] Revision r237735 changed the behavior of F0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77393 --- Comment #6 from Jerry DeLisle --- The update to the test case should correct any platform specific KIND issues. May need to upsize the bufers a little for Dominique's issue. I set the buffers tight so we could catch different behaviors on platforms I do not have access for testing.
[Bug c++/77442] error: ‘free’ is not a member of ‘std’ std::free(ptr);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77442 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-09-01 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- I can't find a test case in the log or the error message referenced in the Summary. Please provide a test case and/or show how to trigger the error when building GCC (and how you configured it).
[Bug libfortran/77393] [7 Regression] Revision r237735 changed the behavior of F0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77393 --- Comment #7 from Dominique d'Humieres --- > Works for me here! Are you sure that you have tested print "(f8.0)", huge(1.0) print "(f18.0)", huge(1.0_8) print "(f20.0)", huge(1.0_10) print "(f40.0)", huge(1.0_16) end ?
[Bug c++/77448] New: Incorrect code generation for calling stack object's method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77448
Bug ID: 77448
Summary: Incorrect code generation for calling stack object's
method
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nfitzgerald at mozilla dot com
CC: j...@red-bean.com
Target Milestone: ---
Created attachment 39536
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39536&action=edit
zipped testcase.ii
Here is the source of `JS::CallArgs::create` (full, pre-processed test case in
attachment):
> class MOZ_STACK_CLASS CallArgs : public
> detail::CallArgsBase
> {
> private:
> friend CallArgs CallArgsFromVp(unsigned argc, Value* vp);
> friend CallArgs CallArgsFromSp(unsigned stackSlots, Value* sp, bool
> constructing);
>
> static CallArgs create(unsigned argc, Value* argv, bool constructing) {
> CallArgs args;
> args.clearUsedRval();
> args.argv_ = argv;
> args.argc_ = argc;
> args.constructing_ = constructing;
> return args;
> }
>
> public:
> /*
> * Returns true if there are at least |required| arguments passed in. If
> * false, it reports an error message on the context.
> */
> bool requireAtLeast(JSContext* cx, const char* fnname, unsigned required)
> const;
>
> };
Here is the disassembly:
> Dump of assembler code for function JS::CallArgs::create(unsigned int,
> JS::Value*, bool):
>0x55df6e6f5c0a <+0>: push rbp
>0x55df6e6f5c0b <+1>: movrbp,rsp
>0x55df6e6f5c0e <+4>: subrsp,0x20
>0x55df6e6f5c12 <+8>: movQWORD PTR [rbp-0x8],rdi
>0x55df6e6f5c16 <+12>: movDWORD PTR [rbp-0xc],esi
>0x55df6e6f5c19 <+15>: movQWORD PTR [rbp-0x18],rdx
>0x55df6e6f5c1d <+19>: moveax,ecx
>0x55df6e6f5c1f <+21>: movBYTE PTR [rbp-0x10],al
>0x55df6e6f5c22 <+24>: movrax,QWORD PTR [rbp-0x8]
>0x55df6e6f5c26 <+28>: movrdi,rax
>0x55df6e6f5c29 <+31>: call 0x55df6e6f5bf8
>
>0x55df6e6f5c2e <+36>: movrax,QWORD PTR [rbp-0x8]
>0x55df6e6f5c32 <+40>: movrdx,QWORD PTR [rbp-0x18]
>0x55df6e6f5c36 <+44>: movQWORD PTR [rax+0x8],rdx
>0x55df6e6f5c3a <+48>: movrax,QWORD PTR [rbp-0x8]
>0x55df6e6f5c3e <+52>: movedx,DWORD PTR [rbp-0xc]
>0x55df6e6f5c41 <+55>: movDWORD PTR [rax+0x10],edx
>0x55df6e6f5c44 <+58>: movrax,QWORD PTR [rbp-0x8]
>0x55df6e6f5c48 <+62>: movzx edx,BYTE PTR [rbp-0x10]
>0x55df6e6f5c4c <+66>: movBYTE PTR [rax+0x14],dl
>0x55df6e6f5c4f <+69>: nop
>0x55df6e6f5c50 <+70>: movrax,QWORD PTR [rbp-0x8]
>0x55df6e6f5c54 <+74>: leave
>0x55df6e6f5c55 <+75>: ret
> End of assembler dump.
Notice how %rdi, the first parameter, is saved onto the stack, then the value
is read back from the stack into %rdi and passed as the `this` parameter to the
`clearUsedRval` method. This is incorrect.
-
Invoked with these flags:
> $ /usr/lib64/ccache/g++ -std=gnu++11 -S
> -I/home/fitzgen/src/rust-mozjs/target/debug/build/mozjs_sys-e6acb629d67eff9a/out/dist/system_wrappers
> -include
> /home/fitzgen/.cargo/git/checkouts/mozjs-fa11ffc7d4f1cc2d/smup/mozjs/config/gcc_hidden.h
> -DDEBUG=1 -DTRACING=1 -DENABLE_BINARYDATA -DENABLE_SIMD
> -DENABLE_SHARED_ARRAY_BUFFER -DEXPORT_JS_API
> -I/home/fitzgen/.cargo/git/checkouts/mozjs-fa11ffc7d4f1cc2d/smup/mozjs/js/src
> -I/home/fitzgen/src/rust-mozjs/target/debug/build/mozjs_sys-e6acb629d67eff9a/out/js/src
>
> -I/home/fitzgen/src/rust-mozjs/target/debug/build/mozjs_sys-e6acb629d67eff9a/out/dist/include
> -fPIC -DMOZILLA_CLIENT -include
> /home/fitzgen/src/rust-mozjs/target/debug/build/mozjs_sys-e6acb629d67eff9a/out/js/src/js-confdefs.h
> -MD -MP -MF .deps/Unified_cpp_js_src4.o.pp -Wall -Wc++11-compat
> -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith
> -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings
> -Wno-invalid-offsetof -Wc++14-compat -Wno-error=maybe-uninitialized
> -Wno-error=deprecated-declarations -Wno-error=array-bounds -fno-rtti
> -fno-exceptions -fno-math-errno -pthread -pipe -g -fno-omit-frame-pointer
> -Wno-shadow ~/scratch/testcase.ii
-
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=/usr/bin/gcc
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.1.1/lto-wrapper
> Target: x86_64-redhat-linux
> Configured with: ../configure --enable-bootstrap
> --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
> --mandir=/usr/share/man --infodir=/usr/share/info
> --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
> --enable-threads=posix
[Bug libstdc++/75402] std::condition_variable::wait_until wakes up constantly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=75402 Nick Fitzgerald [:fitzgen] [⏰PDT; UTC-7] changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Nick Fitzgerald [:fitzgen] [⏰PDT; UTC-7] --- Apologies. My attached testcase's behavior was due to not compiling with `-pthread`. Unfortunately, I have not been able to reproduce the futex syscalls with a timeout in the past that would wake constantly and then immediately make another futex call with a timeout still in the past, etc etc. If I can reproduce, I will reopen or file a new bug.
[Bug c++/77448] Incorrect code generation for calling stack object's method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77448 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-09-02 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Why do you think this is incorrect code. This is a called named return value optimization. See https://en.wikipedia.org/wiki/Return_value_optimization . This is a way to reduce the number of copy constructors being used. The reason why it is the first argument is because the return value is passed via a pointer as the first argument (the rest of the arguments are shifted over by 1 register); this is the x86_64 ABI (AARCH64 ABI is different and the pointer would have been passed in via a different register and the arguments registers would stay the same).
[Bug tree-optimization/71831] __builtin_object_size poor results with no optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71831 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Martin Sebor --- Enhancement patch committed in r239953.
[Bug tree-optimization/71831] __builtin_object_size poor results with no optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71831 --- Comment #9 from Martin Sebor --- Author: msebor Date: Fri Sep 2 02:14:50 2016 New Revision: 239953 URL: https://gcc.gnu.org/viewcvs?rev=239953&root=gcc&view=rev Log: PR tree-optimization/71831 - __builtin_object_size poor results with no optimization gcc/testsuite/ChangeLog: PR tree-optimization/71831 * gcc.dg/builtin-object-size-16.c: New test. * gcc.dg/builtin-object-size-17.c: New test. gcc/ChangeLog: PR tree-optimization/71831 * tree-object-size.h: Return bool instead of the size and add argument for the size. * tree-object-size.c (compute_object_offset): Update signature. (addr_object_size): Same. (compute_builtin_object_size): Return bool instead of the size and add argument for the size. Handle POINTER_PLUS_EXPR when optimization is disabled. (expr_object_size): Adjust. (plus_stmt_object_size): Adjust. (pass_object_sizes::execute): Adjust. * builtins.c (fold_builtin_object_size): Adjust. * doc/extend.texi (Object Size Checking): Update. * ubsan.c (instrument_object_size): Adjust. Added: trunk/gcc/testsuite/gcc.dg/builtin-object-size-16.c trunk/gcc/testsuite/gcc.dg/builtin-object-size-17.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-object-size.c trunk/gcc/tree-object-size.h trunk/gcc/ubsan.c
