[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
[Bug c/81777] Compiler doesn't detect wrong function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81777
--- Comment #1 from jsiebert at poczta dot wp.pl ---
file test.c:
#include "testarg.h"
int main(void)
{
testarg();
return 0;
}
[Bug c/81777] New: Compiler doesn't detect wrong function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81777
Bug ID: 81777
Summary: Compiler doesn't detect wrong function declaration
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jsiebert at poczta dot wp.pl
Target Milestone: ---
Is it possible to miss wrong declaration of function in seperate include file.
An example:
file testarg.c:
#include
typedef struct {
int c;
} test_t;
void testarg(test_t *t)
{
printf("c = %d\n", t->c);
return;
}
file testarg.h:
void testarg(void);
file test.c:
#include "testarg.h"
int main(void)
{
gcc test.c testarg.c -o test
testarg();
return 0;
}
compilation with:
gcc -Wall -Werror -pedantic-errors test.c testarg.c -o test
gives no warning or error about wrong testarg() usage.
[Bug c/81777] Compiler doesn't detect wrong function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81777 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Andrew Pinski --- Yes this is because this is not required to issue a diagnostic at compile time. Also there is no real way. -flto is able to diagnose this though due to having all the information while linking.
[Bug c/81777] Compiler doesn't detect wrong function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81777 --- Comment #3 from Andrew Pinski --- Also -Wmissing-declarations helps here to make sure you have a declaration before an external definition. It will warn as you don't have a declaration for testarg function in testarg.c.
[Bug libstdc++/81751] __basic_file::sync() may flush _all_ files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81751 --- Comment #3 from Volker Wehrs --- Why is sync() (alias fflush()) called in sys_open(FILE*,...) at all? 1. It is not called in sys_open(int,...) 2. Both sys_open() functions are called in the constructor of stdio_filebuf _only_. So, as __basic_file seem to be intended as an internal class, maybe the call to sync() can completely be omitted as there definitively is no open file.
[Bug rtl-optimization/81301] [8 Regression] ICE: verify_flow_info failed (error: non-cold basic block 13 dominated by a block in the cold partition (8)) on 32-bit BE powerpc target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81301 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-08-09 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can't reproduce, can you please provide -mtune and -march options?
[Bug rtl-optimization/81301] [8 Regression] ICE: verify_flow_info failed (error: non-cold basic block 13 dominated by a block in the cold partition (8)) on 32-bit BE powerpc target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81301 --- Comment #2 from Arseny Solokha --- I also cannot reproduce it anymore w/ gcc-8.0.0-alpha20170806 snapshot. It must be fixed or made latent some time in between. % powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20170806 -Q --help=target | grep -e march -e mtune -mtune= [default] Known CPUs (for use with the -mcpu= and -mtune= options): The target CPU is e300c3, as the triplet says.
[Bug target/81708] The x86 stack canary location should be customizable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708 --- Comment #10 from Uroš Bizjak --- Created attachment 41955 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41955&action=edit patch that introduces mstack-protector-guard-symbol= This patch can be used to override TLS offset with a symbol. gcc.target/i386/stack-prot-guard.c compiles to (-O2 -fstack-protector-all -mstack-protector-guard-symbol=symbol_name): f: subq$24, %rsp movq%fs:symbol_name(%rip), %rax movq%rax, 8(%rsp) xorl%eax, %eax movq8(%rsp), %rax xorq%fs:symbol_name(%rip), %rax jne .L5 addq$24, %rsp ret
[Bug c/81417] -Wsign-compare should print types being compared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81417 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Wed Aug 9 08:51:20 2017 New Revision: 250984 URL: https://gcc.gnu.org/viewcvs?rev=250984&root=gcc&view=rev Log: PR c/81417 * c-array-notation.c (fix_builtin_array_notation_fn): Update calls to build_conditional_expr. * c-parser.c (c_parser_conditional_expression): Create locations for EXP1 and EXP2 from their source ranges. Pass the locations down to build_conditional_expr. * c-tree.h (build_conditional_expr): Update declaration. * c-typeck.c (build_conditional_expr): Add location_t parameters. For -Wsign-compare, also print the types. * input.c (make_location): New overload. * input.h (make_location): Declare. * objc-next-runtime-abi-02.c (build_v2_build_objc_method_call): Update a call to build_conditional_expr. * Wsign-compare-1.c: New test. * gcc.dg/compare1.c: Adjust dg-bogus. * gcc.dg/compare2.c: Likewise. * gcc.dg/compare3.c: Likewise. * gcc.dg/compare7.c: Likewise. * gcc.dg/compare8.c: Likewise. * gcc.dg/compare9.c: Likewise. * gcc.dg/pr11492.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/Wsign-compare-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/c/ChangeLog trunk/gcc/c/c-array-notation.c trunk/gcc/c/c-parser.c trunk/gcc/c/c-tree.h trunk/gcc/c/c-typeck.c trunk/gcc/input.c trunk/gcc/input.h trunk/gcc/objc/ChangeLog trunk/gcc/objc/objc-next-runtime-abi-02.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/compare1.c trunk/gcc/testsuite/gcc.dg/compare2.c trunk/gcc/testsuite/gcc.dg/compare3.c trunk/gcc/testsuite/gcc.dg/compare7.c trunk/gcc/testsuite/gcc.dg/compare8.c trunk/gcc/testsuite/gcc.dg/compare9.c trunk/gcc/testsuite/gcc.dg/pr11492.c
[Bug c/81417] -Wsign-compare should print types being compared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81417 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Done.
[Bug target/81708] The x86 stack canary location should be customizable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708 --- Comment #11 from Uroš Bizjak --- (In reply to H. Peter Anvin from comment #8) > How about simply letting the user enter an assembly expression of neither of > the standard ABI options are suitable? Also, shouldn't the user space > default on 64 bits be an offset into the TLS using %fs, or is there > something magic about how the kernel is compiled that changes it to %gs:? -mcmodel=kernel switches TLS reg to %gs. You can use mstack-protector-guard-reg=%gs with other code models.
[Bug libgomp/81778] New: libgomp.c/for-5.c failure on nvptx -- illegal memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81778
Bug ID: 81778
Summary: libgomp.c/for-5.c failure on nvptx -- illegal memory
access
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
At r250889, I noticed libgomp.c/for-5.c fail for nvptx offloading:
Minimized example:
...
extern void abort ();
#pragma omp declare target
#define N 64
int a[N];
#pragma omp end declare target
__attribute__((noinline, noclone)) void
f2_tpf_simd_static32 (void)
{
unsigned int i;
#pragma omp target parallel for simd schedule(static, 32)
for (i = N; i > 0 ; i -= 1)
a[(i - 1)] -= 4;
}
__attribute__((noinline, noclone)) int
test_tpf_simd_static32 (void)
{
int i;
for (i = 0; i < N; i++)
a[i] = i - 25;
#pragma omp target update to(a)
f2_tpf_simd_static32 ();
#pragma omp target update from(a)
for (i = 0; i < N; i++)
if (a[i] != i - 29)
return 1;
return 0;
}
int
main ()
{
if (test_tpf_simd_static32 ())
abort ();
return 0;
}
...
...
$ ./install/bin/gcc \
-fopenmp \
-B$(pwd -P)/install/offload-nvptx-none/libexec/gcc/x86_64-pc-linux-gnu/8.0.0
\
-B$(pwd -P)/install/offload-nvptx-none/bin \
for-5.c \
-O2
$ ( export LD_LIBRARY_PATH=$(pwd -P)/install/lib64/; ./a.out ; echo $? )
libgomp: cuCtxSynchronize error: an illegal memory access was encountered
libgomp: cuMemFreeHost error: an illegal memory access was encountered
libgomp: device finalization failed
1
...
[Bug libgomp/81778] libgomp.c/for-5.c failure on nvptx -- illegal memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81778 --- Comment #1 from Tom de Vries --- Created attachment 41956 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41956&action=edit GOMP_DEBUG=1 log
[Bug libgomp/81778] libgomp.c/for-5.c failure on nvptx -- illegal memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81778 --- Comment #2 from Tom de Vries --- nvidia card: Quadro M1200 cuda: 7.5 cuda driver: 375.66
[Bug rtl-optimization/81301] [8 Regression] ICE: verify_flow_info failed (error: non-cold basic block 13 dominated by a block in the cold partition (8)) on 32-bit BE powerpc target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81301 --- Comment #3 from Martin Liška --- (In reply to Arseny Solokha from comment #2) > I also cannot reproduce it anymore w/ gcc-8.0.0-alpha20170806 snapshot. It > must be fixed or made latent some time in between. > > % powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20170806 -Q --help=target | grep > -e march -e mtune > -mtune= [default] > Known CPUs (for use with the -mcpu= and -mtune= options): > > The target CPU is e300c3, as the triplet says. Let me reproduce with a revision from the date you mentioned. For next PRs, please output content of gcc -v so that we can identify a single commit. Thanks.
[Bug middle-end/19706] Recognize common Fortran usages of copysign.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19706 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #5 from Tamar Christina --- (In reply to Ramana Radhakrishnan from comment #4) > > I would have put these testcases into gcc.dg/vect and added a > target_supports_vect_xorsign so that other targets had a fighting chance of > catching such changes. Except for the execution tests, the rest are way too AArch64 specific as they scan the generated assembly. I could however write a generic mid-end one I think to check for the internal function. > > Is this pattern relevant to AArch32 for instance ? If so I'd like to add > those patterns there for bonus points ... Yeah AArch32 would benefit some as well. So fair enough, I'll add it there too. > > I suspect the drotg testcase is fixed up by this . If so this bug should > then be closed out as the mid-end has support for it. I'm not clear if > slasv2.f is worth looking at further as another example. Indeed this does fix drotg for targets that implement the optab, the slasv2 is interesting as it does point out one issue which is combining XORSIGN and COPYSIGN calls in the same chain produces suboptimal code.
[Bug rtl-optimization/81301] [8 Regression] ICE: verify_flow_info failed (error: non-cold basic block 13 dominated by a block in the cold partition (8)) on 32-bit BE powerpc target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81301 --- Comment #4 from Arseny Solokha --- (In reply to Martin Liška from comment #3) > For next PRs, > please output content of gcc -v so that we can identify a single commit. Sure, but how can this possibly help to identify a commit? I dont' have a revision in the gcc -v output. I believe snapshot announcements[1] are those authoritative sources that list revisions from which the corresponding snapshots has been generated. Am I missing something? [1] https://gcc.gnu.org/ml/gcc/2017-08/msg00071.html
[Bug c/81779] New: bool define from stdbool.h suppresses -Wdeclaration-after-statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81779
Bug ID: 81779
Summary: bool define from stdbool.h suppresses
-Wdeclaration-after-statement
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
This testcase warns only once with -Wdeclaration-after-statement since at least
gcc-4.8:
#include
bool f2(char *pRedo)
{
if (!pRedo)
return false;
bool ret = true;
return ret;
}
int f3(char *pRedo)
{
if (!pRedo)
return 0;
int ret = 1;
return ret;
}
# gcc-7 -c -Wdeclaration-after-statement Wdeclaration-after-statement.c
Wdeclaration-after-statement.c: In function 'f3':
Wdeclaration-after-statement.c:18:2: warning: ISO C90 forbids mixed
declarations and code [-Wdeclaration-after-statement]
int ret = 1;
^~~
gcc-4.4 warned 2 for both occurences:
# gcc-4.4 -c -Wdeclaration-after-statement Wdeclaration-after-statement.c
Wdeclaration-after-statement.c: In function 'f2':
Wdeclaration-after-statement.c:10: warning: ISO C90 forbids mixed declarations
and code
Wdeclaration-after-statement.c: In function 'f3':
Wdeclaration-after-statement.c:17: warning: ISO C90 forbids mixed declarations
and code
Adding -Wsystem-headers shows 2 warnings also with newer GCC, but I don't think
that this option should influence -Wdeclaration-after-statement.
[Bug rtl-optimization/81301] [8 Regression] ICE: verify_flow_info failed (error: non-cold basic block 13 dominated by a block in the cold partition (8)) on 32-bit BE powerpc target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81301 --- Comment #5 from Martin Liška --- (In reply to Arseny Solokha from comment #4) > (In reply to Martin Liška from comment #3) > > For next PRs, > > please output content of gcc -v so that we can identify a single commit. > > Sure, but how can this possibly help to identify a commit? I dont' have a > revision in the gcc -v output. I believe snapshot announcements[1] are those > authoritative sources that list revisions from which the corresponding > snapshots has been generated. Am I missing something? > > [1] https://gcc.gnu.org/ml/gcc/2017-08/msg00071.html Yes, but I was thinking that you are using a nighly builds from trunk? Even my distribution release comes with a revision: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/7/lto-wrapper OFFLOAD_TARGET_NAMES=hsa:nvptx-none Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,ada,go --enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver --enable-checking=release --disable-werror --with-gxx-include-dir=/usr/include/c++/7 --enable-ssp --disable-libssp --disable-libvtv --disable-libcc1 --enable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function --program-suffix=-7 --without-system-libunwind --enable-multilib --with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux Thread model: posix gcc version 7.1.1 20170629 [gcc-7-branch revision 249772] (SUSE Linux)
[Bug rtl-optimization/81301] [8 Regression] ICE: verify_flow_info failed (error: non-cold basic block 13 dominated by a block in the cold partition (8)) on 32-bit BE powerpc target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81301 Martin Liška changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #6 from Martin Liška --- Anyway, closing as invalid.
[Bug rtl-optimization/81301] [8 Regression] ICE: verify_flow_info failed (error: non-cold basic block 13 dominated by a block in the cold partition (8)) on 32-bit BE powerpc target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81301 --- Comment #7 from Arseny Solokha --- (In reply to Martin Liška from comment #5) > Yes, but I was thinking that you are using a nighly builds from trunk? I use weekly snapshots. Sorry for not mentioning it earlier. > Even my distribution release comes with a revision: I don't see one neither for stable distribution release nor for vanilla weekly snapshots.
[Bug c++/81668] LTO ODR warnings are not helpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668 --- Comment #8 from Manuel López-Ibáñez --- (In reply to sgunderson from comment #7) > What I'd like is some sort of indication about where test.h came in from > (test1.cc and test2.cc). Actually, what would be more useful is to detect that the difference in type comes from S and point out where S has been declared as different types. Note that this is not the same bug I pointed out for ../include/violite.h:288:8: warning: type ‘struct st_vio’ violates the C++ One Definition Rule [-Wodr] ../include/violite.h:288:0: note: a different type is defined in another translation unit The :0: indicates something wrong with the location info. If the location is unknown, it would be better to use UNKNOWN_LOCATION.
[Bug debug/80938] [7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80938 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||amodra at gcc dot gnu.org, ||marxin at gcc dot gnu.org, ||segher at gcc dot gnu.org Summary|[8 Regression] ICE in |[7/8 Regression] ICE in |maybe_record_trace_start, |maybe_record_trace_start, |at dwarf2cfi.c:2330 |at dwarf2cfi.c:2330 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r235672.
[Bug c/81417] -Wsign-compare should print types being compared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81417 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to Marek Polacek from comment #5) > Done. Thank you!
[Bug libgomp/81778] libgomp.c/for-5.c failure on nvptx -- illegal memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81778 --- Comment #3 from Tom de Vries --- The core loop looks like this: ... $L4: add.u32 %r31,%r42,-1; cvt.u64.u32 %r63,%r31; shl.b64 %r64,%r63,2; add.u64 %r65,%r75,%r64; ld.u32 %r71,[%r65]; add.u32 %r70,%r71,-4; st.u32 [%r65],%r70; add.u32 %r42,%r42,-32; setp.lt.u32 %r72,%r30,%r42; @ %r72 bra $L4; ... If we comment out the branch, the testcase passes. I've investigated the ranges of the registers to understand why the branch is taken. [ By storing the reg into the array, and printing it out afterwards. That meant disabling the jump, otherwise I don't get to the print. ]: ... r42: [0,63] -> [-31,32] r30: [0-31] -> 0 [32-63] -> 32 ... So for index 0, we have: ... setp.lt.u32 %r72,0,-31; ... This evaluates to true, because (u32)-31 is bigger than 0. Changing the compare from unsigned to signed makes the test pass.
[Bug target/81389] _mm_cmpestri segfault on -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81389 H.J. Lu changed: What|Removed |Added Status|REOPENED|WAITING CC||hjl.tools at gmail dot com --- Comment #8 from H.J. Lu --- Please provide a run-time testcase.
[Bug c++/81668] LTO ODR warnings are not helpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668 --- Comment #9 from sgunderson at bigfoot dot com --- (In reply to Manuel López-Ibáñez from comment #8) > Actually, what would be more useful is to detect that the difference in type > comes from S and point out where S has been declared as different types. Yes, that would be even better. But save for that :-) > Note that this is not the same bug I pointed out for > > ../include/violite.h:288:8: warning: type ‘struct st_vio’ violates the C++ > One Definition Rule [-Wodr] > ../include/violite.h:288:0: note: a different type is defined in another > translation unit > > The :0: indicates something wrong with the location info. If the location is > unknown, it would be better to use UNKNOWN_LOCATION. Yes, I know. It's a bit odd, but it doesn't bother me as much in this case.
[Bug target/81780] New: -finstrument-control-flow -mcet is incompatible with __attribute__ ((regparm (3)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81780 Bug ID: 81780 Summary: -finstrument-control-flow -mcet is incompatible with __attribute__ ((regparm (3))) Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: igor.v.tsimbalist at intel dot com Blocks: 81652 Target Milestone: --- Target: i386 When -finstrument-control-flow -mcet is used, __attribute__ ((regparm (3))) can't be used to call external function should is defined in a shared object: https://sourceware.org/bugzilla/show_bug.cgi?id=21598 But https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html has regparm (number) On x86-32 targets, the regparm attribute causes the compiler to pass arguments number one to number if they are of integral type in registers EAX, EDX, and ECX instead of on the stack. Functions that take a variable number of arguments continue to be passed all of their arguments on the stack. Beware that on some ELF systems this attribute is unsuitable for global functions in shared libraries with lazy binding (which is the default). Lazy binding sends the first call via resolving code in the loader, which might assume EAX, EDX and ECX can be clobbered, as per the standard calling conventions. Solaris 8 is affected by this. Systems with the GNU C Library version 2.1 or higher and FreeBSD are believed to be safe since the loaders there save EAX, EDX and ECX. (Lazy binding can be disabled with the linker or the loader if desired, to avoid the problem.) -finstrument-control-flow -mcet should disallow __attribute__ ((regparm (3))) on a non-hidden external function declaration. __attribute__ ((regparm (3))) should be allowed on external function function body since linker may turn it a hidden definition at link-time. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 [Bug 81652] [meta-bug] -finstrument-control-flow -mcet bugs
[Bug c++/81781] New: consexpr pointer comparsion error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81781 Bug ID: 81781 Summary: consexpr pointer comparsion error Product: gcc Version: 7.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bobk-off at yandex dot ru Target Milestone: --- Any gcc version cannot compile code below with error: '((& std::integral_constant::value) == (& std::integral_constant::value))' is not a constant expression. Compilation success only if template arguments of left side and right side parts of equation are equal. static constexpr bool x = &std::integral_constant::value == &std::integral_constant::value;
[Bug target/81780] -finstrument-control-flow -mcet is incompatible with __attribute__ ((regparm (3)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81780 --- Comment #1 from Florian Weimer --- Could we turn calls to regparam (3) functions into noplt calls? Some additional mechanics are probably needed if the address of such a function is taken.
[Bug target/80700] [7/8 Regression] ICE: Bus error (on SPE target)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80700 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||bergner at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|[8 Regression] ICE: Bus |[7/8 Regression] ICE: Bus |error (on SPE target) |error (on SPE target) Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed, started with r244609.
[Bug target/80503] ICE in extract_insn, at recog.c:2311 on ppc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80503 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||amodra at gcc dot gnu.org, ||segher at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/81780] -finstrument-control-flow -mcet is incompatible with __attribute__ ((regparm (3)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81780 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 Ever confirmed|0 |1 --- Comment #2 from H.J. Lu --- (In reply to Florian Weimer from comment #1) > Could we turn calls to regparam (3) functions into noplt calls? Some > additional mechanics are probably needed if the address of such a function > is taken. Yes, we can make regparam (3) to imply __attribute__ ((noplt)) with -finstrument-control-flow -mcet. It should work.
[Bug c++/81750] Calling generic lambda with no parameter fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81750 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- Indeed, thanks, Tim. *** This bug has been marked as a duplicate of bug 64095 ***
[Bug c++/64095] [C++14] Ellipsis at end of generic lambda parameter-declaration-clause should be parsed as a parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64095 Jonathan Wakely changed: What|Removed |Added CC||d25fe0be at outlook dot com --- Comment #6 from Jonathan Wakely --- *** Bug 81750 has been marked as a duplicate of this bug. ***
[Bug c/81233] --Wdiscarded-qualifiers and Wincompatible-pointer-types missing important detail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81233 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Wed Aug 9 11:28:22 2017 New Revision: 250985 URL: https://gcc.gnu.org/viewcvs?rev=250985&root=gcc&view=rev Log: PR c/81233 * c-typeck.c (pedwarn_init): Make the function take a variable list. Call emit_diagnostic_valist instead of pedwarn. (convert_for_assignment): Unroll the PEDWARN_FOR_ASSIGNMENT macro. Print the relevant types in diagnostics. * diagnostic-core.h (emit_diagnostic_valist): Add declaration. * diagnostic.c (emit_diagnostic): Add a comment. (emit_diagnostic_valist): New function. * gcc.dg/diagnostic-types-1.c: New test. * gcc.dg/assign-warn-1.c: Update warning messages. * gcc.dg/assign-warn-2.c: Likewise. * gcc.dg/c90-const-expr-5.c: Likewise. * gcc.dg/c99-const-expr-5.c: Likewise. * gcc.dg/conv-2.c: Likewise. * gcc.dg/init-bad-7.c: Likewise. * gcc.dg/overflow-warn-1.c: Likewise. * gcc.dg/overflow-warn-2.c: Likewise. * gcc.dg/overflow-warn-3.c: Likewise. * gcc.dg/overflow-warn-4.c: Likewise. * gcc.dg/pointer-array-atomic.c: Likewise. * gcc.dg/pr26865.c: Likewise. * gcc.dg/pr61162-2.c: Likewise. * gcc.dg/pr61162.c: Likewise. * gcc.dg/pr67730-2.c: Likewise. * gcc.dg/pr69156.c: Likewise. * gcc.dg/pr70174.c: Likewise. * objc.dg/proto-lossage-4.m: Likewise. Added: trunk/gcc/testsuite/gcc.dg/diagnostic-types-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/diagnostic-core.h trunk/gcc/diagnostic.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/assign-warn-1.c trunk/gcc/testsuite/gcc.dg/assign-warn-2.c trunk/gcc/testsuite/gcc.dg/c90-const-expr-5.c trunk/gcc/testsuite/gcc.dg/c99-const-expr-5.c trunk/gcc/testsuite/gcc.dg/conv-2.c trunk/gcc/testsuite/gcc.dg/init-bad-7.c trunk/gcc/testsuite/gcc.dg/overflow-warn-1.c trunk/gcc/testsuite/gcc.dg/overflow-warn-2.c trunk/gcc/testsuite/gcc.dg/overflow-warn-3.c trunk/gcc/testsuite/gcc.dg/overflow-warn-4.c trunk/gcc/testsuite/gcc.dg/pointer-array-atomic.c trunk/gcc/testsuite/gcc.dg/pr26865.c trunk/gcc/testsuite/gcc.dg/pr61162-2.c trunk/gcc/testsuite/gcc.dg/pr61162.c trunk/gcc/testsuite/gcc.dg/pr67730-2.c trunk/gcc/testsuite/gcc.dg/pr69156.c trunk/gcc/testsuite/gcc.dg/pr70174.c trunk/gcc/testsuite/objc.dg/proto-lossage-4.m
[Bug c/81233] --Wdiscarded-qualifiers and Wincompatible-pointer-types missing important detail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81233 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed. Further improvements are possible.
[Bug c++/81781] consexpr pointer comparsion error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81781
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-08-09
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
Confirmed. Reduced:
template struct I { static constexpr int value = N; };
template constexpr int I::value;
static constexpr bool x = &I<5>::value == &I<10>::value;
ce.cc:5:40: error: ‘((& I<5>::value) == (& I<10>::value))’ is not a constant
expression
static constexpr bool x = &I<5>::value == &I<10>::value;
~^
[Bug debug/79953] ICE in expand_debug_locations when attribute target is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79953 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||aoliva at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, all releases I have ICE. (gdb) p debug_rtx(val) (mem/c:V32QI (plus:DI (reg/f:DI 82 virtual-stack-vars) (const_int -32 [0xffe0])) [0 x+0 S32 A256]) $4 = void (gdb) p mode $5 = BLKmode Problem is probably that nehalem does not have -mavx2 enabled and it's enabled in the source code via target attribute.
[Bug libstdc++/81751] __basic_file::sync() may flush _all_ files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81751
--- Comment #4 from Jonathan Wakely ---
But there is an open FILE and it might have pending writes or ungetc'd data
that should be flushed. I think that's why it's there. Consider:
FILE* f = std::fopen("81751.txt", "w+");
std::fwrite("Some words.", 1, 10, f);
__gnu_cxx::stdio_filebuf buf(f, std::ios::in|std::ios::out, BUFSIZ);
int c = buf.sgetc();
If the constructor doesn't flush then the read performed by sgetc will follow
the write without an intervening seek or flush, which is undefined behaviour.
The constructor taking a file descriptor creates a new FILE using fdopen, so
there are no buffered writes on the stream, and a flush isn't needed.
[Bug target/79810] ICE in ix86_vector_duplicate_value, at config/i386/i386.c:45701
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79810 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 Known to work||7.1.0 Ever confirmed|0 |1 Known to fail||5.4.0, 6.3.0 --- Comment #1 from Martin Liška --- Fixed on trunk in r246161. Do you plan Uros to backport it?
[Bug middle-end/80295] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80295 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||marxin at gcc dot gnu.org Known to work||6.4.0 Summary|ICE in |[7/8 Regression] ICE in |__builtin_update_setjmp_buf |__builtin_update_setjmp_buf |expander|expander Ever confirmed|0 |1 Known to fail||7.1.0, 8.0 --- Comment #1 from Martin Liška --- Confirmed. Started with your commit r246720.
[Bug middle-end/81782] New: Yet another -Wmaybe-uninitialized false positive with empty array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81782
Bug ID: 81782
Summary: Yet another -Wmaybe-uninitialized false positive with
empty array
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
I hope this isn't a duplicate of one of the many similar PRs. This one happens
with -O0. Also, if you remove the (int) cast, the warning disappears, because
then we get rid of the if conditional.
$ ./cc1 -quiet w.c -Wall
w.c: In function ‘foo’:
w.c:8:22: warning: ‘empty_array[i]’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
ret = empty_array[i];
~~~^~~
int
foo (void)
{
char empty_array[] = { };
int i, ret = 0;
for (i = 0; i < (int) (sizeof (empty_array) / sizeof (empty_array[0])); i++)
ret = empty_array[i];
return ret;
}
[Bug middle-end/81782] [7/8 Regression] Yet another -Wmaybe-uninitialized false positive with empty array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81782 Marek Polacek changed: What|Removed |Added Target Milestone|--- |7.2 Summary|Yet another |[7/8 Regression] Yet |-Wmaybe-uninitialized false |another |positive with empty array |-Wmaybe-uninitialized false ||positive with empty array --- Comment #1 from Marek Polacek --- Started with commit 4d2b9d1e3c794a05c00708035519290e920768e8 Author: rguenth Date: Thu Mar 2 13:42:05 2017 + 2017-03-02 Richard Biener PR tree-optimization/79345 PR c++/42000 * tree-ssa-alias.c (walk_aliased_vdefs_1): Take a limit param and abort the walk, returning -1 if it is hit. (walk_aliased_vdefs): Take a limit param and pass it on. * tree-ssa-alias.h (walk_aliased_vdefs): Add a limit param, defaulting to 0 and return a signed int. * tree-ssa-uninit.c (struct check_defs_data): New struct. (check_defs): New helper. (warn_uninitialized_vars): Use walk_aliased_vdefs to warn about uninitialized memory. * fixed-value.c (fixed_from_string): Use ulow/uhigh to avoid bogus uninitialized warning. (fixed_convert_from_real): Likewise. * g++.dg/warn/Wuninitialized-7.C: New testcase. * c-c++-common/ubsan/bounds-2.c: Add -Wno-uninitialized. * gcc.dg/uninit-pr19430-2.c: Add expected warning. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@245840 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug target/68485] ICE while building gpsd package on microblaze
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68485 --- Comment #2 from Sergio Prado --- Created attachment 41957 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41957&action=edit Pre-processed file from rtcm2_json.c compiled with -E option Here is the pre-processed file.
[Bug middle-end/81695] [5/6/7 Regression] internal compiler error: in size_binop_loc, at fold-const.c:1768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81695 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Marek Polacek --- I think I won't backport this, so closing.
[Bug libstdc++/11196] _GNU_SOURCE vs. M_PI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11196 --- Comment #16 from Jonathan Wakely --- See https://sourceware.org/bugzilla/show_bug.cgi?id=21326 and https://sourceware.org/bugzilla/show_bug.cgi?id=21327 for the changes to glibc that are needed before we can change anything in GCC.
[Bug c++/2082] g++ defines _GNU_SOURCE by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2082 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=11196 --- Comment #10 from Jonathan Wakely --- Should this be WONTFIX rather than FIXED? I think FIXED is the default for "closed" from the old gnatweb system, but this was not fixed. Or now that I'm (slowly) working on fixing it, maybe even REOPENED, or make it a dup of Bug 11196.
[Bug c/81783] New: -Wtautological-compare could do better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81783
Bug ID: 81783
Summary: -Wtautological-compare could do better
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
This example code doesn't warn with -Wtautological-compare:
int f(int a)
{
if ((a & 0x10) == 10)
return 1;
return 0;
}
clang warns like this:
Wtautological-compare-1.c:5:17: warning: bitwise comparison always evaluates to
false [-Wtautological-compare]
if ((a & 0x10) == 10)
~~~^
[Bug target/80214] ICE in s390_initial_elimination_offset, at config/s390/s390.c:10249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80214 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 79890 ***
[Bug target/79890] ICE in s390_initial_elimination_offset, at config/s390/s390.c:10430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79890 --- Comment #8 from Martin Liška --- *** Bug 80214 has been marked as a duplicate of this bug. ***
[Bug target/68485] ICE while building gpsd package on microblaze
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68485 --- Comment #3 from Martin Liška --- Created attachment 41958 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41958&action=edit Minimal test-case
[Bug target/68485] ICE while building gpsd package on microblaze
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68485 Martin Liška changed: What|Removed |Added Status|WAITING |NEW
[Bug middle-end/81782] [7/8 Regression] Yet another -Wmaybe-uninitialized false positive with empty array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81782 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||egallager at gcc dot gnu.org Blocks||24639 Ever confirmed|0 |1 --- Comment #2 from Eric Gallager --- Confirmed that GCC warns here Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug tree-optimization/79987] [CHKP] ICE in gimplify_expr, at gimplify.c:12151
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79987 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Taking, I've got a patch.
[Bug target/48227] "rep ret" generated for -march=core2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48227 --- Comment #5 from Matt Godbolt --- Seems to have been fixed in 4.9
[Bug target/80019] ICE in ix86_vector_duplicate_value, at config/i386/i386.c:42584
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80019 --- Comment #6 from H.J. Lu --- *** Bug 79810 has been marked as a duplicate of this bug. ***
[Bug target/79810] ICE in ix86_vector_duplicate_value, at config/i386/i386.c:45701
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79810 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from H.J. Lu --- (In reply to Martin Liška from comment #1) > Fixed on trunk in r246161. Do you plan Uros to backport it? Should have been fixed on all branches. *** This bug has been marked as a duplicate of bug 80019 ***
[Bug target/68485] ICE while building gpsd package on microblaze
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68485 Martin Liška changed: What|Removed |Added CC||eager at gcc dot gnu.org --- Comment #4 from Martin Liška --- Started with r248540: commit 707a69dfb56a2976e2b5c010f0e5cb2ac9905a07 (refs/bisect/bad) Author: eager Date: Sat May 27 18:29:40 2017 + Revert: 2016-01-21 Ajit Agarwal See https://gcc.gnu.org/ml/gcc/2017-05/msg00221.html. * config/microblaze/microblaze.h (FIXED_REGISTERS): Update in macro. (CALL_USED_REGISTERS): Update in macro. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@248540 138bc75d-0d04-0410-961f-82ee72b054a4 Can you please Agit take a look?
[Bug target/78643] [5/6/7/8 Regression] ICE in convert_move, at expr.c:230
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78643 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|ICE in convert_move, at |[5/6/7/8 Regression] ICE in |expr.c:230 |convert_move, at expr.c:230 Ever confirmed|0 |1 Known to fail||8.0 --- Comment #1 from Martin Liška --- Confirmed, started with r220609.https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78643#
[Bug preprocessor/53404] warning column reported on comment in warning during bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53404
--- Comment #4 from Eric Gallager ---
(In reply to Eric Gallager from comment #3)
> (In reply to Manuel López-Ibáñez from comment #2)
> > I don't see this any longer.
>
> I think I might've seen this before, but I'll have to double-check the next
> time I bootstrap to make sure
The warnings I get from gengtype-lex.c when bootstrapping are now:
../../gcc/gengtype-lex.l: In function ‘int yylex(const char**)’:
gengtype-lex.c:287:13: warning: this statement may fall through
[-Wimplicit-fallthrough=]
*yy_cp = '\0'; \
~~~^~~
../../gcc/gengtype-lex.l:116:1: note: in expansion of macro
‘YY_DO_BEFORE_ACTION’
*yylval = XDUPVAR (const char, yytext, yyleng, yyleng + 1);
^ ~~~
../../gcc/gengtype-lex.l:113:1: note: here
"~" |
^~~~
gengtype-lex.c:287:13: warning: this statement may fall through
[-Wimplicit-fallthrough=]
*yy_cp = '\0'; \
~~~^~~
../../gcc/gengtype-lex.l:133:1: note: in expansion of macro
‘YY_DO_BEFORE_ACTION’
^
../../gcc/gengtype-lex.l:131:1: note: here
"ENUM_BITFIELD"{WS}?"("{WS}?{ID}{WS}?")" {
^~~~
...which is no longer in a comment, but it still seems like there's some wrong
location information involved. Separate issue or the same thing?
[Bug target/77953] [MIPS] ice: insn does not satisfy its constraints - __bswapsi2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77953 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-08-09 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can't reproduce on x86_64-linux-gnu cross compiler. Is it reproducible?
[Bug c++/2082] g++ defines _GNU_SOURCE by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2082 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Resolution|FIXED |WONTFIX --- Comment #11 from Eric Gallager --- (In reply to Jonathan Wakely from comment #10) > Should this be WONTFIX rather than FIXED? I think FIXED is the default for > "closed" from the old gnatweb system, but this was not fixed. > > Or now that I'm (slowly) working on fixing it, maybe even REOPENED, or make > it a dup of Bug 11196. From reading the previous comments it looks like WONTFIX is indeed more accurate than FIXED, so I'm changing the status to that for now. Bug 11196 looks like a more specific instance of this one so I'd say if one's going to be marked a duplicate of the other, it should probably be the other way around.
[Bug debug/80938] [7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80938 Segher Boessenkool changed: What|Removed |Added Target|powerpcspe-*-linux-gnu* |powerpcspe-*-linux-gnu*, ||powerpc*-*-* --- Comment #2 from Segher Boessenkool --- Also fails on powerpc*-linux (it needs -Os -fPIC -m32 -g). It gets a conflict in the CFI for the hard frame pointer.
[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #8 from Alexander Monakov --- Mike, you can start by preparing two build trees, one with faulty mesa compiled with -march=native, the other with working-fine mesa compiled with -march=native -mno-bmi. You should be able to collect: - .o files from each tree, and - link commands from build logs and be able to re-link mesa libraries by hand and verify they still exhibit the same behavior (one fails, the other doesn't). >From there you can proceed by building "hybrid" libraries by taking a set of good .o files and a complementary set of bad .o files. This will allow you to find a single .o file that makes the library behave wrongly. More explanation and a helper script for bisecting is available at https://gcc.gnu.org/wiki/Analysing_Large_Testcases At that point please share your status (once you're down to one file there's no generic recipe, you'd have to get creative).
[Bug libstdc++/81751] __basic_file::sync() may flush _all_ files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81751
--- Comment #5 from Volker Wehrs ---
I'm sorry but I ignored the first if-clause in sys_open(). That if-clause makes
sure there is no open file referenced by the __basic_file, otherwise sys_open()
fails.
Then the sync() is called before the new __file is set, so in the current
implementation sync() can only see a _M_cfile set to NULL. Thus sync() is wrong
here.
Note that currently the new file (in __file) is implicitly flushed by the call
to fflush("NULL"), i.e. "flush all". So the new file should be sync'd
explicitly.
So sys_open() might look like this:
__basic_file*
__basic_file::sys_open(__c_file* __file, ios_base::openmode)
{
__basic_file* __ret = NULL;
if (!this->is_open() && __file)
{
_M_cfile = __file;
_M_cfile_created = false;
__ret = this;
this->sync();
}
return __ret;
}
[...]
int
__basic_file::sync()
{
int __err;
do
__err = fflush(_M_cfile);
while ( __err && errno == EINTR );
return __err;
}
[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763 --- Comment #9 from Alexander Monakov --- A (potentially simpler) alternative is to use sequential builds (make without -j) and bisect by index of compiled source file, i.e. have a wrapper script around gcc that uses some global counter to pass -mno-bmi to first N compiler invocations.
[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763 --- Comment #10 from Mike Lothian --- Unfortunately it also depends on LLVM not just Mesa which makes it a much bigger target for figuring this out
[Bug target/79565] ICE in copy_to_mode_reg, at explow.c:612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79565 H.J. Lu changed: What|Removed |Added Status|NEW |WAITING --- Comment #1 from H.J. Lu --- (In reply to Martin Liška from comment #0) > All releases I have suffer from: > > Clang is also broken, ICC work for that test-case. What does ICC generate with -mno-mmx -O0?
[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850 --- Comment #12 from DIL --- Could you please tell me if there is a way I can check whether the dissociated unlimited polymorphic pointer (class(*), pointer), which is set to NULL, is indeed set to a clean state internally? That is, could you please tell me the size and structure of the internal representation of a class(*) pointer and what the proper values of those components would be when the pointer is set to NULL()? I am still trying to understand why the sourced allocate() statement sees that pointer as ALLOCATED. Basically, I want to inspect the internal state of the class(*) NULL pointer to make sure that the problem indeed occurs inside the sourced allocate() statement. Thanks!
[Bug c++/81586] valgrind error in output_buffer_append_r with -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81586 --- Comment #6 from David Binderman --- (In reply to Martin Sebor from comment #5) > Patch: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01866.html Did this patch ever get into trunk gcc ? I have some evidence that gcc trunk revision 250947 doesn't have it.
[Bug target/80503] ICE in extract_insn, at recog.c:2311 on ppc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80503 --- Comment #1 from Segher Boessenkool --- Is this a dup of PR80618? That is fixed on all branches already.
[Bug testsuite/81784] New: [8 regression] gcc.dg/compare2.c fails starting with r250984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81784 Bug ID: 81784 Summary: [8 regression] gcc.dg/compare2.c fails starting with r250984 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- The recent change to the test case gcc.dg/compare2.c doesn't seem to work quite right. At least not on powerpc64 where it fails on both BE and LE (tested on power8). spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk/gcc/xgcc -B/home/seurer/gcc/build/gcc-trunk/gcc/ /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c -fno-diagnostics-show-caret -fdiagnostics-color=never -Wsign-compare -S -o compare2.s /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c: In function 'f': /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:21:5: warning: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Wsign-compare] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:25:5: warning: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Wsign-compare] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:37:5: warning: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Wsign-compare] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:41:5: warning: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Wsign-compare] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:49:12: warning: operand of ?: changes signedness from 'int' to 'unsigned int' due to unsignedness of other operand [-Wsign-compare] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:57:12: warning: operand of ?: changes signedness from 'int' to 'unsigned int' due to unsignedness of other operand [-Wsign-compare] output is: /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c: In function 'f': /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:21:5: warning: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Wsign-compare] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:25:5: warning: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Wsign-compare] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:37:5: warning: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Wsign-compare] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:41:5: warning: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Wsign-compare] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:49:12: warning: operand of ?: changes signedness from 'int' to 'unsigned int' due to unsignedness of other operand [-Wsign-compare] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:57:12: warning: operand of ?: changes signedness from 'int' to 'unsigned int' due to unsignedness of other operand [-Wsign-compare] PASS: gcc.dg/compare2.c case 1 (test for bogus messages, line 12) PASS: gcc.dg/compare2.c case 2 (test for bogus messages, line 13) PASS: gcc.dg/compare2.c case 3 (test for bogus messages, line 16) PASS: gcc.dg/compare2.c case 4 (test for bogus messages, line 17) PASS: gcc.dg/compare2.c case 5 (test for bogus messages, line 20) PASS: gcc.dg/compare2.c case 6 (test for warnings, line 21) PASS: gcc.dg/compare2.c case 7 (test for bogus messages, line 24) PASS: gcc.dg/compare2.c case 8 (test for warnings, line 25) PASS: gcc.dg/compare2.c case 9 (test for bogus messages, line 28) PASS: gcc.dg/compare2.c case 10 (test for bogus messages, line 29) PASS: gcc.dg/compare2.c case 11 (test for bogus messages, line 32) PASS: gcc.dg/compare2.c case 12 (test for bogus messages, line 33) PASS: gcc.dg/compare2.c case 13 (test for bogus messages, line 36) PASS: gcc.dg/compare2.c case 14 (test for warnings, line 37) PASS: gcc.dg/compare2.c case 15 (test for bogus messages, line 40) PASS: gcc.dg/compare2.c case 16 (test for warnings, line 41) PASS: gcc.dg/compare2.c case 17 (test for bogus messages, line 44) PASS: gcc.dg/compare2.c case 18 (test for bogus messages, line 45) PASS: gcc.dg/compare2.c case 19 (test for bogus messages, line 48) FAIL: gcc.dg/compare2.c case 20 (test for warnings, line 49) PASS: gcc.dg/compare2.c case 21 (test for bogus messages, line 52) PASS: gcc.dg/compare2.c case 22 (test for bogus messages, line 53) PASS: gcc.dg/compare2.c case 23 (test for bogus messages, line 56) FAIL: gcc.dg/compare2.c case 24 (test for warnings, line 57) FAIL: gcc.dg/compare2.c (test for excess errors) Excess errors: /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:49:12: warning: operand of ?: changes signedness from 'int' to 'unsigned int' due to unsignedness of other
[Bug c++/81767] Unused variable warning with structured binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81767 Antony Polukhin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Antony Polukhin --- Yep, feature was already implemented in r248483
[Bug target/79565] ICE in copy_to_mode_reg, at explow.c:612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79565
--- Comment #2 from H.J. Lu ---
Created attachment 41959
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41959&action=edit
A patch
I got
[hjl@gnu-6 pr79565]$ cat x.i
typedef float a __attribute__ ((__vector_size__ (16)));
a b, d;
int __attribute__ ((__vector_size__ (2 * sizeof (int c;
void e () { d = __builtin_ia32_cvtpi2ps (b, c); }
[hjl@gnu-6 pr79565]$ make x.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -mno-mmx -S -o x.s x.i
x.i: In function ‘e’:
x.i:4:17: error: ‘__builtin_ia32_cvtpi2ps’ needs isa option -m32 -msse -mmmx
void e () { d = __builtin_ia32_cvtpi2ps (b, c); }
^~
make: *** [Makefile:21: x.s] Error 1
[hjl@gnu-6 pr79565]$ cat y.i
typedef short v4hi __attribute__ ((__vector_size__ (4 * sizeof (short;
v4hi a, b, c;
void
foo (void)
{
a = __builtin_ia32_psubusw (b, c);
}
[hjl@gnu-6 pr79565]$ make y.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -mno-mmx -S -o y.s y.i
y.i: In function ‘foo’:
y.i:6:7: error: ‘__builtin_ia32_psubusw’ needs isa option -m32 -mmmx
a = __builtin_ia32_psubusw (b, c);
^
make: *** [Makefile:21: y.s] Error 1
[hjl@gnu-6 pr79565]$
[Bug c++/81767] Unused variable warning with structured binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81767 Jonathan Wakely changed: What|Removed |Added Resolution|INVALID |FIXED Target Milestone|--- |8.0
[Bug libgomp/81778] libgomp.c/for-5.c failure on nvptx -- illegal memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81778 Alexander Monakov changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 Ever confirmed|0 |1 --- Comment #4 from Alexander Monakov --- I agree that simd loop in the presented testcase is mishandled, but fwiw the original for-5.c testcase should not exhibit this issue with loop counter wraparound; the root cause must have been different in the original failure you were seeing.
[Bug libstdc++/81751] __basic_file::sync() may flush _all_ files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81751 --- Comment #6 from Jonathan Wakely --- Or just call fflush(__file) directly: https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00673.html
[Bug middle-end/80295] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80295 --- Comment #2 from Andreas Schwab --- No, it doesn't. It only made it possible to call the builtin from the frontend.
[Bug target/81753] Building of cross-compiler for powerpc-darwin7 is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81753 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #6 from Segher Boessenkool --- (In reply to Martin Liška from comment #4) > I can confirm it works ;) Should I send the patch and install it? Please send the patch for review.
[Bug testsuite/81784] [8 regression] gcc.dg/compare2.c fails starting with r250984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81784 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-08-09 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763 --- Comment #11 from Mike Lothian --- So a lot of the segfaults I see are in si_shader so I thought I'd compile Mesa with and without BMI and compare the onjdumps of the two .o files CFLAGS="-O2 -march=native -pipe -mno-bmi -m32" CXXFLAGS="-O2 -march=native -pipe -mno-bmi -m32" LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fuse-ld=bfd -m32" ./autogen.sh --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --docdir=/usr/share/doc/mesa- --htmldir=/usr/share/doc/mesa-/html --libdir=/usr/lib32 --enable-dri --enable-glx --enable-shared-glapi --enable-texture-float --enable-nine --disable-debug --enable-dri3 --enable-egl --enable-gbm --enable-gles1 --enable-gles2 --enable-glx-tls --disable-libunwind --enable-valgrind=no --enable-llvm-shared-libs --with-dri-drivers=,swrast,i965 --with-gallium-drivers=,swrast,radeonsi --with-vulkan-drivers=,intel,radeon PYTHON2=/usr/bin/python2.7 --with-platforms=x11,surfaceless,wayland,drm --enable-nine --enable-llvm --enable-omx --enable-va --enable-vdpau --disable-xa --disable-xvmc --with-va-libdir=/usr/lib32/va/drivers --disable-glx-read-only-text --disable-gallium-osmesa CFLAGS="-O2 -march=native -pipe -m32" CXXFLAGS="-O2 -march=native -pipe -m32" LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fuse-ld=bfd -m32" ./autogen.sh --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --docdir=/usr/share/doc/mesa- --htmldir=/usr/share/doc/mesa-/html --libdir=/usr/lib32 --enable-dri --enable-glx --enable-shared-glapi --enable-texture-float --enable-nine --disable-debug --enable-dri3 --enable-egl --enable-gbm --enable-gles1 --enable-gles2 --enable-glx-tls --disable-libunwind --enable-valgrind=no --enable-llvm-shared-libs --with-dri-drivers=,swrast,i965 --with-gallium-drivers=,swrast,radeonsi --with-vulkan-drivers=,intel,radeon PYTHON2=/usr/bin/python2.7 --with-platforms=x11,surfaceless,wayland,drm --enable-nine --enable-llvm --enable-omx --enable-va --enable-vdpau --disable-xa --disable-xvmc --with-va-libdir=/usr/lib32/va/drivers --disable-glx-read-only-text --disable-gallium-osmesa Were my configure options, and LLVM was compiled with -mno-bmi I'm attaching the dumps
[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763 --- Comment #12 from Mike Lothian --- Created attachment 41960 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41960&action=edit si_shader objdumps
[Bug target/80503] ICE in extract_insn, at recog.c:2311 on ppc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80503 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Martin Liška --- Confirmed, it's dup. *** This bug has been marked as a duplicate of bug 80618 ***
[Bug target/80618] [8 regression] test case gcc.dg/pr50310-2.c fails with ICE starting with 247544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80618 --- Comment #14 from Martin Liška --- *** Bug 80503 has been marked as a duplicate of this bug. ***
[Bug libstdc++/79820] std::ifstream sets errno to zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79820 --- Comment #8 from Jonathan Wakely --- Author: redi Date: Wed Aug 9 17:52:10 2017 New Revision: 250993 URL: https://gcc.gnu.org/viewcvs?rev=250993&root=gcc&view=rev Log: PR libstdc++/81751 don't call fflush(NULL) PR libstdc++/79820 PR libstdc++/81751 * config/io/basic_file_stdio.cc (sys_open(FILE*, ios_base::openmode)): Call fflush on the stream instead of calling sync() while _M_cfile is null. Restore original value of errno. * testsuite/ext/stdio_filebuf/char/79820.cc: New. * testsuite/ext/stdio_filebuf/char/81751.cc: New. Added: trunk/libstdc++-v3/testsuite/ext/stdio_filebuf/char/79820.cc trunk/libstdc++-v3/testsuite/ext/stdio_filebuf/char/81751.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/io/basic_file_stdio.cc
[Bug libstdc++/81751] __basic_file::sync() may flush _all_ files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81751 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Wed Aug 9 17:52:10 2017 New Revision: 250993 URL: https://gcc.gnu.org/viewcvs?rev=250993&root=gcc&view=rev Log: PR libstdc++/81751 don't call fflush(NULL) PR libstdc++/79820 PR libstdc++/81751 * config/io/basic_file_stdio.cc (sys_open(FILE*, ios_base::openmode)): Call fflush on the stream instead of calling sync() while _M_cfile is null. Restore original value of errno. * testsuite/ext/stdio_filebuf/char/79820.cc: New. * testsuite/ext/stdio_filebuf/char/81751.cc: New. Added: trunk/libstdc++-v3/testsuite/ext/stdio_filebuf/char/79820.cc trunk/libstdc++-v3/testsuite/ext/stdio_filebuf/char/81751.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/io/basic_file_stdio.cc
[Bug debug/80938] [7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80938 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #3 from Segher Boessenkool --- I have a patch (for rs6000).
[Bug libstdc++/79820] std::ifstream sets errno to zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79820 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #9 from Jonathan Wakely --- Fixed for GCC 8.
[Bug target/67694] ICE on returning undefined enum in must_pass_in_stack_var_size_or_pad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67694 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed for GCC 6 and 7.
[Bug c++/81359] [7/8 Regression] bogus error: constructor required before non-static data member for ‘Foo::Bar::test’ has been parsed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81359 --- Comment #3 from Jason Merrill --- Author: jason Date: Wed Aug 9 18:32:02 2017 New Revision: 250994 URL: https://gcc.gnu.org/viewcvs?rev=250994&root=gcc&view=rev Log: PR c++/81359 - Unparsed NSDMI error from SFINAE context. * init.c (get_nsdmi): Add complain parm. * typeck2.c (digest_nsdmi_init): Add complain parm. (process_init_constructor_record): Pass complain to get_nsdmi. * pt.c (maybe_instantiate_noexcept): Add complain parm, return bool. * method.c (get_defaulted_eh_spec): Add complain parm. Pass it into synthesized_method_walk. (synthesized_method_walk): Adjust. (walk_field_subobs): Pass complain to get_nsdmi. (defaulted_late_check): Skip other checks if deleted. * decl2.c (mark_used): Pass complain to maybe_instantiate_noexcept. * call.c (build_aggr_conv): Pass complain to get_nsdmi. * parser.c (defarg_location): New. * error.c (location_of): Use it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/sfinae59.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl2.c trunk/gcc/cp/error.c trunk/gcc/cp/init.c trunk/gcc/cp/method.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-defer6.C trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-template14.C trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi10.C
[Bug libstdc++/81359] [7 Regression] bogus error: constructor required before non-static data member for ‘Foo::Bar::test’ has been parsed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81359 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|NEW Component|c++ |libstdc++ Assignee|jason at gcc dot gnu.org |unassigned at gcc dot gnu.org Summary|[7/8 Regression] bogus |[7 Regression] bogus error: |error: constructor required |constructor required before |before non-static data |non-static data member for |member for ‘Foo::Bar::test’ |‘Foo::Bar::test’ has been |has been parsed |parsed --- Comment #4 from Jason Merrill --- I've adjusted the compiler to accept this on trunk, but the change is too invasive for the GCC 7 branch. I'm changing the component to libstdc++ so that library folks can consider a library approach for the branch.
[Bug c/81785] New: Segmentation fault for signed overflow in index expression when -fwrapv is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81785
Bug ID: 81785
Summary: Segmentation fault for signed overflow in index
expression when -fwrapv is enabled
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: willwalker26 at gmail dot com
Target Milestone: ---
Created attachment 41961
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41961&action=edit
reproduction preprocessed file
gcc version 4.9.2 (Debian 4.9.2-10)
Target: x86_64-linux-gnu
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O0' '-fwrapv' '-mtune=generic'
'-march=x86-64'
Compiling the c file (see the attached preprocessed file):
% gcc -O0 -fwrapv repro.c
Execution results in:
% ./a.out
Segmentation fault
I also tried with varied levels of optimization to the same results. It looks
like 4.7.x and earlier versions of gcc work as expected.
The offending code segment is:
unsigned int k;
unsigned int i;
i = 0U;
k = 2147483648U;
while (k < 2147483658U) {
y[i] = x[(int)k - (int)2147483611];
k++;
i++;
}
What I was hoping to happen, is to have (int)k wrap to some large negative
value and the following signed subtraction wrap to a small positive value in
the range [37,46]. Note the arrays for x and y are length 100.
I am aware that signed overflow is not defined in C, but was hoping that using
the -fwrapv compiler option would let this through.
Note, hoisting out the index expression results in the expected execution,
e.g.:
tmp = (int)k - (int)2147483611;
y[i] = x[tmp];
[Bug libgomp/68033] OpenMP: ICE with teams distribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68033
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment #2 from Martin Jambor ---
Below is a slightly more reduced testcase, crashes with gcc -S -fopenmp.
From what I have gathered so far, we would like to issue an error from
the gimplifier about a non sharing of an artificial temporary variable
that has not DECL_NAME and thus segfault.
void lud_omp(float *a, int size)
{
int i,j,k;
float sum;
for (i=0; i
[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763 --- Comment #13 from H.J. Lu --- (In reply to Mike Lothian from comment #12) > Created attachment 41960 [details] > si_shader objdumps We need a small testcase in C.
[Bug target/68834] ICE: in decompose_normal_address, at rtlanal.c:6086 with -O2 -fPIC --param=sched-autopref-queue-depth=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68834 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||marxin at gcc dot gnu.org, ||segher at gcc dot gnu.org Known to work||7.1.0, 8.0 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, it's connected to haifa scheduler. Fixed on trunk in r239105 as we switched to LRA. It's probably broken since the problematic param was introduced.
[Bug target/67643] [SH] ICE with ISR and -mfmovd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67643 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||aoliva at gcc dot gnu.org, ||kkojima at gcc dot gnu.org, ||marxin at gcc dot gnu.org, ||olegendo at gcc dot gnu.org Known to work||4.9.0 Ever confirmed|0 |1 Known to fail||5.4.0 --- Comment #1 from Martin Liška --- Confirmed, 4.9 looks fine, while 5 is affected by the ICE. Adding port maintainers.
[Bug target/67638] [SH] ICE with nosave_low_regs ISR and -mfmovd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67638 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-08-09 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can't reproduce with cross compiler on trunk and gcc-5 branch. Is it reproducible with cross compiler? Which options do you use?
[Bug target/67586] xtensa: ICE with -Os -g -fno-builtin-malloc in dwarf2out_var_location, at dwarf2out.c:22380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67586 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-08-09 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can't reproduce with cross-compiler, is it reproducible on x86_64-linux-gnu?
