[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 Francois-Xavier Coudert changed: What|Removed |Added Status|WAITING |ASSIGNED CC||fxcoudert at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |fxcoudert at gcc dot gnu.org
[Bug fortran/57598] [Coarray,caf] Add FPE summary printing for ERROR STOP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57598 Francois-Xavier Coudert changed: What|Removed |Added Status|WAITING |NEW CC||fxcoudert at gcc dot gnu.org Summary|[Coarray,caf] Add |[Coarray,caf] Add FPE |FPE-Summary printing|summary printing for ERROR |(floating-point exception) |STOP |for STOP/ERROR STOP | --- Comment #2 from Francois-Xavier Coudert --- The co-array part does not seem fixed.
[Bug libfortran/62768] Handling of file names with embedded nulls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62768 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Francois-Xavier Coudert --- Fixed.
[Bug libgcc/63182] [5.0 Regression] libgcov-interface.c:136:33: error: alias definitions not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63182 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Francois-Xavier Coudert --- This appears to be fixed on current trunk. Closing.
[Bug c++/63388] New: cout of enum class value - segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63388
Bug ID: 63388
Summary: cout of enum class value - segmentation fault
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kuq03132 at qoika dot com
See example:
//==go.cpp
#include
enum class Month {jan=1, feb, mar, apr, may, jun, jul, aug, sep, oct, nov,
dec};
std::ostream& operator<<(std::ostream& os, Month m)
{
return os << m;// BUG - SEGMENTATION FAULT
}
int main()
{
Month m = Month::may;
std::cout << m << '\n';
return 0;
}
//
Compiled and run with:
c++ -std=c++11 -o go go.cpp
./go
Segmentation fault
DON'T WE WANT a COMPILER ERROR INSTEAD?
(Segfaulting with something so "simple" is very dangerous!)
(Problem also if -std=c++14)
To get the code to work correctly, we can convert the Month m to int:
int(m)
std::ostream& operator<<(std::ostream& os, Month m)
{
return os << int(m); // CONVERT TO INT - ok
}
Thanks.
A.
PS: Thanks for the gnu c++ compiler. I know I say "simple" above. But I'm not
fooled. A c++ compiler is a complex monster.
[Bug c++/63388] cout of enum class value - segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63388 --- Comment #1 from kuq03132 at qoika dot com --- (problem might be in libstdc++)
[Bug c++/63388] cout of enum class value - segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63388 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andreas Schwab --- Endless recursion, os << m is calling operator<<(std::ostream&,Month).
[Bug c++/63388] cout of enum class value - segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63388 Marc Glisse changed: What|Removed |Added Keywords||diagnostic Severity|major |normal --- Comment #3 from Marc Glisse --- I guess it would be possible to have an optional warning, late in the optimization process, when we see an empty infinite loop: : goto ; I don't know how many false positives we would get from that, but the limitation to an empty block might make them rare enough.
[Bug c++/63388] cout of enum class value - segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63388 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org Resolution|INVALID |DUPLICATE --- Comment #4 from Manuel López-Ibáñez --- (In reply to Marc Glisse from comment #3) > I guess it would be possible to have an optional warning, late in the > optimization process, when we see an empty infinite loop: Indeed. Such warning is an old request... *** This bug has been marked as a duplicate of bug 53871 ***
[Bug c/53871] Please warn about endless loops if they are obvious
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871 Manuel López-Ibáñez changed: What|Removed |Added CC||kuq03132 at qoika dot com --- Comment #5 from Manuel López-Ibáñez --- *** Bug 63388 has been marked as a duplicate of this bug. ***
[Bug testsuite/58321] FAIL: gcc.target/i386/memcpy-strategy-3.c scan-assembler-times memcpy 2 on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58321
Dominique d'Humieres changed:
What|Removed |Added
CC||mrs at gcc dot gnu.org
--- Comment #2 from Dominique d'Humieres ---
Would the following patch be acceptable?
--- ../_clean/gcc/testsuite/gcc.target/i386/memcpy-strategy-3.c2014-05-10
23:13:06.0 +0200
+++ gcc/testsuite/gcc.target/i386/memcpy-strategy-3.c2014-09-27
15:15:50.0 +0200
@@ -1,6 +1,7 @@
/* { dg-do compile } */
/* { dg-options "-O2 -march=atom
-mmemcpy-strategy=vector_loop:2000:align,libcall:-1:align" } */
-/* { dg-final { scan-assembler-times "memcpy" 2 } } */
+/* { dg-final { scan-assembler-times "memcpy" 2 { target { ! *-*-darwin* } } }
} */
+/* { dg-final { scan-assembler-times "memcpy" 1 { target i?86-*-darwin*
x86_64-*-darwin* } } } */
char a[2048];
char b[2048];
--- ../_clean/gcc/testsuite/gcc.target/i386/memset-strategy-1.c2014-05-10
23:13:02.0 +0200
+++ gcc/testsuite/gcc.target/i386/memset-strategy-1.c2014-09-27
15:14:08.0 +0200
@@ -1,6 +1,7 @@
/* { dg-do compile } */
/* { dg-options "-O2 -march=atom -mmemset-strategy=libcall:-1:align" } */
-/* { dg-final { scan-assembler-times "memset" 2 } } */
+/* { dg-final { scan-assembler-times "memset" 2 { target { ! *-*-darwin* } } }
} */
+/* { dg-final { scan-assembler-times "memset" 1 { target i?86-*-darwin*
x86_64-*-darwin* } } } */
char a[2048];
void t (void)
[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969 Maciej W. Rozycki changed: What|Removed |Added CC||ma...@linux-mips.org --- Comment #31 from Maciej W. Rozycki --- PR 61397 is another fallout, on Power.
[Bug bootstrap/61164] GCC 4.9.0 fails to build libitm when fortification enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61164 --- Comment #2 from Gleb Pfotenhauer-Malinowski --- Patch: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02460.html
[Bug fortran/37173] Check whether intrinsic assignment between character kind=1 / 4 is allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37173 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |ASSIGNED CC||fxcoudert at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |fxcoudert at gcc dot gnu.org --- Comment #2 from Francois-Xavier Coudert --- Long overdue, though it's not particularly bad (and it appears noöne uses non-default character kinds anyway). I'll take care of it.
[Bug middle-end/63376] [5.0 Regression] ICE: in operator[], at vec.h:736 compiling team.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63376 --- Comment #2 from John David Anglin --- This was bug was introduced by r214422: Author: marxin Date: Mon Aug 25 13:01:47 2014 New Revision: 214422 URL: https://gcc.gnu.org/viewcvs?rev=214422&root=gcc&view=rev Log: IPA C++ refactoring 4/N * cgraph.h (symtab_node): (bool needed_p (void)): created from decide_is_symbol_needed (bool referred_to_p (void)): created from referred_to_p (static cgraph_node *get_for_asmname (tree asmname)): created from symtab_node_for_asm
[Bug fortran/36534] Bogus: '__convert_s1_s4' at (1) is obsolescent in fortran 95
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36534 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |ASSIGNED CC||fxcoudert at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |fxcoudert at gcc dot gnu.org
[Bug c++/59804] C++ front-end checking ends in an infinite loop on erroneous code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59804
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||error-recovery,
||ice-checking
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-09-27
CC||manu at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||4.9.0, 5.0
--- Comment #1 from Manuel López-Ibáñez ---
It is recursing here:
1396#ifdef ENABLE_CHECKING
1397 if (USE_CANONICAL_TYPES)
1398{
1399 bool result = structural_comptypes (t1, t2, strict);
so we get:
#0 comptypes (t1=0x76db4000, t2=0x76d59000, strict=) at
/home/manuel/test1/pristine/gcc/cp/typeck.c:1401
#1 0x006f5e1e in structural_comptypes (t1=0x76db42a0,
t2=0x76d592a0, strict=0) at
/home/manuel/test1/pristine/gcc/cp/typeck.c:1341
#2 0x006f7c88 in comptypes (t1=0x76db42a0, t2=0x76d592a0,
strict=) at /home/manuel/test1/pristine/gcc/cp/typeck.c:1399
#3 0x006f5e1e in structural_comptypes (t1=0x76db4540,
t2=0x76d59540, strict=0) at
/home/manuel/test1/pristine/gcc/cp/typeck.c:1341
#4 0x006f7c88 in comptypes (t1=0x76db4540, t2=0x76d59540,
strict=) at /home/manuel/test1/pristine/gcc/cp/typeck.c:1399
#5 0x006f5e1e in structural_comptypes (t1=0x76db47e0,
t2=0x76d597e0, strict=0) at
/home/manuel/test1/pristine/gcc/cp/typeck.c:1341
#6 0x006f7c88 in comptypes (t1=0x76db47e0, t2=0x76d597e0,
strict=) at /home/manuel/test1/pristine/gcc/cp/typeck.c:1399
#7 0x006f5e1e in structural_comptypes (t1=0x76db4a80,
t2=0x76d59a80, strict=0) at
/home/manuel/test1/pristine/gcc/cp/typeck.c:1341
#8 0x006f7c88 in comptypes (t1=0x76db4a80, t2=0x76d59a80,
strict=) at /home/manuel/test1/pristine/gcc/cp/typeck.c:1399
#9 0x006f5e1e in structural_comptypes (t1=0x76db4d20,
t2=0x76d59d20, strict=0) at
/home/manuel/test1/pristine/gcc/cp/typeck.c:1341
[Bug c++/16564] g++ seems to go into an infinite loop after errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #22 from Manuel López-Ibáñez --- (In reply to Volker Reichelt from comment #18) > The first error message about exceeding the maximum template instantiation > depth appears rather quickly. So maybe we could make the first error message > a fatal one to avoid further processing of potentially bogus nested classes. This is a patch doing exactly that: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01709.html However, I probably won't have time until the Christmas holidays to work on it, so please anyone feel free to take it and get it reviewed and applied. Thanks!
[Bug c++/63389] New: Wrong warning about 64 bit integer constant overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63389 Bug ID: 63389 Summary: Wrong warning about 64 bit integer constant overflow Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ingo.josopait at gmx dot de Declaring the following constant creates a warning. I don't think it should. -2^63 is the largest negative 64 bit integer value. The same warning appears when compiling C language. long i = -9223372036854775808L; // equals -2^63 The compiler output is: test.cpp:1:11: warning: integer constant is so large that it is unsigned long i = -9223372036854775808L; ^ test.cpp:1:1: warning: this decimal constant is unsigned only in ISO C90 long i = -9223372036854775808L;
[Bug c++/63389] Wrong warning about 64 bit integer constant overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63389 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- In c, - and constants are two different tokens.
[Bug target/54236] [SH] Improve addc and subc insn utilization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54236
--- Comment #9 from Oleg Endo ---
The following function compiled with -O2
unsigned int check (unsigned int x)
{
return x == 0 ? 1 : x;
}
results in:
tst r4,r4
bt/s.L7
mov #1,r0
mov r4,r0
.L7:
rts
nop
Writing it as:
unsigned int check (unsigned int x)
{
return x + (x == 0);
}
results in:
tst r4,r4
mov #0,r0
rts
addcr4,r0
It seems that ifcvt is trying to utilize the 'addcc' standard name
pattern. If the 2nd operand of the conditional addition is a constant 1 or -1
the addcc insn can be implemented via addc or subc without a branch.
If the comparison can't be done in one insn (e.g. x != 0) and requires T bit
negation/inversion:
unsigned int check (unsigned int x)
{
return x + (x != 0);
}
results in (non-SH2A):
tst r4,r4
mov #-1,r0
negcr0,r0
rts
add r4,r0
slightly better (one arith insn less):
tst r4,r4
mov #-1,r0
subcr0,r4// r4 = r4 - (-1) - T = r4 + 1 - T
rts
mov r4,r0
and on SH2A (already minimal):
tst r4,r4
movrt r0
rts
add r4,r0
subc case:
unsigned int check (unsigned int x)
{
return x - (x != 0);
}
non-SH2A:
tst r4,r4
mov #-1,r1
mov r4,r0
negcr1,r1
rts
sub r1,r0// r0 = r4 - (1 - T) = r4 - 1 + T
SH2A:
tst r4,r4
movrt r1
mov r4,r0
rts
sub r1,r0
better (non-SH2A and SH2A):
tstr4,r4
mov#-1,r0
rts
addc r4,r0 // r0 = -1 + r4 + T = r4 - 1 + T
The equivalent conditional version should result in the same (currently it
isn't):
unsigned int check (unsigned int x)
{
return x != 0 ? (x - 1) : x;
}
Since ifcvt is also ran after combine, combine won't get the chance to combine
patterns such as:
(set (reg:SI 165 [ D.1635 ])
(plus:SI (xor:SI (reg:SI 147 t)
(const_int 1 [0x1]))
(reg/v:SI 164 [ x ])))
which would occur after emitting a comparison, negating the result (T bit) and
then adding/subtracting the T bit via addc/subc. If that happens, the combine
must be done manually in the split pass as it's done with some of the other
insns.
[Bug bootstrap/61164] GCC 4.9.0 fails to build libitm when fortification enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61164 --- Comment #3 from Gleb Pfotenhauer-Malinowski --- https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02469.html Sorry, previous patch is incomplete.
[Bug c++/63391] New: Erroneous -Wsign-conversion with offsetof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63391
Bug ID: 63391
Summary: Erroneous -Wsign-conversion with offsetof
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at geometrian dot com
//Bug report:
//by Ian Mallett
//Compile with "g++ -std=c++11 -Wsign-conversion
#include
#include
struct Foo {
char data;
};
int main(int /*argc*/, char* /*argv*/[]) {
int num = 6;
#if 0 //No warning
size_t offset = offsetof(struct Foo,data);
delete [] new char[offset*static_cast(num)];
#else //warning
delete [] new char[offsetof(struct Foo,data)*static_cast(num)];
#endif
return 0;
}
[Bug target/63390] New: [SH] Hoist/schedule constant pool loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63390
Bug ID: 63390
Summary: [SH] Hoist/schedule constant pool loads
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
The following example resembles a use case where a tagged pointer (1 bit tag in
LSB) is tested for nullptr and a function is invoked with the extracted normal
pointer:
void foo (unsigned int, int);
void test (unsigned int* x)
{
if (__builtin_expect ((*x >> 1) != 0, 1))
foo (*x >> 1, 123456);
}
-O2 -m4 -ml:
mov.l @r4,r4
shlrr4
tst r4,r4
bt .L3
mov.l .L6,r1
mov.l .L7,r5
jmp @r1
nop
.align 1
.L3:
rts
nop
.L7:
Since the pointer is likely to be not nullptr, the function 'foo' is also
likely to be executed. Thus it would make sense to hoist the loads for the
function call to get better scheduling:
mov.l @r4,r4
mov.l .L6,r1
shlrr4
mov.l .L7,r5
tst r4,r4
bt .L3
jmp @r1
nop
.L3:
rts
nop
.L7:
The scheduler doesn't see that because the constant loads remain in the same
basic block that contains the function call. Moreover, the constant pool loads
are expanded by sh_reorg pass after scheduling (which makes sense).
One idea could be to record the expanded constant pool load insns and try to
hoist them after sh_reorg and maybe run the scheduler on the modified insn
sections.
[Bug c++/63392] New: poor error recovery with missing typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63392
Bug ID: 63392
Summary: poor error recovery with missing typename
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
template
class A {
A(int i) : x(i) {}
T::type x;
};
$ g++ test.cc
test.cc:4:3: error: need ‘typename’ before ‘T::type’ because ‘T’ is a dependent
scope
T::type x;
^
A::A(int)
test.cc:3:14: error: class ‘A’ does not have any field named ‘x’
A(int i) : x(i) {}
^
$ clang++ test.cc
test.cc:4:3: error: missing 'typename' prior to dependent type name 'T::type'
T::type x;
^~~
typename
Of course it gets worse in the case of GCC if x is used later in the code.
[Bug c/63393] New: -ffreestanding not work: memset call cause valgrind crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63393 Bug ID: 63393 Summary: -ffreestanding not work: memset call cause valgrind crash Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dushistov at mail dot ru Created attachment 33588 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33588&action=edit problem code On my system linux/x86_64 compilation of valgrind with -O3 -march=native cause crash of valgrind with any executable file. The problem is similar to http://llvm.org/bugs/show_bug.cgi?id=9795, vgPlain_memset call memset, memset call vgPlain_memset and so on. To simplify bug hunting I extract code to separate file, if compile it with: >gcc -O3 -march=native -ffreestanding -static -nodefaultlibs -nostartfiles >-ggdb test_memset.c gcc give error: undefined reference to `memset', but with "-O2" >>gcc -O2 -march=native -ffreestanding -static -nodefaultlibs -nostartfiles >>-ggdb test_memset.c all works fine. gcc 4.8.1
[Bug c/63393] [regression]-ffreestanding not work: memset call cause valgrind crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63393 Evgeniy Dushistov changed: What|Removed |Added Summary|-ffreestanding not work:|[regression]-ffreestanding |memset call cause valgrind |not work: memset call cause |crash |valgrind crash --- Comment #1 from Evgeniy Dushistov --- And I suppose this is regression, because of with gcc 4.7.3 all works, even with "-O3".
[Bug c/63393] [regression]-ffreestanding not work: memset call cause valgrind crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63393 --- Comment #2 from Andrew Pinski --- I think what is happening is hand coded memset is being optimized to memset and then becoming an infinite loop. I thought there was a fix for this already.
[Bug c++/63386] Release version of CB wont compile Bullet (-o2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63386 --- Comment #4 from TechoMan --- gcc version 4.8.1 (GCC). Why CB release - that error was only on release of CB. It changes some variables , such as -O2. Originaly it was rel. CB, but i found what its O2
[Bug c++/63386] Release version of CB wont compile Bullet (-o2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63386 --- Comment #5 from TechoMan --- TDM version - gcc version 4.8.1 (tdm-2)
[Bug c++/19808] miss a warning about uninitialized members in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Manuel López-Ibáñez changed:
What|Removed |Added
Last reconfirmed|2005-05-09 00:52:15 |2014-9-27
CC||mpolacek at gcc dot gnu.org,
||paolo.carlini at oracle dot com
--- Comment #21 from Manuel López-Ibáñez ---
I just got hit by this bug. This can obviously be warned in the FE as clang
does:
test.cc:4:11: warning: field 'j' is uninitialized when used here
[-Wuninitialized]
S() : i(j), j(1) {}
^
simply by marking the members somehow as initialized or not, and when using
them realizing that they are still uninitialized.
Marek, Paolo, Jason? Any idea how to do this?
[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972
--- Comment #20 from Manuel López-Ibáñez ---
(In reply to Jonathan Wakely from comment #14)
> Created attachment 20817 [details]
> better -Wmeminit patch
>
> This version ignores empty classes and checks for a nontrivial default ctor
> instead of layout_pod_type.
>
> This patch doesn't enable the warning unless explicity requested. I realise
> that this warning is about enforcing style ("members should be initialised
> in the mem-initializer-list not in the ctor body") but that's ok because
> it's my preferred style, I just don't want the compiler to enforce other
> people's preferred style ;)
Perhaps a better alternative is to warn only if the uninitialized member is
used in a mem-initializer. Then, when building the constructor call, mark the
uninitialized members somehow as uninitialized for the middle-end, and let the
middle-end handle the cases in the body of the constructor. The first part
would already fix PR19808. The second part will fix this bug with fewer false
positives than the proposed patch.
[Bug c/63394] New: Segmentation Fault with -O3 flag on ARM v61 Processor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63394 Bug ID: 63394 Summary: Segmentation Fault with -O3 flag on ARM v61 Processor Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: Bruce at Daihls dot com Created attachment 33589 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33589&action=edit Preprocessed file layer3.c, from lame gcc: 4.8.2 20131212 (Red Hat 4.8.2-8) system: Raspberry Pi, ARMv6-compatible processor rev 7 (v6l) gcc build options: unknown cmd line: gcc -I. -I.. -I../include -I. -I../libmp3lame -I.. -O3 -c layer3.c output: layer3.c: In function ΓÇÿhip_init_tables_layer3ΓÇÖ: layer3.c:1871:1: internal compiler error: Segmentation fault } ^ This occurs when building lame-3.99.3.tar.gz. The shortened command line that will cause the segmentation fault is above, with the output from the compiler. When the -O3 flag is removed, it compiles without error.
[Bug other/63395] New: Cygwin vs Cygwin64 Floating Point Discrepancy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63395 Bug ID: 63395 Summary: Cygwin vs Cygwin64 Floating Point Discrepancy Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: bernardwidynski at gmail dot com Created attachment 33590 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33590&action=edit C source program that prints the floating point output I transitioned from Cygwin to Cygwin64 and noticed that one of my programs produces differing floating point output. I realize that floating point round off can produce differing outputs on different computer platforms, but Cygwin and Cygwin64 are each running on the same computer and the same floating point hardware is used. I noticed that with identical input values, the output values are different. I printed the floating point number in hexadecimal format and the outputs do not match. See the attached flterr.c program. This program computes the square of a floating-point number. The value of x before and after the square is printed. There are two iterations. On the first iteration Cygwin and Cygwin64 produce the same output: 0x3ff441395eb3a15d. But on the second iteration, differing outputs are printed: For Cygwin, the output is 0x400b56a2041cc08e. For Cygwin64, the output is 0x400b56a2041cc08d. See the attached files flterr.out and flterr64.out. Is there some explanation for this? This seems to be an error. I am running Cygwin and Cygwin64 on the same computer. The information from the system display shows the following: HP Pavilion dv5 Notebook PC Windows 7 Home Premium ServicePack 1 AMD Turion(tm) II P540 Dual-Core Processor 2.40 GHz 4.00 GB (3.74 GB usable) 64-bit Operating System The files gcc-v.out and gcc-v64.out show the gcc output when executing the make command. I've also attached cygcheck.out and cygcheck64.out for each installation. I thought perhaps that this may be a hardware error and I tried this same program on another computer which has the the following processor: AMD Phenom(tm) II N620 Dual-Core Processor 2.80 GHz The same error occurred. Apparently Cygwin and Cygwin64 are handling floating point differently and do not produce identical outputs.
[Bug other/63395] Cygwin vs Cygwin64 Floating Point Discrepancy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63395 --- Comment #1 from bernardwidynski at gmail dot com --- Created attachment 33591 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33591&action=edit Cygwin output file
[Bug other/63395] Cygwin vs Cygwin64 Floating Point Discrepancy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63395 --- Comment #2 from bernardwidynski at gmail dot com --- Created attachment 33592 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33592&action=edit Cygwin64 output file
[Bug other/63395] Cygwin vs Cygwin64 Floating Point Discrepancy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63395 --- Comment #3 from bernardwidynski at gmail dot com --- Created attachment 33593 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33593&action=edit Cywin .i file
[Bug other/63395] Cygwin vs Cygwin64 Floating Point Discrepancy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63395 --- Comment #4 from bernardwidynski at gmail dot com --- Created attachment 33594 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33594&action=edit Cygwin64 .i file
[Bug other/63395] Cygwin vs Cygwin64 Floating Point Discrepancy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63395 --- Comment #5 from bernardwidynski at gmail dot com --- Created attachment 33595 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33595&action=edit makefile
[Bug other/63395] Cygwin vs Cygwin64 Floating Point Discrepancy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63395 --- Comment #6 from bernardwidynski at gmail dot com --- Created attachment 33596 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33596&action=edit Cygwin make output
[Bug other/63395] Cygwin vs Cygwin64 Floating Point Discrepancy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63395 --- Comment #7 from bernardwidynski at gmail dot com --- Created attachment 33597 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33597&action=edit Cygwin64 make output
[Bug other/63395] Cygwin vs Cygwin64 Floating Point Discrepancy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63395 --- Comment #8 from bernardwidynski at gmail dot com --- Created attachment 33598 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33598&action=edit Cygwin cygcheck output
[Bug other/63395] Cygwin vs Cygwin64 Floating Point Discrepancy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63395 --- Comment #9 from bernardwidynski at gmail dot com --- Created attachment 33599 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33599&action=edit Cygwin64 cygcheck output
[Bug c/63393] [regression]-ffreestanding not work: memset call cause valgrind crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63393 --- Comment #3 from Mikael Pettersson --- I don't know if this is supposed to be "fixed" (for all str* and mem* functions one might want to implement oneself), but the standard workaround is to compile with -fno-tree-loop-distribute-patterns. The -ffreestanding does nothing for these annoying transformations.
[Bug c/63394] Segmentation Fault with -O3 flag on ARM v61 Processor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63394 --- Comment #1 from Mikael Pettersson --- (In reply to Bruce Dale from comment #0) > gcc build options: unknown "gcc -v" will tell you that
[Bug other/63395] Cygwin vs Cygwin64 Floating Point Discrepancy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63395 --- Comment #10 from Mikael Pettersson --- I strongly suspect 32-bit Cygwin uses x87 by default, while 64-bit Cygwin probably uses SSE2 by default. These two FP implementations are very different, and it's not at all surprising to see different results from them. Try compiling with -mpc64 on 32-bit Cygwin.
[Bug c/63393] [regression]-ffreestanding not work: memset call cause valgrind crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63393 --- Comment #4 from Evgeniy Dushistov --- (In reply to Mikael Pettersson from comment #3) > I don't know if this is supposed to be "fixed" (for all str* and mem* > functions one might want to implement oneself), but the standard workaround > is to compile with -fno-tree-loop-distribute-patterns. The -ffreestanding > does nothing for these annoying transformations. Not sure why you think so. >From gcc manual: >a "conforming freestanding implementation" is only required to provide certain >library facilities: those in `', `', `', >and `'; since AMD1, also those in `'; since C99, >also those in `' and `'; and since C11, also those >in `' and `' So in "freestanding" case we have no "string.h" and compiler should not insert any function calls from it.
[Bug rtl-optimization/63384] ICE in moveup_expr_chached->sel_bb_head->bb_node with special options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384
--- Comment #1 from Andi Kleen ---
With a newer compiler version
gcc version 5.0.0 20140926 (experimental) (GCC)
the test case doesn't crash anymore, but just runs very very long. I killed it
after 20s. This happens with the following two options:
g++50 matrix.i -o outfile -O2 -fvar-tracking-assignments-toggle
-fselective-scheduling2
The overhead is mostly in the scheduler:
- sched_analyze_insn(deps_desc*, rtx_def*, rtx_insn*) ▒
- 99.39% deps_analyze_insn(deps_desc*, rtx_insn*) ▒
tick_check_p(_expr*, deps_desc*, _fence*) ▒
fill_insns(_fence*, int, _list_node***) ▒
sel_sched_region_2(int) ▒
sel_sched_region(int) ▒
run_selective_scheduling()▒
(anonymous namespace)::pass_sched2::execute(function*)▒
execute_one_pass(opt_pass*) ▒
execute_pass_list_1(opt_pass*)▒
execute_pass_list_1(opt_pass*)▒
execute_pass_list_1(opt_pass*)▒
execute_pass_list(function*, opt_pass*) ▒
cgraph_node::expand() ▒
symbol_table::compile() ▒
symbol_table::finalize_compilation_unit() ▒
cp_write_global_declarations()▒
compile_file()▒
toplev_main(int, char**) ▒
__libc_start_main ▒
+ 0.61% tick_check_p(_expr*, deps_desc*, _fence*)
sched_analyze_insn(deps_desc*, rtx_def*, rtx_insn*)
│
│for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
12.84 │ 748: add$0x1,%r13d
0.07 │add$0x30,%r14
│cmp$0x4d,%r13d
│ ↓ je 7e5
│ if (TEST_HARD_REG_BIT (implicit_reg_pending_uses, i))
0.06 │ 75a: mov%r13d,%eax
12.45 │shr$0x6,%eax
0.17 │mov0x1828100(,%rax,8),%rax
6.06 │bt %r13,%rax
6.21 │ ↑ jae748
│{
[Bug rtl-optimization/63384] selective scheduling on x86 takes very long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384 Andi Kleen changed: What|Removed |Added Attachment #33585|0 |1 is obsolete|| --- Comment #2 from Andi Kleen --- Created attachment 33600 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33600&action=edit Reduced test case for long compile time Oddly the problem goes away when the variable allocation that is not used is commented out.
[Bug tree-optimization/63302] [4.9 Regression] Code with 64-bit long long constants is miscompiled on 32-bit host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302 --- Comment #6 from Zhenqiang Chen --- I double checked the function optimize_range_tests_diff. Overall, I think it does the right thing. X86 and ARM work correctly. The ldil.c.169t.optimized is : x_2 = ival_1(D) & -2147481601; _8 = x_2 + 2147483648; _9 = _8 & -2147483649; _10 = _9 == 0; _6 = (int) _10; return _6; If we can not fix the wide-int issue, I will create a patch to workaround it for 4.9 since I never expected optimize_range_tests_diff can work between a positive value and a negative value.
[Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969 Andi Kleen changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment #3 from Andi Kleen --- I did some experiments. I can reproduce it with trunk for 32bit. The interesting part is that the printed value seems to be uninitialized on the stack and changes on every run. a valgrind run gives =23130== Use of uninitialised value of size 4 ==23130==at 0x40B102B: _itoa_word (in /lib/libc-2.18.so) ==23130==by 0x40B474A: vfprintf (in /lib/libc-2.18.so) ==23130==by 0x40BAFCE: printf (in /lib/libc-2.18.so) ==23130==by 0x40879D2: (below main) (in /lib/libc-2.18.so) ==23130== Uninitialised value was created by a stack allocation ==23130==at 0x80482F4: main (in /home/andi/Downloads/pr61969/t) ==23130== ... more warnings like this ...
[Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #4 from Andi Kleen ---
The problem is when returning a struct from func_52:
const struct S0 func_52 (uint32_t p_53)
{
const struct S0 l_55 = { 4, 40290, 10, 4 };
return l_55;
}
The main code stores the struct value from the stack into the global variable
and eventually prints it
80482f4: 83 ec 38sub$0x38,%esp
80482f7: 0f b6 15 4c da 04 08movzbl 0x804da4c,%edx
80482fe: 8b 1d 20 d1 04 08 mov0x804d120,%ebx
8048304: 0f b6 35 70 da 04 08movzbl 0x804da70,%esi
804830b: e8 b0 0c 00 00 call 8048fc0
8048310: 0f b7 45 d2 movzwl -0x2e(%ebp),%eax
8048314: ba 01 00 00 00 mov$0x1,%edx
8048319: c7 05 20 d1 04 08 48movl $0x804da48,0x804d120
8048320: da 04 08
8048323: 66 a3 5c da 04 08 mov%ax,0x804da5c
But func_52 has been completely optimized away and puts nothing onto the stack:
08048fc0 :
8048fc0: f3 c3 repz ret
8048fc2: 8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi
8048fc9: 8d bc 27 00 00 00 00lea0x0(%edi,%eiz,1),%edi
So the value is random stack garbage.
[Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #5 from Andi Kleen ---
func_52 disappears during/after nrv:
in 173t.nrv:
;; Function func_52 (func_52, funcdef_no=86, decl_uid=2858, cgraph_uid=54,
symbol_order=1152)
func_52 (uint32_t p_53)
{
extern const struct S0 l_55 = {.f0=4, .f1=40290, .f2=10, .f3=4} [value-expr:
];
:
return ;
}
in 174t.optimized
;; Function func_52 (func_52, funcdef_no=86, decl_uid=2858, cgraph_uid=54,
symbol_order=1152)
func_52 (uint32_t p_53)
{
:
return ;
}
