[Bug middle-end/55176] [4.8 Regression] Out of memory during Chromium build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55176
--- Comment #1 from Markus Trippelsdorf
2012-11-02 07:18:00 UTC ---
Reduced:
class Sandbox
{
void sandbox_exit ();
struct A
{
int write ();
};
void die ();
};
int a;
void
Sandbox::sandbox_exit ()
{
A b;
while (b.write () && 1)
if (a)
die ();
for (;;);
}
Buying Intent
Attn: This is Ms Vanessa Lawrence from Falkland Inc. Australia, we have got your company info from our client Alibaba Trade and we are interested in your product. we will like to know your production/shipping time frame. Ensure to make a cc copy of your response to Email- falklandgro...@hotmail.co.uk Best regards, Ms Vanessa Lawrence Falkland Inc. Level 5-2 Bulletin Place, Sydney, Australia Tel: 61 (2) 9151 4812 Tel: 1300 456 239 Fax: (02) 8088 6066
[Bug target/55147] [4.8 Regression] x86: wrong code for 64-bit load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55147 --- Comment #7 from Jakub Jelinek 2012-11-02 08:03:05 UTC --- Author: jakub Date: Fri Nov 2 08:03:02 2012 New Revision: 193090 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193090 Log: PR target/55147 * config/i386/i386.md (bswapdi2): Limit to TARGET_64BIT. (*bswapdi2_doubleword): Removed. * gcc.target/i386/pr55147.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr55147.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug middle-end/55176] [4.8 Regression] Out of memory during Chromium build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55176 --- Comment #2 from Markus Trippelsdorf 2012-11-02 08:09:51 UTC --- This only happens when gcc was lto/profiledbootstraped. Looks like it gets miscompiled in this case.
[Bug c++/55159] pythy constexpr auto lambda pointer has no initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55159 --- Comment #4 from Daniel Krügler 2012-11-02 08:10:14 UTC --- (In reply to comment #3) > But it seems that gcc doesn't ignore the const (in "const T*" or "const > auto*") > for functions here, which seems to be the root of the second problem (This is > *not* attempting to form a function with cv-qualifier-seq). I withdraw my interpretation that it is *clear* here that during template argument deduction we can successfully match a "const T" with a function type. This looks like a core language problem to me and I'll notify CWG in regard to this.
[Bug regression/55167] [4.8 Regression]: g++.dg/other/vector-compare.C, ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55167 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Marc Glisse 2012-11-02 08:30:11 UTC --- Thanks. The failure also disappeared between: http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00087.html and: http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00095.html so let's mark this bug as fixed. PR55001 remains open because the patch makes the compiler produce sub-optimal code (but correct at least).
[Bug middle-end/55176] [4.8 Regression] Out of memory during Chromium build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55176 --- Comment #3 from Markus Trippelsdorf 2012-11-02 08:37:08 UTC --- (In reply to comment #2) > This only happens when gcc was lto/profiledbootstraped. > Looks like it gets miscompiled in this case. Turned out that "--enable-checking=release" is enough to trigger this bug. % ~/gcc/configure --disable-bootstrap --disable-werror --disable-multilib --enable-languages=c,c++ --enable-checking=release % make
[Bug middle-end/55176] [4.8 Regression] Out of memory during Chromium build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55176 Markus Trippelsdorf changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||steven at gcc dot gnu.org --- Comment #4 from Markus Trippelsdorf 2012-11-02 08:52:39 UTC --- Started with r193047: commit 9ccd9ece034984af0e6a775fdfb51b98a7029a84 Author: steven Date: Wed Oct 31 21:37:10 2012 + gcc/ PR tree-optimization/55018
[Bug c++/55159] pythy constexpr auto lambda pointer has no initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55159
--- Comment #5 from Daniel Krügler
2012-11-02 08:57:33 UTC ---
I need to insert another correction. My attempt to simplify the reporters bug
failed because I was mislead by the report description that "visual studio 2012
work fine" interpreting this to mean the Microsoft Visual Studio 2012 compiler.
But that one does not understand 'constexpr' therefore my reduction to 'const'
was not equivalent.
(In reply to comment #1)
> I really think that Pythy should fix this implementation, because it is not
> supported by the C++11 standard. Any compiler accepting that is defect.
This statement still holds. The original code is not conforming.
The following presents a conforming code that reproduces the problem:
template
struct min_t
{
static bool less(T0 x, T1 y) { return x < y ? x : y; }
constexpr static auto* f = &less; // #5
};
min_t mi; // #8
"8| required from here|
5|error: declaration of 'constexpr auto* const min_t::f' has no
initializer"
Please ignore the part about const T in template deduction. This is a different
issue and not related to this one.
[Bug tree-optimization/55177] New: Missed optimisation: bswap, mask with constant, bswap back again.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177
Bug #: 55177
Summary: Missed optimisation: bswap, mask with constant, bswap
back again.
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dw...@infradead.org
extern int x;
void foo(void)
{
int a = __builtin_bswap32(x);
a &= 0x5a5b5c5d;
x = __builtin_bswap32(a);
}
With GCC 4.7.2 (x86_64 Fedora) this compiles to:
foo:
.LFB0:
.cfi_startproc
movlx(%rip), %eax
bswap%eax
andl$-1515936861, %eax
bswap%eax
movl%eax, x(%rip)
ret
.cfi_endproc
Surely the actual swap should be optimised out, and the 0x5a5b5c5d constant
mask should be swapped instead so we just load, mask with 0x5d5c5b5a and store
without any runtime swapping?
(See also PR42586 which may be related)
[Bug bootstrap/55175] i386/sfp-exceptions.c:52:7: error: impossible constraint in 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175 --- Comment #1 from Uros Bizjak 2012-11-02 10:01:44 UTC --- Created attachment 28596 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28596 Proposed patch Patch that disables relevant parts of soft-fp library
[Bug bootstrap/55175] i386/sfp-exceptions.c:52:7: error: impossible constraint in 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175 --- Comment #2 from Uros Bizjak 2012-11-02 10:05:24 UTC --- Can you please try to build with attached (untested) patch? The patch disables the part that handles exceptions and where rounding mode is set. We need either x87 or SSE control register for this functionality.
[Bug tree-optimization/55162] Loop ivopts cuts off top bits of loop counter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55162
Oleg Endo changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment #3 from Oleg Endo 2012-11-02 10:07:26
UTC ---
(In reply to comment #2)
> >For example, passing a virtual address 0x1000 and c = 0x8000 to the
> function should actually run over the address range 0x1000 .. 0x80001000,
>
>
> No it runs over the address range 0x1000 .. -1 and more as 0x8000 * 4
> wraps/overflows. If x was char* then I would say there is a bug but this is
> int* which has a size of 4.
Ugh, sorry for the mess up. Of course you're right.
I guess that the pointer wrap-around would fall into "undefined behavior"
category. If so, then the loop counter adjustment could be left out entirely,
couldn't it?
My point is that the loop counter adjustment can become quite bloaty on SH:
struct X
{
int a, b, c, d, e;
};
int test (X* x, unsigned int c)
{
int s = 0;
unsigned int i;
for (i = 0; i < c; ++i)
s += x[i].b;
return s;
}
results in:
tst r5,r5
bt/s.L4
mov r5,r1
shll2 r1
add r5,r1
mov.l .L9,r2
shll2 r1
add #-20,r1
shlr2 r1
mul.l r2,r1
mov.l .L10,r2
add #4,r4
mov #0,r0
sts macl,r1
and r2,r1
add #1,r1
.L3:
mov.l @r4,r2
dt r1
add #20,r4
bf/s.L3
add r2,r0
rts
nop
.L4:
rts
mov #0,r0
.L11:
.align 2
.L9:
.long 214748365
.L10:
.long 1073741823
[Bug libstdc++/55169] std::discrete_distribution::operator(generator&) makes unnecessary copy of parameter vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55169 --- Comment #4 from paolo at gcc dot gnu.org 2012-11-02 10:45:40 UTC --- Author: paolo Date: Fri Nov 2 10:45:25 2012 New Revision: 193092 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193092 Log: 2012-11-02 Paolo Carlini PR libstdc++/55169 * include/bits/random.h: Remove all uses of param(). (chi_squared_distribution<>::__generate_impl(_ForwardIterator, _ForwardIterator, _UniformRandomNumberGenerator&): Declare * include/bits/random.tcc: ... define. * include/ext/random: Remove all uses of param(). Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/random.h trunk/libstdc++-v3/include/bits/random.tcc trunk/libstdc++-v3/include/ext/random
[Bug tree-optimization/55177] Missed optimisation: bswap, mask with constant, bswap back again.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177
--- Comment #1 from David Woodhouse 2012-11-02
10:45:52 UTC ---
We have a similar issue with:
extern void func(void);
int baz(void)
{
if (__builtin_bswap32(x) & 0x8)
func();
}
baz:
.LFB1:
.cfi_startproc
movlx(%rip), %eax
bswap%eax
testl$524288, %eax
jne.L12
rep
ret
…
Again there's no need for a bswap followed by testing with a constant.
[Bug fortran/55174] [4.6 Regression] Segmentation fault with bad array reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55174 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-02 CC||janus at gcc dot gnu.org Summary|internal compiler error:|[4.6 Regression] |Segmentation fault with bad |Segmentation fault with bad |array reference |array reference Ever Confirmed|0 |1 --- Comment #2 from janus at gcc dot gnu.org 2012-11-02 10:54:50 UTC --- (In reply to comment #1) > It looks like it has been fixed on trunk (aka 4.8.0). For me it also works with: gcc version 4.7.2 20120920 [gcc-4_7-branch revision 191568] (SUSE Linux) (while it fails with 4.7.0 and 4.6.0). Note: The 4.6 branch is still maintained, so we should consider fixing it there.
[Bug rtl-optimization/55177] missed optimizations with __builtin_bswap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-02 CC||ebotcazou at gcc dot ||gnu.org Component|tree-optimization |rtl-optimization Summary|Missed optimisation: bswap, |missed optimizations with |mask with constant, bswap |__builtin_bswap |back again. | Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #2 from Eric Botcazou 2012-11-02 10:56:17 UTC --- If you don't need to swap, then do not use __builtin_bswap! The first example is really dumb. That being said, the second example has some merit and we should do something to optimize it at the RTL level.
[Bug c++/55178] New: lambda cannot be found at linkage stage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55178
Bug #: 55178
Summary: lambda cannot be found at linkage stage
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: icegood1...@gmail.com
#include
class intermed
{
public:
virtual void Proceed(int cb(int))
{
cb(123);
};
};
class smain
{
public:
smain(intermed *Af_intermed)
{
f_intermed=Af_intermed;
}
virtual void run()
{
f_intermed->Proceed([](int num){ std::cerr
[Bug fortran/55172] [4.7/4.8 Regression] [OOP] ICE on invalid: gfc_variable_attr(): Bad array reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55172
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-11-02
Summary|[OOP] ICE on invalid: |[4.7/4.8 Regression] [OOP]
|gfc_variable_attr(): Bad|ICE on invalid:
|array reference |gfc_variable_attr(): Bad
||array reference
Ever Confirmed|0 |1
--- Comment #1 from janus at gcc dot gnu.org 2012-11-02 11:07:33 UTC ---
(In reply to comment #0)
> (Reported by Janus at http://gcc.gnu.org/ml/fortran/2012-11/msg5.html):
> With 4.7 the ICE also occurs, but only after the correct error message:
>
> select type (component => self%cb(i))
>1
> Error: Symbol 'i' at (1) has no IMPLICIT type
Yes, therefore it's a regression in 4.7 (ICE after error) and 4.8 (ICE only).
4.6 of course rejects it ('cleanly') with:
class(ncb), allocatable, dimension(:) :: cb
1
Fatal Error: Polymorphic array at (1) not yet supported
(Side note: The 'fatal' seems a bit strong here, but that was probably used to
suppress further error messages.)
[Bug c++/55178] lambda cannot be found at linkage stage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55178 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Paolo Carlini 2012-11-02 11:10:49 UTC --- It's the same, it's the same. In any case, when PR55015 will be fixed, we'll add this testcase too. *** This bug has been marked as a duplicate of bug 55015 ***
[Bug c++/55015] Lambda functions not found at link time when declared in an inline function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55015 Paolo Carlini changed: What|Removed |Added CC||icegood1980 at gmail dot ||com --- Comment #4 from Paolo Carlini 2012-11-02 11:10:49 UTC --- *** Bug 55178 has been marked as a duplicate of this bug. ***
[Bug c++/55171] incorrect virtual thunk on mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55171 Paolo Carlini changed: What|Removed |Added CC||cgf at gcc dot gnu.org, ||dave.korn.cygwin at gmail ||dot com, ktietz at gcc dot ||gnu.org --- Comment #1 from Paolo Carlini 2012-11-02 11:13:16 UTC --- Thus, is this mingw specific? Should be target instead?
[Bug c++/55159] pythy constexpr auto lambda pointer has no initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55159 --- Comment #6 from Paolo Carlini 2012-11-02 11:14:54 UTC --- Thus, Daniel, is this invalid?
[Bug libstdc++/55169] std::discrete_distribution::operator(generator&) makes unnecessary copy of parameter vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55169 --- Comment #5 from paolo at gcc dot gnu.org 2012-11-02 11:18:22 UTC --- Author: paolo Date: Fri Nov 2 11:18:13 2012 New Revision: 193093 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193093 Log: 2012-11-02 Paolo Carlini PR libstdc++/55169 * include/bits/random.h: Remove all uses of param(). Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/bits/random.h
[Bug libstdc++/55169] std::discrete_distribution::operator(generator&) makes unnecessary copy of parameter vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55169 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.3 --- Comment #6 from Paolo Carlini 2012-11-02 11:19:37 UTC --- Fixed mainline and 4.7.3.
[Bug c++/55159] pythy constexpr auto lambda pointer has no initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55159
--- Comment #7 from Daniel Krügler
2012-11-02 11:39:07 UTC ---
(In reply to comment #6)
> Thus, Daniel, is this invalid?
I think this part of the problem is indeed valid:
template
struct min_t
{
static bool less(T0 x, T1 y) { return x < y ? x : y; }
constexpr static auto* f = &less; // #5
};
min_t mi; // #8
"8| required from here|
5|error: declaration of 'constexpr auto* const min_t::f' has no
initializer"
(With or without & in front of less)
According to my understanding this should be accepted.
[Bug fortran/55179] New: Optionally warn when use-associating a module with no (public) symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55179 Bug #: 55179 Summary: Optionally warn when use-associating a module with no (public) symbols Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: tkoe...@gcc.gnu.org Compiling the following program by Open64/PathScale/Crayftn gives by default the warning: Module "M" has no public objects declared in the module, therefore nothing can be use associated from the module. I think it makes sense to have a similar warning, though I am not sure that one should warn by default. module m end module m use m end
[Bug middle-end/53697] [4.7/4.8 Regression] ICE: in get_expr_operands, at tree-ssa-operands.c:990 with lambda function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53697 Markus Trippelsdorf changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #2 from Markus Trippelsdorf 2012-11-02 11:43:48 UTC --- Dup of Bug 53137.
[Bug c++/54431] [C++11] g++ crashes when compiling the following file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54431 --- Comment #6 from Markus Trippelsdorf 2012-11-02 11:43:50 UTC --- Dup of Bug 53697 and Bug 53137.
[Bug c++/55159] pythy constexpr auto lambda pointer has no initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55159 Paolo Carlini changed: What|Removed |Added Blocks||55004 --- Comment #8 from Paolo Carlini 2012-11-02 11:48:39 UTC --- Ah, Ok, I was a bit lost ;) Thanks. However, my (very rough) feeling is that we have got already quite a bit in Bugzilla in the area, constexpr, auto, pointers...
[Bug c++/53137] [4.7/4.8 Regression] g++ segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53137 Paolo Carlini changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #11 from Paolo Carlini 2012-11-02 11:51:00 UTC --- *** Bug 53697 has been marked as a duplicate of this bug. ***
[Bug middle-end/53697] [4.7/4.8 Regression] ICE: in get_expr_operands, at tree-ssa-operands.c:990 with lambda function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53697 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Paolo Carlini 2012-11-02 11:51:00 UTC --- Dup. *** This bug has been marked as a duplicate of bug 53137 ***
[Bug c++/54431] [C++11] g++ crashes when compiling the following file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54431 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #7 from Paolo Carlini 2012-11-02 11:52:07 UTC --- Dup. *** This bug has been marked as a duplicate of bug 53137 ***
[Bug c++/53137] [4.7/4.8 Regression] g++ segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53137 Paolo Carlini changed: What|Removed |Added CC||m101010a at gmail dot com --- Comment #12 from Paolo Carlini 2012-11-02 11:52:07 UTC --- *** Bug 54431 has been marked as a duplicate of this bug. ***
[Bug fortran/55172] [4.7/4.8 Regression] [OOP] ICE on invalid: gfc_variable_attr(): Bad array reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55172 janus at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #2 from janus at gcc dot gnu.org 2012-11-02 12:09:50 UTC --- I suspect the 4.8-problem of having only the ICE without a prior error message might be due to this commit: http://gcc.gnu.org/viewcvs?view=revision&revision=187192 I think the function 'copy_ts_from_selector_to_associate' comes too early (namely during parsing). It tries to resolve the target expr, which should rather wait until resolution stage!?!
[Bug bootstrap/55175] i386/sfp-exceptions.c:52:7: error: impossible constraint in 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175 Joel Sherrill changed: What|Removed |Added CC||joel at gcc dot gnu.org --- Comment #3 from Joel Sherrill 2012-11-02 13:29:45 UTC --- (In reply to comment #2) > Can you please try to build with attached (untested) patch? > > The patch disables the part that handles exceptions and where rounding mode is > set. We need either x87 or SSE control register for this functionality. The patch lets the tool build. I successfully built i386-rtems4.11 using binutils and newlib cvs heads. Please commit and close this. Thanks for fixing this. i386 soft float doesn't attract much attention but some people still care. :)
[Bug bootstrap/55175] i386/sfp-exceptions.c:52:7: error: impossible constraint in 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175 --- Comment #4 from uros at gcc dot gnu.org 2012-11-02 14:09:09 UTC --- Author: uros Date: Fri Nov 2 14:09:02 2012 New Revision: 193095 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193095 Log: PR target/55175 * config/i386/sfp-exceptions.c: Guard with _SOFT_FLOAT. * config/i386/sfp-machine.h: Guard exception handling code with _SOFT_FLOAT. * config/i386/32/sfp-machine.h: Guard rounding handling code with _SOFT_FLOAT. * config/i386/64/sfp-machine.h: Ditto. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/i386/32/sfp-machine.h trunk/libgcc/config/i386/64/sfp-machine.h trunk/libgcc/config/i386/sfp-exceptions.c trunk/libgcc/config/i386/sfp-machine.h
[Bug target/55175] i386/sfp-exceptions.c:52:7: error: impossible constraint in 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175 Uros Bizjak changed: What|Removed |Added Target||x86 Status|UNCONFIRMED |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-11/msg00190.htm ||l Component|bootstrap |target Resolution||FIXED AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | Target Milestone|--- |4.8.0 --- Comment #5 from Uros Bizjak 2012-11-02 14:26:09 UTC --- Fixed.
[Bug rtl-optimization/50339] suboptimal register allocation for abs(__int128_t)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50339 --- Comment #2 from Marc Glisse 2012-11-02 14:33:27 UTC --- It looks even worse in 4.8: movq%rdi, %r9 movq%rsi, %rdi movq%rsi, %r10 sarq$63, %rdi movq%rdi, %rcx xorq%r9, %rcx movq%rcx, %rax movq%r10, %rcx xorq%rdi, %rcx subq%rdi, %rax movq%rcx, %rdx sbbq%rdi, %rdx ret
[Bug middle-end/55130] [4.8 Regression] ICE in insn_rhs_dead_pseudo_p, at lra-constraints.c:3224
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55130 --- Comment #2 from Vladimir Makarov 2012-11-02 14:44:23 UTC --- Author: vmakarov Date: Fri Nov 2 14:44:12 2012 New Revision: 193096 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193096 Log: 2012-11-02 Vladimir Makarov PR middle-end/55130 * lra-constraints.c (debug_loc_equivalence_change_p): Rename to loc_equivalence_change_p. (lra_constraints): Check equiv_insn_bitmap for debug insn. Call loc_equivalence_change_p for non-transformed insn. 2012-11-02 Vladimir Makarov PR middle-end/55150 * gcc.target/i386/pr55130.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr55130.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/55150] Crash in copy_rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55150 --- Comment #6 from Vladimir Makarov 2012-11-02 14:44:24 UTC --- Author: vmakarov Date: Fri Nov 2 14:44:12 2012 New Revision: 193096 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193096 Log: 2012-11-02 Vladimir Makarov PR middle-end/55130 * lra-constraints.c (debug_loc_equivalence_change_p): Rename to loc_equivalence_change_p. (lra_constraints): Check equiv_insn_bitmap for debug insn. Call loc_equivalence_change_p for non-transformed insn. 2012-11-02 Vladimir Makarov PR middle-end/55150 * gcc.target/i386/pr55130.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr55130.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug target/54791] AIX-only: Constructors are not called in main program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 --- Comment #3 from Adi 2012-11-02 14:49:03 UTC --- After more investigation I saw that I managed to get the constructors called by removing the "inline" keyword from just one constructor of a class that resides in my master header. >From my -Wl,-debug linker options I see that this particular constructor name is used to generate the dynamic initialization in almost every object file. See debug.txt attached for more details. Look for "_GLOBAL__I_65535_0__ZN5TraceD2Ev". Do you know why would that be? Is this a bug ? Do you know why on Linux with the same compiler version and same code is not happening? I have around 1000 member functions that are declared "inline" across various classes. Do you know if there are any know issues with inline and constructors? Any compiler options I should be aware of? I am not using any optimization (yet .. I am planning to). Now after I did this I am still having some other problems. Some object seemed are not initialized properly. I am still suspecting the other inlines might be the culprit. Any ideas/suggestions would be appreciated. From: dje at gcc dot gnu.org To: adivilce...@yahoo.com Sent: Wednesday, October 3, 2012 4:46 PM Subject: [Bug target/54791] AIX-only: Constructors are not called in main program. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 --- Comment #2 from David Edelsohn 2012-10-03 13:46:44 UTC --- Constructors are working because they work without your big header. I would try using divide and conquer techniques to reduce the big header and find out what is interfering with constructors. It gives all appearances that it is due to the user code. Static constructors and destructors are run by functions generated at link time. A programmer wrapper around AIX ld called "collect2" scans object files and libraries for constructors and generates functions that are invoked by AIX linker -binitfini feature. You can add -Wl,-debug to the link line to see the way the AIX linker is invoked and see the helper function. Is something in the big header changing the mangled names of constructors and destructors so that they do not use the standard pattern? Or inserting some illegal character like dollar sign ($)?
[Bug target/54791] AIX-only: Constructors are not called in main program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 --- Comment #4 from Adi 2012-11-02 14:51:50 UTC --- my attachment as text did not work so I have done it via word doc. From: "adivilce...@yahoo.com" To: dje at gcc dot gnu.org Sent: Friday, November 2, 2012 4:48 PM Subject: Re: [Bug target/54791] AIX-only: Constructors are not called in main program. After more investigation I saw that I managed to get the constructors called by removing the "inline" keyword from just one constructor of a class that resides in my master header. >From my -Wl,-debug linker options I see that this particular constructor name is used to generate the dynamic initialization in almost every object file. See debug.txt attached for more details. Look for "_GLOBAL__I_65535_0__ZN5TraceD2Ev". Do you know why would that be? Is this a bug ? Do you know why on Linux with the same compiler version and same code is not happening? I have around 1000 member functions that are declared "inline" across various classes. Do you know if there are any know issues with inline and constructors? Any compiler options I should be aware of? I am not using any optimization (yet .. I am planning to). Now after I did this I am still having some other problems. Some object seemed are not initialized properly. I am still suspecting the other inlines might be the culprit. Any ideas/suggestions would be appreciated. From: dje at gcc dot gnu.org To: adivilce...@yahoo.com Sent: Wednesday, October 3, 2012 4:46 PM Subject: [Bug target/54791] AIX-only: Constructors are not called in main program. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 --- Comment #2 from David Edelsohn 2012-10-03 13:46:44 UTC --- Constructors are working because they work without your big header. I would try using divide and conquer techniques to reduce the big header and find out what is interfering with constructors. It gives all appearances that it is due to the user code. Static constructors and destructors are run by functions generated at link time. A programmer wrapper around AIX ld called "collect2" scans object files and libraries for constructors and generates functions that are invoked by AIX linker -binitfini feature. You can add -Wl,-debug to the link line to see the way the AIX linker is invoked and see the helper function. Is something in the big header changing the mangled names of constructors and destructors so that they do not use the standard pattern? Or inserting some illegal character like dollar sign ($)?
[Bug tree-optimization/55180] New: Missed optimization abs(-x) -> abs(x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55180
Bug #: 55180
Summary: Missed optimization abs(-x) -> abs(x)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
double f(double x){
double y=-x;
return __builtin_fabs(y);
}
The negation doesn't disappear, even at -Ofast, I still see both "xor" and
"and" in the asm. (I don't think this optimization requires any unsafe math
option, but I am not completely sure about the trapping behavior)
Note that if I write __builtin_fabs(-x), the negation is removed before it has
a chance to appear in a dump.
[Bug middle-end/55176] [4.8 Regression] Out of memory during Chromium build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55176 --- Comment #5 from Markus Trippelsdorf 2012-11-02 15:13:48 UTC --- Gcc is spinning in compute_antic (tree-ssa-pre.c:2507) calling bitmap_set_new() until OOM: #0 _int_malloc (av=0x7794d600 , bytes=2408) at malloc.c:3694 #1 0x77661700 in __GI___libc_malloc (bytes=2408) at malloc.c:2859 #2 0x00cbc938 in xmalloc (size=) at /home/markus/gcc/libiberty/xmalloc.c:147 #3 0x0060b561 in pool_alloc (pool=0x11a51e0) at /home/markus/gcc/gcc/alloc-pool.c:282 #4 0x00936c00 in bitmap_set_new () at /home/markus/gcc/gcc/tree-ssa-pre.c:606 #5 0x0094065c in compute_antic_aux (block_has_abnormal_pred_edge=, block=0x773d4d00) at /home/markus/gcc/gcc/tree-ssa-pre.c:2161 #6 compute_antic () at /home/markus/gcc/gcc/tree-ssa-pre.c:2507 #7 do_pre () at /home/markus/gcc/gcc/tree-ssa-pre.c:4709
[Bug tree-optimization/55180] Missed optimization abs(-x) -> abs(x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55180 Andrew Pinski changed: What|Removed |Added Depends on||16107 --- Comment #1 from Andrew Pinski 2012-11-02 15:43:29 UTC --- Related to or a dup of bug 16107.
[Bug other/55181] New: [4.7/4.8 Regression] Expensive shift loop where a bit-testing instruction could be used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55181
Bug #: 55181
Summary: [4.7/4.8 Regression] Expensive shift loop where a
bit-testing instruction could be used
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
Target: avr
The following C code:
unsigned char lfsr (unsigned long number)
{
unsigned char b = 0;
if (number & (1L << 29)) b++;
if (number & (1L << 13)) b++;
return b;
}
compiles to a right shift 29 bits of number which is very expensive because AVR
has no barrel shifter. Instead, a bit-testing instruction could be used which
takes just a few cycles and not more than 100 like with the right shift.
4.6.2 uses a bit testing instruction.
== Command line ==
[Bug other/55181] [4.7/4.8 Regression] Expensive shift loop where a bit-testing instruction could be used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55181 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-02 Ever Confirmed|0 |1 --- Comment #1 from Georg-Johann Lay 2012-11-02 16:10:05 UTC --- == Command Line == $ avr-gcc -S foo.c -Os -dp with avr-gcc GCC: (GNU) 4.8.0 20120915 (experimental) Set component to "other", dunno if avr backend is the culprit or the middle-end disregarding costs.
[Bug other/55181] [4.7/4.8 Regression] Expensive shift loop where a bit-testing instruction could be used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55181 --- Comment #2 from Georg-Johann Lay 2012-11-02 16:11:40 UTC --- Created attachment 28597 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28597 foo.c Test case
[Bug tree-optimization/16107] missed optimization with some math function builtins
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16107 Marc Glisse changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #5 from Marc Glisse 2012-11-02 16:11:43 UTC --- *** Bug 55180 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/55180] Missed optimization abs(-x) -> abs(x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55180 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Marc Glisse 2012-11-02 16:11:43 UTC --- Thanks, I had missed that one. ABS_EXPR is a bit special in that it has its own tree code, instead of appearing as a call to a builtin function, but the issue is the same indeed, the optimization is there but can never be applied. *** This bug has been marked as a duplicate of bug 16107 ***
[Bug other/55181] [4.7/4.8 Regression] Expensive shift loop where a bit-testing instruction could be used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55181 --- Comment #3 from Georg-Johann Lay 2012-11-02 16:13:18 UTC --- Created attachment 28598 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28598 foo.s (from 4.8) Assembler output that shows the expensive shift loop in insn 44.
[Bug other/55181] [4.7/4.8 Regression] Expensive shift loop where a bit-testing instruction could be used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55181 --- Comment #4 from Georg-Johann Lay 2012-11-02 16:15:16 UTC --- Created attachment 28599 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28599 foo.s (4.6.2, good) Assembler output from 4.6.2 that generates a bit test instruction.
[Bug tree-optimization/55079] [4.8 regression] false positive -Warray-bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55079 --- Comment #4 from Jan Hubicka 2012-11-02 16:35:01 UTC --- Author: hubicka Date: Fri Nov 2 16:34:52 2012 New Revision: 193098 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193098 Log: PR middle-end/55079 * tree-ssa-loop-niter.c (number_of_iterations_exit): Update MAX field if NITER was folded to contant. (record_estimate): Sanity check. * tree-ssa-loop-ivcanon.c (remove_exits_and_undefined_stmts): New function. (remove_redundant_iv_test): New function. (loops_to_unloop, loops_to_unloop_nunroll): New static vars. (unloop_loops): Break out from ... (try_unroll_loop_completely): ... here; Pass in MAXITER; use remove_exits_and_undefined_stmts; do not unloop. (canonicalize_loop_induction_variables): Compute MAXITER; use remove_redundant_iv_test; remove loop_close_ssa_invalidated and irred_invalidated arguments. (canonicalize_induction_variables): Compute fresh bound estimates; unloop; walk from innermost. (tree_unroll_loops_completely): Likewise. * gcc.dg/tree-ssa/cunroll-10.c: New testcase. * gcc.dg/tree-ssa/cunroll-9.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/cunroll-10.c trunk/gcc/testsuite/gcc.dg/tree-ssa/cunroll-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ivcanon.c trunk/gcc/tree-ssa-loop-niter.c
[Bug tree-optimization/55079] [4.8 regression] false positive -Warray-bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55079 --- Comment #5 from Jan Hubicka 2012-11-02 16:46:54 UTC --- The patch cures a lot of false positives seen at -O3 bootstrap. The testcase here is not cured, I am looking into it.
[Bug rtl-optimization/55177] missed optimizations with __builtin_bswap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177 --- Comment #3 from David Woodhouse 2012-11-02 17:05:03 UTC --- The first example isn't *that* dumb, as a cut-down test case of real code which may look more complex in reality. If the real code really *is* as simple as my test case, you're right that perhaps we *could* optimise it ourselves by eschewing the normal accessor macros for explicit-endian values, and manually byteswapping the constant instead. But really, we shouldn't *have* to. The compiler can see what's happening, and it can deal with it a whole lot better than we can, especially when it comes to loads and stores. Your argument applies just as well to the second test case. I could just byteswap the constant instead of the variable. But still I shouldn't have to.
[Bug rtl-optimization/55177] missed optimizations with __builtin_bswap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
--- Comment #4 from Eric Botcazou 2012-11-02
17:45:54 UTC ---
> The first example isn't *that* dumb, as a cut-down test case of real code
> which may look more complex in reality.
OK, and I can indeed think of some usage patterns in real life.
> If the real code really *is* as simple as my test case, you're right that
> perhaps we *could* optimise it ourselves by eschewing the normal accessor
> macros for explicit-endian values, and manually byteswapping the constant
> instead.
>
> But really, we shouldn't *have* to. The compiler can see what's happening, and
> it can deal with it a whole lot better than we can, especially when it comes
> to loads and stores.
Another category would be comparisons then:
int compare1 (int x)
{
return __builtin_bswap32 (x) == 0xdeadbeef;
}
int compare2 (int x, int y)
{
return __builtin_bswap32 (x) == __builtin_bswap32 (y);
}
Will have a look shortly.
[Bug tree-optimization/55079] [4.8 regression] false positive -Warray-bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55079
--- Comment #6 from Jan Hubicka 2012-11-02
18:44:37 UTC ---
Hmm, it seems to be due to off-by-one bug in my patch
Index: tree-ssa-loop-ivcanon.c
===
--- tree-ssa-loop-ivcanon.c (revision 193098)
+++ tree-ssa-loop-ivcanon.c (working copy)
@@ -405,11 +405,11 @@ remove_exits_and_undefined_stmts (struct
into unreachable (or trap when debugging experience is supposed
to be good). */
if (!elt->is_exit
- && elt->bound.ult (double_int::from_uhwi (npeeled)))
+ && elt->bound.ule (double_int::from_uhwi (npeeled)))
{
gimple_stmt_iterator gsi = gsi_for_stmt (elt->stmt);
gimple stmt = gimple_build_call
(builtin_decl_implicit (BUILT_IN_UNREACHABLE), 0);
gimple_set_location (stmt, gimple_location (elt->stmt));
gsi_insert_before (&gsi, stmt, GSI_NEW_STMT);
I however introduced it because w/o it we get bootstrap miscompare. Looks like
I will need to debug it after all :(
[Bug c++/55183] New: GCC 4.8 constexpr is too permissive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55183 Bug #: 55183 Summary: GCC 4.8 constexpr is too permissive Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: steve...@gmail.com In the second patch set here uploaded by my colleague: https://codereview.qt-project.org/#change,33290 GCC 4.8 was too permissive in its handling of constexpr compared to GCC 4.6 and clang. I don't know how to create a minimal testcase for this issue, but wanted to file it in case it can be fixed before 4.8 is released.
[Bug c++/55183] GCC 4.8 constexpr is too permissive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55183 --- Comment #1 from Andrew Pinski 2012-11-02 19:36:36 UTC --- 4.6 does not really do constexpr. Anyways I think this is a dup of bug 55039 as referenced by the following C++ Defect report: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1384
[Bug rtl-optimization/55177] missed optimizations with __builtin_bswap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177 --- Comment #5 from David Woodhouse 2012-11-02 19:41:28 UTC --- Indeed. Bear in mind that sometimes we *hide* the actual variable (by prefixing its name or putting it in a small struct of its own), just to *force* people to use the appropriate byte-swapping accessor functions/macros. And with good reason, because people will often forget to handle the endianness issues otherwise. So what you describe as 'really dumb' is actually something that we *force* people to do. We'd be much worse off without it. Of course, if we could just mark the variable with __attribute__((bigendian)) then perhaps it would all JustWork™ ... but that's a separate discussion ☹
[Bug c++/55171] incorrect virtual thunk on mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55171 --- Comment #2 from Adam Mitz 2012-11-02 19:51:26 UTC --- (In reply to comment #1) > Thus, is this mingw specific? I can only get it to fail on mingw. > Should be target instead? Sorry, I don't know what this means.
[Bug target/55171] incorrect virtual thunk on mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55171 Paolo Carlini changed: What|Removed |Added Component|c++ |target --- Comment #3 from Paolo Carlini 2012-11-02 20:13:21 UTC --- Means this, easy ;)
[Bug c++/55183] GCC 4.8 constexpr is too permissive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55183 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Paolo Carlini 2012-11-02 20:14:42 UTC --- This isn't a PR.
[Bug tree-optimization/54985] [4.7 Regression] dom optimization erroneous remove conditional goto.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54985 --- Comment #15 from Jeffrey A. Law 2012-11-02 20:19:23 UTC --- Author: law Date: Fri Nov 2 20:19:16 2012 New Revision: 193108 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193108 Log: PR tree-optimization/54985 * tree-ssa-threadedge.c (cond_arg_set_in_bb): New function extracted from thread_across_edge. (thread_across_edge): Use it in all cases where we might thread across a back edge. * gcc.c-torture/execute/pr54985.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/execute/pr54985.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-ssa-threadedge.c
[Bug tree-optimization/54985] [4.7 Regression] dom optimization erroneous remove conditional goto.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54985 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #16 from Jeffrey A. Law 2012-11-02 20:24:54 UTC --- Fixed on 4-7 branch and trunk.
[Bug c++/55183] GCC 4.8 constexpr is too permissive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55183
--- Comment #3 from Andrew Pinski 2012-11-02
20:36:12 UTC ---
The functions dealing with the void* internalPointer() can't be
constexpr on GCC 4.6 and Clang 3.2-trunk, even though GCC 4.8-trunk
accepts it, because of the casts required.
inline void *internalPointer() const { return reinterpret_cast(i); }
[Bug c++/55183] GCC 4.8 constexpr is too permissive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55183 --- Comment #4 from Paolo Carlini 2012-11-02 20:50:48 UTC --- Thanks Andrew, if the issue would actually be about the reinterpret_cast it's indeed very well known.
[Bug tree-optimization/55079] [4.8 regression] false positive -Warray-bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55079 --- Comment #7 from Jan Hubicka 2012-11-02 20:51:31 UTC --- Actually not, what happen here is that we unroll the loop 17 times based on the fact that the array access iterates from taillen to tailen+n_iterations and the array size is 17. Later in compilation we prove that tailen is actually non-zero by VRP and we work the hard way across the unrolled loop body to work out that the last access must be out of bounds. So this is not bug of unroller to not remove statement. Short of teaching SCEV about the value range of initial tailen, we really can't reduce number of iterations. We discussed it here http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01103.html I do not think we really can solve these cases reliably short of silencing the warning on unrolled loop copies and other duplicated statements.
[Bug tree-optimization/55085] [4.8 regression] false positive -Warray-bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55085 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Resolution|DUPLICATE |FIXED --- Comment #3 from Jan Hubicka 2012-11-02 20:55:58 UTC --- This one is solved now (and not a duplicate)
[Bug tree-optimization/55133] gcc-4.8-20121028 dubious array bound check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55133 --- Comment #2 from Jan Hubicka 2012-11-02 20:57:34 UTC --- Fixed. *** This bug has been marked as a duplicate of bug 55085 ***
[Bug tree-optimization/55085] [4.8 regression] false positive -Warray-bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55085 Jan Hubicka changed: What|Removed |Added CC||nat...@t-online.de --- Comment #4 from Jan Hubicka 2012-11-02 20:57:34 UTC --- *** Bug 55133 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/55177] missed optimizations with __builtin_bswap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177 --- Comment #6 from Eric Botcazou 2012-11-02 21:59:27 UTC --- > So what you describe as 'really dumb' is actually something that we *force* > people to do. We'd be much worse off without it. 'really dumb' applied only to the example though, not to your design decisions which are probably reasonable, even if they yield these useless byte-swapping primitives in some cases.
[Bug target/55184] New: Invalid codegen with vectors and casts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55184 Bug #: 55184 Summary: Invalid codegen with vectors and casts Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: math...@gaunard.com Created attachment 28600 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28600 Testcase On x86-64, when 128-bit vectors of long or unsigned long are aliased, an invalid optimization seems to occur and causes only the first element of the vector to be modified. Output is correct when compiled without optimization, but fails with -O1 or greater. Usage of -fno-strict-aliasing doesn't change anything. The problem doesn't seem to appear in the 4.4, 4.5 and 4.7 series. Nevertheless I'd like to know all the cases it affects and whether there is a workaround.
[Bug target/55184] [4.6 Regression] Invalid codegen with vectors and casts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55184 Andrew Pinski changed: What|Removed |Added Known to work||4.4.0, 4.5.0, 4.7.0 Target Milestone|--- |4.6.4 Summary|Invalid codegen with|[4.6 Regression] Invalid |vectors and casts |codegen with vectors and ||casts Known to fail||4.6.3
[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142 --- Comment #18 from H.J. Lu 2012-11-02 23:09:19 UTC --- (gdb) disass $pc - 19, +25 Dump of assembler code from 0xf7dddc7a to 0xf7dddc93: 0xf7dddc7a :mov%r8d,%esi 0xf7dddc7d :sub%eax,%esi 0xf7dddc7f :cmp$0xa,%esi 0xf7dddc82 :ja 0xf7ddd431 0xf7dddc88 :neg%eax 0xf7dddc8a :lea(%rcx,%rax,4),%eax => 0xf7dddc8d :mov%edx,-0x4300(%rax) End of assembler dump. (gdb) p info $4 = (Elf32_Dyn **) 0xf7ffdc38 (gdb) p/x $rax $5 = 0x37ffe064 (gdb) p/x $rax -0x4300 $6 = 0xf7ffdd64 (gdb) -0x4300(%rax) should be zero-extended from SImode to DImode.
[Bug rtl-optimization/54524] [4.6/4.7/4.8 Regression] Spurious add on sum of bitshifts (forward-propagate issue)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54524 --- Comment #7 from Andrew Pinski 2012-11-02 23:32:38 UTC --- Author: pinskia Date: Fri Nov 2 23:32:32 2012 New Revision: 193111 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193111 Log: 2012-11-02 Andrew Pinski PR rtl-opt/54524 * simplify-rtx.c (simplify_relational_operation_1): Don't simplify (LTU/GEU (PLUS a 0) 0) into (GEU/LTU a 0) since they are not equivalent. Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c
[Bug rtl-optimization/54524] [4.6/4.7 Regression] Spurious add on sum of bitshifts (forward-propagate issue)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54524 Andrew Pinski changed: What|Removed |Added Known to work||4.8.0 Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] |Spurious add on sum of |Spurious add on sum of |bitshifts |bitshifts |(forward-propagate issue) |(forward-propagate issue) Known to fail|4.8.0 | --- Comment #8 from Andrew Pinski 2012-11-02 23:33:46 UTC --- Fixed on the trunk.
[Bug target/55184] [4.6 Regression] Invalid codegen with vectors and casts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55184 --- Comment #1 from Mathias Gaunard 2012-11-03 00:29:47 UTC --- Problem seems to occur with i686 as well but only if SSE2 is enabled (you'll need to replace 'long' by 'long long' for this in the testcase)
[Bug middle-end/55185] New: Error generated on extern inline function which isn't called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55185
Bug #: 55185
Summary: Error generated on extern inline function which isn't
called
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
On x86-64:
[hjl@gnu-tools-1 tmp]$ cat y.i
extern double strtod (const char *__restrict __nptr,
char **__restrict __endptr);
extern __inline double
atof (const char *__nptr)
{
return strtod (__nptr, (char **) ((void *)0));
}
[hjl@gnu-tools-1 tmp]$ gcc -S -O y.i
[hjl@gnu-tools-1 tmp]$ cat y.s
.file"y.i"
.ident"GCC: (GNU) 4.7.2 20120921 (Red Hat 4.7.2-2)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-tools-1 tmp]$ gcc -S -O y.i -mno-sse
y.i: In function ‘atof’:
y.i:6:1: error: SSE register return with SSE disabled
[hjl@gnu-tools-1 tmp]$
[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142
--- Comment #19 from H.J. Lu 2012-11-03 02:51:26
UTC ---
This patch:
[hjl@gnu-tools-1 tmp]$ cat /tmp/x
diff --git a/gcc/expr.c b/gcc/expr.c
index 3e8e004..da35488 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -8115,7 +8115,7 @@ expand_expr_real_2 (sepops ops, rtx target, enum
machine_mode tmode,
And force_operand won't know whether to sign-extend or
zero-extend. */
if ((modifier != EXPAND_SUM && modifier != EXPAND_INITIALIZER)
- || mode != ptr_mode)
+ || mode != Pmode)
{
expand_operands (treeop0, treeop1,
subtarget, &op0, &op1, EXPAND_NORMAL);
[hjl@gnu-tools-1 tmp]$
removes most of glibc failures. Does it make any senses? If it
does, there is another place in expand_expr_real_2:
[hjl@gnu-tools-1 tmp]$ cat /tmp/y
diff --git a/gcc/expr.c b/gcc/expr.c
index 3e8e004..816fdb8 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -8157,7 +8157,7 @@ expand_expr_real_2 (sepops ops, rtx target, enum
machine_mode tmode,
And force_operand won't know whether to sign-extend or
zero-extend. */
if ((modifier != EXPAND_SUM && modifier != EXPAND_INITIALIZER)
- || mode != ptr_mode)
+ || mode != Pmode)
goto binop;
expand_operands (treeop0, treeop1,
[hjl@gnu-tools-1 tmp]$
[Bug testsuite/55186] New: gcc.dg/const-uniq-1.c fails due to vector expected but not being in the constant pool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55186 Bug #: 55186 Summary: gcc.dg/const-uniq-1.c fails due to vector expected but not being in the constant pool Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org Target: cris-axis-elf Created attachment 28601 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28601 const-uniq-1.c.004t.gimple While technically this is a regression, the reason for the brief PASS period is likely related to a temporary severe bug in the source tree rather than the more common sequence: a conscious change foiled by a later bug. This is a rare event! This test previously failed, started passing somewhere in the (]-range 193059:193061 (likely due to the bug in r193061) and started failing again somewhere in the (]-range 193063:193070 (likely due to the bugfix in r193064). At r193109, the const-uniq-1.c.004t.gimple dump is as attached: no label present for the expected constant-pool entry. The assembly output for the vector initializations are piecewise, one for each element: moveq 1,$r9 move.d $r9,[$sp+4] The test assumes a single vector in the constant pool supposedly used with some memcpy-equivalent (call or in-line expansion). At first glance, the piecewise initialization might seem suboptimal, but a memcpy call would *not* be better for -Os for this target, when counting the constant vector (well, twice). Piecewise initialization would be optimal - if the storing instructions use post-increment instead of indexing, as expected by the specified relevant target macros. (N.B.: poor autoincdec generation is a long-standing flaw in gcc covered by PRs elsewhere). Constant-pool vectors and memcpy are optimal for e.g. vectors four times as large; will propose such a patch for this test-case.
[Bug testsuite/55186] gcc.dg/const-uniq-1.c fails due to vector expected but not being in the constant pool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55186 Hans-Peter Nilsson changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-11-03 AssignedTo|unassigned at gcc dot |hp at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug target/54791] AIX-only: Constructors are not called in main program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 --- Comment #5 from Adi 2012-11-03 06:21:08 UTC --- Please tell me if you received my email. I got some delivery failures because of attachments. - Forwarded Message - From: "adivilce...@yahoo.com" To: dje at gcc dot gnu.org Sent: Friday, November 2, 2012 4:48 PM Subject: Re: [Bug target/54791] AIX-only: Constructors are not called in main program. After more investigation I saw that I managed to get the constructors called by removing the "inline" keyword from just one constructor of a class that resides in my master header. >From my -Wl,-debug linker options I see that this particular constructor name is used to generate the dynamic initialization in almost every object file. See debug.txt attached for more details. Look for "_GLOBAL__I_65535_0__ZN5TraceD2Ev". Do you know why would that be? Is this a bug ? Do you know why on Linux with the same compiler version and same code is not happening? I have around 1000 member functions that are declared "inline" across various classes. Do you know if there are any know issues with inline and constructors? Any compiler options I should be aware of? I am not using any optimization (yet .. I am planning to). Now after I did this I am still having some other problems. Some object seemed are not initialized properly. I am still suspecting the other inlines might be the culprit. Any ideas/suggestions would be appreciated. From: dje at gcc dot gnu.org To: adivilce...@yahoo.com Sent: Wednesday, October 3, 2012 4:46 PM Subject: [Bug target/54791] AIX-only: Constructors are not called in main program. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 --- Comment #2 from David Edelsohn 2012-10-03 13:46:44 UTC --- Constructors are working because they work without your big header. I would try using divide and conquer techniques to reduce the big header and find out what is interfering with constructors. It gives all appearances that it is due to the user code. Static constructors and destructors are run by functions generated at link time. A programmer wrapper around AIX ld called "collect2" scans object files and libraries for constructors and generates functions that are invoked by AIX linker -binitfini feature. You can add -Wl,-debug to the link line to see the way the AIX linker is invoked and see the helper function. Is something in the big header changing the mangled names of constructors and destructors so that they do not use the standard pattern? Or inserting some illegal character like dollar sign ($)?
[Bug target/54791] AIX-only: Constructors are not called in main program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 --- Comment #6 from Adi 2012-11-03 06:24:03 UTC --- This is the 5thmail I am sending(I got 4 delivery errors because of MIME attachments). After more investigation I saw that I managed to get the constructors called by removing the "inline" keyword from just one constructor of a class that resides in my master header. From my -Wl,-debug linker options I see that this particular constructor name is used to generate the dynamic initialization in almost every object file. See debug.txt attached for more details. Look for "_GLOBAL__I_65535_0__ZN5TraceD2Ev". Do you know why would that be? Is this a bug ? Do you know why on Linux with the same compiler version and same code is not happening? I have around 1000 member functions that are declared "inline" across various classes. Do you know if there are any know issues with inline and constructors? Any compiler options I should be aware of? I am not using any optimization (yet .. I am planning to). Now after I did this I am still having some other problems. Some object seemed are not initialized properly. I am still suspecting the other inlines might be the culprit. Any ideas/suggestions would be appreciated.
[Bug target/55175] i386/sfp-exceptions.c:52:7: error: impossible constraint in 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175 --- Comment #6 from Ralf Corsepius 2012-11-03 06:25:33 UTC --- I can confirm i386-rtems4.11-gcc now builds. @Uros: I am inclined to believe this patch probably should be backported to 4.7.x. At least, RTEMS is facing bizarre compilation issues, which I would not want to be related to similar issues as this.
