[Bug fortran/90198] internal compiler error: in convert_move, at expr.c:229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90198 --- Comment #3 from guido --- Hello Kargl, Thank you a lot! The problem was that I was calling the heat_function_field incorrectly. I forgot to put the "()" and the error message wasn't that helpful. Therefore this is not a bug at all. Cheers, On 2019-04-22 00:04, kargl at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90198 > > --- Comment #2 from kargl at gcc dot gnu.org --- > Reduced testcase. > > program test > >implicit none > >contains > > real function foo(temp) > real, intent(in) :: temp > foo=bah()*(2) > end function foo > > real function bar(temp,nh) > real,intent(in):: temp,nh > bar = 2 * bah ! Danger Will Roberson! > end function bar > > real function bah() > bah = 1 > end function bah > > end program > > The problem is that bah is referenced in bar() as a variable. Later, > we find that bah is defined as a function. gfortran chokes on this. > > Note, if the function bah() were moved in front of the function > bar(), then gfortran generates > > a.f90:18:36: > >18 | bar = 2 * bah ! Danger Will Roberson! > |1 > Error: Function 'bah' requires an argument list at (1)
[Bug c++/18635] [DR 504] use of uninitialised reference accepted (without -Wuninitialized) in C++ front end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635 Eric Gallager changed: What|Removed |Added Keywords|accepts-invalid |diagnostic Blocks||24639 Summary|[DR 504] use of |[DR 504] use of |uninitialised reference |uninitialised reference |accepted in C++ front end |accepted (without ||-Wuninitialized) in C++ ||front end Severity|normal |enhancement --- Comment #17 from Eric Gallager --- (In reply to Jonathan Wakely from comment #16) > This is > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3293.html#504 which > is Open, so I'm suspending this. If/when that gets resolved we can revisit > this PR. > > I think SUSPENDED rather than INVALID is being generous, as G++ is > completely correct to accept the code, and follows the committee's > intentions: > "Implementations can warn about such constructs, and the resolution for > issue 453 makes executing such code undefined behavior; that seemed to > address the situation adequately." Changing from an accepts-invalid to an enhancement request for an optional -Wuninitialized diagnostic then Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug fortran/90198] internal compiler error: in convert_move, at expr.c:229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90198 --- Comment #2 from kargl at gcc dot gnu.org --- Reduced testcase. program test implicit none contains real function foo(temp) real, intent(in) :: temp foo=bah()*(2) end function foo real function bar(temp,nh) real,intent(in):: temp,nh bar = 2 * bah ! Danger Will Roberson! end function bar real function bah() bah = 1 end function bah end program The problem is that bah is referenced in bar() as a variable. Later, we find that bah is defined as a function. gfortran chokes on this. Note, if the function bah() were moved in front of the function bar(), then gfortran generates a.f90:18:36: 18 | bar = 2 * bah ! Danger Will Roberson! |1 Error: Function 'bah' requires an argument list at (1)
[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #21 from Eric Gallager --- (In reply to jos...@codesourcery.com from comment #20) > r261797 removed all references to _ANSI_H_ from stddef.h, so this issue > can't be relevant after then. ...so that sounds like it can be closed, then.
[Bug fortran/90198] internal compiler error: in convert_move, at expr.c:229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90198 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to guido from comment #0) > Hello gcc users, > While trying to compile a fortran code, I obtained the following error: > > flash_err.f90:31:0: > > > l_t_field=rho_0*heat_function_field*(1E7*1.184E5/(temp+1000)**2*exp(-1.184E5/ > (temp+1000))+1.4E-2*(0.5*temp**(-0.5)*exp(-92/temp)+sqrt(temp)*92/ > temp**2*exp(-92/temp)))/sim_m_proton While gfortran should not ICE, it would help if you considered writing better structure code. In the above line of code, what does "rho_0 * heat_function_field * (1E7 *..." do?
[Bug rtl-optimization/90174] Bad register spill due to top-down allocation order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90174 --- Comment #2 from Feng Xue --- Created attachment 46219 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46219=edit asm file generated by llvm
[Bug rtl-optimization/90174] Bad register spill due to top-down allocation order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90174 --- Comment #1 from Feng Xue --- Created attachment 46218 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46218=edit asm file generated by gcc
[Bug tree-optimization/90200] New: [graphite] ICE: Segmentation fault (in apply_schedule_on_deps)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90200 Bug ID: 90200 Summary: [graphite] ICE: Segmentation fault (in apply_schedule_on_deps) Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: powerpc-*-linux-gnu Created attachment 46217 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46217=edit The original testcase gfortran-9.0.0-alpha20190414 snapshot (r270355) ICEs when compiling silup.f from the MATH77 package[1] w/ -Ofast -floop-parallelize-all -fstack-reuse=none -fwrapv -fno-code-hoisting -fno-tree-ccp -fno-tree-vrp -fno-unsafe-math-optimizations: % powerpc-e300c3-linux-gnu-gfortran-9.0.0-alpha20190414 -Ofast -floop-parallelize-all -fstack-reuse=none -fwrapv -fno-code-hoisting -fno-tree-ccp -fno-tree-vrp -fno-unsafe-math-optimizations -w -c silup.f during GIMPLE pass: graphite silup.f:1:0: 1 | subroutine SILUP (X, Y, NTAB, XT, YT, NDEG, LUP, IOPT, EOPT) | internal compiler error: Segmentation fault 0xd84526 crash_signal /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/toplev.c:326 0x14ba10d apply_schedule_on_deps /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/graphite-dependences.c:207 0x14ba10d carries_deps(isl_union_map*, isl_union_map*, int) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/graphite-dependences.c:229 0x14b5b7a ast_build_before_for(isl_ast_build*, void*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/graphite-isl-ast-to-gimple.c:1372 0x14b6f3b translate_isl_ast_to_gimple::scop_to_isl_ast(scop*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/graphite-isl-ast-to-gimple.c:1407 0x14b9547 graphite_regenerate_ast_isl(scop*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/graphite-isl-ast-to-gimple.c:1480 0x14b4da4 graphite_transform_loops() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/graphite.c:472 0x14b5340 graphite_transforms /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/graphite.c:538 0x14b5340 execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/graphite.c:615 Unfortunately I failed to minimize the testcase in any meaningful way. I have isl 0.21 installed on this machine. [1] http://netlib.org/math/index.html
[Bug c++/90199] New: ICE: tree check: expected complex_cst, have plus_expr in output_constant, at varasm.c:4994
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90199
Bug ID: 90199
Summary: ICE: tree check: expected complex_cst, have plus_expr
in output_constant, at varasm.c:4994
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-9.0.0-alpha20190414 snapshot (r270355), 8.3, 7.4, 6.3 all ICE when
compiling the following testcase w/ -frounding-math:
template
class complex;
template constexpr complex
operator+ (complex hd, complex qc)
{
hd += qc;
return hd;
}
template <>
class complex {
public:
constexpr complex
operator+= (complex rm)
{
jp += rm.jp;
return *this;
}
_Complex float jp;
};
constexpr complex fl{3.3}, ka{1.1}, r0 = fl + ka;
% g++-9.0.0-alpha20190414 -frounding-math -c cvzjr7ol.cc
cvzjr7ol.cc:24:56: internal compiler error: tree check: expected complex_cst,
have plus_expr in output_constant, at varasm.c:4994
24 | constexpr complex fl{3.3}, ka{1.1}, r0 = fl + ka;
|^
0x7b55c1 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/tree.c:9881
0x7cce74 tree_check(tree_node*, char const*, int, char const*, tree_code)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/tree.h:3176
0x7cce74 output_constant
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/varasm.c:4994
0x126c2bf output_constant
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/varasm.c:5246
0x126c2bf output_constructor_regular_field
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/varasm.c:5246
0x126c2bf output_constructor
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/varasm.c:5513
0x126d034 output_constant
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/varasm.c:4885
0x126d034 assemble_variable_contents
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/varasm.c:2144
0x1275ad4 assemble_variable(tree_node*, int, int, int)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/varasm.c:2323
0x1278449 varpool_node::assemble_decl()
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/varpool.c:584
0xb6b69c output_in_order
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cgraphunit.c:2446
0xb6b69c symbol_table::compile()
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cgraphunit.c:2686
0xb6ddfc symbol_table::compile()
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cgraphunit.c:2599
0xb6ddfc symbol_table::finalize_compilation_unit()
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cgraphunit.c:2865
[Bug fortran/90198] New: internal compiler error: in convert_move, at expr.c:229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90198 Bug ID: 90198 Summary: internal compiler error: in convert_move, at expr.c:229 Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: g.granda at irya dot unam.mx Target Milestone: --- Hello gcc users, While trying to compile a fortran code, I obtained the following error: flash_err.f90:31:0: l_t_field=rho_0*heat_function_field*(1E7*1.184E5/(temp+1000)**2*exp(-1.184E5/(temp+1000))+1.4E-2*(0.5*temp**(-0.5)*exp(-92/temp)+sqrt(temp)*92/temp**2*exp(-92/temp)))/sim_m_proton internal compiler error: in convert_move, at expr.c:229 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. I compiled it the following way: gfortran -ffree-line-length-none flash_err.f90 -o flash.exe Here you have some compiler information: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-27ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04) I tried to compile the same code using gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) and I got the same error. The code I used is: program test implicit none real:: sim_temp,sim_num_dens,sim_k,sim_cond,sim_box_size,sim_pi real::sim_m_proton,sim_gamma,sim_mu_mol,sim_gasconstant,sim_boltzmann real,dimension(4) :: coeff sim_m_proton=1.6726219E-24 sim_gamma=1. sim_mu_mol=1.27 sim_gasconstant=8.3144598E-7 sim_boltzmann=1.38064852E-16 sim_pi=3.14159265 sim_temp=729.5 sim_num_dens=3.0 sim_box_size=10*3.085678E18 sim_k=2*sim_pi/sim_box_size sim_cond=67524.2086 call coeficients(sim_temp,sim_num_dens,sim_k,sim_cond,coeff) contains !! Initial velocity functions ! real function cool_function_field(temp) real, intent(in) :: temp cool_function_field=heat_function_field()*(1.0E7*exp(-1.184E5/(temp+1000))+1.4*1e-2*sqrt(temp)*exp(-92/temp))/sim_m_proton end function cool_function_field real function l_t_field(temp,nh) real,intent(in):: temp,nh real :: rho_0 rho_0=sim_m_proton*nh l_t_field=rho_0*heat_function_field*(1E7*1.184E5/(temp+1000)**2*exp(-1.184E5/(temp+1000))+1.4E-2*(0.5*temp**(-0.5)*exp(-92/temp)+sqrt(temp)*92/temp**2*exp(-92/temp)))/sim_m_proton end function l_t_field real function heat_function_field() heat_function_field=2.0E-26/sim_m_proton end function heat_function_field real function sound_speed(temp) real,intent(in):: temp sound_speed=sqrt(sim_gamma*sim_boltzmann*temp/(sim_mu_mol*sim_m_proton)) end function sound_speed real function kappa_rho(temp,nh) real,intent(in):: temp,nh real:: rho_0 rho_0=sim_m_proton*nh kappa_rho=sim_mu_mol*rho_0*cool_function_field(temp)/(sim_gasConstant*sound_speed(temp)*temp) end function kappa_rho real function kappa_t(temp,nh) real,intent(in):: temp,nh kappa_t=sim_mu_mol*(sim_gamma-1)*l_t_field(temp,nh)/(sim_gasConstant*sound_speed(temp)) end function kappa_t real function kappa_k(temp,nh,cond) real,intent(in):: temp,nh,cond real :: rho_0 rho_0=sim_m_proton*nh kappa_k=sim_gasConstant*sound_speed(temp)*rho_0/(sim_mu_mol*(sim_gamma-1)*cond) end function kappa_k real function
[Bug d/90130] gdc.test/runnable/test12.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90130 --- Comment #2 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sun Apr 21 20:26:12 2019 New Revision: 270485 URL: https://gcc.gnu.org/viewcvs?rev=270485=gcc=rev Log: PR d/90130 d/dmd: Merge upstream dmd 065fbd452 Fixes endian bug in CTFE, and corrects tests in the D2 testsuite that failed on big endian targets. Initial patch by Robin Dapp. Reviewed-on: https://github.com/dlang/dmd/pull/9665 Modified: trunk/gcc/d/dmd/MERGE trunk/gcc/d/dmd/constfold.c trunk/gcc/testsuite/gdc.test/runnable/mars1.d trunk/gcc/testsuite/gdc.test/runnable/test12.d trunk/gcc/testsuite/gdc.test/runnable/test23.d
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #17 from Paul Thomas --- Created attachment 46216 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46216=edit Patch for the remaining problems. I am registering this now as a measure of progress towards doing a proper job of fixing this PR for good. The part in trans-expr.c(gfc_trans_assignment_1) is obligatory and stops the compiler doubling up mallocs on top of one another. The part in trans-array.c(gfc_alloc_allocatable_for_assignment) is a partial solution. Instead of testing the shape of the lhs against that of that of the rhs, we need to be comparing the size in bytes. The attached lets the system do this by relying on realloc to do the job. This might be the most efficient way to do it - I will look into it. I note in passing that the estimate of the size of the rhs is going to fail, where class entities are a dynamic type other than the declared type. This is easily done and requires perspiration rather than inspiration :-) Paul
[Bug target/90178] [9 Regression] Missed optimization: duplicated terminal basic block with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90178 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #9 from H.J. Lu --- Fixed.
[Bug target/90178] [9 Regression] Missed optimization: duplicated terminal basic block with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90178 --- Comment #8 from hjl at gcc dot gnu.org --- Author: hjl Date: Sun Apr 21 18:23:00 2019 New Revision: 270484 URL: https://gcc.gnu.org/viewcvs?rev=270484=gcc=rev Log: LRA: Revert "Remove useless move insns" Useless move insn removal was added to LRA just to avoid wasting CPU cycles on such insn processing afterwards. Such insns are removed anyway later in the pass pipeline. The CPU time savings are tiny but the removal creates too many problems including PR target/90178. Vladimir pre-approved the patch to remove the code: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00834.html gcc/ PR target/90178 Revert: 2018-11-21 Uros Bizjak Revert the revert: 2013-10-26 Vladimir Makarov Revert: 2013-10-25 Vladimir Makarov * lra-spills.c (lra_final_code_change): Remove useless move insns. gcc/testsuite/ PR target/90178 * gcc.target/i386/pr90178.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr90178.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-spills.c trunk/gcc/testsuite/ChangeLog
gcc-b...@gcc.gnu.orgHP
gcc-bugs+ 开各地正规普通增值税票，点优惠，包真。 详 电 ：林（姐） 业务部 手机及V信：133-6051-3868 Q Q : 692210769 +++lBWeIaCyj+++ 2:09胶俞,%hSZWu丝歌会
[Bug c++/90196] std:: types unused without warnings but simple type not affected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90196
--- Comment #5 from Максим Прохоренко ---
using namespace std;
class __attribute__((warn_unused)) kw
{
public:
bitset<12> flags{"0010"};
};
int main() {
printf("Hello World!\n");
kw KW;
puts(to_string(sizeof(kw)).c_str());
return 0;
}
Mark all my class by __attribute__((warn_unused)) and all my colleagues was
hate me.
[Bug d/88431] link errors on build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88431
--- Comment #3 from Iain Buclaw ---
Added some debug prints in the boilerplate check.
configure:12017: Checking compiler boilerplate from: $CC -o conftest$ac_exeext
$CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5
configure:12018: module mod; extern(C) int main() { return 0; }
configure:12019: Boilerplate = d21: warning: command line option '-Wlogical-op'
is valid for C/C++/ObjC/ObjC++ but not for D
d21: error: cannot find source code for runtime library file 'object.d'
d21: note: dmd might not be correctly installed. Run 'dmd -man' for
installation instructions.
d21: note: config file: not found
import path[0] = /usr/include/d
So the D boilerplate in the initial test does not match the warnings in latter
tests.
This is the problem here.
[Bug libstdc++/83029] Memory leaks due to leaked thread local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83029 --- Comment #5 from Paul Pluzhnikov --- (In reply to Jonathan Wakely from comment #4) > Which version of glibc are you using? "Debian GLIBC 2.24-12". I believe this bug should be closed as fixed or invalid: 1. The original test case does not fail on this system, and produces expected matching constructors / destructors: Constructing printer. Constructing printer. Printing something... Destroying printer... Printing something... Destroying printer... 2. The test case from #c2 is quite different (because thread_local is in function scope rather than the global scope), and is actually a (hard to spot) bug in the test case. Analysis by richardsm...@google.com: "The program references a function-static local variable without ever having executed its initializer." (This happens because function-local thread_local variables are initialized when they are reached, just like function-local static variables, and that never happens in the test case from #c2)
[Bug c++/55203] No unused warning for variables of non-trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 Andrew Pinski changed: What|Removed |Added CC||maxim.prohorenko at gmail dot com --- Comment #21 from Andrew Pinski --- *** Bug 90196 has been marked as a duplicate of this bug. ***
[Bug c++/90196] std:: types unused without warnings but simple type not affected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90196 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup of bug 55203. *** This bug has been marked as a duplicate of bug 55203 ***
[Bug d/88431] link errors on build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88431
--- Comment #2 from Iain Buclaw ---
(In reply to David Binderman from comment #1)
> This config line works fine:
>
> ../trunk/configure --prefix=/home/dcb/gcc/results.266950 \
> --disable-multilib \
> --disable-werror \
> --enable-checking=df,extra,fold,rtl,yes \
> --enable-languages=d
>
> so it looks like using -O3 in the top level Makefile causes trouble.
I see the following in the config.cache for libphobos:
lt_cv_prog_compiler_pic_works=${lt_cv_prog_compiler_pic_works=yes}
lt_cv_prog_compiler_pic_works_D=${lt_cv_prog_compiler_pic_works_D=no}
config.log:
configure:12414: checking if ./gcc/gdc -B./gcc/ PIC flag -fPIC works
configure:12432: ./gcc/gdc -B./gcc/ -c -nophoboslib -fno-moduleinfo -nostdinc
-g -O3 -march=native -Wlogical-op -fPIC conftest.d >&5
d21: warning: command line option '-Wlogical-op' is valid for C/C++/ObjC/ObjC++
but not for D
configure:12436: $? = 0
configure:12449: result: no
It looks like -Wlogical-op is the culprit, not -O3.
This is the condition in configure:
---
if (exit $ac_status) && test -s "$ac_outfile"; then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings other than the usual output.
$ECHO "$_lt_compiler_boilerplate" | $SED '/^$/d' >conftest.exp
$SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
if test ! -s conftest.er2 || diff conftest.exp conftest.er2 >/dev/null; then
lt_cv_prog_compiler_pic_works_D=yes
fi
fi
[Bug debug/90197] New: [8/9 Regression] Cannot step through simple loop at -O -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90197
Bug ID: 90197
Summary: [8/9 Regression] Cannot step through simple loop at -O
-g
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Compiling:
__attribute__((noipa))
void
test (unsigned int *dst, unsigned int base, int count)
{
for (int i = 0; i < count; ++i, base += 15)
dst[i] = base;
}
int
main (void)
{
unsigned int dst[100];
test (dst, 0x4000, 100);
}
with -O -g and launching with recent gdb trunk (and stock gdb):
(gdb) break test
Breakpoint 1 ...
(gdb) run
Starting program: ...
Breakpoint 1, test ...
5 for (int i = 0; i < count; ++i, base += 15)
(gdb) next
6 dst[i] = base;
(gdb) next
__libc_start_main (main=...
i.e. it isn't possible to step through each iteration of the loop. With gcc 7
this worked even for -O2 -g.
The test works with -O -fno-tree-ch -g (and thus also with -Og). For -O2
-fno-tree-ch -g we get:
(gdb) break test
Breakpoint 1 ...
(gdb) run
Starting program: ...
Breakpoint 1, test ...
5 for (int i = 0; i < count; ++i, base += 15)
(gdb) next
__libc_start_main ...
With just -O2 -g we get the same as for -O -g.
A breakpoint on the loop body (line 6) hits for each iteration of the loop
though.
As you can tell, this isn't my area, so I'm not sure whether it's actually a
gdb bug (or a dup).
[Bug c++/90196] std:: types unused without warnings but simple type not affected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90196 --- Comment #3 from Максим Прохоренко --- Allocate GiB of unused memory and don't warn about it? But 1 simple double - it is a big problem. For std:: objects with side effect - OK! But for simple unused vector or set or map???
[Bug c++/90196] std:: types unused without warnings but simple type not affected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90196 --- Comment #2 from Jonathan Wakely --- The warning works as intended. Types with a non-trivial destructor do not cause a warning, because if the destructor has side effects then the variable is not unused. We don't want to warn for types like std::lock_guard which are constructed and then not "used", because the destructor does all the useful work.
[Bug libstdc++/83029] Memory leaks due to leaked thread local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83029 --- Comment #4 from Jonathan Wakely --- Which version of glibc are you using?
2019 CCTV Accessories Supplier
Dear Manager, Happy New Year! This is Kevin from INSTARGO CO.,LTD We are factory produce a wide range of CCTV Accessories, POE switch, Tester, Power Supply, IR Lighting, BNC Connector, CCTV Housing & Bracket,Wire/Cable, Microphone,Video Balun, Lens, package etc. All of the products are high quality with 100% QC test before shipping. Welcome your inquiry. Regards, Kevin
[Bug d/88238] libphobos compile problems on Solaris 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88238
--- Comment #1 from Iain Buclaw ---
(In reply to Rainer Orth from comment #0)
>
> which allow libgdruntime.so and libgphobos.so to link on Solaris 11.3 without
> unresolved symbols, there are more on Solaris 10:
>
> *
> symbol not found: backtrace
> (libdruntime/.libs/libgdruntime.so)
> symbol not found: backtrace_symbols_fd
> (libdruntime/.libs/libgdruntime.so)
> symbol not found: backtrace_symbols
> (libdruntime/.libs/libgdruntime.so)
>
> Unlike Solaris 11, Solaris 10 lacks the backtrace functions in libc. When
> trying to use them, this failed because backtrace-supported.h wasn't found
> during configure. This is due to an error in m4/druntime/libraries.m4
> which
> tries to add to CPPFLAGS with +=, which of course the shell doesn't
> understand.
>
Just saw this, I noticed this also when building on one of the BSDs, fixed in
r270377.
> *
>
> symbol not found: dl_iterate_phdr
> (libdruntime/.libs/libgdruntime.so)
>
> Unlike Solaris 11, dl_iterate_phdr support was only backported to a late
> Solaris 10 update and even so only lives in libdl, not in libc. Not yet
> fixed.
>
So does dlopen and dl_iterate_phdr live in separate libraries? I would have
thought that DRUNTIME_LIBRARIES_DLOPEN would correctly add -ldl to the driver
spec file.
> *
>
> symbol not found: getprogname
> (libdruntime/.libs/libgdruntime.so)
>
> Solaris 10 lacks getprogname or equivalent; for now I'm faking this by just
> returning "a.out".
>
There's the following function in rt/dmain2.d
extern (C) string[] rt_args();
Would the basename() of argv[0] be a suitable fallback? Looking at illumos,
they use dlinfo(RTLD_SELF, RTLD_DI_ARGSINFO) and strrchr(argv0, '/').
> *
> symbol not found: posix_memalign
> (src/.libs/libgphobos.so)
>
> Also missing from Solaris 10. I've not yet checked what to do here. One
> might be able to use pagealign_alloc from gnulib instead?
If the OS version can be obtained from the compiler, same as FBSD_MAJOR, then
one option would be to provide posix_memalign internally in druntime.
extern(D) int posix_memalign(void** ptr, size_t alignment, size_t size)
{
// ...
}
extern(D) so that it won't conflict with extern(C) function of the same name.
Though whether it is worth the effort, I'm not so sure. As you've said that
Solaris10 will be removed before.
[Bug c++/90178] [9 Regression] Missed optimization: duplicated terminal basic block with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90178 --- Comment #7 from Paolo Carlini --- The Component field is wrong, right?
[Bug c++/90172] [9 Regression] ICE: Segmentation fault (in contains_struct_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90172 Paolo Carlini changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-21 CC||paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- I think this is also a rejects-valid.
[Bug d/90064] InSituRegion lacks SPARC64 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90064 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Buclaw --- Merged in r270483.
[Bug d/90064] InSituRegion lacks SPARC64 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90064 --- Comment #1 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sun Apr 21 10:21:07 2019 New Revision: 270483 URL: https://gcc.gnu.org/viewcvs?rev=270483=gcc=rev Log: PR d/90064 libphobos: Merge upstream phobos 428460ddd Defines growDownwards on SPARC64, initial patch by Rainer Orth. Backports another fix to std.process, allowing permissions tests to be skipped when running as root. Reviewed-on: https://github.com/dlang/phobos/pull/6962 Modified: trunk/libphobos/src/MERGE trunk/libphobos/src/std/experimental/allocator/building_blocks/region.d trunk/libphobos/src/std/process.d
[Bug c++/89900] [9 Regression] ICE: Segmentation fault (in check_instantiated_arg)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89900 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Paolo Carlini --- Fixed.
[Bug d/89017] ICE in force_type_die, at dwarf2out.c:26061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89017 --- Comment #4 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sun Apr 21 07:03:32 2019 New Revision: 270478 URL: https://gcc.gnu.org/viewcvs?rev=270478=gcc=rev Log: d: Use semanticRun to prevent declaration pass from running multiple times. This shouldn't happen during normal traversal of the AST provided from the front-end, however as there are some cases where declarations need to be visited out of order, such as what is being done in PR d/89017, it then becomes necessary to guard against this. gcc/d/ChangeLog: 2019-04-21 Iain Buclaw * decl.cc (DeclVisitor::visit(Import)): Set semanticRun after completion, guard against being called more than once. (DeclVisitor::visit(StructDeclaration)): Likewise. (DeclVisitor::visit(ClassDeclaration)): Likewise. (DeclVisitor::visit(InterfaceDeclaration)): Likewise. (DeclVisitor::visit(VarDeclaration)): Likewise. (DeclVisitor::visit(TypeInfoDeclaration)): Likewise. Modified: trunk/gcc/d/ChangeLog trunk/gcc/d/decl.cc
